私、松山は、自分が経営している会社であるsiroとは別に、BASSDRUM（ベースドラム）のメンバーとしても活動をしています。日頃自分の肩書きを「テクニカルディレクター」とはあまり言いませんが、ベースドラム内では紛れもなく「テクニカルディレクター」のひとりとして、存在しています。

この「なんとかの松山です」という肩書に悩む人のボヤキシリーズとして、テクニカルディレクターについて語ってみようというのが今日の記事です。

テクニカルディレクターとは何か

「エンジニアの松山です」という名のり方が一番使ってるかもしれませんが、エンジニアとテクニカルディレクターは役割が違います。ただ言えるのは、テクニカルディレクターは本来は「もともとエンジニアとして仕事していた人が成って担う仕事」です。

ここからさき、ベースドラムの見解とも違う話になるかもしれませんが、「松山の考えるテクニカルディレクター像」について語りますよ。

エンジニアとしてもまじですごい

もともとずっとエンジニアとしてやっていて、スキルもトップレベルだったりすると思います。ただし、「エンジニア」とひとくちで言っても、ジャンルは様々ですので、デバイス開発のスペシャリストがいたり、フロント寄りのプログラミングのスペシャリストだったり、サーバー寄りのプログラミングのスペシャリストだったりするわけです。また、エンジニアの役割のなかで、重要なものの一つは「設計」だったりします。プロジェクトの初期の段階で、どういう実現の仕方をするのかという「設計」をするのは、最終的にコードを書く作業とは職能が違うわけですが、特に小規模な会社だと、いきなり設計のスキルを積む人よりも、実装のスキルを経ての設計というケースが多いと思います。

設計者は先が見える人

そして、「設計」という作業は「できるかできないか」という判断をする役割も担います。いわゆる「フィジビリティチェック」ですね。それは、「技術的に可能か」ということもありますが、「コスト内で実現できるか」という目線もあります。通常クライアントワークというのは、予算枠があってその中で何かを作ることになり、かつ納期というデッドがあるので、「予算内で扱える技術で納期までに実現できるか」ということを考えなくてはいけません。

そして、一般的な話からややそれますが、私がやってきたような展示などの演出の場では、さらに「それは魅力的なのか」という部分も重要なポイントになります。技術的に難しいことを実現したとして、それが魅力がなければ、意味がありません。

例えば、メーカーの展示でなにかをアピールする場での展示演出を企画してる場合に、「インタラクティブな展示があれば目立つだろう」という想定のもと「こういう展示を企画したんですが、この予算と期間で実現できますか？」と問われる立場であるとします。でも、それが実現できるかどうかという判断とセットに、「実現できますよ。でも面白くないですよ！」と言えてしまう経験を持っていたりします。そりゃそうです。年がら年中展示演出のシステムを開発してるわけですから、「それを作ったら面白いかどうか」ぐらい想像ができてしまいます。

（自分の場合はそこに関心が強いので特にわかる。テクニカルディレクター全員のスキルではないと思いますが、便宜上書きました）

技術だけではない

ここまでの内容でなんか見えてきた気がします。

「あれ、これってテクニカルディレクターっていう人たちは、技術に強いだけじゃないっぽい」

例えば、コストが収まるかどうかというのは、自分が扱う範囲を超えて企画の実現に必要な様々なコストの感覚がないと判断できません。仮に自分のパートの範囲が想定よりも安く収まったとしても、運用コストが想定の３倍かかるとしたら、全体のコストにはハマりません。でもシステムの操作性を向上させるなど、運用コストを減らす努力をしたら、全体のコストにハマってくるかもしれません。

とかなんとかで、「様々なスキルを持っていて、かつテクノロジーに精通してる人」がテクニカルディレクターなんだと思います。

つまり、「〇〇 x テクノロジー」みたいな状態ですね。

問題解決能力が尋常じゃない

エンジニア思考とでもいいましょうか。エンジニアの人たちは日頃から「デバッグ」という修行的作業と向き合っています。何かを設計し、それを実装したんだけど、うまくワークしない。そんなときに問題を見つける作業が必要になります。

それは「問題の切り分け」です。

例えば、作ったものがソフトとハードが組み合わさっている場合、「ハードによる問題なのか、ソフトによる問題なのか」を切り分けないと直すべきバグはみつかりません。両方ダメな場合もあります。それぞれは単独では良くても、組み合わせると問題が起こる場合もあります。

こういう問題を切り分けるときは、超ロジカルに可能性を潰していく作業になります。ここでうっかり感情に流されてしまうと、本当の問題にたどり着かず、何日もさまようことになります。なので、経験からくるカンはありつつも、ロジカルに切り分けていく冷静さが必要です。

この「問題の切り分け能力は、実は様々な曲面で使える」んです。

今でこそ、サービスの企画や商品開発、ソフトウェアの開発などでも一般的にやられていると思いますが、「小さくスタートして価値を検証する」というやりかたも、これはロジカルな積み上げ手法です。感情的になってしまうと、以下のようになります。

「この企画は最高に違いないから、最高のクオリティで作ろう！一刻も早く見たいから明日から全力でやろう」

でもですよ、もし作りきったあと完成レビューをしたときに、「全然良くないんですけど...」みたいなことってよくあるんですよね。当事者は魔法にかかってて、そこに気がつけなくなってるみたいなやつです。なので、「価値を検証するために最小限のところで切り分けて作る」。小さく分けすぎてもだめです。価値が判断できないと意味がないので、その切り分けのポイントをみつけるのは、とてもセンスが必要な作業です。

他にも企画が長引いている仕事なんかだと、話がディテールに行き過ぎて、全体像を見失うみたいなことがあります。例えば「この演出って技術的に実現可能かな？」みたいな話を延々し続けてしまって、あとになって「その演出って効果的なんだっけ？」みたいな手前のところで、かけちがってるみたいなこともあったりするので、企画を見つめる視野を狭くしたり広くしたりを日頃から心がけています。それは、まさに問題に気がつくスキルの延長だったりします。

実際、ロボット系の開発仕事で、そこにいる全員が「これはソフトウェアの問題に違いない」と設定値とにらめっこしてるときに、自分だけが「これは配線の問題かもしれないぞ」と疑い、問題を見つけて解決したことがあります。別の可能性を常に考えていかないと本当の問題は見つけられません。

リーダーシップ

書くの忘れてました。「テクニカルディレクター」ですから、そりゃディレクション能力が必要です。前述の通り、様々なスキルをもちつつ設計の役割も担いつつフィジビリティチェックもして、なんならデバッグでエンジニアのケツを拭きつつ、チームを引っ張る能力も問われるわけです。

ここは、かなりファジーなやつで、相手は人です。エンジニアを束ねないといけません。まぁ、僕に言わせれば、その人の個性というのはコードを読めば一発でわかりますので、その人に合わせてうまく付き合っていけばいいわけです。（今これを読んで嫌な気持ちになった人は、僕のチームメンバーですね）

そしてディレクターは、プロデューサーやクライアントとの会話も仕事になってきます。こちらも人と対峙する仕事ですね。機械を制御するよりもこっちのほうが難しいよねなんて思ってるのは秘密です。

複合的なスキル、そして問題解決能力の高さ、リーダーシップ

そうです。結構こういう人っていろんなときに必要ですよね。それが、テクニカルディレクター！（言い過ぎてたらすいません）

そして急激にまとめて今日の記事はここでおしまい！