この記事は、Business Bank Group Advent Calendar 25日目の記事です。
大手SIerを退職し、Web系スタートアップ企業のCTOとしてJOINしています
元々私自身は大手SIerの研究開発部署に11年半ほど在籍し、様々な新規技術をキャッチアップしながら、現場を支援するという立場にいましたが、今年の1月1日からビジネスバンクグループのCTOとして就任し、ほぼ1年間組織のこと、プロダクトのこと、会社のこと、開発のこと、技術のこと、様々なことについて考え、取り組んできました。アドベントカレンダー最終日に枠をいただき、この1年間取り組んできたことに対する振り返りを書きたいと思います。
CTO is 何?
私自身はこれまでCTO経験は特になく、他の人よりちょっとだけ扱える技術領域が広いぐらいで、CTOが何をする仕事なのかというのもよく分かっておらず、そのあたりは書籍を読んだり、様々な方のインタビュー記事を読ませていただいたり、お酒の席やイベントなどで先輩CTOのお話を伺ったりしました。特に「CTOのやるべきことは何なのか？（翻訳と考察）」については、ちょうどJOIN前の時期だったこともあり、とても参考になりました。
しかしながら、それでも「CTOとは何をする人か」というところについては、未だに固まった答えが出ておらず、今後もこの質問に向き合いながら仕事をすることになるのではないかと思っています。
振り返り
入社〜2ヶ月 → 現状の問題の洗い出しと方針決め
入社して間もない頃だったので、この頃はチームに特に大きな変化を求めることはなく、現状のキャッチアップと問題点を整理する期間でした。この時に感じていた問題を当時の日記から抜粋してみたのですが、以下のようなことを問題と考えていたようです。（ここで書いた問題は、全部私が発見した問題というわけではなく、開発メンバーとの日々の会話の中から上がってきたものを書き留めたものもあります）
- フロントエンド周りの技術スタックが混沌としていて集約する必要がある。それに加えて、そこそこの規模があるのにテストが全く存在しない。自分もフロントエンド周りにとても詳しいというわけではないので、フロントエンド周りのアーキテクチャを一任できるエンジニアが必要。
- Railsの上に載せたオレオレGemやRailsから外れたアーキテクチャが、Railsのアップデートを妨害している。独自フレームワークへの依存度を減らす必要がある。
- 自社サービスをユーザがどのように利用しているか、どれぐらいの頻度で使っているかについて計測できておらず、開発した機能の成功・失敗が分かっていない。可視化手段が必要。
- デプロイ・リリースが安定しておらず、一部のバックエンドジョブが停止して数日気が付かないレベルの問題があった。インフラ周りの監視の強化と安全なデプロイプロセスの確立が必要。
- 定例会議で開発チームの出すKPIが、消化したストーリーポイント数を報告する場になっていて、そのことが開発チームを疲弊させている。またスプリント内で消化するタスクもプロダクトオーナーと合意されておらず、期待値の調整ができていない。
- プロダクトオーナーとのコミュニケーション不足、またプロダクトオーナーが他の業務も兼務しているため、プロダクトに対して十分に時間が割けておらず、プロダクトオーナーの負荷を減らす、またはプロダクトオーナーをサポートする必要がある。
- メンバー間の意見、プロダクトに対する思い、お互いの期待値がバラバラであり、お互いが言いたいことを言えない状況になっている。まずお互いがバラバラであることをきちんと認識し、相互理解し合う必要がある。
- プロダクトの成長戦略についての問題点（ここでは割愛）
また、ここでまとめた内容については、このとき2週間に1回、社長とプロダクトオーナーと私と3人で開かれるミーティングの中で問題点の報告、今後どうしていくべきか、また必要であれば計画の変更のお願いや、予算の割り当てをお願いしていました。小さい組織だったこともあったので、その場で解決することも多々あり、とても助かりました。
3ヶ月目 → 開発リソースの配分の変更
チュートリアル期間が終わり、いくつかの技術課題の解決や、緊急で発生した問題の解決などを経て、メンバーからの信頼を得た(?)後に、本格的に動き始めたのがこのあたりからになります。
具体的には上記で挙げた問題を、どのようにして、誰が解決するか、というところを決めていきました。
この頃の開発はまだ１スプリントの中で、個人で消化するタスクをスプリント会議で申告し、積み上げるやり方だったため、解決するためのリソースを確保するために一部プロダクトの開発を止めるという理解をお願いする必要がありました。
特にインフラ周りの管理が不在だったことが深刻な問題だったので、@bigplantsにプロダクト開発を止めて、インフラ整備・開発者環境の整備に移ってもらいました。元々インフラやDevOps周りの知見が彼にはあったので、どうなるべきかという部分で私の考えを深く理解してくれること、また徹底したこだわりを見せるため、インフラ周りの安定度や開発環境は１年前に比べ、劇的に改善しました。
ここでは成果について詳しく紹介しませんが、以下の記事がおすすめです。
現在はデプロイの仕組みの刷新を行っており、これも近日中に成果が出る予定です。
この頃は大型機能を３機能２人ずつで同時に開発していましたが、リソースが分散していると、どの機能もいつまでもリリースできない可能性がある、という懸念があり、全リソースを１機能に集中させて、まず確実にリリースさせる決断をし、社長やプロダクトオーナーに理解をお願いしました。
また、開発メンバー全員（後にプロダクトオーナー含む）との1on1をこの時期から始めており、メンバー全員と対話する場を作りました。ここで出た問題については相談者１人ではどうしてよいか分からない問題でも、CTOの分掌範囲であれば、周囲に協力者を求めたりすることで、アクションが打てるものも多く、（公開して良い例としては）例えば、弊社の新米エンジニアの@shota_yamashitaが「どうやって現状の開発にキャッチアップしていけばよいか分からない」という相談については、分からないこと、知りたいことについて疑問点を集めて、CTOがそれについて全部回答する会を週に１時間程度作る、という解決策を提案し、二人でやってきました。後に疑問点の解消の過程で、自分も気づかなかったシステムの問題に気づけたり、他の人も参加してくれたりするようになったり良い効果もあったのではないかと思います。
４ヶ月目 → プロダクトのKPIを再定義
@Akiyah がTableauを使って、プロダクトのアクセスログやプロダクト内のデータを集計できる仕組みを作ってくれたため、これまで開発チームとしてスプリントで消化できたポイント数を指標としていた部分を廃止し、プロダクト内のユーザの活用度を数値化したものをKPIとする変更を行いました。
毎月の定例会議で毎月の変動をグラフをベースに議論していますが、前よりも全員が真剣にプロダクトと向き合うようになったと感じています。ただ、数値が事業の売上目標や成長戦略と直結していないという問題があり、関係者全員で合意できるKPIにしないと意味がないな…、という反省もあり、見直し予定です。
6ヶ月目 → 開発のやり方を大きく変更した
６月に開発していた大型機能のリリースがあり、メンバー総力でリリースまで持っていき、一段落した後、開発チームの体制を大きく変更しました。具体的には以下のようなことを行いました。
- 元々QAテストを合わせて４週間で行っていたリリースサイクルをテストと開発を同時に行うことで、２週間でのリリースに変更
- １スプリントを２週間から１週間に変更
- これまで個人の裁量で見積もっていたものをプランニングポーカーで全員で見積もりをするように変更、まだ実現するかどうかわからない先のタスクについては、見積もりが大きくずれることも想定に入れつつざっくりと見積もり、実際に着手する段になった時に、細かい作業レベルで見積もる。
- １スプリントをタイムボックスで管理し、１スプリントで消化できるストーリーポイントを固定した。
- それに伴い、開発の優先度をプロダクトオーナーにより明確に求め、１スプリント内でやるべき内容をプロダクトオーナー含む全員で合意するようにした。
このアイデアについては、以前から@Akiyahから提案されており、私も@ryuzeeさんのブログなどを読んだり、前の会社の同期繋がりで@ikikkoを会社に招いて、チームメンバー数名と壁打ちでのコーチングを行ってもらい、どうなるか分からないながらも、まずはやってみようと導入しました。
結果としては、これは成功で、これまでは機能を開発する時にいつまでに完成できるかという部分について曖昧な部分がありましたが、１機能・１作業のボリュームが可視化されるようになり、１スプリントで消化できるポイントが安定するようになったため、いつまでに終わるかという予測をプロダクトオーナーが立てやすくなり、ビジネスチームと開発チームの間のプレッシャーが緩和された効果がありました。
また、スプリントを安定させるために、@keitatakahashiがプロダクトオーナーの要求を整理する立場に、@Akiyahがスプリント会議や振り返りのファシリテータに入ってくれるようになり、当初課題と感じていた、プロダクトオーナーが多忙で作業負荷を減らす必要がある、という部分を解消できつつあります。
これについては、@AkiyahがXP祭り2018でこれまでの話を含めて発表してくれました。
一方で、これまでのやり方に賛同してもらえなかったメンバーが抜けてしまうという事件もあり、これについては1on1などでお互いの問題点の整理や期待値を調整するなどのアクションは取っていたものの、解決できなかった問題であり、人の問題を扱う難しさを感じました。
１０ヶ月目 → Rails・Angularのアップデート問題に着手
これまでずっと問題だったにも関わらず、開発リソース不足で着手できなかったRails・Angularアップデート問題に着手し始めました。Railsは主に私が、Angularは@tronperidotと@kyokoshimizuがメインで行っています。最終的にはこのようにオープンソースで外部のライブラリに依存する開発を行う以上は最新バージョンに追従しておくのは、単純にサポートされる・されないだけの問題ではなく、そういう部分にきちんと注意を払って開発しているかという点でも外部から評価されるため、他のビジネスを止めてまでも進めるというのは難しいのですが、頑張っていきたい点と思っています。
その他の活動
採用活動
採用とプロダクトの成長はワンセットで語られる必要があり、まだ、うまい方法を確立できていない部分です。来年以降はプロダクトの成長戦略にも関わる予定なので、改めて来年以降はもっとうまくやる方法を模索したいと考えています。
プレゼンス力向上
今年は、RubyWorld Conferenceへの登壇、表参道.rbの会場ホストなどを行いました。来年以降はAngular勉強会のホストも予定されており、利用している技術のコミュニティには知られる会社になれるように頑張っていきたいという思いです。
まとめ
冒頭で、「CTOは何をする人か」という問いかけを自分にしていると書いたのですが、現時点では「他の人の手が回っていない部分については何でもやるが、特にCTOにしか解決できない領域の問題を解決する」のがCTOの仕事だと考えています。
あまり手を動かしていると、すぐにリソース不足になってしまうため、「問題を正しく定義すること」「問題の解決方法についてある程度の方針を打ち出すこと」「正しい方向に進んでいそうか、途中で止まってないかを確認して、必要であれば支援する」ぐらいが仕事の領域で、できれば後は誰かにお願いして、後方支援に回るぐらいがバランスが良いなと感じています。
これも数年経ってくると、青臭いことを言っているなという感じになるのかもしれませんが、まずは現時点のスナップショットとして、残しておきたいと思います。
これで、25日に渡って続いた、ビジネスバンクグループ開発者アドベントカレンダーは終わりです。
ここまで読んでくださった皆様、ありがとうございました。