要件定義フェーズ
要求を記述していない仕様書があまりにも多い。
- 要求には、理由(背景)がある
- 要求には、範囲がある
- 要求は、仕様を導出する
- 「概」の付く文書は、不要
- 要求は、カテゴリ化する
- 機能単位
- システム単位
仕様は、次のポイントを考慮すべし。
- 仕様間の境界をMECEにする。さらに、この境界の分割基準を明確化、共有すべし。
- 時系列分割
- 構成分割
- 状態分割
- 共通分割
- 仕様の階層は、2階層程度が妥当。
- Numberingを活用。
- 仕様がフローになっても良いが、グループ化により流れを区切るのが良い。
要求仕様の変更管理も重要。
- 差分のみを記述すれば良い。
- 変更
- 追加/移植
- 削除
- 変更要求を仕様化する
- 修正前の状態も記述するべき
- トレーサビリティ・マトリックスを活用
要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?
- 作者: 清水吉男
- 出版社/メーカー: 技術評論社
- 発売日: 2005/10/07
- メディア: 単行本
- 購入: 11人 クリック: 220回
- この商品を含むブログ (72件) を見る
システム開発方法論
ソフトウェアを効率的に開発する方法はないか。そう思っていろいろ調べてみるとよさそうな本に出会う。
SOFTWARE FACTORIESソフトウェアファクトリー
- 作者: ジャックグリーンフィールド,スティーブクック,キースショート,スチュアートケント,マイクロソフト,Jack Greenfield,Steve Cook,Keith Short,Stuart Kent,野村一行
- 出版社/メーカー: 日経BP社
- 発売日: 2005/12/17
- メディア: 単行本
- 購入: 5人 クリック: 95回
- この商品を含むブログ (36件) を見る
この本で新しかったのは、ソフトウェアを工場化し、コンポーネントの再利用を促進するために、①まず工場を作ること（プロダクトライン開発）、②その工場の中で、製品を作ること（プロダクト開発）を明確に分けることを提唱している点だ。
①は、いわばフレームワークやWebサービス、デザインパターン、ライブラリなどをうまく組み合わせて、その製品を作るために最適化された土台を作るということである。この重要性を認識して、SIプロジェクトに適用している例がどれだけあるのだろう。
また、アスペクト指向で横断的な関心事を分離し、プログラマにはコンポーネント開発にのみ専念できるようにすることや、DIによって、コンポーネントの疎結合性を高めるといった考え方も重要だと思う。
本書でも触れられているが、今後オフショア開発が進んでいくときに、オフショア化による品質の問題というのは、これである程度解決されるのではないだろうかという期待がある。①を作ったうえで、②をオフショア化し、最低限の品質を担保するというのは有効ではないか。
プロジェクトをマネジメントする上で、技術の力によって効率性を追求するというのは、一つの重要な手法である。最新技術がゆえ、メンバーがキャッチアップするのにコストがかかる、技術的に未成熟であるなどの問題はあったりするが、そういったリスクを覚悟の上で、長期的に見て何が一番効率的かという視点を持ちたい。
しかし、この本は2005年に出ていたのか。チェックが遅いな。。。まあ、そのときは入社もしていないから仕方がないといえばそうだが。この辺は完全に勉強不足なので、今後勉強していくことにしよう。
プロジェクトを成功に導くために
プロジェクトマネジメントとは、スコープ、コスト、スケジュール、人的リソースなどの制約条件下において、成果物をクライアントの期待を満足するレベルで提供することだと思う。
ここで、プロジェクトを成功に導くために、重要な点が3つある。
まず、制約条件は、コントロールできるということ。制約条件が限られた領域では、そもそも解空間が狭いため、局所最適にしかならない可能性がある。プロジェクトが失敗する原因の一つは、この制約条件が非常に限られた状態があらかじめ決定され、そこからプロジェクトがスタートすることにある。始まったときには、すでに勝負がついてしまっている。
すなわち、スコープ、コスト、スケジュールなどの制約条件はできるだけ広く確保するべきである。そして、プロジェクト開始後でも、その制約条件を変更することができるのであれば、変更を検討するのは、重要なことである。制約条件は、条件としてあくまでも変えず、力技で何とかしようとする例があまりにも多いように思う。
次2点目。プロジェクトの成果物は、大きく言って、システム開発の場合は、システムであろうし、プラント建設の場合は、プラントであろう。その場合、成果物のレベルは、あくまでもクライアントの期待を満たしたかどうかということである。言い換えれば、プロジェクトの成否は、ステークホルダーの期待を満たすかどうかで決まる。つまり、ステークホルダーの期待レベルを上げすぎないようにコントロールするのが非常に重要だ。
最後3つ目。制約条件も成果物のレベルといった外的要因をこれ以上コントロールできないとなれば、あとはプロジェクト内部をいかにコントロールするかということになってくる。そこはいろいろなことが考えられると思うが、僕は「モチベーション」と「効率化」がキーポイントだと今は感じている。
限られたスケジュールと人的リソースで求められるレベルに達するのは容易な事ではない。時には、それを長時間労働でカバーするのはやむをえないと思う。そういう日々が日常になると、やはりチームのモチベーションは下がる。倒れる人が出てくると、チームの雰囲気はさらに悪くなる。そんな時、やはりリーダーが「絶対にやり遂げる」という意志を見せ、周りを鼓舞することで、チームの雰囲気は変わる。そして、チームが一丸となって一つの目標に向かえた時、チームの力は、個々の能力の総和を超える。僕は、その力を信じている。
ただ、やみくもに勢いで突き抜けるというのは、リスクがある。長時間労働が続くと必然的に効率は下がる。したがって、忙しくても時には早く帰る、土日は休むということは、長期的に考えると効率的だったりする。
以上、まとめると、
- スコープ、コスト、スケジュールなどの制約条件は、プロジェクト開始時に広く確保すること。
- 開始後であっても、変更できるのであれば、変更を検討すること。
- プロジェクトの成否は、ステークホルダーの期待を満たしたかどうかであるということ。
- 制約条件下で、チームのパフォーマンスを最大化するためには、個々のモチベーションを上げ、チームが一丸となること
- 忙しい中でも、常に効率性を考え、仕事の仕方を工夫すること
はじめに
システム開発に携わって3年。
これまでは、デファクトスタンダードなる方法論に従い、先輩のやり方をまねることで仕事をしてきた。
SI業界の構造、慣習、システム構築の作法なども学んだ。
でも今こう思う。"もっとうまいやり方があるはずだ。"
それを今体系的にこうだと提示することは、まだ僕にはできそうにない。ただ、そういう目を持ち、現状のやり方に満足するのではなく、より良い方向を求め、自分自身が考え、現場で実践することは有益なことだと思う。
このブログは、僕が日々感じる疑問を示し、それに対する解法を考えていくことで、新たなシステム開発の方向性を模索していくものにしたい。
このブログで扱おうと思うテーマは、プロジェクトマネジメント、リーダーシップ、コーチング、システム開発方法論、テクノロジートレンドなど。
