無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
ソフトウェア職人気質: 人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series 別巻 7) 単行本 – 2002/3/1
- 本の長さ183ページ
- 言語日本語
- 出版社桐原書店
- 発売日2002/3/1
- ISBN-104894714418
- ISBN-13978-4894714410
この商品を買った人はこんな商品も買っています
商品の説明
メディア掲載レビューほか
スペースシャトルの設計とワープロ・ソフトの開発は違う。当たり前のように思うかもしれないが,これらを一緒くたに扱ってきたのが従来のソフトウエア工学だった,と著者は喝破する。代わって著者はソフトウエア職人気質という“思想”を提示し,生産性向上のための新たなシステムと人材育成手法を示唆する。
従来のソフトウエア工学は,ソフトウエアを「工業生産物」としてとらえてきた。その開発は「工場内の流れ作業」であり,「いくらでも代替可能な開発者が定量的に投下できる」と見なしていた。重んじられるのは開発者よりも管理者であり,経験や熟練よりも資格の有無であった。
宇宙開発や軍事開発など,国家的な巨大プロジェクトでは,従来のソフトウエア工学の手法は有効だった。そもそも,巨大プロジェクトにおける必要性からソフトウエア工学が誕生したのであるから,当然といえば当然である。
しかし,その手法が商用ソフトウエアに適用されると様相が一変してしまう。
人員は膨らみ,コストがかさむ。その一方で,ソフトウエアには「クール」な機能が次々と付け加えられていく。機能が飽和状態となり,明らかに使いにくいものであっても,悪いのはそれを使いこなせない「間抜けなユーザー(lusers)」ということにされてしまう。開発に人員が過剰に投下されながらも,保守はないがしろにされるため,ますますこんがらがったソフトウエアが出来上がっていく―著者は従来のソフトウエア工学の問題点をこのように描く。
こうした現状を踏まえて,ソフトウエア工学そのものの変革を唱えているのが本書である。
まず,従来のソフトウエア工学的なメタファから「職人気質」というメタファに切り替えよ,と筆者は主張する。顔の見えないソフトウエア開発者より,自分の「作品」に責任を持つソフトウエア職人を重んじたほうが,結果として生産性の向上につながると説く。後継者育成という観点においても,「職人的な徒弟制度の方が,従来の学校や資格制度よりも有効」と指摘する。
職人気質や徒弟制度と言うと,いかにも前時代的な考え方に聞こえる。「工芸品を作るのには適しているのかもしれないが,近代的な生産物を作るのにはあまりにアナクロな発想だ」。だれもがまずそう考えるだろう。
しかし,そのとき我々は「ソフトウエアとは工業生産物である」という観念に知らず知らずのうちにとらわれてしまっているのではないか。そうした意味で著者の主張は新鮮だ。
著者は職人気質のメリットとして,「自分で考え,個人あるいは少人数グループで理解可能な“作品”を作り出すから,ユーザーとの乖離かいりがないこと」や,「ソフトウエアにクレジットを入れることによって,仕事に対して責任が持てるようになること」などを挙げる。
後継者育成についても,「アプレンティス(弟子)」,「ジャーニーマン(一般職人)」,「熟練職人」といった徒弟制度のメタファを提示して言及している。このメタファからは,ソフトウエア工学が長年見捨てようとしてきた熟練の「技」を再発見できる。
(日経コンピュータ 2002/06/03 Copyright©2001 日経BP企画..All rights reserved.)
-- 日経BP企画
内容(「MARC」データベースより)
登録情報
- 出版社 : 桐原書店 (2002/3/1)
- 発売日 : 2002/3/1
- 言語 : 日本語
- 単行本 : 183ページ
- ISBN-10 : 4894714418
- ISBN-13 : 978-4894714410
- Amazon 売れ筋ランキング: - 653,711位本 (本の売れ筋ランキングを見る)
- カスタマーレビュー:
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
ソフトウェア開発は、一生続けられる職種です。そこで日々新しいことを学び、後に続く者にそれを伝え、育てていくことが必要です。
そういうことに目を向けさせてくれます。
要求を出すのはオーナー、要求を分析しシステムにマップするのはソフトウエア技術者です。
優れたソフトのためには要求の質もさることながらシステムへのマッピングも重要な要素です。
本書はそこを言っているのではなく、要求仕様に対してソフトを効率よく品質よく作り出すアプローチは家内制手工業の職人の世界で行うのがよいと述べています。
適応範囲はミサイル防衛システムなんかの巨大なものは除くけどたいていの民生ソフトはこのアプローチで十分とのこと。
職人は自分の作品に誇りを持って常によいものを作りだそうと日々精進している。
幾人かの弟子を取り後継者も育てている。
再生可能かつ発展的なエコシステムといえます。
著者はソフトウエア工学的手法を対立させていますが、
これは特徴を目立たせるためで特に気にする必要もないと思います。
ただ全ての作業手順において一切の妥協を許さないことの硬直性は害があるというレベルでしょう。
職人とはそもそも頑固一徹なので妥協を許さないのは近代工場の工場長以上ではないでしょうか。
その妥協を許さないベクトルの違いはあるでしょう。
他の方の書評中にTQCとか品質向上の取組によって80年代には日本でも本書と同様のことが行われていたと
いわれている方がいました。
当時を知る者として看過できないので一言。
TQCを開発現場で取り入れていたのは母体が通信、工業などTQCが活発な企業の系列で一般的ではありませんでした。
ソフトウエアの品質に関してはまさしく工業製品には品質の要素というものがありそれをソフトウエアに適用するのだという
ソフトウエア工学手法そのものであり、現場としてはかなり冷笑的に見ていました。(冷笑的に見ていた部分が職人的だということなら同意ですが)
本書が名著であるか私には判断できません。
職人気質的エコシステムが主流になるか否かによって決まるのではないでしょうか。
現在の開発現場においても職人は数は少ないのですがいらっしゃいます。
エコシステムができているかというとこれは微妙ですね。仕事のできる人の周りには人が集まるというところまでは
観測できますが、職人が後継者を育てているかというとそういう環境にないといわざるをえない気がします。
ここは残念です。
もうひとつ、ソフトウエアのプログラミングとは建築、工業のメタファで製造と言われますがメタファとしては工業・建設の設計作業に該当します。本書はにもかかわらずエコシステムの評価によって職人と言っています。
職人は最終製品まで作る(中間産品のこともありますが)ので設計製造を行うわけですが、
プログラマが行うのはメタファとして設計(および設計検証としてのテスト)まで。製造を行うのはコンパイラ、リンカ、デプロイスクリプトです。
この微妙な違いがメジャーにならない理由なのでしょうか?
管理職や経営者だろう。我々開発者は機械ではなく、生きた人間で
ある。人類の長い歴史の中で、技術者が如何にして学び、技術を継承
してきたか。その教訓を現代のソフトウエア開発にも活かすべきである。
優れた技術者は良い仕事をする。あたりまえのことだが、これを忘れ
ている経営者が多くないだろうか? また、優れた技術者を育成する
のも優れた技術者の仕事であり、会社にとって最も注力するべき仕事
だろう。
本書の一節に、「非常に優れた技術者のほとんどは、やがて独立するか
もっと報酬の多い職種に転職する」とある。この問題をどう捉えるか、
管理職や経営者の方によく考えて頂きたい。
考え方の基盤が古過ぎて、時代に取り残されているということだけがよく理解できました(';')
身近で何人も見てきました。
彼らの技術の奥深さ、知識の豊富さには神がかりと思えるほどに凄みを
感じるものが多いのは紛れもない事実です。
NCマシンやCAD/CAMが進化したとは言っても、製造の現場では定量化され
ていない事象があまりにも多く、思ったようには進みません。
そのため、定型処理や荒加工は自動化できても、納品できるレベルに達
するには職人さんに頼ることも多く、彼らなしには製造業は立ち行かな
いのが現実としてあります(「勘所」という奴ですね)。
本書は半ば強引な論調に思える言い回しもありますが、対比によって
理想=ソフトウエア工学(NC機械)
現実=クラフトマンシップ(職人)
を浮き立たせ、一見相反する存在の特性をうまく表現しています。
開発技術の具体例を述べているわけではないので、そういう話を期待す
るとガッカリすると思いますが、理想と現実に振り回されがちな開発者
達に対して健全な心構えのあり方も示しており、その意味では個性のあ
る良書だと思いますね。
自分が思っていることとあまり違わないことが書いてあるので、ほとんど読まずに積ん読していました。
多くの書評(レビュー)を読むと、様々な立場で、この本を読んでいる事が分かりました。
「100人未満のプロジェクトでは、ソフトウェア職人気質に則ったアプローチの方がより効率的になります。」
という記述は、自分の経験則からも妥当だと思う。ただし、能力が低く、なおかつ能力にばらつきがある場合には、10人になったときから、ソフトウェア工学によった方がよいかもしれない。
職人気質を問題にするには、そこまでの質の高い職人がいる場合だけである。
そうでない多くの人たちには、関係ない世界かもしれない。
職人という響きに何も感じない人は、読まない方がよいかもしれない。
当時流行りつつあったペアプログラミングやエクストリームプログラミング、アジャイル開発はその実現例の一つでしょう。
また、自分の関わったプロジェクトに自分の名前を載せる、というのは今後のキャリア形成でも有効です。
#アニメSHIROBAKOでもあった「作品のクレジットは名刺代わり」というのと全く同じでしょう
現代的なプロジェクトやプロセスの背景を知るための歴史的古典という位置付けですが、ぜひ電子書籍化して永く販売して欲しい1冊です。
実作業をとおしてしか体得できない、「設計の勘所」「知恵」のようなものだ。単なる「知識」でもなければ、個々の「技術」でもない。それぞれの
技術を実作業の文脈のなかで、有機的に連動させ発動させるセンス=「技能」と、その原動力となる「仕事へのプライド」、そしてその伝承の方法。
これらが一般的な開発において最も重要なもので、工学のメタファーで
それらが「負なるもの」とされてきたことが問題だという。
それは、標準プロセス導入や言語研修の充実、資格制度等とは全く無縁の
領域。かろうじてナレッジマネジメントで「暗黙知の共同化」として語られ
る部分かもしれない。ISOやCMMで何を失ってはならないか、開発現場に疎い企画・導入部門の方にも是非一読を薦める。






