成功するシステム開発、失敗するシステムその差を分析してみた

これまで100本以上のシステム開発に携わってきた。
システム開発にも「成功」と「失敗」が存在する。
せっかくやるなら「成功」したいと誰しもが思うはずだ。
今回その成功確率を高める方法を分析していく。

成功と失敗の定義

そもそもシステム開発における成功の定義とは何か。
見解は人様々だとは思う。私の中では「想定以上のユーザーにご愛用いただけること」である。

じゃあ逆に失敗したシステム開発とは。これまでの経験から考えると、良い失敗と悪い失敗にさらに分解できる。各フェーズでどのようにシステム開発に向き合ったかが分岐点となっている。

良い失敗は「企画構想、要件定義、設計」に情熱をもち、関係者をほどよく巻き込み取組んだ。が、最終的にはユーザーが使ってくれるにはいたらなかったケース。

悪い失敗は、誰も真剣に取り組まず「企画構想、要件定義、設計」をないがしろにし、開発以降の工程で言った言わない問題が発生するような事案だ。

表にまとめた。

経験則的に成功する時は、上記の要素が全て揃っている。
良い悪い失敗は曖昧だが、すくなくとも情熱的に取組む主担当がいるかどうかは一つのポイントになると考える。

システム開発、アプリ開発の進め方・フェーズ・工程は以下で解説している。

情熱もった主担当

成功可否を決める50%がここで決まる。
何としても成功させたいと思っている主担当がいるか。
中小企業の場合、社長や経営陣がどこまでコミットしてシステム開発に向き合い取組むのかということも重要だ。経営陣が主担当になるケースも多々ある。
無機質なシステムを作るのに、精神論や根性論が出てくるところが不思議だ。しかし100回のシステム開発の経験結果に基づく成功事例の共通パターンとして上げざる負えない。
まさに仏作って魂入れずというコトワザの通り、ITシステムもモノづくり要素が強く魂がスタート地点からこもっていると成功しやすい。

関係者巻き込み

共感してもらえる人を上流工程でいかに巻き込むことができるかどうか。
一緒にモノづくりしている工程に、共感者たちからの意見を反映しているかどうかで、リリース後の愛用いただけるかどうかに関わってくる。
人を巻き込みすぎて動き辛くなってしまうのは本末転倒だ。
おおよそ目安として1〜3名ほどに常に関わってもらい、一緒にシステム開発を進めていくストーリーを共有することを推奨する。

言語化

上流工程で会議、打合せ、議論、話したことは面倒でも全て言語化して記録しておくと、成功確率と比例するということが判明した。要件定義書や走り書きのメモでも何でも良い。そしてメンバー全員が情報を取りにいける状況を作ること。また、変更が発生した場合にもすぐに情報共有ができるような体制と仕組みを整えておきたい。
失敗したシステム開発のセカンドオピニオン相談が来た時に、上流工程を言語化した資料が見当たらないケースが90%以上である。逆にいうと記録しておくと、成功しやすいということの裏返しである。

ユーザー愛用

社内向けシステムであれば、上記工程を丁寧にやれば100%成功する。
社外向けシステムだと、そうはいかないこともある。どうすればユーザーにささるのか、愛用してもらえるのかというデータ検証を日々チェックし次回アクションを実施することを繰り返し行うことだ。
ここでも情熱もった主担当がいることにより、愛用利用を目標としてゴールと掲げられると小さな失敗を繰り返しながらも少しずつ成功に近づいていくことができる。

まとめ

再掲載した以下の表のチェックを実施することで、システム開発は成功にかなり近づけることができる。