« December 2006 | Main | June 2007 »

2007.04.22

大規模ソフト開発の宿命

今の会社に転職した際の動機のひとつが、ものすごく大規模なソフトウェア開発をやってみたいという好奇心だった。以前の会社では数人単位の小さな案件がほとんどで、多くて10人程度のプロジェクトしかなかったのだ。

運良く、転職後しばらくして、ソフト開発者のみで数百人規模のプロジェクトに2年程関わることができ、ようやくひと段落したので、その感想を書いておこうと思う。

ソフト開発における最大のボトルネックは、開発者間のコミュニケーションだと良く言われるが、大規模開発になると、このコストがとてつもなく重くのしかかってくる。

本部のトップの偉い人、課の偉い人、企画担当者、仕様担当者、UIデザイン担当者、OS/ミドルウェア担当者、アプリフレームワーク担当者、担当機能部分の要件分析/設計担当者(←自分)、実装担当者(←1部自分)、テスト担当者等、、、

ひとつの機能を搭載して世に送り出すためには、役割別でこれだけの人たちが関わってくる。しかも各役割ごとに数人の人たちが参与することも珍しくない。

そんな中で、最初に猛烈に揉めるのが"仕様"である。市場動向、ユーザーニーズ、規格的制約、ハードウェアのリソース的制約、既存ソフトの仕様の制約、スケジュール、工数、担当者のスキル等を鑑みて、何度何度もミーティングとメールを繰り返す。

そして、仕様の内容は、一担当者の意見で決められるものでもないので、関係者から少しずつ情報収集をして、決断を下すための判断材料をかき集めていき、資料にまとめあげる。仕様に関係する人数が多ければ多いほど、この仕様策定にかかる時間が比例して長くなり、実際に実装に取り掛かかるまでコストが増大する。

仕様が決まると、今度はその機能に関係するモジュールを洗い出し、モジュールごとの責務を割り振っていく。ここで各実装担当者間の利害と感情の調整が始まる。皆バグが生まれそうな複雑かつ面倒そうな部分は自分の担当に抱え込みたがらない。(当たり前な行動ではある)。全体設計の整合性や実現方法の提案、メンバーアサインの変更案など、ロジカルな正攻法から押してみたり、確か前回ここは譲ったよねとか、別の人から要請してもらったり等、変化球を織り交ぜて、説得を試みる。憎まれ役になることを覚悟で強引に押し切るという手もあるが、敵をつくってしまうと結局うまくいかなくなるので、その手は使わない。

それでも、引き取り先がないまま宙にうく要件がでてくると、全く新規の吸収モジュールをつくり、別の担当者にアサインしたり、自分で書いたりするわけである。

モジュールごとの担当が決まると、今度は進捗管理が始まる。皆複数の案件を抱えているので、常にウォッチしていないと簡単にストールして、Remindしないと一週間くらい平気で経ってしまう。

そして、自らの担当ブロックに関しては、出来る限りコミットログを読んで、実装コードのチェックをする。危なそうな内容が多い場合にはコードレビューの場を設定する。なかなか統合が進まない場合には、自らコードを追って具体的なコード内容まで指示して、正面突破を図る。

仕様決定に伴い、実装工程と平行して実施するのがテスト担当者への仕様の説明と評価項目の整備である。本当は実際のテスト作業項目を全部こちらで列挙できれば良いのだが、とてもそこまでは回らないので、ある程度から先の粒度は、評価担当者に任せる部分がでてくる。このテスト項目の洗い出し時点でそもそも仕様としてつめ切れていない箇所が発見されたりすると、また関係者間で議論が巻き戻って始まったりする。

こうしたへビィなプロセスが、ものすごく単純な機能をひとつ足すだけでも発生するわけである。いかにこのプロセスを効率よく回していくかが勝負のポイントになるわけだが、いくつか学んだ教訓は以下の通り。

・仕様や分析/設計の内容は簡潔かつ明快な資料にまとめる
 -議論の過程も必ず記録しておく
 -あとから仕様検討に参画した人が同じ議論を繰り返すことを防止する
 -複雑な要件はできるだけ図や表に書き起こすようにする。安易な箇条書きの繰り返しは避ける。

・実装進捗管理にはバグデータベースを使う
 -BugzillaやMantisなどのTodo票を活用して、進捗がどこで止まっているかを
  常に把握できるようにする

・仕様が決まったら必ずすぐにテストケースの策定に取り掛かる
 -検討漏れや設計で考慮すべきポイントをあぶりだすことができる
 -仕様の理解不足や開発の進捗情報共有不足に起因する
  無駄なバグ票の起票を抑える

・適切な範囲の情報共有を怠らない
 -ついつい限られたメンバーで議論を終えてしまいたい誘惑に駆られるが、
  あとからそこに加わっていなかった人から猛烈な反対にあって結局振り出しに
  戻ったりする
 -直接は関係ないと思われる場合にも若干広めに情報を配信する
  ようにする。議論が収束して最終決定をしたら、出来る限り早く全体に公開する

ソフトウェア開発に銀の弾はないと言われるが、本当にない。

ここに書いたことも当たり前すぎる内容なのだが、これらを当たり前にやることがとてつもなく難しい。ついつい楽なほうに進んでいき、やるべきことをスキップしたい誘惑に駆られるのだが、そこを踏みとどまってある意味愚直にやるべきことをやっておくと、後が楽になる。

RUPもXPもスクラムも、効率を上げる手段ではあるが、それだけではプロジェクトはうまく回らない。結局、地道な改善プロセスを経て、参加メンバーに適したやり方が醸成されていくので、それを忠実になぞって行くアプローチだけが頼りになる。

大規模プロジェクトを経験してからというもの、自分ひとりで仕様を決め、UIを考え、設計して、実装してテストする。この営みがいかに楽しくて効率的なのかが実感できるようになったので、家での自作ソフト開発をしている時間が至福のひと時だったりする今日この頃なのであった。


| | Comments (0) | TrackBack (0)

« December 2006 | Main | June 2007 »