RIAプロジェクトのライフサイクル

プロジェクトの誕生から終り(次への継続分岐点)まで

RIAプロジェクトは、開発担当企業から見れば、RFP(提案依頼書/ Request For Proposal )が示された時点や、コンペを勝ち抜いた時から始まります。しかし、実際の発注者側の中ではそのかなり前から、プロジェクトの胎動が始まっています(始まっていなければなりません)。

Webサイトはもはや「作っておけばよい」という次元から、顧客との連絡通路としての明確なポジションを得つつあります。そのような状況の中で、各企業は、Webで何をやりたいのか、何をやれば成功なのかを熟考する必要性に迫られています。しかし、よほど技術的に明るくない限り、どんなことがどれ程の予算で実現できるのかを考えつつ、RFPの形にするのは難しいと言えるでしょう。なので、この時点からWeb専門集団がコンサルテーション的な立場で関わることも多いですし、パートナー的に阿吽の呼吸で話ができるチームを外部に持っていることもあります。

優秀な人材が、それぞれのコア技術領域に集中できるプロジェクトマネージメントこそ

次に注意すべきは、実装プロジェクトと並行して、様々なプロジェクトが走るという点です。図では、「社内調整プロジェクト」と「運用プロジェクト」を書きましたが、企業戦略上サイトを開設すれば万事OKという場合はあり得ないと思いますので、何かしらの調整と開設後に焦点を合わせたタスクはあるでしょう。もしなければ、実装プロジェクトの中の誰かが肩代わりしている可能性が高いと思われます。並行して走りつつ、互いの仕様をすり合わせるタイミングが多々あり、上流(設計)段階で決めておくべきことも多々あります。規模が大きくなるにつれ、自律的に並走できないと困る場合もありますので、注意が必要です。

また、調整の部分に関わる点ですが、コミュニケーション・コストの意識は、非常に大切な問題です。IT技術の高度化/コモディティ化に伴って、Webサイト(RIAプロジェクト)の開発基盤環境は常に流動的です。そんな中で、手で触れる形のないモノを、相互理解のもとで構築していく過程は容易なものではありません。また、ユニークなモノを作ろうとするほど、その難易度は想像以上に高まります。誤解しあったまま進んでいたと、驚きあう場面は珍しいものではありませんし、そもそも理解を放棄される場合もあります。具体的には長文mailの増大や長時間ミーティング、更には関係がこじれた末の無駄なドキュメント増大等の形で現れるのが一般的です。優秀な開発者が、開発に専念できずに、間接タスクに忙殺されてしまいます。ですので、時間的にも予算的にも体制的にも、「コミュニケーション」には留意し続けることは、最大のリスク回避策とも言えます。

こうしたコミュニケーション系の山場は、実はプロジェクトの初期の辺りにあるのも注意が必要です。発注者と開発者が初対面の場合、当初は何かしらの遠慮や、過度な期待が入り混じります。その辺りで、仕様の優先順位や役割分担の共通認識ができていないと、「やってくれていると思っていた」が重なり、開発末期の大きな足かせになりかねません。最近では、打ち解けた雰囲気作りも考慮して、紙芝居やポストイット等アナログな道具も交えて、意見や発想を引き出し、その場で画面設計を行い、デジカメで撮影して、それを仕様書とするということも行われるようになってきています。

最後に、スキルについての注意点です。HTMLはブログやSNS等の普及も相まって、かなり一般的に知られるようになっています。しかし、今現在進めるWebプロジェクトは、そうしたものとは一線を画します。一見シンプルに見える問題も複雑に絡み合い、それが発注者の企業ブランドにまで影響を与える場合も多々あります。形だけを安価に整えれば良い時代は終わっています。開発者の高度なスキルを、慎重に大胆に活用できるようなプロジェクト運営こそが、目指すべき企業戦略に沿うものなのです。