見出し画像
Photo by note4221

2021→2022 エンジニア組織を強くするためのCTOの関わり方

hatamasa

any株式会社の取締役CTOの波多野(@hatamasa1988)です。

any株式会社はQastというナレッジ経営クラウドを開発・運用している会社です。
2021年で従業員数で12名、業務委託合わせると30名近くまで人数が拡大すると同時に売り上げも着々と伸びてきております。
そして2021年はlaunchpadで入賞できたことは素直に喜ばしいことでした！！


さて、前回のnoteからだいぶ時間が経ってしまいましたが、年末年始のため久々に執筆しようと思います。

「エンジニア組織を強くする」という壮大なテーマで書いていこうと思うのですが、2021年の振り返りと合わせて書いていきます！
今年もみなさまどうぞよろしくお願いします！

2021年のCTOの動き

プロダクト品質向上PJ開始(2021年5月)

初期のCTOはCTO業もほどほどにして、開発メンバーとして機能開発をガッツリ進めていました。
難しい要件の開発もあり、ドキュメントにまとめきれなかったり、コミュニケーションによってエラーが発生する可能性が高い案件はCTOが自ら時間を取って実装してしまっていました。
もちろんデリバリーを早く行うほど顧客へ価値を早く提供できるのでそこに注力する必要があると判断したためです。

一方メンバーとの関わり方については、
ビジネス要件だけCTOが整理して、それ以外は各メンバーにほぼほぼお任せ（丸投げ）していました。もちろん少ないリソースでスピードを担保するために意識的に行っていたことです。
そこで発生したのが、実装メンバーごとに俗人的な設計/実装/テストになっており、コード品質、プロダクト品質ともに低下しておりました。

その流れから前回のnoteに至った訳ですが、
ざっくりすると「エンプラシフトへ向けてプロダクト品質を向上させる」ために変換が必要であったためです。


CTOコード書くのやめるってよ。をやめるってよ。(2021年7月)

ここからが前述のnoteの後の世界です。
「CTO、コード書くのやめるってよ」という、コード書きません宣言を大々的にしましたが、、、申し訳ないです、ガッツリとコード書いていたことを謝ろうと思います。。。
やめます宣言から2ヶ月くらいで書いてしまってましたね笑

余剰時間で開発する分には問題ないのですが、この場合はアサイン漏れした機能開発、バグや障害、緊急の負債解消のタスクをCTOの時間を使って半ば無理やり行なっていました。
つまり、優先度や目指すスピード感で開発を進めるには他のメンバーのアサインができない状況でした。
よく言うマネジメントのアンチパターンの「自分で抱えてしまってる」状態で手が回っていませんでした。笑

ちなみに、プロダクト開発において一番怖いのは予測できない事象が発生することで、皆さんがよく言う「技術負債」とはこの事を示します。
表面に見えていて把握しているものは技術負債ではあるのですが、実際は「リファクタタスク」です。

予測できない事象が発生するとプロダクトのマイルストーンに大幅に影響を及ぼします。
なので、空いている or 開けられるリソース（CTO）が入って消化することがスケジュールの狂いを最小限にする方法の一つになるという判断です。

このような背景がありCTOも開発のメンバーとしてガッツリ開発を行なってしまっていたと言う事なのですが、10人ほどのスタートアップのリアルはこんな感じかと思います。

裏を返せば、このような事象があっても柔軟にCTOが対応できる状況であったのはいい事ですし、今までのように機能開発を持っていたら本当に対応できない状況になっていたと思います。
その点で、コード書きません宣言（実際は書くのですが）は非常事態への体制を作る上で有効であったと思っています。
「ごめんなさい、コード書いてました」というよりも「非常事態時の開発や保守対応をしてました」の方が適切かもしれません。


プロダクトオーナー(PO)宣言(2021年10月)

PO宣言は主題との関連は薄いので簡単に書きます。

