「エッセンシャル思考」読書メモ

 

エッセンシャル思考とは?

エッセンシャル思考は、より多くの仕事をこなすためのものではなく、やり方を変えるためのものである。

「やらなくては」→「やると決める」

「どれも大事」→「大事なものはめったにない」

「全部できる」→「何でもできるが、全部はやらない」

 

エッセンシャル思考の基礎となる3つの考え方

  1. 選択 

YESと言う事に焦りすぎない。

それを引き受ける上で、何が犠牲になるのか熟慮する。

人間の体力や気力は、どんなに優秀な人でも無限ではなく、いつかそのリソースには限界が来る。

人間の人生は有限なので、早いうちから選択と集中を行うこと。

 

このことについて特にしっくりきた説明は、とある優秀なエンジニアの話だった。

彼は優秀であるが故にいつも沢山のことを同時並列で勉強していたが、全てのことにおいて中途半端で1mmずつしか進んでいないような感覚に置かれていた。

 

著者であるマキューン氏は彼にこうアドバイスした。

 

もっとも大事なことを、ひとつだけ選んでみてはどうでしょう?

 

10つの最優先事項を持っていると、成果が出せない。

上の例でいうと、10つの勉強をして毎年1mmしか進めないよりも、その中から最も大切な最優先事項を1つ決めて、毎年1cm進む方が、目に見える成果としてのreturnは大きい。

 

ただ、最優先事項を決めるのはとても難しい。

しかし、全てを優先するというのは、全てを優先しないのと同じ結末になる。

 

みんなを優先するのは、誰も優先しないのと同じだ。

 

また、自分にとって本質的に大切なことを優先するのは、一時的に見て相手を怒らせたり落胆させることもある。

しかし、長期的に見るとそれは相手からの敬意と尊敬を勝ち取ることなのだ。

 

例えば、ジョブスはNexT社のロゴを有名グラフィックデザイナーのポール・ランドに依頼した。

「複数のデザイン案を提出してほしい。」

しかし、ランドはこの依頼を蹴った。

「いくつも候補など出さない。」

ジョブスは憤慨した。

 

ランドは、自分自身の仕事の仕方に信念を持っていた。

最高のデザインを1つ提出するが、それを使うかどうかの判断はそちらでしてくださいと。

結果ランドの出したデザインはジョブスを感嘆させた。

そして結果的にジョブスの敬意を勝ち取ったのだ。

 

好印象を手に入れたいからと何でも安請け合いしていては、この敬意は手に入れることはできなかっただろう。

 

2.ノイズ

世の中の大半のものはノイズ。

その中から本質を選び取らないといけない。

本質を選び取るというのは、編集作業と似ている。

本当に必要なところだけを選び取るのだ。


スティーブン・キングの言葉で、以下の言葉が紹介されていた。

書くことは人の仕事だが、編集は神の仕事だ

 

1であげたような選択ができるようになるためには、何がノイズなのかを注意深く選択しなければならない。

 

そのために必要なスキルが3番目にあげるトレードオフだ。

3.トレードオフ

例えば、上司に急に差し込みの仕事を依頼されたとする。

この時、部下が抱えている仕事の何かしらは犠牲になる。

 

差し込みの仕事と、犠牲になった仕事はトレードオフの関係にあると言える。

 

この時、「どの仕事を後回しにしますか?」

と上司に聞くことで上司にトレードオフを意識してもらうことが出来る。

 

目の前の仕事を優先した結果、もっと重要な仕事が駄目になるかもしれない。

 

あるいは、自分自身の問いかけにもこれは使える。

 

目の前にやらなければいけないことが10個あったとする。

これをやることで自分は何をする時間を犠牲にしているのかきちんと認識するようにする。

 

人生は常に選択の連続だが、選択したもののみにフォーカスするのではなく、何が犠牲になっているのかを意識することで、結果的に本質的なものだけを選択する判断力が身につくのだと思う。

 

犠牲になったものを失ってでも、今の自分はこれをしたのだと考えることで、後悔の少ない人生を送ることにもつながる。

 

逆プロトタイプ

なんのためにその仕事があるのか謎な仕事がある。

例えば毎週作成しなければならないグラフィカルな手の込んだ報告書。

これは一体誰を喜ばせるための仕事なのか?

止めるべきか判断がつかない時には、「逆プロトタイプ」と著者が名付けた方法が役に立つ。

 

今やっていることを試験的に一定期間やめてみる。

苦情が来なければ、それはやめていい仕事だということだ。

 

こうして時間をより大切なことに使えるようになる。

 

仕事を早くする

手当たり次第に進めるのでは、逆に効率は悪くなる。

 

準備は徹底的にする。

バッファは最悪の事態が起こった時にかかる見積もりの1.5倍載せておく。

ボトルネックを見つける。

 

この仕事が進まない一番の問題点。

この問題さえ取り除かれれば、一気に仕事が軌道に載る。

 

