エンジニアが『メモの魔力』を読んで、活用できると思う部分を感想してみた話

ブロガーへの道

前田裕二さんの『メモの魔力』読みました。この本の良いところはなぜメモすることがいいのかということをちゃんと意識できるように書いてくれて、普通のメモだけしろっていうことではなくそこからさらに発想を生み出す工夫を丁寧に教えてくれる良本です。

メモすで「ファクト」を集めて何故そう思ったのか?何故かそう感じたのかを「転用」して次に考えてまたメモをする。

その点まで書けたら「実行」する。

メモの魔力 The Magic of Memos (NewsPicks Book)amzn.to1,512円(2020年02月26日 01:36時点 詳しくはこちら)Amazon.co.jpで購入する

この単純な工程のように見えて普段から意識していない部分を表に出せる考え方は非常に有効な方法でした。

いつもとりあえずメモするのはするんですけど、なんでその事象が起きたのか、起こるのかを知ることで全然違う捉え方になるってことなんですね。

実はエンジニアの中でもこれに該当することがあるんですね。

エンジニアもメモの魔力を活用出来る

前田さんはまずファクトを捉えろと言っていました、エンジニアもよくある事例から学ぶとすれば、バグを発見したときではないでしょうか?

例えばあるエンジニアがバグを発見します。
「対象Aの場合に更新処理で異常終了する」という事象に遭遇しました。

新人くんは以下のように解析します。
・大量件数を処理してしまったようだから異常終了しているようだ。

先輩くんは以下のように解析します。
・大量件数を処理してしまったことが原因のようだ。
・処理時間はどうなっているんだろう?
・処理はどのように動いていたのだろうか?

結果対処として
新人くんは大量件数を条件ごとに分割して処理件数を小さく小刻み処理することで解決を図りました。

先輩くんはひとつ、ひとつに対してなぜを検証した結果、実行方式に問題があると判断して同じ処理になっているものを横展開で探すことにして本当の諸悪の原因を直すことにした。

ひとつの事象から多角的に捉える

今回の事例は実際にカツオが経験した現場での出来事です。

新人君の提案も悪いわけではないです、ただ小手先の回収となっていることで本当の原因を特定できていないおかげでこの後、実は数か所でこの更新処理の方式を使っている箇所があり軒並み直す羽目になったということです。

要はひとつの事象がわかってからどのようにその原因を追究するかによってはまったく違う結果になるわけです。

新人くんは最初の段階で件数が多いから悪いというとこに着目したわけですが先輩くんはそこを見たわけではなく方式自体の検討しなければいけないのではと気づいた点です。

経験がもちろんものを言いますがエンジニアにとって故障が起こった時に取る行動で大きくそのあとの回収などがスムーズにいくかドロドロしたものになっていくかは明暗が分かれます。

抽象化が大事なことはプログラムも世の中も一緒だ

抽象化って何か言われれば、本当に大事なものは何か?ってことだと解釈してます。(間違ってたらごめんなさい)

このことをより明確かさせるためにメモの魔力で紹介されている筆記方法を用いる事はすごく有効だと思います。

物事の本質を見極める、いったい何が原因でそうなったのかを知ることがどれだけ大事かを身を持って知るための方法、それがメモすること

っとカツオはこの本を読んで感じました。
事象を目先で捉えて小手先で解決したところでモグラ叩き的に問題はででくるかもしれません。

そのことに気づかせてくれました。
いろんな仕事、勉強、活動においても必要なスキルだと思います。

まとめ

メモの魔力は問題のかけらを抽出し、その問題の本質を見抜き実行して解決する。

このシンプルな動作で良い方向に向いていくってことが書かれている本だと思います。ぜひともみなさんが活用して頂ければと思います。

コメント

タイトルとURLをコピーしました