こんにちは。エンジニアリング マネジャーをしている今野です。
この記事はリンクアンドモチベーション Advent Calendar 2021の9日目の記事です。
これはなにか
新しいフレームワークを導入したいとか、開発プロセスを変えたいとか...
学習していると、気になること、やってみたいことが出てくるもの。
ただ、どうしたら決裁する人を動かす技術提案ができるのか
挑戦したいエンジニアに向けて、僭越ながらヒントを書き記したものです。
個人的な経験に基づくものですが、少しでも参考になれば幸いです。
※ 私自身もエンジニアのマネジャーをやっておりますが
なんとなくOKを出しがちなので、自戒を込めてちゃんと言語化しようという記事です。
解決したいテーマ
開発のお仕事をしていると「効率上げたいからアーキを再構築したい！」とか
「開発プロセスをもっとTDDにやりたい！」といった相談を上げたりすると思います。
ところが、意気揚々とリーダーに相談するとなんとなく受けが悪い…。
そんな**「せっかく考えた技術提案に共感してもらえない！」**状態を今回の課題としています。
技術でチャレンジできる環境を、自分の提案で実現できたら最高じゃないですか！
原因らしいこと
技術的には面白い提案であるにも関わらずどうも共感が得られない場合
およそ次の3つの「よくわからない」が発生していることが多いように思います。
-
解きたい課題が何なのか よくわからない
🤔ダメな例： 「効率悪くて、レガシーで、システムの見通しが悪くて...」 -
どんな選択肢があるのか よくわからない
🤔ダメな例： 「絶対このライブラリ入れるのが良いですよ！」 -
やる気があるのか よくわからない
🤔ダメな例： 「他社と同じプロセスを導入すべきだと思います。」
上記3点に気をつければ、だいたい共感が得られると言って良さそうです。
提案のコツ
なにもきれいなプレゼンを作って提案しましょう！という話ではなく
頭の中でちゃんと整理してから相談すれば、わかってくれるはずです。
たいていの場合、リーダーもそれなりに経験を積んだ手練なのですから。
3つのコツを紹介していきたいと思います。
【Point #1】 課題が何なのか特定する
コードの見通しが悪いとか、バグが出やすいとか、やる気がでないとか
ソフトウェアには様々な問題があるわけですが、それらはまだ課題ではありません。
枝葉の問題から解決しようとすると、いくら時間があっても足りなくなってしまいます。
まずは、根本的な問題を特定して、課題を明らかにしましょう。
"根本"というと難しく聞こえますが、シンプルに2 Stepで見つけられます。
Step 1：問題をディレクトリ構造で整理する
抜けもれなく問題を見つけるために、ディレクトリで整理する。MECEですね。
Before:
コード調査が大変、開発が大変、テストできない、やる気が出ない
インシデント多発、MTTR低い、スキルアップできない、負債が蓄積 etc...After:
低い生産性/
├プロダクト/
│ ├コードの複雑性
│ └テストコード不足
├プロセス/
│ ├開発
│ └運用/
│ └通常運用
│ └インシデント
└エンジニア/
├スキル不足
└モチベーション低い
Step 2：問題をリスト形式でなく、矢印形式に変える
上記で出てきた課題たちの因果関係を明らかにするために、問題を矢印でつなげる
After：
コード複雑＋テストコード不足
→ コード調査が大変
→ 日々の開発・運用で手一杯
→ 新たな挑戦ができない
→ スキルアップできない
→ 開発のモチベーションが低い
実際の現場では上記のサンプルほど単純ではないと思いますが
まずは矢印の出発点を根本の課題として認識できるはずです。
【Point #2】 解決の選択肢を考える
問題を解決するとき、複数の技術の選択肢を持っているのがエンジニアというもの。
1つしか選択肢がないと「ちゃんと検討できていないのでは？」と不安になってしまいます。
提案するときは、松竹梅で3つくらいプランを出すと良いでしょう。
Before:
「Vue.jsでフロントを開発しましょう！」After:
・| プラン① | 学習コスト:小 | 開発サイズ:小 | Vue
・| プラン② | 学習コスト:中 | 開発サイズ:中 | React
・| プラン③ | 学習コスト:高 | 開発サイズ:大 | Angular
⇒ 「プラン①にしましょう！」
さらに技術的な面白さも比較項目に入っているとモチベーション上がります。←私見
【Point #3】 やり抜く意思を主張する
合理的にロジックを説明するのも大事ですが、伝える側の心の声も欠かせません。
逆に合理性だけでは、遠巻きに評論家として言っているだけに映るリスクもあります。
最後までやり抜く意思表明として、欲求や感情を伝えることも大切にしましょう。
Before:
「開発効率1.5倍が見込まれるのでTypescriptを導入したいです。」After:
「もう変数が把握できない現在のコードベースでは正直つらいです！
開発効率1.5倍にするのでTypescriptを導入しましょう！」
ポジティブに、エンジニアとして挑戦したい旨を伝えるのもオススメです。
挑戦したい気持ちを無下にするリーダーはそういないはずです。
まとめ
エンジニアが、もっと技術の提案ができるようになると良いなぁ、という気持ちで
提案までの要点整理を3つのポイントで書き起こしてみました。
上司やリーダーがエンジニアの場合は、なんとなくで合意が取れるケースもありますが
周囲の仲間たちに納得してもらうためにも、上記の観点は意識してみると良いと思います。
提案が苦手だな、という方に少しでも伝わるものがあれば幸いです！