”職人気質”を胸に刻もう

”職人気質”を理念として提案し、業界の意識改革を求める書。
「ソフトウェア工学へのアンチテーゼ」、
「徒弟制度による、開発者育成の促進」を主なテーマとする。
管理者、ユーザに対しても、意識改革を求める点で、アプローチの正しさを感じる。

文章は、例えを踏まえつつ、軽快な調子ですすむ。
訳も良く、読みやすかった。

提案の性格上、明日からの実務に大きく反映できるものではないが、
近年の「アジャイル手法」への注目や、本書の評価の高さなど、
”職人気質”は支持されるべくしてされつつある。

ただ、冗長な箇所が多く、内容がない節も度々見られる。
また、何度も読み返すような必要性に駆られず
そういった意味で、評判に適う内容ではないように思う。

ソフトウェア開発は職人の仕事だと思っていた

ソフトウェア開発は職人の仕事だと思っていたので、思わず購入してしまった。
自分が思っていることとあまり違わないことが書いてあるので、ほとんど読まずに積ん読していました。
多くの書評（レビュー）を読むと、様々な立場で、この本を読んでいる事が分かりました。

「１００人未満のプロジェクトでは、ソフトウェア職人気質に則ったアプローチの方がより効率的になります。」

という記述は、自分の経験則からも妥当だと思う。ただし、能力が低く、なおかつ能力にばらつきがある場合には、１０人になったときから、ソフトウェア工学によった方がよいかもしれない。

職人気質を問題にするには、そこまでの質の高い職人がいる場合だけである。
そうでない多くの人たちには、関係ない世界かもしれない。

職人という響きに何も感じない人は、読まない方がよいかもしれない。

「中小規模」を職人という切り口で

→個人のＰＭスキルを、経験してきたＰＪ規模で
　レベル分けすることがあります　
　なぜなんでしょう？

→それは、「なんとなく」、「体験的に」
　「大規模」と「中小規模」のＰＭは別物である
　ということを、数多くのＰＭの方々が認識しているからなんだろーなー
　と私は勝手に思っていました

→この本は、その「なんとなく」、「体験的に」という　モヤッとした部分を
　「大規模」をソフトウェア工学
　「中小規模」を職人
　という切り口で、明確に、納得させてくれる本です

→ただねぇ．．言ってることはいいんだけど
　文章がダラダラ続いて読みにくいなぁ．．
　斜め読みで十分かも．．

開発者の未来

多くの優れた開発者の大半が、
より報酬の多い別の活動へと移っていき、
しかも、開発者としては頭打ちという状態から
抜け出すために、管理者、起業家、研究者に
ならざるを得ない現状に警告を発しています。

プロスポーツの分野で、花形選手よりも
コーチの方に高い報酬が支払われているような
チームがどれだけ長くやっていけるかで、
例えています。

優れた技術者に育成するために、
徒弟制度を推奨しています。

現在の組織、プロジェクトに違和感を感じる方は、
是非一読してください。

ソフトウェアもやっぱ職人芸が必要！？おもしろい本♪

この本では、
従来、「製造業」である「ソフトウェア開発業」の中で
いかに優秀な職人をそだてあげるか？
ということを命題にして、いろいろとかきまくられています。
もちろん、組織論や技術論も展開されていきます。

ドイツのマイスター制度みたいに
・熟練職人
・ジャーニーマン(親方の右腕)
・アプレンティス(見習い)
でやんなきゃだめなめんもあるそうです。
(スペースシャトルうちあげるような大プロジェクトは、従来の
「ソフトウェア工学」でもＯＫだそうです。)

ピアソンから同じくでている
「人月の神話」から引用も多く、一読に価する良書です。

・・・さて、じゃ、今日は「お師匠さん」をさがそうかな。。♪

この本読んで欲しいから、星５個つけてレビューします。

読んで、いいなと思った主張を拾います。
「工業製品の工場での生産にあたるのは、ソフトウェアにおいては出来
　上がってテストを終了したバイナリ－をCD-ROMにコピーしてるときで
　ある。コーディングやテストですら、工業製品で言えば開発・試作工
　程にあたる。ゆえに、工学（エンジニアリング）の世界での大量生産

　の成功例を当てはめる試みはうまくいかない」
これは、ホントにそうだなと思いました。

ソフトウェア開発でのプロセス（ＣＭＭとかＩＳＯとかＲＵＰとか）か、
人かという対比は、サッカーにおけるシステムか人かという問いと似てる
と思う。サッカーではそこの問題は落ち着いてきて、約束事は必要だが、

