トラベルブックの技術顧問となって1年以上が経った。今ではそれに加え、ブレイブソフト、HIROKENと合計3社の顧問をやっている。僕が元から持っているオモロキでの「ボケてのバックエンド開発」は継続しつつの顧問業務である。最初は「しんどいかな？」とか「ほんとに俺でいいの？」と感じるところがあったが、今では試行錯誤しつつも機動に乗ってきたところがあり、仕事としての実感も出てきている。ということでバスワード気味に浸透している「技術顧問」というお仕事の実態について、他の顧問さんと違いがある前提で、僕のケースを紹介してみたい。
誰から誘われたのか？など
まず最初に「技術顧問は誰から依頼されるのか？」ってので、その会社に対する役割が変わってくる。大きくは2つのパターンがあるだろう。
- CTOもしくは開発部長の立場の人
- 社長や代表
トラベルブックの場合は当時、全社で10人にも満たない開発も一人だけのスタートアップであった（現在もインターン含めて20名弱程度）。以前から付き合いのあったCTOの高木くんから声をかけてもらったのである。
また、ブレイブソフトの場合はボケての開発でも縁がある社長のえいちゃんから依頼をされた。技術顧問というだけあってサービスなりプロダクトの「制作」に対するアドバイスをするわけだが「誰から声をかけられたか？」によって、その性質は若干異なる。
特徴的なのは社長から声をかけられたブレイブソフトで、技術チームとの打合せや勉強会以外に、えいちゃん本人との話し合いの時間を別途用意したり、採用にまつわるブランディングなども役割として課せられる。またHIROKENでも社長経由であり、技術的な事柄の関わりは少ないという前提なので、新規事業の企画会議の進行補助なども行った。このように誘ってくれる人が、技術系か？経営寄りの人から？によって、業務の比重が変わってくるのは確かだと思う 。
と、もうこの時点で技術顧問は「技術関係ない場合が多い」「各社やることバラバラ」という結論が見えて来ているが続けよう。
ちなみに、顧問として、条件にもよるが、僕の場合は月に2〜3回の訪問を目指している。これもわりとケースバイケースで、議題がホットな時期は毎週通ったりしていた。SlackやGitHubなどのオンラインツールで済むこともあるだろうが、実際に足を運ばないと温度感が分からないし、自分も仕事をしているという実感が沸かないので、このスタイルは崩さないようにしたい。
その役割
もうお分かりかもしれないが、技術顧問の役割は「技術を伝授する」だけに留まらず多岐に渡る。今でこそ技術的な話題が多くなってきたトラベルブックであるが、当初はサービスとしての意識がチーム全体でつくれていない状態だったので、そのサービスの「哲学とは何か？」「どんな可能性がある？」「じゃ最終的に何がしたい？」といったことを話し合う打合せのファシリテーションをしたのが思い出深い。
このように事業のステージや会社規模によっても役割が変わってくるので、その辺りは柔軟に対処していきたいと思う。
さて本筋とされそうな技術的要素においてのロールについて。これについて求められている事を一言でいうと「技術選択への不安を払拭したい」となるだろう。エンジニアなら誰しも経験があるだろうけれど「こういうことしたいんだけど、このライブラリでいいのかな？」といった類いの迷いに対してのアドバイスをする、という形である。ただし、顧問の場合、特に言語固有のライブラリ選択にまではあまり口を出さず、サービスのアーキテクチャや環境構築などといった大きな括りについて方向性を示すことが多い。
例えば、要件として頻繁なテーマはいわゆる「Infrastructure as Code」について。僕はAnsibleをオーケストレーションやデプロイに使っているので「例えばこれ使うと簡単だよ〜」なんてアドバイスを実例を交えながらesa.ioにまとめつつ、その資料を使って勉強会をしたりした。
また、参照実装と呼んでいる「ロジックとして」参考になるコードをサクッと書いて「これでどう？」なんてやりとりもたまに起こる。
僕の場合は経験もあるだろうが、周りに優秀で中には大規模をやっているエンジニアがたくさんいるので、そこからの情報をキャッチ出来る立場である。それを利用して出来るアドバイスもあるかな〜なんて思っています。また、OSSのソフトウェアは以前から覗いていて、こうした「外の世界」をあまり知らない人達に対して、OSSの紹介や実装を教えつつも外を見ることを習慣付ける心がけをしている。
注意したいのは顧問は「答えを出しちゃいけない」ということだ。つい、議論が白熱して「俺の考えが正しいぞ」となることもあるが、それを強要しちゃいけない。顧問である以上、それに対して責任を負えない。「選択肢を広げる」または逆に「選択肢を狭める」ことをアドバイスしながら、答えを自ら出させるのが仕事だと思っている。
チームビルディングへの貢献
以前、こうした顧問業以外に、大手コンサルティングファームの子会社の技術研修を外部講師として社内勉強会を担当したことがあった。その際に、良かったなと思ったことが印象深い。とある製品を子会社含めて3社合同で開発していたのだが、その3社のエンジニアが一同に会することがあまりなかったらしく、僕が担当する勉強会という存在が珍しいものだった。すると、顔が見える場所で、やたら的を射た質問をしてくる方がいる。休憩中でも僕に積極的に絡んできてくれて「〜ってライブラリを家で使ってみましたよ」なんて言ってくれる。すると周りにエンジニアは「彼は出来る人なんだ」もしくは「彼は意識がある人なんだ」という認識が生まれてくる。これは開発が会社として3社に分かれているから、今まで見えてこなかったことだったかもしれない。結果、半年に及ぶ勉強会が終わる日にはみんなで仲良くピザパーティをし、質問をしてきた彼には「XXXの責任者やってくださいよ〜」なんて声もかかった。
このエピソードから実感したのは、外部として入ることの付加価値である。ウマく機能さえすれば、チームのメンバーが見える化するんだな、と。技術顧問も「あえて」社外の人間としてそのチームと関わる。いい感じに自分がキッカケになってチームのメンバーが仲良くなり、全体のパフォーマンスも上がると嬉しいし、そのことを心がけたい。
複数社を見ることでの相乗効果
トラベルブック以外の2社は今年1月から関わっている。来社する手間は当然増えるわけだが、このように複数社を受け持つことによるメリットはだいぶあるなと実感している。簡単に言えば「A社とB社を見ていれば、A社で培ったノウハウを困っているB社で活かすことが出来る」といった効果である。各社の会社の守るべき価値はあるとして、相乗効果を狙える部分はWin-Winにしていきたいし、キャパの許す限り（とはいえ結構もう一杯なんだけど）技術顧問していくのはアリですね。
技術顧問を出来る環境
僕がこうして技術顧問が出来るのも、代表を務めるワディットという会社があるからだし、オモロキもオフィスがなく成果主義だからである。仕事をある程度自由に選択出来る立場の人でないと技術顧問をするのは正直キツいな、とは思うもの、こうした環境はもっと広まってもいいと感じている。
まとめ
僕が今チャレンジしている技術顧問というお仕事について実態を語ってみました。「技術顧問」といえどこのように役割が多岐に渡るために、汎用的な言葉として「コンサルティング」という言葉を使った方がいいんじゃね？とは思いますが「響き」として技術顧問は気に入ってます。現在進行形でエンジニアだから、自分だから、出来ることはあると思うので、いい関係になれるように頑張っていきたいです！
各社勝手に宣伝
トラベルブック
旅行にまつわるいわゆるキュレーションメディアですが、全てオリジナル記事で質が高く、今後も旅行やお出かけをアシストしていきます。インターンのエンジニアを募集してます。
ブレイブソフト
スマホアプリの開発会社です。ボケてのモバイルアプリもパートナーとしてつくってもらってます。
HIROKEN
士業というリアルなところとつながりのある会社です。僕も関わっている新規事業が面白そうです。わくわく
PS.
Podcastやってます！夫婦で聴いてる人達もいるらしいです！