2009-09-27

なぜドキュメントを書かない?

久しぶりに『ジョエル・オン・ソフトウェア』を読んだ。Amazon で調べたら、最近、この本の続編である『モア・ジョエル・オン・ソフトウェア』が出たようだ。

ジョエル・オン・ソフトウェアの著者である Joel Spolsky はソフトウェア業界での豊かな経験を持つ開発者で、彼のウェブログ "Joel on Software" はプログラマ向けサイトとしては最も人気のあるものの一つで、彼はマイクロソフトの開発者だったころ Microsoft Excel 等多くの有名なソフトウェア製品の開発に携わった。

彼がブログで記事にしたことをまとめた最初の本が『ジョエル・オン・ソフトウェア』である。もともとはブログの記事であり。アメリカ人でないとわからないようなスラングや引用(例えばジョージ・ブッシュ大統領の口癖 Not gonna do it! 「それをやるつもりはない」等)がふんだんにちりばめられており、読みにくいと言えば読みにくいが、ところどころで「まさにその通り!」と膝を打ちたくなる部分がある。

まずは、『第5章 パート1:なぜわざわざ書く必要があるのか? やさしい機能仕様』の一節を読んで欲しい。

ジョエル・オン・ソフトウェア 第5章 パート1:なぜわざわざ書く必要があるのか? やさしい機能仕様 より引用】
 私の考えでは、ちっぽけではないあらゆるプロジェクト(1週間以上のコーディング、あるいは2人以上のプログラマを要するようなもの)において、仕様書がなければ常に、より多くの時間を費やし、より品質の低いコードを作ることになる。理由はこうだ。

 仕様書の最も重要な役割はプログラムをデザインすることだ。たとえあなたがすべてのコードを1人で書いているのだとしても、純粋に自分自身のためだけに仕様書を書くのだとしても、仕様書を書くという行為自体によって-プログラムがどう機能するか詳細に記述することによって-プログラムを実際にデザインするように強いられるのだ。

-中略-

人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからないということだ。ワープロ文書の段落を1つ削除するのを残念に思う人はいない。しかし、あなたがプログラミング言語で製品をデザインしているなら、反復デザインには何週間もかかる。さらに悪いことにあるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していなくても、上司や顧客が何と言おうとも、スピーディにその美しいコンバータのコードを捨てさせるこてはできない。その結果、最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。それは、「すでに書いてしまったコードがあり、そのコードは捨てたくなかったので、それを前提とすれば私たちに得られた最良のデザイン」ということになるのだ。これは「私たちに得られた最良のデザイン」ほど良いものではないのだ。

 これが仕様書を書く大きな理由の1番目だ。大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。あなたが仕様書を書いておけば、プログラムがどう動くと想定されているか一度だけ説明すれば済む。チームのみんなはただ仕様書を読めばいいからだ。品質保証の人たちは、プログラムがどう動くを想定されてるか知るために仕様書を読み、何をテストすればよいのかを理解する。

-中略-

 このコミュケーションは不可欠であり、あなたが仕様書を書いていない場合でも発生するが、その場合は行き当たりばったりに発生することになる。品質保証の人たちがしだいにあれこれとプログラムをいじり回し、そして何か奇妙なことが起きるたびにプログラマを邪魔して、どうなるのが正しいのかについてばかげた質問をする。これがプログラマの生産性を損なうという問題は脇に置いておくとしても、プログラマというのは「正しい答え」ではなく彼らがコードをして書いたことに即して質問に答える傾向がある。だから、品質保証の人たちは仕様に従っているかをテストするのではなく、プログラムの挙動に沿ってそのプログラムをテストすることになってしまうわけで、これは、なんというか、もう少しマシにやれたはずなのだ。
【引用終わり】

機能仕様書を含むソフトウェアドキュメントを書くことがムダである、役に立たない、その時間をプログラミングやデバッグに費やした方がマシだという声を間接的に聞くことがある。間接的にというのは、面と向かっては言わないが品質保証担当がいないときに、開発が遅れていることの理由としてやり場のない怒りに対して、要求されるドキュメントが多いということが開発が遅れる原因だとプロジェクトの内部で愚痴っているのだ。

自分がプロジェクトの遅れの原因にされているソフトウェアドキュメントだったら「それは、濡れ衣だ!」「 プロジェクトの遅れはドキュメントのせいじゃない!」と叫んでいるだろう。ドキュメントはしゃべれないから口をきけない者に問題の原因を押しつけているだけだ。ひどい話だ。

そう思っていたら、『ジョエル・オン・ソフトウェア』に上記のようなことが書いてあった。

ドキュメンテーションという行為はソフトウェアの設計に他ならない。いきなりプログラムを書き始めるのはもっともレベルの低い設計であり、自然言語や図表を使ってソフトウェアドキュメントを作るということがレベルの高い(抽象度の高い)設計行為だ。 Joel Spolsky が語っているドキュメントが必要な一つ目の理由が「ドキュメンテーションはプログラムをデザインすること」なのだが、2つ目の理由であるドキュメントがあることによって各部門とのコミュニケーションを効率的に行えると言う点は同意するものの、日本のソフトウェアプロジェクトでは難しい面があると感じる。

