連続的で不可視の「プロジェクトX」たち
「プロジェクトＸ」成功の原因は、プロジェクトを描くフォーマットにあった。つらいプロジェクト、成功への道は見えない。そこで「男たちの逆転をかけたドラマ」（だいたい番組開始35〜40分ぐらいだったか。「水戸黄門」を想起させる）が始まって、めでたくプロジェクトはうまくいく。
多くの人々がこのパターンにはまり、日本PTA全国協議会は「プロジェクトＸ」を2003、2004年度の「子供に見せたい番組」に選定するまでになった。
少し考えれば、この構図が欺瞞（ぎまん）であることはすぐ分かる。「男たちの逆転をかけたドラマ」を仕掛けなければならないという時点で、すでにプロジェクト管理は失敗しているのだから。
適切なプロジェクト管理によって、潜在的な危機を事前に回避して本当に成功したプロジェクトはドラマにも研究材料にもなりにくい。従って、なかなか人の目に止まらない。
日本Rubyカンファレンス2006というイベントで、目玉とも言えるDHHの講演の次に興味を引かれたのは、後藤謙太郎さんの「仕事で使うRuby」という、やや地味目の発表だった。
それは、まさに、「連続的で不可視の『プロジェクトX』」の話なのではないかと思う。
とは言っても、後藤さんの発表は決して大上段に構えたものではなく、Wikiとワークフロー管理ソフトの使用例であり、Rubyというプログラミング言語にフォーカスしたイベントの中では、ちょっと場違いとも思えるようなアプリケーションソフトウエアの適用事例である。
まず、私が注目したのは、魅力的だが荒削りなソフトを非プログラマにどう使わせるかというノウハウだ。
主たる内容は、影舞というバグトラッキングシステムと、HikiというWikiソフトを、ソフトウエア開発ではない業務、従って、大半のユーザがプログラマではないという環境の元で活用した話。バグトラッキングシステムは、細かいタスクに関わるワークフロー管理として使用しているそうだ。
後藤さんは、「テンプレートに客先のロゴを配置する」「印刷用スタイルシートに気を使い簡易ワープロとして使用できるようにする」「まず自分が率先してたくさんの文書を書き込み、他のユーザの参考にする」「全ての画面でバグという言葉を『案件』という言葉に変更する」と言った、さまざまな気配りと工夫によって、ユーザの感情的な拒否反応をやわらげ、多くの取引先との共同作業の中で、これを見事に活用されている。
そもそも、オフィス文書の多くは、根本的なことを言えば、情報の共有を目的としている。たくさんの文書を印刷して、会議で使ったり配布物にしたり回覧したりするのは、全て、情報の共有の為である。紙というのは、誰にとっても扱いやすく、二次加工しやすく、共有の為の媒体としては優れている。
業務にパソコンを使う時に、個人使用と一番条件が異なるのは印刷に関わることだが、それは重要ではあるが手段であり目的ではない。しかし、現実的には、「情報の共有」という目的は「見栄えのよい(見やすい)印刷」という手段無くしては考えられず、紙にすることが実質的な目的とされてきた。
しかし、気軽にチューニングできるWebアプリケーションの出現によって、多くの人が気がつかないうちに、状況は大きく変化している。
バグトラッキングシステムやWikiをうまく活用することで、直接的に「情報の共有」を目指すことも可能になりつつあるのだ。
ただし現状では、その為には、後藤さんのように、コードの中身を読みとって必要に応じて調査、修正ができる能力と、「普通の人」と会話して「普通の人」の要望を適切に理解できる人が必要で、その条件はなかなか満たされないのかもしれない。特に、後者の能力を持ったプログラマは少ない。
そもそも、後藤さんの回りの人がこれらのアプリを使うようになったのは、後藤さんとの信頼関係がベースになっているのではないかと私は推測する。
つまり、カスタマイズや細かいノウハウだけではなく(もちろんそれも重要なファクタだが)、「よくわからないけど、後藤さんが言うのなら試しに使ってみようか」と、パソコンにアレルギーがある人にも思わせてしまうような、後藤さんの人柄と実績があって成り立っているのかもしれない。
実際、影舞もHikiも、最初のうちだけ我慢しつつ最低限の学習をすれば、普通の素人にも充分使える水準にあると思う。そのようなソフトはたぶん他にもたくさんある。しかし、その「我慢しつつ最低限の学習」というのが最大の障壁なのだろう。MS-OfficeとWebアプリの差は、トップギアに入ってからの機能や使いやすさではなく、発進してギアチェンジするまでの段階を素人が越える為の障害、そこにある言語化しづらい「何か」なのだ。
後藤さんの発表はわかりやすかったけど、たぶん、簡単に他人が真似できるようなものではない。おそらく、「人柄」から「ベテランRubyプログラマとしてのプログラミングテクニック(特に調査、カスタマイズ関係)」までの間に連続的に散らばったたくさんのポイントがあって、その総合力ではじめて成り立つ事例である。
だが、その結果、「普通の人」たちの作業効率は飛躍的に高まっていると思う。何より、非定型業務の中に数多くある非定型のリスクは、たくさん可視化されて事前にたくさん回避されていることだろう。ワークフローソフトの意味はそこにある。毎日の作業については1割か2割プラスするだけで、それは学習のコストにようやく釣り合うレベルであるとしても、それが数多く蓄積され、たくさんの観点から一覧表示できる時に、そこから読み取れる情報は大きい。
その読み解き方が、また非定型で言語化できないノウハウなのだろうが、ともかく、優秀な経営者、管理者はそこに何かを読みとって、何か、ちょっと気になることにちょっとしたアクションを起こしほんのわずかの情報を得て、それによって誰にも知られないうちに(場合によっては本人も意識しないうちに)たくさんのリスクが回避されていく。
不可視のうちに回避された多くの危機を全部合体すれば、「プロジェクトX」一本分くらいのボリュームになるのではないかと私は思うのだが、これはテレビ番組にはならず、かろうじてプログラマ向けのカンファレンスの発表になるくらいだ。
しかし、普通の人の普通の仕事のあり方を根本的に変革する為のノウハウのタネみたいなものはそこに確かにあって、それは、少なくとも私にとってはテレビ番組より面白いものであった。
ただし、これまでのオフィスアプリケーションとこのようなWebアプリの違いは、カスタマイズの可否だ。共有されるソフトウエアは個人使用のそれよりはるかに多くのカスタマイズを必要とする。それは決して設定項目を増やすことでは対応できない。ソースを直接修正するまではなくても、何らかの形でソースを見て調整する要素が無くならない。コミュニティと「普通の人」の両方ときちんと会話できる技術者がいて初めて使えるものだと思う。
高品質だが仕事の根本的な変革を要求するASP系のサービスと、仕事の変革はそれほど要求しないが「普通属性」完備の技術者を要求するオープンソースアプリが、オフィスの現場で見えない競争を始めているのだ。
(参考)
Rubyカンファレンスの詳細については、まちゅダイアリーさんのまとめや、今日からはじまった、私のもうひとつのブログgem戦記等を参照してください。