Qastのプロダクト開発は非常に多方面から幅広く意見を集めた上で決定を行っています。
その上で様々な問題が出てきていました。

  • 意思決定のフローや意見の収集の仕方が曖昧であった

  • 意見を聞きすぎて議論が無限ループのような状態になる

  • 後から入ってきた人が慣れるまで時間がかかる

上記を解消するため「プロダクト開発ガイドライン」を定め運用することを決めました。
プロダクト開発ガイドラインには上記の問題を解消するように下記の内容が含まれています。

  • PdM, POの設置

  • 会議帯、意思決定のフローを明確化

  • すぐにアクセスできるようにQastで全社に共有

PdMとPOとの関わりはこちら
イメージ的にはPdMがビジネス、POが開発寄りです。

開発フローの実際の図はこちら
後半での要望発生は手戻りが大きいのでなるべく早めにキャッチアップを心がけます。
また、言うのはガンガンどうぞ！でも反映するかどうかはPdMの判断次第。という決定権限は誰が持っているかを示すことができたと思っています。


あえて拾わなかった問題

2021年はあえて拾わなかった問題があり、そこは今度とも改善していく形となります。
社内のQastにCTOの思想などの記事を残しており、明確な意思表示として示してありましたが、メンバーには伝わっていなかった部分も多々あるかと思い反省しております。
ちなみに弊社の開発は時期ごとにテーマを設定していて、その変遷もあります。

  • スピード最優先(〜2021/4)

  • 品質を担保し、スピード優先(2021/4~)

  • 品質を担保し、スケール優先(2022/1~徐々に移行)

また品質とは「プロダクト品質」を指しており、これはコード品質とイコールではありません。弊社では品質については明確に「プロダクト品質」「コード品質」と分けてコミュニケーションするように心がけています。
（余談ですが、プロダクト品質はシナリオやパターンを書き起こしてあるものをリリース前の受け入れテストとして数人で行なって担保しております）

拾わなかった問題というのは「コード品質」です。理由は「開発スピードを上げるため」です。
ここでまず最初に反論として起きるのは「スピードとコード品質はトレードオフではない」ということですが、まぁ至極同然な話としてあります。
もちろん話の内容は理解しており、開発チームとしても力を注ぎたい分野ではありました。
実際にTDDの和田卓人さんによってかなり強めに提唱されて、話の内容として下記のように言ってます。

「技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。逆に、技術力が高くない人が時間をかけて作ったとしても、その人の技術力以上の品質のコードは書けないだろう」

https://codezine.jp/article/detail/12245

「品質のいいコードには時間ではなく技術力が必要」と言う話でスピードとコード品質を天秤にかけること自体が間違っているという説明になります。

話の裏を返すと、機能開発を行うエンジニアが内部構造を綺麗に書けないとしたら、サポートやレビューが必要となるという話になります。
そこにはペアプロ、設計レビュー、コードレビューなどに追加でリソースが必要なことは容易に想像できるでしょう。

現実問題、エンジニアの内部構造に対する技術力についても趣向性や得手不得手もありますし、スタートアップではインフラエンジニアがフロントを書くなんてことが平気で起きる世界なので個人で担保できるものではなく、教育やペアプロ、レビューなどチームで担保する仕組みが多かれ少なかれ必ず必要なのです。初期のスタートアップ経験者ならみな納得だと思います。

そして更にタチの悪い話が、PMF前のプロダクトは磨ききれていなく、どの機能が刺さる状態かわからない状態。
つまり「作った機能が保守されるかどうかすらわからない」という事も大いにあります。
そして、Qastの戦略上膨大な機能開発が早急に必要であったため、その中で内部構造にリソースを割く判断は行いませんでした。
いち早くユーザの課題とそこに刺さる機能の開発に投資してきました。
要するに、PFM前の非連続な成長を前提とした機能開発ということでした。

これは戦略の話で、しかもかなり強めな意思決定をした認識はあります。
なのでチームの中に伝わりきれてなかった部分や、理解仕切れない部分も多々ありストレスをかけてしまったかもしれない部分が反省です。

