こちらはグロービスアドベントカレンダー25日目の記事です。グロービスは国内では最大規模のビジネススクール/経営大学院を運営している会社で、私自身もグロービス経営大学院のMBAに通っているので、この記事では私が学んだMBAスキルの中でエンジニアの皆さんにも役に立つであろう知識・フレームワークをピックアップしてご紹介します。
1. 正しい意思決定をするスキル
まずは正しい意思決定をする為のスキルです。顧客が本当に欲しかったものを作り上げる為にも、エンジニア側も交渉力・調整力を持つ事が重要です。
1-1. 交渉力としての「ZOPA」と「BATNA」
ZOPA（ゾーパ）とBATNA（バトナ）と呼びます。ZOPAは Zone Of Possible Agreement の略で、お互いに交渉が締結できる範囲のことを示し、BATNAは Best Alternative To Negotiated Agreement の略で、お互いにどこまでなら妥協ができるのかという限界点を示します。
請負などで開発をしていると要件は所与のものと捉えがちですが、積極的に交渉・ヒアリングをしましょう。意見にはファクトが隠れている ことが多いです。ファクトを中心にコミュニケーションをしっかり行い、意見の背景にある隠れたニーズを探しだし、ZOPAを広げにいきましょう。基本的にエンジニアとビジネスサイドには情報格差があります。顧客が本当に欲しかったものを作り上げるためにも、柔軟なマインドを持ちながら、相手の合意領域を広げた先で お互いに妥協点を探る のが有効です。
1-2. アンカリング・フレーミング
アンカリング・フレーミングとは、 最初に印象的な情報を与える事によって、その後の意思決定に影響を与える 事です。
特に人月に関しては適切な 情報のアンカー(錨) をおくべきです。10人月かかるシステム開発も、それがどれくらいのコストになるかがわかっていない人はステークホルダーの中に結構いると思います。**「10人月くらいかかるので1人月100万円だとして1000万円程度の投資が必要」**という情報のインプットをしておくことで適切な意思決定を促せます。ビジネスサイドのメンバーは人月に対するコスト意識が低い場合もありますので、適切にコストに変換をして、金額で比較できるようにします。 Apple to Apple(=同じ物差し)で比較をする ことを徹底しましょう。
交渉において大事なのは 正攻法で意見をぶつけに行かないこと(戦わないこと) です。いろんな場面でアンカーを置いていくことで、より自分が進めやすい方向に物事を進めましょう。
1-3. 意思決定マトリクス
プロジェクトのステークホルダーが多くなってくると、明確な意思決定が一気に難しくなります。そういった際に 定量的かつ客観的に優先するプロジェクトを決定 できるフレームワークが意思決定マトリクスです。
アイデアを並べて、その 評価軸 (以下では収益性・将来性・コストを選択) を決めます。加えて 評価軸の重要度 (以下では将来性を重要とし2倍で評価) を決め、掛け合わせ総和をとる事で総合評価として優先度を決定します。
| 収益性 (x1) |
将来性 (x2) |
コスト (x1) |
総合評価 | |
|---|---|---|---|---|
| アイデアA | 5 | 2 | -1 | 8 |
| アイデアB | 3 | 5 | -2 | 11 |
| アイデアC | 4 | 4 | -3 | 9 |
A案がいいのか、B案がいいのかをダイレクトに議論をすると 意見の衝突 が発生します。意見の応酬は大概いい結果を産みません。 ファクト を基に 価値基準で判断 する事が重要です。
1-4. 緊急度・重要度マトリクス
あなたの開発現場では 緊急度が高いものが優先されている なんて事はないですか？そういう時に緊急度・重要度マトリクスが有効です。
| 緊急度:高 | 緊急度:低 | |
|---|---|---|
| 重要度:高 | MUST↑ | 価値↑ |
| 重要度:低 | 錯覚↓ | やめる↓ |
緊急度も重要度も高いものはMUSTで実施されるのでそう気にする必要はありません。
気をつけなくてはいけないのは、緊急度が高くて重要度が低い ものです。それが優先度が高いという状態は 錯覚 です。優先度を下げましょう。重要度が高くて緊急度が低い ものは 価値 のある施策です。そういったものこそ優先度を上げましょう。
1-5. ロジカル・シンキングとクリティカル・シンキング
思考法としてのロジカル・シンキング (論理思考)とクリティカル・シンキング (批判的思考)についても少し触れます。
ロジカル・シンキング (論理思考) においては 意見と事実 (ファクト) の混同 、 論理のすり替え、 異なるものでの比較 (=Apple to Orange) などが発生しているケースが多々あります。本質解を導く為にも なぜ？を5回繰り返せ 、という言葉もありますが、適切な論理思考ができていないと５回繰り返した先に出した答えも Garbage In Garbage Out で無意味なものになります。
クリティカル・シンキング (批判的思考) とは何か？という問いもよく聞きますが、これは他者に対して批判的になるということではなく 自分の思考の癖に批判的な思考法 と定義してみるとわかりやすいです。
自分の意見は論理的に正しいのか？ ではなく、よりメタ的な 意見を出すに当たっての自分の考え方は正しいか？考え方の考え方はどうか？ に対して問いかけてみる思考法です。メタプログラミングっぽいですね。
2. 開発にかかる正しいコスト意識を持つスキル
次はコストに対する考え方を理解し、正しい意思決定ができる為のスキルについて見ていきます。
2-1. 資産と費用
あなたがソフトウェア開発・運用にかけたその支出は 資産ですか？費用ですか？
長期に渡って運用されるソフトウェアの開発にかかった支出は 資産 としての計上、AWS等のサーバ運用の支出は 費用 として計上されるケースが多いと思います。昔のオンプレミスであれば購入したサーバ代金を資産として計上し、減価償却するケースが多かったですが、だいぶそういったものも減って来ました。
会計上の処理のされ方も変わって来ますが、大きな違いは、 資産とは将来の価値を作るための支出 、 費用とはその時点で消費されてしまう支出 です。なので、同じ支出だとしても Apple to Apple として比較をしてはいけません。
ソフトウェア開発に1000万円をかけたのに今年は売上が800万円しか出ていないのでダメだ、というのはそれ単体では論理が間違っています (案外こういった論点を出す人は多いです)。資産は将来の価値を作っているのですから、将来価値まで含めて議論が必要です。
2-2. 時間的割引率
上記の話に少し関係しますが、 今年100万円もらえるのと、来年100万円もらえるのでは価値が違う ということにも意識が必要です。
直感的にもわかるかと思いますが、来年もらえる100万円よりは今もらえる100万円の方が価値は高いです。ファイナンスでは 時間的割引率 という考え方で、将来の期待収益を割引率という数字で割り引いて現在価値に戻します。
例えば割引率が10%であれば、来年100万円もらえるという事象の現在価値は90.9万円 (100万円/(1+10%)) 、という形になります。
ですので、10年にわたって100万円のキャッシュを生み出す事業に1000万円投資しましょう、という論理も怖いものがあります。時間的割引率の考え方を活用して、正しい将来価値の見積もりをしたいものです。
2-3. サンクコスト
サンクコスト (埋没費用)は 今現時点での意思決定に、過去に支払った金額は一切関係がない という考え方です。
去年1000万円の投資を行なっていたとしても、今年、別のプロジェクトに投資をした方が将来価値が高いのであれば過去の1000万円の投資は捨てるべきです。
「せっかく投資したんだから」「せっかく開発したんだから」 という言葉が出て来くる気持ちもわかりますが、その言葉が出るたびにちゃんと今、何に投資をすべきかを正確に判断するべきです。
2-4. MVP開発に使える「リアル・オプション」
ファイナンスの中には リアル・オプション という理論があります。簡単に説明すると、今時点で全ての投資の意思決定をするのではなく、例えば小さく始めて、よかったら追加投資をする、といったような将来に段階に渡って意思決定のオプション(選択肢)を持つプロジェクト評価方法の一つです。とてもアジャイル的な匂いを感じます。
通常、 リスクの高いプロジェクトだと上記で書いた時間的割引率は高くなり、現在価値は低く評価 されます。よってリスクの大きい新規プロジェクトは嫌われます。一方で、リスクの高いプロジェクトもリアルオプションの考え方を導入することで、プロトタイプが成功したら大きくシステム投資をしましょう、といった小さく始めるオプションを選択することでプロジェクト価値を高く評価することが可能になります。
不確実性の高いプロジェクトでも、リアルオプションの考え方を使ってトライしましょう、と提案しましょう。
2-5. 技術的負債という言葉に表れる「負債」
エンジニアが大好き技術的負債という言葉ですが、ファイナンスにおいて 負債は一概に悪いものではありません。
100万円しか自己資金がなくとも900万円の負債を借りることができれば10倍の資金でレバレッジの高い事業推進が行えます。支払利息があることで利益も下げることができ、税金を減らすなど節税効果も期待できます。
悪いのは 負債を返さない ことです。負債を返さないと毎年の支払利息がかさむようになり、最悪の場合倒産に至ります。
エンジニアの我々としても、技術的負債を借りることで得た側面もあると思います。一概に悪いと捉えるのではなく、 技術的負債が返済されないこと に対して課題意識を持ちましょう。
3. エンジニアからプロダクトマネージャになるためのスキル
エンジニアからプロダクトマネージャになる方も多いと思います。プロダクトを正しい方向に導くために必要なスキルをいくつか紹介します。
3-1. 最高の戦略とは戦わずして勝つこと
競合サービスがこの機能を入れているので同じ機能を入れましょう といった意思決定はされていないでしょうか？競合サービスには我々にない機能があるから作らなきゃいけない、という論理はとても危険です。
競合と正面から戦いに行くのもなくはないですが、次第にコスト競争に陥って、コモディティ化し、結果チームとしても疲弊します。戦略論を正しく理解し、外部環境や業界状況を分析、理解することが必要です。
古典的ではありますが、PEST 、 5F 、 3C 、 STP 、 4P といった言葉は理解しつつ、競合環境の中でもプロダクトが進むべき道を描いて行かないといけません。外部環境から導かれる理想の状態と、現在のギャップを埋める、という考えが重要です。
最高の戦略とは戦わずして勝つことです。その開発に戦略はありますか？
3-2. 密度、範囲、規模、ネットワークの経済性
事業は何かしらの競争優位を築く方向に進めるべきですが、 密度の経済性 、 範囲の経済性 、 規模の経済性 、 ネットワークの経済性 という言葉は知っておいていいと思います。
例えば 規模の経済性 は、規模の大きいことを実施する際には固定費としてかかるコストが分散され、コストメリットを活かせるということを言っています。AIを使って業務改善をしましょう、といった話になった際にも、規模が活かせなければAI導入のコストは回収できません。大きな規模のことをやるからこそ、システム開発等に関わるコストが低減できる、ということを意識したいですね。
これらそれぞれの経済性は 参入障壁 を確保するために重要です。戦わずして、参入障壁を積み上げる。そういった戦略をうまく活用しましょう。
3-3. プロダクト・ライフサイクル
全く新しいサービスを開発して、ユーザを拡大していきたいので、ユーザに不満を感じているところを聞きましょう、というのは正しいアクションでしょうか？
おそらくそういうフェーズでより重要視すべきは、 「なぜ使わないか」 ではなく 「なぜ使うのか」 です。プロダクトにはライフサイクルというものがあって、 「導入期」「成長期」「成熟期」「衰退期」 を変遷します。それぞれのステージにおいて、競合状況や顧客層も変わってくるので、プロダクト開発にも何を重要視するかが変わって来ます。
| 導入期 | 成長期 | 成熟期 | 衰退期 | |
|---|---|---|---|---|
| 売上 | 低い | 急上昇 | ピーク | 低下 |
| 利益 | マイナス | 増加 | ピーク | 低下 |
| 競合 | 少ない | 増加 | 安定 | 低下 |
| 顧客 | イノベータ | アーリーアダプター | マジョリティ | ラガード |
新しいサービスを開発した直後はおそらく 新しいものが好きな顧客層に対してマーケティングをしている状態 だと思いますので、顧客の声も なぜ使うのか？ といった事を明確にする事に重点を置きたいですね。
3-4. PPM（プロダクト・ポートフォリオ・マネジメント）
プロダクト・ライフサイクルにポートフォリオの考え方を導入できるのがPPMの考え方です。プロダクト・ライフサイクル上 導入期 のプロダクトばかりだとマーケティングに費用がかさみ資金が枯渇します。一方 成熟期 のプロダクトばかりだと 衰退期 に入った際に新しい芽がなく心もとないです。
| 市場のシェア:高 | 市場のシェア:低 | |
|---|---|---|
| 市場成長性:高 | 花形事業 | 問題児 |
| 市場成長性:低 | 金のなる木 | 負け犬 |
PPMでは 「問題児」「花形事業」「金のなる木」「負け犬」 の4象限で事業を分析します。プロダクト・サイクルに置ける導入期は問題児、成長期は花形事業、成熟期は金のなる木、衰退期は負け犬といった対応となるのが理想的です。
ソフトウェア開発もこのようにキャッシュを生む 金のなる木 のような事業からの資金を、新しい 問題児 の事業に投資して、 問題児 の事業を 花形事業 に転換できるよううまくポートフォリオを組んでいきたいものです。
3-5. プロダクト・アウトとマーケット・イン
プロダクト開発の手法としては、 開発者がいいと思うものを作るプロダクト・アウト と、 マーケットのニーズに合わせたものを作るマーケット・イン として分けることができます。
古き良き時代には作ったら売れるという時代があり、プロダクト・アウトが主流でしたが、近年はマーケットのニーズに合わせたものを作る必要が出て来てマーケット・インの考え方が主流です。一方で、iPhoneやiPadはプロダクト・アウトの考え方で大きな利益を確保する事ができました。
ニーズが飽和され尽くし、技術が発展した現代においてはプロダクト・アウトもマーケット・インも双方適用可能な考え方です。一方で、どちらのスタンスで事業を進めるかによって開発の手法やマーケティングのあり方は大きく変わってくる という意識が重要です。
3-6. アジャイル開発とリーン開発
アジャイルとリーンの違いについても少し触れておきます。
アジャイルは敏速なという意味で速度重視 です。リーンは無駄のないという意味で効率性重視 です。アジャイルは大きなソフトウェア開発であっても、開発工程を小さく区切ることで柔軟な要求変更に対して機敏に対応するものです。一方のリーンでは無駄を極力なくそうとするのでMVPを通しながら顧客像を徐々に明確化していきます。
結果として高速なプロダクト開発ができるので同じような文脈で語られることが多いですが、定義の違いを理解し、どのように組織開発の中に組み込むべきかは考えた方が良いと思います。
4. リーダーシップを育むためのスキル
エンジニアのキャリアとしてテックリード、エンジニアマネージャ、CTO、VPoEなどがありますが、そのそれぞれで必要とされるリーダーシップについて見ていきます。
4-1. リーダーシップとマネジメント
リーダーシップとマネジメントに対して様々な整理はあると思いますが、私の中でのわかりやすい定義は、リーダーシップは Do the right things. であり、マネジメントは Do things right. です。
...わかりにくかったですかね？つまり、 正しい事をやる というのがリーダーで、 正しく物事を進める というのがマネージャです。もっと噛み砕くと、リーダーはWhyやWhatにフォーカスをします。なぜ、何をやるのか、それを示せばメンバーは付いて来ます。一方でマネージャはHowとWhenにフォーカスをします。どのように、いつまでにというものを明確にし、物事を正しく進めます。
4-2. リーダーシップとフォロワーシップ
優れた組織運営をするには優れたフォロワーもまた重要 です。フォロワーとして、いかに組織の目標にコミットして推進するか、また自律して行動できるかは重要な指標となります。
CTOもVPoEといった人材でさえ誰かのフォロワー です (CEO兼CTOといった人は自由にやっていそうですが) 。優れたフォロワーシップを育むというのも、キャリア開発においてはとても重要です。
4-3. マズローの欲求5段階説
リーダーとして行動する際に、人の欲求について理解をする事は重要です。マズローはこの欲求の段階を 「生理的欲求」「安全の欲求」「所属と愛の欲求」「承認の欲求」「自己実現の欲求」 の5つと定義しました。
| 欲求 | 内容 |
|---|---|
| 自己実現の欲求 | 能力を発揮してなすべき事を成し遂げたい |
| 承認欲求 | 他者から認められたい |
| 所属と愛の欲求 | 組織に属して他者に関わりたい |
| 安全の欲求 | 身の安全を守りたい |
| 生理的欲求 | 生命を維持したい |
生理的欲求を満たすように過剰な労働時間にならないようコントロールし、安全欲求を満たすように健康的なデスクやチェアを用意する。所属と愛の欲求を満たすようにチームワークを大事にし、承認欲求を満たすように評価制度を構築する。ここまでは組織運営の中でも比較的実現できると思います。
一方組織運営の中で 自己実現の欲求を満たす事はかなり難しく なります。個人個人によって何を自己実現とするかは千差万別です。本当の自分とは何か、何をやっている時に楽しいと思うのか、フロー状態でコードが書けるのはどんな時か、死ぬことがわかっていたら何をやっていたいか、そんなキークエスチョンに向き合いながら見つけていく必要があるため、高いコーチング能力とメンバーとの信頼関係 が必要です。
4-4. ジョハリの窓
チームの中でのコミュニケーション活性化や信頼関係を築くのにジョハリの窓というフレームワークも有効です。自分が知っているか知らないか、また他者が知っているか知らないかの4象限で 「開放の窓」「秘密の窓」「盲点の窓」「未知の窓」 という領域に分けられます。
| 自分が知っている | 自分が知らない | |
|---|---|---|
| 相手が知っている | 開放の窓 | 盲点の窓 |
| 相手が知らない | 秘密の窓 | 未知の窓 |
お互いがお互いを知っていれば知っているほど、コミュニケーションが活性であればあるほどに、自然とチームワークが生まれ、リーダーがマイクロマネジメントをする必要がなくなって きます。
直接管理するのではなく、チーム全体の場を作る、という事もリーダーとしては意識をしておく必要があります。
最後に
MBAはかなりの時間と労力を使うので技術に特化したいエンジニアの方にはおすすめできません。専門スキルを伸ばす方向にしっかり時間を使った方がいいと思います。一方でエンジニアマネージャ、CTO、VPoEといったキャリアを目指す方にはスキルやマインド、そこでできる人脈には大きな価値があると感じます。
エンジニアがビジネスサイドに歩み寄る事で新しい発想や新しい進め方が生まれると思います。世の中にイノベーティブなプロダクトやより良い開発プロセス、エンジニアの地位向上が実現できる事を期待しています。