kintone開発を成功させるためのベンダーとの付き合い方とは？kintoneのメリットを活かして開発しよう！
"顧客が本当に必要だったもの"
「顧客が本当に必要だったもの (Tree Swing Cartoon)」という、IT業界では有名な画像があります。システム開発の難しさを風刺した絵で、顧客が欲しいものをベンダーは理解してくれず、費用ばかり高額になった挙げ句、全く違うものができてしまった…という状況を表しています。
ソフトウェア開発ベンダーの社員はこの画像を見ると「そうだよねー、どうしたらいいんだろう」と、納得しつつも、まるで自分を見ているようで恥ずかしい思いをしますし、顧客も「なぜベンダーは私たちが欲しいものをわかってくれないのだろう…」と、歯痒い思いをします。いや、「歯痒い」どころではなく、数百万円、数千万円を投じて何も役に立たないものを作られたなら、それは悪夢でしかありません。
ベンダーだけが悪いのか？
私が顧客なら、この画像を見て「本当に、頭の悪いベンダーばかりだよな…」などと上から目線でものを言いたくなりますが、ちょっとまってください。上の画像の左上と右下に注目すると、左上は「顧客が説明した要件」で、右下は「顧客が本当に必要だった物」とあります。つまり顧客は右下の画像のモノ（枝から吊り下げられたタイヤ）が欲しかったのに、ベンダーに対しては左上の画像のように「枝から吊り下げられた3段のブランコ」のように説明してしまったのです。実はそれが悪夢の始まりで、ベンダー内部では顧客の要件を、プロジェクトリーダー、アナリスト、プログラマ、営業がそれぞれ独自の解釈をし始め、プロジェクト全体がおかしな方向に向かっているのです。
このことは何を意味しているのでしょうか？
顧客もベンダーもゴールは見えない
上の風刺画が意味していることは「顧客もベンダーも本当のゴールは見えない」ということではないでしょうか？なぜ顧客は「自分たちが本当に必要なもの」がわからないのでしょうか？自分のことなのに？
これには深い原因があり、説明するのは難しいのですが、なるべくわかりやすく説明してみたいと思います。
ソフトウェア開発は「ビルの建設」とは違う
建設業を想像しましょう。作るものは、住宅でも商業ビルでもダムでも、なんでも構いません。それらをどのように作るでしょうか？まず設計して、それから製造（この場合は施工）します。当たり前ですか？そうですね。この場合、設計が完全に終了していないのに「あとは作りながら考えるよ」などとは言いません。「設計→製造」が、建設業には必須の工程です。
アーティストは？画家は「要件定義」するのか？
では、画家はどうでしょうか？設計書を書いてから、実際に絵を描くのでしょうか？下書きくらいはするかもしれません。では、その下書きはどのように描かれるでしょうか？デッサンを想像しましょう。用意するのは、鉛筆と、食パンです…あれ？食パンで消すのはもったいないですか？では練り消しゴムを買ってきてください。描いては消し、描いては消し…と、繰り返していくうちに、はじめはボンヤリしていた絵が次第にはっきりとしていきます。
別に、私たちソフトウェアベンダーは自分の仕事を「高尚なお芸術だ。私たちは芸術家だ。」と言いたいわけではありません。しかしその制作過程を観察していると、それは建設業よりも画家に近いものであり、「何度も修正していくうちに完成図が見えてくる」ものだと感じます。これは、プロのプログラマーでなくても、一度でもコーディングをした経験がある人は理解してもらえると思います。コードは、書いては消し、書いては消しをしているうちに完成に近づいていくものです。家を建てる時、少し作っては壊し、また少し作っては壊し…そんなことしますか？
建設業の作業は「ウォーターフォール」式
建設業や、ソフトウェア開発であっても大規模開発では、よくウォーターフォール式の開発が採用されます。下の図にあるように、要件定義から始まって、設計、製造、テスト…と、水が上から下に流れるように進みます。
これの何が問題なのでしょうか？上の風刺画を考えてみましょう。顧客は、自分たちが本当に必要なものをベンダーに伝えることに失敗しました。または、本当に必要なものは自分たちもよくわかっていません。そのような中、既に進んでしまったプロジェクトで顧客が「出来上がったモノ」を初めて見られるのは「システムテスト」工程が終わった時点、開発も終盤に差し掛かっているところです。ようやく顧客はその成果物をみることができました。そこで一言「私が欲しいものとぜんぜん違うんですけど」。ベンダーは大騒ぎです。プログラマーは過重労働で死にかけています。プロジェクトリーダーは明らかに不機嫌です。営業が飛んできて、こう言います「御社は要件定義書に書かれた内容で合意しましたよね？こちらには合意したエビデンスだってあるんですよ？今さら要件定義まで手戻りが発生したら、スケジュールはめちゃくちゃです！日程が延びた分は別途見積もりしますので、追加分の料金をキッチリ用意して待ってろよ！」こんな具合です。
どちらの言い分もわかるけど…
ソフトウェアベンダーの仕事は「顧客に新たな価値を創造すること」なのに、結果として「顧客が本当に必要だったもの」を作れませんでした。顧客はご不満です。当然でしょう。ベンダーも守りに入って「要件定義書に書かれた内容を作ったのだから、お金は払ってもらうぞ！」と、利益を守ることに執着して、自分たちがなぜこの仕事をしているのか、基本精神を見失ってしまいました。これではどちらも不幸になるだけです（いえ、お金はもらえるベンダーだけ得をしています）。一体何が悪かったのでしょうか？
思い出してみましょう。「顧客もベンダーもゴールは見えない」のです。なのに「要件定義書」として「見えない嘘のゴール」を作ってしまったのだから、ベンダーは「要件定義書に書かれたものを作ることがゴール」であると認識してしまいました。それでは、ベンダーの本当の仕事とは何なのでしょうか。
それは、「お客様と一緒にゴールを見つけること」です。ウォーターフォール式開発では、建設業と同じく、「設計→製造」の順番で作る前に作るものを定義します。「それが間違えなら、何も作れないじゃないか」と言いたいですか？そうです。作るものは決めましょう。しかし、「要件定義が固まったら、それ以外のものは一切作らない」という態度では、「本当に必要なもの」は作れません。顧客は必ず「そういえば、こんな機能も必要だった」と、あとから気づくものです。ウォーターフォール式の欠点は、「仕様変更に弱い」と「手戻りによってスケジュールが大幅に延びる」点にあります。「仕様など顧客にもわからない」と考えれば、ウォーターフォール式を採用するのはやめたいところです。
ウォーターフォール式を少し擁護するなら、この方式は「最初から作るものが完全に決まっている」場合なら採用してもよいでしょう。例えば、工場の生産システムなどです。あとは大規模開発にも使えるでしょう。
今回は、kintoneによる小規模な開発を前提としています。そのように考えればなおさら、ウォーターフォールを採用する理由はなくなります。
"変化ヲ抱擁セヨ"
ではウォーターフォールに変わる開発手法には、何があるのでしょうか？代表的なものは、アジャイル開発です。これは「設計→製造→テスト→リリース」を細かく分けることで、「動くモノを素早く提供する」ことができます。このリリース期間は、一般的に1週間から10日とされています。顧客は毎週「動くモノ」を見られるのですから「思っていたものと違う…」と言われても、それは「1週間の手戻り」で済むことになります。もしこれがウォーターフォールで、半年、1年のプロジェクトの最後の最後で設計段階までの手戻りが発生したら？想像するだけで恐ろしくなります。「失敗に早く気づくこと」で素早くリカバリ／方向転換ができるのは、スケジュールを延長させないためには重要なことです。
品質管理の用語でいう「PDCAサイクル」をソフトウェア開発にも適用し、このサイクルを早く回すことで前に進むのがアジャイル開発です。
アジャイル開発は顧客も巻き込みます！
「顧客が本当に必要だったもの」を作るには、顧客にも時間的なコミットをしてもらいます。「カネは払うからあとは全部よろしくね」と、ベンダーに丸振りしていたのでは、私たちベンダーも良いモノは作れません。毎朝1回とか、最低でも週に1回は顧客とミーティングを持ち、進捗と成果物を確認して貰う必要があります。そこで失敗（必ずあります）には早く気づき、早く修正して、顧客も「実際に動くモノを見て気づいたんだけど、そういえばあの機能も必要だったな…」と、仕様変更に早く気づくことができます。
私たちが向かっているゴールはどこなのか？それを顧客と一緒に見つけていくのが私たちの仕事です。
羅針盤は毎日確認！
顧客とベンダーは同じ船に乗っています。船が進んでいる方向は正しいのか？毎日確認しましょう。もし10日の航海日程で、9日目になって初めて自分たちの進んでいる方向を調べた時「進路がぜんぜん違うんだけど…」と気づいたら、できることはあまりありません。進路を毎日確認すれば、必ず正しい方向に向かいます。
kintoneはアジャイル開発に向いたサービスです
アジャイル開発をするのに、ゼロからコーディングをしていては実際に動くモノを見るまで時間がかかってしまいます。kintoneなら、顧客と一緒に画面を見ながら画面の開発ができるので、「実際に動くモノ」を見ながらミーティングもできます。まさにアジャイル開発に向いたサービスといえるでしょう。もしあなたが新しくシステム開発を考えているなら、私たちと一緒に「本当に必要だったもの」を見つけましょう！少しだけ大変ですが、その分楽しいですよ🙂
お問い合わせ
Kintone導入検討時のご相談から、導入後の利活用・定着化に至るまで、私たちは、お客様と「伴走」しながら思いを込めてサポートいたします。ご相談無料ですので、ぜひお気軽にお問い合わせください。
記事作成
kintone推進チーム 金子 🙂
使用画像
UnsplashのJeremy Bishopが撮影した写真