提案力ってなに?
「提案力ってなんだ...?」
「企画書を書けるようになれってことか...?」
「AIツール導入のための稟議書を書こうみたな...?」
いえ、そんな難しい話ではないので安心してください。一言で言ってしまえば、提案力とは、「自分はこれがいいと思う」ということを周りに伝える力です。
これから詳しい話をしていきますが、最初は全然できなくてOKです。というか、最初はそれどころではありません。
先輩「こういうエラー起きたら詰んじゃうね」
「ぐぬぬ...」
先輩「このロジックだと境界値でバグるよ」
「ぐぬぬ...」
先輩「N+1になってるから、パフォーマンス悪くなっちゃうね」
「ぐぬぬ...」
先輩「1ファイルが長いから責務を切り分けよう」
「ぐぬぬ...」
こんなことばっかりです。
ですが、安心してください。最初はだいたいみんなそうです。雲の上に居るような先輩エンジニアたちも、かつてはボコボコにレビューされ、ミスをやらかし、ベソかいています。
なので、へこたれることなく「一度受けた指摘は二度と繰り返さない」という気持ちで、まずはレビューや失敗から学ぶことに専念しましょう。
この記事は、ある程度こなれてきたちょっと先の段階のお話になります。人によりますが、1〜3年くらいで意識するといいかなという内容です。
スタート地点が違うという残酷な現実を直視する
同じ社会人1年目、同じ経験年数であっても、スタート地点は全然違います。
ちょっと勉強していたというレベルから、大学でCSを修め、インターンで実務レベルのプログラムを書いていたレベルまで、スタート地点はすでに大きな差があります。この事実は変えようがありません(同じ会社でここまでの差が出ることは稀ですが。)
なので、自分と周りを比べないことです。言ってもたかが数年の差。これまでの人生の倍くらいある社会人生活においてこんなものは誤差なので、割り切りましょう。
1. プログラムの提案力
プログラムの実装方法はいくつもの選択肢がありえます。シニアエンジニアでも、「どれがいいかな...」と悩むこともあります。
こういった複数の選択肢が見えた際に、とりあえず最初に思いついたやつで実装してPRレビューに出すのではなく、「A,B,Cの3つのパターンがあると思うんですが、自分はAがいいと思います。なぜなら...」と、提案する。
自分で選択肢を吟味することが成長につながる
実は、提案そのものよりもその過程が大事です。最終的に「これがいい」と提案するにあたって、当然自分自身で選択肢を洗い出し、メリット・デメリットを比較検討して結論を出すわけなので、提案を行う過程で自分なりの意思決定ロジックを組み立てることになります。
この思考活動そのものもいい経験ですし、何より、先輩からレビューやフィードバックをもらう際に得られる経験値が倍増します。というのも、先輩が思考プロセスや意思決定そのものに対してフィードバックを行うことが可能になるからです。
「Aも悪くないんだけど、ここが致命的になるかもしれないからBの方が安全かな」
「今回はAで良いと思うんだけど、実はDっていう方法もあって...」
「今は結論を出さずに一旦Aで実装してみて、困ったらBやCに変えるのがいいね」
つまり、書いたプログラムがどうかという次元ではなく、そう書くに至ったプロセスがどうかという次元のフィードバックに変わるわけです。
エンジニアはこういう知的な会話が大好物なので、おそらく頼んでもないのにめっちゃ教えてくれます(笑
簡単な実装であればPRのコメントに書いたり、時間がかかりそうな実装なら事前に相談したり、どのタイミングで提案を行うかはタスクごとに工夫してみてください。
あるいは、提案までいかずとも「Aがいいと思うけれど、決めかねている」という相談でもアリです。ポイントは、情報が足りない中で自分なりの「答案」を作ること。この答案を先輩に添削してもらうことによって、自分に何が足りないのかが見えてきます。
- 単純に知らなかったのか
- 観点が足りなかったのか
- 比較における優先順位の立て方がイマイチだったのか
自分に不足しているものがわかったら、もう8割がた解決したも同然です。勉強するなり、次に活かすなりでどんどん知識・経験として積み上げていきましょう。
先輩の調査・意思決定を肩代わりできる
先輩がレビューする際、コードだけを見てレビューしているわけではありません。設計を考えたり、脳内デバッグしたり、外部ライブラリのドキュメントやgithubのissuesを読みにいったり、実はいろいろな調査をしています。
提案する形で持ってきてくれると、この手間が大い減ったり、あるいは簡単なレビューだけでPRをapproveできます。
こんな仕事ができると、それはもう評価するしかありませんよね。先輩の仕事をどんどん奪いましょう。これを繰り返していると、気づけば自分がレビューを行う側に回ることができています。
2. 仕様の提案力
仕様は、決まりきったものではありません。最初から詳細含めてすべての要件を文書化するのは難しい(というかそんな暇あるならコード書き始めたほうが早い)ですし、むしろ実装する中で気づくことも多いものです。
「UIでこういうケースが考慮されてなかったな」
「論理的に考えたらこうした方がシンプルじゃないか?」
「今の仕様だとめんどくさい。こういう仕様にしたら1週間早く実装できるのにな...」
こんなふうに、仕様に関わる気づきが出てきたときも、チャンスです。
「今のままだとこのケースに対応できないので、こんな仕様にするのはどうですか?」
「この2つのラジオボタン、セレクトボックスで1つにしたほうがわかりやすいと思います」
「この仕様にすれば1週間早く実装できますが、どうでしょう?」
こちらも、ただ「どうすればいいですか?」とオープンクエスチョンを投げるのではなく、提案する。
仕様の提案をすることの良さは、プログラムの提案力とだいたい同じです。自分の成長につながるし、マネージャーの仕事を肩代わりできる。
ジュニアとミドルの差 ≒ 提案力の差
普段のコミュニケーションで、結構はっきとジュニアとミドルの差はわかります。
ジュニアレベルはオープンクエスチョンというか、意思決定を先輩に委ねたり、「正解」を教えてもらうような仕事の進め方である一方、ミドルレベルになると基本的に提案ベースで話を持ってくる。
最初はもちろん、「どうすればいいですか」「わかりません」でいいです。技術・ビジネス両方の知識が一定ないとそもそも判断もクソもないですし、何を質問すればいいかもわからないので、最初から提案するというのは不可能に近い(1~3年くらいの人が対象と冒頭で言ったのはそのためです。)
最初は、自分が理解できていること、理解できていないこと、困っていることをできる限り言語化して相談すればよいです。ただ、「提案できるようになる」という方向性は、最初のうちから意識しておくといいでしょう。
提案は、「自分で考えて決める」という経験を積んでいった先にしかありません。
まずは、コードベースで提案。
次に、仕様そのものを提案。
この2つがいい感じにできるようになってくると、新人卒業という感じですね。
先輩エンジニアにとってもプロダクトマネージャーにとっても、提案をどんどんしてきてくれるエンジニアはとってもありがたいです。
提案ベースでコミュニケーションを取る
これを普段の仕事で心がけてみてください。