プログラミングに関するTIPSを中心に紹介 はてなアンテナに追加 はてなRSSに追加
開発プロセス改善 - ところで問題は何なのか?   このエントリーを含むはてなブックマーク
解法を問題の定義と取り違えるな。ことにその解法が自分の解法であるときには注意
ライト、ついてますか―問題発見の人間学』 D.C.ゴース G.M.ワインバーグ
ちょっとばたばたしてたのでひさびさの更新になります。そのばたばたの原因のひとつでもあるのですが、今年度に入ってソフトウェアプロセス改善(Software Process ImprovementSPI)の仕事が増えました。しかし、多くのソフト屋さんの例に漏れず、私もこの手の仕事はあまり気乗りしません。というよりも、「そんなことより実装させてくれ!!」というのが強いといった方がいいかもしれません。とまぁ、愚痴ってみたものの、開発プロセス改善は決して「そんなこと」ではなく、今日の組込みソフトウェア開発において非常に重要なテーマです。今回は、プロセス改善について考える機会ができたことで、改めて感じたことを少し書いてみようかと思います。

私と同様、組込み業界に身を置いておられる方も、「組込みもこれからはCMMくらい取れないと!」ということで、手順・ルールが増えたり、厳しくなったりという経験をお持ちの方も多いでしょう。しかし、CMMといえど、所詮はルールや仕組みであって、それは目的ではなくは手段です。体系的な仕組みは短期的には面倒なことでも、長期的には効果を発揮することも多いのは事実です。しかし、その裏にある目的を意識せず仕組みを作ることだけに一生懸命になっていては本末転倒です。

プロセス改善については、どうもトップダウンの「押し付け感」が伴いがちです。そのため、現場から見れば「望んでもないことを押し付けられる」、上から見れば「現場は意識が足りない」という調子になってしまうことが多いです。これはなぜでしょう。一つには、課題認識があっていないということが挙げられます。「プロセス改善なんて工数の無駄だ」「プロセスがないなんて問題だ!」というやりとりでは、絶対に収束しません。まずは、「なぜプロセス改善が必要か」ということをお互い認識をあわせる必要があります。つまり、「誰にとって」「何が」「なぜ」問題かという点をまず明らかにし、その次に初めて解決策を検討するというステップが必要がなのです。

現場の人間が「プロセス改善は工数の無駄だ」といった時に、つい「長期的な視野に立ってないからだ」ということがよく言われます。大抵の場合、それも一理あるとは思いますが、決してそれだけではありません。それよりも、「もっと他にすべきことがある」というのがあるからでしょう。プロセス改善の目的は、開発効率の改善や品質の向上にあります。そして現場の人の多くは、その目的のための近道がドキュメント管理や、手順の定義がネックであるとは思っていないのです。では、何が必要かと思っているか。大抵の人は「工数」と答えるのではないでしょうか。

では、工数とは何か?時間が足りないのか?人が足りないのか?実際はどちらも正しくないでしょう。実際は「スキル」が足りないのです。人月という単位はいうまでもなく形式的なもので、実際は全ての人が同じスキルをもっているわけではありません。そして、工数が足りないといった時に、多くの場合開発者のスキルが足りないということが多いと思います。

プロセス改善といった時に、まだまだこの「スキル問題」が議論の中心になることはあまりないような気がします。ノウハウの蓄積といったテーマがあがることがありますが、まだ少し違う気がしいます。もっとより、自由意志でのスキルアップのようなもの、これをうまく組織としてまわるようにしていくにはどうすべきか、これを考える必要があるように思います。それは自己啓発だからどうしようもない、そう言って片付けてしまうのは単なる思考放棄です。梅田信夫氏の著書「ウェブ進化論」でも紹介されていますが、Googleは20%の時間を自分のオリジナルなテーマに当てなくてはいけないという「20%−80%」ルールがあるそうです。ポイントは「当てなくてはいけない」という点です。さすがGoogleといってしまわず、このような仕組みも積極的に検討していく必要があるのではないでしょうか。これも、実開発の工数に影響を与えるかもしれませんが、「ドキュメント管理」よりははるかに技術者の「モチベーション」に効果的に働くでしょう。

さてさて、こうは書いたものの、やっぱり基本は会社にたよるのではなく自分自身の動機付けが一番。かくいう私も最近業務に追われ気味なので、ちょっと深呼吸して新しい言語でも勉強してみようかなと思う今日この頃です。
なんだかまとまりのない話になって、結局何が主題だったか分からなくなってしまいました (^^;)。
プロセス改善の話の続きはまた改めて。。

【関連書籍】
ライト、ついてますか―問題発見の人間学 ドナルド・C・ゴース G.M.ワインバーグ
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか E・ヨードン
ウェブ進化論 本当の大変化はこれから始まる 梅田 望夫
ソフトウェア開発のためのプロジェクトマネジメント入門―CMM導入の手引き パンカジュ ジャロート
ソフトウェアプロセス改善と組織学習―CMMを毒にするか?薬にするか?
ザ・サーチ グーグルが世界を変えた ジョン・バッテル

コメント
この記事へのコメント
はじめましてタンジといいます。
プロセス改善の必要性は十分わかっていますが、やはりCMMなどは、うんざりです。
というより、実現方式があまりにも直球すぎることに「うんざり」という方が正確です。
折角こんな商売しているんだから、ITを駆使して楽しく業務改善できたらいいのになと常日頃思っています。
2008/02/02 (土) 03:16:23 | URL | タンジ #EpdnBAro[ 編集]
コメントを投稿する
URL:
Comment:
Pass:
秘密: 管理者にだけ表示を許可する
 
トラックバック
この記事のトラックバックURL
この記事へのトラックバック
http://proger.blog10.fc2.com/blog-entry-69.html 現場の人間が「プロセス改善は工数の無駄だ」といった時に、つい「長期的な視野に立ってないからだ」ということがよく言われます。大抵の場合、それも一理あるとは思いますが、決してそれだけではありません。それよりも
2006/09/19(火) 02:47:07 | methaneの日記
copyright © 2005 職業としてのプログラミング all rights reserved.
Powered by FC2ブログ.
FC2ブログ