2022年からは拾いにかかり、チームとして体制を作ってコード品質に対しても強化していこうと計画しています。
今後は課題にフォーカスした「深さ」の機能開発となっていくはずなので今年に開発する部分はQastのコア技術となる開発が多く、既存機能への仕様追加なども増えていくはずなので保守性、拡張性を担保する必要があるためです。
体制の強化については詳しくは後述する「チーム開発の強化」で記載します。

蛇足ですが、
一応ベストエフォートでアーキテクチャや設計は気にかけていましたが、仕組み化しなければ予想以上にできないことに気づいた一年でもありました。


2022年のCTOのEM業

CTOの注力領域：開発マネジメント(EM業)

開発マネジメント的な役割をまぁまぁ蔑ろにしていたので2022年は開発マネジメント(EM業)をやろうかと思います。

戦略の部分は今まで通りに行い、戦術については試行作しつつ実行していきます。
自分がドップリ浸からない方が良さそうなのは、技術戦術の部分。

理由は

  • 手を出すとキリがなく時間が溶ける

  • PO業やEM業を権限委譲できるメンバがまだいなそう

  • 正直にあまり得意ではない

と言う判断から技術戦術の部分を自分がやるのは適切ではないかと思い、いち早く権限委譲したいと思っています。
かと言って1人に権限委譲するわけではなく、できる限りチーム全体に権限委譲する形にしていこうと思っています。
もちろんアーキテクチャや設計の議論にはCTOも参加して意見を言っていこうと思っています。

そこに入れるようにCTOのリソース配分をします

  • やること

    • PO

    • チーム開発体制の整備(EM業)

    • リファクタ、Issue消化

  • 意思決定には関わる

    • 技術戦術(技術選定、アーキテクチャ、設計など)

  • やらないこと

    • 機能開発

    • 保守運用作業


チーム開発の強化

2021年の機能開発では進め方は開発者に委ねていたため、個人の設計力や技術力に依存した機能開発になってしまっていました。
その分最小限のリソースでスピード感は出せていたのですが、チーム拡大と2022年以降のグロースを考えると、とても今のコードのまま運用していくのはキツイと感じたからです。
メンバは増えたけど開発スピード上がってなくね？みたいな事態を最小限にするためにチームで技術力を共有し合い、一定のコード品質を保つことを目的に、チーム開発に方向転換を行います。

具体的には下記のように変更する予定。まだブラッシュアップ段階なのでやってみてチューニングしていきます。

  • 保守・バグ修正(チームでスピーディーに対応)

    • 今まで：CTOが保守タスクをメンバにアサイン

    • これから：メンバ全員で立候補制

  • 開発(1. プロダクト品質 2.コード品質)

    • 今まで：設計は担当者から相談があればレビュー

    • これから：チームへの設計の事前壁打ちを必須とする

  • PRレビュー(チーム全員でレビュー)

    • 今まで：正社員メンバをレビュアーにアサイン

    • これから：正社員、業務委託問わず修正範囲に知見がある人をレビュアーにアサイン

  • 日次設計定例

    • 設計の壁打ちに全員がリアルタイムで関われるような仕組み

  • issue消化day

    • 技術負債やリファクタタスクの洗い出しと修正を行う日

  • メンター制度

    • 新規メンバのオンボーディングやチャレンジングな機能開発を二人三脚で行える仕組み

他にも様々な仕組みを様子を見て追加していこうと思っています。


エンジニアチームMVV設定

これらの2022年のチームづくりのためにMVVを設定しました。
全社には当然MVVがあるのですが、開発チームとして一体感を出すためにも指針があった方が意識統一が図れると考えたからです。

※現時点で社内に展開しているものをベースとしているため今後変更の可能性もあります

Mission
　チームの力で個人の力を120%発揮させる

Vision
　高拡張性、高保守性、高品質を持つシステムを構築できる
設計技術が高いエンジニアを増やす

Value
　HRTの原則を厳守する(他人への接し方)
　リーダーシップを持つ (自分への接し方)
　本質を見極める(課題への接し方)

