『「納品」をなくせばうまくいく』を読みました
こちらの本を読んでみたので、まとめてみます。
- 常識をくつがえす「納品のない受託開発」とは
- 時代が「納品のない受託開発」を求めている
- 顧客から見た「納品のない受託開発」の進め方
- 「納品のない受託開発」を支える技術とマネジメント
- エンジニアがナレッジワーカーになる日
- さいごに
常識をくつがえす「納品のない受託開発」とは
「納品のない受託開発」は月額定額の受託開発を行います。エンジニアは「顧問エンジニア」として、お客様と直接やりとりしながらシステム開発を行います。
受託開発との大きな違いは「納品はしない」ということ。ソフトウェアは「完成させるだけ」では意味がなく、「使わないと」意味がない。そのため一括請負でソフトウェアを開発する事はありません。なぜなら一括請負ではソフトウェアが出来上がる頃には使い物にならなくなる危険性があるからです。ソフトウェアを事業の一部と考えて、「納品のない受託開発」というスタイルを取っています。
時代が「納品のない受託開発」を求めている
新規事業と要件定義の相性は最悪です。要件定義はそもそも難しい行為であり、将来に必要な機能をすべて決めてしまうのは「予言」に近い。
それと比較して、「納品のない受託開発」では見積が存在しません。インターネットサービスは作って終わりではなく、日々変化する市場に適応しながら、臨機応変に対応する形で開発を続けていく必要があるからです。
圧倒的なフィードバックの速度に対して、どれだけスピード感を持って対応していくかが、事業の成功に直結するからです。そのため引き継ぎしたシステムの改修は出来ません。素早く改修が出来ないシステムの場合は、スピード感が無くなるためです。
「納品のない受託開発」では、一括請負のように一度に多くのお金をいただくのではなく、「長く取引を続けてもらう」ことを大切にしています。
顧客から見た「納品のない受託開発」の進め方
顧客との関係性において、最も重視していることは、ビジネスの成長という共通の目的を持ってひとつのチームとして互いに協力し合うということ。そのため素早くフィードバックを得るために、ユーザへの提供タイミングをなるべく早く設定することを意識しています。また、最初のマイルストーンはユーザが初めてソフトウェアを見るタイミングなので、一番重要視しています。そしてムダな機能を作らないために、毎週マイルストーンを設定し、開発を進めています。
「納品のない受託開発」では開発と運用を同じ担当者が実施するため、情報の分断がありません。そのため引き継ぎのドキュメントが不要となり、動いているソフトウェアが「仕様」という状態になります。
「納品のない受託開発」を支える技術とマネジメント
「完成する」ことから「持続する」ことへの考え方の転換を行っています。
「バグはゼロに」→「すぐに直せること」
「あらかじめ仕込む」→「必要になるまで作らない」
エンジニアがナレッジワーカーになる日
ナレッジワーカーとはマニュアル化出来ない仕事をする人です。ソニックガーデンでは企画～運用まで得意・不得意があっても一通りの工程をこなせる人のことをプログラマーと呼んでいます。
Sierのような人月のビジネスをしていると、人を多く使うことが会社の売り上げやその人の評価につながります。「納品のない受託開発」では業務量が評価となるので、エンジニアとしての努力がそのまま会社のビジネスの結果に結びつく仕組みになっています。
「納品のない受託開発」では、「持続的であること」を大事にしており、そのために肝要なのは「急成長を目指さない」ことである。
さいごに
自分はSIer勤めなので、どうしても人月を意識して売上やコストを意識してしまいます。
「納品のない受託開発」ではその考え方が無く、エンジニアの努力が成果となっていく仕組みになっているので、自分の中で知らなかった世界が垣間見えた気がしました。
個人的に心に残っているのは「持続的であること」です。お客様と長く取引を続けることはとても大変であることを仕事の中で実感していたからです。この本は改めて大切なことを自分に教えてくれたと思います。
PoCについてまとめてみた
社内の勉強会でPoCについて触れる機会があったので、まとめてみます。
PoCとは
Proof of Concept の略。日本語に訳すと、「概念実証」という意味です。
新しいITソリューションが本番運用でも使用できるか？ということを
技術的な観点・顧客満足度など、様々な評価軸を用いて検証するフェーズのことです。
PoCは要件定義フェーズの前で行われるものであり、
「新しいソリューションを導入する前に、そもそも使えるかどうか」を検証していきます。
PoCの目的
システム開発の提案の際に用いられます。
顧客が導入するシステムにおいて、
「本当に投資をする価値があるのか？」と判断する際に、
より効果的な提案をするために、よりプロジェクトのリスクを低下させるために行われます。
野村総合研究所において、ビジネスITソリューションでの、PoCフェーズの重要性が説明されています。
PoCの流れ
PoCは大きく分けて、以下の3つのステップに分かれています。
・準備
・仮説検証
・評価
準備
Pocフェーズでは、対象業務の選定において、
提案者の方で、業務仮説を立て、顧客にヒアリングして進めていきます。
これは、業務のイメージが当初はぼんやりしているため、提案者が仮説を立てることで
対象業務をより明確に選定するためです。
このステップでは、業務ごとのINPUT/OUTPUTを意識することが重要です。
仮説検証
使用するソリューションが実際に使用できるかどうか、ソリューションの試用版を作成します。
試用版を作成する場合には、ソリューションに精通したメンバーにアドバイスをもらうなど
PoCフェーズに参加していないメンバーの協力を仰ぐことも重要です。
評価
PoCフェーズでは、顧客においての評価軸を設定し、PoCフェーズが効果的であったかを
評価してもらう必要があります。
ここでは、主に業務適合度やユーザビリティといった評価軸が用いられます。
業務適合度は、先述の「準備」ステップでおこなった際のヒアリング内容を用いて、
よりクリティカルな業務を選定する必要があります。
効果的に実施するには
スモールスタートで取り組む
PoCは検証や提案を目的としたフェーズのため、出来る限りスモールスタートで行う必要があります。
あくまで投資をする是非を評価するフェーズのため、必要最低限のソリューションを作成する必要があります。
しかし、本番運用した際のシステム構成と異なる部分が多いと、受注後のシステム構築で、認識違いや実現不可能な要件が多発してしまうため、スモールスタートのスコープを適切に設定することが大切です。
実運用で検証する
顧客の環境と近いレベルのソリューションを作成して、顧客に検証してもらうことが大切です。
顧客が使用するデバイス・ネットワーク環境・実際の業務の動きなど、
顧客の環境を意識したソリューションを提供すると、評価がされやすくなります。
PDCAサイクルの実行
評価がされやすくなったタイミングで、最初に提案したソリューションをさらに顧客の要望に近づけるために、当初定義した仮説をさらにブラッシュアップし、またソリューションに適用していきます。
これにより、顧客満足度の高いソリューションに近づけることが出来ます。
まとめてみて
PoCフェーズ自体、自分は初見だったので、
要件定義前にこういった活動をしているのかと、気づきが多い勉強会であった。
ただプロジェクトによっては、要件定義フェーズとの被りが出てしまったり、
そのあたりのやりようは考えなくてはいけないと感じた。
ただ、ソリューションの検証は個人的には顧客との意識違いをなくすいい手段だと思ったので
システム開発以外のフェーズも意識して、プロジェクトの流れを俯瞰していこうと感じた。
おわりに
今回はPoCフェーズについてまとめてみました。
提案活動は自分にとっては疎い分野であるので、今後も未知の仕事を流れを
積極的に見ていこうと思います。
