- 2005-03-02 (水)
- 日々思うこと
自分の属する開発部はバリバリ「フォーターフロー型開発プロセス」が主流です。幾つか外注パートナー企業とも仕事をしましたが、未だにアジャイルやXP等の「反復型開発プロセス」が常識となっている開発部隊に出会った試しがありません。さらに言うとオブジェクト指向プログラミングを得意とする開発者にも出会えた試しがありません（悲）。そんな中で、うちの開発部でも「いい加減、予測通りに事が進んだ試しが無いウォーターフロー型開発プロセスから脱却しようよ」という声がごく一部ながらも（上層部で無く、現場層から）聞こえ始めてきています。そんな現場層の一人である、とある同僚が部内メーリングリストにはてなでのXP導入例を紹介してました:
「はてな」ではXPを取り入れていて、1時間〜1日で仕様決定からリリースまでやってしまうそうです。http://shibuya.pm.org/slides/200304/hatena.ppt（「要望への対応」のページ）僕の理想です。
少数精鋭エンジニアの集まりって特徴も含め、bashiもこんな形で仕事したいと願います。XPもペアプロもじゃんじゃん取り込んで、良い仕事に繋げたいです。
自分は一度だけプロジェクトにてペアプロ+OOPを試してみただけ(メンバー3名/800万円規模)、の実践経験しかありませんが、現時点で思う、「企業のシステム開発部に属する身として、eXtreme Programming を業務に取り込む際の課題点／問題点」をまとめてみました。XP肯定派ですが、現状の「ウォーターフォール型」が当たり前の体制下で「業務」として導入するには以下に挙げる課題／問題を乗り越える必要があるかと感じています。※上記 はてなCEO近藤氏のプレゼン資料にも「課題」として一部下記とかぶる内容が挙げられていました（受託開発業務への応用ページ）。
前提
システム開発に関係するドキュメントを以下のように定義します（というか、自分にとってのこれらドキュメントの意味定義）
- 要件定義書
クライアントとのコミュニケーションの結果をまとめた要望確認＆システム化提案をまとめた資料
大まかなシステム全体像の定義／インフラ定義を含む
- 基本設計書
より詳細なシステム仕様の定義資料
画面遷移図／データストア定義／各画面イメージ定義
各画面ごとに実装する機能／処理の概要説明資料
- 詳細設計書
エラーハンドリング含む、各画面ごとの詳細なロジックを定義
クラス定義（クラス図、シーケンス図、コミュニケーション図含む）
OOPで無いならば > 共通モジュール（関数）の定義
ソースレイアウト（ディレクトリ構成）定義
要件定義書／基本設計書はやっぱり必要
- 何を作るのかをクライアント（ユーザ）確認する事は必要なのでは？
→クライアントレビュー
- 何を作るのかを開発メンバー内で共有する必要あり
→口頭伝達のみでは複雑な要件を伝えきれない／全員が仕様を把握・記憶できない場合があるのでは？
→すでにあるシステムに対する追加改修案件は口頭伝達のみで共有は可能... しかし新規開発案件でも可能とは思えない（システム要件の規模によるけど）
見積もり算出／スケジュール引きの精度が低くなる
- 要件定義書なしで出来るのか？
- 基本設計書なしで出来るのか？
業務引継ぎはどうするのか？
- XP = 自分達で保守メンテをずっと行っていく前提になってない？
仕様は開発メンバーの頭の中... だけだと、引継ぎ作業の効率／品質すごく悪くない？
- 引継ぎが必要になった時にドキュメント作ればいいじゃん？
→その際の工数／費用はだれが担保する？（クライアントでは無いはず）
開発メンバーに一定以上の知識／技術力が必要
- メンバー全員が反復型開発プロセスのフレームワークを理解している必要あり
- 未知の問題に対する解決能力（意欲）が必要
※これら課題はペアプロが解決策になるっぽい
※そもそも、メンバー同士のお互いの能力に対する信頼が必要だと思う
→信用できない奴に問題／課題を任せる気にはならない
性善説のシステム開発が前提条件
- 参加メンバーの意欲／やる気がシステム品質にダイレクトに繋がる
総論：bashiの考察
- 仕様書無しの eXtreme Programming 開発手法はあくまで「詳細設計書」の存在を無くす為の手法。XP導入したとしても要件定義書／基本設計書 は必要なのでは？
余談
解決策を何ひとつ講じてない辺り、あまり楽しくない内容になってしまいました。課題／問題点... というか、これって僕の「疑問集」ですね（汗）。机上議論では無く、実践で試してみるのが一番手っ取りばやいかと。とりあえず適当な案件で、積極的に試してみるべし。日々精進です。
Comments:4
- ooba 2005-03-03 (木) 00:56
-
確かに、はてなは自前サービスだからあそこまでスピード感を出せているというのはありますな。
ドキュメント残す必要ないもんな。 - bashi 2005-03-03 (木) 14:47
-
質の高い／理解しやすいソースコードであれば、僕もドキュメントに必要性を感じないんだけど... 「ドキュメント皆無＋へっぽこ難解ソースコード」なシステムの保守を業務として引き継がなきゃならないケースが多いだけに、腹立たしさ込めて、僕は皆に「ドキュメントの重要性」を主張し続けています。
でも要は「開発メンバー全員が、質の高い／理解しやすいソースコードを書ける」状態にあれば、そんな不信感を持つことは無いわけで。→ドキュメント作れコラ、と僕も言わなくなる。根本解決にはまず、
メンバー全員が、個々の能力・資質に対して相互の信頼感を持てる状態
に持っていく事が大切なのでは、と思ってます。
信頼できる者同士で仕事ができる環境を築きたいんだけど... 今の場所では厳しいかな（涙 - sachi 2005-03-04 (金) 12:59
-
ちょっと視点が違うかも知れないけど、私は今まさにクライアント側。
bashiが書いている通り、前提以下のことがちゃんとしてる開発会社ってあまりなくない？
私たちが出しているスケジュールに無理があったりするのかも知れないけど、
それにしても・・・っていう設計書ばっかり。
挙句の果てに、設計書に赤字を入れて修正してもらってるのよ〜。
それは今も変わらないんだけどね。
- bashi 2005-03-04 (金) 14:52
-
あ、さっちゃんこんちは♪ ←同会社別部署の友達
> 前提以下のことがちゃんとしてる開発会社ってあまりなくない？
XPだ反復型開発プロセスだって話以前に、通常のウォーターフォール型プロセスでのシステム開発ですら ろくに出来てない実例
の紹介ありがとう（笑
クライアントがシステム設計書に赤字入れてる状態（しかもC/O後と聞いてます） ...ってどうよ？（汗
我らの会社＋周辺環境がたまたま、そういう「イケてない開発屋さん」に恵まれた環境にあるだけなのか、それとも世の中の多くのシステム開発業務の実態はそんなもんなのか... 個人的にとっても興味あります。
sachiの事例でも、仮にその開発チームの中に１人でも「仕事にプライド持って、情熱注いでシステム作る意欲アリアリ」という姿勢の方がいたとしたら、残りのメンバーに足引っ張られてるであろうその人に同情するよ...======================
※sachiさんへ、部外者からのアドバイス
設計書がイケてないという事は、作り上げたシステム自体もイケてない可能性が高いです。
C/O後にクライアントが痛い目を見がちなのは、今後のメンテナンス・追加改修案件の際に、初回でイケてない作りにしてしまったがために、そこに手を入れる（追加改修）際も
無駄に労力／時間／工数がかかってしまうこと。＝不当に高額な見積もりを提示されがちな事
だと思います。不当かどうか（手間がかかる原因がクライアント要件では無く、システムの作りにあるかどうか）の判断を、面倒くさい＆難しいだろうけど、クライアントの sachi 達が見極めたうえで、高額見積もりに対してツッコミ入れていかないと、お金を搾取され放題な状態になっちまいます。