前回のエントリーでは、とちぎRuby会議02で発表した資料を公開したのですが、時間の都合でカットした分を公開します。死蔵しても意味ないしね。まさにディレクターズカット版です。というか、カットした部分だけ。どちらかというと、文章の書き方渋川流メソッドなので、内容的にはこちらの方が「儲かるRuby」という今回のテーマには近い気がしたけど、どうしてもアジャイルについて入れたかったのと、江渡さん栃木上陸記念を入れたかったので、こちらをカットしました。イテレーティブなドキュメンテーションとかの話しはここでの話しを飛ばしてしまうと、本編で唐突な印象だったんじゃないかな、とは思いますが・・・
儲かるドキュメントを書く場合に、何をどう書いていけばいいのか、という話しをします。まだ考え中の部分なので、これからもこの内容はどんどん変わってくると思いますが。
ソフトウェア開発にもいろいろなケースがあります。それに応じていろんなドキュメントがあります。例えば、将来が完璧に予想できるX-メンと、将来が予想できると思い込んでいる痛い人向けのウォーターフォールという開発プロセスでは、後段のプロセスの下々の人達向けに情報を伝達する目的でドキュメントを書きます。オープンソースでは、インストールやTipsなどのサポート記事を開発者以外の人がブログに書いたりしますし、MLの過去ログとして誰かがポストすることもあるでしょう。こういうのが重要な情報源だったりしますが、これも立派なドキュメントと言えます。
どのようなスタイルであっても、開発を加速して、ソフトの実体を知らない人に効率よく情報を伝えて、といった、汎用的な部分は必ずあると思います。また、ドキュメントの作成にも時間がかかるため、品質もあれば、作業時間もあるし、スコープもあります。リソースも必要です。そのため、ドキュメントもソフトウェア開発と似たようなものですし、当然「効率」というものから逃れることはできません。そこはについては、これからもじっくり考えていきたいと思っているところです。
現在、ドキュメントを分類するための方法を検討中です。なんとなく、２×２のマトリックスにできるのかな、と思います。もちろん、長くたくさん読まれるドキュメントが儲かるドキュメントです。○○仕様書って誰が得なんですかね？ユーザがそのまま読めるリファレンスマニュアルの形で書いた方が、書く方ももらう方もうれしいと思うのですが・・・「リファレンスマニュアルに書いてあることが仕様です」という契約にすればいいのに、と思います。まぁ、そのまま下請けに投げるような会社は仕様書の方ががうれしいのかもしれませんが。
多くのケースには応用できないと思いますが、僕が最近心がけていることを紹介していきます。
これが秘伝の技です。五七五にしてみました。一度音読してください。読めましたね？免許皆伝です。
具体的にどのようにイテレーションをしていくか、ということですが、文書だけを何度も書くと時間がそのまま整数倍かかります。効率が下がってしまいます。僕が最近使っている手は、話しかけられて答えた内容を文書にするとか、チャットしてから文書にするという作戦です。会話、チャットも含めて、一度アウトプットして洗練させてから文書に落とすという感じです。特に、人が介在すると「理解させよう」という意識が出てくるので、一人で何度も書くよりも品質はあがります。
文書だけの場合、時間がかかっても品質を上げたいという場合も多いでしょう。特に生きた履歴書とも言うべきブログは、場合によっては何百人、何千人という人が読みに来ますので、ちょっとでも品質が良いに越したことはありません。某ベストセラーの書き方のセミナーでは一度リライトすると品質は300%上がるということを言われました。
人にお願いするときも、メールだけで済ませるのはどうの、ということはよく言われますが、やはり、会話して、その上でメールをまとめとして送るというと、誤解がなくなって品質を上げられます。また、会話する前に一度メールの原稿だけでも作っておくと、言いたい内容が整理されて伝えやすくなるでしょう。これもスパイラルです。
文章については、今日、とちぎRuby会議に来られている角谷さんの書かれたドキュメントに関する文章や言葉はいろいろ参考になります。是非目を通されることをオススメします。
でも、ヒトコトだけ補足しておきます。最近、いろんなところで書いているし、話している内容とかぶりますが、Why?、あるいは「なぜ？」という言葉は危険な言葉です。これの危険性はみんな認識すべきです。
なぜなぜをやったり、やられたりしたことがある方は身をもって体感していると思いますが、つぎつぎと「なぜ」と言われると、逃れられないという感覚を覚えます。たいてい、目標と現在の立ち位置のギャップがある状態で言われることが多いです。そして、そのギャップというのは「ストレス」そのもの。ストレスはストレッサーからの抑圧から起こるとか分かったように書いてある本とか情報も多いですが、ストレスというのは「目標と現在の立ち位置のギャップを感じて、その本人の内部から起こる」ものです。GTDをやるとストレスが減るというのは「何かをしなければならない」という、目標が分からないけど、何かしないとだめ(現在地)という状況において、「これをやればいいんだ」という道しるべを造ってくれるからです。
「なんのための？」「だれのために？」というのは、現在地はとりあえず目をつぶって、目標だけに焦点を合わせる言葉です。このあたりはワンランク上の問題解決の技術
さて、いかがでしたでしょうか？次のLTはOSC 2009 Tokyo/Fallです。どんなに前もって作り始めても、できあがるのって当日の朝3時とかになっちゃうんですよねw
