ジョン・テンプルトン 10の投資理念とITエンジニアリング
はじめに
投資家として有名なジョン・テンプルトンには10の投資理念があったそうです。
それを見たときにコレはITエンジニアリングにも通ずる(というより解釈次第で普遍的に役立ちそう)と思ったので、エンジニアリングと絡めつつ紹介したいと思います。
日本語訳は次のサイトから引用させていただきました。
ジョン・テンプルトン 10の投資理念
まず10の投資理念とは次の10個です。
- 実利を目指して投資する
- 偏見を持たない
- 大衆の後追いをしない
- マーケットは常に変化する
- 人気株を避ける
- 過去の誤りに学ぶ
- 悲観で買い楽観で売る
- 価値ある掘り出し物を見つけ出す
- 世界中を探す
- すべてを知ることはできない
ひとつずつ見ていきます。
実利を目指して投資する
これはエンジニアリングで行われる様々な活動、特にプラクティスに通ずる物があると感じました。
いわゆる朝会やふりかえり、モブプロ、コードレビューなどシステムを顧客に届けるために行われているあらゆる活動です。
これらの活動は何かの効果があると仮定されたうえで設計され、その効果(実利)を目指して行われるべきです。
ですが、なかには「みんなやってるから」、「カンファレンスで良いと聞いてきた」、「もともとやってて惰性で続けている」などの効果を求めず、または考えずに行われているケースがあります。
どのようなプラクティスも現場にあった効果設計あってのものです。
現場にあった効果設計ができていなければ害悪にさえなってしまうものもあります。
何かプラクティスを始めるときは実利を目指してきちんとして効果設計を行い、我々の時間を投資したいものです。
偏見を持たない
これはUnlearn(学びほぐし)に通じる物があると思いました。
例えばSIerと聞くと条件反射のように古い、悪と思ってしまったり、
新しい方法を否定し自分の経験に固執してしまいがちですが、偏見はよくありません。
一度自分の経験や考えをリセットしてまっさらな状態で受け取ってみる、考えてみる、やってみると思ったより良いものだったり、自分にあったものだったりすることがあります。
また、30代40代のエンジニアと比べ新卒や学生エンジニアの成長が早いと感じたことはないでしょうか?
彼ら・彼女らは知識や経験が無いが故に新しい方法を素直に試し、経験して高速に学習サイクルをまわしていきます。
経験がなければその方法に効果があるかどうかなど分かりようがないため、自分で試して調べてみるしかありません。
そのため、その学習サイクルをノータイムで回すことができ圧倒的な速度で成長していくのです。
10年以上同じ業界に居ると様々な知識や経験や助けられることもありますが、ときにそれが邪魔をすることもあります。
偏見を持たずUnlearnして新たな方法や知識に触れ続けることで常に高速な成長を続けていきたいものです。
大衆の後追いをしない
これはキャリアに通ずる物があると捉えました。
ITエンジニアのキャリアを考えたとき、人気の言語、稼げる言語、プログラマのみのキャリアのように他に大勢の人がいるキャリアだけを選んでしまうと後々苦労します。
特にそのキャリアで1番を狙おうとすると非常にたくさんの努力が必要になってしまいます。
しかし、そこにあなただけの特色を持たせることであなただけのキャリアを作ることができます。
特色と行っても特別なことは何もありません。
あなたが経験してきたことを付け加えるだけで良いのです。
他に大勢がいるキャリアパスでもそこに自分の経験を特色として足すことで唯一無二のキャリアを持ったエンジニアになることができます。
特色をつけた私のキャリア
例えば私は現在バックエンドエンジニアを中心にキャリアを形成しています。
しかし、それだけではなくSIerに9年いた経験からSE、セールスエンジニア、それらの経験と知識が求められたカスタマーサクセスエンジニア(CSE)の経験もあります。
またバックエンドではJavaの経験が一番長かったため、Android開発の実務経験を積むことができ、バックエンドエンジニアでありながらスマホアプリ開発も出来るエンジニアとなっています。
さらにSIer時代にマネジメントの必要性を強く認識したことから、プロジェクトマネジメントに興味を持って勉強しており、開発プロセスとしては認定スクラムマスターの資格も持っています。
このように自分の経験を特色として追加するだけで、単なるバックエンドエンジニアにならない、大衆の後追いではないキャリアが築けると思います。
マーケットは常に変化する
これは不確実性との戦いそのものであると捉えました。
エンジニアリングの一つの側面として不確実なものを確実にしていくものであるという認識が個人的にあります。
同じプロダクト、同じ機能の開発経験があったとしてもまったく同じものを開発することはありません。
常に何かしらの変化があり、それが不確実性として目の前に立ちはだかります。
しかし、人によってはこの不確実性を認識しておらず、同じようなプロダクト、似た機能であれば同じ工数で確実に出来る、なんの問題も起きないという認知をしている場合があります。
不確実性は限りなく小さくできますが、完成するまで0になることはありません。
開発している間、常に不確実性との戦いは存在します。
節目節目で最後まで考えることで不確実性と戦う
私が不確実性との戦いに役立てている考え方の一つに「節目節目で最後まで考えてみる」というものがあります。
システム開発の工程では雑に分類すると要件定義、設計、開発、テスト、リリース、保守運用、改修のようにわけることができます。
要件定義や設計などの工程の前段階では保守運用や改修まで念頭においた行動をよく取りますが、特に開発以降になるとそれがおざなりになりがちです。
開発やテストフェーズでもそれ以降のフェーズのことをその時点で可能な限り考えつつ作業を行うことで後工程の不確実性を減らし、後工程を楽にすることができます。
もちろん、前工程で後工程の全てを把握することはできません。
前述したとおり完成するまで不確実性を0にすることはできません。
しかし、次のように定期的に工程の最後までを考えることで不確実性をへらすことはできると考えます。
(実際には要件定義や設計段階で後工程のことを考えますがあくまでイメージということでw)
人気株を避ける
これは「注目を集めているもの」と捉え、ふりかえりにおける観点のひとつとして有効かと思いました。
ふりかえりでは例えばKPTであれば「Problem」、YWTで「やったこと」などに意識が行きがちです。
しかし、問題ではなかったこと、やらなかった(やれなかった)ことも必ずあるはずです。
そこからの気づき・学びを得られないのはもったいないことです。
ふりかえりをする際にこれらの話題で盛り上がっていたら、一段落したタイミングで「逆にProblemではなかったことってなんだろう?」、「やらなかった(やれなかった)ことってなんだろう?」と投げかけて見ると新たな気づき・学びを得られるかもしれません。
またこれは設計ドキュメントにおいても有効かと思います。
設計ドキュメントは往々にして決まったことは書かれますが、検討して廃案になった内容やその経緯などは残りません。
その経緯を知らない者にとっては同じ検討して時間の無駄になりかねないので、決まったこと以外も残すスペースを作ると良いでしょう。
過去の誤りに学ぶ
これはまさにふりかえりですね。
ふりかえりとは何なのか?を改めて「ふりかえり読本 学び編~経験を力に変えるふりかえり~」から引用したいと思います。
ふりかえりは「過去の行動を見直し、未来の行動を決定する」という、未来をよりよくしていくための前向きな活動です。
テンプルトンは誤りと行っていますが、ふりかえりはあくまでも行動を見直すので正しかったことからの学びや気づきもあるはずです。
後ろ向きな反省だけでなく、行動から未来をより良くしていくための前向きな活動がふりかえりです。
「愚者は経験に学び、賢者は歴史に学ぶ」とは鉄血宰相オットー・フォン・ビスマルクの名言ですが、経験から学ぶことが悪いとは言っていません。
これから起こりうることは歴史に学んだほうが良いでしょうが、既に起こったことから学ばないのは愚者と変わらないと考えます。
ふりかえりを通して学ぶ姿勢を忘れないようにしたいですね。
悲観で買い楽観で売る
これは計画マネジメントの文脈で語られる「楽観的に構想して、悲観的に計画して、楽観的に行動する」に当てはまると捉えました。
この言葉は稲盛和夫さんの名言なのですが、
新しいことを進めるには楽観的に構想し、
悲観的に計画して、
楽観的に行動するのが大事と説いています。
社内勉強会やモブプロなどエンジニアリングのプラクティスを始める際は「根付かなかったらどうしよう」、「誰も来ないんじゃないか」、「文句を言われたらどうしよう」と不安になりがちです。
時としてその不安に負けてしまい行動に移せなくなってしまいます。
ここで楽観的に「物は試し」「宝くじは買わないと当たらない」と行動を始めることが重要です。
ただし、実際の行動計画は悲観的に行いましょう。
微に入り細に入り自分の全力で計画する事が大事です。
重要なのは完璧さではなく自分の全力でやることです。
完璧な計画のような不可能なことに固執するのではなく、人事を尽くして天命を待つ段階まで行うことが重要です。
また最初の『実利を目指して投資する』でも書きましたが効果設計は本当に重要です。
「試しにやってみる」でもいいですが、試した結果をふりかえる計画をきちんと立てておきましょう。
価値ある掘り出し物を見つけ出す
元の文脈では掘り出し物の銘柄はみんなが売っている銘柄にあるといったものですが、これは故・横井軍平さんの「枯れた技術の水平思考」に通じるものがあると捉えました。
横井軍平さんは任天堂の社員でゲームクリエイターでした。
「枯れた技術」とは「すでに広く使用されてメリット・デメリットが明らかになっている技術」のことで、「水平思考」は「既存の概念に捉われず新しい角度から物事を見る」ということです。
既に当たり前となっているものでも自らをUnlearnし見つめ直すことで新しい気付きや学びが得られるかもしれません。
例えばふりかえりがマンネリ化してる場合に既に検討したふりかえり内容であっても、新たな観点を加えてふりかえりなおしてみるなどと言った応用ができます。
もちろんプログラミング技術にも適用できます。
AjaxとベースとなったXMLHttpRequestの関係なんかはまさに「枯れた技術の水平思考」だと思ったものでした。
コレを機に自分の中で既に当たり前になっているものに新たな観点が加えられないか考え、見つめ直すことで新たな気付き、学びが得られるかもしれません。
世界中を探す
これはアジャイルサムライの著者ジョナサン・ラスマセンの、
「もっとうまくソフトウェアを届けるやり方を探し求め、分かちあい、見出していこう
(でもあんまり深刻に受け止めすぎないで。楽しみながらやっていこう)」 に通じるものがあると思っています。
我々エンジニアは顧客にソフトウェア(システム)を届ける仕事をしているわけですが、それをより良くする方法は世界中の現場にあると私は考えます。
ひとつとして同じ現場はないですが、問題や課題を抽象化し自らの必要な形に具体化するのはソフトウェアエンジニアの得意とするところのはずです。
ぜひ本記事のように自分たちの現場で起こったことを分かち合いましょう。
そして他者の知見を見出すことによって、自らの現場に還元し、それをまた抽象化して発信する。
このエンジニア界隈の特徴のひとつであるインプット・アウトプットはとても大好きな慣習です。
それは世界中で起こっており、自動翻訳を行えば海外の記事も読むことができますし、翻訳された本もたくさんあります。
ぜひもっとうまくソフトウェアを届けるやり方を探し求め、分かちあい、見出していきましょう。
でもあんまり深刻に受け止めすぎないで、楽しみながらやっていきましょう。
すべてを知ることはできない
元記事では次のように訳されています。
すべての答えがわかっているつもりでも、実は何が問題なのかも分かっていないものです。
これはまさにアジャイルの考え方である漸進的に良くしていくことではないでしょうか。
最初からすべて分かっていることなどありえませんし、それを期待するほうが無謀というものです。
ではどうすれば分かるのか?と聞かれれば行動してみるしかありません。
そしてそれをふりかえることで知ることができます。
システム開発の不確実性との戦いはまさにすべてを知ることはできないから始まっている、と言っても過言ではないでしょう。
不確実性コーンの話にも当てはまると思います。
おわりに
Twitterで流れてきたこの投資理念を見たときにまさにエンジニアリングだなぁと思ったのでこの記事を書こうと思っていました。
本当は自分のブログに書くつもりだったのですが、Zennを応援する意味でもこちらに書いてみました。
最初に書いたとおりこの理念はバイアスを持って解釈すれば普遍的に役立ちそうなものです。
それをエンジニアリングと絡めて紹介したのは、自分が大事にしている原理原則のようなものがこの10個に凝縮されていると感じたからでした。
ぜひ自分の解釈を持ってこり理念を読み解いてみたり、他の理念にエンジニアリングを当てはめてみて欲しいと思います。
きっとそこにあなたの大事にしている原理原則のようなものが存在すると思います。
Discussion