ホーム

ホーム

更新を再開します

仕事の関係等によりしばらく更新が滞っておりました。
順次、不具合を含めて対処していこうと思います。

断片 (このサイトのどこかにあるもの)

いろいろ体験してよくわかった。人の性格は、その人がどんな冗談に気を悪くするかによってよくわかる。


ホームにて最新の記事の全文を読むことができます。
(読書ノートはログインしないと全文が読めません。)


ホーム > 読んだ >

ソフトウェア職人気質

書誌

authorピート・マクブリーン
editor村上雅章(訳)
publisherピアソン・エデュケーション
year2002
price2300+tax
isbn89471-44-18

目次

1感想
2抄録

履歴

editor唯野
?読了
2017..公開

ちょっと古い本であるが、一般的に流布しているソフトウェア工学に対する一種の反旗として「ソフトウェア職人気質」を提唱した本。書名にもあるように、ソフトウェア開発者をソフトウェア工学で「管理」するのではなく、職人気質を高めることによって開発者が誇りを持ってプロジェクトに参加する――という流れを促している。そのために小規模チームやインクリメンタル開発が推奨されているが、とはいえ本書の中で著者自身も触れているように、大規模開発の現場などソフトウェア工学の全てを否定しているわけではない。

個人的には職人気質という考え方は大いに賛成できるし個々の開発者が自分の携わるプロジェクトに対して責任を持って取り組むのも当然だと思うが、一方でこの種の職人的考え方は定量性に欠け、また個人の素質に左右されやすく、醸成に時間もかかるというのも事実だと思う。そのため、この本の内容もただ鵜呑みにすればよいということではなくて、行き過ぎたソフトウェア工学的アプローチを戒めるための一種の反発・警告という意味合いの方が強いのではないかと思う。

もっとも自分の仕事に対して責任を持つというのは職人に限った話でもなかろうが...

抄録

xii

-/-職人気質は、あなた個人の持つ3つの責任、すなわち、あなたの作業責任、あなた個人の向上責任、あなたのプロ意識に対する責任というものも象徴しています。、あなたの用いているソフトウェア開発手法が何であろうと関係ありません。-/-

xvi-xvii

アプリケーション開発チームが、ビジネス上で計り知れないほどの利益を生み出せる、価値あるアプリケーションをリリースしました。しかし、ソフトウェア工学のベスト・プラクティスをうまく適用しなかったというだけの理由で謝罪を要求されるのです。こういった事例を、私は何度も見てきました。チームに対する本当の評価とは、うまくリリースできるかどうかという点と、その後何年にも渡ってアプリケーションの拡張・保守が可能であるかどうかという点であるはずです。初期リリースがタイムリーに行え、それぞれの新リリースでアプリケーションを改善できるかどうかなのです。

1

-/-ソフトウェア工学というものは、NATOにおける大規模システム構築プロジェクトにおいて発生した問題を解決するために考え出されたものです。-/-

5-6 cf.11

ソフトウェア開発に必要な要員。

  • 要件をドキュメント化するためのアナリスト
  • 要求仕様書を作成するためのデザイナ
  • コーディングを行うプログラマ

9 cf.17-18