日本の小規模な組込みソフトウェアプロジェクトでは、プログラマが仕様も作成し、マーケティングもテストも品質保証もしなければいけないことが少なくない。品質保証という名が付く担当部門があってそこに担当者がいても実施的なソフトウェアの品質保証作業はプログラマがやっていることもある。

だれからも読まれないドキュメントを作るのは確かに辛い。誰かが読んでくれるから、自分や他の誰かのために役立つからドキュメントを書こうという気になる。

だから自分はレビューがあるときは事前に全部のドキュメントに目を通す。斜め読みするのは得意なので、数十ページのドキュメントでも10分くらいあれば問題点や「よく見てるね」と言われるような質問項目をピックアップすることができる。だから、レビューの数時間前に書類が送られてきてもへっちゃらだ。

的確に問題点や良い点を見つけてレビューで伝え、こういうときには何をチェックする必要があるのかをレクチャーする。時間かけて作ったドキュメントを読んで評価してくれる人がいれば次のドキュメンテーションの動機につながる。日本のソフトウェアプロジェクトがドキュメントを書かない理由のひとつに「誰も読んでくれない」ということがあると思う。

『あるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。』という Joel Spolsky の主張はその通りだと思う。

これは個人的な感覚だが、自分はプログラムを書き直してプログラムがきれいになる、アーキテクチャが美しくなるのなら、今のコードを捨てることにぜんぜんためらいがない。(もちろん心に余裕だないとダメだけれど) 自分が作ったコードにきったないところがあって、後で誰かから「あれはないだろ」と言われるのは我慢がならないし、陰でクスクス笑われるのも嫌だ。やはり「いい仕事しているね」と言われたい。

だから、いつも自分がアウトプットした成果物をできるだけ第三者の客観的な目になったつもりで批評し、指摘されそうな部分があったらためらいなく直す。これを繰り返していると「ひとりピアレビュー(セルフレビュー)」ができるようになる。熟練すると質問されそうなことをいくつも想定できるようになるので、成果物をレビューされるときもスムーズな回答ができる。

ひとりピアレビューができるようになるのはそう簡単ではないので、やはりプログラマやソフトウェアエンジニアがモチベーション高く仕事を続けるためには、彼らの仕事を誰かがきちんと見て評価してあげないといけないと思う。成果物をほったらかしにせず、少なくともプログラムを作ったプログラマ以外の誰かが評価してあげることが、ドキュメントの必要性を理解させ、ドキュメントが役に立つことを体感させることにつながると思う。

P.S.

最近、昔作ったソフトウェアのことを聞かれ、10年前の日付が入っているドキュメントとソースコードを提供して再利用されたことがあった。ソースコードではなく、そのソフトウェアの元となる考え方自体が有用だったこともある。3年以上前に作ったソフトウェアだと自然言語で書いたドキュメントやモデルなどがあるととても助かる。こういうことがあると、あの時ドキュメントを作ったり、作らせたりして、キッチリいい仕事しておいて良かったと感じる。

2009-09-21

カイゼンの実現にはジャーナリズムが必要

今、政治が面白い。政権が交代し新しい施策・政策が次々と打ち出され改善が進んでいく過程を見るのは心地よいものだ。

組織内でなかなか進まないソフトウェア系のカイゼンをうまく前進させるためのヒントが今の政治に見いだせるのではないかと思った。

そもそもこれまでどうにかボトムアップ&技術的なアプローチで組織的なカイゼンが実現できないか考えてきた。時間はかかっても実績を積み上げることでボトムアップアプローチでもなんとかなるだろうと思っていたが、なかなか道のりは険しく組織上位層の理解や協力がなければ難しいのではないかという気がしてきた。特に、ソフトウェアの再利用戦略であるソフトウェアプロダクトラインはトップダウンのアプローチが不可欠と言える。

今の民主党の政治の進め方は、まずマニフェストという基本方針・基本計画を記したドキュメントを作成し、それを実現することを宣言し支持を取り付け、トップダウンで具体的な実現の手段を発信するというやり方だ。

何か迷いが生じたときに立ち戻るための基本方針が活動のトップにあるのはとても大事だ。広範囲な施策を講じていけばどこかでA施策とB施策の間に矛盾が生じたり、調整しなければいけなかったりするときが来る。そういうときには基本に立ち戻って何が本質に近いのかを判断しなければならない。

しかし、何よりもこれまでうまくいっていると思うのは情報公開の姿勢だと思う。政府は今、これからやることやろうとしていること、部下に指示したことが何かを特に隠すことなくオープンにしている。問題点があればすぐにマスコミや個人から「問題だ」という情報が発信されるから、行動や発言には基本方針と矛盾がないようにしておかないといけない。また、指示を受けた官庁の職員達は指示の内容がオープンにされてしまっているためサボりたくてもサボれない。ちゃんと仕事しているかどうか常に不特定多数の観客から監視されている。おそらく成果が上がれば観客から「よくやった」と評価もされるだろう。

