理科系の作文技術と合わせて勧められる事が多いので読んでみた。
正直「めちゃめちゃ勧められる割に難しくない？」という感想だった。
もちろん「修飾・被修飾の言葉同士を近づける」「長い修飾語を前に、短い修飾語は後に持ってくる」*1などのわかりやすいtipsは役に立つと感じたが、本全体を理解できたかと言われると怪しい。
特に助詞のあたりは文の「格」の定義を理解した上で読まないと理解するのが難しいと感じた。
とはいえ「対照の『は』は一つの文で使いすぎない」「接続助詞の『が』は逆接ではない使い方があり、多用すると読み手に逆接を想定させるため読みづらくなる」というtipsは役に立つ。
完全に理解するのは難しい本だが、各tipsを知るだけでも価値がある本だと感じた。
*1:この「」は本で取り上げられた引用としての使い方じゃないです...
通勤で気軽に読めそうな本として選択。ザ・ゴールと同様に物語調に話が進むので気軽に読めた。
「これを読めばソフトウェア開発を成功に導ける」というような具体的なHowTo本というよりは、プロジェクトを進行するに当たってのNG行動や気持ちのあり方を述べている。
全体的に意外性のある項目は少なく「そうだよね」ってことが書いてある印象。
ただ、時々思い切った断言をする箇所があるようにも感じた。
例えば正しい管理の4つの本質として、以下の項目を挙げている。
「それ以外のことは全部管理ごっこ」という記述を見たときに、「思い切ったな…そうなのかな…そうなのかも…?」という感覚になった。
また、会議で重要でない人物が出席しなくて良いように、「議事予定表を発行し、それに厳密に従うこと」というのはそのとおりだと思いつつ、今の自分は全く実践できていない。
今の自分だと、会議という同期的にコミュニケーションできるタイミングで、(もし時間が余ったら)せっかくなら会議のテーマ以外でも話しておきたいことがないか聞いてしまっている。 より大規模なプロジェクトやチームなら不必要な会議を減らすためにこの本のようなことをするのは重要そうだ。
Amazonのレビューを見ると「ピープルウェアの補足として」と書かれていたりするのでピープルウェアも読んで見る。眺めた感じ電車の中でサクサク読めそうだ。
とても良い本だった。
自分が管理運用している検索サービスではまだランキングを積極的に改善するほどではないが、将来改善をするとしたらどのように取り組んでいくべきかがクリアになった。プロジェクトとしての準備やログの収集から触れられており、いざやる場合にどのように動けばよいかがイメージしやすかった。
実装の部分においても、ハンズオンがあることで方法の見当がついていない状態から理解が進んだ実感がある。
一方で実サービスで実際に取り組んでいく場合、「ユーザーがクリックした情報 (学習・評価用のラベル)」の取得やその時の検索エンジンのスナップショットを保持する運用、さらにはA/Bテストをやっていく仕組みづくりは、かなりの苦労になりそうだと感じた。この部分の整備とランキング改善による旨味の天秤がなかなか厳しい。
また、ランキング改善とは関係ない部分で、負荷テストに関する章はとてもありがたかった。少し前に検索エンジン周りで負荷テストをする機会があり、やる前にこの本を読んでいたら…と思ってしまった。
仮説思考も論点思考も、改めて思うとSIerにいたときにガッツリ教えられていたんだなと思い返していた。
論点思考は「そもそもさぁ…」「で、その問題を解決しないと何が困るの？」みたいな話にかなり近いと感じた。
何が「問題」かは立場によって異なるという話もとてもわかりみが深い。権限と責任に応じて何が問題かが変わるし、その問題に対して取りうる手の広さも変わってくる。
また、チームで仕事をするときにメンバーに論点(問題)を伝えるということもかなり肌感覚と合う。メンバーの皆さんに「なぜこれをやるのか」を伝えると、作業をする人としてでなく、問題解決をする人として自分にない視点を提供してくれるのはこれまでもよく経験した。
今まで触れたことがなくて面白いなーと思った考え方は以下のあたり
読んでるのは 思考力大全【合本版】だが、仮説思考の部分だけ読み終わったので感想。
「あれ？どっかで読んだことあったかな？」というぐらい見たことある話が頻出する。ドラゴンボールを読んで「ありきたりな展開だな」と感じたり、1984年を読んで「よくある設定だな」と思ってしまうのと似た話なのかもしれない。
「イシューからはじめよ」と同じような話もよく出てくる。 とはいえ完全に被っているかというとそうでもなくて、どちらも良い感じ。
読んでみて思うのは、日々の自分の仕事の中で情報コレクターになっていないかということ。
自分がなにかの問題に遭遇したとき、まずはそれが本当に問題なのかを考えてから要因分析に取り組むが、要因分析ですべてを調べきるまで次に進まない。とかやっているかもしれない。
もちろん肌感覚でツリーの枝刈りをして、なるべく手数を少なくしているのかもしれないが、それをちゃんと意識できているかというと怪しい。
あまり視点を変えるということもやっていない気がするので、要因分析の幅も出ていないのかもしれない。
読むだけでは足りず日々の訓練が必要な部類のものだと思うし、こういったスキルはあらゆる仕事において必要だと思うので訓練していきたい。
プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ
面白い本だったが、読むのが難しいと感じる本だった。
認知科学の観点から、コードを読む・書くときに自分たちの脳内で何が起きているのか、より早く物事を学び、よりうまく問題解決するには、といったことに触れられている。
具体的には認知科学に関する研究を多く紹介しつつ、その結果からどのようなことが言えるのか、どのように学習・プログラミング・問題解決・オンボーディングに応用できるか、何を回避すべきかといったことが書かれている。
とはいえ魔法のようなことが書いてあるわけではなく、これまで肌感覚でわかっていたことを言語化してくれているような本だった。明日からでも使えるような実務的なテクニックを期待して読むと予想を裏切られることになりそう。
それでも読んだことで、この先自分が混乱したとき・オンボーディングする・オンボーディングされている状況で、自分自身がなぜ混乱しているのか、新規メンバーは何に混乱しているのか、を少しながら把握できるような実感が得られた。
会社のビジネス側の皆さんが読まれている名著らしいので読んでみた。 物理本だとすごい厚さらしいが、実際に読んでみると2-3日あれば読み終えることができた。物語調なのでサクサク読める。
読むには読めるのだが、これをソフトウェア開発にどう適用するか、という点はなかなか難しいなと思った。
勿論ソフトウェア開発プロジェクトにおいて、ガッツリ線表が引かれているならクリティカルパスがあるし、クリティカルパスがある以上それ以外の工程がどれだけ頑張ってもプロジェクト自体の短縮にはならないよね、というのはわかる。
ただ、恥ずかしながらしばらくそういったプロジェクトをしていないのと、顧客に売るためのソフトウェア開発をしていない(作った物自体が直接利益に結びつく生産をしていない)ので、「企業の目的はお金を稼ぐこと」と置くと、この本の工場のような計測・改善が難しいと感じた。
どちらかというと「自分たちが実装した機能で、実際に利益に結びつく業務のボトルネックを削減できるか？」という観点が当てはまる気がした。何を作って何を作らないべきか。
一方で、会社の様々な部分に応用が効く理論ではあると勉強になった。
自分の会社は工場ではないものの、読んでいて「これ◯◯/□□の部署のお仕事に当てはまりそう」と思う部分は数多くあった。また本では推奨されていないが、意図的に自分自身の仕事のゴールを部分最適に寄せると「これをやっても自分・自組織の◯◯の改善には影響は薄いな」とかも考えることができそう。
一通り読んで、社内ソフトウェアを開発しているソフトウェアエンジニアとしても、「これをすることで会社としてどれぐらい美味しいのか？」を考えるのは大切だと改めて思えた良い本だった。
同作者から工場ではなくプロジェクトにフォーカスした本も出ているようなのでぜひ読んでみたい。
