題名は書籍のタイトルです。今回はPM試験対策として読んだ本について紹介します。
書籍
なぜ、システム開発は必ずモメるのか？
昨年のプロジェクトマネージャ試験（PM試験）受験の際に購入した書籍を振り返ってみました。
以下、過去記事より転記。
IT訴訟やトラブル事例から教科書的な対策案の物語調で紹介していく本。
私はこの本結構好きで、PM経験はもちろん現場経験もそんなに長くない人がPM試験を受けるときにも軽く読んで軽くネタ集めするのにいいのかなとも思ったんですが、私が落ちてしまったせいであまり推せませんね。。
今回はPM試験の論文を書く際に使えそうな考え方などを中心に、少し現場のことも交えながら目についたものを書き留めていきたいと思います。
具体的な解決方法は個々のプロジェクト状況によって考えた方がよいと思いますので、問題を考える起点になればよいのではないかと思います。
要件定義
何度も要件を追加してくるユーザ
確定したはずの要件をユーザが次々と追加・変更するために作業が進まず、開発は予定より2か月も遅れています。
最初に確定した要件も立場が異なるユーザがでてくるたびに意見や主張が変わる状況。
ユーザの出す要件変更がプロジェクトに及ぼす影響は専門家であるシステムベンダでないと分からず、メリットやデメリット、追加費用などを検討しベンダ側からユーザをコントロールする姿勢が必要になる。
■本書より
・要件変更に関する定期会議を設定する。
・計画時に要件変更に対処するための管理工数を見込む
■PM試験的には
「何度も要件を追加してくるユーザ」は現実的にも起こりそうな問題です。本書でも別のページで、要件定義工程で全ての要件が固まることはないという記述がありました。
試験的には例えば以下のようなストーリーが思いつきます。
要件定義工程は完了し、基本設計工程、詳細設計工程にて要件の変更が発生する。そのまま受け入れると、コスト超過や進捗遅れが発生する。
要件変更のプロセスを確立し、開発側か顧客側に起因した要件変更を切り分ける。
切り分けの結果により予算の増加や期限の延長を検討する。
要件の変更プロセスは計画時に確立しておくべきことな気もするので、問題とするのは要件変更が多すぎるため、そこを抑制するのが対策になるかもしれません。
試験的には2か月の遅れは物語の振れ幅が大きくなりすぎるので私の技量では避けます。
そもそも要件定義とは何を決めるのか？
そもそも「要件定義」とはどのようなことをする作業なのか、いま一つ理解できていません。
要件定義の作業自体を列挙するととてつもない量になってしまうので本書でも深くは触れられてはいません。
■本書より
・システムの要件を定義するために、対象となる業務自体の処理や流れを定義する。
・最初はコンピュータのことを意識せずに定義し、システム化範囲とシステム外の範囲を明確に定義する。
・機能要件と非機能要件を定義する。
■PM試験的には
試験的には、要件定義とは何かという点自体を問題にするのは根本的すぎて難しいと思われます。
要件定義を実施する中でワンポイントとして、コンピュータのことを意識せずにシステム化範囲とシステム外の範囲を明確にするという点を盛り込むぐらいでしょうか。
要件定義をベンダ任せにするユーザ
ユーザがシステムの要件定義を任せてくれるため、開発がスムーズに進んでいる。
■本書より
・開発経験の少ないユーザが要件定義に必要な作業を全て把握しているわけはない。
・ユーザに作業を促す必要がある。
■PM試験的には
問題の起こし方としては要件定義の途中まで、作業をユーザからぶん投げられていて、作成した成果物などで業務上の不具合が発生した。
対策や予防策として発生した問題に対する対応をユーザに促すというのはありではないでしょうか。
決まらなかった要件はどうするのか？
システム開発の要件のすべてが、要件定義工程の完了時点までに決まることは稀有です。
決まらなった要件は未決事項として、解決担当者や期限等を定めて継続的に管理することが大切です。
要件定義工程において、システム化の要望があふれた場合、要件が決まりきらずに次の工程へ進めない状況。
■本書より
・他の部分への影響の大きさなどから切り分けを行う
・本当にやらなければいけないことを色分けし、確実に決め切るべきことを決めて要件定義工程を完了とする。
■PM試験的には
要件定義工程にて要件が予想以上に溢れるという状況は試験においてもありがちで対策も様々。
実際にその対策で要件が収束、まとめ切れるかは置いていおいて割り切った方がよい。
要件の優先順位を決めるための方針は自身の書きやすい方針は持っておいた方がよいと思われる。
未決事項については場合によって、対策の中か残った問題として処理する。「方針」程度でよければ適当な理由を添えて解決担当者や期限等を設定するでも十分な気もする。
修正の影響範囲がわからなくなってしまった
修正が発生した際に、その影響がどこまで出るか把握できず、トラブルを招くことになります。
■本書より
・要件、ドキュメント、プログラミングなどの相互の関係を表すトレーサビリティマトリクスを作成する。
■PM試験的には
試験的には、開発から保守工程までに続いた話になることは少ないため、主題となることはあまりないと思われる。
要件変更などへの対応には活用を検討してもよい。
プロジェクト計画と管理
プロジェクトのリスクはどのように管理すべきか？
プロジェクト管理の中でも、その品質・コスト・納期を阻害する要因を事前に洗い出して管理するリスク管理は、もっとも効果的かつ重要な管理です。
■本書より
・対応策を発動する基準を設ける（トリガ）
■PM試験的には
論文の主題となることも多いため、受験者的にはリスク管理は意識しているだろうし、リスク自体及びその対策はプロジェクト固有になる。
リスクに対しては予防策と（発生時の）対応策を策定することが一般的で、その対応策を発動する際のトリガを定量的に示すことができた方がよいのではないかということ。
遅延何日、コスト幾万、品質指標値範囲など
ユーザ側のリスクをベンダ側はどのように管理するのか？
ユーザが自身の内在するリスクに気づかないことがよくあります。ベンダには専門家として、ユーザにリスクを気づかせる努力が求められます。
■本書より
・管理は専門家（ベンダ）の責任だが、リスクの抽出や解決の責任はユーザの分担
・ベンダはユーザのリスクの抽出をガイドする
■PM試験的には
ユーザ側のリスクを主題とした問題はみたことはない。
ステークホルダ管理の一環として、工夫としてユーザ側への助言を一言添えるぐらいだろうか。
ユーザの参加意識をどう高めるか？
ユーザとベンダの共同作業と言われるシステム開発では、ユーザの責任感と参加意識を醸成することが成功の鍵となります。
■本書より
・プロジェクト計画時に会議の設定を行う
・その際に、参加者やアジェンダ、成果物を仮でもよいので設定しておく。
■PM試験的には
ステークホルダマネジメントの分野で問題設定次第では似たような状況は作れる。
ユーザと自分たちの役割分担を設定する場合には、部門はもちろん必要に応じてバイネームで記述してしまってよいだろう。
主要なメンバーが病気でダウンしてしまったら
メンバーの病気交代のようなベンダサイドの事情による進捗遅れでも、ユーザを巻き込んで対策を講じることが必要です。
■本書より
・実施可能な計画を立てなおす
・ベテランエンジニアには作業よりもレビューや助言に終始させて全体での作業効率を上げる
■PM試験的には
まずはPM試験というより現実的には、かなり厳しい状況という印象があります。現場に優秀な人がいた場合、属人化しがちでその人がいきなり欠けた場合の影響は計り知れないという印象があるからです。
さてPM試験では、メンバが病気で欠けるというのはリアルに体験したことがないととってつけた問題のような気がしてなかなか出しにくい状況なような気がします。
似たような状況を設定した場合には、対策としてのユーザへの協力依頼もメインに据えると話が回収しきるのが大変になりそうなので、まずは自身のチーム内での対応を優先し、どこかからメンバを補充するのが妥当になりそうです。
メンバを補充した際には試験的には教育期間の存在は重視しコストかスケジュール面での見直しをする必要性はでてくるでしょう。
設計
成果物を客観的にレビューできる人とは？
システムの設計書を作成するときには、作成者が常識だと考えて記述しない事柄を、読み手が勝手に解釈してトラブルを招くことがあります。
■本書より
・客観的な視点でレビューできる仕組みを構築する
■PM試験的には
実際に起きてしまった問題として設定するのは個人的にありな気がします。
対策として外部有識者によるレビュープロセスを入れる。
ただしある程度似たような状況を経験していないと話を盛るのが難しそう。
また、そのままの状況設定だと次の工程に進んでしまっているため、前工程の全成果物の再レビューを実施するのが自然となるので問題的に大きくなりすぎる可能性があるためその点でも工夫が必要かもしれない。
チェックリストはどう「運用」すべきか？
システムの設計書は、機械や建築の図面とは異なり「言葉」で書かれている場合が多いため、曖昧な表現やヌケ・モレが多く、導入後の保守時の作業に誤りを招くことがあります。
■本書より
・曖昧さやヌケモレを排除するためにチェックリストを導入運用する。
・設計者同士やプログラマも交えてチェックリストを改善し続ける。
■PM試験的には
チェックリストの導入は試験的には未経験者でも書きやすく汎用性も高い。
しかし、基本的な対策でもよいとされる論文試験でもさすがに導入しただけでは対策としては弱いと思われる。
作成したはいいものの使用されなくなるというのは簡単に想像がつくため、導入と同時に確実に使用され続ける仕組みを策定することは必須だろう。
また、作成したチェックリストを別プロジェクトで再利用するということも考えられる。
ーーーーーーーーーーーーーーーーーーーーーーーーー
その他、本書ではプログラミング、テスト、契約と仕事の完成の項がある。
全体的に仕組みや考え方に関する施策なので、PM試験から内容が逸れるわけではないが少し試験的な汎用性が落ちるのと内容も長くなるのもあるのでカット！
詳しくは本書で見てください。
今回書いた内容程度だとやや具体性が低いので、自身の設定プロジェクトに向けてもう少し内容を盛り込む必要があると思われる。
それにしてもPM試験の対策があまり進んでいる気がしない。
