技術書を読むことと素振りをしておくこと

メンバが組織的にはかなりチャレンジな投資になるIT企画を立ち上げて、経営陣向けにプレゼンをしていたが、会議の終わる時間になっても戻ってこない。プレゼンが長引いていて次に予定していたミーティングに遅れるとslackは入った。

様子を見に会議室を覗いたら、ミーティングは終わっていたが、助けを求めるような顔つきで自分を見る。話を聞くと、出直しするように言われたと言い続けた後、もともとミーティングの予定を入れていた時間と自分の身体を欲しいという。

どう巻き直すか、作戦会議をしたいのだという。会議室を覗いた時点ですでにどうするか事後の策を検討を始めていたが、企画提案チームだけでは打開策を見いだすことが難しと感じたらしい。

メンバや他のエンジニアから相談を受けると、まずはオーソドックスに、ありがちな対応策やアイデアを考える。ちょうど、事業企画（IT企画）の流れを個人的に整理していたこともあり、ありきたりな流れならこんな風にとホワイトボードに書いていく。そこに今回の企画テーマのエンティティを書き加えながらどう進めるかをイメージアップしていく。

ありきたりだからとても手順が多いし、一見、時間がかかるように見える。だからこれを全部やる必要があるかと問い直したり、ショートカットをした場合の揺り戻しのリスクがないかを問いかける。

時間軸的にはミーティングを始めてから、企画チームの思いのずれを感じる。自分はこれまで断片的にしか聞いていないので同じようにずれている。それを可視化しようとエレベーターピッチのテンプレを人数分コピーして配り、それぞれの目的を書いてもらう。

とにかくホワイトボードがあって、書いていたとしても同じ言葉を違い意味合いで話したり、共通概念のないところでいくら書いてもプロトコルは一致しない。

同じフレームワークで同じセンテンスの上でどう捉えているか、どうイメージしているかを言葉にしなければ何も始められない。

目的は
何を
どんなアーキテクチャで

この3つは一番大元になるものだから、最初にそれぞれがどこに立っているかを知ってから始めないとまたプレゼンを失敗してしまいかねない。そういうときに、技術書にあるフレームワークやテンプレをさっと出して、それを使うことは効果的だ。

それと、技術書を読んだら全てはないにしろ技術書を読んだ目的のことについては実際に自分で使っておくことだ。頭の中だけではそれこそ机上でしかなく、いざという時に手が止まる。それは書いたりタイプしていないからフレームワークと脳内の言葉が紐づかないのである。なんとなく感じを掴めるまで、数回でも良いから使っておく。プログラム言語なら写経をするのと同じである。コードを打ち込んで実際に動かしてみる。エラーは取り除く。動けばわかった気になるし、フレームワークに書けばそれで良いか感覚をつかめていないか感じられる。

企画提案は、スポンサーである経営陣に騙されてもらうために行うのである。であるから、提案する側にやりきるための自信がなければならないし、そのための裏付けがなければならない。エンジニアならそれは企画でのアーキテクチャに他ならない。

第一、やったことがないITなんてやれますなってエンジニアなら言い切れるはずがないのだから。