そーとー個人的なオススメです。
...
...
仮説思考 (内田 和成)
仮説思考 BCG流 問題発見・解決の発想法
内田 和成 (著)
一気に、正解を見つけようとするのではなく、また、網羅的にひたすら検証するのではなく、仮説を立てて検証する。間違っていればまた仮説を立てて検証する。
基本的と思われるかもしれませんが、意外に難しいものです。いざ本番になると、アンチパターンにはまってしまいがち。
プログラマーとしては、日々のデバッグ、トラブルシューティング、ここに深くつながることだなぁと。
jfluteは、
予期せぬコストはデバッグ作業から生まれる
と考えています。
DBFluteの紹介ページでもテーマに挙げているものです。
=> DBFluteの紹介: jfluteコラム
「この実装何日で終わる？」ってのはわりとみんな答えやすいかと思います。(それも難しいですけど...)
「このバグ何日で直る？トラブルいつ終わる？」ってとっても答えづらいかと思います。5分で終わるかもしれないし、一日かかるかもしれないし。
いかにデバッグを速くするか？
Happyなプログラミングライフに欠かせない要素かと。
以前の記事で、もっと詳しく紹介しておりました:
=> My Favorite Book: 仮説思考 | jfluteの日記
プロトタイピング (藤村龍至)
藤村龍至 プロトタイピング-模型とつぶやき
(現代建築家コンセプト・シリーズVOL.19)
藤村龍至 (著)
かなりプログラミングにつなげるのが難しい本かもしれません。
「えっ、なんで建築の本？」
と思われるかもしれません。ですが、ぼくはこれに相当感銘しました。
空間を設計するときの、
超線形プロセス
この感覚、
フレームワークを作るときの感覚とすごいシンクロしたんですね。
書いては壊して書いては壊して、その過程で色々な発想が舞い込んできて
最終的に「ちょうどこのくらい」という絶妙なバランスのプログラミング空間に仕上がる。
まず、プロトタイプとなるプログラムを作るのが大切、それが土台となって次の発想が生まれる。いきなり正解を見つけようとすると、先に進まないか、つまらないものができあがる。
この一点ではありますが、別の業界の思考とシンクロすることで、その思考がより意識づいたものになるかなと。刺激にもなり、プログラミングでのインスピレーションも感覚と感性を鍛える。
プログラミングは、そのプロトタイプがそのまま最終成果物の一つにもなり得るので、コストも少なくやりやすいはず。ただ、書くスピードは求められますので、指のトレーニングは怠りません笑。
ちなみに、空間設計と言う言葉が、フレームワークの設計とリンクするなぁと。フレームワークは目に見えないですが、確実に空間がそこにあって、プログラマーがその空間にいます。ぼくはプロトタイピング思考をさらに鍛えていって、プログラマーが過ごす空間の「デザイン力」を高めていきたいなって。
もちろん、業務のプログラミングだって、いきなり正解に辿り着けるわけじゃない。探るように実装していく、探るために実装する。
ディズニーの気づかい (芳中 晃)
誰もが“かけがえのない一人"になれるディズニーの気づかい
芳中 晃 (著)
さて、チームビルディング。
ここでいう「気づかい」は、前向きな気づかい。
一見、お客さん相手のサービス業のお話に見えますが、後半は「仕事仲間への気づかい」という点にフォーカスが当たっていて、得られるものがたくさんありました。
こういった本はたくさん出ていますが、とても完結にポイントをついていて読みやすく、レジャーとつながっているので、違う意味でも興味深く読めるんじゃないかと。
システム開発のほとんどはチーム開発です。チーム仲間への気づかいが求められますし、そういうことができる人が少ない気もします。逆にいうと...
気づかいができるプログラマーは、現場でとても重宝されます
...
また、プログラミングにおける気づかい、その世界であまり聞く言葉ではないですが、多くの人がソースコードに求めていることって、要はこういうことだなぁと読んでて感じました。
さらに突っ込むと、コード上での気づかい、単に「コードを綺麗に綺麗に」だけだと、なかなか伝わらないかなぁと。綺麗にしてなにがうれしいのか？そこハッキリしないとセオリーも曖昧になりやすく、「いや綺麗ってそういうことじゃない...」って、うなっている人をよく見かけるなぁと。そもそもケースバイケースだから、これが綺麗あれが綺麗って絶対的なものではない。
...
コードを読む人がHappyになったらうれしい
もとから人に備わっている...
「他の人が喜ぶと自分もうれしい」
って、この感覚がもっと前面で出てくれば、自然とコードも良くなっていくだろうって。良くするためにたくさん考えるだろうって。
コードを読むときって、大抵は苦しいときに読んでるよね、きっと。そこに少しでも笑顔が入るようなコード書けてたら、やっぱりうれしいじゃんって。(それ自分かもしれないし)
そのためにどうすればいいんだろう？
気づかいってスキルであることがわかります。意識して想像力を高めて気づかい思考ができるように、この本を読んでそう思いました。アーキテクトの重要スキルの一つでもあると感じています。
=> アーキテクトのちから | jfluteの日記
...この本からここまで飛躍させましたよぅ笑
リーダブルコード
リーダブルコード
―より良いコードを書くためのシンプルで実践的なテクニック
Dustin Boswell (著), Trevor Foucher (著),
須藤 功平 (解説), 角 征典 (翻訳)
そのコード上の気づかい力をアップさせるための本。コード上での思考のヒントを与えてくれる本。ようやく技術書が出てきました。(そしてこれだけです)
実はわりと最近読みました。このイベントがきっかけ。
=> SEゼミ、リーダブルコード勉強会のフォロワー参戦
よかったぁ、自分の考えとだいたい合ってたー、って安心した記憶があります笑。
まあ、読む人のHappyを考えていれば、要は、行き着くところは同じなのかなって。
特に若い人にはBigオススメの本です。これをきっかけに人のコードを読むのが楽しくなってくれるとまた嬉しいなって。
...
ただ一つ、若い人に読んでもらって気になった点。「この本に載っているからこう書く」
って考えには陥ってはいけない。というか、先のイベントで、解説の須藤さんからそういう話を聞き、「まったくその通りだな」と思った次第です。他の本でもどの本でも同じことが言えるでしょう。
なぜなら、結局のところ正解はないから。正解はケースバイケースだから。そもそも、この本もそういうニュアンスで書いてるところがたくさんありますし。
しょせん、何がリーダブルかって、できるプログラマーが10人集まっても、7割も一致しないかもしれません。
この本は、「リーダブル思考のヒントときっかけ」を与えてくれる本です。その考え方をもとに想像力をたくさん働かせて、自分の目の前のコードをどう書いたらいいかな？
という感じで、
コードに意図を持たせることが大切
意図があれば、若干読んだ人と感覚が違っても、そのコードは伝わるからそんな問題にはならない。
自分と違うからイヤだなぁブツブツ言う人のことは無視していいかと思います笑。
論点思考 (内田 和成)
ズバリ、その論点、合ってますか？
どれだけ的を得た仮説でも、
どれだけ効率的なプロトタイピングでも、
どれだけ優しい気づかいでも、
どれだけコードがリーダブルでも、
そもそもの論点が間違ってたら、ものすごいスピードで間違った方向に進んでるだけ
です。
論点思考は、本当に根本中の根本であって、今日紹介した思考の土台になるわけです。だから写真の背景も唯一違うわけです！
論点を間違って突き進むケース、よく見かけます。もったいないですよね。
というか、怖いものでもあります。どんだけ優秀になってどんだけスキル付けても、間違った方向に行ってたら成果ゼロなわけです。どれだけ成長したとしても怖いわけです。
だから、この意識だけは外せない。
何を解決したいのか？
その論点を求めるために、仮説思考を使いますし、プロトタイピングをすることもあります。様々な思考はつながってるんですね。
だから五冊。
本をおもいでにする
「なんとか思考」だらけでしたが...
もちろん、他にも優れた本がたくさんあるので、色々とじゃんじゃん読む方がいいのですが、やはり時間に限りはありますから、焦点を絞って効率よく本を読めるといいのでは？ってことで、一例としてjfluteのオススメ本として、紹介させて頂きました。
また、この手の本で紹介されているスキルは、読めば「できる」ものではありません。知識ではないんですね。感覚なんです。
どうやったら本番でその思考を思い出せるか、まあ、トレーニングするとしか言いようがないですが、ひとつ！
自分にフィットした本を「おもいで」にすることで、いざ必要になったときに、ふと自然と思い出す
少なくともぼくはそういうことがよくあります。それをわざと活用します。
だから、こうわりと大げさ愛着を持ちますし、解釈も広げて、色々な符号を付けておきます。記憶を掘り出す刺激が増える、すると状況が勝手に導いてくれます。
だからまあ、別にこの五冊じゃなくていいわけで。みなさんの五冊、なにかありますか？
jfluteは、この五冊。
こんな感じで読んでいます。
