Webシステムの開発方法を話す際の最近の話題は、「見積り」に偏ってきた。どの技術を組み合わせて作るか、どういったアイデアで勝負するか、そういった観点の大切さは普遍だ。けれど、今はそうしたことよりも、どう開発体制を「維持」するか、の重みが増している。
背景には、作り出す価値を分かってもらえないというジレンマがある。アイデアを金銭に換える「方程式」がない。どんなに悩んでも、どんなに時間をかけても、どんなにアクセス数が増えても、支払われる賃金が上昇しない。豊かなアイデアは、ある程度以上の生活がないと育たない。
何を作るかという「仕様」が決まる前に、予算が決まっている。その後、余程大きな事件でもない限り、それが見直されることはない。但し、仕様は変更される。コロコロ変わると言っても言い過ぎではない。その理由は何だろう。
■
クライアント側の流れとして、発注するという時点では、技術的に何が可能で何が不可能なのかを把握している人は殆ど居ない。そもそも、そのアイデアを買うために外注するのである。だから、それ自体は当たり前のことである。
そして、打合せを重ねると、共通の（業務知識やプログラミング技術も含めて）技術的な理解が広がっていく。その進度は、担当者の個人差が大きい。どんどんと理解が進む人も居れば、毎回同じ技術的障壁にぶつかる事柄を「できますか？」と聞いてくる人もいる。
そこの部分では、技術コンサルまでも請け負っている仕事なら、説得というか教えるしかない。しかし、大抵は通常の打合せ程度しか時間の拘束はされないという前提の仕事が多い。クライアントと開発社の両輪のスピードが大きく異なると不協和音が響きだす。
知識が上昇しても、採用する技術を理解すればやりたいことが増えてくる。そして、多くの場合ユーザビリティの観点でもやりたいこと（チャレンジしたいこと）が増えてくる。こんなアイデアはどうだろう、あんな仕掛けはどうだろう。議論するだけだと楽しいが、絵に描いた餅では意味がない。誰かが実装しなければならない。そして、それには時間が確実に必要だ。その楽しさと表裏一体の部分に落とし穴がある。
勿論、最初に決めた仕様を着実に実装していく、ウォーターフォール型を今さら推奨はしない。時間がある限り、お客さまのためのより良いアイデアを練るのは歓迎すべきことだ。重ねる打合せの中で芽を出したアイデアを形にできる新しい体制こそが求められている。
そうした新体制への過渡期にあるのだと思いたい。まだ正しいものが見えないからこそ、模索しているが、辛い状況にも数多く出会う。そして、そういった状況では、お金を払う者の方が優位に立つ。技術を提供する側は何故か劣勢に立たされる。対等な契約関係のはずなのに。
そして、そういった上下関係がついてしまった時点から、真のパートナーとして歩めなくなってしまった時から、そのプロジェクトがハッピーな仕事として成立する可能性は激減する。そして得てして、エンドユーザにもハッピーな結果をもたらさない。
■
では、どうしてこうしたことが起こるのだろうか。今までの私の約十年の経験から考えると、少なくとも下記のようなポイントがある：
- 担当者が知識習得や思索に時間をかけない：
- 新しいことを学ぶのが好きでない（自ら時間をかけない）
- 別の仕事を抱えていて、そのプロジェクトに割り当てられる時間が、そもそも打合せの時間程度に限られている（体制的に時間をとれない）
- 技術的優位者が、教えるのが下手（伝わらない）：
- 見事なコードは書けるが説明ができない（そもそも説明が苦手）
- 何のためにその技術を使っているのかという戦略的説明ができなくて、眠くなる技術解説に偏る（教えるべき事柄にズレがある）
- 説明自体を避ける（説明したくない＝俺に従え）
- 金銭感覚の欠如：
- 「正当対価」という概念を知らない（社会人としての未熟さ）
- 担当者が「下請け」を「パートナー」と思はない（搾り取ればよい）
- 合意の欠如：
- 合意して進んでいくというプロセスを怠たる（時間をとらない）
- 合意の大切さを軽んじる（合意と仕様変更の関係を考慮しない）
- 無戦略：
- 何のためのプロジェクトか、何人か理解していない（お荷物）
- 何のためのプロジェクトか、全員が考えない（無軌道）
プロジェクトに火かつく時、基本的にはメンバー全員の気持ちも怒りで燃えあがる。情熱を注いでいるプロジェクトであればある程、その度合いも大きくなる。対象が人災であれ、体制災であれ、突発的な事故的災害であれ。
でも、怒りで何かが解消された経験はない。呑んで憂さをはらしても何も解決しない。時々立ち止まり、課題整理をして、対決方法に想いを巡らせるのも大切なことだ。私は問題を解消する方法は、二つしかないと思っている（実行はできていないが、まだ）：
1) 気が付いた者が何とかする
2) 相手も気が付くように仕向ける
■
まだまだ妙案に出会えた訳ではない。毎回が試行錯誤だが、方法は様々ある。担当者に宿題をだす。打合せの前日に前回議事録を付けてリマインダーを出す。mailではなくMailingListを用いる。ドキュメントで工夫する（技術ドキュメントだけでなく、コンセプトシートというプロジェクトの目的など戦略的な要注意事項のみを記したもので、毎回無軌道にならないための道標など）。
前回の議事録reviewから会議を始める。決裁権のある方を討議メンバにする。担当者がそのまま上司に提出できる資料を提供する。説得して自分が必要とする他部署も巻き込む。金曜夜中に月曜朝一の仕事を頼まれたら、次回は木曜朝にこちらから電話する。
伝える技術を磨く。分かってもらえないのは、下手な伝え方だからなのだ。上手ければ、相手に依らず伝わるはずだ。場合によっては、選手交代も考慮しながら作戦を練る。
Web屋としての知恵ではなく、社会人の知恵だ。でも、それが必要になってきている。毎晩の徹夜は「気合だーッ」だけでは乗り越えられない。生活と命がかかっているのだから。
Web開発の実態を分かりつつ、プロジェクトを円滑に進められる人が必要だ。以前、Webプロジェクトには「タイムキーパー」が必須だとするコラムを読んだことがあるが、そう呼んでも良いかもしれない。あるいは、ネゴシエータ。あるいは真のプロジェクトマネージャ。
■
私は見れなかったが、友人が教えてくれたTV番組がある。引越し屋さんの競技会。競技内容は、重いものをどう運ぶかという肉体技術系から、最初の必要ダンボール箱数の見積りと実績との比較などの予測系まで、様々。
今後のWebアプリケーション開発でも、こんなのをやって見るのも良い資産になると思う。最初の見積りと開発終了後の実績との比較。機能だけではなく、要した「人月」の時間数。打合せに要した時間。問題となったものが、技術系なのか人災系なのか。分かり易い指標で比較できたら、学ぶべきことが一目で伝わるかもしれない。
RIAコンソーシアムに経産省の方を招いて話して頂いた時、今後の日本の技術力を磨いていくための課題に触れた。いわゆる「下請け」が長時間労働で青色吐息状態であることを国は知っている。そしてそれを健全な状態だとも思っていない。つまりそうさせている原因の改善にも着手したいのだ。
Web（ネット）という、情報伝達手段・情報共有システムが、今後の知識産業の土台となって行くのは自明である。それをより豊かにするための新たな努力が、Webプロジェクトを依頼する側にも、依頼される側にも、求められ始めている。
以上。/mitsui