開発プロセスは導入するものじゃない
TDD で出来上がるもの のコメントに曰く、 「導入コストどうしよう・・・。」
ええ、 うちの会社もそうなんですが、 アタマの痛いところです。
ある部署なりチームなりの年間予算で見てくれてれば、 まだマシだと思うんですが…
案件ごとの売上金額とコストが問題にされちゃうと、 開発プロセスの改善といったような、 将来への投資コストを潜り込ませるのは、 たいへんです。
そのほかにも問題はたくさんあると思いますが、 ここでは大きな話を 2つ、 いや 3つ。
# っていうか、 ここから本題 f(^^;
「開発プロセスを導入する」 という言い方を聞くと、 不安に駆られます。
「開発プロセスを改善する手段の一つとして、 ×××というプロセスのやり方を取り入れてみる」 というような意味ならよいのですが。
「×××という開発プロセスを導入することにしたから、 開発プロセスに関わる問題は一切出なくなるはずだ」 という、 銀の弾丸幻想に囚われた意味だと、 困ります。 というか、 それは失敗に終わるでしょう。
◆ 開発プロセスは改善するものであって、 導入するものじゃない
これは、 それこそ製造業の量産ラインを見習って欲しい点です。
プロセスを倦まず弛まず改善し続けていくこと。 普段はちょっとずつ、 大きな効果が確信できるときは大幅に。 製造業の会社なら、 どこでも改善し続けています。
そして、 製造業では、 自社の既存のプロセスを、 他社が作り上げた 「×××プロセス」 に丸ごと置き換えることはありません。 よそとまったく同じやりかたをしたって、 そこには勝てない、 という分かりきった理由からです。 ( あ、 いや、 一番最初は違うか。 自社のプロセスなんて無いんだから、 追いつくために、 とりあえず猿真似するかも。 )
生産性や品質の向上を目的として開発プロセスを 「導入」 した場合、 その直後の地点で止まってしまいます。 また数年と経たないうちに、 他社に、 あるいは時代に、 取り残されることになります。
◆ 開発プロセスに銀の弾丸は無い
誰がやっても同じ結果が出る、 誰がやってもプロジェクトが成功する、 そんな手法はありません。 ( → 人月の神話 )
ということは、 どんな開発プロセスであっても、 やる人によって結果が変わる、 やる人によって成功もすれば失敗することもある、 ということです。
これすなわち、 属人性を排除することは不可能だ、 ということです。
属人性を排除することを目標に開発プロセスを 「導入」 した場合、 成功率は上がるでしょうが、 バラつきは残り、 やはり失敗するプロジェクトも出てきます。 結果としては、 開発プロセスを 「導入」 したときの ( 過大な ) 目標は達成できなかったことになります。
※ 本当に属人性を排除できるプロセスが見つかったら…
それをマニュアルにすることができて、 誰でもそれを読めば、 必ずプロジェクトを成功させることができるはずです。 そんなマニュアルができたなら、 それをプログラミングすることも可能でしょう。
すなわち、 属人性を排除できるプロセスがあるなら、 自動化できるということです。
もうひとつ、 開発プロセスの改善を評価することについて。
◆ 開発プロセスだって、 計測していなかったら、 改善も無い
開発プロセスを改善する目的はなんでしょう? 生産性? 品質? 納期?
どのくらい改善できたかどうか、 どうやって評価しますか?
チーム内のレベルでは、 「うん、 良くなったよね!」 という感覚的な評価だけで十分なこともあるでしょう。
しかし、 会社組織としては、 それでは成果があったとは認識できないはずです。 なんらかの具体的な数値として示さなければならないでしょう。
今まで生産性や品質を継続的に計測していなかったならば、 開発プロセスの改善結果は見えません。 そして、 改善の成果が数字として見えないならば、 その開発プロセスの 「導入」 は成功したとは評価されないでしょう。
以上の話をひっくり返すと、 成功する開発プロセスの改善方法が見えてくるように思います。
1. 生産性や品質を継続的に計測すること。 そのデータから、 精度の良い見積りができるようになっていること。 ( 見積りの誤差以上の改善効果が無いと、 改善分は誤差の中に埋もれてしまって、 数値として見えないので。 )
2. 開発プロセスの改善活動を軌道に乗せること。 それを継続すること。 改善効果が数字として見えるようになること。
3. 改善活動の中で出てきた問題点の解決策として、 適切な開発プロセスがあるか探すこと。 見つかったなら、 どのように自己のプロセスに取り込むか、 改善活動の一環として進めていくこと。
# …と、 1.~3. まで書き終えてから思った。 なんだやっぱり、 製造業に勤めてたころに教わったことじゃん f(^^;
| 固定リンク
「プログラミング」カテゴリの記事
- 【.NET / Win8.1 ストアアプリ】 HttpClient で TLS 1.1 / 1.2 に対応するには(2018.06.17)
- 【VS2017 15.7pv2】 XAML のランタイム ツールに 「ヒートマップ」 が増えた(2018.03.28)
- 【.NET Core】 プロジェクトを作ると 「project.assets.json が見つかりません」 エラー(2018.02.10)
- 【#UWP】 ビットマップの表示色を変える (Win2D.uwp 経由で Direct2D を使う)(2017.08.23)
- 【#UWP】 CompactOverlay モード: Picture in Picture というか、「最前面に表示」するウィンドウを作る(2017.08.16)
「-プログラミング ( わんくま )」カテゴリの記事
- [わんくま名古屋] 第21回: Metro サンプルコード解説 (1/3)(2012.04.15)
- [わんくま名古屋] 第21回は 4月 14日 - Windows 8 Metro をやるよ~♪(2012.04.12)
- [わんくま東京] 第59回の資料を公開しました(2011.06.02)
- [わんくま東京] 第59回は 5月 28日 - 名古屋から侵略します♪(2011.05.23)
- [わんくま名古屋] 第17回は 4月 9日 - TDD ネタで喋ります(2011.04.03)
「-プログラミング ( 開発プロセス )」カテゴリの記事
- Visual Studio 11 beta は Windows 8 beta と同時リリース! なんと、 TFS に Express 登場!!(2012.02.24)
- [本] アジャイルサムライ ~ アジャイルマインドの伝道書(2011.11.12)
- [MEMO] ファンクションポイントの算出法、あれこれ(2011.10.11)
- アジャイル開発を失敗させる 7つの大罪(2010.10.24)
- [岡崎図書館サイバー冤罪事件] MDIS って CMMI 認定を受けてる優秀なソフトウェア開発会社なんでしょ?(2010.09.26)
この記事へのコメントは終了しました。
コメント
> なんらかの具体的な数値として示さなければならないでしょう。
数値化が難しいですよね。何を指標にすればいいんでしょうか。意味無い数字出しても、ろくなことにならないし。
製造では、サイクルタイムだとか直行率だとか、誰もが納得できてかつ有効である指標がそれこそいくらでもあるんですけど、ソフトウェア開発だとなにを指標にするのがいいのかなぁ。
投稿: あきひろ | 2008年7月 3日 (木) 19時23分