このプロジェクトマネジメントを続けてはだめだ！！もういい加減に成長しなければいけない。
そんな思いからアート・オブ・プロジェクトマネジメントを読んだ
オライリー・ジャパン
売り上げランキング: 96079
バイブルにしています
プロジェクトマネジメントに関する教科書的な一冊 プロマネ、必読 プロジェクト大災害で大炎上 真のマネジメントがここにある
目次
- 計画
- スケジュールの真実
- やるべきことを洗い出す
- すぐれたビジョンを記述する
- アイデアの源
- アイデアを得た後にすること
- スキル
- 優れた仕様書の記述
- 優れた意思決定の行い方
- コミュニケーションと人間関係
- メンバーの邪魔をしない方法
- 問題発生時に行うこと
- マネジメント
- リーダーシップが信頼に基づく理由
- ものごとを成し遂げる方法
- 中盤の戦略
- 終盤の戦略
- 社内の力関係と政治
そもそもなぜソフトウェア業界はこんなにもプロジェクトマネジメントを声高にする必要があるのだろうか。
事業規模で考えれば他業界でもっと大きなプロジェクトはたくさんある。もちろん、それらプロジェクトがすべからく成功を収めているかというとそうとは言い切れない部分はあるが、、、
本書はプロジェクトマネジメント全般にわたって書かれてはいるが、ここではこの頃私を悩ませている仕様書に関しての話題に言及したい
仕様書は必要か？
本書ではプロジェクトに必要となる書類として以下のものを定義している
- 要求仕様
- プロジェクトに期待される様々な物事を文書化するため、作業によって達成されるべきすべての要求と責任の概要を記述する
- 機能仕様
- 顧客の視点から見た特定のシナリオやシナリオ群における振る舞いや機能を記述したもの。ソフトウェアの機能をユーザーインターフェースを通じて解説し、なるべく技術的な詳細に踏み込まないようにしつつ、物事の動作方法を解説する。要求の一覧ではなく、それを実現するための機能の一覧。
- 技術仕様
- 機能仕様を満足するために必要となるエンジニアリングアプローチの解説。もっとも複雑なコンポーネントや、他のプログラマが再利用する可能性のあるコンポーネントを開設したり、機能仕様に必要な作業項目に対して技術的な裏付けを提供できるだけのレベルで十分。
- 作業項目一覧（WBS）
- 機能仕様を満足するために必要となるプログラミング上のタスクを解説したもの。
- テスト基準とマイルストーン達成基準
- 各テストケースの優先順位と、各マイルストーンにおける品質目標を満足するためには、コードが該当テストケースにおいてどの程度正しく動作する必要があるのかという目標。
私のこれまで携わったプロジェクトでは、要求仕様や機能仕様を合わせて外部仕様書と読んだり、機能仕様と技術仕様がごちゃっとなって内部仕様書と読んだりしていた。ちなみにWBS、テスト基準等はそれぞれの文書として独立させることになる。
恐らく本書で述べられているこれら内容は別に独立した文書である必要はなく、それらを網羅するべきということなんだろう。
私の場合は転職経験があるわけでも、大学でソフトウェア関連のことを学んだことがあるわけではないので他にどういう形の文書があるのかは知らないのが現実だ。
内部仕様書に記述する技術仕様は、どの程度まで記述するのかが問題となるのではないだろうか。仕様書を書くことが本来達成するべき仕事ではないので、これらの切り分けをどうしていくのか…。内部仕様書に関しては、社内の誰に対して文書を書くか？ってことになるのかもしれないなぁ
仕様書と設計書の違い
設計段階では仕様は固まっていない。未確定な内容が含まれており、それに対する議論や検証を行う必要がある。それらを経て、実際のモノづくりを行う作業の前に仕様書を作るべき。
設計書と仕様書を同時に作成しようとした場合、設計の変更に伴う仕様書の修正工数ばかりが増大していき、仕様書は意味のあるものとして成り立ちづらい。もしくは計画そのものが破たんする。これらは全く別のプロセスとして動かす必要があるだろう。
ううん、言っていることは分かるが…。
実際のところ、現場では設計書と内部仕様と作業指示がめちゃくちゃになっている。内部仕様書が正しく仕様書としてなりたっておらず、中途半端な設計書になっているだけだった。
だからこそ、”何の文書を書くのか”ということが明確になっておらずに、文書の作成に行き詰ってしまっているのだと思う。
そう考えると、これらを全く別のプロセスとして捉えて取り組むというのは分かる話ではあるのだが…。
ううん、時間がないっていう言い訳をしてはいけないのは分かるが時間がない。時間を捻出する手立てを立てなくてはいけないなぁ
多くのすぐれた仕様書では、設計が階層に分けられた上で記述されている。まず最初に、顧客のエクスペリエンスが顧客の言葉で記述されている。次に、基本オブジェクトの大まかな概要とアーキテクチャが記述されている。そして最後に、エンジニアリングにおける、設計上の複雑かつ詳細な問題が記述されている。
ふむぅ
やはり、仕様書か設計書か。
どうしても私は今自分が見ている”仕様書”が頭に入ってしまっていてここで述べている”仕様書”との間には隔たりがあるようだ。この隔たりを解消するにはどうしたものか…。やはりここでいうところの”優れた仕様書”を見てみるのが一番だと思う。
Joel on Softwareでおなじみのジョエル氏のページには氏が”優れた仕様書”のサンプルを出している
- 仕様書とはどんなものか？(Joel on Software)
- 機能仕様書サンプル (Joel on Software)
んー・・これ見たことあるな…。たぶんJoel on Softwareにそのまま載ってるな…。
はい、出直してきます