そういうボトルネックを見つけること。

 

本当に必要なところに一度だけメスを入れる。これは問題解決にかぎらず、最上限の努力で最大限の結果を得るための普遍的なやり方である。

 

準備を徹底的にし概要を把握したら、ゴールを決めること。

「〇〇ができたら達成。」

期日もゴールに入るだろう。ゴールはできるだけ具体的な方が良い。

 

そして、ゴールが決まったら上述したようにボトルネックを見つけること。

仕事に取り掛かる前に自分に問いかけよう。

この仕事をやり遂げるうえで、邪魔になるものは何か?

 

仕事の完成を邪魔する要素を全てリストアップする。

そして、優先順位をつける。

 

そしてもう一度自分自身に問いかける。

これを取り除けばほかの問題も解決するような、大きな障害は何か?

 

ここまでで、明確にボトルネックが見つかればあとはそれを取り除くだけだ。

 

最後に

ここにメモしきれないくらい、様々な良いトピックがある本だった。

例え話も多く、文章も明快で分かりやすく、読みやすかったので2日ほどで読み終えることができた。

 

その割に学びもとても多かった。

 

エッセンシャル思考を生きる人は、周囲の人と同化しない。

人がイエスとい言うとき、あなたはノーと言う。

人が行動するとき、あなたは考える。

人がしゃべるとき、あなたは耳を傾ける。

人がスポットライトを浴びようと押し合うとき、あなたは陰に立ってしかるべき時期を待っている。

人が見栄えのいい履歴書をでっちあげてインターネットのプロフィールを派手な言葉で飾るとき、あなたは地道に仕事の力をつけている。

人が忙しいと不満 (=自慢)を言うとき、あなたは控えめにただ微笑んでいる。

人がストレスとカオスの渦中にいるとき、あなたは豊かで充実した暮らしを送っている。

この情報と雑音とストレスと虚栄に満ちた世の中にあって、エッセンシャル思考を生きることは、静かな革命である。

 

PHPerKaigi 2023に参加してきた[レポ]

東京都練馬区で開催された「PHPerKaigi2023」に初参加してきました。

会社が「PHPerKaigi」のために金曜日をお休みにしてくれたので、金土の2日間、オフラインでの参加ができました。

 

PHP歴は5ヶ月ほどと、まだまだ浅いので楽しめるか不安だったのですが、結論から言うと全くの杞憂でした。

事前にノベルティBOXの中に入っていたパンフレットを見ながら、当日の開催されるトークテーマを見つつ、「TrackAとTrackBのどちらのテーマに参加しようかな」なんて考えて、今度はあっち今度はこっちなんてするのは文化祭感があって良かったです。

 

また、どのトークテーマもほかではなかなか聞けない話ばかりで、貴重だったのも好奇心がくすぐられましたね‥

普段他社のPHPerさんとお会いする機会はなかなか無いので、一斉に揃った景色を見るのは圧巻でした。

確か累計で300名くらいオフライン参加されていたような気がします。

 

スポンサーブースもそれぞれ意匠を凝らして独自の企画やノベルティを用意していたりして、普段使ってるサービスってPHPで書かれてたんだ!みたいな発見もあったりして楽しかったです。

 

あとこれは余談なのですが、PHPカロンなるものが用意されていたのですが、「無料なの?!」ってくらい大量に用意されていて、なおかつクオリティの高いお味で見た目も可愛く、感動しました‥

 

また、参加二日目にはTwitterでPHPerKaigi参加者同士でランチの募集があったので、人見知りながらも勇気をだして行ったりしました。

PHPerの知り合いが増えて嬉しかったし、「Awkにハマっている」という面白い話も聞けたりして、良い時間でした。

ご一緒させていただいた方には改めてお礼を申し上げたいです。

ランチで食べたオムライス。会場から徒歩10分ほどの場所にあった

また、Twitter上でフォローさせて頂いてる尊敬してる方の姿を生で見れるのも、PHPerKaigiの凄いところでしたね‥

「あ、あの人も知ってる!この人も知ってる!」みたいな感じで、テンション上がりまくりでした。

人見知りのくせに声をかけずにはいられなくなり、厚かましくも一緒に写真を撮っていただきました‥

皆さんこんな得体のしれない人物に、快くOKを下さり、Twitterなどでの掲載許可もくださり、頭が上がりません。

ほんとうにありがとうございました!

一生の宝ものにします!!

ちょうぜつ本著者の田中ひさてるさん。フラットにお話してくださりめちゃめちゃ良い方でした!!

エンジニア転職する前から尊敬している女性エンジニアのななうぇぶさん。腰が低くて感動してしまった‥

トークセッションの合間にLT大会なるものもあり、いろいろな工夫もすごかったなあと印象的でした。

まず、会場の後方にビールやサワーやおつまみが用意されていて、傍聴者はお酒片手にLTを聞けるのです‥!

