本を読んでいただいた yuri_at_earth さんから感想が送られてきたので紹介したいと思う。
【『リコールを起こさないソフトウェアのつくり方』の感想】
：【感想終わり】
：
まず、ソースコード20例が大変貴重なものだと思いました。ベテランになった著者の方が考えて書いた初心者っぽいコードでは、実際に初心者が書いたコードははまるポイントを押さえてはいたとしても、それ以外の素人っぽさは再現できなくなっていると思うので、リアル感がよかったと思います。実際に集められる人も限られていると思いますし。
しかも、2,3例でなく、20という数がいいですね。私自身、ちゃんとした集合教育的なものを受けたことがなく、同じ課題を多数の人が書いた結果というものを実際に体験したことがなかったので、とても貴重でした。さらに、同じ人が書き直したコードが改善された例など、この部分は新人時代に読みたかった、もしくは前職で部下だった人たちに見せたかった感じです。
次にこれまでの経験をもとに素直に読んで、「プライドを傷つけないようにする」という表現が、最もなのですが（だからゆえ？）笑えました。（私があまりほかの本を読んでないのかもしれませんが）こういう内容を強調されているところが特徴的というか、現場を経験されている方ならではだと思いました。
その他、実際に見聞きされたんだろうなという例がたくさんあって、心当たりがあり苦笑するものと、組み込みだとそうなのかと思うところがありました。ちょっと話がとびますが、エンプラ系はもともと進化が早く、新しいものを取り入れたものが偉い的な風潮があり、昔ながらのやり方だとだめ的な考え方があるためか、プライドを傷つけないように新しいことを取り入れていくという考え方は少ないように思います。
どちらかというと、新しいものについていけない方が悪いというような。。。
そして、やっぱり（吸収の早い）若い人にはかなわないよねという文化だと思います。とはいえ、上司のプライドを傷つけないように導入していけば、エンプラ系でありがちな、最近の技術はわからんから若いもんでやれ的な態度で投げ出すのでなくて、協力してくれるのかも？と思いました。
実際、以前の職場のマネージャは、javaはわからんとか、最近の～はわからんとかで実装は経験が数年レベルの部下に丸投げ状態で、その結果テストが全然だったことがありました。そこで、最近の開発環境とか、はやりとかはわからないかもしれないが、テスト設計をするときの考え方は今も昔も同じだし、彼らはそのスキルがないのでテストしたつもりになっていても、実際は肝心なところがテストされていないんですよ。なので教えてくださいという話をしたら、快諾してくれたことがありました。
プライドを傷つけずに導入することができていたら、（昔は言語は違えど現場でばりばりにコードを書いていたはずの）上司が、実装はわからないと目も耳もふさいでしまうことはなかったかも？と思ってしまいました。（本題とはかなりずれてしまいましたが・・・）
最後に、今の職場の問題に対してどう対処すべきか？という目線からです。まさに現状がこの本の例にあるように、「あたたかい人間関係の中のやさしい一員」状態なので、ここに書かれていることを気をつけながら導入していけばよいかな？と思ったのですが、現状でそれなりにうまく回っていて、現場的にも特に問題意識もなく、開発規模が大きくなることもなく。。。
ならば、このまま「あたたかい人間関係の中のやさしい一員」のままでいるのもひとつの解かと思ったのですが、ここはどうお考えですか？
まずは、感想を送っていただいた yuri_at_earth さんにお礼を言いたい。ありがとうございました。書籍にしてもブログにしても読者が何を考えているのか、こちらからの発信をどう受けとめたのか、じっと待っていてもが何も分からない。その点、Twitter は双方向のコミュニケーションが成立しているが、やはり不特定多数の読者の深い意見を吸い上げることができない。
そういった意味でも本の感想は貴重だ。Amazon のサイトにも「とら子」さんから「日本の開発現場にフィットする品質向上策」というタイトルで『リコールを起こさないソフトウェアのつくり方』の感想をいただいたので是非見て欲しい。
さて、yuri_at_earth さんの感想で Part1 の20のソースコードの例が貴重であると評価していただいたのが正直うれしい。重厚なタイトルにしてしまったため、新人や初級者、上司の方達には「自分には関係のない本」と思われたかもしれないが、実は Part1 だけでも切り離して多くの初級プログラマや指導する先輩、上司の方達に読んで欲しい内容なのだ。
Part1には他の本には書かれていない人間の本質からくる危うさを具体例で示している。その危うさは現場でまともに仕事をしていくとどんどん薄れていくのでほとんどの技術者が忘れてしまうのだが、「焦っているとき」「集中力が欠けているとき」「モチベーションが下がっているとき」などに、その危うさがプログラムに出る。また、プロジェクトリーダーが確固たる設計の規範を持っていないとき、持っていてもメンバーに指導しきれていないときに、その危うさがソフトウェアシステムの欠陥となって表面化する。
その根源がどこにあるのかを Part1 では具体的に読者に知ってもらいたかった。テストでよい点を取る手順のように、あらかじめ用意されたユニットテストのテストケースをパスすることだけに注力を注いでいると、そのソフトウェアを使うエンドユーザーにとって危険なプログラムを作り込んでしまう可能性があるということをソフトウェアを作ったことがない人、昔作っていたけど今のような大規模・複雑化してしまったソフトウェアの中身を知らない人に伝えたかった。
「プライドを傷つけないようにする」というのは特に日本のソフトウェアプロジェクトでプロジェクトを成功させるためには重要なポイントだと思う。この本では「あたたかい人間関係の中のやさしい一員」というキーワードを何十回も書いている。日本人がそういう性質を持っているからこそ、トップダウンでの指示よりも、プライドを傷つけないように気をつけながら導くことが大事なのだ。ちなみに、D・カーネギーの『人を動かす』にも同じようなことが書いてあるので特に日本人だけに当てはまることではないみたいだ。
yuri_at_earth さんからの「あたたかい人間関係の中のやさしい一員のままでうまくいっているので、これまでのやり方を変えていく必要があるのか」という問題提起に答えていきたい。
20年くらい前の組込みソフトウェア開発の現場は「あたたかい人間関係の中のやさしい一員」でうまく回っていた。開発効率は今ほど納期が厳しくなかったのでそれほどプレッシャーが強くなかったし、最終成果物の品質もよかった。しかし、現在、自分の周りではそんなにうまくはいっていない。ひとつの製品が自分のプロジェクトの中だけで閉じなくなってきている。スタンドアロンの機能だけでは他社に勝てない、ネットワークを使った連携機能が求められるようになってきた。
そんな時代になった昨今、「あたたかい人間関係の中のやさしい一員」の世界で培われてきたアプローチと「創造性と個性にあふれた強い個人」の世界で体系化されたアプローチの両方を使わないと顧客満足の高い商品をアウトプットできないと考えている。
もちろん、プロジェクトの人間関係という視点では「あたたかい人間関係の中のやさしい一員」のよさが前面に出ていていいのだが、大規模、複雑化したソフトウェアシステムの顧客に対する安全や信頼を保つためには「創造性と個性にあふれた強い個人」の世界で体系化された是正・予防のアプローチ等をきっちりやっていくことも必要だ。
ただし、マニュアルに書かれたようにシステマティックでなくても、大工の棟梁が失敗した職人を呼び出して説教をし、一度目は軽く、二度目は雷を落とすという、見事な是正・予防のアプローチをしていることもあるから「あたたかい人間関係の中のやさしい一員」もまんざら捨てたものではない。
また、CMMIには是正を言い渡してダメ出しした後に、相手と飲みに行って「本音で話す」などというアプローチは書いていないが、上記の大工の棟梁は雷落とした後に職人を飲みに連れて行ったりする。
従って、問題提起の答えは「顧客を満足させる品質が保てているのなら今のままでよい」「それが危うくなってきたら、変わる必要がある」となる。大工の棟梁のすごいところは顧客満足のことを第一に考えていながら、職人を一人前に育てることも同時に重要だと考えているところだ。どちらが欠けてもいけないことが分かっている。でも、どんなに優れた棟梁だって100人の職人を同じように気に掛けてやることはできない。そのアプローチの有効な範囲（プロジェクトの規模）はある。
西欧と東洋の良さを融合させながら、グローバルマーケティングにアウトプットする商品が多くの顧客に満足される品質を確保するにはどうしたらいいかということを『リコールを起こさないソフトウェアのつくり方』には書いたつもりである。