注目したいのは、この行動や成果の情報をオープンにして議論することを恐れないという点だ。今、組織内の活動で足らないのはこのことではないかと思う。目標を示し、それをリーダーが自分の言葉で語り、活動と活動の成果を逐一公開して議論をする、これが大事なのではないか。

実際の政治の世界で重要なのはジャーナリズムだと思う。複数のジャーナリストが公平な立場でいろいろな確度から施策を分析したり評価したりすることで、その施策が正しいのか、見落としている問題がないのか精査される。施策を実行している者がその情報をフィードバックすれば軌道修正できる。

ちなみに、新聞やテレビを見ている限りジャーナリストの一部は自分の立ち位置をどこにおいていいかという迷いが見られるように思う。これまで政治の世界では見えない部分の闇が必ずあったから、体制に対して批判的な要素を突っついていればジャーナリズムとしてバランスが取れているように見えた。読者、視聴者から見て体制側に日和っているように見られないような記事、報道のスタンスを必ず入れるという習慣が付いてしまっていた。

だから、闇がないアプローチ、発言を次々とされると、突っ込みどころがなくなる。そもそも、闇のある体制に日和っているように見られる心配がなくなったことに気がついていない。突っ込むべきは掲げている目標に賛成なのか反対なのか、賛成ならば目標の実現を阻害する要因は何か、目標実現の陰で不利益を被っているものはいないかという点だ。そういう報道がこれまで体に染みついてしまった習慣で体制に日和っていると感じてしまうジャーナリズムは何でもいいからアラを探そうとする。誰と誰の意見が微妙に違っているとか、裏でこんなことでもめているといったワイドショー的なネタをニュースの枠で取り上げたりする。

ともあれ、情報をオープンにして自由な議論を許容するということがこんなに大事であり、プラスの効果をもたらすのかとこの数週間感じている。もちろん、おおもとの基本計画がしっかりしていて行動がぶれないようにしないと議論も発散してしまうと思うが、トップダウンのメッセージ発信と行動の公開、ディスカッションの誘導がカイゼンに役立つように思う。

そして、意外に大事なのは誰のための活動か、施策かを常に頭に置いた上での賛成や反対のさまざまな意見をオープンに議論するジャーナリズムであり、ソフトウェアのカイゼンの世界でもジャーナリズムは必要なのだと感じている。

このブログも組込みソフトウェアの世界でジャーナリズムの一端を担うことができればいいと思う。
 
P.S.

先の衆議院選の選挙期間中自民、公明両党がインターネット上で展開した、民主党を批判するコマーシャル(ネガティブCM)を見た人のうち6割以上、63.5%が、批判している自公両党に対して逆に「悪い印象を持った」という調査結果がでた。このネガティブCMはラーメン編プロポーズ編が特にヒット数が多かった。百聞は一見にしかずでまずは YouTube でご覧あれ。

自民党はこららのCMのヒット数が多かったことからプラスの効果があると考え、次々にネットCMを作ったようだが、実は視聴者は面白いので見るけれど、作り手側の悪意に嫌気を感じたということだろう。

ジャーナリズムはただ単に相手をあげつらえばよいという訳ではない。十分な根拠を持った批判が必要だということが分かる。

2009-09-05

体調を崩して改めて考える日々の時間の過ごし方

はじめて気管支炎になった。風邪とは違ってなかなか薬が効かず、深く呼吸をすると咳が出そうになるのでそれがストレスになる。タミフルという特効薬があるインフルエンザにかかった方がましだっただろうか。気管支炎が治るには数週間かかることもあるらしい。

なにはともあれ、健康を害するといかに健康であることがありがたいかが身にしみて分かる。そう感じることはこれまで何回かあったが、「喉元過ぎれば熱さを忘れる」で調子がよくなるとすっかり忘れてしまう。

体調が悪いと集中して仕事をすることができない。知的労働力がほとんどを占めている21世紀の社会において知的生産性が低下するのはたいへんなことだ。

そう考えると健康で集中力が高いときにいろいろやっておけばよかったと感じる。貴重な時間をボーッとしていたりテレビを見てしまったりして過ごすのはもったいなし、一日一時間ずつでもやっておけば進んでいただろうという仕事もあった。ちょっとしたマイナスの気持ちが51対49の勝負を「今日はやめておこう」というネガティブな判断に導いてしまう。

生活にメリハリを付けて働くときは働き、休むときは休んだ方がいいのはわかるが、大人になるとプライベートな時間を自己研鑽の目的に使うには誰も束縛してはくれないので、楽な方向に流されないようにしなければいけない。

体調を崩して思うのは、健康管理をキチンとやることも自己管理の範疇なんだなということだ。身体が資本だということは病気になるとよく分かる。