高度な組織は高度なプレーヤーがいないと成立しない、長期的な!強化
は若年層の継続的な強化が肝要、という所にだいたい落ち着いていると
思う。

ソフトウェアエンジニアもそうだと思う。約束事が少ない小規模な開発で
も、大人数で約束事が増える場合も、何をすればよいか分かって手を動か
せる職人が必要だと思う。

多くの失敗の原因を解明している

本書を読むのは開発者が多いと思うが、本当に読む必要のあるのは
管理職や経営者だろう。我々開発者は機械ではなく、生きた人間で
ある。人類の長い歴史の中で、技術者が如何にして学び、技術を継承
してきたか。その教訓を現代のソフトウエア開発にも活かすべきである。

優れた技術者は良い仕事をする。あたりまえのことだが、これを忘れ

ている経営者が多くないだろうか？　また、優れた技術者を育成する
のも優れた技術者の仕事であり、会社にとって最も注力するべき仕事
だろう。

本書の一節に、「非常に優れた技術者のほとんどは、やがて独立するか
もっと報酬の多い職種に転職する」とある。この問題をどう捉えるか、
管理職や経営者の方によく考えて頂きたい。

中々、ユニーク。ＸＰと似てるのか？

ソフトウエアの品質問題をクリアする為、新しい開発手法として、昔
からある職人の「徒弟制度」を提案している。（「品質問題」とは、
生産性、信頼性、保守性、可用性等で客等を納得させられない事。）
「徒弟制度」とは、優秀な熟練職人（親方）をトップに、一般職人、
弟子の３階層で、１０名前後のグループに開発全てを任せる。大工や

今流行の料理人等の職人の世界と同じやり方。
従来の開発手法は、全て「ソフトウエア工学的」なアプローチである
が（ＣＡＳＥ等）、機械的処理（作業）が主でない人間中心の頭で考
える作業が主のソフト開発に当て嵌めるのは無理が多いと。
よって、大規模システムではまあ良いかも知れないが、大分の中小規

模システムには向かず、むしろデメリットが多いと言う。
我々は、今在る開発手法が現時点ではまあ一番良く、規模に関係無く、
使うのがベストと思って居たが、これを見事打ち砕くくらい説得が在
る説明を、工学的が何故ダメで職人気質が良いかを、延々と判り易く
説いている。
ソフト開発に係わる人、特に始めに述べた品質の良いソフト作りに関

心在る方には、是非、一読をお勧めしたい。多分、大部分の人は、期
待を裏切られない筈。
文章は非常に読み易く一気に読める。訳書に多い微妙な言い回しなど
で伝わり難い文が多いが、本書には殆ど無い。これは訳者の力も大と
思われる。

３０年位前か？確か、ＩＢＭが「チーフプログラマ制」とか言う、

優秀なプログラマをヘッドに小人数グループによる開発体制で、生産
性や信頼性を両話題になたのと、似てて面白いと思った。

只、疑問に思ったのは、ソフトは形や技術が直接的に目に見え難い為、
評価がキチンと出来ず、これがソフトをダメにして居る最大の原因で、
この為、良い技術や職人気質の優秀なプログラマも育ち難い筈。

良い例が、新人がコーディング覚えプログラムが組めるようになると
（半年から１年）、もう先輩の話など聞こうとしない為、技術指導な
ど何も無い。このようないい加減な所で、良い技術者は育たず、又、
熟練者も技術の違いを見せ付けられない。（尤も、職人世界でも技は
指導でじゃあなく盗むらしいが(^⊥^;)…）

これに対する説明は無く、只、徒弟制度を導入しても、師弟関係が旨
く行くとは思えず、給与で差を付けるべしと言ってるが、これだけで旨く行くのか疑問。

－以上－

ここに書いてある通りだけど

いつまでも職人でやってちゃ生産性があがりません。
それとプロジェクト内の標準化や継承ができない。

当たってるけど、改善が必要。

ソフトウェア開発とは？

私は、この本を読まれる多くの方と同様に、ソフトウェア開発に従事しています。常日頃、ソフトウェア工学に基づく手順に則り（極力）、業務を行っていますが、何か違うなと感じていました。

この本では、「職人気質」という印象的な言葉により「ソフトウェア開発は人間が行っているのだ」ということを再確認させてもらえました。

ソフトウェア工学は誤っているのか？
ソフトウェア開発の失敗は、正しく、ソフトウェア工学に則った手順を踏まなかったからだ思っていましたが、この本により、自分なりに、見直してみる機会が与えられたように感じます。