プロジェクト失敗原因となる典型的症例
とある(中規模以上くらい、200人くらいの体制)プロジェクトを見てきて、それを分析してみる。
- VSS (VisualSourceSafe) を使っているせいで名前変更などのつまらない変更に全員が同期していっせいに対応しなければコンパイルエラーの嵐
余計な TODO の増加。
ちなみに名称変更は全体を一日近く停止させるイベントだった。
また、ファイル削除がローカルに反映されないので、誰かがファイルを削除するとローカルに残ったソースでコンパイルエラーというケースが頻発。
CVS なら(以下略)。 - 内部ライブラリの API がタコ
呼び出し側に負担を強いる仕様。変更のたびに全員が(以下同文)。
ライブラリは直感的に利用した時に通常の動作をするように、特別な操作をしたい時にオプションを指定できるように。
そして利用手順は最高でも３ステップまでにしよう。
個人的にはあるクラスAへのオプショナルパラメタのためにクラスPを用意すべきでないと思う。相当オプションが多い場合はわからなくもないけれど、典型的な利用者のためにクラスAのメソッドとして提供されるべき。
一言で言うなら、API は利用者のこと、特に利用の手間を最優先に考えようってこと - wrapper の氾濫
ライブラリが使いにくいということで、wrapper を作りまくる。自分の担当範囲でしか用いないならそれはそれでいいが、同じ機能を実現する wrapper が複数作られ、「全員それを使って」アナウンスが頻発。どれを使えばよいのやら＆アナウンスのたびに全員が(以下同文)。 - 開発環境/実行環境の構築ノウハウの多さと、それが口コミでしか伝わっていないこと
ビルドは全開発者が実行すること、それに注意事項がたくさんあることはミスを誘発。
その上、その手順/ノウハウに日々変更が入り、全員がそれに従うようにとのアナウンス。アナウンスが無いことも多々。
動かないという話の半分以上が VSS の使い方によるバージョン不整合及びビルド手順のミス。
チェックアウト→実行までの手順は最初から最小化されているべき。
あるいは、せめて一貫したドキュメントをワンステップで辿れる所に配置してメンテナンスすべき。 - 各種アナウンスのダメさ
「全員が」これこれに注意せよという類のアナウンスが多すぎ。
全員がと書かれていない場合は「関係者は」と書かれていたり。
見るべきアナウンスなのか否かの判別が苦痛。
ただ、これに関してはベストな改善方法はまだ思いついていない。
おいらなら、そもそもそういったアナウンスをできるだけしなくてよいように環境を整備するけど。 - ドキュメントの検索性/追跡可能性の悪さ
Excelのドキュメントが数百。
さらに新たなドキュメントが数100KB の zip 形式で ML に添付されてくる。読む人はごく少数。
grep できない。ドキュメント置き場はカテゴライズしているがカテゴリの意味が理解できないことと階層を辿らないといけないので辿れない/辿らない。さらに同じ文書の版違いがたくさん。
(ここはあくまで個人的にではあるけど)プレーンテキストがいい…せめて grep しやすいものが…。 - 仕様書主義の癖に仕様変更ばかり
仕様が変わるのは当たり前なので仕様書主義が間違っている。
これは顧客説得まで絡む話なので、やはり該当プロジェクトで改善できるかというと難しいだろうけれど。
おいらなら、そういうのを強要される仕事は受けない。少なくとも今後は。 - 誰が何をやっていて、自分が何をすべきで、このシステムのアーキテクチャが何なのか理解しているのが極少数
元の要求や業務背景に基づく各種概念のややこしさがあるのは仕方がないし、ある程度の規模だとこれが難しいのはよくわかる。
ただ、問題は、用語/概念の定義がいいかげんでまぎらわしい部分を用語レベルで正さず、顧客用語をそのまま用いている所にあると思った。使っている当人も似た異なる意味として定義されている用語と誤用していたり。それを全員に理解しろと言いますか？ - 規約のタコさ
工業生産的規約とそれに縛りを入れるためのプリプロセスツールに縛られて、設計の自由度が減少し、歪みだらけ。
オブジェクト属性定義書のようなものからクラスを自動生成することになっているが、相互依存関係にあるフィールド群、例えば数量/単価/金額とか、金額/税額/税込金額とか、計算で求まるものにまでフィールドを与える結果になっていて、これじゃ内容の整合性を保つのが大変だろう…。データの重複/コードの重複あたり前。
多段になったプリプロセスツールのおかげで、ビルド手順の複雑化の後押しに加え、変更が掻き消される(自動生成されたソースを修正してたりとか)事件も。これは自動生成されるファイルまでチェックインしているから、という問題でもあるが。
どんなプロジェクトでも、スキルの下限はかなり低い所を想定しなければならないので同情するけど…。というか、あの状況で挫けずに仕事できる人って別の意味でスキルがすごく高いわけで、尊敬に値するわけですが^^;。 - 設計のタコさ
クラスの分割単位が変。データ構造的に問題。フィールドが30以上くらいあるクラスがざら。その状況でフィールド間の相互依存が何通りもあるわけだから…。
えーっと、クラスってのはモジュール化の結果でもあるわけで、例えば先に示した「数量/単価/金額」なんかならそれを pack したクラスとして定義すべきでは？と。プログラマの意識しなければならない範囲を狭めることにこそ意義があるってのに…。
それを後押ししていたのが前述のプリプロセスツール。細かい意味の単位でモジュール化を行うことを億劫にさせるという効果もあるのでしょう。そのフェーズには参加してませんが。 - コンテキストベースの UI 設計
部品単位の独立性/モジュール化ではなく、あらゆる場面をリストアップして、場面ごとに各部品がどう振る舞うかを決めていっている。
これでは、特定部品がどのように振る舞うべきかが読み取りにくい。ただし、この方針は、これをそのままテスト仕様書として使えることを想定しているらしい。その気分は分かる。
しかしその仕様書をベースにプログラムに落とし込むのはすさまじく苦痛な作業だ。すべてのコンテキストを判定して分岐し、分岐先で全部品のパラメタ設定を行うという檄コード重複な作り方が推奨されるらしい。やだよそれ…。
基本は部品単位で例外的状況への対応を行い、複数の部品に影響を与える特定コンテキストだけきり分けるのがよいと思うけどなぁ…。State を使えばよかったか…とも今さらながら思うけれど、他の人達はずらずらと書いていたようだ…。
この問題はまだ完全な解答を持っているわけではないけれど、State パターンを使うことを周知するのであればそれはそれでいいのかもしれない。しかしそれによって重複は減らせても、やはりむやみにコード量が増大する策だ、と思う。大体特定部品が特定の状況でだけ disable になる、みたいなのを一つの State とみなしちゃうようだと、いったいいくつの State になるのやら。
そんな感じで、ある程度規模が大きい開発プロジェクトが難しいのはよくわかるし、自分はそういうプロジェクトのリーダにはあまりなりたくないし、それをやっている方達はすごい、と素直に思うわけですが、上記の中には、やるべきことをやっていてもなるべくしてなるバタバタというより分析レベルからおかしく、それに引きずられる形でデータ構造設計、プログラムの設計にも曖昧さといいかげんさを引きずってるケースが多いわけですね。
ヘルプ的に導入される方は、みな対処療法に専念するわけです。自分だったら本気モードの場合は設計フェーズが終りぎみだったとしても再整理をやるだろうけれど、今回はお手伝いに徹しました。が、担当部分のインターフェイスだけに着目しててももともとの用語の紛らわしさと、事あるごとに一日無駄になる環境の変更には正直耐えられなかったなぁ。
