エンジニア・テクニカルディレクタ・コンサルタント

　自分によく相談が来る仕事は大きく3つあると思っている。勿論綺麗に別れるわけじゃないけれど。

　『森岡さんはどういうことをお仕事にされているのですか？』と言われると毎回困る。困るので最近やった案件や、主だった案件の話をする。

　そうすると『はーすごいんですねー。でも幅が広すぎて良く判らないですね』と言われる。すると自分の役割の軸で説明しなきゃならなくなる。が、技術者の話はなかなか説明が難しく、どうやったら端的に説明できるかなーと（自分の説明に納得がいかない時など）よく考える。

　で大きく3つ業務がある、という最初の話に戻る。大きく3つの仕事の役割を兼ねてやることが多い、という説明から入る。大きくはエンジニア、テクニカルディレクタ、コンサルタントと3つをやっている。

エンジニア

　文字通りエンジニアだ。エンジニアの仕事は『実装すること』だ。

　『設計するのもエンジニアの仕事やんけ！』と言う人も言うだろう。尤である。エンジニアとしてアサインされても設計業務はワリとある。

　ただし、テクニカルディレクタも設計はするので切り分け基準としてはあまり宜しくない。設計・プランニング業務は大体どこのレイヤでもある、と言える。つまりテクニカルディレクタはテクニカルディレクタの領域で、エンジニアはエンジニアの領域で設計を行う。なんだったらコンサルタントもプランニングする。この場合のプランニングは企画じゃなくて計画のほうだ。これも設計にあたる。

　最終成果物に対して実装を行うのがエンジニアの特徴である。ものづくりの最前線。プロダクトサイドから見た場合のフロントマンだ。

　優秀なエンジニアとは？という話もそのうち書くと思うが、それはまた後日に（この手のテーマを書くときに自分でも忘れてしまうのだが、これは日記である）。

テクニカルディレクタ

　テクニカルディレクタはあまり馴染みのない業界の方も多いかもしれない。特定のプロダクト、プロジェクトの技術責任者である。要するにエンジニア、あるいは様々な技術を束ねて他の視点を持った人（デザイナとか経営者とか）と喋る人だ。

　特定の技術に根差したサービスやプロダクト開発チームだとチームリーダーや業務内容別に社員を分けている会社の、エンジニアリングの部門のマネージャなどもテクニカルディレクタ業務を遂行している。

　『技術の翻訳者』という説明のしかたをする人も多いが、本質的には『実現可能性の最大化』というのが主な業務だ。精度を上げる仕事である。そういう意味ではプロジェクトマネージャにも非常に近い役割も持っている。工数や開発スケジュール、機材費を弾くのも仕事である。

　プロジェクトマネージャと違う職種としてある理由は2つある。

　1つは技術がブラックボックス化しやすいために目利きにそれなりのシステムを捉えるスキルが必要だということだ。プロジェクトマネージャは人とお金を見る事に特化しているが、テクニカルディレクタはシステムやツール、技術など、プロジェクトマネージャとは別の視点からプランニングや設計を行う。この点では『技術の通訳』的側面が大きい。

　もう1つの理由も技術がブラックボックス化しやすいことに起因する。技術選定の内容によっては『当初のプロダクトのクォリティを上げる』ことや『コンセプトからズレるが大幅にプロダクトのクォリティが上がる』ことがよくあるため、プロジェクトマネージャよりもクォリティ面でのプラス方向へのコミットが多いことだ。

　例えば、プロジェクトマネージャ的アプローチだと『普通に計算したら工数2人月かかってしまう』ものを安くする必要がある場合、工数の安い人を探す、というアプローチをとる。

　テクニカルディレクタの場合は『既存のシステムを購入して流用することで1人月に圧縮できないか』とか『2人月の作業を0.5人月でシステム開発してあとはバイトにオペレーションさせて安く上げられないか』とか考えるわけである。

　プロジェクトマネージャは減点方式になるが、テクニカルディレクタはそもそも技術を相手にするので加点とか減点とかいう枠で測れない振れ幅の広さがある、とも言える（勿論良い事ばかりでもないだろう）。

　少し脱線したがテクニカルディレクタは『クォリティを上げつつ、実現可能性を最大化する』のが仕事だ、ということだ。これはつまりターゲットが決まっている、プロジェクトがもう存在している前提である。なのでテクニカルディレクタ業務はプロダクトやプロジェクトありきだ。

コンサルタント

　最後がコンサルタント業務だ。この前も書いたがコンサル会社がやっているコンサル業務とは違うので、文字通り『相談』の業務だと捉えて欲しい。

　これは文字通り会社の相談に親身になって乘る、ということである。いや、馬鹿みたいなことを言ってるように聞こえるかもしれないが、これは明確に上2つとは違うのだ。エンジニアは何を作るかはっきりしているし、テクニカルディレクタの時はプロジェクトがはっきりをある場合にワークする。

　ただし、そもそも『このプロジェクト、御社的にあまりハマってなくないですか？』とか『経験上、その予算では作れないのでそのプロジェクトは検討はしても良いけど実現しないと思います』みたいな話をしなければいけない場合が結構あるのだ。つまりテクニカルディレクタ業務以前のプロジェクトの妥当性の話だ。

　会社のプロジェクト発足の是非やプロジェクトのゴール設定、プロジェクトの予算取りなどがここに入る。特定のプロダクトの会社だとCTOなどがこの業務をしていたりする。技術的な知見、モノづくりの知見を使って会社の経営やプロジェクトの発足など、メタものづくりをするのがここだ。

　何度も言ってる通り、テクニカルディレクタ業務の『どうやったら作れるか』『どうやったらクォリティが上がるか』よりさらにマクロな視点で話をするので意識しないと話がズレやすい。『作らないほうが良いですね』はテクニカルディレクタのロジック的にはあり得ない発言だ。

　つまりコンサルタント業務は『クライアント（もしくは自分の会社）は何を為すべきか』という話を技術者の視点を持ちながら行う、というのが主な業務だ。