11/30(土)にYOUTRUST主催のテックカンファレンスのプロダクトヒストリーカンファレンスがありました。

弊社はシルバースポンサーとしてブース運営をしていましたが、本当にたくさんの方と交流できたのでよかったです。セッションからも学びがたくさんありました。

そして、12/10(火)にKINTOテクノロジーズ室町オフィスで行われたプロダクトヒストリーカンファレンスのAfter PartyでLTをしてきました。

本日の記事はそのLTの内容に加えて、LTの時間制約の中では話しきれなかった部分も共有しようと思います。

LTタイトル: 経験が少ない若手こそ歴史から学ぼう

新卒入社した楽天では楽天トラベルのレガシーシステム運用業務でパワープレー要員をしていました。23年1月にnoteに入社しnote proという法人向け高機能プランの開発を担当しています。

今日一番言いたいことはLTのタイトルにもあった通りこちら。

経験が少ない若手こそ歴史から学ぼうということです。

このように主張したい背景として自分がずっと課題感を持っていたことがあります。それが意思決定の質は経験に依存するということです。

Decisions from Experienceという研究分野でも一定示されていますが、体感ではもっとありそうですよね。

そして意思決定の質を高めるには、経験を積み上げていく必要があります。ここでいう経験とは選択の結果として得られる繰り返しのフィードバックを通じて形成されるモノです。

意思決定をし、それを実行し、完了した結果がフィードバックとして返ってきて、それを元に学習して次に意思決定をする際はより鋭い意思決定ができるようになります。

この学習サイクルを回していく必要があります。

そして、若手に経験が足りない理由を構造的に説明してみると、経験を増やすことには時間的制約がありキャリア年数に依存するからです。

プランを実行するにも時間がかかりますし、実行が完了した後も結果が返ってくるまでに「時間的遅れ」が存在します。

ここで一旦、フィードバックには時間的遅れが存在するということを詳しく説明します。

フィードバックには時間的遅れが存在する

例えば業務効率化のためにマニュアル作業を自動化したとします。フィードバックをその自動化だけにフォーカスして考えればマニュアル作業の工数分が削減できたと考え「良い取り組みだった」と判断できるでしょう。しかし、実際に考えなければならないのは、「全体的に業務効率化ができたのか」であって、そちらに対するフィードバックを待つならばもう少し長期で考えなければなりません。

その理由としては、マニュアル業務自動化のためには追加でコードを書かかなければなりません。その追加したコードによってシステムの複雑さが増えてしまったとします。そしてさらに複雑さが増えてしまった部分が、システムにおいてクリティカルな部分だったり、よく変更が行われる部分だったとします。

その場合にシステム運用負荷が増えてしまい、全体的に見た場合にむしろ業務効率が下がってしまうということもあり得ます。そしてこの結果がわかるには、実際にシステムを数ヶ月運用してみて初めてわかるようなことだと思うので、フィードバックが返ってくるには時間がかかってしまうのです。

問題を構造的に捉える意義

スライドで述べた「若手に経験が足りない理由」は、当たり前のことを言っていますが、ポイントは構造的に問題を捉えることにあります。構造的な問題には再現性があります。一見、意思決定の質の高さは属人的な問題に思われるようなものかもしれませんが、そのように捉えてしまうと思考停止に陥ってしまい問題を解決するには至りません。

これでは、私が抱えていた悩みの「若手が経験の壁を超えること」ができなくなってしまいます。

ですが問題を構造的に捉えることによって、（エンジニアなら特に）ハックとかリファクタが可能になります。

そして「経験には時間的制約がある」という問題のハック方法の一つが、「歴史から学ぶ」ということになります。

歴史から学ぶとは、他者が回した学習サイクルを利用して経験の時間的制約から解放されることになります。要するに学習サイクルのうち、最後の「学習」からスタートできることになります。

そのため、経験が少なくても意思決定を精緻化できることになります。

よく、「歴史は繰り返す」とか「人類は繰り返す」と言いますが、それは「脳みそが人生経験によって発達していくこと」と「人生には終わりがある」という構造のせいなのかなぁと思っています。

この人類が宿命的に持っている構造をハックしなければ繰り返す（再現する）存在になってしまうと思っています。

