昨夜から今日にかけて、ある一冊の本を読んだ。
「ITアーキテクトのためのシステム設計実践ガイドVOL.3」
お恥ずかしい。この本に書いてある大事なことを何一つできていなかった。
正直、上記のことを守れたとしてプロジェクトの予算、納期を考慮するとQCD全て満たせたかは分からない。
今回特に失敗したところを以下に挙げておく。
1.各工程で作るべき成果物、作業、そして完了基準が明確でない
1.1 要件定義（私がプロジェクトに参画する前）
お客さまからいただいたRFPに基づき先行作業をしていたが、なぜか基本設計書の執筆になっていた。なぜ作成すべきもの、タスク（WBS）を整理していないのか。情報収集していたが、情報収集した結果をドキュメントで整理していなかった。当然、収集した情報を整理・分析できていない。 今思えば、この時点でプロジェクトが破綻するのは当然だ。
1.2 基本設計以降
その成果物を何の目的で作成するのか、共有できていない。 つまり、目的がないということは当然完了基準が明確にならない。 何も考えずウォーターフォールで作成する成果物を作成している。
特にユーザIFまわりの確認、合意は重要だ
2.ユーザの要件をプロトタイプで確認していない。その結果、納品後にユーザからの不満が次々と出る。
今回、新しいフレームワークを使用することとなった。 納品前までは、設計書、モックアップ(HTML)だけでユーザと確認していた。
下記、ユーザが重視するところをプロトタイプを作成して確認してもらっていなかった。
- バッチ系のプログラムのパラメータの入力チェックエラー時のコンソール出力
- 画面のエラーメッセージ
- ログ出力
プロトタイプを見せることによってユーザが気づいていなかった要求を洗い出すことができる。要求を早めに洗い出せば対処もしやすくなる。
何でもかんでもプロトタイプを作ればよいというわけではない。プロトタイプの目的とスコープを明確にしないとユーザからの要望が噴出し、プロジェクトが前に進まない。
3.見積もり前提が不明確
見積もりの前提がWBSを起こすには不明確だった。PMの「一括請負」という契約 = 「何でもやる」という雰囲気がプロジェクト内に蔓延していた。PM自身が、これに対応したら対応できる人とどれくらいの工数がかかるのか把握できていないためだ。全体のWBSを洗いだしていないため、工数がどれくらいかかるのか把握できていない問題がこういった結果を生み出す。一括請負だからこそ、契約でWBSに落とせる範囲まで決めないと全て請け負った側の責任となってしまう。見積時のメンバーではWBSを洗い出す力もないから結果お客さまに説明できず一方的に値切られてしまう。
4.WikiなどWEB上での情報共有の仕組みを作っていなかった。
メンバーに周知することをWikiなどで情報共有する仕組みを考えておらず、口頭での周知になってしまった。口頭で周知することも非常に大事だが、そのための準備を怠ったため、開発現場が混乱した。一番の問題は、そのような情報共有の仕組みをWBSに計画していなかったこと、責任分担を曖昧にしていたことだ。リソースにも含まれておらず自分自身が非常にしんどい思いをした。今後はそのようなことがないようにWBSを作成したい。
5.性能の問題のため高度なスキルを持った人が不足
性能問題を解決できるスキルを持った人をアサインしていなかった。問題となる機能を洗い出し、早い段階で製造して問題がある場合は、対策を打つようにしないとまずい。今回、性能に問題があった場合も自分で対処することになった。結果、他の重要なタスクを後回しにせざるを得なくなってしまった。
6.実装・テスト工程は、メンバーを増員した場合の対処を準備しておく
プロジェクトの後半になって、問題が表面化してリカバリするためにメンバーを増員することがある。こんな場合も想定して、機能分割、構成管理の運用方法を準備しておく必要がある。特に、共通ファイルの取り扱いを明確にしていないと開発現場が混乱する。
7.新規フレームワークを採用する場合は、効果を早い段階で検証する
プロトタイプを作成して、開発前にサンプルコードを作成しておく。平均的なプログラマは、機能を0から実装することはできない。同じようなプログラムを参考にして実装する。彼らのフレームワークに対する学習効果を想定してスケジュールを組まないと、実装時の生産性が上がらない。そのためには、自組織が調達できるエンジニアのレベルを把握することも重要である。
8.大規模開発では、ある程度の重複を受け入れる
何でもかんでも共通化をしてしまうと、定数、共通ロジックの追加・削除の申請に手間がかかってしまい生産性を下げる原因になる。
どこまで共通化してどこから分割するのか現場経験豊富なリーダが決めて周知する必要がある。
9.各テスト（特に単体テスト）の定義を明確にする
各試験で、何をどこまで試験するか、チームの主要メンバーで決める必要がある。
特に単体テストの定義は重要。オブジェクト思考開発を経験した人とそうでない人では、単体テストの定義が違うことが多い。
ましてや、JUnitを使って下さい、といった場合、スケジュール(WBS)を立てる場合、「メソッド単位」なのか「クラス単位」なのか、あるいは「機能単位」なのか決めてからでないと意味のないスケジュールとなってしまう。当然、「メソッド単位」での単体試験を実施する場合のほうが工数がかかる。更に問題なのは、仮に単体テストを「クラス単位」に試験と定義した場合、「機能単位」での試験項目は、「単体試験」となるのか「結合試験」となるのか明確にしていない場合が多いのである。ありふれた用語を理解せずに使用すると、後工程になってから問題が表面化し、取り返しのつかないことになる。
10.テストの自動化は、テスト結果の検証も自動化しないと効果がない
テストをJUnitなどのツールで自動化するには、テスト結果の検証も自動化する必要がある。
テスト結果の検証を自動化しないとテストの工数はそれほど変わらない、むしろツールの使い方で悩んだり手間がかかってしまうので工数がかかる。検証項目が多い場合は、ツールに設定すること自体時間がかかってしまうので、Excelを使った方が早い場合もある。
そこを考慮した上でテストツールの採用を決めることが重要である。
P.S.改めて画面のレイアウトの検証でツールを使うのは難しいなぁと感じる。
他にも失敗したところが多々あるが、まとめると以下３点になる。
- 目的を考えて仕事をしていない（既存のテンプレートに沿って作業している）
- 見積もり時に前提となる必要なタスク(WBS)を洗い出せていない
- 各メンバーの役割が不明確
本当に情けない限りだが、次回からはこの失敗談を伝えることで、対処方法などの説得力が増すはずだ。
これから改善する点を更に整理する。
0 件のコメント:
コメントを投稿