読書感想文
池袋に出かけたついでに、三省堂を初めて覗きに行ってきた。法務系は今の問題意識にピンとくるものがなかったので、夫の欲しい本を探しにコンピュータ系の本棚に。そこで推薦された２冊がなかなか面白かったので、一気読み。読み終わった報告をしたらブログを書けと煽られたのでざっと感想を。
ライト、ついてますか―問題発見の人間学 | ドナルド・C・ゴース, G.M.ワインバーグ, 木村 泉 |本 | 通販 | Amazon
夫に、ぜひ読めと言われた１冊目。
古い名著のようで、部分的に知っていたエピソードもあったが、なかなか問いかけが深いというか煙に巻かれるようというか。
色々な事例を交えながら、繰り返し同じことを言葉を変えて問いかけられているのだと思う。サクサク読めるが、２回通読して、まだ半分強わかった気がするレベル。印象に残ったポイントは以下の通り。
- 問題を解きたいというプレッシャーに負けてはいけない。
- 誰の問題なのか
- 問題の定義が正しいかどうか、常に疑い続ける
- 問題を解決したことで副次的に問題が起きる
（問題の解決によって、当然すぎて気がつかなかった何かを変えてしまう可能性）
- 実は問題を解決することを誰も望んでいない可能性
与えられた「問題」を自分の解法で解こうとしてしまう自分の癖に気付かされた点。「問題を放置」することが解法の１つである、という点が特に印象深かった。コンプライアンスが現場にとって「カンマの用法に関するメモ」（対応しているように見せかけて実際には無視する方法を示されている例）と同じ扱いを受けないように問題の設定や見せ方を考えないといけない、とも思った。
アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント | 平鍋 健児, 野中 郁次郎 |本 | 通販 | Amazon
スクラムに関する本は夫に借りて読んだことがあったのだけど、アジャイルとそのプラクティスの関係とかいまいち把握していなかったので、まぁ読んでみるか、と購入を決めた１冊。最初の目的は１部で達成されたけど、２部（導入企業の経験談）と３部（野中先生の論文における元祖「スクラム」とソフトウェア開発手法における「アジャイルスクラム」の関連）が想像以上に面白かった。
１冊目もそうだったが、私の過去関わり特に成果も残らなかった「業務改善」がなぜ失敗したのか、その答えが載っている気がした。（情熱もなかったし、対話も圧倒的に不足していた。問題の定義も「解決」による影響もあまり注意深く検討されていなかった。）
印象に残ったのは主に３部。下手に感想を書くと読みが浅いと言われそうだが、備忘的に。
- TDDはXPのプラクティスの１つ （私にとってグリーンバンドは独立した１カテゴリだったのでびっくりした。）
- 実践知の共有、身体で学んで身体で伝える
- 共感の重要性。顧客は分析の対象ではない。体験を共有する。共感する。
- 「見える化」とは感覚的に現状を把握できる状態にあること
- PDCAのPの前には、情熱をスローガン化してメンバーと共有する、共振させるフェーズがあるべき
個人的には、「日本の新製品開発現場の特徴をまとめた元祖スクラムには組織論といった視点での特徴が挙げられている。他方、それを参考に構成されたアメリカ発のアジャイルスクラムはプロジェクト単位で考えられているために組織に横展開する、組織の共有知や実践知として蓄積していく、といった適用対象を広範囲に広げていくという方向への知見が蓄積していない」という点が興味深かった。「強い組織になるには」という問題提起は比較的自分の周りではよく見かける問いだったので、他国には組織に知識や経験を蓄積しようという視点がない、という指摘に驚いた。また、日本の組織はもともと持続的な発展に長けているという視点に勇気付けられた。（暗いニュースに明日は我が身か、と思わずにいられない世の中でもあるけれども。）解決法が「合宿しなさい」というのは、すごくよくわかるが、まずその実行に難儀しそうだな、と自組織の構成員に思いを馳せつつ。。。。
コンプライアンス担当として、プログラマの製品開発にあたるようなプロジェクトはいくつか存在していて、これをスクラムの枠組みで回してみるのは面白そうだな、と思った。ただ、この場合プロダクトオーナーとスクラムマスターを誰がやるのが良いのだろう、とか、スプリントバックログをどう切り出すのが良いのだろう、とか、具体化にはちょっと考慮要素あるし、上長に提案しにいくのには、まだちょっとかかりそう。
さて、なんとか書き上げたし、お迎えに行って、子供とマリオカートしよう。
