システムエンジニアの晴耕雨読

< 新しい記事

新着記事一覧(全7553件)

過去の記事 >

2007.01.26

ピート・マクブリーン「ソフトウェア職人気質」・・「ソフトウェア工学」ｖｓ「ソフトウェア職人気質」

(1)

テーマ：ビジネス・起業に関すること。(20247)

カテゴリ：カテゴリ未分類

ピート・マクブリーン「ソフトウェア職人気質」
　人を育て、システム開発を成功へと導くための重要キー
　Professional computing series
　ピアソンエデュケーション

　訳は、村上雅章さん。

「ソフトウェア工学」ｖｓ「ソフトウェア職人気質」

ソフトウェア開発において、「ソフトウェア工学」を適用することが提唱されて久しいが、
あなたのプロジェクトがそれに相応しいか、をまず疑え、という。

「ソフトウェア工学」が目標とするのは、
「十分によいソフトウェア」であり
「リソース、スケジュール、機能、欠陥といったものに対する工学上のトレードオフを表現したもの」

つまり、
・安全性が重視されるなら、スケジュールとリソースが要求どおり認められる必要があるし、
・廉価版の商用ソフトなら、一部欠陥が残ったものでも致命的でなければリリースも可となる

でも、前者のように十分なスケジュールを与えられたりコストの上限が極めて大きかったり、
また後者のように欠陥を残したまま出荷が認められることが許容されていることはおかしくないか？

　これに対して、「職人気質」は、「高品質で堅牢なアプリケーションを妥当なコストかつ
比較的短い期間でユーザに調達するという問題に対する解決策」である、という。

「ソフトウェア工学」に相応しいプロジェクトは、
　１００人年（１２００人月）を越えるもの
　ｅｘ．２年以上にわたって５０人以上の開発者が必要となるもの
である。　　

　そもそも「ソフトウェア工学」は、大規模プロジェクトをいかに円滑に推進するか、
いかに成立させるか、を目的としている。
　優秀な開発者が数名、数十名いたとしても、それだけでは数千人月～数万人月のプロジェクトを
成立させることさえ覚束ない。
　そこで、要員一人一人を代替可能とし、製造業の製品製造過程になぞらえた「ソフトウェア工場」的な視点にたち、ウォーターフォールモデルによる工程の細分化、各工程に対応した役割分担とする。
　ここでは、プログラマの上に、システムエンジニアがあり、そのさらに上にシステムアナリストが
位置づけられる。また、この企業においては上流工程のエンジニアや管理者にならない限り、
報酬が与えられない。
　・・・ここでは、保守エンジニアに、優秀なエンジニアがアサインされることはなく、
ソフトウェアは手が加わるごとに改悪していく。

　つまり、ソフトウェアの開発が、工場の生産物であるのなら、製造業のアナロジーに基づく
「ソフトウェア工学」も正しいのだろうが、
　ソフトウェア開発におけるエンジニアの位置づけは、工場のラインにいる作業者ではなく、
工場のラインを設計・開発する技術者なのだ。
　であれば、ソフトウェア開発の本質は「技芸」なのではないか。
そして、「技芸」の世界では、「ソフトウェア工学」より「ソフトウェア職人気質」の方が相応しいのだ。

　システム開発からプログラミングがなくなる・・という未来予測の話は、２０年以上前から聞いていますが、統合ＣＡＳＥツールやアプリケーション・フレームワーク等で実現した部分はごく一部・・
　「ソフトウェア工学」が前提とするウォーターフォールモデルのソフトウェア・ライフサイクルの中で、
プログラミングが占める割合は、２割かせいぜい３割にすぎません。
　そのため、失敗プロジェクトの原因が、プログラミングやコーディングの誤りであることはほとんどありません。

　ソフトウェア開発が、作業手順にのっとった作業ベースと思っていると、
「要求仕様と設計仕様の間」にある大きなギャップが埋めることができず失敗してしまう。
　このギャップを埋めるのは、ツールやプロセスではなく、「熟練した開発者」だけが効果的に
対応することができる。

　「ソフトウェア職人気質」は、「ソフトウェア工学」が見落とした人間に目を向ける。

　この熟練した開発者の育成には、徒弟制度で最低５年間かかる。
　初心者であるアプレンティスとして修行を積むこと、そして、
　アプレンティスを卒業して一人前の職人として認められるジャーニーマンになること。
　でも、その価値は十分にある、と。

　途中、マクブリーンさんも「ソフトウェア職人気質」は「ソフトウェア工学」と対立するものではなく、
補完するものだ、と言われています。

　プロジェクト成功の鍵は、人・技術・プロセスと言われますが、
　人の面については、初期の導入教育をしっかりやった後は、ＯＪＴがベースだと思いながら、その具体的な内容は、配属されたプロジェクトによりかなりバラツキがあるのでは、と思います。

　いまのプロジェクト内教育の問題点は、人が多すぎることにある、と指摘されています。
　熟練者であるジャーニーマンは、新人のアプレンティスを育成する役割を担うが、多くて２名までにせよ、
という。実際のところ、よくできる熟練エンジニアの下には、５名程度、多ければ１０名を越える初心者が
ぶらさがっているのではないか、と思います。

　人を極端に減らして、たとえば１０分の１にして、報酬を１０倍与えよ、と思い切ったことも
言われていました。
　・・・こういう世界もベンチャー企業の中にはあるだろうと思いつつ、いまのままではつとまらない
自分を振り返るのでした。

　人を教えることは自分自身への学びにもなり、初心者だけでなく熟練者にも良い刺激になると思います。

これを契機に、ＯＪＴの内容の高度化・・を考えてみたい。

お気に入りの記事を「いいね！」で応援しよう