5年技術顧問の経験で出来た自分なりの型

はじめに

技術顧問という役割もだいぶ普及してきましたね。一概に技術顧問と言ってもやっていることはそれぞれぜんぜん違い、普通にコードを書く人もいるし月に一回ありがたい講演をする場合もある。自分が今まで7社技術顧問してきてある程度やり方というか自分なりの型が出来てきた。
技術顧問って何をするんですか？聞かれることもあり、もう一社ぐらい技術顧問をしてもいいかなと思い営業資料代わりに自分なりの型をこの記事でまとめている次第である。

技術顧問を採用する利点

● 第三者視点の提供
- 第三者視点外の立場で俯瞰して評価したり、他ではこんなことをやっているなどの情報を付加価値として提供できる
●CTOの壁打ち
- とりわけ小さい組織のCTOは結構孤独、大きい組織ならPdMやPM、テックリード、エンジニア採用など分業するところを兼ねる事があり。意思決定前に相談する相手が欲しい
- スタートアップのCTO同士で話もできるがビジネスに深く踏み込んだ話はできない
- NDA契約を結んでいる技術顧問はこの隙間を埋めるのに丁度いい

技術顧問で支援しても効果が得られないケース

何社も技術顧問をしているとうまく行った会社もあるし、うまく行かなかった会社もある。
うまく行かない場合は第一にCTO(相当の人を含む)ならびCEOが会社のビジネス・プロダクトに対して熱があるかどうかが鍵である。特にCTOがやる気を失ってる場合は技術顧問の支援範囲ではどうにもできない。社外CTOをするとかCTOの挿げ替えるなど施策は思いつくが大なたを振うことを検討せねばならない。

期間

大抵の企業で技術顧問として支援する期間は半年から1年
このように意外と短い。短いことを若干悩んだ時期もあったが現在はこれぐらいの長さが丁度いいのではと思っている。
なぜなら技術顧問先の組織的・技術的問題をなくすのがオレの仕事である。つまりオレの仕事をなくすのがオレの仕事なのだ。
長期的にCTOとの定期的な壁打ちを1ヶ月に一回ぐらいできると、軌道修正が出来たりこちらが提供する新しい情報も入れられるので利点があるだろう。

最初にやること

技術顧問として支援する際に最初に、CEOやCTOなどキーマンと現在の開発組織についてKPTを実施する。
まずKPTのProblem中心にあげてもらう。Keepは良い点も挙げないと問題ばかりなってしまうし、よかったこと再認識してもらうきっかけを作る。
KPTを行う際はいくつか問やテーマを与えてファシリテーションを行うので、そこから想起する内容を書いてもらう。
その後Problemの優先順位をつけてもらい、優先度の高いものからTryを考えていく。

入り始めに気をつけていること

最初の1ヶ月はよほどクリティカルなところ以外は大きい改革は進めない。CXO以外の人からすると、なんだかよくわからない奴が定期的にやってきて外から会社を引っ掻き回す事になってしまうので反発しないまでも嫌々従いモチベーションを下げてしまうことになってしまうからだ。

ダメダメなプログラムだとしても、それがダメであることは開発者自身が認識していることも多く、スケジュールや人手不足などの様々な理由でそうせざるを得なかったりと物語がある。それをいきなりやってきた外野がこれはダメだと突きつけるのはあまりにも敬意が足りない。

技術的・組織的な施策でも、提案し実行してもらうためにも、理想の形を定義して、そこから現状とのギャップを埋めるために少しづつ段階を踏んだ施策を実行するように心がけている。この辺りはMAYA理論の影響を受けている。気になる人はググってみてほしい。

特に技術的な問題を対応を求められている場合は、早期に技術的に担保があるところを開発者に見せて、技術的なスキルを認めてもらうことも気をつけている。こちらはいささか動物的なアプローチで、要はこいつ口だけじゃないなと信用して貰う必要がある。

技術顧問の支援内容

今まで支援指摘内容をカテゴライズしてまとめてみた。概していつかやらなきゃなと思いながらも目先の機能拡張にリソースが取られて対応できていない課題や、技術的負債をCTOやテックリード、PMが手を付けられていないところを分解して優先順位付けをサポートし支援していることが多い。

エンジニアリング組織的な支援内容

●プロジェクトマネジメント
- エンジニア組織体制の相談
- 開発ロードマップ作成支援・レビュー
- エンジニアとの定期的な1on1
- KPIとKGIの策定支援とレビュー
- オンボーディングから次に何をやってもらうかの相談
●生産性の向上施策支援
- 1週間どのタスクをしていたか時間を計測してもらう
- 定期的なミーティングの種類と内容
- ミーティングを短くする、無くす、参加メンバを減らす
●エンジニア採用
- エンジニアの紹介
- 採用面接代行
- 転職サービスの選定
- 転職サービスの募集記事レビュー
●スクラムの段階的な導入
- スプリントの導入支援
　- いきなりスクラム開発で必要なことを全部やると軋轢が生まれる
　- 現状から少しずつ変える。朝会をやっているのであればそれを少しデイリースクラムに寄せる。良かったことを入れるようにするとか。時計を使うようにするとか
●できるだけ自前で作らないことを教育
- SaaSの利用
- ライブラリをよく探す
- 自前で作らないで仮説検証できないか、実装は検証後に判断するように出来ないか

技術的な支援内容

●設計
- 設計のレビュー
- ライブラリの選定
- パフォーマンス向上
- パフォーマンス測定ツールの導入
- 大事なのは修正する優先度と、許容するレスポンス速度の目標値を設定する
- 問題箇所の修正(N+1問題や遅いSQLの修正、データベースのパフォーマンスチューニングなど)
●プログラミング
- コードレビュー
- ペアプログラミング
●セキュリティ診断
- OWASP ZAPを用いてレポート提出
- 緊急・なる早・現状維持の判断と開発スケジュールへの組み込みサポート
●インフラ
- AWSの構成の見直し
- AWSのコスト見直し
●データベース
- データの種別、頻度にによるDBMSの選定
- モデルの見直し
●問題を発見できるようにする
- クラッシュした際に通知するようにする
- 500エラー発生時に通知するようにする
- ログにユーザIDをつける
- ユーザの問い合わせ時にどのユーザかわかるようにする施策の提案
●開発フローの調整
- Gitのフローを整える。Githubフローや、Gitlabフロー
- GithubのIssueテンプレートやPRテンプレートを作る
● 静的解析ツール導入支援
- Linterは入れてるけど使ってないとかをなくす施策の提案
- 静的解析ツールの指摘が多すぎて無視してしまう状態の改善
●スマフォアプリのUIのレビュー
●ツールの相談・選定

技術顧問の依頼・相談は下記SNSからご連絡ください。
Twitter:https://twitter.com/kon_yu
Facebook:https://www.facebook.com/yusuke.kon.79