2021年の反省と2022年の行動指針＜学術的なやり方をする・体系的なやり方を整理する＞
もう既に元旦をだいぶ過ぎてしまったが、2021年の振り返りと2022年の目標・行動指針の整理をする。
2022年の目標・行動指針
2022年の大目標
10→100の実現
2022年の目標
- テックリードを3人入れる（入れないとしぬ）
- 1on1の定着
- DevOpsの充実、仕様書自動生成の完成
2022年の行動指針
- 学術的なやり方をする
- 体系的なやり方を整理する
- 短針だけの時計を作らない
2021年の振り返り
じつは社会人生活10年目の節目の年で、結果的に個人としては原点回帰の年だった。つまり、マンガを読み、テレビ（オリンピック）を見た。鬼滅の刃で組織を考えたり、ルックバックに触発されて開発チームの理念を考えたりした。学術的ではない、経験に基づく根本的な価値観を整理できたところで、経験の体系的な整理や学術的な知識の応用に課題がある。
事業的には、6月末に1つ、年始を挟んで1月上旬に1つ、それぞれ大企業の事業部レベルのサービスをリリースした。収支の面でも、現在の規模においては申し分ない成果が出ていると言える。これからの10→100が鍵である。
採用に関して、業務委託の契約は進めてチームメンバー的には10人弱になったが、正社員採用はほとんど進んでいない。チームの核/顧客折衝もできるテックリードが3人必要。
私以外のメンバーで運用ができるようになり、トラック係数が2になった。それに伴い、運用負荷が可視化されてきている（運用が可視化されているというより負荷が可視化されている！）ので、運用負荷を下げていく必要がある。
組織構造が完成した訳ではないが、理念などで組織構造については検討を進めたので、今後はそれに従ってノウハウを伝えつつ、整理しつつでスケールする体制を作っていく。運用をはじめ、体制づくりのボトルネックになっている属人化した内容の整理をしていく。
2020年の採用の成功も改めて可視化された。同時に、結局は私が採用/チーム編成をしていると、偶然なにかで道を踏み外した異常個体を採用するしかないのか、という気分になる。常人で勝てる組織にするには、まだノウハウが足りない。
学術的なやり方しか知らない場合にどういう世界が見えるのかを考える。
能力を学術で補った場合で、かつ、やり抜く力を仮定しないリソースの使い方。
目標についての振り返り
2021年は＜自分が作業を引き取らない構造を目指す＞および＜最初に持っていないベストな答を拾いにいく＞を挙げていた。これらは、実際には目標というよりは行動指針として機能した。
結果として、チームの理念の定義や案件の舵取りを他の人や営業に渡したところもあり、またそれで成功した部分があり、目指す方向性としては正しかったが、具体性の観点であまり良い目標ではなかった。そこで、今年は目標はもう少し具体的にして、それと別に行動指針を挙げることにした。
今だからできるこの5年の意味付け
結果的に、この5年で0→1と1→10を経験することになった。私のポジションは一貫して開発の人であって事業責任者ではないが、ことサービスの開発という事に関しては、文字通り全ての工程に携わった。10→100でも同じように全てのことをやり続けられるのかはわからないが、事業として成立して単独で大きな黒字を生じる（開発の費用だけではなくて、単純に事業として回る）状態にできた。実装に関しては、一貫して私が最終決定者だった（営業的な依頼を受けるか否かの判断も含めて）。
ただし、そのために開発費用を顧客が出すような状態を維持したり、サービスそのものだけでなく開発予算である程度延命をしたから事業として成立したという側面もあるので、単純な0→1/1→10の開発としてこのやり方が良かったかというと、なんとも言えない。この仕事の仕方になったのは、私の最初のキャリアがSIおよび開発をやる会社だったからで、開発自体でお金をもらうという事がそれなりにできたためだった。これが良いのか悪いのかはなんともわからない。もっと普通のベンチャーっぽく、どかーんと開発だけを進めるというやり方もあったとは思う。
5年前に会社をつくった（そして半年で売って1年で畳んだ）時点で、自分自身の仕事に困るイメージはなかったが、この5年の経験は語りようによってはかなり大きく言うことができるので、改めて仕事に困る事はなくなったと思う。そんな事のために働いたわけではないが、得たものとして一応...
（ただ、今のところ仕事がかわるという事は全く考えられないが）
この5年で結果的にたりなくて困ったこと
必ずしも2021年足りなかったことではなく、2021年はそれを踏まえてうまくいった事もあった。
- 失敗を前提に考える勇気
- 失敗を統計的に扱う勇気
- ベストな製品を目指しながらも根本的に改善すべきか否かについての考え方
- 自分で仕事を取りに行く事と全体設計についての考え方
- 考え方がめちゃくちゃ出ちゃう
- 余裕が無い時にもいろんな人に優しくする
気をつけること
- ベストプラクティスの把握
- 体系的にベストプラクティスや知見を整理する
- 身につけた知見の整理/体系化が必要
- マネジメント的な部分だけではなく、技術的にも（伝達・スケールが必要になるため）
- 非開発メンバーの"本質的な開発"への巻き込み
- IFの自動出力など、システムを把握するための整理
今後の流れ
10→100は、今後の2〜3年でおそらく完成する（させる）
そのための開発組織づくりが急務で、その後はノウハウを使って周囲の領域での連携するシステムの開発、壮大な事業計画みたいな事になっていくと思われる。
少なくとも2年前までは、管理者としてシステムを使う人の名前ぐらいはわかっていることが多かったが（案件共通メールを見られる立場にあるので）、もはや全く知らない人が管理者としてシステムを使うようになった。5年前に、今のような形の未来は全く想像していなかったが、完全集中ではないにしても一つのシステムに深く携われるようになり、かつそのシステムが人間の活動の中で本質的なものであると思えるようになり、転職前に仕事について感じていた課題は解消した。まだ工数が細切れになっている部分もあるが、結局進みたかった方向には進めている。
最初の会社で叩き込まれた日本的な仕事の仕方、それが良かったか悪かったかはわからないが、少なくとも今の仕事はそこで叩き込まれた日本的な仕事の仕方によって成立していて、感謝している。もう少しうまく、あの仕事の方法の本質を伝えられればよいな、と思う。
Discussion