ここ数日、色々と考える事があったが、今の私がやりたいと思う事が見つかった。
圧倒的な成果を出せる開発者のスタンスとして、運用・実世界への影響を考えて開発を行うというものがある。これをチームで実現できれば、一層圧倒的な成果を、過剰な負荷無しで実現できる。これを示せ。
問題文の定義は、まだ十分ではない。十分ではないが、気持ちはだいぶ表せるようになった。これはチームや組織というよりは、本当に純粋に私個人のやりたいことだ。
誰にでも合う、誰でもできる方法論ではないが、きちんとやれば確実にできる。開発としての唯一無二のあり方でもない、むしろ開発者は運用と切り離したほうが組織として成立するという考え方もある。ただ、少なくとも私自身は、全く切り離さないことで得ているものが沢山あるし、それを切り離して実現できる目処を全く立てられなかった。
自分がその開発を1日でできるのはなぜか。自分がその修正を即時でやるのはなぜか。自分が運用もやっているのはなぜか。
運用もやっているのは、自分が開発したいものを作るために一番早い方法が、それだったから。例えばデータ構成だけを考えて、管理画面を作る前にリリースしてしまうのは、管理画面を作る価値を見極めると同時に、それで本当にやりたい事が実現できるかを短いサイクルで確認する必要があったから。
修正を即時でやるのは、例えばエラーデータが増えたら修正しないといけない仕事が増えるから。1件だけなら、タイミングが悪かったのかな？と思って顧客に再実行してもらえることが、100件だったらそうはいかない。問い合わせが発生して、組織的な対応も必要になる。工数が圧倒的に増える。組織に無駄が増える。
私はその合理性で動いている。
増えた仕事の先に自分のやりたい事が無ければ、別に放っておけばいい。放っておかないのは、自分のやりたい事がその先にあるから。緊急で必要だが本質的ではない仕事に潰されないためには、運用を考えて、即時の修正は即時でやって、という事が必要になる。そうやって、私は手放さない仕事に熟達していった。
そうやって熟達した結果、1日でできる仕事が増えた。自分が作っているものに対する知識も、当然ながら増えていく。それで、他の人との差はどんどん開いていく。
元々、プログラミングが得意な方だったとは思う。良くも悪くも、プログラミングそのものを人に教えてもらった事は一度もない。本当に一度もないと思う。てきとうな本に書いてあったVBのコード断片でできる事を学んで、VB6で神経衰弱やテトリス（もどき）を作って、そのテトリスを作る方法を高校生に教えたのが中学生のとき。他人のコードの誤りを指摘するのは、その時から早かった。当時の私は毎日部活もやっていたし、ゲームもやっていて、かつ22時には寝ていたので、そんなにプログラミングに時間を使ったわけでもなかった。知識は今のほうが圧倒的に増えたが、根本的にコードを書く速度そのものは、多分この頃とそこまで変わっていないと思う。その後、人とプログラミングの会話をすることは、就職するまで二度となかった。教えてもらうどころか、誰とも話したことがなかったのだった。
チケットシステムという事業領域は、意外と難しい。新型コロナがあったとはいえ、メガベンチャーが作った会社やサービスがいくつも撤退した。大手が出資してそれなりの規模の新会社を作ったというニュースがあっても、その後の動きが全く消えたりする。新しい会社の動きを見ていても、想定よりは悪そうに見える事も多い。実際にやってみて、確かに色々と難しいのだろうと思うことは内情としてあるのだが、そういったことを一切考えないとしても、外に見えている事実だけで割と難しい事業領域なのだということがわかる。そもそも、チケットの本質的な仕組み自体は割符や貨幣ができた頃から存在しているわけで、その意味では明らかなレッドオーシャンであるし、しかしおそらく外から見ても中から見てもシステム化が進んでいない領域であり、実際に何もないところから作って、システムとしては7年、右肩上がりで生き延びることができている。新型コロナがあった上でも利用者は増え続けているし、事業部ではそこそこの黒字が出ていて、もはやすぐに死ぬような事業でもない。
レッドオーシャン・実際に撤退する事業が多くある中で、生き残れている理由はなにか。私の思う答えは「人」で、要するにうちの事業部に集まっているメンバーが頑張っている。一人の人が多くのことをできる、これをやり遂げるという推進力がある、いざという時にすぐに動けるマインドがある。これはうちの事業部に限らず、コアメンバーはみんな人の会社だと思っていると思うし、実際そうだ。
かつて、私が他のメンバー2人と会社を作って取締役をやっていたとき、どこから出資を受けるかという話になった。金額提示まであった会社は5社ぐらいあって、単純な条件だけで言えばもっと良い条件の会社もあったが、一緒に仕事をしていて気持ちが良い・事業としても一番良いのは絶対にここだと私は強く主張して当時の社長を説得して、今の会社でやっている。結果的に2人は居なくなってしまったが、私にとってその選択が間違いでなかったことは、今も証明され続けている。
その良さ、現実に成果が出るということを、もっと多くの開発者について示したい。そう思うようになった。難しい領域でもビジネスを右肩上がりで育てていける、私自身は多少しんどい局面はあるにしてもずっと楽しく開発ができる、良くも悪くも思ったようには行動できている、それが、決して私個人の事ではなくて、本当の全員ではないにしても、ある程度もっと多くのメンバーで実現できる事を示していきたい。そのようなメンバーで、もっと楽しく開発をしていきたい。
「やりたい」とはっきり思ったのは昨日だが、今振り返れば、そのために必要なことがなにか、というのを考え続けた1年半ぐらいだったと思う。実装の成果に差が出てしまうのはなぜか。修正をすぐやる気持ちにならないのはなぜか。運用を任せられないのはなぜか。ちょうど、上に書いたような問いに対応しているような事を、どうやって改善すればよいのか、ずっと考え続けた。
実装の差は、認知と熟達の差。修正は、認知の差と修正をリリースまでもっていく遂行力の差。運用は、セキュリティと対応負荷と効率。
この構造を、構造として整理して理解するまで、本を読んだり考えたり実践したりの1年半だった。低レベルクリアが得意な自分が、低レベルクリアではなくて本質的な育成をするにはどうすればよいか。
私は多分、プログラミングに限らず、教育を受けたことがなかった。大学院まで通っておいて、何をおかしい事を書いているのかと思われるかもしれないが、多分、本当に一般的な教育を受けていない。環境というよりは私自身がそれを選んだという事だが、教わるという経験が人より圧倒的に乏しい。小中高と授業を全く聞いていなかったし、提出物も出さなかったし、大学でも講義はほとんど聞いていなかった。塾にも行かなかったし、父からも中学以降で勉強を直接教わることはほとんどなかった。部活も先輩が少ない環境だったり、主体的に考える事が求められるような環境であったりした。ピンポイントにごく一部の知識を教えてもらう事はあったが、基本的にはほとんど自分で学んでいくような体験が主だった。だから、『学力喪失』を読んだときには、強い納得感と同時に不思議な感覚もあった。つまり、私は教育を受けていなかったから学力を喪失しなかったのだ。なんということ。
誰かのせいという事ではなくて、それは私が自分で選んだ事だし、実際にそれで失敗どころか成功している事の方が多いと思うので、間違いだとも思っていない。結果的に学力喪失にも直面せずに済んだ。もちろん教わった事で伸びた事も沢山あると思っている。ただ、とりあえず、いわゆる教育は受けてこなかったのだ。
そんな自分が、ごく短い期間だが、ソフトウェアエンジニアリング協会のコードレビューに携わった。（これは短い期間で終わらせたわけではなくて、風邪を引いたり仕事が忙しくなったりで結果的に出られなくなって、そのまま1ヶ月経過してしまった。。。また余裕ができたら続ける。）
なるほど、たしかに、最初に書くコードの筋があまり良くなくても、ほぼ自動化されるまで書くことと相互に指摘する事を繰り返していくことで、最終的には普通に良いコードがそれなりにすぐに出てくるようになった。教育とはこういう事だったのか。単純な知識を得る教育ではない、自動化を一つの焦点とした教育とはこういう事なのか、という事が38歳の今更はじめてわかった。
そうやって実践しているうちに、私が実際に必要としている教育のコンテンツとしては、ソフトウェアエンジニアリング協会のものにいくつか加える必要があるという事がわかってきた。一つは、自分が作っているサービスとの向き合いや、運用の考え、運用者や営業と心を一つにできるための認知。これは、「運用をやる開発」として一般的なことと、チケットシステムに関する固有のことと、両方がある。かつ、両方とも、Google等の入社試験では問われない。もう一つは、そうした認知を習得していくうえで、いわゆる「小学生ができること」ができないという事について自分がどう向き合うべきか、という向き合いの姿勢をつくること。学力喪失は教科の勉強に限ったことではなく、いわゆる生活態度のようなものについても、間違ったスキーマを構築してしまっていた場合、そのスキーマを構築し直す必要がある。それは時に、小学生にもできることを獲得するというような事になる。それにきちんと向き合ってやるということ。これらは、成熟した組織や、いわゆる大手外資の環境では、（少なくとも一エンジニアとしては）歓迎されるにしても必要ではないだろうと思う。もっとも、一兆ドルコーチでは「コーチングを受け入れられる姿勢があって、はじめてコーチングに値する」とあるので、上に上がっていくには必要なのだろうと思うけれども。
本質的な教育を進めるにあたって、まずはこうした認知や教育に関するスキーマ・メンタルモデルを合わせる必要性を感じている。それらについて『学びとは何か』『学力喪失』『プログラマー脳』の3冊を通読してディスカッションをしたうえで認知を合わせて、具体的な方法はともかく私が社会人になって克服したような事はやっぱり逃げずに克服するという事を思うようにして、その辺の認知が合った最強のチームを作る。
たぶん最初はそれなりに厳しいが、それは時間や物理的な厳しさではなく、単純に向き合うことへのストレス。それを克服すれば、負荷は消える。
一般的な開発者に求められるものよりは、より多いものが求められる。それには一長一短があり、また全ての人がそうであるべきとは思わないが、我々に限れば、それで圧倒的な成果を出せる。笑う人、貶す人、批判する人、いくらでも居ると思う。それでいい。ようやく、私がベットする対象と決意が固まった。