ソフトウェア工学における最大の問題は、「体系的」かつ「規格化」された「定量的アプローチ」が唯一可能なアプローチであると仮定している点です。ソフトウェア開発に機械工学的なメタファを導入することで、私たちはそれに代わる道を探すことを止めてしまうのです。この問題における古典的な例として、ソフトウェア工学における「潜在欠陥数」と「欠陥除去率」という概念を挙げることができます。

  • 潜在欠陥数 : ソフトウェア・プロジェクト中に存在すると予想される誤りやバグの総数のこと
  • 欠陥除去率 : ソフトウェア・プロジェクトが顧客向けリリースを行うまでに除去した欠陥数と潜在欠陥数の比のこと
  • こういった機械的な観点は、「すぐれた開発者ほどまちがいをあまり作り込まず、血管の検出にも長けている」という事実を無視しています。つまりソフトウェア工学は、「ソフトウェア開発者の熟練、知識、経験こそがプロジェクトにとって本当に必要なものである」ということを忘れさせるのです。

    もっとも、そういう個人のスキルに依存しないために、マニュアルだとか規約が出てくる側面もあると思う。言い換えれば基準を要員の上に合わせるより下に合わせるというか...

    12

    -/-ただし、(ソフトウェア開発の自動化は:唯野注)人間同士の様々なやりとりが含まれていない、定義済みのプロセスしか自動化することができないのです。-/-

    19

    ソフトウェアの開発プロセスでは、明確な知識と口に出されることのない知識の双方をソフトウェア中に具現化しなければなりません。Howard Baetjer は、分散された知識学習の調和こそがソフトウェア開発の鍵であり、「私たちの行おうとしていることに対する理解力」こそが主要な障害になっていると指摘しています。

    20

    大昔のソフトウェア開発では、コンピュータをプログラミングすること自体が難問であったため、こういったことはさほど重要視されていませんでした。しかし開発者によって、より優れたプログラミング手法が徐々に作り出されるにつれ、難問は設計作業へとシフトしていったのです。そして現代のプロジェクトの多くでは、要件定義工程、および要件をソフトウェア設計に反映する方法が主な難問となっているのです。

    ところが、そんなことはないのです。作業をより細かい手順に分割すればするほど、ある要因から別の要員への情報引き渡し時間が掛かるようになってしまいます。流れ作業というアプローチは、機械的作業に対してならうまく機能するのですが、知的作業に対してはまったく機能しないのです。

    27 cf.25

    私はソフトウェア開発というものが、効率的なシステム調達を目的とした、芸術、科学、工学の創造的な調和であると考えています。そしてこういった考え方を語るには、ソフトウェア職人気質というメタファを用いるのが最善なのです。ソフトウェア職人気質というメタファによって、開発者は自らの成果物に、測定可能な機械的観点と同様、美術的および芸術的な観点を見出すことができるようになるのです。

    34

    CASEツールがプログラマを不要にするという展望も、ソフトウェア開発で最も難しい作業がコーディングではなくなった時点で、単なる神話となりました。-/-

    34 cf.35

    -/-しかし技芸の世界では、全員が個人の能力や才能にあったプロセスを採用するようになっているわけです。大事なのは成果物であり、それを達成するためのプロセスではないのです。

    37 cf.39

    -/-開発者が認定試験に合格しているという事実は、有益なアプリケーションを開発する上で必要となる開発者の能力については何も述べておらず、その開発者が試験に合格する方法を学んでいたという点を述べているにすぎないのです。

    45

    -/-つまり、物事というものは考え方だけで変わるものではなく、その考え方に従って行動し、その考え方に基いて判断することで、初めて変わってくるわけです。

    48

    機械工学の世界では、職人気質が今や現実的でない理由について、経済的観点からの議論が数多くなされています。まず第一に、実際の品物を製造する際のコストが挙げられています。ここでの問題は、職人が工芸品を作るための時間に対する対価を、それぞれの顧客が支払わなければならないという点です。この問題に対する解決策は、より安く、より迅速に製造できるよう、量産化できるような形で品物を設計することです。-/-

    よくできたオーダーメイドを目指すということ。

    51

    もしも50%の製品満足度を達成したいのであれば、大衆全体を50%満足させるような方法ではだめなのです。これを実現するには、人々の中から50%を選抜し、彼らを100%満足させるしか方法はありません。しかしこれによって、予想以上の成果が期待できるのです。そして市場の10%をターゲットとし、彼らを100%満足させることができれば、ずっと大きな成功を得ることができるでしょう。-/-

    51

    ユーザと購入者のこういったジレンマを無くすには、「ユーザ自身が本当に必要とするものは、たいていの場合ユーザ自身が見つけ出す」ということを肝に銘じておくことです。ソフトウェアがゆーざのニーズにぴったりと適合する本当に素晴らしいものであれば、それはすぐに購入品リストの先頭に載ることになるのです。

    52 cf.59

    開発者として自身の作品に署名することによって、自らの成果物を放棄することなく、使用中に発生した問題に対して責任を持つという意思を明確にするわけです。このスタンスは、現在のソフトウェア・ライセンスによる「現状渡しでの販売 : 本ソフトウェアに対する一切の責任を負いません」というものとは大きく異なっています。もちろん、誤りの結果として引き起こされる理不尽な要求を抑止するため、何らかの保護は必要です。しかしそういったことと、ゆーざが問題やバグの報告を行ってきた場合、責任を放棄してユーザにその責を負わせることとはまったく違っているのです。

    56

    基地のバグを残した状態で出荷するなんて、とんでもないことです。品質および信頼性の高いソフトウェアを製造するということは、ソフトウェア職人が既知のバグすべてを製品の出荷前に修正していることを意味しているのです。隠れた欠陥はあるかもしれませんが、それが発見させる可能性はさほどありません。既知の欠陥がまったくないソフトウェアを出荷することは、コスト面から見ても妥当な範囲で十分に可能なのです。ソフトウェア開発において本当にコストがかかるのは、隠れた欠陥が問題を引き起こす可能性を削減する際の作業です。安全性を重視するシステムでは、隠れた欠陥が存在する可能性を極端に低いものにしなければならないため、多くの時間と努力がその確認のために費やされることになるわけです。-/-

    57

    -/-マイナスの修正度合いとは、プログラマの宴会で古くから歌われている、「プログラムの中にゃバグが99個、1個直せばバグは100個」("Ninety-nine bugs in a program, fix one bug, now there are 100 bugs in the program.")によって的確に説明されています。-/-

    58

    値札だけを基本にして仕事を発注する慣習は終わらせましょう。代わりに長い目で見たトータル・コストを最小化するのです。

    驚くにはあたりませんが、ソフトウェア職人はプロジェクトの発足前に顧客の評判を注意深く調べるのです。それを行なわないほど彼らは間抜けではありません。とどのつまり、彼らの評判は一連の成功したプロジェクトの上に築き上げられるものだからです。そして、プロジェクト成功への鍵は、良い開発者のチームと良い顧客がともに作業をすることなのです。

    60 cf.70/89/103

    そうです、文字通りに捉えてください。優れた開発者には、彼によって置き換えられるすべての開発者と同じくらいの金額を支払う価値があるのです。小規模チームによって生み出されるアプリケーションは、ずっと優れたものになるため、こういった決定は経済的にもペイするわけです。チームが小さければ、優れたソフトウェアを生み出すことができるのです。

    63-64

    こういった信頼関係のバランスをとる方法は、進化型の開発を伴うインクリメンタル開発手法を採用することです。新たな機能を開発、検証する度にそれを本番稼働させるのです。-/-

    64-65

    顧客は、スケジュール、リソース、機能、欠陥のうちからアプリケーションにおける優先項目を選択し、適切な「ミッション・プロファイル」を定義するわけですが、Highsmithの定義によれば、顧客はミッション・プロファイルの中で、いずれかの品質項目を「卓越」(excel)と選択し、さらに後1つの項目を「向上」(improve)と選択することができます。残った2つの項目は「受容」(accept)と分類されます。-/-

    65

    -/-より重要なのは、発見された欠陥が迅速に修正できるようになっているということです。

    66

    大規模プロジェクトの場合、管理の移行といったものは一般的に何らかのファンファーレとともにアナウンスすることが重要なのです。

    71

    -/-(ソフトウェア職人気質における:唯野注)管理者に必要なものは、世話役と指導担当者としての役割を果たすスキルであり、すべてのものをコントロールしようとする何でも管理者は、じきにお払い箱になってしまうのです。

    73

    ー/-マシンは高速化し、メモリはたっぷりあり、プログラミング言語も変わってきましたが、ソフトウェア開発における技芸の基本、つまり真の問題を理解しているかどうか確認し、じっくりと厳しい目で簡潔な解決策を模索し、見つけ出した解決策は、まず小規模の例で検証するということは変わっていないのです。

    78

    ソフトウェア職人気質は、ソフトウェア工学が開発者に強制するような、極端な役割分担を否定し、「仕事を最初から最後まで、すべてやり遂げることができる真の職人を高く評価」します。つまり職人気質は、ユーザや顧客のニーズに見合った成果物を作り出したと開発者が自信を持って言うためには、自分自身で最初から最後まで一貫して開発に関与するしか方法はないとしているわけです。-/-

    79

    -/-伝統的な技芸を身につけようとした場合、たんなる学校教育だけでは不十分かつ非効率的です。その理由は、学校教育では技芸の徒弟制度を支える大黒柱である状況学習(situated learning)と正統的周辺参加(legitimate peripheral participation)という考えが無視されてしまうからです。-/-

    81

    徒弟制度は、特定の技術やテクノロジを学習することよりも、態度や考え方を繰り返し教え込むことに焦点を当てているため、どうしても時間がかかるのです。そして徒弟制度とは、単なる技芸の学習以上のものであり、新人に対して(職人の域に到達できた際に)社会でどのように振る舞えば良いかを教えるものなのです。つまり徒弟制度では 、熟練職人がどのように技芸と取り組んでいるのかを間近に見ることで、評判というものに対する深い意味を時間をかけて学習するのです。

    ソフトウェア開発における、産業化されたソフトウェア工学の観点と、ソフトウェア職人気質の立場の違いは、訓練された技術者と熟練職人の違いとなります。訓練された技術者は書籍に従い、指示された通りのことを行います。これに対して、熟練職人は多くの質問を投げかけた後、あなたが本当に必要としているもの(あなたが実際に要求したものよりも素晴らしいものかもしれません)を調達するのです。

    83

    -/-そして探し出す際の鍵となる質問は「彼はソフトウェア開発の技芸に対する自分の意気込みと熱意を、同僚に伝染させたことがあるだろうか ?」ということです。

    87 cf.88

    -/-才能と熟達は同じものではありません。熟達とは、高品質で堅牢なアプリケーションを構築し、うまく拡張する能力のことなのです。これには、ユーザのためにアプリケーションを保守する責任、および自分が次のアプリケーションに移る場合に備えて、保守担当となる他の開発者を育成する責任を引き受けることも含まれているのです。

    91

    開発者が実際のプロジェクトで作業する際に役立つような大学の講義は、ほとんどありません。問題は、大学が採用している学校教育モデルに従うと、十分な指導や助言を与えることができないという点にあります。-/-

    91

    プログラミングを始める最適な方法は、対話型で言語が実行できる端末を用意し、傍にその言語をすでに知っている友人を座らせ、いつ割り込んでも良い状態で何かほかのことをやっててもらうようにすることです。そして、プログラミングの感触がどういったものかが判るまで、自分で色々と試してみるだけです。そうすれば、うまく動作するプログラムを書けるようになるでしょう。

    93

    ソフトウェア職人気質は、徒弟制度によって、初心者と熟練職人との間に指導や助言を行う関係を作り出します。これを実現するため、ソフトウェア職人気質によって徒弟制度に対する組織的な支援が行われます。-/-

    95

    -/-こういったことは、熟練職人によるレビューを数人分の作業のみとし、そのレビューも二次レビューにすることで、詳細に行うことができるわけです。つまり、熟練職人によるアプレンティスの作業レビューに先立って、その作業を他のアプレンティスやジャーニーマンがレビューし、その際のフィードバックに基いてエラーを一掃しておくのです。ソフトウェア工学のパラダイムでは、この種の二次レビューを時間の無駄と考えるかもしれませんが、これはどのような技芸の実践においても必要不可欠なことなのです。フィードバックなき実践は、単なるエラーの積み重ねでしかないのです。

    96

    ソフトウェア職人気質では、アプレンティスに2つの重要な役割が割り当てられます。彼らは、探究好きかつ探索好きな学習者になるとともに、ソフトウェアを作り出す開発者にもなるのです。-/-

    これに従ってアプレンティスには最初はプロジェクト内の自家製ツールなどの保守を行ない、徐々に顧客アプリケーションの開発へと携わるようにする。

    99

    徒弟制度では、技芸の文化と倫理を身につける期間が必要となるため、その道のりは長いものとなります。ソフトウェア開発における大きな問題として、何かを行う方法というものは、その方法を探る根拠について深く理解していなければ、非効率的な形でしか実践できないという点を挙げることができます。そして、こういった理解を培うには、長い期間が必要なのです。多くのプロジェクトで高いストレスが生み出されている理由は、こういった理解の欠如によって説明することができます。-/-

    103

    -/-ジャーニーマンは常に、少なくとももう1人のジャーニーマンもしくは熟練職人と作業を行って、アプリケーションについての詳細知識を最低でも2つの頭の中にしまっておくべきなのです。-/-

    105/106

    ソフトウェア職人気質はソフトウェア工学の代替ではなく、それを補完するものです。-/-

    優れた開発者で構成された小規模チームであっても、解決することができない問題は存在します。-/-

    109 cf.125

    ソフトウェア工学の世界では、「ウォーターフォール型」のソフトウェア開発ライフ・サイクルは非効率的であるという「リップサービス」を行っているものの、いまだにそれが大勢を占めています。-/-

    110

    -/-この重大な違いによって、ソフトウェア工学とソフトウェア職人気質の違いを説明することができます。ソフトウェア工学とは、ハードウェアとソフトウェアを組み合わせたものであるのに対して、職人気質は既知のユーザに対して既知のハードウェア上のアプリケーションを調達することに注力したものなのです。

    114

    -/-安価なソフトウェア工学は、ソフトウェア工学ではないのです。低予算で進めることは、うさんくさいソフトウェアを作り出すための危険な近道でしかありません。-/-

    114

    事例を色々と見てみると、プロジェクトというものは遅れ、予算を超過する傾向にあることが判ります。これは、恐らく真実でしょう。プロジェクトの多くは、予定されていた時間を超過するのです。しかし、「当初に見積もられた所要時間」を超過したような事例は、ずっと少なくなります。つまり問題にしなければならないのは、プロジェクトの遅れではなく、「根拠のない見積もり」なのです。言い換えれば、こういったプロジェクトは、「スケジュールに対する過度のプレッシャー」によって被害を被っているのです。

    115

    こういった考え方(科学的管理法、scientific management : 唯野注)は、熟練を要しない労働における生産性向上に寄与したため、1920年代から30年代の産業世界を支配する考えとなりました。それ以降、この考え方は現在に至るまで、かんり側の頭の中を支配し続けています。実際、あまりにも広く普及してしまったため、私たちはいったん立ち止まって考えることさえしなくなっています。つまり、科学的管理法の大きな成功によって代替策を考えることが事実上不可能になってしまっているのです。-/-

    119

    問題は古くから存在している悪魔、すなわち機械的メタファなのです。調査報告書にもあるように「ソフトウェアは過ちが露呈されるまで正しいと見なされるべきであるという観点が採られていた」(一部強調しています)と述べられています。こういった観点は機械的なものに対してはうまく当てはまるかもしれませんが、ソフトウェアにはまったく通用しないのです。-/-

    119

    -/-Jim Highsmithが指摘したように、「プロセスを得ることとそのプロセスを実行するスキルを得ることは違う」のです。この考え方によって、ソフトウェア工場というものが実際の工場のように機能しない理由が説明できます。-/-

    120

    ソフトウェア工学は、スキルの幅が狭い、見せかけだけの専門家を作り出すことで、1人の人間ではアプリケーション全体を理解できないようにしてしまうのです 。-/-

    121

    組織は、開発を効率的に行うという観点よりも、監視や管理の目的でプロセスを採用する傾向があります。そして組織にとっては、すべてのプロジェクトを同じ手法で扱う方が簡単であるため、「すべてにフィットするフリーサイズ」のアプローチを試みるのです。その結果、チームによっては、プロセスにしたがっていると見せかけながら、進捗させるためにプロセスに従わずに作業を行うというおかしなことが引き起こされてしまうわけです。

    123

    要するに、開発者が学習可能であることを忘れ、単に交換可能なリソースだと考えることによって、ソフトウェア工学はスキル不足を人為的に作り出しているわけです。これは、個人を忘れ去るという、ソフトウェア工学がもたらす必然的な結果なのです。

    132 cf.143

    ソフトウェア職人気質では、ドキュメントは常に時代遅れで間違っているという問題に対して、インクリメンタル開発を用いて対処します。-/-

    137

    プロジェクトを成功させたいのであれば「そこにいて、やることをやっている」者を選ぶことです。つまり、あなたがすでに知っている、そして信頼している者を選ぶことです。それだけのことなのです。ソフトウェア職人気質は、成果物に対する評判という土台の上に確立された長期の信頼関係の上に築き上げられるものなのです。

    138

    もし名前が聞き出せたら、推薦を依頼した職人に、あなたを含めた3人で会議を行う手はずを整えてもらいます。3者会議によって、自身の評判が賭けられていることを、双方の職人に対してあらためて明確にしておくわけです。また、3人が一堂に会することで個人のつながりが強調されるのです。

    139/140

    ポートフォリオをレビューする際、同じ規模のプロジェクトで成功したという実績を探してください。-/-

    私は、プロジェクト規模のこういった不一致によって深みにはまったプロジェクトを数え切れないほど見てきました。-/-

    141

    過去に開発を成功させた際、一緒に作業していた開発者達を同じチームに招集すると、高い生産性がもたらされるという傾向があります。-/-

    142 cf.145/147

    本当に優れた開発者は、1人で平均的な開発者5人分以上の価値をプロジェクトにもたらすのです。彼の給与を算出する際は、アプリケーション調達が遅れた場合に被るコスト、および機会損失について考えてみてください。-/-

    同様に経験に対しても支払う。

    144

    最先端のテクノロジとは何でしょうか ? それはチームが経験したことのないテクノロジすべてです。-/-

    152

    -/-これによって最終的に開発者とユーザは、アプリケーションが絶対に「完成」しないこと、ビジネス・ニーズに合わせるために共同作業を行ってアプリケーションを進化させていくこと、そういった進化を止める理由は何もないことに気づくわけです。

    こういったことに気付くことが、ソフトウェア職人気質における重要なテーマなのです。アプリケーションはずっと使われるものであり、構築した担当者よりもずっと長く残ることもあるという可能性について、最初のアプリケーション構築時に考えておきさえすれば、その可能性は簡単に現実のものとなるのです。-/-

    155

    -/-つまり、柔軟性やコンフィギュレーション可能性が必要かどうかを判定するための問題領域の調査に十分な時間をかけておらず、また簡潔で変更が容易なアプリケーションの構築にも失敗しているわけです。その代わりに、2つの戦略をそれぞれ中途半端に取り入れようとして、いつの間にか保守にかかる全体コストを増加させてしまっているのです。こういった罠に陥らないようにしてください。-/-

    157

    アプリケーションとデータベースを分離することについては、あまり進んでいるとは言えません。SQL(Structured Query Language)という標準化努力にも関わらず、データベースの世界では、「標準化というのはあまりにも素晴らしいものなので、各社がそれを持つべきだろう」という昔からあるジョークを地で行っているかのようです。-/-

    161

    テストや保守のための設計を行う際に最も大きな問題となるのは恐らく、十分な診断機能や計測機能をアプリケーション中に構築することでしょう。-/-

    163

    -/-つまりアウトソーシングによって、開発チームはアプリケーションの保守を行わないことになるため、アプリケーションに関する経験の蓄積が妨げられてしまうわけです。-/-

    169 cf.170

    ソフトウェア開発者には、良い記憶力、非常に優れた学習能力、そして偉大な忘却力が必要です。中でも忘却力は、永続的な学習の鍵であるため、最も重要な能力と言えるでしょう。ソフトウェア開発分野は常に変化し、進化しているため、学習することが重要なのです。-/-

    178

    ソフトウェア開発は楽しくなければなりません。そうでなければ、そのプロセスは間違っているのです。

    Up