チェックリストでリスクを見つけてプロジェクトを幸せにしよう
先日、今の日系企業の末路が垣間見える記事を見てしまいました。
エンジニアの個人技能がどんなに優れていても、それで得られる恩恵は
・就職／転職に有利
・一生食いっぱぐれない
・常に最先端の技術に触れていられる
くらいでしょう。仕事を内向き（個人に収束させる方向）に見るなら、それもアリだと思います。ですが、ＩＴの仕事って個人たった１人で成立するものでしょうか？
情シスのような保守・運用だけに特化するなら、初老くらいまではなんとか１人でも耐えられるかもしれません。
ですが、最前線でバリバリ開発していようと思ったら、組織化されている環境でないと、なかなか仕事がありません。よほど飛び抜けた才能でもあれば別なのでしょうけど、私を含め、凡人から努力して才能を開花させてきた多くの一般人には、なかなか個人単体で仕事をするのは難しいと思います。仮に個人事業主になったとしても、大半の「開発するお仕事」自体はどこかの組織的な活動をしているSIerやベンダーの中でなければ存在しません。結局、どこかのプロジェクトチームの中で活動することの方が多いのです。
そこで重要になってくるのが、組織をコントロールするマネジメントの腕です。
大人数で１つのビッグプロジェクトを成し遂げようとしたとき、個々人が割り当てられた役割に対して必要十分なスキルを有していることも重要ですが、それ以上に「個」を「集」にすることで何倍、何十倍もの成果をあげられるようにできるマネージャーの力量が不可欠になってきます。
と言うか、エンジニアがブラック化された現場に直面するかどうかなんて、個人技能ではどうにもならず、すべてマネージャーの腕次第ですよ。マネジメントが下手ならプロジェクト期間中の人生は棒に振った…と思っておいて良いでしょう。
一昔前とちょっと違うのは、「残業は全額支払う」と言う企業が多少増えたくらいでしょうか。真性ブラックな企業ならサービス残業は当たり前ですし、準真性ブラックなら、新労基法の定める規定時間を超えた分だけ"なかったこと"にさせられるくらいでしょうか。
私の今いる会社でも、残業時間が80hを超えたら、翌月に総務から「80h未満に減らしてください」って言われました。前々から「こんなに仕事を押し付けられたら、間違いなく超えるから。うちの部は、たった１人しかいないんだから、負荷分散できないんだよ？」と言っておいたのに、いざ超えてみると「実績値を減らせ」と言うのです。まぁ、管理職だし、残業代なんて深夜残した時にわずかながら入るかどうか…ってところですから、別にいいんですけど、コンプライアンスとしては大問題ですよね。
まぁ少なくとも、今も昔も、エンジニア一人ひとりの幸不幸を掌握しているのは、マネージャーだということです。
そんな中、有能か無能かわからないマネージャーに自分の人生を丸ごと預けたいと言う人が、56%もいるんだなぁ…言うのが、ちょっとビックリです。
私は、それが嫌で、社会人になって丸３年経った春（25～26歳？）に、上司に直訴しました。
「どんなに小さくてもいいので、
１からすべてを経験できる立場をさせてください。
今のままでは、全体のどこを担っているのか把握できません」
と。当時、１からってのは「見積り」からって意味で言った言葉でした。その言葉をきっかけに、「じゃあ、やってみるか？」と言われてリーダー兼マネージャー（兼エンジニア）をするようになりました。誰から教わるでもなく、誰から支援されるでもなく、すべてが自己責任で、すべてが自己裁量だったので、もちろん恐ろしく苦労したのは言うまでもありません。
それでも、そうやって全体を掌握するポジションでい続けたからこそ、メバーの目線とマネージャーの目線の食い違いを整理し、客にとってだけでなく、会社にとってだけでなく、メンバーにとってだけでもない、誰にとってもハッピーになれるマネジメントを模索するようになれました。
どんなニーズがあるから、どんな設計に紐づくのか
どんな設計があるから、どんなプログラムに紐づくのか
そういった情報の流れが見えず、ただ指示された機能、処理を、ただ指示されたとおりに実装するだけのお仕事に満足できなかったんですね。とにかく全体を俯瞰して見たかったんです。ほら、建築なんかだと模型（モック）作るじゃないですか。あんなイメージを自分の中でも常に描けるようにしたかったんです。
そうすれば、他人（他マネージャー）に自分の人生を振り回されずに済む、そしてできればメンバーの人生を振り回すことなく、彼らが満足して仕事に従事できる環境を作りたい、そう思ってきました。
管理職になった今でも、その考え方は変わりません。
だからですかね、部下を駒や道具としてしか見ていない上司、部下に命令するだけで自分では何一つ動こうとしない上司、責任を負わず、果たさず、取らず、ただ偉そうにしているだけの上司、と言うものが心底大嫌いなんです。
もし、エンジニアを目指している方がいらっしゃったら、ちょっと足を止めて考えてみてください。
「自分の人生を、有能かどうかもわからない
マネージャーに預けることができるか？」
「自分がマネージャーになって、
多くの人を幸せにできるマネジメントを修得してみないか？」
それでも「技術が好き！」と言うのであれば、私も止めようとは思いません。エンジニアと言っても、優秀になればなるほど選択肢は広がるわけですから、優秀なマネージャーが在籍している企業に属すればいいだけですしね。
私の時代にはそう言う選択肢もなかったもので、優秀なマネージャーに遭遇するギャンブルを選ぶよりは、自分で優秀なマネージャーと言う道へ進むのが一番楽だと思えたんです。
リスクをすべて取り除けば、成功への一本道しか残らない
さて、そんなマネジメントですが、私なりに色々と経験してきた中で、１つの結論をお話しすると、極論になりますが、マネジメントとは
「リスク管理とイコールである」
と言っても過言ではないと言うことです。多くの選択肢が用意されていると言えば聞こえはいいですが、それらの選択肢の９割以上は『失敗』ルートです。『成功』ルートも複数用意されていますが、『失敗』ルートの数に比べれば、圧倒的に少ないのが実状です。
リスクとは、この失敗する選択肢のことです。
ですので、ありとあらゆるすべてのリスクを回避すれば、プロジェクトはかならず
期限通りに、
要件通りに、
お客さまも満足して、
全員がハッピーに、
終わるはずです。全てのリスク（危険性）が発生しなければ、そうならないとおかしいはずです。
もちろん、机上の空論なのはわかっています。
事実上、すべてのリスクを取り除くことはできませんし、私もそうするべきだとは言いません。そもそも「あ、これ失敗するな」と見た瞬間に理解できるリスクなんて、わざわざ選ぶなんてことはしないので、放置しておいても問題ありませんし、過去の経験や歴史から、「あ、これ失敗するやつだ」と言うことをしっかり振り返って学んでおけば、潰せる選択肢も少なくありません。
たとえば、たまに「品質の劣化」が著しいから品質向上を図るように…と指示すると、
「品質に注力しようとすると、コストがかかる」
という言い回しをする人がいます。
おかしいですよね。
そもそも、見積もる時点で、納品するであろう製品の品質は、100%となるように見積もっているはずです。最初から予算の中に、品質を100%にすることが大前提ですし、お客さまとして求めているのは、必要な機能に対して品質100%であることですから、これ以上、品質を上げなくていいような仕事ぶりになっていなくてはいけません。
まさか、
「品質70%のつもりで見積もってました」
なんてプロジェクトは存在しないはずです。もしそうなら、見積り条件に明記する等していないと、非常に大きなリスクとなります。
仮に、100%にできなかった場合をリスクとして想定するなら、どうすれば既存予算で100%にできるか、その工夫を試行錯誤するのが、エンジニアやリーダー、マネージャーの責務のはずです。
なにひとつ工夫しようとせず、ただの人海戦術しか選択肢を持たマネジメントは、マネジメントしていないのと変わりません。それは、素人でもできることです。
マネージャーに求められる力量は、そんな素人紛いのものではないはずです。
リスクは完全に取り除けない。ならば次なる施策にかかるまで
たとえば、あるゴールへたどり着くと思われる選択肢が100本用意されていたとしましょう。そのうち、成功するルートは３本。残り９７本は確実に失敗するルートです。
たいていはこのようなスタートとなるはずです。
みなさんならどうしますか？
私なら、まず「経験」と「歴史」から情報を集め、明らかに失敗すると分かっている選択肢を取り除きます。これを「リスク回避」と言います。この時点で『成功』ルートしか残っていない状態にするのが最も良いのですが、
・過去の経験を蓄積できない
・過去の歴史データを蓄積できない
と言う個人や企業が大多数である以上、なかなかリスク回避精度の高いマネジメントを行うのは難しいみたいです。私含め、こうした過去データをしっかり管理している一部の人にしか実践できません。
そこで次に重要になってくるのが、『失敗』ルートに迷い込んでしまうことを想定して、リスク対策を構築することです。ありがちなのは
・思った以上に不良／欠陥が多くなってしまった
・一部のメンバーが体調不良等になってしまった
・お客さまとの情報連携が上手くいかず、仕様が定まらない
と言った理由によって、スケジュールが遅延しはじめるというものです。実際、こんなものは多くのマネージャーが、まず間違いなく経験するもので「まさかそんなことが起きるなんて」なんて想定外になるようなものではありません。
けれども、こうした既知のリスクに対して、何も手を打とうとしないマネージャーがごまんといるのです。
では、仮にこれらのリスクに対して、発生することを受け入れつつも、発生した際の対策がしっかりと練られている場合はどうでしょう？
・対策準備が整っていてすぐに鎮静できる施策
・すぐに応援が駆けつける施策
・コミュニケーション齟齬の原因を特定し、保険を掛けておく施策
なかには検討したうえで「微々たる影響しかでないので、放置する（もっと優先度の高い施策にとりかかる）」と言う施策があってもいいでしょう。
こうした対策に秀でていると、プロジェクトメンバーであるエンジニアたち、組織であれば部下たちは、安心して目の前の仕事に従事できるのではないでしょうか。
ITプロジェクトのリスク予防への実践的アプローチ
そんな中、IPAが幸せへの最短ルートと言うべきドキュメントを出しています。それが、
です。
長いですが、一読の価値はあるというか、百読の価値あるドキュメントです。色々なシチュエーションごとに編纂されていて、
「プロジェクトの最初に」
「プロジェクトの途中で」
「プロジェクトが終わってから」
それぞれ違う読み方ができると思います。
ただし、大学の先生が監修しているためか、非常に長いので、「長い」「多い」と言うだけで読む気が無くなるような人には勿体ない資料かも知れません。
これは、「システム化の目的が明確でない」場合のチェックシートのようです。汎用的に作られているため、「○○の案件では…」と言った固有の条件に特化した仕様には耐えられません。そう言うミニマムな資料にはなっていません。固有の制約は、個別のプロジェクトごとにテーラリングするのが常識です。
しかし、これをチェックするだけでも、割といい線でリスクの洗い出しが出来るはずです。
リスクとして「発生しうる可能性が高い」ものが見つかったら、対応方法を考えなければいけません。基本的にはチェックに引っかからないようにすればいいのですが、どうするのがより良く対応できるのかは実際に資料を読んだ方が良いでしょう。
一番大事なことは、
プロジェクトの成功のためにはベンダーの努力だけではダメで、
必ずユーザーにも協力をしてもらわなければならないシーンがやってくる
ということです。
IPAが推奨する方法としても、
「こういう協力をしてもらいましょう」
という対応策がほとんどですので、計画段階…具体的にはお客さまとのキックオフミーティングの段階までに、どこまでお客さまを巻き込み、責任のスコープを明確にし、きちんと合意を取っておけるかで、プロジェクトリスクの難易度、ひいてはプロジェクトの成功率が変わるということです。
開発チームとユーザー、お互いの幸せのために、そして企業と従業員の幸せのために、リスクが顕在化しない、あるいは顕在化したリスクの被害を最小限にできるマネジメントを心がけましょう。
それこそが、マネジメントを担うものの最優先で負うべき責任です。
また、このIPAの提供する資料では「進捗が遅れる」とか、「見積もりを誤った」とか、そういう自己責任で起こりうるリスクに対する対応は入っていません。
しかし、このリストに対応をあらかじめ取っていれば、そもそもそういった事象が発生しにくくなることは間違いありません。
「ちゃんとこういう工数考えてる！？」
と言ってくれているリストにちゃんと対応すれば、基本的に進捗や見積りベースとなる工数が足りなくなることなんて無いはずだからです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。