ソフトウェアプロジェクト組織論


2002/03/10

顧客の要求仕様(2)

一時期、EUC(End User Computing)という言葉が流行りました。早い話がソフトウェアの仕様等の詳細はユーザ主導で決めましょう、という話です。でも、最近あまりこの言葉聞きませんよね?どして?もう当たり前のこととして浸透したからでしょうか?1990年頃に、「1995年頃には『オブジェクト指向』という言葉はなくなる。その頃にはオブジェクト指向でシステムを作るのが当たり前になるからだ」と仰った方がいらっしゃいましたが、こっちは未だに無くなってませんね。「オブジェクト指向でシステムを作るのが当たり前になる」というのはある意味当たってたように思います(だって、Java, J2EE, EJB,XML,....どれを取ってもオブジェクト指向抜きにはシステムは作れません)が、言葉としては根強く残ってますね。やっぱり敷居が高いと思います。それほど理解できているエンジニアさんいませんし。

さて、話を元に戻してEUCです。システムの仕様をユーザサイドの担当者に一任して果たしていいシステムができるのか?に対しては私は懐疑的です。でも、開発側にやらせるのも反対です。ここは、仕様を纏めるためのコンサルティングの存在が重要になってくるような気がします。ユーザには、一貫性の取れたシステム仕様を構築するだけのスキルは恐らくありません。思いつきで好き勝手にああしたい、こうしたいとのたまうのが関の山でしょう。また、システムは、人間の仕事を減らすために作るのであってユーザサイドの担当者が楽するために作るものではありません。システムを導入した結果、仕事が無くなる人がいてしかるべきです。人件費を安く上げることがシステムの主要命題なのですから。となると、システム化にあたっての意思決定は第3者に託すことがいいシステムを作るための条件になるような気がします。彼には発注側、受注側の仲介に立ってもらってその双方から報酬を頂くというビジネスモデルは成立しないかしら?受発注の双方にとってもメリットがあるような気がします。発注側は出来るだけ低コストで機能を詰め込みたがります。また受注側は同じ金額なら、出来るだけ開発項目を削減しようとします。ここで双方の折り合いをつける立場というのが恐らく重要になるのではないかと。この受発注モデルだと仲介する人間(まぁ、仮にコンサルとしましょう)には両者から板挟みにあうのでかなりキツイ仕事にはなるかと思います。でも、それに見合う能力の人間と報酬を用意すればそれなりにこなせる人間はいるんじゃないでしょうか?

経営学とソフトウェア工学

経営学って、『人間組織の最適運営方法の追求』だそうです。なんかソフトウェア工学にも合い通じるものがあるような気がしています。でも、これまでの経営学は、「如何に安く大量生産するか」にフォーカスしてたそうで、今後はこの姿勢も見直されるそうな。となると、経営学のスタンスとしては、これまでの工業製品の製造メタファ(いわゆるハードウェア製品)から、知識集約型開発メタファ(いわゆるソフトウェア製品)へとパラダイムシフトが進むでしょうから、ますますソフトウェア工学と経営学との接点が見出せるようになるんじゃないかと期待してます。

2002/2/28

顧客の要求仕様

顧客の要求仕様ってどれぐらい取り込んでますか?なんて聞くと「お前はあほか」という罵声が返ってきそうです。まぁ、予算、期日から見ても無理な要求をしてくるお客さんは必ずいるもので、そういった場合は、「コスト的に無理です」とか「間に合いませんので、次期バージョンにて」という話になることはよくあると思いますが。昔(といっても数年前ですが)、隣の部の部長さんからは、「いいシステムというのはお客さんが望んでるシステムなんだから客の言うこと聞いてりゃいい」ようなことを言われたことはありますが、僕は、客の言う通りのものを作るからシステムがダメになる、と思っている。人にも拠るんだけどね。『客の言うとおりにシステム作るのは、ヘボSE』とも言いますし。とりあえず、要求仕様の探検学―設計に先立つ品質の作りこみを始めとするワインバーグ本で再度修行が必要ですな。

2002/2/25

進捗管理

進捗管理ってそもそもそんなに重要かな?本当は、プロジェクト管理者が進捗している(気がする)ことを実感できる以外にメリットないんでは?という気がしている。以前に経験したプロジェクトで、単体試験の実施項目を1日単位で提示せよ、というお客さんがいた。普通、単体試験って、メイクと切り離して考えることはまずなくて(あったらそんなプロジェクト、辞めちまえ)普通、作っては動かして、ってのを繰り返す。そうやって小さい部分から段々肉付けしていって大きなプログラムにしていく、というのが普通のプログラムの組み方だと思う。で、ここでいう単体試験ってどこから何処まで?コンパイルした回数?Syntax Errorでコンパイル失敗した場合ってカウントする?どう考えても単体試験の試験実施項目数のカウントって理不尽。その時私が取った行動は、上司に目安の項目数を弾いてもらった(おそらく適当)。で、その数字から飛躍的に外れない範囲を定めて、その範囲内で、整数値の乱数列を生成するプログラムを作成し、日別試験項目数一覧を作成した。これで余計なことに稼動をかけず、お客さんの望む報告書が出来てなおかつ重要なプログラム開発に神経を集中させることができた、と信じている。僕って、なんてお客さん思いの顧客第一主義に乗っ取ったエンジニアなんでしょう?そう思いませんか?

