「プロジェクトマネジメントのスキルだけでは、プロジェクトは成功しない」プロジェクトマネジメント勉強会第5回に予定していた内容を公開します
こんにちは、リチャード 伊真岡です。以前私が勤務していた会社でプロジェクトマネジメント勉強会というものをシリーズで開催していて、今回の記事は最終回にあたる第5回の内容です。第4回と5回は内容こそ準備できていたものの、途中で私が退職したため開催出来なかったので、ブログ記事として内容を残します。
- 第1回はこちら - 「ディズニー映画制作、ゲーム開発そしてソフトウェア開発の類似点」
- 第2回はこちら - 「アジャイル開発から要件定義・設計重視な開発への回帰」
- 第3回はこちら - 「並行作業とスキーマ駆動開発」
- 第4回はこちら - 「効果計測が当たり前のデジタル広告、計測が当たり前じゃないエンジニア生産性」
以下勉強会で発表予定だった内容です
最初に結論です。
ソフトウェア開発プロジェクトのマネージャー(注釈*)が、プロジェクトマネジメントだけを一生懸命学んだとしてもプロジェクトは成功しません。なんのために5回も勉強会をやってきたんだ！というな話ですが、現実は厳しいものです。ただ「それだけでは成功しない」のであって「役に立たない」わけではありません。
(注釈*) ここでは最近よくあるプロジェクトマネージャー、プロダクトオーナー、テックリード、エンジニアリングマネージャーなどの細かい分類はしません。ぜんぶまとめてマネージャーと呼びます。プロジェクトに関してメンバーに指示を出す立場でプロジェクトの成果に責任をもつ人のことです。
マネージャーが必要とするプロジェクトマネジメントスキルをより細かく分類すると、ざっと思いつくだけでもこういったものが挙げられます。会社によってはスキルマップのような形で明示しているところもありますね。
- アジャイル開発、リーン開発、スケジュール管理、Work Breakdown Structure、リソース分配、リスク・マネジメント、ビジネス・アナリシス、リーダーシップ、コーチング、人事評価、ネゴシエーション…
Project Management InstituteのCore Competency Areasなんてものもありますね。これをみても分かる通り、スキルマップの類は通常、面食らうほど多種多様なスキルを列挙しているものです。
それだけでなく、一つ一つの知識体系が非常に深くもあります。例えば「アジャイル開発」ひとつを考えてみても、エンジニアとして手を動かして開発した経験がないとピンと来ない説明が多くあります。そしてスクラムかカンバンどちらを採用するのか、さらにアジャイル以外の手法にも詳しくないといけません。なぜなら正しい選択というのは採用しなかった選択肢も含めて詳しく知ることで初めて可能だからです。
リスクマネジメントもセキュリティのようにリスクを「危険性」として捉える話か、それとも投資判断としての側面からリスクを「機会」として捉えるかで、必要な知識の種類が全く変わってきますし、それぞれ、究めようと思えば学問として複数分野が成立している深い分野なのです。
さらに深さだけでなく、知識体系の広さも問題です。「プロジェクトマネジメント」という枠にとらわれず、プロジェクト成功に必要な知識を考えると、純粋なソフトウェア開発技術、業界の知識など、必要な知識はいくらでもあります。
「いやいや、マネージャーが全てのスキルを身につける必要はない。チームで開発するのだから、多様なスキルを持つメンバーが各々得意な分野を担当する」と普通は思いますね。これについては気をつけるべきです。
あなたがマネージャーであるならば、自分にない能力を他人に頼る時点で、足元を見られる可能性が格段に高まります。自分が詳しくない分野の成果物は品質の確認を出来ないからです。他人の作業途中での進捗を判断することも出来ません。最悪の場合カモられます。他人を信頼して任せることと、その人以外に頼む先がなくてすがりつくことは全く違います。「信頼して任せる」とは「他に選択肢があるが、あえてあなたにお願いする」という依頼主に余裕のある状態を指すものです。
マネージャー自身がある程度純粋なソフトウェア技術を勉強する必要があります。スキーマ駆動開発で紹介したように、学べば大きく開発スピードをあげてくれるものがあるからです。しかし困ったことに自分のプロジェクトにどの技術が役立つかは、勉強した後でないとわかりません。
そして業界知識、ビジネスの知識も必要です。あなたがマネージャーとしてソフトウェアに新機能を追加する時、新サービスを立ち上げる時、調べに調べ抜いて、考えに考え抜いて作っていますか？もしそうでないなら、今あなたが月間数十万の給料を支払うメンバー複数人を割り当てて作っている機能が役に立つと確信する根拠は何でしょう？まさか「さらに上の上司に言われたから」ではないですよね。
リソース(時間と人的資源)の足りない中で勝負する
さて、プロジェクトマネジメントのスキルマップだけ面食らっている場合ではなく、マネージャーにはそこからさらに知識の深さも広さも追求していかないと、プロジェクトの成功がおぼつかない、という話をしてきました。ここからは私の持論なのですが、組織論の大原則を紹介しましょう。
- 現代の組織はリソース(時間と人的資源)が足りない、それも圧倒的に足りない中で戦わなくてはならない
組織論って今も昔もビジネス書では大人気テーマで、マネージャーみたいな職種の大好物なんですが、この大原則を真正面から取り扱っている本はほとんど見ないです。「やれば効果のある組織論ノウハウ」は星の数ほど紹介されているんですけど、どれか1つでも実行すると有限で貴重なリソースがどんどん削られていくんですよね。多分ビジネス書を読んだときの高揚感が一気に失われる都合の悪い話だから隠してあるんだと思います(笑)。
「ふざけるな！勉強することが際限なくあるって言ってるのに、リソースも足りないんじゃ八方塞がりじゃないか！」という声が聞こえてきそうですが、やる気を削ぐためにこんな話をしているのではなく、残念ながらこれは現実です。現実の力は強大なので、現実から目をそらしても失敗が待っているだけです。もう少し先に希望があるのであと少しだけこの文章に付き合って下さい。
これは日本の中小企業だけでなく、世界の大企業でも、世界中から優秀な技術者が集まる超有名オープンソースプロジェクトであっても、リソース不足には苦しんでいます。たとえばKubernetesのGitHubレポジトリをみてみましょう。2000を超えるイシューがありますね。Tensorflowは3600イシューです。両方とも、これでも昔に比べればイシューの数がだいぶ減ったのですが(笑)メンテナの人数に対してイシューの数が多すぎです。オライリーから出ている有名なUser Story Mappingの本の中にも次の表現があります。
There’s always more to build than you have people, time, or money for. Always. - User Story Mapping: Discover the Whole Story, Build the Right Product (English Edition)
KubernetesでもTensorflowでもこの状態なので、「優秀な人材を雇う」といったリソースを増やすリソースの不足に対処する方向では、プロジェクトの成功に近づかないことは明らかです。
これらのプロジェクトはGitHubイシューの数と比べると、圧倒的にエンジニアの数が足りていません。しかし、プロジェクト自体は大成功しています。オープンソースとしても、それに付随するビジネスとしても、これら以上に成功しているソフトウェア開発プロジェクトを探すことが難しいほど、世界的にトップレベルの大成功プロジェクトです。
ここでようやく希望が見えてきました。リソースが足りなくてもソフトウェア開発プロジェクトは成功させられるのです。そして日本のソフトウェア開発プロジェクト、企業でも間違いなく成功と言える例は枚挙にいとまがないほどあります。
リソースが足りない中での戦い方として、大きなヒントとなるのはt_wadaさんの発表にもあった「質とスピード」の概念です。開発スピードが遅くなっていくと、どんどん時間を削られて負け戦が確定するので、歯を食いしばってソフトウェアの質と開発スピード両方を保ち続ける必要があります。
放っておくと質もスピードもどんどん下に引っ張られるので、マネージャーは自分とチームの時間をどこに投資すれば両方を保ち続けられるのか、見極めを繰り返さなくてはなりません。長期間スピードを保つことができれば、少しずつ時間に余裕ができ、そこで初めて先を見据えた勉強が出来ます。
マネージャーは自分の知識の幅と深さを向上させ、さらに盤石の体制を築かなくてはなりません。メンバーにも勉強してもらわないといけませんが、優秀なメンバーに頼るのが危険なのは先に述べたとおりです。メンバーに任せきりにせず、マネージャーは同じ分野を自分も勉強する心構えが大切です。実際には、メンバーが勉強していること全てをマネージャーが勉強するのは、無理だとわかりきっています。それでも「本当ならマネージャー自身も知ったほうがいいことを、時間的に無理だからメンバーに任せる」と捉えることは重要です。そういう意識でいたら、ほんの5分でも10分でも、マネージャーは空き時間にメンバーの取り組んでいることを調べ始めるでしょう？
そもそもエンジニアは技術力がある人間のみ尊敬する人が多いので、マネージャーがとんちんかんな依頼を続けると、メンバーはマネージャーの足元を見るようになります。「自分より優秀な人間を雇う」みたいな話はマネージャーの耳に心地よいですが、実際は「優秀なメンバーに蹴落とされないよう必死で食らいつく」のが、自分より優秀なメンバーを抱えるマネージャーの実情です。
そして、どんなにマネージャーが頑張ったとしても、プロジェクトの成功に重要な知識を全て身につけることは不可能です。ここで自分の時間を、そしてチームメンバーの時間をどこに投じればよいかという投資判断の必要が出てきます。
- どうしても自分ができないところはメンバーに任せるしかないが、任せすぎると足元を見られる
- マネージャーは勉強すべき事項が多すぎて、それぞれの間で取捨選択が発生している
- ソフトウェアの質とスピードを保とうとすると、つい新機能開発に及び腰になる。どうすればバランスを保てるか？
- ソフトウェア開発の質とスピードを高く保たねば勉強する時間の余裕がなくなるが、勉強時間が減ると質とスピードを保つための技術の探索ができなくなる、卵と鶏の関係
- 何を勉強すればいいかは最終的には勉強した後でないとわからないため、ある程度ムダを覚悟で勉強にリソースを割り振るしかない
同じ表現を繰り返しますが、「歯を食いしばって頑張る」しかないです。リソースに対してやるべきことはいつでも圧倒的に多いのです。マネージャー自身とチームが何に取り組むべきか、何を勉強すればよいかという投資判断を、何度も何度も繰り返さなければなりません。ある程度の判断ミスは許容せざるをえませんが、失敗しすぎると、あるいは大きすぎる失敗を1つやらかすと、チームかもしくは会社が沈む厳しい世界です。
判断を失敗しないマネージャーはおらず、すべての知識を備えた完璧なマネージャーも存在しません。しかし毎回の判断の際に仮説検証をしっかり繰り返し、知識の分野にとらわれず自分でどんどん知識を掘り下げ広げていくマネージャーが「結果として」(つまり最初からその状態を目指すのではなく)、知識豊富でメンバーから頼られるマネージャーになれると思います。