2023年の反省と2024年の行動指針＜人を巻き込む・学術的なやり方をする・深さを求める＞
2024年の目標・行動指針
〜2033年の大目標
10→100の実現
2024年の目標
- 複数チームの編成ができる体制づくり
- オンボーディングの高速化
- 全貌ざっくりを2ヶ月で把握できるようにする
- 2023/12時点では6ヶ月〜
- 券売機Androidも含む定期テスト体制の確立
- ジョブローテーションを円滑に行う
- 勉強会の定着
- オンボーディングの高速化
2024年の行動指針
- 人を巻き込む
- 学術的なやり方をする
- 深さを求める
2023年の振り返り
そもそもの目標の立て方について
特に大目標だが、2023年中にどこまでやる、という事をきちんと考えていなかった。
つまり、これから10→100を実現していくという考えは正しいが、それがざっくり数年というような考え方だったのがよくなかった。
実際には、我々が目指しているのは3年で2倍なので、10→100が文字通りの実現を迎えるのは、このペースを維持するとしたら10年後である。
もちろんやってみて調整することはあるだろうが、そこがだいぶブレていた、というのを5月〜6月で実感した。
あと、細かくは後述するが最初に挙げている想定手段が結構ずれている。これは結果的な事なので、最終的な評価にはあまり大きくはカウントしない事にした。ただ、初手が悪いという事ではあるので、それはそれで改善が必要ではある。
目標ベース 65/100
総論として、設計・仕組み的な部分では前進して、個別の局面では良いところも悪いところもあったという感じがする。特に戦術的にはだいぶ失敗した部分があった。
その戦術的失敗を見て、今年は自分の動きとしては本当にダメだったなと12/28ぐらいまでは思っていたのだが、冷静に振り返ってみると確かに戦術はダメでも戦略的には目標として挙げた事に向かって進捗していて、なるほどこれが戦略に向かって進むという事なのかと実感している。この歳になって。
複数チームの編成ができる体制づくり 20/40
元々列挙していたものに対して言うと、技術顧問/スポットコンサルは結局のところうまく行っていないし、インターンの復活もできていない。テックリード育成については、ある程度の進捗はあった。
という感じではあるが、複数チームの編成という事については、明確に進捗を感じている。例えば2022/12と比べれば、複数チーム編成的な構造を取れるようになっている。
これにはいくつかの要因があって、まず正社員を採用したこと。次に、リリースフローを整理してGitHub FlowをやめてGit Flowの亜種を採用し、状況共有手段としての会議体もツールも整理をしたこと（正確には会議体が事業部全体で整理されて、それを受けて運用する中でフローを整理してツールを調整した）。CDKや、細かい運用を改めて整理して、開発チーム内で共有したこと。あと重要だったのは勉強会が活発になったことで、勉強会が活発になったのは出社メインの体制と採用による寄与が大きい。
複数チーム編成をするには、究極的には私がやっていることをチームで代替できる必要があるが、私がやっていることを分解してそれぞれやれるようにするよりは、やはり私がやっていることを（スピードや精度はさておき）ある程度は一人でやれるようにして、分解せずに拾えるようにした方がよい。それは単にアプリ開発をしているだけでは身につかない事もあり、アプリ開発と並行して最初からやれる。
そのような考えの一つのあらわれとして、新人教育（オンボーディング）でCDKを使うことにした。
これまで開発環境は全関係者につき共通のいくつかのAWSアカウント内で提供していたが、今後は原則個人に1アカウントを割り当て、そこでCDKを動かして実際に自分で環境を作る、ドメイン管理も（サブドメインだけど）自分でやるという振り切りをすることにした。
作業速度とチーム編成の長になれることはまた違う能力で（というのは当たり前なのだが）、単純なアプリ開発だけではなくて、オンボーディングで運用的なことも含めて全体を把握した上で操作可能にすることを目指す 方がよいだろうということ。
DevOpsの充実、仕様書自動生成の完成 20/30
DevOpsとしてやったことは既に書いているが、「会議体が事業部全体で整理されて、それを受けて運用する中でフローを整理してツールを調整した」。特にリリース内容や新機能に関する情報共有の体制がきちんとできた。（逆に、今までそれなしでどうやっていたのだろうか、と思うが。）
仕様書自動生成については、ほとんど進捗はなかった。ただ、コーディング的にはChatGPTのようなものが出現したし、共有目的としては人間が都度最新を確認して仕様を可視化することでも目的を果たすことができ、かつ仕様を確認する作業は 時間をかける前提ならば 直接的な開発と比べてスケールする。そのため、自動生成にそこまで拘らなくてもよいかなあと思うようになり、結果的に仕様書自動生成は進めていない。
品質向上・QA体制の充実 25/30
これもまずリリースフローの整理が大きくて、リリース前にオペレーションチームの確認を経ることができるようになった。バグ修正や緊急性の高いものと新機能の開発でフローを分けて、確認すべきものをきちんと確認する事について、今までは職人芸っぽくリリースタイミングを私が管理していたが、スケジュールを決めた上で修正内容を全てNotionで共有するようにした。
また、特に採用したメンバーからの機能性や品質にかかるレビューが増え、内容がよくなった。要望と修正内容をNotionで共有した結果、相互のやり取りがよりやりやすくなったのも良い。
体制的には、念願のQA専属メンバーを確保し、Playwrightで自動テストを流せるようになった。
目標に関しては、総じて情報共有やコミュニケーションの設計の部分に根本的な課題があって、それを整理したことで構造が良くなっているが、とはいえ単純なコミュニケーションだけでもなくて、CDKとかNotionとかPlaywrightみたいな具体的なツールや知識の部分もあり、それらが組み合わさって機能した結果ではある。
2024年の目標は、今年の結果を踏まえて「複数チームの編成ができる体制づくり」を軸に再構成した。2023年の他の目標も、「複数チームの編成ができる体制づくり」を軸として解釈できる内容だったので、中目標として「複数チームの編成ができる体制づくり」を据えた上で、具体化したものを挙げることにした。
行動指針の実践度
人に教えを請う
まだまだ教えを請えていない層が確実にあるが、特に今年は単に教えを請う事よりも巻き込むことが単純に不足している事を改めて実感させられまくったので、やはり人を巻き込むようにする。
学術的なやり方をする
プログラマー脳を読んで、そこから大きく得るものがあったが、他全般的に学術的なやり方を徹底できていたかというと、まだできていない事がある。据え置き。
短針だけの時計を作らない
これもできていない事はそこそこあった。ただ、短針だけの時計を作らないことを目指すのは、自分の理解を直接的に伝える上での方針だったが、それを掲げる必要があったのは
- うまく主体的に巻き込むことができない
- 深さを求めるために、まずは理解できる必要があると考えた
からだった。UI的な意味では、短針だけの時計を作らないことを引き続き意識する必要はあるが、それよりも人を巻き込んでかつ主体的に業務を進めることができる事の方が大事で、それらをそれぞれに行動指針とする。
事業など
計画に対して売上を伸ばしていく必要はあるが、手応えはあるので引き続き伸ばしていく。
今年から来年にかけて、いくつかチャレンジングな案件がある（いつものことではあるが）
その他
自分が何をするのが得意なのかというと、結局のところ低レベルクリアのような種類の縛りプレイなのだ、ということがわかってきた。ある種の最適化ではあるが、ゲームそのものを楽しむというよりも、特定の目的に特化してそれを最低限突破する、という事が得意で、日常的な仕事についてもそのような取り組み方をしているところがある。
それで、アプリが深さを必要とする局面ではもっと上手いやり方がある、という事を感じている。
今後の流れ
去年挙げていた
テックリードを採用ではなくて育成で数年かけることにして、10→100を実現するための仕組みづくりを直近でやりつつ、チーム体制を強化する。
この方針はある程度ワークしている。採用の都合で毎週ぐらいこの戦略を説明することになったので、それによって自分自身強く意識することになったのが良かった気がする。これまで主観的に感じていたよりは進捗したように思う。
実際に複数チームの編成でどうやって進めるかという事はまだ課題のままになっているが、これはこの記事で述べた
私がやっていることを分解してそれぞれやれるようにするよりは、やはり私がやっていることを（スピードや精度はさておき）ある程度は一人でやれるようにして、分解せずに拾えるようにした方がよい。
という事が基本方針なのだとは思う。
これまで、単に準備ができていないとか、そういったことで積極的に渡せていなかった運用タスク等について渡していくと同時に、それを 一通り全て引き継いでいく という事を目指して進めていきたい。結局はそれがスケールさせるために根本的に必要な事なのだろうと感じている。
Discussion