国民的番組に成長したプロジェクトXを見てる方も多いと思いますが、例えばあの中で一番多く再放送されている東京タワーの話(いや、別に『東京タワーなんて簡単やん!』ってことを言いたいわけじゃありません。現場の職人の方々には敬意を表します)。あの話に出てくるのって、ソフトウェアで言うと「ビルド」の部分だけなんだよね。あるいは「リンク」の部分だけかも知れん。つまり、コンパイラが自動でやってる部分。これは進捗を管理する意味があると思うんだ。「今、何処まで進んだかな?あとどれぐらいで終わるかな?」ってのが気になるから。それに終了時刻の見積もりができるのとできないのでは、その後の作業の効率が全然違うし。でもね、あの番組で一瞬で流されてしまった東京タワーの設計図の作成って恐らく進捗管理してないよね?「設計書、どれぐらいできました?」「48%です」って意味ないもん。それに設計を進めていって「あぁあああ、計算間違えてた。やりなおし〜。進捗20%に戻る」なんてことはやらないよね。設計のやり直しはあっても。それに、鳶職人の方々が頑張って高いところで作業してる最中に、発注者が、「やっぱり、芝公園は土地も高いし、品川にしてくれ」とか「この向きは困る。ちゃんと東西南北を向くように作ってくれ」とか「高さ300mだと、三浦半島の先っちょまで届かないから500mにしてくれないか?500mないと、現場の運用担当が、使えないって受け取ってくれないんです。すいません」なんてこと、言うか?『ソフトウェアは作り直しが簡単に出来る』という幻想、そろそろ捨てないか?

2002/2/11

前口上

世の中には無数のソフトウェアプロジェクトが進行中である。毎日のように、新しいプロジェクトが立ち上がっては失敗して消えていく。何がまずいのか?現在のソフトウェア工学に何が欠けているのか?本来のソフトウェア開発プロジェクトはどうあるべきか、を考えるコーナーである。ここは不定期に気が向いた時に更新を行う。もちろん、つっこみ、挙げ足とり、意見等は大歓迎。宛先は、こちらまで。そんなことはありえない、とは思うが、万が一ご意見等を戴く頻度が高ければ、このページにWikiを導入することも検討します。

提起

このページのベースとなる考えは、以前に私が友人とのメールのやりとりのこんな言葉に端を発している。
そう言えばソフトウェア工学、プロジェクト管理、心理学、経営組織論、人事システムあたりに跨って「ソフトウェア開発プロジェクトのあり方」に言及したような研究なり、論文なり、文献なり、ご存知ないでしょうか? ない、とは思ってるんですが。どっから攻めていいのやら、皆目検討がつかないので。とりあえずはワインバーグあたりから攻めるのが筋かなぁ、とは考えています。
これに対して、友人から返ってきた助言がこれ。
XPとかアンチパターンとかは?
この後、この友人と議論(といっても、飲み屋で朝までうだうだ喋ってただけだけど)させて頂いた内容をかいつまんでまとめるとこんな感じ。 まぁ、ざっとこんな感じでざっくばらんの一言に尽きる。

ソフトウェア開発プロジェクトを工業製品のメタファで捉えることの弊害について触れた。つまり、今日の、仕様検討、設計、製造、試験、運用、という流れ(これこそ、ウォーターフォールモデル)はそもそも工業製品の製造プロセスだ。同じ「製造」という言葉を用いているが、ソフトウェア開発の「製造」が詳細設計、コーディングを指すのに対し、主たる工業製品の「製造」というものは、いうなれば、大量生産、つまり、「既存品のコピー」にしか過ぎないんだよね。逆に言うと、工業製品で言う「製造」工程って、ソフトウェア開発で言うところの「ファイルコピー」しかやってない。では、ソフトウェア開発で言う、「製造」工程にあたるものを工業製品ではなんて言うか、っていうと、「研究、試作」にあたるんだ。と言っても、例えば車で考えると、車の「研究、試作」って、早い話が、既存の車の性能改善、デザイン変更にしか過ぎない。つまりこれは、ソフトウェア開発で言うところの、「リファクタリング」、「チューニング」とかあるいはGUIの修正(つまり、ボタンの位置を変えました、とかちょっと見せ方変えました。みたいなもの)にしか過ぎないんだよね。それに対し、ソフトウェア開発は、常に世の中にないものを作るということをやっている。(世の中にあったら、開発なんかしなくてそれを持って来ればいい、ということになる。)もちろん、他社にはあるけど、自社にないものを作る、ということもあるけどこの場合は、開発担当者にとっては、初めてのものだから、実質的には変わりない。もっと言うと、車作ってたエンジニアに、ロケット作れ、とか船作れ、とかっておそらく言わないと思うんだ。でも、こういうことを平気でやってるのがソフトウェア業界なんだと思う。そうなると、人類史上、最も複雑なものと比喩されるソフトウェアを開発するのに参考になるメタファはおそらくなくて、ソフトウェア開発に特化した何かが必要になるような気がしてる。そういった点を中心に、ソフトウェア開発プロジェクトのあり方、といったものを考えてみたいと思う。もちろん、答えはでないだろう。でも、何かしらのヒントになるようなものが示唆できれば、十分だと思う。

ってな感じで、不定期にいろいろ調べたこととか、考えたことなどを書き連ねて行くページになる予定。


Tadashi Kaneda
Last modified: Tue Feb 12 00:59:06 JST 2002