こんにちは、開発１部のHIKARUです。
クロノスが執筆した本ではないですが、先日「MBA100の基本」という本を読んだので、ぜひアウトプットさせてください！
"MBA"とは、Master of Business Administration（経営学博士）の略で、本書はMBAを育成するビジネススクールで教えられているキホンのキを記したものになります。
その中でも、私が特に共感した３点を抜粋してまとめてみました。
（出典）東洋経済 MBA100の基本 https://str.toyokeizai.net/books/9784492046067
根拠は３つ
何かを主張するときは根拠を３つにせよ。
２つ以下は根拠に欠け、４つ以上は例え伝えたとしても、受け手側が覚えられない。
これは耳は痛いです...。
根拠はあればあるだけ信憑性が増すと考えていたので、挙げられるだけの根拠を提示してしまっていました。
ただ、仮に根拠の数が足りない場合、無理に絞り出して３つを目指そうとすると、そもそも根拠として薄くなる可能性が高いです。
根拠それぞれの質が高いという前提の元、初めて数にフォーカスすべきであると個人的には考えます。
仮説と検証を繰り返せ
問題解決する際、総当り式で可能性を探るよりも、アタリをつけてから検討するほうが早く解決する。
本書ではビジネス目線でのアドバイスですが、エンジニア目線、特にバグ対応のシーンでも活きてくると考えます。
注意点として、本書でも述べられているのですが、「クイック＆ダーティ（多少荒くてもいいから素早く）」な検証が求められます。
例えばコーディングにおいては、デバッグログを確認したり、特定の変数を出力したりと、できるだけ最小限の労力で検証し、次仮説を試す、といったサイクルが重要です。
マニュアルを作成しろ
現場において、マニュアル（手順書）を作成することによってたくさんのメリットがある。
- 業務やその前提となる戦略や企業の目的に対する理解が深まる
- 筋道を立てて考えたり表現する力が鍛えられる
- その仕事を自分がやる必要性が減る結果、別の仕事に時間が使える
これは最近私の現場でも、属人化している業務に関して、マニュアルを作成していこうという方針になってきました。
書き手側はもちろんのこと、読み手側にとっても質問する時間を削減できるので、一石二鳥です。
また組織としてナレッジが蓄積していくこともメリットです。
過去に別の現場で、大ベテランの方が急遽PJを離任され、大パニックになったことがありました。ただその方が多くのマニュアルを残してくださっていたため、それを参照して窮地を脱した、といったこともありました。
以上、特に共感した点のご紹介でした。
本書は上記のトピック以外に、かなり視座の高い内容が多く、（リーダーシップ、組織、マーケティング、etc）その中でも現状のポジションで通用しそうなマインドをまとめてみました。
今後、年次が高くなったときにまた読み返すことで、また感じ方も変わりそうです。
最後までお読みいただきありがとうございました！弊社が執筆した書籍もぜひ御覧ください！
