振り返りの目的
おっと、画像は振り返ってますけど、内容とはまったく関係ありません。あと、ググって拾った知らない子の画像です。ｶﾜｲｲﾃﾞｽﾈｰ。
PMIが制定しているPMBOK（第5版）の定義では、「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」とされている。 つまり、会社などの通常業務や、継続的な運用管理、あるいは改善活動などは、特に開始と終了が定義されていないので、「プロジェクト」とは呼ばない。
とあるように、基本的にプロジェクト活動というのは、
・期限／期間が設けられている
・なにかしら独自性がある（過去、全く同じものは存在しない）
ことが大前提です（ちなみにPMBOKはＩＴだけでなく、殆どの製造業、サービス業で適用可能な国際規格です）。
そのため、原則としてＰＤＣＡのフレームワークが用いられており、プロジェクトを重ねるごとに改善、昇華されていくようなマネジメントであることが求められています。
プロジェクトマネジメントのＰＤＣＡは、プロジェクト内のＰＤＣＡと、プロジェクト間のＰＤＣＡに大きく分かれます。
プロジェクト内のＰＤＣＡは、定点観測（Check）に従い、運用中に課題・問題があればどんどん改善(Action)していったり、逆にいい点があれば周知展開して、メンバー全体にも共有してもらったりする行為です。
プロジェクト間のＰＤＣＡは、プロジェクト終結時に「振り返り(Check/Action)」をおこない、その中で
成功体験であれば「再現性の追求」
失敗経験であれば「再発防止の検討」
を議論しあいます。「どんなことをすれば、次も同じ成功が再現ができるのか？」「どんなことが原因で失敗したのか？どうすれば全く同じ失敗をしなくていいのか？」これらがCheckやActionの中で検討されなければ、次に新しいプロジェクトに参画する時、前回成功したことが再現しなかったり、前回失敗したことと同じ失敗をしてお客さまの不興を買ったりしてしまいます。
なにより、プロジェクトメンバーが成長しません。
プロジェクトメンバー…すなわち、企業を構成する従業員が成長しない、あるいは企業の収益を支える人的リソース（外注含む）のグレードが上がらないと言うことになります。
労働集約型モデルの企業の場合、こうなってしまっては「社員を増やす」ことでしか収益が右肩上がりにならないことが確定します。ただでさえ、労働人口が減少している昨今、ＩＴ関連企業は数も多く、どの会社も人材の取り合いが続くような状況です。そんななかで、いつまでも「人自体を成長させる仕組みがないため、人を増やさなければ収益は横ばい。人が辞めれば収益が下がる」と言ったやり方では、生き残れるはずもありません。
だからこそ、（ＯＯＤＡだろうがなんだろうが、他のどんなやり方をしてもいいけど、それとは別に）ＰＤＣＡはＰＤＣＡでしっかりやることが求められます。量で勝負しにくいのなら、質で勝負するしかないのです。
（それに質を向上させれば、一人ひとりの業務効率も向上しますので、結果として多くの人のワークライフバランスに好影響が出るようになりますしね。そうしてホワイトな企業体質になれば、さらに採用面でも好影響が出ることでしょうし。）
今所属している会社でも、そういった取り組みを私が主体になってさせてはいますが、如何せんまともに報連相もできない人がマネージャーをしていたりもするので、私のところに提出されてくるプロジェクト終結時の報告書（完了報告書と呼んでいますが）をチェックするたびに、ため息ばかりこぼしています。
今日届いた報告書のなかでは、プロジェクト進行の中で起きた「反省点（問題点）」について、次のような内容が記述されていました。
・基本設計作成の時期と詳細設計再作成の時期が重なり、詳細設計再作成のレビューに人を割くことができなかった。そのため、再作成の確認は簡易的な確認となってしまい詳細設計作成のレビューに記載内容の問題が発覚した。
再作成した内容を再修正する作業が発生し工数が多くかかり、リスケジュールを行うこととなった。詳細設計再作成の完了時期を遅らせても、レビューに時間を割いた方が結果として工数がかからなかったと思われる。
先ほども述べたように、この文章が記載された文書は「完了報告書」です。報告することが主目的の文書です。まず、最初に
詳細設計再作成の完了時期を遅らせても、レビューに時間を割いた方が結果として工数がかからなかったと思われる。
という最後の一文は不要ですよね。だって、これは「報告」ではなく「意見」ですから。「報告」は主観が入ってはいけません。事実情報以外が含まれていてもいけません。それが報連相の大前提です。口頭で報告する場合、報告の後に「これは私見ですが…」と意見を添えても許容される場合はありますが、少なくとも「報告」の中にごちゃ混ぜにして良いものではありません。
もちろん、報告書の中に「対策案」等の欄があれば、内容が良いか悪いかはともかく、
詳細設計再作成の完了時期を遅らせても、レビューに時間を割く
と記載するのはあってもいいでしょう。「次からはそうする」そう言う決断をした報告となるからです。ですが、ただ単に思ったかどうかはどうでもいい話ですよね。
また、この報告では、
詳細設計再作成のレビューに人を割くことができなかった。
ことが問題だったのか、
詳細設計再作成の確認は簡易的な確認となってしまった
ことが問題だったのか、
詳細設計作成のレビューに記載内容の問題が発覚した
ことが問題だったのか、
再作成した内容を再修正する作業が発生し工数が多くかかり、リスケジュールを行うこととなった
ことが問題だったのか、ハッキリしません。もちろん、一つひとつは根本的原因があったからこそ連鎖的に発生した問題ではあります。ですが、因果関係を明確にするのであれば、
基本設計作成の時期と詳細設計再作成の時期が重なったから（原因）
詳細設計再作成のレビューに人を割くことができなかった（結果）
と
詳細設計再作成のレビューに人を割くことができなかったから（原因）
詳細設計再作成の確認は簡易的な確認となってしまった（結果）
と
詳細設計再作成の確認は簡易的な確認となったから（原因）
詳細設計作成のレビューに記載内容の問題が発覚した（結果）
と
詳細設計作成のレビューに記載内容の問題が発覚したから（原因）
再作成した内容を再修正する作業が発生し工数が多くかかり、リスケジュールを行うこととなった（結果）
は、問題としては全くの別物です。そして、もしもこれらが１本の線でつながるものであり、他に要因がないと言うのであれば、最初の
基本設計作成の時期と詳細設計再作成の時期が重なったから（原因）
詳細設計再作成のレビューに人を割くことができなかった（結果）
だけを挙げれば済むはずです。これさえなければ、他の問題も誘発されなかったと言うことなのですから。
ただ、私に言わせれば、基本設計作成の時期と詳細設計再作成の時期が重なったからみたいな他人事のように書いていることの方に問題を感じます。作業タスクは重なってしまったのではなく、重なるようにスケジュールを組んでいたのです。
たしかにＩＴ業界のプロジェクトは、お客さまがあまりＩＴリテラシーを持ってらっしゃらなかったりもするので、「どれだけ大変か」とか「どれだけの規模になるか」と言うイメージをされにくい傾向があります。そのため、短納期／低コストを求められやすいと言う特性があります。
そのため、スケジュールが一つひとつしっかりと地に足をつけて…と言うわけにはいかず、かなり五月雨で進めなければならないケースも珍しくありません。
確かにスケジュールを詰め込む手法として多く見てきましたが、だからといって一人の担当者のタスクを同じ日、同じ時間に重複させていいと言うわけではありません。あくまで、工程や作業が重複しない範囲で、スケジュールを圧縮することが目的です。
にもかかわらず、マネージャーはこうしたスケジュールを作成する際に、「成果物の伴わないタスク」をスケジュールに記載しようとせず、その上で、担当者全員のスケジュールを隙間なく詰め込もうとするものだから、
・会議体
・レビュー
・調査作業
と言ったタスクが発生すると、必ず他のタスクと重複し、スケジュールが乱れることになってしまうわけです。
では、そうした乱れを一般的にはどうやって解決しているのか？と言うと、殆どのＩＴ企業では
個々人の残業を強制する
ことで賄おうとするわけです。根本原因はすべてマネジメント上の不備であるにもかかわらず、その責任をメンバー全員に押し付けるようなかっこうを採るわけです。
私に言わせれば、この問題点の報告は、長ったらしくズラズラと言い訳を書くのではなく、
レビューをWBSおよびスケジュールに組込まなかったため、
レビュー担当者の開発タスクとの間でスケジュール調整が難航し、
結果として、再作成時のレビュー密度が下がって、問題の流出があった
と書くべきではないのかと思うわけです。
ちなみに
再作成した内容を再修正する作業が発生し工数が多くかかり、リスケジュールを行うこととなった
ことは、原因からは直接紐づきませんので、行きつく問題としては扱っていません。レビューをWBSおよびスケジュールに組込まなかったと言う原因に紐づく問題は、あくまでもレビュー品質が下がったことです。その対策を講じた時にたまたまスケジュールの見直しをしなければならなくなったにすぎません。
こういうスキルって、ＩＴとか全く関係ありませんよね。
いわば「国語」の領域です。
ＩＴ業界と言うと、とりわけ理系の方が有利とか言われて久しいですが、私はそうは思いません。コンピューターに慣れている方が良いでしょうし、理系学科の方がコンピューターに触れる機会が多いのは確かですが、理系だから有利と呼べるのは、数学を起点とした「論理的な考え方」だけです。
最初のうちはそれでスタートダッシュできるかもしれません。旧態依然としたキャリアパスですが
３５歳（４０歳？）エンジニア定年説などと呼ばれた、半ば年功序列でこんなヒエラルキー型のキャリアパスをいまだに継続しているＩＴ企業を非常に数多く見てきました（今いる会社でもそうです）。そしてマネージャーの中から、それらしい業績を上げている人を管理職に取り立てていくのです（本人が、プロジェクトの業績にどれだけ貢献したのかを全く見ようとせずに昇格させるから、能力も人望も高くない上司が存在していたりするわけです）。
ですから、理系大学出身の方がまだまだ「プログラミングに馴染みやすい」「馴染む環境が用意されていることが多い」関係上、有利と言われているわけです。
しかし、歳を重ね、経験を積み上げていくと、フロント（客の前）に立って、説明や交渉、調整などを求められるようになっていく人も多いと思います。エンジニアになり、リーダーになり、マネージャーへとなっていくと、当然、「顧客説明」「顧客報告」「顧客交渉」「顧客調整」などは他の誰でもない、自分で行わなければなりません。
ここで多くのエンジニアの壁となっているのが
「国語」
です。まともな文章力（表現力、語彙力）が無かったり、ビジネストークを知らなかったり、報連相もまともに使えなかったりと言うケースが後を絶ちません。後半必須スキルとなるのは文系スキルです。
ＩＴ業界でよく言われていたのは
理系は「採用」に有利、文系は「出世」に有利
です。実際、管理職の多くは「話せる人」「コミュニケーションが取れる人」が多いと思います。顧客や経営層へのプレゼンテーションにせよ、部下への指導やコーチングにせよ、コミュニケーション能力が高くないと、多くの人たちと意思疎通を図ることができませんしね。
いいなと思ったら応援しよう！
