"技術顧問" のお仕事
"技術顧問" 👨🏻💻ブームだな〜と思ってて、ソフトウェアエンジニアや一定の経験を積んだ人たちが、他のそういう知識・経験の無い会社を副業や業務委託という形でサポートしていくのは良いしどんどん広まると良いな、というのがある一方で、"技術顧問" という言葉が独り歩きしていて、
・それってどういうことをやるひとなの？
・(エンジニアにとって)自分が技術顧問になってほしいと言われたらなにをやるの？
・(技術顧問が必要かも? という経営者にとって) 自分たちに必要なのはどういう人達なのか
などがあまりハッキリしないままで、今現在、仕事の内容も単価もおぼつかない状態で混沌💥としていると思います。
など、かつてのCTOブーム、VPoEブーム、エンジニアリングマネージャーブーム等同様(まぁ、ブームっていうのは若干自虐的揶揄も含みつつではあるものの) 言葉が独り歩きして爆発的にそれっぽい人が増える、というのはよくあることだし、そこから徐々に収束していくのも見てるんで、それはそれでいいんですが、最近よくあるものをざっくりパターン分けすることによって、IT業界全体が適切な人が適切な価格で適切にお仕事こなせるようになっていくと良いね、と思うわけです。
あ、最初に、とはいいつつ別に、"お前らの技術顧問は間違っている" というのはどうでも良くて、まあ要するに、お仕事を請けたり依頼したりするときには、何を期待しているのか、何を提供できるのか、をはっきりさせるのが、お互いが幸せになれるよってだけの話ではあります。🙏
大きく分けて2つのタイプの技術顧問
ざっくり現在観測範囲では、
・経営コンサル型の技術顧問
・特定技術領域特化アドバイザー型の技術顧問
が存在しています。
(それを "技術顧問" と呼ぶべきなのかどうか、は一旦別議論としても良いとは思っていて、単にそういうものを観測しているという話です)
それぞれがどういう感じの人なのかというと、
経営コンサル型の技術顧問
その会社のCTOや、CTOがいない会社のCEOにアドバイザーっぽく入って、メンターになったり、あるいはコーチングしたりしながら、開発そのもの・アーキテクチャ・セキュリティなどだけでなく、開発組織のマネジメントや採用や、周辺チームと開発組織の関係性づくり、IT全般統制など、幅広く技術組織とそれに関わる経営をどうやっていくのか、について色々顧問するやつです。
特定技術領域特化アドバイザー型の技術顧問
最近、プレイヤーとして増えているのはこっちのタイプなんじゃないかな、とは感じています。
比較的大きな会社でテックリードを務めるような、特定技術領域に非常に詳しい人が、その領域で困っている会社にアドバイスに入るケース。例えば、サーバーエンジニア居て、CTOもサーバー系の人で、サーバーサイドとインフラはバッチリなんだけど、クライアントアプリは業務委託を中心に作っていて、もうちょっとどうにかしたい、みたいなケースで、iOSのスペシャリストにアドバイザーになってもらう、みたいな。
それぞれの単価感💸
これも一概には言えないけれども一般論として、
・経営コンサル型 → 経営コンサルの単価に近い (が、それよりはもっと安い 単価(h)数万~1x万 とか)
・特定技術領域特化型 → ソフトウェアエンジニアの業務委託の単価に近い (が、それよりもっと高い 単価(h) 1万~1.x万とか)
という感じの雰囲気がしています。
例えば、比較的大きな会社でめちゃくちゃAndroid開発経験積んでいて詳しい、テックリードやってます、みたいな人が副業でどこかの会社週1回1時間アーキテクチャやリファクタリングについてのアドバイスを、1万ちょい/h 単価のx4 → まるめるとざっくり5万でやってます、みたいな。
コレの単価の傾向はなぜかと言うと、経営目線で、ビジネスコンテキストを理解したうえでアドバイスができたほうが、課題解決の領域が広く、影響度が大きいからです。(あとそもそもそういう経験／知識があってアドバイスのできる人がレアリティが高いというのも単純にあります)
例えば、「開発がスケジュール通りにいかない」という悩みを抱えた経営者がいたとして、その会社が「元々立ち上げ時に外注を使っていて今は内製なんだけど、なんかレガシーな書き方をしてるコードが最初納品されてて、それをもとに改変してきているから、すごく困ってるんです」という状況だったとして、なるほどじゃあどういう方向性でリファクタリングすればいいかを考えましょう、というのはスタート地点になるけれども、実際に話しを聞いてみたら、課題の本質はもっと別のところにあった！みたいなこともザラで、その場合、いくらリファクタリングしてもちゃんと開発が進むようにならないんですよね。
(例えば深掘ってみると「実はプロジェクトマネジメントがうまくいってないのが原因だった！」とか「ビジネス側の要求と開発側の要求がうまく話し合われておらず経営側からの意見と開発側からの意見が全然違っていた = 結局コミュニケーションが問題だった」とかも、よくあるケース)
期待していることと提供できることのマッチングが重要
まあ何度も言うですけど、これが重要という話です。
ここの期待値と単価がハチャメチャになるとあまり良いことにならないですね。
一般的に、特定技術領域のアドバイザーがうまく機能するケースは、社内にCTOとかが既にいて、でもCTOといっても自社のすべての技術領域に詳しいわけではないので、XXXについてはワカラン、じゃあその領域誰かアドバイザーになってくれないかな、みたいな、課題となっている領域の分解がある程度明確であるケースかな、と思います。
逆に、CTOになりたてです、スタートアップ初めてです、CTOいません、みたいなケースだと、当然、いろいろな経験積んだ元CTO、みたいな人とかに経営コンサル型のアドバイザーをやってもらわないと、機能しないかな、と思います。
というわけで、何を求めてるんだっけ? みたいなところが重要かなーと。
自分が "技術顧問" をする理由
まとめに入る前に一応自分のスタンスなんですが、ありがたいことに、自分にもオファーをいただくケースもあり、お手伝いさせていただいている会社もあります。
自分の場合、ソフトウェアエンジニアを軸としてキャリアを始めつつ、起業したり、M&Aされたり、CTOしたり、ものすごい採用したり、VPoEしたり、IPOしたり、などなど、(いや、本当にありがたいことに)いろいろな経験をさせてもらったので、若いスタートアップ、比較的、CTOや経営陣自体がそもそも経験が浅かったりワカランことばかりや！みたいなところに対して、いわゆる経営コンサル型の技術顧問をしています。技術経営コンサル、みたいなイメージですかね。
少しでも、彼らの意思決定の精度が高くなったり、try-and-errorのerrorの数を減らす・失敗をスキップできる状況が作れたらいいな〜と思いますし、結果的に、少しでも成功するITスタートアップが増えると楽しいな〜と個人的には思ってます、ので少しでもお役に立てればと思ってやっています。
まとめ
・技術顧問っていっても色々あるよね。
・お仕事を請ける場合、依頼する場合は、期待値、提供できる価値、それに見合った単価で。