『組込みソフトエンジニアを極める』の第4章－品質の壁を越える－の中に組込みソフトウェアプロジェクト簡易評価指標を載せた。組込みソフトウェアプロジェクト簡易評価指標の10個の質問事項は、ジョエル・テスト(The Joel Test: 12 Steps to Better Code)を参考にしたものだ。2005年の12月に、このジョエル・テストを考えた Joel Spolsky 氏の翻訳本、『Joel on Software
』が出版された。Joel Spolsky 氏はMicrosoft にいたとき、Excelの開発に携わっていたソフトウェアエンジニアで、彼のウェブログ Joel on Software は、独立したプログラマ向けのサイトとしては最も人気のあるものの一つである。
【組込みソフトエンジニアを極めるで紹介した 表4.6 組込みソフトウェアプロジェクト簡易評価指標】
- コーディングルールを定めているか？
- 障害票データベースを持っているか？
- ソース管理システムを持っているか？
- 開発の節目節目でレビューを実施しているか？
- スケジュール表を常に更新しているか？
- 仕様書を作ってからプログラムを書き始めているか？
- プログラムを変更した後の回帰テストは実施しているか？
- 買える範囲で一番良い開発ツールを使っているか？
- OJT以外に技術者教育のカリキュラムを持っているか？
- テスト担当者はいるか？
The Joel Test とはソフトウェア開発チームを評価する簡単なYes・No形式のテスト
『Joel on Software
』は、Joel Spolsky 氏のウェブログ Joel on Software をベースにしたもので、そのフランクな語り口がとても軽快でおもしろい。具体例が満載でネタの宝庫だ。今回は、エンジニアがなぜ仕様書を書かないのかについて Joel Spolsky 氏が書いたことについえ考えてみたい。
【Joel on Software 第5章 やさしい機能仕様 パート1：なぜわざわざ書く必要があるのか？ より引用】
2000年10月2日 月曜
ジョエルテストを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければいけないということだった。前にも行ったことだが、仕様書はデンタルフロスみないなもので、みんな書かなきゃいけないとは思っているけど、誰も書かない。
なぜみんな仕様書を書きたがらないのだろう？ 人々は、仕様書作成フェーズを飛ばして時間を節約しているんだ、と主張している。彼らは、仕様書作成がNASAのスペースシャトルのエンジニアや巨大な保険会社で働いているような人たちのための贅沢品であるかのように振る舞っている。戯言だ。何よりも仕様書を書かないということは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクなのだ。それは着替えだけリュックに詰めて、その場になれば何とかなるさとモハーベ砂漠を横断に出発するのと同じくらい愚かなことだ。仕様を書かずにコードに飛びつくプログラマやソフトウェアエンジニアは、自分たちがかっこいい早撃ちガンマンであるかのように思う傾向がある。そんなんじゃない。彼らはとても非生産的だ。彼らはまずいコードを書き、お粗末なソフトウェアを作り、まったく必要のない大きなリスクを負うことでプロジェクトを危険にさらしている。
：
<ここに仕様書を書いた場合と書かない場合の具体的な例が入る>
：
この物語の教訓は、人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからないということだ。ワープロ文書の段落を1つ削除するのを残念に思う人はいない。しかし、あなたがプログラミング言語で製品をデザインしているなら、反復デザインには何週間もかかる。さらに悪いことに、あるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していなくても、上司や顧客が何と言おうとも、スピーディにその美しいコンバータのコードを捨てさせることはできない。その結果、最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。それは、「すでに書いてしまったコードがあり、そのコードは捨てたくなかったので、それを前提とすれば私たちに得られた最良のデザイン」ということになる。これは「私たちに得られた最良のデザイン」ほど良いものではないのだ。
これが仕様書を書く大きな理由の1番目だ。大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。あなたが仕様書を書いておけば、プログラムがどう動くと想定されているか一度だけ説明すれば済む。チームのみんなはただ仕様書を読めばいいからだ。品質保証の人たちは、プログラムがどう動くと想定されているかを知るために仕様書を読み、何をテストすればよいのかを理解する。マーケティングの人たちは、Webに載せるための、まだ作られていないベーパーウェア製品のホワイトペーパーを書くときに仕様書を使う。ビジネス開発の人たちは仕様を読み違えて、その製品がいかに禿やイボによく効くかという奇妙なファンタジーを紡ぎ出すかもしれないが、それで投資家を引き寄せられるのだから、それはそれでOKだ。開発者たちはどういうコードを書くべきか知るために仕様書を読む。顧客は開発者の作っているものが自分たちの欲しい製品であることを確認するために仕様書を読む。テクニカルライターは仕様書を読んでマニュアルを作る。マネージャは経営会議で何が起こっているかについて知っているような顔をするために仕様書を読む、などなど。
【引用終わり】
前半の仕様書を書く第1番目の理由「仕様書を書かないと、すでに書いてしまったコードが既成事実になってしまい、デザインの修正に時間がかかる」の説明はよく分かる、実際その通りであり現場をよく観察していると思う。それに対して、第2番目に理由は、日本のそれも組込みソフトの開発現場に照らし合わせたとき「そうだ、そのとおり」と相づちが打てるだろうか。
チームのために仕様書を書くという点は分かるものの、「品質保証の人たちのために書く」「マーケティングの人たちのために書く」「ビジネス開発の人たちのために書く」「顧客のために書く」「テクニカルライターのために書く」「マネージャのために書く」というところが引っかかる。一つ一つそうなっているのか検証してみよう。
「品質保証の人たちのために書く」は、品質保証担当がソフトウェアをテストするのに、仕様書をもとにテストケースを作るから仕様書が必要だということだ。でも、10人以下の組込みソフトプロジェクトでは、プログラムの作成者が自分で自分の作ったプログラムをテストしたりする。そうなると仕様は自分の頭の中にあるということになる。
次に「マーケティングの人たちのために書く」はまだ完成していない製品のホワイトペーパーを書くときに仕様書を使うとあるが、組込み製品の場合はホワイトペーパーは書かない。
「テクニカルライターのために書く」は、取り扱い説明書の原案をソフトウェアエンジニアが書いたりする。
「マネージャのために書く」もそうだが、何しろ日本の小規模な組込み開発では、製品の機能仕様について知りたいプロジェクト外の人間は、直接製品開発をしているエンジニアに仕様について聞く。人の流動が少ないので誰が製品仕様について詳しいか知っているし、知らなくてもプロダクトマネージャに尋ねると「彼に聞いて」などと言われる。「仕様書を読んでくれ」とはなかなか言わない。仕様書を読まなくても聞きたいことを直接聞けるから仕様を知りたい側は楽だ。
プロジェクト外の人間のみならず、プロジェクトの内部でも製品の機能仕様を一人のアーキテクトが作っていたりすると、エンジニアもマネージャも誰も彼もが、その一人のアーキテクトに仕様を聞きに来る。
要するに人間仕様書だ、いや生き字引だ。そのエンジニアがすべての仕様を知っていて、その人に聞けばだいたいのことがわかってしまう。そんなエンジニアがあなたのプロジェクトにもひとりぐらいいるのではないか？
「権限もいらないから責任もとらないってあり？」の記事でも書いたように、日本の組込みソフトウェアプロジェクトは責任と権限が曖昧な場合が多い。責務が曖昧だから、仕事の分担がはっきりせず、人間仕様書状態が発生しやすい。
しかし、人間仕様書状態の発生により日本の組込みソフトウェアプロジェクトは2つの大きなリスクを抱えることになる。1つ目は、生き字引となっているアーキテクトが何かの理由でプロジェクトから離れたり、会社を辞めたりするとものすごく製品開発の生産性や品質が落ちる。また、後を引き継いだアーキテクトはろくな仕様書がないから非常に苦労することになる。
2つ目のリスクは、人間仕様書となっているアーキテクトに情報が集中してしまい大きな負荷をかけることにる可能性があるということだ。知らず知らずのうちにそのアーキテクトへの負担を累積させて潰してしまう危険がある。
人間仕様書となったアーキテクトは潰れないまでも、いろいろな会議に呼ばれ、マネージャが外部の人間から製品の仕様について説明を求めら得ると「それは○○君から答えさせます」などと振られる。どこに何が書いてあるか知らなくても、人間仕様書が必要な情報を適宜加工してアウトプットしてくれるので非常に便利だ。
しかし、機能仕様について尋ねられると、自分のやっている作業が一時的に止まるので集中が途切れる。だから、質問が来なくなる残業時間の間に集中して自分の仕事をやったりする。
ああ、無情。悲しきアーキテクトよ。人間仕様書状態から彼を解放せよ！ と叫んでみても始まらない。人間仕様書となっているアーキテクトが、この状態を解消しようとしてがんばって紙の仕様書を書いても、彼に聞いた方が早いので仕様書の方を読んでくれないのだ。
大規模なビジネス系のプロジェクトでもろくに仕様書が書かれないのなら、小規模な組込みソフトプロジェクトで人間仕様書状態を解消するのはかなり大変だ。
いまは小規模でも、ソフトウェアの規模が増大し、一人のエンジニアが製品の仕様全体を把握できなくなったときに、仕様書がないことでプロジェクトが破綻するのを待つか、それとも人間仕様書状態になっているアーキテクトにしばらく倒れてもらうか・・・
現時点では、いいアイディアが浮かばないが、もしも、ドキュメントがなくて困っているプロジェクトマネージャやアーキテクトがいたら、『Joel on Software
』を読んで、この本に書いてあるいろいろなシチュエーションの具体例の中から解決のヒントをつかんでいただきたい。
0 件のコメント:
コメントを投稿