ドイツの鉄血宰相ビスマルクは「賢者は歴史に学び、愚者は経験に学ぶ」と言っていましたが、当時の外交スキルを見ていると相当歴史から学んでいたり、構造的に問題を捉えていたりしたように感じます。

ここから後半パート

ここからは後半パートでプロヒスで回せた学習サイクルを共有していきます！たくさん学びはあったんですが、あえて絞って一言で言えば「ボトルネックを未然に防ぐための意思決定に必要な観点や情報を学べた」ということです。

これに価値があると感じた理由は、

システム思考的に考えると、ボトルネックは表面化してしまった時点で成長が鈍化していると言える（歴史を繰り返してしまっているとも言える）からです。

どのような意思決定で物事を進めると、どういう部分がボトルネックになるということをプロヒスのセッションを聞いて学ぶことができたので、自分がやるときには、もう少し精緻化されたリソース配分ができるようになる可能性が増えました。

ということで、学びを2つほど共有していこうと思います。

取り上げるのはLayerXさんとNealleさんのセッションです。

一つ目が、プロダクトの立ち上げ期に素早く検証することを重視した結果、データモデル品質がボトルネックになった例です。

素早く検証をするため、本質的ではない機能（admin）に関してはSaaSを導入して開発工数を削減するという取り組みはGoodでしたが、ドメイン理解が浅い部分のデータモデル設計を「だろう設計」で進めたことで、データモデル品質がボトルネックになってしまったと言います。

凝集度の問題やデータの取り回しが頻発して開発速度が落ちてしまいました。

そこから得られた学びとしては、ドメイン理解を深める時間を取ったり、理解した部分だけデータモデル設計を行うということでした。

私がプロダクトを立ち上げるとなった時は、この事例を知った状態から意思決定をできるのでより精緻化された状態で望めると思いました。

二つ目は、プロダクトの急成長期にプロダクト開発体制の強化が間に合わずにボトルネックになってしまった例です。

PdMが一人しかいなかったので、エンジニアにも要件定義をやってもらったことはGoodでしたが、複雑な部分を作りながら理解しようとしてしまった結果、レビューできる人が育たずレビュープロセスが属人化して品質が悪化してしまったと言います。

反省として、ドメイン理解を深める時間を取ったり、レビューが必要なドメイン特化の複雑な部分とそうでもない部分を仕分けてレビュワーの負担を減らしたりするべきだったと言います。

こちらについても、プロダクトの急成長時には体制がボトルネックになってしまう例とどうすれば良かったのかの学習データセットが手に入りました。

ということで、本来は数ヶ月くらいかかってしまう学習サイクルを数分にすることができました。

最後に発表内容をまとめます。

一番言いたいことは、経験が少ない若手こそ歴史から学ぼうということです。

• 歴史から学ぶことで本来は数ヶ月かかる学習サイクルを数時間・数分で部分的に回せること

• 歴史から学ぶべきことは、意思決定を精緻化させるために不足していた観点や情報

• プロヒスに参加することで、プロダクトの成長を鈍化させてしまう可能性を減らすことができそう

補足

歴史から学べることは他者の経験の一部に過ぎないし、どうしてもバイアスがかかるので取り扱いには注意が必要になります。

というのも「意思決定を精緻化させる」には「視座を高めたり、視野を広げたりすること」と同時に「物事の機微に気づけるようになること」という2軸がなければ頭打ちになるからです。

歴史から学ぶことは前者の「視座を高めたり、視野を広げたりすること」には有効かもしれませんが、やはり自分で実際に経験をしてみなければ物事の機微に気づけるようになるのは難しいところが大きいです。

文字ベース、伝聞ベースだと情報量が足りないので自分で経験してみて5感で学ぶ必要があると思っています。

ただ、自分にとって未知の部分は減らせたり、無駄な探索コストは減らすことができるのでやはりお勧めします。

また、若手の意思決定の強みとしては、「経験にとらわれない斬新な発想」という部分もあるのでうまく融合していきたいところですね。

最後に

登壇の機会をくださった会社の方々、スペースや飲食等の準備をしてくださったKINTOテクノロジーズの皆さん、共同開催してくださったX Mileさん、ASUENEさん、After Partyに参加してくださった皆さん、ありがとうございました。