☆プロマネ再生工場 アクションガイド
プロジェクトマネジメントの全ての領域において何をどのようにすべきかというガイドラインを連載にて順次明らかにしていきたいと思います。
現在は下記のマネジメント領域についてのアクションガイドの連載を予定しています。
１．スコープマネジメント アクションガイド
２・人的問題マネジメント アクションガイド
３．リスクマネジメント アクションガイド
プロジェクトを指揮する立場にあるプロマネないしはリーダーにおいて行き詰まりを感じている方々にはきっとお役に立てるだろうと思います。連載開始：2020.2.14
３．リスクマネジメント アクションガイド
：プロジェクトのリスクを解消するためのガイドラインです。
ｒ４ 課題：仕事に余裕を生み出す（続き）
▶プロジェクトに余裕を生み出す方法
時間や心の余裕のない場合は、他人に対しての誠意のある対応が難しいだけではなく自分の仕事においてもミスを出しやすくなります。自分の実力以上の仕事量だと感じた場合は速やかに上長と相談する必要があります。また年中仕事に追われて全く余裕のない状態が続いているのなら、その原因について組織的に対策を講じる必要があります。仕事を他に丸投げしなければならないほど余裕のない状態に自分やチームをおくべきではないでしょう。丸投げはＱＣＤすべてをだめにするだけではなく信頼関係を失う原因にもなります。
どのような仕事においても、作業内容や量にもそれなりのゆとりがなければ合理的な仕事の遂行はできません。メンバーの立場では、ゆとりがなければ他の人に代わってもらうことや、作業を減らしてもらうなど、上長への相談も必要となります。一方、リーダーにおいては、メンバー各人の作業状況を把握し、全体的なバランスを図り、負荷が集中しないように気を配る必要があります。
ゆとりのある開発を実現するためには、従来の出たとこ勝負的なコントロールの効かない開発スタイルから新たな開発スタイルに脱皮する必要があります。
新たな開発スタイルの獲得に必要な三つのポイントは次の通りです。
仕事に余裕を生み出す開発スタイル
◎ 事前準備の実行
◎ 改善活動の実行（弱点の克服と生産性の向上）
◎ 振り返りの実行
ｒ４ 課題：仕事に余裕を生み出す
余裕のあるプロジェクトはめったにないでしょうが、それにしても必要な仕事が満足に実行できないような状況は日常茶飯事のことだと思いますが、あなたは今まで次の選択肢のどれを選択してきたのでしょうか。
①いつものことであり、いまさら手の打ちようもなく、出来る範囲で体力勝負で頑張る。
②ゆとりのない開発ばかりが繰り返されることの本当の原因を明確にして対策を講じる。
①の選択肢でよく行われる対策は、不足している時間を人員追加や残業や休出によってカバーするということですが、その結果は１００時間以上もの残業による極度の疲労の蓄積となり、それに伴って起こる失敗ややり直しは更なる時間不足と品質の悪化を招いています。 本当のことを言えば、すでにまったく余裕を失ってしまったプロジェクトに対する救援策は限定的にならざるを得ず、余程のことがない限りほとんど回復の見込みがないことは皆さんも経験済みでしょう。
一方、②の選択肢で実行されることは次のようになります。
余裕のない開発の改善策は、余裕がなくならないように開発の最初の時点において妥当な開発期間と開発費の獲得を行い、要求仕様の早期凍結を実現することにありますが、これらのことを実現するためには、基本的な開発スタイルの改善が必要となります。
ｒ３ 課題：先行着手問題への対応（続き）
▶先行着手の予防措置について（続き）
想定仕様で先行着手してしまった開発につける妙薬はありません。多くのプロジェクト開発の経験から言えることは、仕様未凍結状態で開発に先行着手した場合の変更・修正・影響度の管理は非常に手間がかかり、多くの無駄やミスを招く原因となっているということです。先行着手という言葉はもっともらしく聞こえる言葉ですが、科学的合理性も妥当性もないやり方であり、仕事が成功する道理はありません。
この場合のリスクは仕様凍結前に先行着手を行わざるを得ない状況自体にあります。このリスクを排除する方法は、仕様凍結を決められた期日までになんとしてでもやりとげることです。どうせ今回もずるずると仕様が決まらないから、今回も想定仕様で先に着手しておこうと言うような、悪い習慣や惰性はいますぐ断ち切る必要があるでしょう。
◆【アクションガイド：仕様凍結と開発納期を守る方法】
□要求仕様を顧客価値の重要度順に整理すること。
＊これは仕様の詳細内容が未定でも可能。
□仕様を全部一度に決めようとしないで、顧客価値の重要度順に決定していくこと。
□仕様検討に時間がかかりそうな場合は、日時を決めた上で顧客と直接顔を付き合せて、こちらからも 対案を出し検討会や合宿で一気に仕様決定を行うこと。
＊従来のように相手が決めてくれるのを待っている姿勢では何も変わらない。
□仕様が決定したものから順（顧客価値の重要度順）に開発着手を行うこと。
以上のことを顧客間およびチーム内で共有・実行する必要があります。
ｒ３ 課題：先行着手問題への対応（続き）
▶先行着手の予防措置について
短納期によって焦った挙句、基幹仕様が未確定にもかかわらず基本設計に着手したり、基本設計が未確定にもかかわらず詳細設計やプログラム作成に着手したりするような問題があとをたちません。このような想定仕様に基づく開発とは、本来あるべきプロセスを無視した非合理かつ無謀な行動です。何を開発するのか決まっていないものを想定することなど不可能に近いことで、何を開発するのかを決めるのは顧客であって開発側ではありません。 この問題の根本的な解決は早期の仕様凍結にかかっています。
◆【アクションガイド：先行着手の予防措置】
□顧客側から仕様凍結期限の合意を取り付けておくこと。
□顧客側との集中検討会・合宿等にて、短期集中的に仕様決定を行うこと（ベースラインの確定）。
□顧客価値の優先度順に仕様凍結および開発着手を行うこと。
□受注側においても提案型仕様凍結を行うこと。
□開発仕様の目的・背景・範囲・内容を文書にて明確化すること。
□基幹仕様未凍結状態ないしは疑問点・不明点を残したままで、先行開発着手は行わないこと。
□仕様の変更管理を実行すること。
□プロセス管理表を厳格に運用し、プロセス飛ばしや手抜きなどの不完全なプロセスを無くすこと。
上記の実行は下請けベンダー内だけで実現することは非常に難しいでしょう。特に元請ベンダー側組織においてこれらの施策が通常業務のプロセスとして実行されていない場合は、この施策の実現には長い期間が必要となるかも知れません。 しかしながら、そのような組織を相手にしていると言っても、この状況に黙って忍従しているわけにはいかないでしょう。目の前で、自分が参加しているプロジェクトのＱＣＤが棄損されるのを見ているだけでは、自分にも自社にも損害が及ぶことになります。
自社が近い将来、開発の元請け会社になることを想定し、現在の元請ベンダーに不足している部分については、あきらめることなく相手を支援しつつ可能なところから行動を促す必要があります。
ｒ３ 課題：先行着手問題への対応
▶先行着手がもたらす問題点
納期を守るために仕様凍結前に先行開発着手を行ったり、基本設計が未確定なまま次の工程に進んでしまうと、次のような問題が発生します。
① 仕様変更が発生しやり直しが発生する。
② 仕様変更が他の仕様にも影響しやり直しが拡大する。
③ 仕様の不整合や理解不足によって不具合を発生してしまう。
納期が遅れそうになった場合にとられる対策としては、一般的に次の二つが考えられます。
① 開発期間を確保するために、とりあえず想定仕様で開発を進めて時間を稼ぐ。
② 開発期間のショートを避けるために、要求仕様の凍結に全力を注ぐ。
焦っている場合、人は分かりやすくてすぐに実行できる方を選択しがちです。そういうわけで多くの開発チームは、①を選択してしまいます。②を実行するためには、要求仕様をまとめあげるために多くの困難な作業が必要となります。顧客が納得できるような仕様案の提示も必要となり、顧客・要件定義担当者・開発チームなどの間の煩わしい作業が待ち受けています。
私たちのいわゆる応用ソフト開発の大前提は、決まった仕様に基づいて開発を実行することであり、開発側が想定した仕様に基づいて開発を実行することではないでしょう。
想定に基づいた開発は、冒頭の現場の声にあるような問題を必ず引き起こし、稼いだと思ったはずの時間も稼げず、逆に多くの開発時間を失う結果を招いてしまいます。
ｒ２ 課題：早期仕様凍結（続き）
◎設計着手前の要求仕様凍結は、顧客およびベンダーの共同義務。
◎顧客は運用知識を、ベンダーは仕様知識を、開発チームは技術知識を持ち寄って適切な要求仕様の決定を早期に達成すること。
◆【アクションガイド：早期仕様凍結】
□仕様凍結の期限を切り、顧客・元請・下請間で合意をしておくこと。
□顧客・元請・下請間の直接コミュニケーションによる要求仕様の期限内凍結を行うこと。
□早期仕様凍結のために顧客および関連各社の参加・協力の要請を行うこと。
□仕様の決定にあたっては、一方的な丸投げを行うことなく、関係各社が協力して臨むこと。
□ベンダーにおいては、複数社間・複数工程間の統合的な管理および情報共有を行うこと。
□顧客価値・顧客要求度の高い仕様からの仕様凍結および開発を行うこと。
□要求者側と仕様集中検討会や合宿を行い設計着手時期前までに仕様凍結を完了させること。
□あいまいな点・不明確な点・矛盾点などについて直接コミュニケーションや電話によるヒアリング、Ｑ＆Ａシート等による確認を設計開始前に終了させること。
□開発の初期工程においては要求元担当者との密な（週２～３回）コミュニケーションを重ね仕様変更・追加の有無を確認することで後工程での頻繁な仕様変更や仕様凍結の遅延を防ぐこと。
□仕様の条件やノウハウである要求仕様の目的・背景・範囲・内容を文書にて明確化すること。
□経験不足な部分は有識者への質問や相談を行うこと。
□待ちの姿勢ではなく、開発チームからも仕様提案を行うこと。
□下請けベンダー側においても、仕様提案力をつけるために元請ベンダー・顧客間の仕様打ち合わせ等へ直接参加すること。
□要求仕様には必ず抜けや誤りがあるという前提を持ち、仕様未凍結状態ないしは疑問点・不明点を残したままで先行開発着手は行わないこと。
□契約外の要求に対しては追加期間・追加コストの要求を行うこと。
ｒ２ 課題：早期仕様凍結（続き）
良質な要求仕様書を作成するために必要なアクションは次のとおりです。
◆ 【アクションガイド：仕様力・技術力の強化】
（元請けベンダー側に必要なアクション）
□ 仕様ノウハウを学習・蓄積すること。
□ 一定の割合で設計・製造を実行し，開発技術力を保持しておくこと。
□ 外注まで含めた統合的プロジェクトマネジメントを実行すること。
（下請けベンダー側に必要なアクション）
□ 仕様ノウハウを学習・蓄積すること。
□ 設計能力を進化させること。
□ 製造能力を進化させること。
□ 評価能力を進化させること。
□ プロジェクトマネジメントを実行すること。
要求仕様の精度はプロジェクト成功の必須要件の一つであり，それは要求する側および請ける側双方の同時連携が必要となります。これは「相互義務の履行」という重要な組織行動規範の一つです。
日本の顧客およびソフトウェア業界には強い納期意識はありますが、その納期達成に絶対的に必要な要求仕様の凍結時期という納期意識は全くと言ってよいほど存在していません。残念なことに、ソフトウェアだからいつでも変更可能だろうという思いが顧客側のみならずベンダー側にも存在しています。プログラムは複雑な論理の組合せで構成されており、さらにその構造は動的に変化していく精密機械にも例えることができます。開発途中や終盤における仕様変更は、その精密に組み上げられたロジックを壊しかねない大きな危険性をはらんでいます。リリース直前の仕様変更などとんでもないことだといえます。
ｒ２ 課題：早期仕様凍結
仕様凍結を遅らせる原因としては次のようなものが考えられます。
①抽象的な要求内容は決まっているが具体的な内容に落とし込まれていない。
②顧客内の複数部門からの要求がばらばらに出されてくるために仕様のまとめに時間がかかっている。
③要求仕様作成者におけるシステムの実運用知識および仕様知識が乏しい。
また仕様凍結を遅らせる不適切な認識としては以下のようなものがあります。
ａ．ソフトウェアはいつでも変更可能であるという認識の甘さ。
ｂ．顧客はベンダーに、ベンダーは下請け開発会社に対する依存性が強くなっており、仕様決定についても上位から下位に依存する傾向が強い。
ｃ．要求仕様は設計着手の前までに凍結しなければ、まともな開発は実行できないという認識の欠如。
▶仕様の全体像および主要仕様の把握は設計工程の前に済ませておくこと
優れた開発者における開発工程ごとの時間の使い方は、初期工程に重く、後になるに従って軽くなっています。さらに開発すべき対象をどれだけ正確に把握しているかが勝負の分かれ目となります。プロジェクトの成否は見積り時および要件定義工程においてほぼ決定していると言えます。プロジェクトを成功させる要因の重さは、”何を作るのか”が分かることで六割、”どのように作るのか”が分かることで三割、その他要因で一割程度だと思われます。
要求仕様を早期に決定できない主な理由として，以下のものがあります。
□ 仕様知識の低下
□ 開発技術力の低下
□ プロジェクト・マネジメント力の低下
□ 外注依存の高さ
▶プロジェクトリスクの回避（続き）
◆ 【アクションガイド：開発プロセスの成功パターン】
【見積り回答前】 ◀ Check Timing
□要求仕様の骨子が決定され明確に書面にて提示されていること。
□見積り回答書の内容は、要求仕様骨子の実現に見合った開発期間および開発費になっていること。
□見積り回答書には、明確な要求仕様骨子に対してのみ見積られ、不明なものについては見積りに含まれていないことを明記すること。
□見積り回答書に、開発に必要な実行条件がある場合、その条件を明記すること。
【設計着手前】 ◀ Check Timing
□すべての要求仕様が決定され、明確に書面にて提示されていること。
□全ての要求仕様に関して、全ての不明点および疑問点が払拭されていること。
【製造着手前】 ◀ Check Timing
□基本設計が完了され、基本設計書として明確に書面にて提示されていること。
□詳細設計が完了され、詳細設計書として明確に書面にて提示されていること。
□全ての設計書に関して、全ての不明点および疑問点が払拭されていること。
【単体テスト前】 ◀ Check Timing
□単体テスト試験書が作成済であること。
□テスト対象機能のコーディングが全て完了していること。
【結合テスト前】 ◀ Check Timing
□結合テスト試験書が作成済であること。
□テスト対象機能の単体テストが全て完了していること。
【総合テスト前】 ◀ Check Timing
□総合テスト試験書ないしは運用（シナリオ）テスト試験書が作成済であること。
□総合テスト対象機能の単体・結合テストが全て完了していること。
【成果物リーリース前】 ◀ Check Timing
□全ての機能が要求仕様通りにシステムとして実運用を満たしていることが確認されていること。
□発見済で未修正の不具合が残存していないこと。
ｒ１ 課題：最初から失敗しないために（続き）
▶プロジェクトリスクの回避
◎地道な日々の問題・リスク情報の共有活動を
プロジェクトにおけるリスクの回避やソフトウェアの不具合問題などを一度に解消できる方法などは存在しません。開発業務の進行と同期をとったリスク対応や不具合傾向の把握を可能にするには、それなりの準備が必要となります。 リスクについては、リスクが問題化した時点および対策を実行した時点においてその要因などの情報を記録しておき、不具合についても、発見および修正時に不具合票にその真因や発生工程などの情報を同時に記録しておく必要があります。これらのことを全員が都度こまめに実行していれば、これらの累積されたデータは常時グラフや表として分析することが可能となります。
◆【アクションガイド：見積り・要件定義時のプロジェクトリスク回避】
□ 見積り交渉における妥当な開発費および期間を獲得すること。
□ 要求仕様の早期凍結を行うこと。
□ 開発業務品質向上のための改善活動を実行すること。
□ リーダーによる開発仕様の全体像の把握を行うこと。
□ 開発メンバーによる開発仕様の十分な理解を行うこと。
□ 開発メンバーに対する適切な仕事の配分を行うこと。
◆【アクションガイド：プロジェクトを成功させるための基本条件】
（統合管理）
□ベンダーを中心とした統合的プロジェクト管理を行うこと。
□適切なプロジェクト・マネジメント能力を発揮すること。
（コミュニケーション）
□プロジェクト傘下の全組織および全会社間の密接なコミュニケーションを行うこと。
□日次情報共有会議によるチーム内での情報共有を行うこと。
（要求仕様）
□主要な仕様を適切な時期までに凍結させること。
（リソースの確保）
□見積り交渉において、開発内容に見合った工期・予算を確保すること。
□顧客システムおよびその運用業務に精通していること。
□開発規模および難易度に応じた開発体制を構築すること。
（開発）
□顧客価値の重要度順の仕様凍結ならびに開発を行うこと。
□ドキュメントに基づいた開発を行うこと。
□データに基づく開発を行うこと。
□開発効率化・失敗の再発防止のために普段の改善活動を行うこと。
ｒ１ 課題：最初から失敗しないために（続き）
◆【アクションガイド：情報共有不足の原因と対策】
原因①：プロジェクトのリーダーシップ不在
プロジェクトのまとめ役が居ないか、まとめ役がプロジェクトをまとめきれていない。
対策：プロジェクトまとめ役の作業量を減らし、各メンバーから共有される情報をまとめ、適切なプロジェクト体制を構築する。
原因②：プロジェクトの統合マネジメントが行われていない
複数の会社でそれぞれの担当部分を開発し、最終的に１つにまとめるようなプロジェクトの場合に起きやすい。
対策：プロジェクトキックオフ会議の開催
□開発者全員に開発仕様の目的や背景および全体像の説明を行う。
□常に決まったタイミングで、各担当の代表なりを集めた上での仕様説明ないし、仕様変更があった場合の報告を行う。
原因③：仕様情報の共有不足
現実は全体の仕様がある程度固まった時点で一度説明があるだけで、その後の仕様変更について横展開が十分にされていない。
対策：
□日次情報共有会議を実行することでリーダーが仕様変更の横展開を図りつつ、メンバーの作業状況や仕様理解度を把握すること。日次情報共有会議は単なる進捗報告会議ではなく、各担当が抱えている問題や疑問点・不明点の質疑応答も行うことで、仕様の目的や背景、全体像、要求仕様の疑問点・不明点を日次ベースで解消していく必要があります。
原因④：時間不足
・リーダー／メンバーの時間不足（市場障害対応、複数開発の兼務など）
・開発途中で参加するメンバーも多く、一度に全員に説明することができない。
・要求仕様そのものが決まっていない。
対策：
□要件定義遅れの解消
□無理な納期短縮の回避
□見積り失敗の回避
□繰り返される類似不具合の解消
□情報共有不足の改善
□雑な仕様書・設計書の改善。
ｒ１ 課題：最初から失敗しないために
▶失敗プロジェクトの特徴
最初から失敗しているプロジェクトの特徴は次の通りです。
①開発の目的や全体像の説明が行われない
開発開始時に関係者全員に開発の目的や全体像の説明が行われていない。
②要求仕様の読み合わせが行われない
開発者全員での要求仕様の読み合わせが行われていない。
開発を登山に例えれば、 目的や目標を達成するために必要な大きな地図に相当するのが、開発の目的・目標および全体像の把握であり、小さな地図に相当するのが、要求仕様の読み合わせだと言えます。
この二つの地図の用意を怠った場合、プロジェクトは不具合多発・納期遅延・コストオーバー・人員の疲弊などの遭難状態に陥ってしまう確率が非常に高くなってしまいます。
自分たちが何処へ向かうべきか、そのためには何をすべきか分からないまま、とりあえず歩きながら考えようというような非科学的・情緒的な思考ではプロジェクトを成功させることは難しいでしょう。
◎プロジェクトの開始時点で必要なこと
①プロジェクトの目的・目標および全体像の明確化と情報共有
②開発すべき仕様の明確化と情報共有
２．人的問題マネジメント アクションガイド
：開発者の人間的思考・行動にかかわる問題を解消するためのガイドラインです。
（ノウハウの継承の続き）
◆ 【アクションガイド：ノウハウ情報の共有】
（情報共有の手段）
□日次情報共有会議等の実施
□知識データベースの構築
□マニュアルおよびガイドラインの作成
□専門用語集の作成
（共有すべきノウハウ）
個人保有およびチーム保有の下記ノウハウ
□見積り知識
□プロジェクト管理知識：プロセス管理、開発手順、ＱＣＤ管理、開発手順、レビュー方法
□リスク情報：人的リスク、技術的リスク
□顧客情報：顧客情報、顧客システム運用情報
□仕様知識：顧客システム仕様、顧客業務仕様、仕様調査方法
□技術知識：設計知識、プログラミング知識・言語知識、評価テスト知識、トラブル対応知識
▶見積り・スケジュール管理ノウハウの継承
◎まずはメモベースから始めること
見積書作成やスケジュール管理の手順やポイントについて、まずはメモベースでも良いので普段自分が行っていることや注意点、留意点についてまとめておくことです。またこれらのメモベースができた後、他のリーダーにも渡して意見を交換し加筆・修正すればある程度の「見積書作成ガイドライン」や「スケジュール管理ガイドライン」などのドキュメントは完成できるでしょう。これらは必ずメンバー全員の役に立ち、組織全体のスキルアップに大いに貢献します。
▶個人保有ノウハウの継承
◎ノウハウの継承はあなたの義務です
同じチームに所属する者たちにおいて、先に進んでいる者が後進の者へノウハウや情報を伝え継承することは、必ず実行しなければならない”義務”です。自分のことにかまけて、やってもやらなくても良いようなものではないと言うことに気づく必要があります。先に自分が譲りを行わなければ、他の誰も譲りを行わないでしょう。たとえ他人からの譲りがなくとも、自分の使命感によって譲りを続けていけば、他のみんなも同じ行動をとることでしょう。それがリーダーの使命であり役割だと言えます。
技術情報やノウハウの継承においては、自分や他人の一定の時間を必要としますが、広くノウハウの継承および情報の共有が行われることによるチーム全体の生産性および品質の向上はその何倍もの効果を及ぼします。役割が固定化してしまったチーム内では特定の人に仕事が集中してしまい、個人間での煩雑なやりとりが発生し、極めて生産性の低い組織となってしまいます。ノウハウの継承に一時的な時間がかかったとしても多くの人に継承することでチーム内の技術レベルの向上および能力の均質化を図ることが可能となり間違いなく自分自身およびチームの力を向上させます。「情けは人のためならず」の本意通りでしょう。
◎仕様情報の集結と常時更新および全員への公開を
ドキュメント軽視が招いた結果が、重要な開発情報の個人分散化です。せっかく作成した仕様情報共有のための質問回答表が未完のまま役目を果たしていません。会話の中で決めた仕様についても直ちに仕様書や設計書へ記録することを全員の習慣とする必要があります。多忙なためにできないのではなく、情報共有をリアルタイムに実行しないから多忙になっているのです。
サーバーでの一元管理も重要ですが、毎日メンバーがそろう時間に３０分程度の日次情報共有会議を実施することをおすすめします。特に仕様やスケジュールや問題・課題については毎日顔を合わせた話し合いが効果抜群でしょう。日次情報共有会議は、一人業務の場合はＰＭあるいは上司と行い、適当な相手がいない場合は自分一人だけでも実行すべきでしょう。とにかく、昨日行ったこと、今抱えている問題、明日実行予定のことについて自問自答することだけでも非常に意味のある行動だといえます。
◎ノウハウ継承の効果確認およびドキュメントによる継承を
専門的な知識や技術、見積り手法、トラブル対応のいずれも非常に難しい内容で簡単には継承できないものですが、どの程度メンバーに継承されているのか半期ごとに振り返ってみる必要があります。振り返りはＱＣＤの各指標の改善度合いによって計測を行う必要があります。またこれらのノウハウはＯＪＴ的な実地訓練では浸透に非常に時間がかかってしまいますので、それぞれのノウハウ集をガイドライン的にドキュメントにまとめておき、それに基づく説明や自学自習を行うことによる効率化を実現する必要があります。これらのドキュメントは、例えば、「○○技術ノウハウ集」、「見積りガイドライン」、「不具合対応の手引き」などがあるでしょう。
またこれらのノウハウ集の作成自体も一度にやろうとすると大変な作業となりますので、都度こまめに記録する作業を継続する方法や改善活動チームによる取り組みなどで完成し、メンテナンスを行うようにすれば良いでしょう。
（ノウハウ継承の続き）
▶プロジェクト管理ノウハウの継承
◎ドキュメントによる開発および知識の継承を
最も効率的かつ正確な仕事のやり方はドキュメントベースの仕事をするということです。多数のメンバーの頭の中に分散されている知識を根拠に仕事をする方法と、明確な定義が過不足なく記述されているドキュメントを根拠に仕事をするのとでは、どちらが正確で早くそして失敗が少ないかは明白でしょう。不確かで感情に流されやすい人間の記憶に頼るような仕事のやり方から早く脱却する必要があります。口頭やメールでの情報伝達はリアルタイム性を確保する場合には必要ですが、これらの情報はすぐに雲散霧消してしまい長時間・長期間の業務活動の根拠には有効ではありません。根拠に乏しい仕事のやり方では、人によって出来栄えの幅が大きくぶれてしまい、また理解不足や誤解による失敗が多く発生するために後戻り対応で多くの時間とコストを失ってしまいます。
忙しいから文書化する時間がないのではなく、文書化してから仕事に着手しないから時間が足りなくなるのです。二、三人の小規模開発では文書なしの口頭ベースでのやり方で何とかなったのでしょうが、それ以上の規模の開発では全く不可能なことです。なおドキュメントベースの開発は一人ではできませんのでチーム単位および全社単位での活動が行われる必要があります。
（ノウハウ継承の続き）
▶コミュニケーションノウハウの継承
◎有用情報はすぐに情報共有すること
日々の開発作業上、自分が気づいたことで仲間のメンバーにも必須の情報や知識はたくさんあると思われます。そのような情報については、文書化などと大上段に構えずに、自分の手帳に書きとめておき、日々実行されている短時間日次進捗会などで他のメンバーにもすぐに伝えるようにする必要があります。このようなことをプロジェクトの全員が小まめに実行すればプロジェクトの業務品質や効率性の向上に必ず貢献することになります。このような有用な開発情報や知識を、その都度、プロジェクトの「技術情報WIKIPEDIA」などにみなさん全員でこまめに登録し情報共有する必要があります。
▶チームプレーのノウハウの継承
◎ノウハウの継承は、人および組織に永続的な発展をもたらすということ
自分でノウハウを囲い込むことは、結局自分の首を絞める結果になってしまいます。あるノウハウを他人に伝えると同時に自分は更に次のステージのノウハウにチャレンジしていれば、何も心配は要らないでしょう。新しいことにチャレンジできなくなった人は自分のノウハウを他人に教えたがらないものです。
進歩が止まってしまった人や組織は必ず衰退していく運命にあります。一方、先進の者から、後進の者へとノウハウ継承の流れが続いている人や組織は継続的な発展を手に入れることができます。このように人間にとって価値あるものごとを、持てるものから持たざるものへと譲り、継承していく流れの連鎖の中から永続的な発展が生まれてくるものです。
（ノウハウ継承の続き）
▶協力会社への評価テストノウハウの継承
◎協力会社のキーマンを継続雇用メンバーとすること
評価体制が協力会社メインとなるのはコストパフォーマンス上やむをえません。このような体制においてチームの能力を低下させない方法は、チーム内を有識者層と一般層に分けて構成することです。評価のノウハウを保有する協力会社の人材は評価チームの核として継続的に雇用しておき、体力勝負の評価作業に関しては一般層の評価者に割り当て、仕事量の増減に応じて雇用の増減を図るのがよいと思います。協力会社の要員に対する教育はこの核になる有識者層に重点的に実施し、一般層に対する教育は、これらの有識者層に任せた方が良いでしょう。
教育において一番の問題は教育するための資料・ドキュメント不足だと言えます。資料が不十分な場合は、十分な説明も不可能となり、説明者の負担も非常に重いものになってしまい、いつしか教育も行なわれなくなります。必要な資料としては下記のものを常に最新な状態に更新しておく必要があります。
◆【アクションガイド：評価テストに必要なドキュメントの作成】
□テストガイドラインの作成：単体テスト、内部結合テスト、外部結合テスト、総合テスト、等。各ガイドラインの内容は、テスト対象物の規定、各テストへのINPUT/OUTPUT資料および規定類（評価データ、テスト範囲、テスト方法・手段・ツール等、採取すべき品質管理データ、必要な評価環境、評価結果の確認資料、評価報告書、など）
□評価テスト設計書・評価チェックリストの作成
□テスト成績書（単体テスト・結合テスト・総合テスト）の作成
□要求仕様書・基本設計書・詳細設計書の作成
□評価用リリースノート（評価対象物の定義および注意事項）の開発チームからの受領
（ノウハウ継承の続き）
◆【アクションガイド：ノウハウの継承に必要なドキュメントの作成】
下記に示した開発ドキュメントの精度はプロジェクトの成功およびノウハウの継承・人材育成の達成度に直接的に影響を及ぼします。
【見積り、要求仕様】
□ 要求仕様書品質の評価ガイドライン
□ 要求仕様変更管理マニュアル
□ 見積回答書作成マニュアル
【開発管理】
□ プロジェクト管理マニュアル
□ 品質管理ガイドライン
□ コスト／プロフィット管理ガイドライン
□ プロジェクト進捗管理ガイドライン
□ 生産性管理ガイドライン
□ 開発／評価プロセス手順書
【技術情報】
□ 統一専門用語集
□ 顧客システム情報集
□ 顧客システム運用情報集
□ 技術情報／ノウハウ集
□ アプリケーション仕様集
□ 仕様変更影響度表作成マニュアル
□ 基本設計ガイドライン
□ 詳細設計ガイドライン
□ プログラミングガイドライン
□ 評価設計ガイドライン
□ テスト仕様書作成マニュアル
□ 開発／評価ツール操作マニュアル
□ 機器操作手順書
□ 構成管理マニュアル
□ 障害対応マニュアル
□ 重要障害対応記録集
ｈ１４ 課題：ノウハウの継承
ノウハウ継承の最大の阻害要因はドキュメントによる継承が行われていないということにあります。このことはコミュニケーションにおける正確な情報の伝達における阻害要因でもあり、組織内で重要な情報を伝達するためには文書などのドキュメントが絶対的に必要であるという認識が欠如していることをも意味しています。さらにこの認識欠如の原因は、ドキュメントを作成する時間がないことおよび、他者との相互理解や相互関係をめんどうなことだと感じてしまう束縛感を嫌う姿勢がもたらしているのかも知れません。
▶ドキュメトによるノウハウの継承
【設計書作成のポイント】
設計書の作成の留意点は以下の通りです。
□設計書の完成度は、要求仕様書の精度に依存するため、要求仕様の検討時に不明点や疑問点を全て解消した後で決定版の要求仕様書に基づいた設計書の作成を行うこと。
□設計書と要求仕様書の内容が一対一に対応していること、漏れ・重複がないことを確認すること。
□設計書の基本的フォーマットやベストサンプルがあれば、それを参考にすること。
【人材教育のポイント】◎ドキュメントベースの仕事の実行を
後輩教育および協力会社の教育については、基本的にドキュメントに基づいて実施することが最も効果的です。教育とはとりもなおさず開発ノウハウの継承ということに他なりませんので、複雑な内容である開発のノウハウをその場しのぎに思いつくまま口頭で説明しても相手には伝えることはできません。人の頭脳の中だけにしかない開発ノウハウを口頭だけで後輩や協力会社の人々に効率的に伝えることは不可能です。開発ノウハウは全てドキュメントに書き表さなければ他人へ説明することはできません。すなわち記録された開発ノウハウとは、過不足のない要求仕様書、基本設計書、詳細仕様書、構成管理仕様書、評価設計書、開発管理表、プロジェクト完了報告書などに他なりません。これらのドキュメントの完成度が高ければ、適時これらの資料の一部を切り出して説明資料とするなど、後輩や協力会社への効果的説明も教育も可能となります。まずは自分の担当する領域におけるドキュメントの完成度を向上させ、それに基づいて後輩や協力会社の教育を実行する必要があります。
（続き）ｈ１３課題：基本的な開発能力
アジャイル思想の骨子は以下に示す通りです。ここに示されたことを現在のウォーターフォール開発においても実現する必要があるでしょう。
◆ 【アクションガイド：基本的な開発能力】
□ チームにおける日常的で密な直接コミュニケーション力
□ ドキュメントの常備はもとよりちゃんと動作するソフトウェアの素早い開発力
□ 顧客との日々の直接コミュニケーションによる協調
□ 変更要求に対する俊敏な対応力
□ 顧客価値優先度の把握力
□ 意欲ある人材で構成されたプロジェクト構築力
□ 短期開発力
□ 一定のペースを持続できる開発力
□ 技術的な優位性の保持、良好な設計力の保持
□ 無駄・不要な仕事の削減力
□ 自律的チーム力
□ 定期的・効果的振り返りによる行動の変更・調節力
以上のことができるのでしょうか。アジャイル開発の形式的な特徴であるイテレーション開発・スプリント開発（短期繰り返し開発）をまねることがアジャイル開発ではありません。まず我々が取り組むべきことは現在のウォーターフォール開発手法の中にあっても、アジャイル的な上記の価値・原則の実力を身につけるところから出発する必要があります。
ｈ１３ 課題：基本的な開発能力
▶自分の頭で考える自律性こそが開発の基本
開発者に求められる基本的な能力の筆頭として、自律性があります。
自律性とは、自分が遭遇した問題に対して、自分自身の観察力で判断し自分の力でそれを解決していく能力のことを意味します。自律性の発揮は、自力更正とか自助・自主自立という形で現れてきます。この自律性の力は人間の思考や行動のベースとなる重要な能力です。
自律性の欠如は、開発の実務行動において下記のような問題を広範囲に起こす原因となっています。
□ 知識不足（技術、仕様、システム構造、評価テスト）
□ 仕様決定能力の低さ
□ 設計・製造能力の低さ
▶ウォーターフォールにアジャイル思想の取り込みを
現在のベンダー側および下請け会社の開発チームが抱える重要な問題点は次の様でしょう。
①システムや業務に関するノウハウ不足
要件・要求仕様を適時にまとめる能力や人材が不足している。
②プロジェクト・マネジメント能力不足
リーダーシップ不足、チーム連携不足、プロセス管理・リスク管理・無理無駄の排除活動・改善活動などの不足。
③コミュニケーション能力不足
顧客・ベンダー会社・下請け会社間における緊密なコミュニケーションが実行されていない。開発各工程の業務が複数社に渡って発注されている状況にもかかわらず統合進捗会議も統合プロセス管理も行われていない。
上記の問題はウォーターフォール、アジャイルに関係なく存在している問題です。我々はまずこれらの共通的な問題を解決する実力を身につけなければアジャイル開発にも進めないでしょう。上記①～③について自社組織の現在の実力はどれほどでしょうか。現時点で自分たちができていないことは開発方式を変えただけでは、やはりできないでしょう。アジャイルをこなせるのはＣＭＭＩで言えば多分レベル４以上の実力を持っている組織だけでしょう。
アジャイル宣言にある４つの価値と１２の原則を現在の顧客・ベンダー会社・下請け会社の混成プロジェクトでどこまでできるでしょうか。
（続き）五里霧中に霞む本質
◆ 【アクションガイド：不明な問題を解く】（参照：数学の考え方１６か条、秋山仁）
□ 分類や整理をしてみる。
□ 図や表にしてみる。
□ 簡単な模型やプロトタイプを作ってみる。
□ 基準をそろえる。
□ 数学やロジックの言葉で表してみる。
□ 小さな例で試してみる。
□ 難しい問題は分割して考えてみる。
□ 必要条件で絞り込んでみる。
□ 特定の要素に注目してみる。
□ 視点を変えてみる。
□ 逆に考えてみる。
□ 操作は１つずつ片付けてみる。
□ 知っている事実を活用してみる。
□ 規則性を探してみる。
□ 対応をつけて考えてみる。
□ 自然からヒントを得てみる。
□ 部分から全体を把握してみる。
◆ 【アクションガイド：本質を見極めるために】
□仕事や仕様の意味を知ること。
□仕事や仕様の背景を知ること。
□仕事や仕様の目的を知ること。
□仕事や仕様の事実の確認を根拠や証拠に基づいた文書・ドキュメントベースで行うこと。
□複数の視点で物事を見て分析すること。
□口頭・文書ともに必ず誤りが含まれるという問題意識を持ち、何故の疑問提起を行うこと。
□自己の役割・責任範囲を良く知ること。
□仕事の許容時間・必要時間を正しく把握すること。
□心身の限界を知ること。
あせりにあせって何の考慮もなく行動に移してもつまずくのがおちでしょう。事に対するあたっては必ず一呼吸の間が必要となります。この静寂の間こそが、本質を見抜くための「なぜ？」を発するための時間となります。
アップル・トゥ・アップル比較 （Apple to Apple）
競合製品の比較分析においてＡ社の高級機種とＢ社の中級機種を比較しても意味はありません。競合製品の比較をするためには同じ価格帯同士の機能比較をすることで自社製品の優劣を判定することができます。これは当り前のことのようですが、ベースとなる条件が異なっているものを比較分析する過ちは意外と多いものです。他人の目をあざむくために恣意的にリンゴとミカンを比較するような提案には要注意です。
（続き）本質の把握 五里霧中に霞む本質
▶五里霧中に霞む本質
不合理な努力は報いられないと言われる通り、的外れな努力はいくら積んでも決して成果を得ることはできません。ある問題に取り組むにあたっては、その対象となる物事の本当の姿を把握しない限りは、その問題を解決することはできません。本質の把握ミスに共通する問題は、「自分の目で確かめない、自分の頭で考えない」という自律性の不足にあります。
◆【アクションガイド：本質を見抜く】
□ 自分の目で観察すること。
□ 自分の頭で考え、判断すること。
□ 複数の情報にあたること。
□ 見聞を深める学習や行動を行うこと。
◆【アクションガイド：思い込みの解消】
□ 湧いた疑問に対して、何故？の問いかけをすること。
□ 根拠となる事実や定義に従い、原典を確認すること。
□ 変更の影響度を確認した上で仕様変更を行うこと。
□ 常識に照らし合わせた理解や判断をすること。
□ 仕様変更、日程変更等の重要情報は、原本配布および直接対話で伝えること。
□ 複雑な問題に対して、複数の解決策を比較検討すること。
◆【アクションガイド：誤解を避ける】
□ 口頭のみではなく文書による情報伝達をすること。
□ あいまいな日本語記述の文書を極力減らし、数値や論理記号表現を用いること。
□ 自分勝手な想定ではなく、正確なドキュメントに基づいた開発を行うこと。
□ 仕様の目的・意味・背景を知った上で開発を行うこと。
□ 全体的視野、顧客の視点で問題を考えること。
□ 他者の視点で考えてみること。
ｈ１２ 課題：本質の把握
ここで使用する「本質」の意味は、かみ砕いて言えば「本当の事」とか「本当の原因」と言えるでしょう。本当の事や本当の原因は、普通目の前に現れた現象の背後に隠れており容易には見破ることができません。ものごとの本質の見極めを妨げる要因としては次のようなことが考えられます。
①思い込み
②ものごとの背景・目的・意味の理解不足
③事象分析力の低さ
④コミュニケーション能力の低さ
私たちの具体的な思考や行動における本質を見誤る例をこれらの阻害要因ごとに見ると以下のようになります。
①思い込みのパターンと失敗の原因
・Ａは○○だと思っていたが、実際は△△だった。⇒原因：意味の追求をしなかった
・Ａ・Ｂ・Ｃが○○だったので、Ｄも○○だと思った。⇒原因：事実の確認をしなかった。
・○○の修正は他に影響がないと思った。⇒原因：根拠や証拠のない感覚的な仕事のやり方。
・一つの解決策にこだわり時間を浪費した。⇒原因：最初に複数の視点での分析を怠った。
②ものごとの背景・目的・意味の理解不足のパターンと失敗の原因
・複雑な設計を行ってしまった。⇒原因：仕様の背景を知らなかった。
・不要なテストデータを作成してしまった。⇒原因：テストの目的を理解していなかった。
③事象分析力の低さ（事実・真因の追究不足）のパターンと失敗の原因
・似たようなＡとＢがあり、Ｂを不要としてしまった。⇒原因：何故？の疑問提起を怠った。
・不具合分析の方向性が悪かった。⇒原因：複数の視点での分析不足。
・想定した仕様が実際は異なっていた。⇒原因：要求仕様の確認を怠った。
・口頭確認だけで処理したものが不具合となった。⇒原因：文書による確認を怠った。
④コミュニケーション能力の低さのパターンと失敗の原因
・口頭だけの依頼内容で解釈違いをしました。⇒原因：文書による確認を怠った。
ｈ１１ チームプレーの実行（続き）
▶前後の工程に対して連携をもって影響力を行使すること
自分が担当する工程の前後の工程に対する考慮は、開発・評価業務の全てにおいて非常に重要かつ必須なことです。自工程の前後の工程に対するさまざまな考慮は、ややもすれば分離分断されがちな各工程を有機的に結び付ける強力な手段となります。プロジェクトのメンバーが開発開始時点からそのように協力しあうことの認識を強く共有し、プロジェクトのあらゆる活動において本当の意味での連携を計画的に実行すれば、すべての工程の業務品質は格段に向上し、結果として自工程で精一杯という状況も軽減されます。
◆ 【アクションガイド：開発チームと評価チームの連携】
□ 開発チームと評価チームは開発初期の工程から連携し必要な情報を共有すること。
□ 開発チームは、妥当な時期に必要な部材や情報を評価チームに提供すること。
□ 開発チームは、評価テストに耐えうるプログラムを評価チームに提供すること。
□ 開発チームは、評価に支障を来す機能等の制限情報と対応時期情報を評価チームに提
供すること。
□ 開発チームは、単体および結合テスト成績表を評価チームに提供すること。
□ 開発チームは、変更仕様の影響度情報を評価チームに提供すること。
□ 開発チームは、評価に必要な実機環境および関連部材を評価チームに提供すること。
All for one,One for all
チームプレーの精神は「All for one,One for all」（みんなは一人のために，一人はみんなのために）の言葉でよく知られています。チームプレーを阻害する最大の要因は，“過剰”な自己防衛にあります。自己防衛は人間の生存本能の基本ですが，問題なのはそれが“過剰”に発揮される場合です。たった10分の時間も，少しのノウハウの伝承も惜しむような心根は“せこい”という言葉で表されます。“せこさ”が自分や組織を衰弱させることをあらためて認識する必要があるでしょう。自分が持っているノウハウはもともと先輩や他人からもらったものであり，自分の譲りの大きさに比例したものがいつか自分に戻ってくるのだということに早く気づく必要があります。
ｈ１１ チームプレーの実行（続き）
▶チームプレーの本質は相互義務の履行と相互扶助の発揮
チームプレーはうっとうしいだけだと思っていませんか。動物的な能力に劣っている人類が他の動物に勝利したのは集団として行動する能力に優れていたからだとも言われています。この能力は人間集団同士の競争においても，その勝敗を決する要因となっています。プロジェクトチームは集団行動の小さな単位そのものでしょう。集団を維持する重要な要素には，相互義務の履行と相互扶助の発揮の2つがあります。相互に果たすべき義務を果たし，相互の弱点を補完し合うということです。個人および組織が生き残り，更なる発展をするための原点がチームプレーにあります。
チームプレーにおける主なリスクは次の通りです。
□ 相互義務の不履行
□ 相互扶助の不在
◆【アクションガイド：チームプレーにおける相互義務の履行】
□顧客チームとベンダーチーム間の相互義務の履行および連携を行うこと。
□同一プロジェクトに参加している他社間の相互義務の履行および連携を行うこと。
□ベンダー・顧客側においては何を開発するのかを要求仕様書等にて明示すること。
□請ける側においては要求に対しての実現方法を見積り回答・設計書等で明示すること。
□要件定義チームと開発チーム間の相互義務の履行および連携を行うこと。
□開発チームと評価テストチーム間の相互義務の履行および連携を行うこと。
□上司と部下の間の相互義務の履行および連携を行うこと。
◆【アクションガイド：チームプレー 組織的問題の解決】
□ＱＣＤなどの目標値を設定し、その達成に向けて仕事を行うこと。
□過酷なスケジュール（長時間・長期間残業）を回避する行動を行うこと。
□チーム内で相互義務の履行および相互扶助を行うこと。
□毎日の声かけや日次情報共有会議を実行すること。
◆【アクションガイド：チームプレー 個人的問題の解決】
□やらされ意識で仕事を行わないこと。
□繁忙時であっても他人からの質問等には丁寧に応えること。
□他人を意識し過ぎて、過剰防衛的な孤立状態に陥らないこと。
□自分の利益に過度にこだわらず困っているメンバーの支援を行うこと。
□依頼や指示をされた仕事に対して、「無理」ですという反応ばかりしないこと。
□一見、困難な仕事に対して、できるための実行条件を提示すること。
□日々の報告・連絡・相談などを行うこと。
□実行済内容、実行予定、抱えている問題等について日報等に記録しておくこと。
□自分に可能な範囲から助け合いの行動を始めること。
□行動できないことを自分の性格のせいにしないこと。
□個人的な競争意識よりもチームプレーを優先させること。
□助け合いや連帯は損なことだと決めつけないこと。
□他人に関心を持つこと。
□支援を受けることを恥だと思わないこと。
ｈ１１ 課題：チームプレーの実行
チームプレーを阻害する原因 ▶
チームプレーを阻害する原因として以下のことが考えられます。
①やらされ意識で行っている仕事
受身の姿勢で行っている仕事はいつしかルーチンワーク的な単純作業と誤認され、面白くない仕事だと感じられ、言われたことだけを実施する仕事になってしまう。
②目標が設定されていない仕事
目標がない仕事は、すなわち先が見えない仕事であり、どこまで頑張れば良いのか分からないため気力・体力の維持ができなくなる。
③過酷なスケジュール（長時間・長期間残業）
無理なスケジュール、受身の姿勢、無計画、無目標が過酷な長時間労働を生む原因となり、開発者を疲弊させ、チームプレーの余裕を無くしてしまう。
④組織運営不良
妥当なスケジュール下であった場合でも、リーダーの率先垂範が行われない場合や適材適所に欠け特定の人に負荷が偏っていたり、日次会議など頻繁な情報共有・目的目標共有・問題共有などが実行されていない場合にはチーム内での助け合いは行われにくいでしょう。
【チームプレーを阻害する原因】
①やらされ意識で行っている仕事
②目標が設定されていない仕事
③過酷なスケジュール（長時間・長期間残業）
④組織運営不良
ｈ１０ 課題：作業指示の仕方
部下に作業指示を適切に行う大前提は、自分が作業内容を完全に理解しておくことです。次に必要なことは、作業の着手前に部下における作業内容の十分な理解を得ておくことでしょう。十分な理解を得るためには、何らかのドキュメントによる説明および部下との質疑応答が必要になります。
◎自分が理解不足のものは他人にはなおさら理解できない。
◎口頭だけの説明では必ず理解不足や誤解を招く。
◎雑な作業指示は、品質悪化による手戻りを招き、余計な時間がかかる。
自分の説明漏れの防止および相手の理解を完全にするためには、作業指示を口頭だけに頼ることなく、見える化すなわち何らかの書かれた資料による説明を行う必要があります。さらに作業指示時における相手の理解度のチェックおよび日々の作業の進捗確認時にも疑問点・不明点などの問題点の確認を実行する必要があります。日次進捗会議で毎日これらのことをフォローし続けていれば、漏れや理解不足による遅れは最短一日分で済みます。
◎ドキュメントに基づく作業指示は、業務品質を各段に向上させる。
◎日次進捗会議での疑問点・不明点の解消は、スケジュールの遅延を確実に防止する。
◆【アクションガイド：作業指示の仕方】
□作業指示者においては、事前に依頼する仕事の内容を完全に理解しておくこと。
□作業指示は口頭のみならず必ずドキュメントに基づいた説明を行うこと。
□作業指示時に、説明した内容が相手に完全に理解されたか確認すること。
□日次情報共有会議にて、作業者における不明点・疑問点・問題点を聞き出し、適切な指導や助言を行い、作業が適切に実行されるように導くこと。
以上説明した作業指示やフォローの仕方は、部下に対してのみならず開発を依頼した外注等に対しても同様なアクションが必須となります。
ｈ９ 課題：苦手の克服法
過剰な自己防衛的姿勢から自分を解放するためには、ものごとに感情的・情緒的にいちいち反応することをやめ、仕事本位・目的本位に業務に集中することが必要です。気分や感情はそのままで、科学的な合理性や道理に従った妥当性の力によって、なすべき仕事の目標に向かって平常心をもって進むことがよい結果を生みます。仕事における具体的な目標を立て、実行する必要があります。
◎苦手意識に基づく判断や行動は悪い結果につながりやすい。
◎プロとしての意識を持つ：仕事に必要なことは必ず実行すること。
◆【アクションガイド：苦手の克服法】
□ 好き嫌い（感情本位）ではなく、必要性に応じた（仕事本位で）仕事をすること。
□ 人と接する際に、人によって自分の対応に極端な差が出ないようにすること。
□ 科学的な合理性に基づき、理屈にかなった仕事を遂行すること。
□ 関係する人々の納得が得られるような妥当性のある行動をすること。
□ 自分のやるべきことを事前に明確にしておくこと。
□ 設定した目標に従って仕事を進めること。
□ チーム内で孤立しないこと。
□ 個人戦ではなくチームとして組織的に仕事を進めること。
□ 仕事を楽しくする工夫をすること。
ｈ８ 課題：意欲的に仕事に取り組む
お客様からの質問に即答できないようなことがたまにはありますが、そのようなことが頻繁にあるようでは問題でしょう。 顧客との打ち合わせは会議の中では最も重要なもので、問題になりそうな件について事前検討をしておくことは、ごく当たり前の常識だと思っていましたが、世の中にはそう感じない人もいるようです。
顧客との打ち合わせに限らず、その場で討議される内容は大よそ想像がつくものでしょう。それに対して事前準備をしていないということは、予習をしないで試験に臨むのと同じです。
事前準備を怠る原因は、単に忙しくて時間不足だったことではなく、そもそも仕事に取り組む意欲が希薄なことにあると思われます。 仕事への取組み意欲が低いプロジェクトにおいては、会議についてのみならず、問題の事前検討やリスクの掘り起こしが実行されないためにプロジェクト自体の失敗を招いています。
◎事前準備を怠る原因は時間不足というよりも、仕事に取り組む意欲が希薄なことにある。
◎仕事に対する意欲は、他人から与えられるものではなく、自分の中から作り出すもの。
仕事に取り組む意欲や自分でやり抜く意思とは、なりゆきまかせや他人依存を避け、物事や問題を自力で解決する自律的な意思や行動のことでしょう。
言葉を変えると、その仕事を”自分事”であると、しっかり認識することに他なりません。
いつも他人依存やなりゆきまかせ的な行動を続けてしまえば、仕事はいつしか無責任に流れ、自分の仕事力の低下を招くだけではなく顧客の信頼も失うことになります。
仕事に意欲的に取り組むためのアクションは、先に示したモチベーション維持と重複する部分がありますが、以下のようなアクションが必要になります。
◆【アクションガイド：意欲的に仕事に取り組む方法】
□ 仕事を楽しくする工夫をすること。
□ 単純作業にも創意工夫を働かせること。
□ そもそも自分の仕事は、誰のために、何のためにしているのかを考えること。
□ 仕事の意味や背景を理解し、形式的にこなすような仕事をしないこと。
□ 言われたから仕方なくやると言うような、やらされ感的な仕事をしないこと。
□ ＱＣＤの数値目標を立て、惰性に流されない仕事を行うこと。
□ 仕事の量や質の全体を把握することで出口（完了時期）が見えるようにすること。
□ 失敗やミスの原因を明確にし、歯止め対策を講じておくこと。
□ やる気のない者と同じ行動をしないこと。
□ 自分自身や他人を過剰にあるいは過少に評価しないこと。
□ 他人より多いあるいは少ないという比較だけにこだわらないこと。
モチベーションの維持（続き）
▶困難に直面したときは条件付行動を選択すること
物事の判断、特に困難な問題に直面した場合の行動の選択を”１か０か”の思考で決定すべきではないでしょう。”１か０”の思考、つまり”All or Nothing”思考では、多くの人は必ず楽な方つまり何もしないことを選択してしまいます。このような１／０思考は習慣化しやすく個人のモチベーションや成長の大きな阻害要因となります。困難な問題に直面したときには、「ここまでは自分が背負えますが、その他は誰かが背負っていただけますか」というような条件付の提案が有効でしょう。
◆ 【アクションガイド：モチベーション低下の歯止め】
□ 単純作業にも意味を見出すこと。
□ 苦手・困難な仕事を克服すること。
□ 強制に対抗する手段をもつこと。
□ 約束違反はどこまでも許されるものではないと認識すること。
□ 目標が見えるようにすること。
□ 低評価に対して感情的な反応を抑えること。
□ 価値が見出せないと言う前に相手の立場で考えること。
□ 緊急な支援要請に対する実行条件を提示すること。
とくにモチベーションを著しく低下させる原因としては，「味方による裏切り」「約束違反」および「体調不良」の3つが挙げられます。味方による裏切りとしてもっともインパクトが大きいものは，上司の無関心さや約束破り等があります。部下が困難な状況に陥っているときの，「オレは知らないからな」とか「自分で何とかしろ」という言葉の一撃で，部下は復讐を固く心に誓うことでしょう。
「一緒に考えよう」の一言が言えるリーダーでありたいものです。
モチベーションの維持（続き）
▶愚痴を言うより工夫をすること
ルーチンワーク的な仕事においてこそ改善活動が必要なのではないでしょうか。定型業務は面白くないなどと愚痴をいうのは受身で仕事をしている証拠です。やらされていると思うから余計に嫌になるのでしょう。面白くなければ面白くなるように工夫すればよいでしょう。どのような仕事においても必ず改良・改善の余地はあります。ルーチンワークは面白くないなどと感じた時にこそ、自分の頭をもっと働かせ面白くするための活動を行ってください。
◆【アクションガイド：仕事への取組み姿勢】
□ 好き嫌いという情緒的な姿勢で仕事をしないこと。
□ 義務感を超えた誠実さをもって仕事に取り組むこと。
□ 仕事内容の意味や背景を知るために、“なぜ。”の問いかけを行うこと。
□ 事前準備・事前調査を行うこと。
□ 放置している案件をなくすこと。
□ 複数の仕事を並列的に進める工夫をすること。
□ 優先度を判断して仕事を進めること。
□ データやドキュメントに拠る合理性に基づいた仕事を行うこと。
□ 人々の納得が得られるような妥当性のある仕事を行うこと。
□ 残務を先送りにしないこと。
□ 顧客からの電話に居留守を使わないこと。
◆【アクションガイド：困難な仕事への対応】
□ 消極的ないしは逃避的姿勢にならないこと。
□ 何が困難で不安なのかを具体的にリストアップしてみること。
□ 他人に解決策を頼る前に、自分で対策を考えること。
□ 事前の学習をしておくこと。
□ 事前準備をしておくこと。
□ 仲間との連携を検討しておくこと。
□ 条件付行動を選択すること。
□ １かゼロ的な思考をやめ、合理的かつ妥当性のある行動を選択すること。
□ チームでリスク解消に取り組むこと。
□ チーム内で妥当な責任分散を行うこと。
ｈ７ 課題：モチベーションの維持
やる気やモチベーションは，自分が出すものであって誰かに出してもらうものではないでしょう。それが証拠に，会社から与えられるご褒美やインセンティブによって社員のモチベーションが継続的に維持向上したなどという話は聞いたことがありません。
疲労困ぱいしている時は誰しもやる気が減退するものですが、それでもやり通せる人とそうでない人の差はどこから来るのでしょうか。過酷な状況を乗り越えるために必要な三つの条件は次のようでしょう。
【過酷な状況を乗り越えるための三つの条件】
①不明点や疑問点の完全な解消を行い、作業内容および量を明確にすること。
②完了時期を見えるようにすること。
③一緒に乗り越えようとしている仲間がいること。
ポイント
◎視線を、自分自身から仕事そのものへ移すこと。
◎抽象的な観念ではなく具体的な行動を起こすこと。
◆【アクションガイド：モチベーションの維持】
□ 仕事の意味を理解し、形式的にこなすだけの仕事をしないこと。
□ 単純作業にも創意工夫を働かせること。
□ 意味や背景を考えて仕事をすること。
□ 言われたから仕方なくやると言うような、やらされ感的な仕事をしないこと。
□ ＱＣＤの数値目標を持って、惰性に流されない仕事を行うこと。
□ 仕事の量や質の全体を把握することで出口（完了時期）が見えるようにすること。
□ 業務中に頻繁にまたは長時間にわたって私的行為をしている者に注意をすること。
□ 失敗やミスの原因を明確にし、歯止め対策を講じること。
□ やる気のない者と同じ行動をしないこと。
□ 自分自身や他人を過剰にあるいは過少に評価しないこと。
□ 個人に対して卑下あるいは侮辱などの行為をしないこと。
□ 他人より多いあるいは少ないという比較だけにこだわらないこと。
ｈ６ 課題：人材育成（続き）
▶感情本位から目的本位へ
【感情本位から目的本位への転換を】
あらゆる仕事において、人の好き嫌いを基準にしてしまうとものごとはうまく行きません。仕事は、人の好き嫌いなどという感情本位で行うものではなく、その仕事は何のために行うのかという目的本位で進めなければならないという認識を強く持つ必要があります。誰にとっても人の好き嫌いはありますが、仕事やメンバーの教育において、そのような感情的あるいは情緒的な態度では目的を達成することは不可能でしょう。仕事の仲間は、顧客の期待に応えるべく、好き嫌いという感情を乗り越えて、全員の思考と行動を集中して目的を達成する集団であり、決して仲良しクラブなどではありません。
◆【アクションガイド：感情本位から目的本位への転換】
□自分の関心を自分の感情から仕事そのものに移すこと。
□顧客の要求するものは何かということを良く理解し、その実現に向けて情熱を注ぐこと。
□たとえ嫌いな相手であっても仕事に必要なことは必ず実行すること。
□人の好き嫌いで自分の行動を変えず、誰に対しても一貫した姿勢と行動を保つこと。
□過度な自己中心性を捨て、顧客要求の実現のためにチームおよびメンバーに貢献すること。
ｈ６ 課題：人材育成（続き）
▶仕事の任せ方 部下に仕事をまかせるためには下記の配慮が必要です。
◆【アクションガイド：仕事を任せる場合のポイント】
□上司は、任せる仕事の全体像を完全に把握しておくこと（丸投げしてはいけない）。
□仕事の難易度とメンバーの能力レベルを見極めておくこと。
□作業の目的・意味・背景を説明すること。
□仕事の指示内容は口頭のみならずドキュメント資料により、漏れや誤解を防止すること。
□説明資料は、細かさも大切だが、分かりやすさに重点をおくこと。
□作業指示時に、相手の反応を確かめ、理解度をチェックすること。
□日次情報共有会議等で問題・疑問点のヒアリングや助言等を行うこと。
□部下の能力や気質を把握し、徐々に負荷を増していくことでその成長を図ること。
□本当の失敗を防ぐために、事前に適時のレスキューを計画しておくこと。
▶ 社員教育の場
◆【アクションガイド：社員教育の場】社員教育の場として以下を意識的に利用すること。
□チーム内における日次情報共有会議
□開発着手前における仕様の説明時
□仕様調査時における不明点および疑問点に関するＱ＆Ａのやりとり時
□レビュー時（設計、コードレビュー、単体テスト、結合テスト、総合テスト）
□不具合修正時
□プロジェクト終了時の振り返り会議
上記のすべての行動を確実に実行していれば、自分の性格の如何にかかわらず自動的にメンバー教育が実行されることになります。
▶自助努力による人材教育
１．まずリーダー自身のスキルアップを図ること。
２．開発行為の全てが教育の場であると考えること。
３．開発工程すべてにわたる改善活動を行うこと。
◆【アクションガイド：メンバーのスキルアップ】
□チーム内の日次情報共有会議等を通して問題点などの指導を行うこと。
□ドキュメント・ベースの仕事を通してノウハウの蓄積をすること。
□ドキュメントは常に最新状態に更新しておくこと。
□失敗事例の蓄積を行うこと。
□改善活動を通して新たなノウハウの獲得を図ること。
□蓄積された失敗事例やノウハウは、組織内でいつでも誰でも検索・参照可能にしておくこと。
□学習の目標および達成時期の計画を持ち、実行すること。
□専門分野に限らず広い領域の書籍を読んで仕事に役立てること。
ｈ６ 課題：人材の育成（続き）
▶改善活動の実行
プロジェクトの業務能力を高めるためには、プロジェクトの構成員である開発者個人の業務能力を高める必要があります。そのためには個々の開発者における現在の業務能力のレベルを把握し、その改善目標値を設定し、必要な改善活動を実行する必要があります。
ヒトの業務品質を数値で把握するために適した指標としては、下記の二つが一般的なものです。
①業務実行ミスの件数および率 ②業務内容の実行件数および率
これらの業務品質の数値は結果として成果物の品質となって現れてくることになります。
開発者の業務品質および成果物の製品品質を向上させるためには、それらの現時点での実力値について個人別データおよびチームデータの両方を収集し、それらの弱点を明確にし、それらを改善するための対策を組織的な改善活動として実行する必要があります。改善活動を個人レベルに任せていては、ほとんど改善は実行されないと思ったほうがいいでしょう。
◎製品品質の改善活動に取り組むことが、結果として部下の成長を生む。
個人のデータに関しては「個人スキル管理票」などとしてまとめておけば、個人のスキル育成計画やキャリア形成計画の資料として活用できます。いずれの業務品質および製品品質の指標も、ソフトウェア業界全体を網羅できるような統一的基準値は公表されていませんので、自組織における過去・現在の実績値の変動の比較によって改善目標値の設定を行う必要があります。
ＯＪＴという計画性のない人材育成方法によらず、ボトムアップ的かつ自発的な改善活動により部下の育成を図る必要があります。受動的な社内外における専門教育コースと合わせて実行すればより高い効果が得られるでしょう。
◆【アクションガイド：改善活動の基本コンセプト】
□個人戦ではなく組織戦（チームプレー）を行うこと。
□一人だけが成長するのではなく、みな共に成長すること。
□能力に長けたものは、後進の者にその知恵（ノウハウ）を譲ること。
□後進の者もその成長に従って、さらに後に続く後進の者にその知恵（ノウハウ）を譲ること。
□先に進んでいる者は、その持てるあらゆる価値あるもの、資産・資金・知恵（ノウハウ）の全てを後進のものに順に譲り渡し、永続的な繁栄の循環を実現させること。
これらの基本コンセプトは、チームプレーを促進するコンセプトであるとも言えます。改善活動はＱＣＤの改善のみならず、その活動を通してメンバーの人的育成を図り、見事なチームプレーを実現することでしょう。
ｈ６ 課題：人材の育成
▶部下が育たないと嘆く前に
部下がリーダーに確認せず、勝手な自己判断で不具合を発生させる、あるいは不明点や疑問点を質問せずにいつまでも考えた挙句に時間を浪費する、といった状況が発生している場合の問題の多くは、部下の問題と言うよりもリーダーの問題であると考えられます。部下は何らかの理由でリーダーに相談しにくい状況に置かれているのでしょう。 部下が何故リーダーに相談に来ないのか良く考えてみる必要があります。
例えば、次のようなことがないでしょうか。
①リーダーが忙し過ぎというオーラをいつも発散している。
②リーダーとメンバー間の日常的なコミュニケーションが希薄。
③メンバー自身が問題点に気がついていない。
これらの問題を解決するためには、日常的なコミュニケーションを行う仕組みを設けることおよび仕事のプロセスを通して日常的な学びの場を設けることが必要になります。
◆【アクションガイド：日次情報共有会議の実行】
（情報共有事項）
□ 開発目的・開発範囲情報の徹底。
□ 毎日の行動結果・行動予定の確認。
□ 毎日の課題・リスクの掘り起こしと対応状況の確認。
□ 開発仕様およびチーム内の情報共有。
□ 開発仕様の優先度順位情報の共有。
（報告事項）
□ ①昨日何を実行したかを報告する。
□ ②今日実行する予定は何かを報告する。
□ ③今、抱えている問題は何かを報告する
□それぞれの報告に対して、リーダーはアドバイスおよび全員で共有すべき情報を伝える。
（注）一人あたり５~１０分程度の短時間情報共有を毎日行うこと。長時間を要する問題の検討については、別途関係者のみで検討会を行うこと。また各メンバーが上記の報告をスムーズにできるようにするためには、終業時等に、報告内容を日報に記入することを習慣化する必要があります。
|
◎有効な日次情報共有会議は、 ▶ チームのコミュニケーションを活性化させ ▶ プロジェクト全体の効率および業務品質を向上させ ▶ メンバーの自律性（仕事内容の把握力、報告能力、問題発見能力）を高める。 |
◆【アクションガイド：日常的なオープンな学びの場の提供】
□ 日常の業務活動中における疑問点・不明点についての質疑応答の活発化。
□ 日次情報共有会議におけるリーダーからの指導や助言。
□ 各工程レビューにおける指摘や助言。
□ 緊急不具合対策時における上級技術者からの指導。
□ プロジェクト完了会議における失敗事例の総括。
□ 講習会・勉強会におけるノウハウの学習。
プロマネの役割の続き④
プロマネの育成
◎ガイドラインや規定の知識だけではプロマネにはなれない。
◎有能なプロマネは組織的な改善活動を通して生み出される。
◆【アクションガイド：プロマネ育成ガイド】
□プロマネの役割を規定したガイドラインを作成すること。
□プロマネガイドラインに沿った開発プロセスの実行・管理をすること。
□組織的な改善活動を実行し、その中でプロマネのみならず有能な開発者を育成すること。
□開発経験５年、１０年、15年以上の開発者は、それぞれの開発スキルに応じたプロジェクトマネジ メントのスキルを目指すこと
□プロジェクトマネジメントの難易度はそのプロジェクトのＱＣＤの難易度に対応したものとすること。
□プロマネの評価は、実行したプロジェクトのＱＣＤの成果によって判定すること。
▶改善活動の実行を通してプロマネの育成を
失敗の多い開発組織の状況を目の前にした場合、現実の環境と不整合を起している多くの問題に対して、それらの問題解決に直結する対策について自分に何ができるかを自らの頭で良く考え、仲間を巻き込んで自らの力で改善行動をとる必要があります。開発者たちは、改善活動を通して有能なプロマネに成長して行きます。このような自律的な思考や行動は自分自身のみならず多くの仲間の成長を約束してくれるでしょう。教育制度やマニュアルは、あくまでも補完的な役割を果たすだけであり、有能なプロジマネを育てるわけではありません。
自分を取り巻く多くの問題について、目が覚めるような改善活動に着手されることが期待されます。
プロマネの役割の続き③
◆【アクションガイド：課題管理の実施】
□ 課題管理表の作成と運用の実施。
□ プロジェクトの全ての課題の明確化と問題解決の実行。
◆【アクションガイド：損益管理の実施】
□ プロジェクト損益管理表の作成と運用。
□ 見積り工数と実績工数の適正な推移の管理と対策の実行。
◆【アクションガイド：プロジェクト完了報告の実施】
□ プロジェクト活動における失敗の真因および再発防止策のまとめ等の振り返り。
□ ＱＣＤの目標値／実績値の対比および原因分析およびデータベースへの登録。
□ 今後の課題のまとめと振り返り結果の他チームへの横展開。
◆【アクションガイド：プロジェクト関係他社開発チームとの情報共有および連携の実行】
□ 自社担当領域に接する他社との情報共有、連携行動を実行する。
◆【アクションガイド：過重負荷の軽減】
□ 一人であらゆる仕事を抱え込んではいないか。
□ 抱えているルーチンワーク的作業を他のメンバーに分散しているか。
□ ノウハウの継承等によりサブリーダーを育成しているか。
□ リスク管理表などで問題の事前掘り起こしおよび解消を行っているか。
◆【アクションガイド：適切な組織編制】
□ リーダー、サブリーダー、メンバーなどのスキル階層別のピラミッド構成を築くこと。
□ リーダーは複数のサブリーダーを育成し、サブリーダーはメンバーを育成すること。
□ 人員異動の要求に対してはチーム能力の急激な低下を防ぐために二番手のサブリーダーおよび二番手のメンバーを異動させること。
□ 異動させたメンバーに関しても自分の組織に必須な人材は、将来元の所属に戻す約束を取り付けておくこと。
□ 特定顧客に対するノウハウの属人的な保有のリスクを減らすために、必要なノウハウは必ず最新状態として技術ドキュメントに記載し更新を怠らないこと。
◆【アクションガイド：人材管理】
□ プロジェクトは上級者から初級者に至るまで適切なスキルの人材で構成されているか。
□ 人材管理カードなどで個人別のスキル管理が行われているか。
□ 人材の基本的な条件が満たされているか。
□ 必要な技術的能力を保有しているか
□ コミュニケーションに必要な自律的な報告・連絡・相談などの行動ができるか。
□ チームプレーに必要な協調性・誠実性などがあるか。
◆【アクションガイド： メンタルヘルス】
□ メンバーを孤立無援の状態に置いてはいないか。
□ メンバーの弱点を特徴として生かせる方法を模索しているか。
□ 他の人の一助になる行動をしているか。
□ 心身不調の者が支援を求めやすい雰囲気を醸成しているか。
□ 上位に位置する管理者は、問題が深刻化する前に発見や手当をしているか。
□ 仕事起因で発生した心身の障害は管理者の責任であると言う自覚を持っているか。
プロマネの役割の続き②
◆【アクションガイド：リスクの解消】
プロジェクトを成功に導くためには、プロジェクトに内在するヒト・モノ・カネ・情報等に起因するリスクの発掘と解消を行うためにリスク管理表の作成と運用が必須となります。
プロジェクトに内在する解消すべき主なリスクは以下の通りです。
【プロジェクトマネジメントリスク一覧】
□ 外注まで含めた統合的プロジェクトマネジメント（品質・進捗・コスト・人材管理）の不在
□ マルチベンダー下における責任分担の不明確さ
□ 開発体制の不備（能力不足の人員配置）
□ 上位マネジメントとの意思疎通不良（孤立無援によるリスクの増大）
□ 無理な開発費減額要求の無条件な受入れ
□ 無理な納期短縮要求の無条件な受入れ
□ 見積りのルール破り（承認ルーチンの無視）
□ あいまいな開発スコープおよび要求仕様の放置
□ 仕様変更管理ルールの不在
□ 条件なしの規模の大きな機能追加要求の受け入れ
□ 利益確保を優先し、品質の確保を怠る
□ 不適切な事前着手
□ 知識のない分野の開発請負
□ 新言語採用にあたっての準備不足
□ 新技術採用における準備不足
□ 既存資産流用の可否判断ミス
□ 新旧システムの同時並行開発
□ 他社ブラックボックス・ソフトウェアの事前検証不足
□ システムの劣化あるいはスパゲッティ化の放置
□ 納期厳守で不良品を出荷する
□ 納期遅延による必要工程の手抜きないしはスキップの黙認ないしは指示
プロマネの役割の続き①
それぞれの役割についての具体的なアクションを次に示します。
◆【アクションガイド：適正な見積り回答の実行】
□ 開発内容の全体像を把握しておくこと。
□ 適切な開発費と開発期間／評価期間の確保。
□ リスク物件における分割見積り等（分割開発・分割リリースの交渉）。
□ 複数社によるプロジェクトでは自社責任範囲を見積り回答書の条件に記述すること。
□ 過去の類似開発のＱＣＤ見積り・実績データベースを参考にした見積りの実行。
◆ 【アクションガイド：早期仕様凍結の実行】
□ 顧客との直接コミュニケーションによる要求仕様の期限内凍結の実行。
□ 顧客の参加・協力の要請により要求内容／納期をあいまいなままにさせないこと。
□ 開発目的・範囲・内容の明確化、あいまいな仕様・開発範囲の撲滅。
□ 要求仕様の優先度順位の明確化および優先度順の仕様凍結・開発実行。
□ 提案型仕様凍結の実行。
□ 仕様未凍結状態での先行着手の禁止。
◆ 【アクションガイド：プロジェクト計画書の作成】
□ プロジェクトの特徴・難易度に応じた妥当性のある開発・評価体制の構築。
□ 開発技術の共有化によるメンバーの育成計画。
□ 採用ルールの規定に基づいた協力会社からの適正な人材の採用。
□ 開発環境の準備・整備。開発スケジュール計画書の作成。
◆ 【アクションガイド：プロセス管理の実行】
□ プロセス管理表の作成と運用。
□ 仕様凍結遅延防止活動。
□ 妥当な設計・製造・評価工程期間の確保。
□ 開発工程内の各工程のスケジュールの遵守および主要イベントの進捗管理。
□ 各工程の出入り口・中間におけるレビューの実行。
□ 各工程における成果物の妥当性の管理。
◆ 【アクションガイド：プロジェクト進捗管理の実施】
□ 各工程のスケジュールの遵守および主要イベントの進捗管理。
ｈ５ 課題：プロマネの役割
プロジェクトマネジメントがうまくいかないわけ
プロジェクトマネジメントがうまくいかない原因は大きく分けて次の二点に集約されます。
▶プロジェクトマネジメントとは何かということを理解していないこと。（What）
▶プロジェクトマネジメントをどういう風に実行すべきかということを理解していないこと。（How）
要するに何を（What）どのような方法（How）で実行してよいのか理解できていないところに問題の真因があります。この問題は開発実務における，確定された要求仕様（What）に基づいて設計・製造・評価（How）を行う場面においても同様の問題を引き起こしています。
プロジェクトマネジメントにおいて何を実行すべきかが分かっていなければ，実行段階に進めないことは当たり前のことで，何を（What）すべきかを最初に理解しておくことが最重要なことだと言えます。
プロマネの基本的な役割
プロジェクトマネジメントは基本的にマネージャの職務であり、すなわち一定の人事権や決済権を持った人でなければ実行できない領域がありますが、マネージャの職位ではないプロマネ補佐的な仕事を担うプロマネ初心者においても、正規のプロジェクトマネージャの役割を十分理解した上で自分の役割を果たす必要があります。 プロマネの役割は次に示す通りです。
◆ 【アクションガイド：プロマネの基本的な役割】
□ 適正な見積り回答を行うこと。
□ 顧客との密接なコミュニケーションを通して早期仕様凍結を実現すること。
□ プロジェクト計画書を作成すること。
□ プロセス管理を行うこと。
□ 進捗管理を行うこと。
□ リスク管理を行うこと。
□ 課題管理を行うこと。
□ 損益管理を行うこと。
□ プロジェクト完了報告および振り返りを行うこと。
□ チーム内の日次情報共有会議を行うこと。
□ プロジェクト関係他社との情報共有・連携を行うこと。
□ 上記のアクションを通してプロジェクト全体の「ヒト、モノ、カネ、情報」の統合管理を行うこと。
ｈ４ 課題：手抜き防止
▶最終成果物は必ず現物確認を
リリースしたソフトが動作しなかったという事例は構成管理失敗の典型的な例の一つです。最終の出荷確認は正式にビルドが完了したパッケージの現物を使って基本動作を確認しなければいけません。開発環境上にあるプログラムを使って最終確認をすると、このような問題を引き起こします。この最終現物動作確認は構成管理用のチェックリストだけではなく、本来はプロジェクトのプロセス管理表に最後の重要プロセスとして記載されるべきものです。開発業務において、”多分大丈夫”という考え方は、必ず失敗の原因となります。この問題は時間を経てまた再発する危険性が高いため、リリースの最後の現物確認については、都度チーム全員に注意を喚起し、チェックリストなどのドキュメントに従った開発を励行する必要があります。これらのことを無視した最もひどい例としては、ソフトが書き込まれていない空のメディアがリリースされた例もあります。
◆【アクションガイド：テストにおける手抜き防止】
□ インターフェースにおける最終的な出力確認をスキップしていないか。
□ テスト項目未消化のまま次工程に進んでいないか。
□ 単体テストをスキップしていないか。
□ 結合テストをスキップしていないか。
□ 総合テスト項目未消化のまま客先にリリースしていないか。
□ 発見済み未修正バグを含んだままリリースしていないか。
ｈ４ 課題：手抜き防止
▶時間制御の失敗
設計・製造に共通する基本的な問題は“時間制御の失敗”にあると言えます。この問題の解消方法は次の通りです。
□ 説得力のある見積もりに基づき妥当な開発期間・費用の獲得を図ること。
□ 早期の仕様凍結を行うこと。
□ 必要時間の削減のために，業務の効率化および失敗の削減を常時実行すること。
あせりによる手抜き行為を防ぎ正常な開発活動を実現するために、上記の三点の実行に個人はもとより組織を挙げて、その全勢力を注ぐ必要があります。ポイントは必要時間の確保および無駄な時間の削減にあります。
◆【アクションガイド：プログラマーがやってはいけない手抜きの12ヶ条】
□ソースコードの”コピペ”を無節操に行なっていないか。
□ベースのプログラム構造を理解しないままソースコード変更に着手していないか。
□データ処理の仕掛けを理解しないままソースコード変更に着手していないか。
□変更対象の機能の呼び出され方、関連機能との連携の仕方を理解せずソースコード変更に着手していないか。
□作られたデータはどの機能がどのタイミングでアクセスしているのか理解しないままソースコード変更に着手していないか。
□他人の書いたソースコードを理解するためにそれを読むことだけしかしていないのでは。
□一つの変更要件に対して複数の担当者が関係している場合、早い段階でお互いに検討内容等の相互確認・レビューをしているか。また、みなバラバラにソース修正にとりかかり、寄せ集めたソースで一気にテストをしているのではないか。
□お互いにどこを変更したのか誰も知らないのではないか。
□一つの機能に関する多数の関数において同一巨大パラメータ構造体（２５６バイト等）を共通に使用してはいないか。
□開発中に発見された、以前から含まれていた潜在バグについていきなりソースコードの修正を行なっているのではないか。
□「プロジェクト計画書」を書いていないのではないか。
□「データ」をとっていないのではないか。
（出典；清水吉男著「派生開発を成功させるプロセス改善の技術と極意」および「要求を仕様化する技術 表現する技術」）
ｈ４ 課題：手抜き防止
▶単純コピペ（copy & paste）の重大な弊害
要求仕様書、設計書、ソースコード、チェックリストなどにおける、誤字、脱字、モレ、コピペミスは慢性的になっています。はっきり言えることはこれらの作成者は、作成した後に作成物を一度も見返していないということです。見返してないという行為は”手抜き仕事”をしているということに他なりません。時間や工数が足りないなどという言い訳は全く通りません。時間がなかったから信号を無視して交差点に突入して事故を起こしてしまいましたということと同じです。これらの手抜き行為で最も危険な行為は”コピペ”でしょう。自分の観察や判断を一切行わず、どこかの誰かが書いたものを単純にコピー＆ペーストすることなど仕事をしているどころか、自分で不具合のもとを量産しているようなものです。もし流用したいソースコードやチェックリストがあったなら、その全文を自分で検証し添削を入れた後に流用すべきです。流用元における入出力やその他の条件が異なっている場合が多いのにもかかわらず、何らの検証もなく”コピペ”する行為は開発・評価業務中における最悪の行為の一つであるという認識を開発者全員が持つ必要があります。
またいいかげんな評価工数の見積りの原因は、いいかげんな設計見積りにあり、いいかげんな設計見積りの原因は、いいかげんな要求仕様にまで遡れます。設計チームは評価チームとも連携し、最上流の要求仕様の明確化および早期凍結に最大の力を発揮することで、妥当な見積り、妥当な工数の獲得を実現する必要があります。
◆ 【アクションガイド：設計・製造・テストにおける手抜き】
□ 仕様の事前調査・検討をスキップしていないか。
□ ドキュメントに基づく設計・製造・評価が行われているか。
□ 基本設計工程をスキップしていないか（基本設計書未作成）。
□ 詳細設計工程をスキップしていないか（詳細設計書未作成）。
□ 仕様実現に必要なメモリー容量、ハードウェア諸元を確認したか。
□ パフォーマンス性能、レスポンス性能の考慮が抜けていないか。
□ 異常系処理の考慮が抜けていないか。
□ 各工程における自己チェックをスキップしていないか。
□ 各工程の内部／外部レビューをスキップしていないか。
□ ソースコードやドキュメントの無節操なコピー＆ペーストが行われていないか。
□ プロジェクト完了時の振り返りやラップアップをスキップしていないか。
◆ 【アクションガイド：異常系処理の見落とし防止】
□ 各種Ｉ／Ｏ系の異常系処理は、ガイドブック等で文書化されているか。
□ ＭＩＮ／ＭＡＸ制御の閾値はチェックされているか。
□ メモリーリソース
□ データ長
□ 伝文長
□ カウンターサイズ
□ ポインター値
□ 異常系項目はチェックされているか。
□ 排他制御
□ 非同期制御
□ 処理タイミング
□ リトライ処理
□ タイマー値
□ レジストリ
□ 設定間矛盾
▶あせりは手抜きを招き失敗を生む
不条理な要求ないしは見積もりの失敗によって最初から不可能な開発期間しか与えられなかった場合や，いつまでたっても決まらず二転三転する要求仕様に振り回されて多くの時間を失ってしまった場合，開発チームの全員はまちがいなく“あせり”モードになってしまいます。“あせり”とは目標未達の危険性に対する感情的な反応であり，開発に必要な最低限の期間が実際に失われてしまったのならば，このプロジェクトは間違いなく失敗することになります。必要時間の不足は業務品質の劣化を招き，調査・検討不足に始まり，工程中断，ひいてはある工程自体のスキップという重病を招いています。
手抜き問題の主なリスクは次の通りです。
▶ 必要工程の中断による製品品質および人間品質の悪化
▶ 必要工程のスキップによる致命的な製品品質および人的品質の悪化
◆【アクションガイド：手抜きの防止策】
□ 仕事の意味を考えて作業を行っているか。
□ 時間がないことを手抜きの言い訳にしていないか。
□ 予算不足を理由に手抜き仕事が行われてはいないか。
□ 合理的なプロセス管理表に基づいて開発を実行しているか。
□ 重要な手順抜けを防ぐためのチェックリストを運用しているか。
□ 手順慣れで必要なチェックを飛ばしてはいないか。
□ コーディングやドキュメント作成において安易なコピー＆ペーストを行ってはいないか。
□ ソフトウェアやドキュメント等の成果物の出荷前の現物確認や動作確認を行っているか。
□ 深刻な疲労に陥ってはいないか。
□ 手抜きで発生した実例を本人に示しているか。
□ 日次情報共有会議等で問題の共有を毎日実行しているか。
□ 前記問題点の改善活動をリーダー主導で行っているか。
□ 同様の手抜きで過去に発生した問題の事例を直接本人に示してやること。
□ 作業手順書をチェックリスト化し、全員に自己チェックを義務づけ報告させること。
□ 現在の手抜き行為に大きな影響を与えている要因の軽減・削減を行うこと。
＊「忙しすぎる」「疲れている」は改善活動の実行による仕事自体の効率化によって解決すべき問題であり、さらに言えば自主的な改善活動は開発者の論理性・合理性・自主性・自律性を育てる原動力となります。改善活動はリーダーおよびマネージャが主導しなければならない重要な義務です。
ｈ３ 課題：丸投げ問題への対応
仕事の丸投げは必ず力関係上の優位なものから劣位にあるものに対して行われます。丸投げは、会社間におけるものと社内におけるものの二通りがありますが、いずれにしても丸投げをする人や組織においては責任の放棄および当事者意識からの逃避という職業倫理上の違反行為が認められます。代金を払っているからといっても自分が果たすべき仕事を放棄することなど許されるものではないでしょう。これらの業務を外注に契約で委託したとしても、最終的にはこれらの業務品質に対する責任は発注会社にあります。他人ごとのような責任放棄的態度は社外においても社内においても許されることではありません。 責任放棄・当事者意識回避の行動は、それを行った組織や人のスキルダウンを招き、それをされた組織や人においては信頼関係の喪失の原因となり、いずれにしても組織や人に大きな害となります。
全ての仕事は、依頼（要求）する人と受ける（請ける）人との間には、それぞれが果たすべき相互義務があるという認識を持つ必要があります。 依頼（要求）する人は、何をするのかを説明する（要求仕様の提示）義務があり、受ける（請ける）人は、その要求内容に従って開発を行う義務があります。
【丸投げ状況のチェックリスト】
□ 優位な立場を悪用した不条理な責任転嫁が行われていないか。
□ 相互の約束がお互いに履行されているか。
□ 責任範疇外の仕事を強要してはいないか／されてはいないか。
□ 過不足のない要求仕様書を提示しているか／されているか。
□ 合理性・妥当性に反した開発期間・内容を強要してはいないか／されてはいないか。
□ 合理性・妥当性に反した開発コストを強要してはいないか／されてはいないか。
□ 仕事に関する疑問・質問に誠意をもって回答しているか／回答を受け取っているか。
▶丸投げは破滅地獄への一里塚 業務委託が責任放棄に至る悪魔のステップを次に示します。
Step１： 仕事が忙しくて間に合わない。
Step２： 外部の業者から人を派遣してもらい、仕事を手伝ってもらう。
このときはまだ仕事の責任は自分にあると思っている。派遣者のミスが自分の指示の悪さに有ったとしたら自分が責任を負うのは当然だと思っている。
Step３： 派遣者で穴埋めしてきたが、仕事の忙しさが限度を越えてきたので、業務のまとまった部分を外部の業者に委託する。最初のうちは委託した業務についての進行状況や品質や問題点について委託先と綿密にコミュニケーションをとっており余り問題は発生しなかった。
Step４： さらに忙しさが増し複数の仕事を抱えざるを得ない状況になってきた。もう委託先の仕事の状況を見る余裕すらなくなってきた。委託業務の細かい指示もできなくなり、自分の専門領域の技術を学習する時間も無くなり、自分の主な仕事は多数の外注に仕事を割り振ることだけになってきた。
Step５： 外注から納入される成果物に多くの欠陥が発生するようになった。
Step６： 多数の欠陥品に対して自分では到底その責任を負い切れないので、委託先外注に対してその非を責め続け製品責任の転嫁をせざるを得ないようになってしまった。
Step７： ｓｔｅｐ４～ｓｔｅｐ６の悪循環がくりかえされると同時に、学習不足の結果は自分の専門的なスキルを劣化させ、外注へまともな指示すら出せなくなってしまった。
Step８： 回復不可能な大障害が発生してしまった。
この悪魔のサイクルはStep３で止める必要がありました。仕事の分散だけではこの問題は解決できません。悪魔のサイクルを止める役割・責任はマネージャにあり、下記のアクションが必要となります。
◆ 【アクションガイド：丸投げを防止する】
□ チーム内で丸投げ行為が行われていないか常に管理・監視する。
□ 仕事のプロセスの見直しや仕事のやり方の見直しを行う。
□ 開発力を維持・強化する。
□ ムリ・ムダの排除のためのリスク排除活動および改善活動を行う。
◆ 【アクションガイド：仕事の丸投げに対抗するポイント】
□ 顧客側の役割および職務責任を契約書等にて明確にする。
□ 元請けベンダー側の役割および職務責任を契約書等にて明確にする。
□ 下請けベンダー側の役割および職務責任を契約書等にて明確にする。
□ 元請けベンダーにおいて統合的プロジェクト管理を実行する。
□ 上司および部下の役割および職務責任を社内規定等にて明確にする。
□ 自分における役割および職務責任を明確にする。
□ 当事者同士で解決できない場合は、さらに一段上のマネジメントに相談する。
□ 明確な要求仕様書、正確な設計書の適時な提供を行い、あいまいな仕様による丸投げを無くす。
□ 事前準備・改善活動等による効率化を行い、時間切迫が理由の丸投げを無くす。
□ 改善活動等によるスキルアップを行い、能力不足が理由の丸投げを無くす。
□ 丸投げ行為は職務放棄とみなし厳罰をもって臨む。
□ 丸投げに泣き寝入りすることなく組織的な対抗措置をとる。
ｈ２ 課題：開発着手前に必要な事前準備
開発作業に必要な絶対時間の不足と焦りの解消
開発に必要な時間の確保に失敗する原因は次の通りです。
（１）見積りの失敗、二転三転する要求仕様
（２）チームとしての技術能力の低さおよび段取り能力（プロセス遂行能力）の低さ
開発手順に対する無知と無理解の解消（チーム内教育）
「プロセスのＶ字モデル」を下記に示しましたが、これを見れば開発の各工程において作成されるドキュメントと各テストとの対比が一目瞭然です。この図に関しては、再度すべての開発者において、ソフトウェア開発の常識として学んでおく必要があります。
チーム統制力の強化
チームのメンバーも新人から熟練者までさまざまなレベルのひとたちが存在していますが、ソフトウェア開発の基本的な常識と言われるレベルの知識は全員で保有しておく必要があります。このプロとしての基本知識は、日々の開発活動の中および改善活動の中での相互教育によってマスターされ続けていくもので、それらの知識習得活動は意識的・計画的に実行される必要があります。 常識力の高いチームが統制力の強さを生みだしていくものだと思います。 チームの統制力とは、チームの能力を高いレベルで維持させておくための力だと理解した方が良いでしょう。一般的に「統制」というと、何がなんでもチームのメンバーをリーダーの思うがままの方向に強制的に向かわせるというような強権専横的な理解をする人たちが少なからず存在しますが、そのようなやり方では本当のチームの力の集結や成長を望むことはできないでしょう。
◆【アクションガイド：開発着手前の事前準備】
□正確かつ妥当な見積り回答によって、必要な開発期間および開発費を獲得しておく。
□設計着手前の仕様凍結を行う。
□組織的かつ継続的な改善活動を実行し、技術力・チーム能力・マネジメント能力の強化を図る。
□開発者のレベルに応じた開発の常識を開発活動や改善活動を通して学んでおく。
ｈ１ 課題：過酷なスケジュールへの対応
過酷なスケジュールを招く原因
１．必要な開発期間・開発費獲得の見積り交渉の失敗
２．いつまでも決まらない要求仕様
３．要求仕様の見積り間違いおよび実現方法の見込み違い
過酷なスケジュール状況下で起こること
過酷なスケジュールの下で行われることは、メンバーの心身の病気を招くだけではなく、開発工程のあちこちでの手抜きによる品質の極端な悪化です。 このような状況に一旦陥ってしまえば、人員投入くらいしか策はなく、その策によってもほとんど問題は改善できないというのが我々の経験則です。
納期に間に合わなかった、あるいは品質未達の結果は全て責任者が負うべきことです。
過酷なスケジュール状況からの脱出は困難
我々の開発という仕事の状況の悪化の仕方は、一般的な仕事における状況の悪化の仕方が徐々に漸増的に悪化していく場合が多いのに対して、仕事の初期の時点から大きな悪化のリスクが埋め込まれている場合が多いということに気づくべきでしょう。すなわち見積り時に約束した開発期間や費用が現実の開発を完遂するためには全く不十分である場合が非常に多いということです。その結果、開発の最初の工程からスケジュールは遅延しており、すべての工程において時間不足に陥り、あるべき目標に対して他律的に追いまくられ、個人およびチームの自律的なコントロールは全て破壊されてしまう結果になります。
見積りおよび要件定義において、自分たちの目でよく見、よく考え、妥当な条件を確保し、主体的な開発を行うことができるような実行環境の準備に全力を集中させる必要があります。
過酷なスケジュールに陥らないための予防策
◆【アクションガイド：過酷な状況に陥らないための予防策】
□ 見積り精度の向上。作業内容および作業量を明確にしておくこと。
□ 仕様調査に注力すること。不明点や疑問点を完全に解消しておくこと。
□ 要求仕様の早期凍結を実現すること。
□ 開発目標および完了時期を見えるようにしておくこと。
□ 継続的な改善活動を実施することで開発力・信頼関係・チームプレー能力の向上を
図ること。
１．スコープマネジメント アクションガイド
：開発すべき仕様の内容および範囲にかかわる問題解消のためのガイドラインです。
ｓ８ 課題：仕様変更影響度表の作成
設計書に拠らない正確な影響度表の作成方法
既存仕様への影響度を調査する仕事は、第一義的には開発チームの義務であると言えます。既存仕様に対する影響度を調査しなければ不具合のない設計も製造もできません。派生開発においては、開発チームは既存仕様に対する悪影響を避けながら設計および製造を行わなければ正しい開発を行ったとは言えません。評価チームは開発チームから提供された既存仕様に対する影響度表を基に評価設計を行うのが普通のやり方です。その上で評価チームは今までの評価の経験を活かして開発チームが見落しそうな影響部分のテストを追加するのが正常なあり方でしょう。
影響度表の作成には正確な設計書が必要ですが、現在多くの設計書は適切な更新が行われていない場合が多く、影響度表の作成は困難を極めています。このような状況下において、ある程度使える影響度表を作成するためのポイントは下記の準備活動が必要です。
【影響度表作成のための準備活動】
単体テスト、結合テスト、総合テストにおいて発見された他のモジュールに影響した不具合ならびに影響が及んでいると気づいたことを、全のテスト実行者が協力して影響度表に書き込むことを継続して実行すること。
当初は大雑把な影響度表しかなかった場合でも、派生開発の都度このことを実行していれば、完全な設計書がない場合でも、回数を重ねるごとに非常に精度の高い影響度表になっていくでしょう。開発チームにおける単体・結合テストおよび評価チームにおける総合テストにおいて両チームが連携してこの活動を地道に実行する必要があります。
影響度表は、本来ソフトウェア構造図・テーブル関連図・プロセスフロー等から作成されるべきものですが、多くのプロジェクトにおいてはこれらのドキュメントが整備されていることが少ないのが実態だと思われます。そのような状況下においては、下記のアクションガイドに示したように、開発の各工程の作業時にできるだけの情報を集めながら影響度表を徐々に作り上げていく必要があります。
◆ 【アクションガイド：仕様変更影響度表の作成】
□ 正確な構造設計書・テーブル関連図・プロセスフローから影響度表を作成すること。
□ 見積り時の実装調査にて判明した他機能への影響情報を記録すること。
□ 設計時において知りえた影響情報を記録しておくこと。
□ 製造時において知りえた影響情報を記録しておくこと。
□ デバッグ時に判明した他機能への影響情報を記録すること。
□ 単体・結合・総合の各テストにおいて判明した他機能への影響情報を記録すること。
□ 市場障害対応にて判明した他機能への影響情報を記録すること。
ｓ７ 課題：性能要件
パフォーマンス性能・レスポンス性能は重要なシステム機能要件
レスポンスとパフォーマンスは重要なシステム機能要件の一つであり、全ての処理に対してレスポンス・パフォーマンスを考慮した設計や製造を行うことは常識中の常識です。業務ロジックが正しくても、適正な時間内に処理や応答がないようなプログラムは意味がありません。
◆【アクションガイド：適正なパフォーマンス・レスポンス時間の達成】
□ソフトウェアのパフォーマンス時間はシステム要件を満たしているか。
□ソフトウェアのレスポンス時間はシステム要件を満たしているか。
□サーバー／ＤＢ／ＨＤＤ等へのアクセスを行うプログラムにおいては、パフォーマンスおよびレスポンス は最重要な要件となるという認識を全員で再度共有すること。
□同様に、これらのアクセスを行うプログラムにおいては、要求仕様書や設計書にパフォーマンス目標値 とレスポンス目標値についての記述を必ず記載し、レビューおよびテスト項目に加えること。
（具体的な達成数値目標の設定例）
□ 表示の切り替わり速度 ：２００ｍｓ以下
□ タッチパネルの反応速度 ：１００ｍｓ以下
□ スキャナーの反応速度 ：１０ｍｓ以下
□ ファンクションキー押下から機器動作開始までの時間 ：２００ｍｓ以下
これらのシステム性能要件はシステム仕様書および要求仕様書に最初から明記されるべきものです。さらにもし記述モレがあったとしても何らかの性能要件が必須であるという常識を開発者全員が持っている必要があります。 自分が設計・製造したソフトが実際に実機でどのように動作するのかを見ることは必須のことでしょう。
ｓ６ 課題：異常系仕様の合理的な決定
【異常系対応の判断基準】
・異常系対応の判断に過剰とか完璧とか想定外などという情緒的な考え方をしないこと。
・異常系対応の判断基準に、発生頻度・難易度・コストなどを持ち込むべきではない。
【例外処理の考え方】
・例外処理には、異常系処理だけではなく正常系処理も存在する。
・想定外や例外の状況になっても、ロックや永久ループの状態に陥ってはいけない。
◆【アクションガイド：異常系仕様のあるべき姿】
□あるべき異常系仕様には、「過剰な、完璧な、想定外」などの非ロジカルな言葉は使用しないこと。
□例外処理には、異常系処理だけではなく正常系処理も存在する。
□想定外や例外の状況になっても、装置側はロックや永久ループの状態に陥ってはいけない。
□イレギュラーなデータおよび状態に対してはすべてエラー処理が必要となる。
□アプリケーションロジックについて、全ての正常系および異常系の処理が過不足なく網羅されていること。
□外部機器とのＩ／Ｆにおいては、入出力条件のチェックおよび異常処理を網羅すること。
□機器単独では決められない場合は、他の機器担当および顧客との合意を得る必要がある。
ｓ５ 課題：要求仕様の変更管理 2020.3.6
▶ベースラインの意味
◎ ベースライン（基線）とは、
・ 顧客と開発側で合意した成果物の範囲および基準の事を指す。
・ 両者間で約束した仕様とそのＱＣＤに関する基準は重要なベースラインとなる。
▶仕様の変更管理が行われにくい理由
仕様の変更管理が行われにくい理由として最初に考えられることは、開発のスコープ・予算・期間を決定してしまうベースラインの確定そのものを顧客側が嫌うということがあります。
一般的に顧客側は限られた予算と期間の中で、できるだけ多くの仕様を盛り込みたいと思っていますが、ベースラインの確定はそれに対しての縛りとなってしまいます。
顧客側の考え方は、できるだけ良いものをできるだけ安く手に入れたいという所から出ているのでしょうが、そのように都合の良いことがいつでもあるわけがなく、相応の価値あるものに相応の対価を払うという健全なビジネスの基本からは逸脱する考え方と言わざるを得ません。
◎ 健全なプロジェクトには、ベースラインの確定が必要である。
▶要求仕様の変更管理不在がもたらす災い
【ベースラインの確定・変更管理の不在がもたらすリスク】
１．プロジェクトの失敗 ⇒ ＱＣＤの大幅な未達
２．顧客ビジネスの停止 ⇒ 市場障害の多発
▶仕様変更管理表がもたらす効果
安易な仕様変更にしっかりとした歯止めをかけるためには、仕様変更管理表の運用が不可欠です。
この管理表の主な目的は、仕様変更の影響を管理し、顧客側の無定見な仕様変更・追加を抑制することにありますが、特に顧客と開発側で同意した仕様凍結日以降に発生する仕様変更を厳重に管理することが重要であり、同意された仕様凍結日以降に発生した変更・追加仕様は基本的には別途見積り（追加コスト・追加開発期間）であることを顧客側が明確に認識するために使用されます。 仕様変更管理表の運用は下記のような効果をもたらします。
【仕様変更管理表の効果】
１．放縦・無定見な仕様変更の防止
２．顧客・開発側両者に対する仕様凍結期日の厳守化（開発仕様のベースラインの確定）
３．情緒的な要件定義工程のプロセス化
４．仕様変更の質、量および費用の厳格な管理
◎ ベースライン確定後の仕様変更・追加分は別途見積りとする交渉が必要。
仕様変更管理表には、管理番号、発生日、対応期限、対応日、対応状況、業務名、変更内容、変更区分、修正担当、影響度範囲、難易度、リリースバージョン、見込み対応工数、実績対応工数などを記録し、仕様の変更状況を明確にしておく必要があります。
▶仕様変更の確認方法
◆ 【アクションガイド：仕様Ｑ＆Ａ表の要件】
□ 要求仕様に関する疑問点・不明点は仕様Ｑ＆Ａ表等にて管理すること。
□ Ｑ＆Ａ表の記述内容は、誰が読んでも分かる記述になっていること。
□ 同じ仕様に関するＱ＆Ａは同じ場所に時系列順に並んでいること。
□ 複数のキーワードで検索可能な書式になっていること。
□ 仕様Ｑ＆Ａで明確になった内容は、要求仕様書も同時にメンテナンスすること。
□ 仕様Ｑ＆Ａ表は要求仕様書の添付資料としてワンセントで保管・管理すること。
◆ 【アクションガイド：要求仕様の変更管理】
□ 要求仕様のベースラインには、顧客と開発側で合意した、開発仕様の内容・範囲の定義およびその開発に関するＱＣＤ（開発費、日程、品質）条件を含むこと。
□ 開発着手前に要求仕様のベースラインを確定しておくこと。
□ 要求仕様のベースラインを基準とした変更管理を仕様変更管理表に基づいて行うこと。
□ 仕様変更管理表で管理される項目には、管理番号・発生日・対応期限・対応日・対応状況・業務名・変更内容・変更区分・変更担当者名・影響度範囲・難易度・リリースバージョン名・見込み工数・実績工数などを含むこと。
□ ベースラインから変更・追加されたものに要する追加開発費・開発期間は別途見積りとすること。
▶仕様変更対応工数の請求について
仕様変更を無料で押し付けようとする相手に対応するためには以下の対策を行う必要があります。
◆ 【アクションガイド：仕様変更対応工数の請求】
□ 見積り条件に、「見積り回答書に記載にないものについての追加・変更は全て再見積りおよび追加 開発費・追加開発期間が必要である」旨の記述を必ず記載しておくこと。
□ 「仕様変更依頼は必ず書面にて、その変更の理由および背景を明示して行うこと」が記載された仕様Ｑ＆Ａ表のフォームを先に渡しておくこと。
□ 顧客と仕様変更についての打ち合わせの都度、上記のことを確認しておくこと。
ｓ４ 課題：要求仕様理解の手順 2020.3.2
▶仕様内容の情報共有
仕様調査用Ｑ＆Ａリストは解決済み内容・未解決項目の解決予定日・変更日など必要事項を記入し、変更部については日次情報共有会議などで全員に周知徹底する必要があります。
またこれらの情報は、当該プロジェクトの掲示板に更新日の記載をもって全員に通知および公開しておく必要があります。メールベースだけではとても情報共有することは難しいでしょう。
▶仕様調査段階で仕様不具合を発見することの重要性認識
仕様の誤解などによるミスはＱＣＤすべてに大きな損害を与えてしまいます。仕様ミスの発見が開発工程の初期の段階であれば被害は少なくて済みます。仕様ミスによる手戻りコストについては一般的に次のように言われています。
【手戻りコスト１００倍の法則】
要求仕様の欠陥を要件定義工程内で修正するコストを１とした場合、
▶設計段階からの手戻り修正コストは５倍
▶コーディング段階からの手戻り修正コストは１０倍
▶テスト段階からの手戻り修正コストは２０倍
▶納入後からの手戻りコストは１００倍
◆【アクションガイド：要求仕様理解の手順】
□ 仕様調査・検討に必要な時間を確保しておくこと。
□ まずは仕様の全体像および骨子の把握から始めること。
□ 仕様調査は、顧客価値の重要度順および基幹的仕様から始めること。
□ 仕様追加・変更の影響度の事前調査を済ませておくこと。
□ 要求仕様の背景や意味を必ず明確にしておくこと。
□ 開発経験者から基本的な仕様のレクチャーを受けること。
□ 過去の失敗事例に学ぶこと。
□ 実機操作によって客先システムの動作を体感しておくこと。
□ 疑問・不明点の発掘を行い、要求者側との直接コミュニケーションで即断即決を目指すこと。
□ 仕様内容および変更内容はチーム内（含む評価チーム）で即時的な情報共有を行うこと。
□ 仕様調査のＱ＆Ａ情報や変更内容は要求仕様書や設計書も同時に更新すること。
□ 仕様決定事項や変更事項は集中的かつ情報共有可能なシステムで管理すること。
□ 期限を切って早期の仕様凍結を行うこと。
□ 基幹仕様未決定で開発に着手しないこと。
ｓ３ 課題：無理な顧客要求への対応 2020.2.28
▶なぜ代案を提案する行動に移れないのか
代案を提示する行動に移れない原因としては下記のようなことがあるでしょう。
【能力的な面】
・代案を考えるだけの知識がないこと。
・代案を相手に納得していただくためのコミュニケーション能力がないこと。
【心理的な面】
・コミュニケーションに自信がないこと。
・苦手な相手との会話を避けたがること。
・面倒くさいと思うこと。
・提案しても何も自分の得にはならないと思うこと。
【環境的な面】
・忙し過ぎてやっている時間がないこと。
不条理な顧客要求への対抗策についてのガイドラインは下記の通りです。
◆ 【アクションガイド：不条理な顧客要求への対抗策】
□ 開発責任者と要求側責任者の密接かつ直接的な話し合いを実行する。
□ 完全な要求仕様書の早期提示時期の確約をとる。
□ 未凍結仕様は、双方の合意の上、要求者において早期凍結時期を確約していただく。
□ 開発仕様はすでに凍結合意されたものに限定する。
≪困難な要求に対しては、更に困難な条件の提示を行うこと≫
□ 要求元からＰＭ、有識技術者・テストメンバー等の投入を行っていただく。
□ 開発要員増強のためのプレミアムコストの要求を行う。
□ 暫定版または優先度順のリリース、分割リリース等の条件提示を行う。
□ 暫定版の不具合発生責任は要求者に負っていただく。
□ 暫定版の市場投入は、限定数にて実験店舗のみで実施する。
□ 全店稼働は正式版のみで実施する。
一見無理だと思われる要求を受けた場合の交渉における基本姿勢は、まずはＹｅｓと答えて、ｂｕｔで実行条件を示すことに尽きます。 良く考えれば、さまざまな実行条件が出て来るはずです。
自分の弱みにばかり気を取られていると敵が見えなくなります。敵の弱みにも注目するところからタフな交渉が可能となります。“All or Nothing”的なデジタル思考をやめ，敵をよく知ることから交渉を始めたいものです。
ｓ２ 課題：仕様凍結 2020.2.23
◎ 想定仕様ではなく確定仕様に基づく開発を！
【仕様凍結を阻害する三つの障壁】
１．組織間の仕様決定能力の分断
２．情報伝達の組織間のタイムラグ
３．組織間のコミュニケーション・ギャップ
◆ 【アクションガイド：早期仕様凍結】
□ 早期仕様凍結のために顧客および関連各社の参加・協力の要請を行うこと。
□ 仕様凍結の期限を切り、元請側と下請側で合意をしておくこと。
□ 顧客・元請・下請間の直接コミュニケーションによる要求仕様の期限内凍結を行うこと。
□ 集中検討会ないしは合宿等にて短期集中的に仕様決定を行うこと。
□ 受注者側においても提案型仕様凍結を行うこと。
□ 顧客価値の優先度順に仕様凍結を行うこと。
□ 顧客価値の高い仕様順に開発着手すること。
□ 開発仕様の目的・背景・範囲・内容を文書にて明確化すること。
□ 仕様未凍結状態ないしは疑問点・不明点を残したままで先行開発着手は行わないこと。
ｓ１ 課題：要求仕様問題の解決 2020.2.14
▷ 誤解を招く仕様書の日本語記述
日本語の長々と続く要求仕様書を正確に読み解くことは至難の技です。このような要求仕様書の改善策としては次のようなものが考えられます。
①図・表・論理記号を多用し誤解を招かない表現方法を採用する。
②できるだけ分かりやすい簡潔な文章にする。
◆【アクションガイド：日本語表記の注意点】
□ 主語がない文章には主語を書き加えること。
□ 可能な限り短い文にすること。
□ 並列的な表現は箇条書きにすること。
□ 時間軸にて整理したチャートで現在・過去・未来の時制を明確にすること。
□ 読み聞かせで聞き手がきちんと理解できるか確認してみること。
□ 単位・期限・期間・対象範囲などの基準を明確にすること。
□ ％表記は何を100％としたのかを明記すること。
□ 程度表現（例：すごく，適当，ちょうど，およそ、等）を避け数値で表すこと。
□ 強調表現（例：ちゃんと，しっかり、等）を避け数値で表すこと。
□ 推測表現（例：～くらい，およそ～、等）を避け数値で表すこと。
□ その他の曖昧表現（例：～の予定，できるだけ～、等）を避けること。
▷要求仕様書のチェックポイント
要求仕様書の品質を保つためには下記の８つのチェックポイントをおさえておく必要があります。
◆【アクションガイド：要求仕様書のチェックポイント】
１．妥当であること
□ 顧客やユーザーのニーズと一致していること。
□ 上位のシステム要求仕様書などの関連する他のドキュメントとの矛盾がないこと。
□ 未確定項目がある場合は、どのように合意するか、依頼者と合意形成方法を決めておく。
２．あいまいでないこと
□ 要求仕様書に記述されている要求が、ただ一通りに解釈できること。
□ 要求仕様書の“良し悪し”を判断する手段や基準をもつこと。
□ 「範囲」を読み取れるように要求を表現すること。
□ 仕様は「仕様である」ことを明示し、説明は「説明である」ことを明示して記述すること。
□ 要求仕様書では、記述内容が“特定”できる表現になっているものを“仕様”とすること。
□ 要求仕様書の構成や内容は、後工程の読者に分かるように書くこと。
□ 「等」や「ｅｔｃ」の文言は使用しないこと。使用する場合は、○月○日までに決めるとコメントをつけること。
３．完全であること
□ 顧客やユーザーの、情報システムに対するニーズが漏れなく要求仕様書に記述されて
おり、かつ図表の参照や用語の定義などの、要求仕様書の形式が整っていること。
□ 「境界」は早い段階で決めること。
□ 「要求」のモレを防ぐために、カテゴリの分類や要求の分割・階層化に漏れがない、
隙間がないことを確認できるようにすること。
□ 要求仕様書には、「操作性」「保守性」「交換性」などの「品質要求」を記載すること。
□ 階層化の基準として、以下を（状況によっては組み合わせて）使い、「隙間」なく分割すること。
時系列分割（時間軸分割）／構成分割／状態分割／共通分割
□ モレなく書くこと。
□ 要求仕様の番号をテストケースの番号とひもづけし、テストケースにモレがないことを確認すること。
□ 仕様をグループに分け、さらに集合を小さくし、混じり気のない仕様のグループを作る。
□ ＜グループ名＞に要求の性質を持たせるためには、範囲をあらわしていることを意識してグループ名を選ぶこと。
□ 「・・・・は、・・・・しない」という「否定表現」を避け、ｔｈｅｎとｅｌｓｅの両方を明らかにすること。
４．矛盾がないこと
□ 要求仕様書内部で矛盾や衝突がないこと。
□ ほかの機能の仕様と衝突していることに気づくためにも、仕様は早期に展開すること。
□ 早い段階で全体の仕様化を行うこと。
５．重要度と安定度のランク付けがされていること
□ 各要求について、重要度と安定度を示す指標を明確につけておくこと。
□ 確認中の仕様をそのまま記述し、変わる可能性があることを明記すること。
６．検証可能であること
□ 開発されたソフトウェアが、要求仕様書に記述された要求を満たしているか否か確認可能であること。
□ 検査部門の人に、「検査可能」という側面から要求仕様書のレビューを実施してもらう。
□ 品質要求（「操作性」「保守性」「交換性」など）はテストでも確認すること。
７．変更が容易であること
□ 要求仕様書に対する変更が、容易に、完全に、一貫して行えるようになっていること。
ａ）目次や索引、明確な相互参照が整備され、使いやすい構造になっていること。
ｂ）冗長でない、つまり、同じ要求が要求仕様書内で複数個所に記述されていないこと。
ｃ）他の要求と混ざらず、各要求を独立・分離して表現している。要求が互いに依存していないこと。
□ 重複なく書くこと。
□ 仕様書全体を「均一」に記述することにこだわらないこと。関係者間で共有できている認定仕様まで、
詳細に記載しなくてもよい。
□ 仕様番号の確定作業は、仕様化の最初の段階では行わないこと。グループ分け確定後に行うこと。
□ 似た記述が続く場合に、何が違うかをすぐに読み取れるようにすること。
８．追跡可能であること
□ 要求仕様書に記述された個々の要求に関し、その起源が明確であり、開発が進行するに伴って作成
された文書等との対応付けがとれること。
ａ）後方追跡可能性があること。
ｂ）前方追跡可能性があること。
□ 設計や実装の工程で明らかになった「仕様」は、要求仕様書に書き戻すこと。
□ 「要求」と「理由」をセットで表現すること。
□ 要求仕様には固有の記番号を付けること。
（ｓ１ 課題：要求仕様問題の解決の続き） 2020.2.19
仕様の理解不足・誤解に起因する間違った記述をなくし要求仕様書の精度向上のためには以下のアクションが必要となります。
仕様問題解決策の概要
ベンダー側の要求仕様担当者にも優劣があり、仕事の開始前にその優劣を判断しておき、相応の対応をする必要があります。これは社内・社外を問わずに必要な、対人間におけるリスク対策といえるものです。次のような認識や対策が必要となります。
①要求仕様には必ず誤りがあるという前提に立つこと
要求仕様内容が貧弱な原因は、仕様決定者において、その仕様の理解が不十分だということでしょう。理解が不十分なままで出される要求仕様は、それ自体の内容は必ず不完全であり矛盾や誤りを多く含んでいます。
②要求仕様の疑問点・不明点を掘り起こすこと
全ての要求仕様に対して、その機能の意味や効果および論理性に疑問や不明点がないかどうかの自己チェックが必要で、最初の要求を受け取った時点でこの作業を必ず実行する必要があります。納得できないことは納得できるまで要求者に確認する必要があります。確認の方法はＱ＆Ａ表に基づいたフェイス・トゥ・フェイスでの確認が最も効率的で正確です。相手の要求内容を鵜呑みにして、言われたことをそのまま開発すればよいというような受動的な姿勢は避けるべきでしょう。
③要求仕様問題の解決策を実行すること
解決策については下記のアクションガイドの実行が必要です。
◆ 【アクションガイド：要求仕様問題解決策の概要】
□ 仕様凍結の期日を切り、お互いに合意しておくこと。
□ 顧客価値・顧客要求度の高い仕様からの仕様凍結・開発を行うこと。
□ あいまいな点・不明確な点・矛盾点などについて直接コミュニケーション・電話によるヒアリング・Ｑ＆Ａシート等による確認を設計開始前に終了させること。待ちの姿勢や放置はいけない。
□ 開発の初期工程においては要求元担当者との密な（週２～３回）コミュニケーションを重ね仕様変更・追加の有無を確認することで後工程での頻繁な仕様変更や仕様凍結の遅延を防ぐこと。
□ 仕様の条件やノウハウである要求仕様の背景や理由について必ず確認し文書化すること。
□ 経験不足な部分は有識者への質問や相談を行うこと。
□ 待ちの姿勢ではなく、こちらからも仕様提案を行うこと。
□ 仕様提案力をつけるためにベンダー側のＳＥ・顧客打ち合わせ等へ参加すること。
◆ 【アクションガイド：ユーザー目線に立つこと】
□ さまざまなエンドユーザーの視点を持つこと。エンドユーザーの例：オペレータ・受発注担当者・商品配送者・商品開発者・運用管理者・損益管理者・クレーム管理者、など。
□ ユーザー目線の本質は、顧客および開発側にて長年蓄積されてきたノウハウであると認識し、要求仕様の妥当性は自己の経験・観察やドキュメントおよび経験者に拠ること。
◆ 【アクションガイド：適切ではない要求仕様の見つけ方】
□ ①明らかにその仕様では正しい機能が実現できない場合（ビジネスロジックの欠陥）
□ ②Ｈ／ＷおよびＳ／Ｗの性能上実現が不可能と思われる場合
□ ③従来同じ業種・業態で広く受け入れられている入出力方式（操作手順、表示方法、印字方法等）と異なっている場合
□ ④ソフトウェアの処理速度（パフォーマンス、レスポンス）に大きな悪影響を及ぼす場合
□ ⑤他の方法でもっと簡単に顧客要求が実現できる場合
◆ 【アクションガイド：提案行動】
□ 代案を考えるだけの知識および相手を納得させるためのコミュニケーション能力を持つための学習や改善活動を継続実行すること。
□ 忙し過ぎて提案する時間がないならば、効率的な提案を行うことで時間の余裕を生み出すこと。