全体感としては全社MVVの中にもある「チームシップ」に重きをおいたMVVを定めたつもりです。
設計技術に関してはCTO自身もまだまだ勉強が必要なのですが、弊社っぽくナレッジ共有をしつつ全員で成長していけたらと思っています。
全体に説明を加えたものもあるのですが、まだドラフトであるためここまでの公開で、いずれ固まってきたら別でnoteにしようかと思っています。


エンジニア組織を強くするために

2021年末の嬉しい出来事

Qastの今後を左右する大規模開発案件を若手メンバ2人に任せることにし、技術権限/責任を全てを委譲しました。
CTOはビジネス要件や相談事以外、よほどのことがない限り関わらないという新しい試みでした。
2人で主体的に進める必要がある状況をしっかりと認識してくれて、お互いで議論しながら役割分担を行なって進めている姿や、最後まで考え抜く姿を見ながら2人の成長を感じていました。

その結果、いろいろと困難はあったものの無事にリリースまで漕ぎ着けてくれて今のところ順調に動いています。

CTOとしては任せきることによるメンバの成長と、発揮してくれる能力の可能性を感じられる非常に喜ばしい出来事で2021年を締めくくれました。

  • やりたい得意分野に集中させられたこと

  • 信頼を感じることで能力を発揮してくれたこと

  • 要所での的確なサポートがあったこと

これらがいい具合に重なって、チームとして120%の能力が発揮できていた代表案件になった気がします。
これぞ弊社のMVVにもある「チームシップ」や「集合天才」であると。

これについては、年明けにしっかりとプロジェクトの振り返りを行なって、チームの経験値の言語化と再現性を出せるように進めていこうと思います。


弊社のvalue「any的性格」とは？

Value「大切にする価値観」
集合天才
走りながら考える
全てをシンプルにする
Give&Give
情報はオープンに
any的性格

https://anyinc.jp/

最後の一つ「any的性格」だけよくわからない抽象的な言葉であります。（集合天才がわからない人はググってくれたら一応出てきます→こちら）
初見の人からするとそもそも「any的」が何かもわからないし、ぶっちゃけ内部の人でも定義しきれていません。笑

valueを決定する合宿で、なぜか全体に一体感を与えており、明確に言語化しなくても理解し合えたような空気感があったのを今でも覚えております。（少し美化されているかもしれない？）
それだけに自分は良いvalueだなと毎回思うのですが、あえて空白を儲けることで、メンバーそれぞれが「何がany的なのか？」を常に考えながら進められる言葉に仕上がってます。
考える個人に帰属意識を与える良い言葉だなーと。

「any的性格」を敢えて言語化するとしたら、自分はHRT+Hかと思っています。
エンジニアチームvalueに定めた「HRTの原則」ですが、書籍『Team Geek――Googleのギークたちはいかにしてチームを作るのか』で紹介されています。
謙虚(Humility)、尊敬(Respect)、信頼(Trust)が円滑な人間関係構築に不可欠で、たびたび発生する衝突はこれらの何れかが欠如しているとされています。これに助け合い(Help each other)を加えたものが弊社っぽいかなと思います。
anyに集まった人たちが持っているもので、チームシップを創出するために必要不可欠なものだと確信しています。

同じ苦楽を共にする仲間なので、エンジニアチームvalueに定めたHRTの原則を重視して相互補完的で助け合いの文化を持つチーム作りを目指していきたいと思います。

やるべきことは維持ではなく作っていくこと！
仕組みも合わせて作っていくことなので全員でやっていきたいと思います！

ちなみにビジネスサイド、エンジニア採用ガンガンやってます。
興味ある方はtwitterでもどこでもOKですので連絡いただけたらと思います！

これから関わっていく全ての人たちへ、2022年もよろしくお願いします！

いいなと思ったら応援しよう！

hatamasa
「ナレッジ経営クラウドQast」を作っているany株式会社で取締役CTOやってます。 会社の成長過程やCTO目線のいろんな投稿を続けようと思います！誰かの役に立てればと思いますので、良かったらフォローお願いします！