![見出し画像](https://assets.st-note.com/production/uploads/images/126190555/rectangle_large_type_2_37b4aa05a51e2097cd887470f6332cd8.png?width=1200)
CTO Night&Dayから今年実践した10のこと
こんにちは!大晦日ですね!みなさんいかがお過ごしでしょうか?
ナレッジプラットフォーム「Qast」を運営するany株式会社 CTO波多野(@hatamasa1988)です。
すでにAWSさんからブログが出ていますが、9/12-13で福岡までCTO Night & Dayに参加してきました。
去年に引き続き2回目の参加になるのでなんとなく勝手をわかった上で今回は名刺多く持って行ったことで切らすことなく、反省を活かすことができました笑
前回参加した時のnoteはこちらです
今回なぜこんな遅れてnote出すのかについてはこれです。
ただ学んだことを列挙する記事よりも、学んだことをどう活かしたのかとその結果を記載した記事を書いていこう。
— はたの@any inc. (@hatamasa1988) October 18, 2023
CTO Night & Dayからその後何を実行してどう変わったかを発信しようかと思います。実践の定義は少し甘くマインド面、行動面含めて粒度もまちまちです。まだ効果が発揮されているものも少ないですが、、、気楽に読んでもらえたらと思いますー。
Day1
①「エンジニアKnow Who」の準備を始めた
セミナーにてある事業会社では社内のエンジニア口コミサイトを作り、これが非常にワークしているという紹介を聞きました。
Qastでもユーザを検索することができるKnow Who検索という機能を最近リリースしたのですが、ドキュメンテーションなどの言語化でコンテキストなどの細かい情報を残すのは現実的ではないと常日頃から思っていて、知識共有にはドキュメントと対人コミュニケーションの両面が必要です。
プロダクトへの実装も行ったこの思想の部分を社内にも落とし込めないかなーというのと、ちょうどドメイン知識の共有がエンジニアチームの課題として浮上しているのでこれは解決策になるのでは?と感じ現在仕込み中です。
ちょうどこの冬休みの宿題として出題しましたので、今後は活用含めて考えていこうかと思います笑
![](https://assets.st-note.com/img/1703910835618-9oFkH9zU38.png?width=1200)
②アーキテクチャは作り込むよりも意図的に変化させるもの
積読にある「進化的アーキテクチャ ―絶え間ない変化を支える」についてのセミナーからの学び。
・漸進的である
小規模なアップデートを徐々に加える、モジュール化、自動化デリバリー、自律した実験思考のチーム
・誘導的である
目的の充足度を評価する仕組みを持つ
・多面的である
重要なアーキテクチャ特性を選択する
主にマインド面が大きいのですが、自分は割と原理主義者でアーキテクチャや設計においても、この設計であればここもこうあるべきという意識が強く出てしまうクセがありました。
ここでは将来の予測より、変化への適用を重視するという一種の行動特性のようなものを意識した方が良さそうと学び、今は実験的思考を持ってアーキテクチャの意思決定に活かそうと日々マインドを変えて望んでいるところです。
フィットネスファンクション活用については恥ずかしながら自分は初耳だったのですが、ビジネスの特性からアーキテクチャやチーム構成(コンウェイ的な)、更にはカルチャーまでも影響しそうな非常に重要ものと感じ。
来年はどうやってビジネスから一本の線を通すかを思考していこうと思っています。
Day2
③「戦時のCTOとしての振る舞い」を意識する
かの有名なHARD THINGSより「戦時CEO、平時CEO」という話。
これはCTOにも同じことが言えるということで、今が経営的にどの状態なのを意識して行動に落とし込むという話です。
スタートアップはいつでも戦時だとは思います。
弊社カルチャー面や自らのマネジメントスタイルなどを加味した上で行動したいのですが、ここは今は戦時のCTOだと意識した上で意思決定と行動まで行っていくのと、チームへのコミュニケーションについても考えて取り組む途中です。
いつからいつまでが戦時で〜みたいな話ではなく、発生する課題一つ一つにおいてこの言葉を思い出して意識しています。
④「経営陣もバリバリプレイヤー」をやること
実は12月から取締役から執行役員になりました。
この話は代表に自分から取締役とは何か?と問いをし今後の動き方や今必要なことは何かをすり合わせて行った結論として何も違和感ない話ですし、自分的にもかなり良い意思決定であったかと思っています。
弊社では取締役 + 執行役員の計4人で経営会議を行なっており、経営と執行を分離せずに取り組んでいます。
今組織を強力に前進させるのに一番大切なのは手触り感だと思っていて、それによりコミットしたい自身の意思によるものです。
きっかけは300人規模になっても「経営陣もバリバリプレイヤーとしても動いている」「現場感がなくなると強い経営ができなくなる」という大先輩たちからの生の声を聞いたことです。
CTO Night & Dayの後すぐにチームの一員として開発しています。
新機能開発までは時間が取れないにしても、バグ修正、仕様変更、リファクタ、顧客問い合わせ対応(CREエンジニア的な立ち回り)をやっています。
また別でnoteにしたいのですが、CTO直下にシン・カイゼンチームを発足させ、スクラムマスタとして業務の多くの部分でコードを書いています。
下記は一昔前の自分のnote。もっとがんばれや・・・
⑤「Google共有ドライブ」が導入された
これも大先輩から生の声を聞いたのですが、その前から進んでいたPJではあります。
自分が入社した3年半前から共有ドライブはなく、dropboxで運用していたのですが、やはりGoogle系のドキュメントは共有ドライブがないと辛い・・・
何年か前からちょこちょこ提案はしていたのですが、強くハンドリングしていなかったのが反省ですが、今回課題を感じていたメンバーからの提案でPJが発足しついに弊社に共有ドライブが導入されました!
今までなかった会社には所属したことがなく、違和感はありましたが、リソースが少ない中での細部の意思決定と実行を行うことの難しさかなと感じています。
多分自明だと思うので多くは割愛しますが、情報共有のスムーズ差が段違い。ありがたや、ありがたや、、、
有名経営者の誰かも言っていましたが、当たり前のことを当たり前にやることの大切さを久々に実感しました。
⑥「プロダクトを主軸にした組織体制」を強く意識
良くプロダクトを主軸に置くという話は聞くと思いますが、でもどうやったらプロダクトが主軸に置かれるのか疑問を持っていました。
その一つとして、チーム分割するときはプロダクトごとという一つの解かとなと認識しています。
職能(フロント、バック、インフラ、、、、)ではなくあくまでも1プロダクト1チームとしてプロダクト単位を敷くというイメージ。
弊社もエンジニア15人とギリギリの人数で一つのチームとして全て見る形にしているのでチーム分割を計画(go, no go含めまだこれから)しています。
まずはプロダクトを主軸に置いた組織体制を敷けないか検討する中で、プロダクトの境界線についてもしっかり見極めなければと考えています。
⑦「開発生産性向上」を考える
こちらのnoteでも触れているようにチームの生産性を強く意識するようになりました。
特に開発生産性については、コミュニケーション面のみならず技術の力を活用する必要があるので、必要なコミュニケーション面(特に⑥のチーム分割等)を考えながら、技術基盤でできることがないかと考えています。
すぐにChatGPT4とGithub Copilotはチームメンバーに付与しました。
技術基盤についてはすぐに効果が出る部分ではないので、しっかりと割ける分のリファクタを引き続き回しながら長期的なイメージで考えています。
弊社では特に散らばったサブシステムのアーキテクチャとリアーキが長く続いていることでキャッチアップ領域が膨らんでいる部分です。
特にシン・カイゼンチームを発足させた意図はそこも少なからずあり、上記もタスクにして実行しています。
いずれしっかり計画化したものを可視化してチームにも展開しようと思っています。
いつ終わるのコレ!?どれくらい進んでるのコレ!?で疲弊しないように、ちゃんと進んでるよ!を示したいです。
⑧「技術負債に感謝する」雰囲気づくり
恥ずかしがらずに言いますが、例も漏れず弊社にも技術負債はたくさんあります。
それは非線形成長をするチームとプロダクトなら当たり前にあるものですし、さまざまなコンテキストによるものです。
どんなウンコードでも動いていて、収益を産んでくれてありがとうと感謝を込めて爆殺するカルチャーを作りたいなと思います。
ウンコード爆殺は是非とも感謝駆動開発で。
今日はCTO Night&Dayで学んだ『感謝駆動開発』でおよそ6,000行のコードに今まで動いてくれててありがとう🙏
— はたの@any inc. (@hatamasa1988) October 25, 2023
と手を合わせて爆殺させていただきました☺️
⑨「CEOが実現したいことを技術でサポートする」マインド
これは大先輩のCTOの一言。
このマインドをいつから持っているのか、なぜそう思っているのかなどの背景は分かりませんが、CTOは経営陣の中で一番技術に詳しいメンバーとしてバリューを発揮すべきで、経営陣は代表(CEO)が引っ張っていくべきとの解釈でいます。
ここら辺をぼんやりとせずに自分の中で言語化させることは非常に大切かと思いますが、CTOとは何をすべきか?についてうまく言語化できていなかったのかなーと感じます。
「CEOが実現したいことを技術でサポートする」というマインドはどちらかといえばサポーティブな性質の自分にとってしっくりくる言葉でしたので胸に刻み込みました。
実際に代表との1on1でも、持ち寄りの意見を言うことよりも、今困っていることは?どうして欲しいか?など代表が課題に感じていることを解決できないか考える会話を意図的に話したりもしました。
⑩「CTOはみんな大変」というセルフマインドコントロール
CTOの稼働時間をみなさんご存知でしょうか。
200~300時間/月でボリュームゾーンは250時間らしいです。
※チームの大小や厳密は分布は公開されてないのでその時の記憶です。
つまりみんな忙しいということで、忙しいのは自分だけじゃない!というあるかどうかわからない一体感に勝手に包まれています。
さいごに
今回のCTO Night & Dayからは交流もしつつ、何を学べるかの意思を忘れずに参加できたと思っています。
しっかりmidnightしましたが、酒にも飲まれず学び多き2日間でありました!
まだまだ解決途中の課題が山積みなので引き続き取り組んでいこうと思います。
また、共に課題解決に取り組んでいただける仲間を絶賛募集中です!!!!
ではみなさん良い年越しを!!
「ナレッジ経営クラウドQast」を作っているany株式会社で取締役CTOやってます。 会社の成長過程やCTO目線のいろんな投稿を続けようと思います!誰かの役に立てればと思いますので、良かったらフォローお願いします!