はじめに
「ITエンジニア本大賞2022」技術書部門大賞おめでとうございます。
技術者が持つべきマインド、心構えに関してとても参考になったのでグッときたところをまとめていきたい。
あなたには現状を打破する力がある
- 職場の環境が悪い
- 仕事が退屈でつまらない
- テクノロジーに追従できていない
このように色々な不満があっても見過ごすのではなく、現状を変えるための努力をする。
技術力に不安があるなら、業務時間外でしっかり勉強する。
働き方に不満があるなら会社に相談する。
とにかく、自分の人生は自分でコントロールしていき、自らが望む方向に進んでいくことが大事。
自らの行動に責任を持つ
自らのミスや無知を素直に認める。
判断ミスなどの過ちを犯したら、それを認めてすぐに対策を考える。言い訳は絶対しない。
弁解の代わりに対策を考える。
わからないことを認めつつ、プロとしてソリューションを見つけていく。
あなた個人が行っていることだけを注意するのではなく、常に周囲で何が起こっているのかも注意するようにしてください
「石のスープとゆでガエル」という節からの引用。
誰も気づかないような小さなことが積み重なって、プロジェクトはゆっくりと手に負えないものとなっていく。
このような惨事を引き起こさないためにも、常に大きな視点で物を見る必要がある。
自分のタスクばかりに目を向けるのではなく、他の人のタスクにもしっかりと注意を向けなければならない。
あなたは完璧なソフトウェアを作ることはできない
完璧なソフトウェアなど存在しない。
完璧を追い求めるのは不可能なので、そんなことに無駄な時間とエネルギーを消費するべきでない。
自分が相対しているコードは正常なものでないかもしれないということを念頭に入れて防衛的なコーディングをしていく必要がある。
コードだけでなく、自分自身も信用しない。自分も含めた誰もが完璧なコードを書くことができないということを知ることで自らの過ちに対して防衛的になる。
本能に耳を傾ける
コードをいざ書こうと思っても、なぜか気が進まない時があるかもしれない。
これは過去の経験を元に、本能（本の中では爬虫類脳）が危険を知らせてくれている合図だ。
この合図をしっかり見過ごすことなく認知する必要がある。
このような時、
- 単に失敗を恐れている。これからコードをたくさん書いていく中で「エラーになったらやだな」と考えてしまう。「エラーを出す = 自分の能力が低い」と考えてしまい、エラーを生み出す可能性のあるコーディングが億劫になっている
- プロジェクトの最後までの工程を思い描けず迷子になったような気分になっている
- 既存のコードの設計や構造が間違えている、もしくは誤った問題を解決しようとしている
といった可能性がある。
こういう時はキーボードから離れて他の作業をしてみる。
本の中では散歩をする、昼食をとる、誰かと話す、睡眠をとるなどの方法がピックアップされている。
とにかく、無理に作業を進めるのではなく、一息ついて何かしらのアイデアややる気が湧いてくるのを待ってみる。それでもだめなら書かないといけないコードの代わりに、それと似たものをプロトタイピングしてみるのもいい。
慎重なプログラミングをする
偶然動いているだけかもしれないような信頼性の薄いコードを書いてはいけない。本の中では、このような行き当たりばったりなコーディングを「偶発的なプログラミング」と呼んでいる。
偶発的プログラミングをやめて「慎重なプログラミング」をしていくべき。
具体的には
- 常に、今自分は何をやっているのかを意識する。つまりは現在のタスクをあまり理解してないけど、とりあえずコーディングしていくみたいなことは避ける
- コードの詳細を他人に説明できるようにする。説明できるようでなければ、そのコードをちゃんと理解できてないかもしれない
- 明確なプランを思い描いてからタスクに臨む
- 偶然や仮定に依存しない。信頼のおけるものを前提として考える。
- 作業に優先順位をつける。そして重要な部分に時間をかける
- 過去の悪しきコードにとらわれず、現状ベスト（good enough）なコードを書いていく。そのためなら過去のコードは全部だろうが書き換える。
伝達しよう！
アイデアを提案したり、ドキュメントを作成したりと1日のうち結構な時間を情報伝達作業に費やす。
どんなにいいアイデアがあっても、それを効果的に伝えられないのであれば意味がない。
では、効果的な意思疎通をしていくためには具体的に何をしていけばいいのか。
- 聞き手のことを知る
- 聞き手の興味やニーズを理解する。コミュニケーションにおいて重要なのはフィードバックである。こちらから質問して、聞き手のことを知る
- 言いたいことを知る
- 自分が言いたいことを概要として書き出し、意図が伝わると思えるまでしっかり練り上げる
- タイミングを選ぶ
- 聞き手に話を理解してもらうためには、聞き手の優先順位を理解する必要がある。この話をするいいタイミングはいつだろうかということをしっかり考える。
- スタイルを選ぶ
- 聞き手にあった伝え方をする。相手は初心者か？熟練者か？長い話が嫌いか？とか
- 聞き手になる
- 相手に話を聞いてもらいたいなら、自分もしっかりと相手の話を聞く
- 相手の立場になる
- メールなどの返信が遅いと相手はどう思うか
- ドキュメントとコードをまとめる
- 達人プログラマーにとってドキュメントをまとめる作業はとても大事。将来の二度手間を防いだり、時間の無駄を省ける。
枠にとらわれずに考えるのではなく、枠を見つけ出す
かなり難しいコードを書く必要がある時にためになるTips。
「〇〇できない(不可能)」「〇〇はしてはいけない（禁止）」といった枠(=制約)の中で問題解決をしてはいけない。
自分が制約であると思っていたものの中には実は単なる先入観でしかないものも混ざっている。
難題に直面したら、制約と先入観をしっかりと見分けて本当に制約が存在するのかを評価していく必要がある（= 枠を見つけ出す）
具体的にやるべきことは、考えられる解決策を全て列挙し、それらがなぜ採用できないのかを吟味する。
- これは本当に不可能なのか？
- これは本当にしてはいけないのか。何か前提が間違えているのでは？
このようにクリティカルシンキングを働かせていくことで本当の制約を炙り出すことができる。
流行を追いかけるのではなく、効き目があるものごとを実行する
流行りの技術や開発手法を採用しても、それらがうまく機能するかどうかはわからない。ある企業でうまくいっていた手法だとしても、自社でも同じように成功するとは限らない。
なぜなら企業、チームによってそれぞれが持つコンテキスト(制約、機会、専門性、組織規模など)が異なるからである。
このようなコンテキストの違いを考えず、流行を表面的に取り入れたとしても成功はしない。
ある流行が自分のチームにとって効果的どうかを知るためには、単純にそれを試してみるのがいい。
小規模、もしくは複数のチームで少しずつ試していき、効き目があったものだけを残していく。
単にコードを調達するのではなく、ユーザーを喜ばせる
開発者が目指していく目標はユーザーを喜ばせることである。
ユーザーを喜ばせることとはつまり、ユーザーの抱えている問題を解決していくことであり、これが達人プログラマとしての仕事の本質である。
ユーザーは決められた予算の中で、特定の目的を達成するためにソフトウェアを使う。つまりソフトウェアは目的を達成するための手段でしかない。
「目的を達成するための手段でしかない」。これが何を意味するか
- ソフトウェアを作って、期限通りに納品できたらOKというわけではない。
- プロジェクトが進む中で継続的にユーザーの期待、要求を洗い出し、問題を解決していく必要がある。
ユーザーの要求に関するTips
自らが欲しているのものを正確に認識している人などいない
ユーザーの要求はさまざまな仮定、誤解、政策（方針）によって隠されてしまっているため、表面上に現れることがほとんどない。つまりは、ユーザーの真の要求を見つけ出すことは非常に難しい。「こういう機能が欲しい」と言っていても、それが本当にユーザーが欲しているものではない可能性がある。
ユーザーに「本当は何を欲しているのか」を気づいてもらうための支援をしていくことはプログラマーにとって大事な仕事である。
要求はフィードバックループの中で学んでいくものである
ソフトウェアを開発して欲しいと依頼する相談者がニーズとして最初に語るものは筆者の経験上、本当のニーズではない。
経験の浅い開発者は、最初に聞いた要求を鵜呑みにして、そのまま実装に進んでいく。
最初に「こういう機能が欲しいんです！」と言われたら、クリティカルシンキングを働かせながら、色々と質問していく。このように開発者が質問して、その答えからどのような結果がもたらされるかをフィードバックすると、相談者（ユーザー）からもフィードバックが返ってくる。このフィードバックループの中で、相談者の思考が洗練されていき、徐々に要求が明確になっていく。
最後に
こちらで、この本は「読むたびに違う箇所が印象が残る」という紹介がされている。2年目以降も毎年読んで、たくさんの学びを得たいと思う。