記事
最新の情報をお届けします
00:00:00
プロセス分解における新方針 v2

方針

エンドユーザーが操作する画面から逆算して考える。ユーザーの「必要性」と「体験」に寄り添うことで、よりよいソフトウェアになると信じているからだ。ビジネスサイドの都合や、エンジニアの都合よりも、エンドユーザーの都合を優先するという価値観をベースに、プロセスを構築する。

ただし、「三方よし」になるように注意している点も、ここに宣言しておきたい。エンドユーザーと発注者と受注者の全てがハッピーになるように設計している。開発プロセス全体が、エンジニアフレンドリーになっている自信があるし、発注能力が欠けていたとしても、騙されることなくシステム開発を進めることができるようになっている。

なぜ、三方よしに注意しているか。受託開発会社にとっての顧客は、エンドユーザーではなく、発注者であるという「根本的な課題」があるからだ。この点において容易にモラルハザードが起こる。受託者にとっては、素早く開発すれば利益率が上がるし、正直な話エンドユーザーなんて関係ない。どんな不便なシステムだとしても、受託者にとって不利益はない。このような課題がある中で、現実的な解決策は、エンドユーザーを最優先にしつつ、受託者の開発工数を明確にし、発注者が騙されない仕組みにすることだと考えた。

プロセスは、「A.顧客視点」からスタートする。ここでいう顧客とはエンドユーザーのことだ。つまり、実際に情報端末に触れる人のことだ。顧客のどのような必要性にこえるためのシステムなのか、顧客にどのような体験をしてもらうシステムなのかを考える。ボンヤリとしたアイデアからスタートし、そもそもユーザーはだれなのか、どのような必要性があるのか、どのような体験を作るのか、具体的にどのような画面を操作するのかを明確にしていくのがプロセスAの役割になる。

システムは無料ではない。そこにはサーバー代(電気代)、人件費などがかかる。システムを継続的に運用するためには、資金が必要になる。継続のためには金が必要なのだ。「B.運営視点」では、そのような問題を考える。現実的に、どのようなチームで、どのようなマーケティング、セールス、サポートの施策を打つのか。ビジネスモデルとしてどのように集金するのか。集金しないならこのシステムを継続される理由はなにか。運営上の施策がうまくいっていることを確認する指標はなにか、その指標を確認する画面はあるか。プロセスBでは、最終的に管理画面の仕様を作成し、運営スケジュールを明確にする。

プログラムを書く作業を分業にするためには、工夫が必要になる。ソフトウェアとは本来一人の人間が全体を設計し、その一人がコードを書くほうが一貫性のある美しいシステムになる。ただし、これはあくまでも理想であり、現実的ではない。現実問題として分業は必要だ。そして分業には工夫が必要だ。1つの仕事を、100分割するには知恵が必要なのだ。「C.設計視点」ではこの点にチャレンジしている。また、発注者と受注者の間で、開発完了の条件を合意することが大切になる。多くの場合、この合意に齟齬があると、ケンカの原因になる。明確に、フェアな形で合意形成ができる仕組みの構築になっている。

プロセスA,B,Cというのは、あくまでも「D.実装視点」のまえふりだ。エンドユーザーが利用できる状態まで、実装し、テストし、リリースし、モニタリングする。今後どのように修正し、システムを改善していくのかを考える段階までプロセスDでやる。