WEBサービサーにおけるシステム開発のポイントについて、実際にサービス開発をマネジメントしている経験を元に、整理の意味も込め少しづつ書いていきたい。
ただ自分にはエンジニアリングは語れないので、技術論ではなく現場の方法論としてより現実的な視点を重視出来ればと思う。
(ちなみにここでいう「システム開発」とは、初期立ち上げ以降におけるサービス機能開発を想定した。また事業運営上必要な内部向け機能も含む)
結局のところ大枠では以下4つに分解できるはずだ。
「何を作るか?」
「どう作るか?」
「どう動かすか?」
「どう活用するか?」
以下まず初回として、各項目毎の論点を整理してみたい。
1)何を作るか?
システム開発案件の優先順位決めは重要な事業課題の一つである。とりわけ事業の成熟度が高くサービスに歴史があるほどシステムは肥大化し、属人的な問題もはらみ複雑化しがちである。
全体的には、事業戦略上の優先テーマからくる施策(トップダウン)と、サービス企画やマーケティング部門、更にはシステム部門からの改善要望(ボトムアップ)を俯瞰し、複合的に判断することになる。プラットフォーム型事業を行っている場合は営業サイド経由の意見や、外部協業先との調整も重要だ。中には、法改正や決済会社やモバイル通信キャリア側の技術仕様の変更など、必然的に対応しなければならない案件も多い。
勿論、個々には費用対効果の考慮などは必須となるが、想定効果は結局「読み」の要素も多い。この工程に対して標準的な判断基準を設定するのは意外と難しい。どういった基準とタイミングで判断していくべきか?
2)「どう作るか?」
技術要素の選定は極めて重要な意思決定要素だ。
フレームワークを採用していない現場はもはやゼロに近いはずであり、追加機能開発というレベルであれば大きな問題にならないが、新しい技術の採用になってくると慎重な判断が必要となる。
とりわけ性能要件(コスト意識も含め)にシビアにならざるを得ないWEBサービサーにとって基盤エンジニアとアプリエンジニアの連携が鍵となる。いわゆるエンジニア間に「糊しろ」を持たせるということだが、現実的にどうすればよいのか?
またユーザビリティと言う観点でデザイン要素を全体工程においてどう織り込んでいくべきかは、ビジネス的には内部的方針以上に重要な要素である。
加えて、「作る」を広義にとらえると、開発工程のスムーズな進行マネージメントのポイントも重要な論点になるだろう。
3)「どう動かすか?」
一般的なSI用語でいうところの「移行」である。B2CまたはB2B事業者の場合は顧客に、B2B2Cなどのプラットフォーム事業者の場合はマーチャントとエンドユーザのその両方に対して、サービス停止期間やサービスレベルの変更などに対する万全に配慮されたコミニケーション設計とその緻密な実行が求められる。
内部的にも、データ移行やシステムの追加修正箇所に対する品質評価やリリース手順に対する検証、サイトや紙媒体などの静的コンテンツへの影響反映など数多くのアクションアイテムを漏れなく管理する必要がある。
最近ではスマートフォンアプリのリリースなど自社サイト更新以外での展開も増え、考えるべきことは増えている。より具体的なアクションアイテムを整理したい。
4)「どう活用するか?」
せっかくのサービス・機能も、作っただけで自発的に利用が進みビジネスメリットをもたらすものはほとんどないだろう。サービス利用促進に向けた宣伝活動も含め、投資効果を最大化するためにはどうすべきか?
ずばり「いきあたりばったり」にならないということである。特に「スピード優先」という言葉に甘えて、事前の設計がずさんになってしまうことが多いのではないか?
事前のKPIの明確化と地道な定点観測及びチューニングの継続という王道の追求しかない。加えて、その利用状況により、その機能を「落とす」という判断をするタイミングをどうするか?も重要な論点になると考えている。
・・・
以上、論点になりそうな点を記述してみた。以降また回を改めて、各項目についてもう少し具体的に記述してみたいと思う。
スポンサーサイト