|
漁師プログラマ
山崎敏 YAMAZAKI Satoshi
vol.08 |
|
|
●●ある日 |
|
|
●名前も知らない小さな映画館で
筆者は，名前も知らない小さくて古めかしい映画館に1人座っていました．椅子はギシギシと音を立てるほど古く，床は誰かが飲み物をこぼしたあとなのか，靴底を通してベタベタとした感触が伝わってきました．そんな小さな不快感と，この映画だけはなんとしても見ておきたいという想いとともに座っていました．この直後，一生に1度あるかないかの体験をするとも知らずに．
●『七人の侍』
その映画館で上映されていたのは，なんと『七人の侍』（"54／日）だったのです．なぜその映画を観ようと思ったのか，なぜその映画館で『七人の侍』を上映していたのか，今となってはまったくの謎なのですが，なぜかその場にいたのです．そして，物凄い衝撃を受けたのです．
それまで筆者は，完全に邦画を馬鹿にしていました．おもしろくもなんともないと思っていたのです．
ハリウッドの映画のほうが，何倍も派手だし，爽快感があるし，楽しいし，邦画なんて暗いだけでおもしろくない．ましてや白黒の時代劇だなんて…，そういった先入観がありました．
●ぐぅの音も出ない
そんな筆者は3時間後，完全に叩きのめされたのです．「ぐぅの音も出ない」とはまさにこのことでした．とにかく凄い作品だったのです．「日本人にもこんなに凄い作品を創る監督がいたんだ」という衝撃です．それまで日本人には映画は撮れないと思っていた筆者の思考は180度変わりました．「なぜ世界に通用する日本人監督が出てこないのだ!?」という思考に…．
その後，黒澤明監督の作品に次々とハマるのですが，今でも『七人の侍』にスクリーンで出会えたことを嬉しく思っています．
|
|
|
●●映画から見えるモノ |
|
|
●映画とXP
『セブン』（'95／米）や『リーサル・ウェポン』（'87／米）などの刑事モノの映画を観ると，たいていは新人の刑事とベテランの刑事がペアで動いています．映画の構成としてもおもしろいのですが，実際の警察官の方たちも基本的に2人1組で行動するそうです．1人が必ず後方支援（バックアップ）できる形で動くという現場から生まれた知恵なのでしょう．
これを考えると，XPのペアプログラミングという考え方はそれほど特殊で突飛な考え方ではないことがわかります．
●映画と人海戦術
『プライベート・ライアン』（'98／米）という映画の最初の10分ほどにノルマンディ上陸作戦を再現したシーンがあるのですが，このシーンを見ると「人海戦術」という方法論が，人としていかに愚かで情けない戦術であるかがよくわかります．デスマーチのプロジェクトを抱える管理者に観てもらいたいと思う作品です．
|
|
|
●●映画とソフトウェア開発 |
|
|
●ソフトウェア開発と似ています
筆者は，映画を撮るという仕事に少しあこがれるところがあります．作品というモノを世の中に残すことが，ソフトウェア開発と似ているからです．大量の人を投入しても，早く完成させることはできないという点も似ています．ただ，映画の場合は完成後の保守や再利用を重視するといった考え方はあまりないので，ソフトウェア開発と「まるで同じ」とまでは言い切れないところもあります．
ここで大事なポイントは，映画もソフトウェアも「人が作る（創る）モノである」ということです．
このあたりまえの事実がなぜか軽視されているようです．とにかく人を集めて大量の資金を投入すれば，『七人の侍』を超える作品を創ることができると思っている人が多いということです．
●人を増やしてもダメ
人を増やしても，報酬を増やしても，罰を増やしても，脅しても，煽（おだ）てても，働く時間を増やしても，監督の思考速度は速くならないし，作品の品質は良くならないと思うのです．むしろ，余計な雑念が入ってしまうことが心配です．これは映画監督でなくても，知的な作業である限り変わらないことだと思うのです．
●全体をまとめるのは1人
なぜ多くの人を投入しても早く完成しないのかというと，「全体をまとめる作業は複数の人ではできない」からだと思います．作品のイメージを伝え，具現化し，全体のイメージを統一してまとめる−全体のイメージを持っているのは監督1人である−ところがボトルネックなので，人を増やしてもボトルネックを解消するのは不可能ということなのです．
|
|
|
●●産地直送 |
|
|
●私たちが作りました
最近の食品偽装問題の影響なのか，デパートの地下食料品売り場やスーパーなどで「生産者の顔の見える野菜」をよく目にするようになりました．野菜や魚などの生鮮食が「私たちが作りました」と顔写真付きで売られているのです．一種のブランドの転換とか細分化のようにも思えます（注1）．
消費者と生産者の間に入る問屋や運送会社が多いほど，消費者の払う金額は上がり，生産者が受け取る金額は下がってしまいます．「末端」と言われる消費者や生産者の負担が大きいということです．最近では大手スーパーなどの企業もITを駆使して在庫や運送などのコストを下げる努力をしていて，その効果も現れているようです．
注1）昔は「産地直送」と言っていた気もしますが．
●ソフトウェア業界では…
ところが，ソフトウェア開発の業界ではまだまだのようです．ITの最先端の開発を行っているソフトウェア開発業界でITの導入が遅れているというのはなんとも皮肉な話です．筆者が感じるのは，システム（注2）の発注者と開発者の距離がとても遠いということなのです．
たとえば，ある顧客A社が「あるシステムがほしい」と思ったとします．そこで，付き合いのあるB社という小さなハード屋に仕事を依頼したとします．B社では規模の問題で大手ハード屋のC社に仕事を依頼します．ところがC社ではハードだけではシステムは完成しないということでD社という大手ソフト屋に仕事を依頼します．しかし，D社では人が足りないということでE社という子会社に，さらにE社では派遣会社F社に仕事を依頼します（図1）．
ここまで酷いケースは稀かもしれませんが，1つの仕事に対して仲介する会社が何社も絡むことはよくあるようです．
結果としてA社は多額の金額を支払い，F社は少ない金額で仕事を請け負うというなんとも皮肉な構図になるわけです．そして，仕事の仲介をした会社はマージンというか紹介料をたくさん手にしているのではないか？と疑念の思いが沸いてきます．
さらに問題なのは，金額の話だけではなく仲介の会社が多く入ることで「情報の伝達能力が落ちる」という深刻な問題です．筆者は以前から「システム開発にはコミュニケーションが重要である」と言っていますが，コミュニケーションのできないシステム開発はほぼ確実にデスマーチになります．A社やF社を筆頭に全員に辛い結果が待っているわけでもっと顧客（システムの発注者）やプログラマ（システムの開発者）にメリットのある開発体制が求められていると思うわけです．さらには体制の問題だけでなく，プログラマとしても野菜を作るように「私が作りました」と堂々と名前を出せるような人材が求められているのかもしれません．
注2）ハードウェアとソフトウェア両方を含む製品
|
|
|
●●『ソフトウェア職人気質』 |
|
|
●署名入りのソフトウェア
『ソフトウェア職人気質−人を育て，システム開発を成功へと導くための重要キーワード』（PeteMceen著／村上雅章訳／ピアソン・エデュケーション／ISBN：4894714418）という，今回のテーマのそのものズバリの本があります．
この本の中に「素晴らしいソフトウェアには署名がある」と書かれています．筆者はソフトウェアに限らず，どんなモノでも「素晴らしい作品には署名がある」と思っています．それが長く続けば「ブランド」になるとも思っています．
そもそもブランドとは，良い物を作る人たちとそれを見分けることのできる人たちとの間での誉め言葉であると思うのですが，むやみにブランド品を買いあさる人たちを見ていると，恥ずかしいというか情けない気持ちになってしまいます．…話が脱線気味なので元に戻します．
●元はハリウッド
映画などの映像作品にも「クレジットタイトル」や「スタッフロール」という形で製作者や制作に関わった人の名前がずらーっと並びます．決して製作者の自己満足のために署名しているわけではないと思います．経験を記録として残したいという現れであり，映画業界を形作るために欠かせないシステムなのでしょう．
この本にも人材確保の方法として「ハリウッドモデル」という名前で小さく取り上げられていますが，人脈といいますか，コネといいますか，人の善し悪しは数字で見るのではなく，人が感じることになると思うのです．それが，オーディションです．経験した年数や回数といった数値も重要ですが，それを体得してきたかどうかは，その人を直接見て，感じ取るしかないと思うのです．
オーディションという人材確保の方法は，それほど広く定着してはいないと思いますが，古くから現在に至るまで行われ続けているのにはそれなりの理由があると思います．映画監督（まとめ役）の「人を見る目」が勝負ということになるのでしょう．
●人力飛行機の話
筆者の好きな映画の中に「飛ばない豚はただの豚だ」の科白（セリフ）で有名な『紅の豚』（'92/日）があります．飛行艇のパイロットと飛行艇を造る女の子の話なのですが，どちらもレベルの高い仕事をしようとする達人的な想いが伝わってくる作品です．
飛行機をモチーフとする映画は多いのですが，『ソフトウェア職人気質』の本の中にも1つおもしろい話が書いてあります．それは人力飛行機の話です．ある人が人力飛行機の8の字飛行に成功したら賞金を出すと言ったのですが，その賞金を手にした人がどのような開発方法を採ったのか，どのような開発方法が効果的であったのかという話です．
この話によると，成功した飛行機の特徴は，ある優秀な開発者が精密に計算した設計に対して精巧に作られた飛行機では「ない」というところです．そうではなく，その飛行機は手直しや修理が容易なように作られていたそうです．何度も飛行のテストを行い，墜落し，修理し，改善し，またテストを行う−このループを加速する方向の開発方法であったということなのです．当然精密な設計資料がこの開発方法に追いつけるわけもなく，設計図よりも動くモノ，飛ばせる飛行機そのものを重視していたということなのです．
設計や理論よりもテストや実践を重視したということです．開発現場を熟知していたからこそできた職人的方法論であると言えると思います．知識やテクニックを駆使するだけの方法論では問題は解決できないということだとも思います．
●職人の経験
『ソフトウェア職人気質』の本には「役割分担（分業）をしないで，すべての作業を経験すべき」と書かれています．筆者もこれに同感で「経験」，中でも「成功体験」はモノを作るうえでかなり重要な要素だと思うのです．
若い人は「くやしい！」とか「ちきしょう！」といった一人前として認められたいという瞬発力（爆発力）をおもなエネルギー源にして動いていると思うのです．ただ失敗に対する免疫がないといいますか，少しの抵抗でネガティブな思考に入りやすいと思うのです．しかし，一度でも成功体験をして一人前であると認められる経験ができれば，その経験から「やればできる」とか「まだまだこんなもんじゃない」といった，失敗してもなかなかへこたれない持久力のあるエネルギー源を得ることができると思うのです．このレベルアップに至る体験は，役割分担をしてしまってはなかなか到達できない（実感できない）経験だと思うのです．
●言語という道具
ソフトウェア開発の世界では，まずプログラミング言語の習得から始まります．しかし，ソフトウェアの開発とは「プログラミング言語の学習といった道具の使い方の習得がすべてではない」ということなのです．何度も出てきますが，「経験や勘，そして慣れ」です．そういった目に見えない技や言葉にできない技の多くを学び，ときには師匠から盗み取る必要があると思うのです．
|
|
|
◆◆◆ |
|
|
これらのことから，職人や職人気質の方法論を重視すべきと思うのです．
|
|
|
●●職人気質とソフトウェア工学 |
|
|
職人気質の考え方は，ソフトウェア製品を作るのはまず「人が根本である」とし，現場の経験や熟練度，コミュニケーション能力を重視し，機動力の高い少人数のチームや個人によって製品ごとに柔軟に対応できる方法論を評価しています．とくに，ソフトウェア製品の開発プロジェクトにはプロジェクトごとの相違点が多く，同じパターンやルーチンワークといった機械的な繰り返し作業が少ないことや，各個人の経験や能力による生産性の違いを重視しているようです．
一方，職人気質と対比させられる考え方は「ソフトウェア工学」と言われています．ソフトウェア工学の考え方は，ソフトウェアを製品として完成させるための開発過程を反復可能な体系として扱います．規則化／マニュアル化を重視し，管理しやすい定量的な考え方を中心に規則（マニュアル）から逸脱することを禁じており，柔軟性の低い方法論と言われています．
とくに大量生産などにおいて分業制度を追求した結果，チャップリンの映画『モダン・タイムス』（'36／米）で風刺されるように，人を交換可能な機械の部品であるかのように扱い，人（部品）に「考えるな」と言ってしまっているところや，人が製品を作っているようでいて，実は製品に作らされてしまっているというところが問題とされるようです．
●職人とチーム
職人の3つのレベル職人気質には3つの段階があるそうです．
【レベル1 アプレンティス】
・学習段階（見習レベル）
・ある1つの方法論について学習しているレベル
【レベル2 ジャーニーマン】
・実践段階（職人レベル）
・1つの方法論については習得している．複数の方法論についてメリットやデメリットを学習しているレベル
【レベル3 マスター】
・応用段階（名匠／師匠レベル）
・複数の方法論についてマスターしている
・未知の問題に対して，複数の方法論から最適と思われる方法を選択できる
・既存の方法論にとらわれず独自の方法を試すことができるレベル
この3つのレベルから，マスター1人，ジャーニーマン2人，アプレンティス2〜3人，合計5〜6人といった少人数のチームを作り，問題と戦うわけです．ソフトウェア開発にはこの人数がベストということなのです．
●3人vs.30人
『ソフトウェア職人気質』の本の中に，「30人の普通の開発者を雇うよりも3人の優れた開発者を雇うべき」といったような記述があります．少々過激な発言にも思えますが，スポーツなどのチームプレイで考えてみるとわかりやすいかもしれません．たとえばサッカーですが，プロ3人vs.素人3人であれば点数の差が10倍以上になることは容易に想像できます．プロの世界でも7対0とか8対0という試合をたまに見かけます．では，プロ3人vs.素人30人ではどうでしょう？ちょっと想像しにくいですが，果たしてこれで互角になるでしょうか？ここでは卓越した人材はそれだけの能力があり仕事量も違うということが言いたいわけです．さらに，スポーツなどのように知識だけではなく体感として習得する「技」や「慣れ」についても比重を増やして考えるべきであるとも言いたいわけです．
映画『七人の侍』においても，達人や少人数のチームの活躍が存分に発揮されています．
●チーム
チームの優れているところは，考え方が一方的にならず，複数のモノの見方ができる点だと思います．職人を中心とした少人数のチームの良さは，言葉では説明できない技が伝わる点と，コミュニケーションというループの高速さだと思います．
たとえば，筆者は趣味でバス釣りをするのですが，最初の数年はまったく釣れませんでした．あるとき，釣りの師匠と言える人物に会い一緒に釣りをするようになってから，たくさんの知識と技を教わり，やっと1人でも釣れるようになりました．とくに釣りは上手い人と下手な人の差に歴然としたものがあります．そして，知識やテクニック以外の経験や勘に関する技によるところの差が大きいと思うのです．
●チームの人数と開発速度
チームを作るうえで，チームの人数には上限があると思います（図2）．
複数の人である1つの仕事をするうえでの効率には，必ずどこかに飽和する人数があると思うのです．たくさんの人をかけて効率が良くなるかどうかは，その仕事の内容によると思うわけです．
ソフトウェア開発の場合は，その飽和する人数が4〜6人であると思うのです．この人数より人を増やしても，開発速度は変わらないか，もしくは遅くなると思います．4〜6人という数値は筆者の感覚的な値なので信憑性はありませんが，職人気質の本をはじめいくつかの本で見かける数値なので，それほど大きく外していることもないと思います．
|
|
|
●●チームの運営 |
|
|
●『ムダとり』
『ムダとり−現場の変革，最強の経営』（山田日登志著／幻冬舎／ISBN：4344001850）という本があります．この本は，筆者がつねに大切だと思っている「考え続ける姿勢」と「実際にやってみる姿勢」について書かれています．そのあたりに，まず魅力を感じます．
中でも興味深い話は，ウォーターフォールモデルの原点ともいえるベルトコンベアによる大量生産方式の崩壊です．ソフトウェア開発で多用しているウォーターフォールモデルは，生産現場のような工場でのベルトコンベアの考え方を流用した考え方だと思うのですが，これが実は本家の工場のほうでも破綻していたという事実なのです．「1人屋台方式」や「セル生産方式」（注3）のほうが大量生産であっても効率が良いという事実です．
この話は，ソフトウェア開発においても「職人や小さいチームをいかに効率良く活用するか」が大事であることを教えてくれていると思います．XPなどのアジャイルな開発方法が注目される理由もわかる気がします．
また，「ベルトコンベア方式の大量生産では作業員に考えるなと言っている」「ベルトコンベア方式は一番能力の低いところに全体のペースを合わせることになる」「大量生産の時代（注4）は終わった」といった，興味深く共感できる記述が多くあります．
注3）「1人屋台方式」や「セル生産方式」については，筆者が解説するよりも，『ムダとり』の本を読んでいただいたほうが正しく伝わると思います．
注4）1人が考えて，みんながそれに従う時代．
●川型から山型へ
少人数のチームを形成すると，川型のチームができてしまう場合があります．それぞれの人の能力は高いのですが，お互いにお互いの仕事の内容が理解できないといいますか，理解しようとしていない状態です．もう少し書くと，お互いに自分の担当分野には「干渉しないでほしい」「自由にやらせてほしい」と思っている状態です．
たしかに，その人はその分野のプロかもしれません．しかし，その人の仕事の内容が誰にも理解されないのであれば，本当に素晴らしい（プロらしい）仕事なのか，それとも本当は簡単なことなのに難しく装っているだけなのか，周りからは判断できないと思うのです．そして，その人がいないときに保守などでその人の担当分野の修正や変更が必要になった場合に，それを補える人がいないという問題につながると思うのです．
流れ作業による作業の分業化が進み，作業が細分化され，専門化され，俗に言う「縦割りの社会」ができました．これが川型の組織です．不干渉主義とでも言うのでしょうか．営業担当者は開発者の仕事を詳しく知りませんし，開発者は営業担当者や顧客の仕事を詳しく知りません．顧客は発注先でどんな作業が行われているのか知りませんし，管理者は個々の担当者の顔を知っていても具体的に何が行われているのか詳しく知らないのです．ここまで酷いチームはなかなかないとは思いますが，それに近い状態はあるようです．
筆者の理想を言わせていただけるなら，コミュニケーションを密に行い，山型のチームを作るべきだと思います（図3）．
お互いがお互いの仕事を理解し，お互いの技術力の高さを認めるわけです．1つの分野を極めるのも重要ですが，ほかの分野の仕事もある程度知る必要があると思います．
●単能工から多能工へ
『ムダとり』の言葉を借りるなら「単能工から多能工へ」となるでしょう．「木を見て森を見ず」といいますか，「戦術を見て戦略を見ず」といいますか，マクロな視野が必要なのです．井の中の蛙の集団にはなってはいけないということです．
最近はコラボレート（collaborate）という言葉が流行っているようですが，ジャズなどの音楽作品の世界では昔から行われてきたことですし，この場合もお互いのコミュニケーションが最重要であって，各個人が自分の理想を求めて勝手に突っ走ってしまったら，それは作品になりえないと思うわけです．
サッカーチームも川型ではなく山型が望ましいと思います．それぞれの能力がいくら高くても，パスが通らなければゴールまでボールを運ぶことが困難だと思うからです．
|
|
|
●●トレードオフ |
|
|
●時間，機能，品質
ソフトウェア製品に限らない話ですが，製品の開発にはトレードオフがあります．それは「開発時間」と「製品の機能」そして「製品の品質」のトレードオフです．一般に品質を下げてでも，開発時間を減らしたり，製品の機能を増やしたりする選択はありえないのですが，品質という目に見えないモノの優先度はどうしても低く見られてしまうようです．
品質を一定以上に確保する場合には，時間と機能のトレードオフになります．時間を増やすか，機能を減らすかのどちらかなのです．人を増やしてもこの関係は変わらないのです．たとえば，医者や看護婦の数を増やしても病気が早く治るわけではないですし，家庭教師の数を増やしても子供の学習速度は変わらないわけです（注5）．
ソフトウェア開発においても，開発期間を減らそうとして人を投入すれば，コミュニケーションの混乱を呼び，かえって開発期間を増やすことになってしまいます．開発者が不足しているのと開発期間が不足しているのは違うわけで，多くの場合不足しているのは開発期間なのです．
しかし，一般に開発期間はゆるぎないものです．
こうなると，削ることができるのは機能しかありません．最初に要求定義として納品すべき機能と開発期間を決めてしまうウォーターフォールモデルの落とし穴かもしれません．
XPなどの開発手法であれば「オンサイトカスタマー」という手法（プラクティス）で顧客が開発者の中に入り，開発する機能の優先度を調整することが容易にできるようです．「開発期間が固定であるなら開発する機能を調整する」という考え方なのでしょう．最終的には，顧客にも開発者にも都合の良い開発手法のようです．
これができないのであれば，すべての機能をマルチタスクに開発できるように神技のごとく分割し，難解なパズルを解くかのようにたくみに人を配置するしか方法は残されていないのかもしれません．
注5）むしろ，病院や勉強が嫌いになる可能性が心配です
●包丁（ほうちょう）と分業
包丁の語源は「包：料理人，丁：人の名前」だそうです．丁さんという料理人（達人）の名前がそのまま道具の名前として定着したのだそうです．丁さんはなんと，同じ牛刀を19年間も使い続けるという牛刀の達人で，普通ならすぐに刀が刃こぼれして使えなくなってしまうのですが，丁さんはその達人の技として「どこに刃を入れるべきか」「どこで分割すると上手に切れるのか」を体得したのだそうです．皮と肉，肉と骨の隙間など，どこに刃をあてるのか，どこにあててはいけないのか，を体で覚えていたのだそうです．
●ソフトウェア開発で分業は可能か
ソフトウェア開発においても，分業できないという根拠はありません．しかし，やみくもに分割するのでは効率を悪くするだけです．いかにして分割するかが問われるわけです．ソフトウェア開発業界においても，丁さんのような分割の達人が必要とされていると思います．それは勉強することで身に付ける知識ではなくて，体感して体得する技であると思うのです．
料理をする人ならわかると思いますが，包丁は使い慣れるほど手になじんできます．最初は恐怖感からか体がスムーズに動かないのですが，使っているうちに慣れてきて考えなくても使いこなすことができるようになります．逆に頭で考えては使えないのです．そういった使い慣れた包丁を使うようにソフトウェアプロジェクトを分割できる人材は希少ですが，たしかに存在します．C++やJavaの開発経験などよりも，こういったプロジェクトの修羅場をどのくらい潜くぐり抜けてきたのかといった点をもっと評価すべきであると思います（注6）．ここでも，まとめ役の「人を見る目」が勝負ということなのです．
注6）このような人材は管理者よりも価値が高く，それに見合うだけの生産性があると言われます．筆者も年収で1,500〜3,000万くらいの価値はあると思っています．
|
|
|
●●最後に |
|
|
職人への道は生涯学習の道である，ということも重要な点だと思います．人生そのものも生涯学習ですが，仕事においても学ぶことは尽きることがないということです．
次回は「データ指向」について書いてみたいと思います．少し多めにコードの話をしようと思います．お楽しみに．
|
|
|
●コラム CinemaScape−映画批評空間 |
|
|
●「CinemaScape−映画批評空間−」とは
「CinemaScape−映画批評空間−」（http://cinema.media.iis.u-tokyo.ac.jp/）というデータベースのようなWebページがあるのですが，このWebページを見ていると，感覚に左右されやすい個人の意見や，「良い作品」とか「おもしろい作品」という数値化しにくい概念であっても，数を集めてデータベース化することで，しっかりした数値として客観的に評価できるようになるということを感じます．
評価においてとくに不安に思っていたのは，投入資金の大きい作品が上位になってしまうのではないかという点だったのですが，現状を見る限り，資金の大小や洋の東西には関係なくきちんと評価されているように見えます．
このシステムの考え方をソフトウェアにも取り入れてほしいのです．たとえば，TVゲームのような評価の難しいソフトウェアであっても，このようなシステムによって数値化することで，客観的な評価と，さらにはクリエイターやプログラマといった個人の名前で評価される時代が，すぐそこまで来ていると思うのです．
どなたか作っていただけないでしょうか．
●顧客も管理者もレベルアップ
映画などの歴史のある業界では，観る人の目が肥えていることもあるでしょう．スポーツなどでもそうでしょう．観客のレベルが上がることで，その業界全体のレベルが上がると思うわけです．それは観る側と創る側のやりとり（フィードバックのループ）があって成立する世界だと思うのです．
ソフトウェア開発の世界も，そういった開発された製品について観る目をもった顧客（ユーザ）や，その顧客からの生の情報を取り入れられる管理者が求められていると思います．もちろん，その要求に応えられる能力のある開発者（プログラマ）が必要なのが前提の話ですけど…．
とにかく，業界全体のレベルアップが必要とされていて，それにはフィードバックされるしくみ（システム）が必要とも思うのです．
|
|
|
●コラム 10倍の差 |
|
|
企業の生産活動には10倍の差があると言われています．ある同じ規模の企業が1年で生産して売り上げる規模に対して，最良と最悪で10倍の開きがあるということなのですが，同じようにソフトウェアの生産性も人によって10倍の開きがあると言われています．ある人とほかの人で同じモノを作った場合，速度に10倍の開きがあり，信頼性や品質にも同じような開きが生じてしまうということなのです．
|
|
職人気質（しょくにんかたぎ）