2020年の反省と2021年の目標＜自分が作業を引き取らない構造を目指す＞
これまでを要約すると、
- 2017年は、インターンでの人集めには成功した。良い会社に出会えた。
- 2018年は、インターンから正社員に切り替えて、至らぬことがあった。仕事のキャパでは、個人のギリギリだった。
- 2019年は、仕事のキャパが組織レベルでもギリギリになった。2018年の失敗が露呈した。
- 2020年は、仕事のキャパは個人レベルでギリギリの状態になった。採用は成功したが、数を増やす・層を増やす必要がある。
このような状況も踏まえつつ、2020/1に立てた目標の振り返りから、今後の課題までを整理していく。
2020年の目標について
2020/1に立てた目標は2020年の目標＜情報収集と、基盤づくり＞ であった。
これは、本を読むという部分では実践して、これまで疑問に思っていた事についての背景が整理された。具体的には、以下のような事が明らかになった。
本から情報収集をして得たこと
- 心理的安全性を標榜しながらもかなり厳しい選考を行うGoogleと、HARD THINGSに描かれる厳しいスタートアップ/「スタートアップ」という日本の本に描かれる状況についてのアウフヘーベン（一兆ドルコーチ）
- 「企業文化がなぜ大切なのか」という事と、その文化が作用するメカニズム的な部分で理解すること
- 何故これまでのやり方では利己心が強い人とはうまく行かないのか、という事の答え
一方で、「首尾一貫感覚を後天的に大人が強く養う方法があるのか」 という事についての答えは得られていない。この辺りは課題がある。
また、チャレンジングな環境で成長するという事については、この事とは別に「才能がある場合は、ゴルディロックスの原理に基づく最も吸収効率の良い難易度が、まさにチャレンジングな環境に挑むことである」という可能性があることも感じた。大雑把に、その"才能"の差がどんな環境でも吸収/成長できる人とそうでない人の違いを産むのかもしれない、という事を思った。
基盤づくりの実践について
基盤づくりに関しては、以下のような業務習慣/フローに関する改善を行った。
- QAサービス/営業主導のテストケースの導入
- GitHubフローの導入
- 学習時間を明確に取る、コメント（N予備校のプログラミング入門Webアプリなど）
営業主導のテストケースに関しては、結局、当初作ろうとしたフローとしての定着はできていないが、マニュアルの作成やその後のサービスの改善に関する打ち合わせに繋がったので、取り組んだこと自体は良かったといえる。
GitHubフローは、レビュー結果を作業者本人が直す事をより意識させることができるようになったと感じる。CircleCIにお金を使う前に、先にGitHubにお金を使っておけばよかったという反省がある。
N予備校のコンテンツに関しては、おそらく多くのプログラミングスクールよりは内容が良く、ある程度のベース教育として機能したように感じる。
また、開発プロジェクトに関して、これまで
- 自分＋インターン
- 経験の浅い社員＋インターン
という構成で新規プロダクト開発をやってきたが、今年は（自分＋）業務委託数人、の構成でプロダクト開発を実践して、一応2ヶ月で仕上がるというところまでは進められた。
その他の雑多な取り組みなど
技術的には、2020年はDB構造の大規模なリファクタをした。これは大きな効果があったが、かなり難易度の高いタスクで、このようなタスクを切り出せるようにするには？というのが課題の一つ。
合わせて、「SPAだがアプリケーションのAPIが返却した内容によってフォームを変更する」という事をある程度定式化した。この書き方はまだ課題もあるが、リッチな機能性の画面を作る速度はおそらく格段に早くなった。
また、最近の新しい実装に関するテストの書き方を一新して、一部では単体の試験ではなくてシナリオ的な試験も行うようにした。これは、機能Aの単純な単体試験をしたいと思っても、ベースになるデータを20テーブル分ほど用意しないといけないためで、それを単体のみで実施しようとすると色々と非効率な事があり、テストケースの実施順序を意図的に指定してテストできるような枠組みを作った。
その他、CloudFrontをはじめて使ってみたり、Athenaを使ってみたり、というような事もあった。
ビジネス的には、新型コロナがありながらも色々と進捗・手応えはあった。少なくとも、これまで進んでいた方向が間違いではなかった、という事は確信できる内容だった。
今後の課題、構造の最適化
今後の課題としては、
- （稼働中の既存システムが存在する）改修プロジェクトで、要件定義の終了フェーズ近い状態から参画する場合に、どうやって新規参画メンバーだけで主体的に業務が回るような構造を作るか。
- 概ねソースのみの状態で、どうやって新規参画メンバーの作業の終わりを定義するか。 → 一部、テストケースは作成中
- 基本設計に相当する作業をどうするか。
- （なるべく短時間で）うまく既存システムの機能をトランスファーするには。
- 採用/体制づくりの強化
- 進捗やモチベーションを維持する的確なコミュニケーション
- "自分に業務が集中しない形での落とし所"を重視すること
といった事がある。この最後のものは、私の考え方が総じて"困難を自分側に倒す"事が多いため、"自分がこの作業をすれば全体の見通しがよくなる"とか"自分がこの作業をすれば他の人の作業が無くなる"というパターンを落とし所として考える事が習慣になっているが、もっとフラットに相手の立場で考えれば、私が出せないような別の解決方法がある、という話。
例えば要件を整理しているとき、私個人の観点では「（私は要件を理解できているのだが）単に私が要件を俯瞰するための資料を作れていないだけ」というところに落としたくなるような状況であっても、他の人の観点では「そもそもこの要件が上がってきた理由が何なのか」を掘った方が効率的、というような場合がある。
これは、私自身が実施するという観点で物事を考えてしまうと、私が俯瞰している要件をいちはやく出して話をしたいという事になってしまうのだが、その工数を割くことが難しい場合には、私以外の人で「そもそもこの要件が上がってきた理由は」みたいな事を別の軸で整理しにかかった方が上手くいく場合がある、ということ。
さらに一歩踏み込むと、そもそも、このような場面で私が見出している道筋も、私の立場から見たものでしかないので、仮に要件自体は全て見えていたとしても、話の進め方や全体の納得を得る、あるいは話し合いを経て相手を巻き込む、というような観点で十分とは限らない。実際、私が俯瞰的な要件を出すことに終始すると、確かにシステムとしては整理されるかもしれないが、逆に「正確で精緻すぎて、それを正確に読み解かないと理解ができない」という状態になっているかもしれないし、システムを作り上げるまでの間で全体像を主体的に考える作業に巻き込むことができず、その意味で他の人の理解度が下がる可能性があり得る。
このような作業の進め方を繰り返すと、最終的に誰もついてこれなくなって、結果的に自分だけしかわからない状態を作り出してしまう場合がある。その結果的な状態がよろしくない。
これは、雑に言えば「局所最適化の継続が全体最適化にはならない例」という事なのだが、実際に具体的な場面でそれを考えるようにしないと、自分の行動や習慣と紐付けて理解することは難しい。ただ、ようやく自分の作業を重くしてしまう習慣の尻尾を掴むことができたので、あとはそれを丁寧に見ていけば、おそらくクリアすることはできる。
それを踏まえた今年の目標は、＜自分が作業を引き取らない構造を目指す＞ かなあ。というようなことを、考えている。
これは、ある意味で「縛りゲーをプレイする宣言」でもある。
これまで、ゲームとしての縛りゲーは好きだが、一方で実際の世界では、自分が敢えて縛りゲーをするプレイヤーになるよりは、ゲームの駒として振る舞った方が成果を残せるという確信があって、縛りゲーをしたくなかった。
しかし、実際には、その場で自分の考えた答を出すよりは、それぞれの参加者をうまく引き込んで、巻き込みながらそれぞれの思う答えを出してもらったほうが、その止揚として良い方向に進む場合"も"ある。
その存在自体は、理屈ではわかっていた事だと思うのだが、去年はようやくその実態を掴むことができた。
だから、ようやく縛りゲーをする気分になった。そういう事なのかなと思う。
Discussion