LT大会が終わる頃には結構酔いが回っており、そのおかげでスポンサーブースで他社のエンジニアさんに話しかけられたりもしたのでアルコールに助けられました笑

 

あともう一つ印象的だったのが、ペンライトを渡されたことですね。

「何に使うんだろう‥?」と思っていたら、なんと、LT大会登壇者の押し色にペンライトのカラーを変えて、LTの制限時間30秒前になったら傍聴者のみんなで一斉にペンライトを振って、登壇者を応援する?という素敵な試みでした。

まるでコンサート会場のようで、一体感がすごかったです。

 

最終日には会場で懇親会もあり、食事とお酒を立食形式で楽しみながら、いろんな方とお話しました。

初参加で顔見知りがいなくてどうしようと思っていたら、登壇者の@soudai1025さんが、人を紹介してくださったり、勇気を出してベテランエンジニアさんに話しかけてみたりすると、駆け出しの自分にたくさんの励ましの言葉をくださったり、PHPerコミュニティのあったかさに感動しました。

懇親会ではDMをくださった、同じく駆け出しエンジニアさんとお話して、そのまま朝まで飲んだりして、こんなに頑張ってる優秀な方がいるんだ!と刺激を受けたりで、いろんなPHPerの方とお話できて、みのり多い懇親会でした。

 

PHPerKaigiの本編は懇親会だとも言われているようです‥笑

 

ということで、初参加で緊張していましたが、初心者からベテランの方まで楽しめる盛りだくさんのイベントでした!

もっと成長して、来年も参加したいと思います。

 

2/26 YKMC祭り[設計実践勉強会]振り返りまとめ

振り返り会感想

1月に参加したYKMC主催の設計勉強会で行った、図書館の貸し出し機能のモデリングについての振り返りに参加した。

 

冒頭から濃い話が沢山出てきて、終わった頃には脳が疲弊しきっていたけど、また沢山の学びがあったので、参加できてよかった。

 

*この記事では、主催者の方の許可をもらって、振り返りの中で出てきた図や振り返りの流れをまとめさせていただきました。

システムはビジネスに依存していて、ビジネスは価値に依存している

ドメインエキスパートと一緒にモデリングしていくなどが有効な方法では?

どのコアドメインが一番価値を生み出しているのか検討する。

その上で一番必要なドメインに高い保守性を持たせる。

古いシステムだと、システム依存の構造になってしまう。

本来システムは形を変えていくべきもの。

ビジネスは変化していくのに、システムに依存してしまっている。

特定の言語というリソースに依存しないようにすること。

負債の解消ができていない?

AS-ISで現状の把握を行い、TO-BEの目標地点へのマイルストーンとする。

TO-BEへの経路は複数ある。

 

蔵書合計計算機をどうして利用者にもたせていいのか?

名前から推論して答えるのは、名前の設計がきちんとしているから出来ること。

「この操作はこの名称のエンティティが持つべき」という観点から置くべき場所を探す

全体の関係を把握した上で、考える。

「この操作はこの属性が必要」という観点から置くべき場所を探す。 

利用者が消えた時に貸し出し中手続き中カートとかだけ残るのはおかしい。

利用者がDDDでいう集約であり、外から通信できるクラス。(このパッケージ図の中で)

 

クラス名から属性を定義する。

属性からクラス名を定義する。

どちらか片方だけではなく、両方の面からチェックする。

複数の視点から見ることで、そのクラスが整合性が保たれているのかチェックする。

 

蔵書合計計算機を利用者に持たせるのであれば利用者という名前はおかしいのでは?

将来を見据えて汎用性の高い名前を付けると責務が広がりすぎてしまう。

DDD的に言うと、その時の責務に応じた名前を限定してつけましょうというのがある。

なにをどうする概念なのかという観点でのネーミングが望ましい名前設計

 

開発者の中で視点があっている状態では、(そのクラスの責務に対する理解が揃っている)、抽象度の高い名前にしてもいいかもしれないけど‥

将来的に新しい人が入ってきた場合、抽象度の高い名前にしたが故に、属性がどんどん追加されて、神クラスが出来上がってしまう可能性がある。

 

貸し出し明細の責務がシステムから生えているのはおかしいのでは?

貸し出しが貸出明細のコンポジションになっている。

参考記事→

https://www.notion.so/2-26YMKC-0f315e0d72424b24bfdce909c0746453?pvs=4#76d1617eb8894326b6fca4918ccac9ce

貸し出しのみを外部に公開して、貸し出し明細を閉じてしまう。

また、貸し出しからループは生成されるべき。



実践と点線/コンポジション

上記パッケージ図の実線が表しているのは、、貸出クラスの属性(プロパティ)が蔵書クラスを参照しているということ。強い参照。

破線が表しているのは、貸出のメソッドが蔵書クラスを参照しているということ。

メソッドは実行されたら終了するので弱い参照。