発注したシステムを初めて触るのが、納品の日でいいのでしょうか
システム開発を外部に発注された経験のある方に、ひとつ伺いたいことがあります。
出来上がったシステムを、ご自身の手で初めて操作したのはいつでしたか。
もしそれが「納品されてから」だったのだとしたら、その進め方にはかなりの危うさがあったと言わざるを得ません。
弊社では、いわゆるウォーターフォール開発を原則として採用していません。26年にわたって試行錯誤を重ねてきた結果、現時点で開発者とクライアントの双方にとって最善だと考えている進め方があります。今回はその中身をご説明します。
ウォーターフォール開発とは、どういうものか
まず前提として、一般的な開発の流れを整理します。家を建てる工程になぞらえると分かりやすいと思います。
一般的なウォーターフォール開発の工程
上から下へ、水が流れ落ちるように一方向に進むことから、ウォーターフォールと呼ばれます。そしてこの方法の弱点としてよく指摘されるのが、仕様変更に弱いという点です。変更が必要になれば前の工程まで戻らなければならず、手戻りが大きくなります。
ただし、ウォーターフォールが最適な領域もあります
誤解のないように申し添えますが、私はこの手法を否定しているわけではありません。
制御系とWebの両方を経験してきた立場から言えば、ウォーターフォールには明確な長所があります。ただし、それにはひとつ前提があります。
着手前に、要件をほぼ完全に固めきれる場合に限り、ウォーターフォールはブレの少ない進め方になります。作るものが最初から確定しているため、余計な往復が発生しません。
医療機器や産業機械の制御系開発は、まさにこの前提を満たす領域です。安全要件や認証の要求があり、組み合わせるハードウェアの仕様も先に確定していなければなりません。動かしてみてから考える、という余地がそもそも小さい。だからこそ、この分野ではウォーターフォールを採るべきだと考えています。
問題は、この前提が成り立たない案件にまで、同じ手法を当てはめてしまうことにあります。
要件を固めきれないまま進めた場合、ウォーターフォールはブレをなくしてくれるわけではありません。ブレを、最後まで見えないところに隠してしまうのです。
要件定義書は完成しているので、工程は順調に見えます。設計も開発もテストも、書かれたとおりに進んでいきます。しかし実際のズレが表に出てくるのは、クライアントが初めて画面に触れる受入検査の場です。
Webシステムは、事情が違います
弊社が主に手がけるのはWebシステムです。Webシステムの特徴は、変更が比較的容易で、反映も速いこと。裏を返せば、変化することが前提の領域だということです。
事業環境が変われば必要な機能も変わります。運用してみて初めて分かることもあります。その変化を「想定外」として排除する進め方は、Webシステムには向いていません。
変化に弱い手法ではなく、変化に強い手法を選ぶべきです。
まずは「60点の要件定義」から始めます
正直なところ、こういうものを作りたいという漠然とした構想はあるものの、具体的な部分はまだ固まっていない。そうしたご相談は非常に多くいただきます。
これは決して準備不足ではありません。むしろ自然なことです。日々の業務を回しながら、まだ存在しないシステムの細部まで言語化するのは、そもそも無理があります。
にもかかわらず最初から100点満点の要件定義を目指せば、要件定義工程だけが長期化し、時間も予算も膨らんでいきます。しかも、それだけ時間をかけた要件定義書が実際に100点である保証はどこにもありません。
そこで弊社は、要件定義フェーズでは多少漠然としていても構わないと考えています。まず60点の要件定義を作り、それをもとに設計のドラフトを引き、叩き台となるシステムを作り始めます。
なぜ、完成度の低い状態で作り始めるのか
理由はひとつに尽きます。
クライアントに、できるだけ早く実際の画面を触っていただくためです。
画面を触ると、打ち合わせや机上の資料では絶対に出てこなかった要件が、驚くほど出てきます。
「この項目、実は月に一度しか使わない」
「ここから前の画面に戻れないと業務が回らない」
「この一覧、担当者ごとに絞り込めないと意味がない」
こうした声は、実物がなければ出てきません。誰の準備不足でもなく、人間は動くものを見て初めて自分の業務を客観視できる、というだけのことです。
そして出てきた声を汲み取り、要件定義に反映し、設計を直し、また作る。
要件定義・システム設計・開発の三つの工程を、螺旋階段を上がるように小刻みに往復しながら、完成度を上げていきます。一直線ではなく、行きつ戻りつしながら着実に上へ向かうイメージです。
「資材が無駄になりませんか」
先ほど家の建築に例えたので、こう思われた方もいるかもしれません。作っては直すのでは、資材が無駄になって余計に予算がかかるのではないか、と。
ご安心ください。Webシステム開発では、建材を購入しません。
かかるのは設計者と開発者の手間だけです。ではその手間は大きいのか。ウォーターフォールで進めた結果、開発後期になって「思っていたものと違った」となったときの手戻りに比べれば、はるかに小さいというのが実感です。
そして何より避けたいのは、そのとき「最初の要件定義で決めましたよね」という話になってしまうことです。
契約上はそのとおりでも、残るのは使いにくいシステムだけです。クライアントが妥協するしかない状況を作らないことが、この進め方の目的でもあります。
弊社では、ヒアリング → 叩き台の作成 → 触っていただいてフィードバック → 必要なら修正、という流れを、ある程度まとまった機能ごとに繰り返します。
その結果、クライアントは納品後に一気に受入検証を行うのではなく、開発と並行して検証を進めている状態になります。
図2は、中心をスタート地点、円周上の点をゴールに見立てたものです。左のウォーターフォールでは、クライアントが思い描くゴールと開発側が想定するゴールにわずかな角度差があっても、まっすぐ進むほどその差は開いていきます。しかも、離れていることに気づけるのは到着してからです。先ほど述べた「見えないところに隠れたブレ」とは、この距離のことです。
右が弊社の進め方です。小さな円を通過するたびにフィードバックをいただき、方向を微修正します。一回あたりの修正は小さくても、それを繰り返すことでゴールのズレは広がりません。
アジャイルとDevOpsの、いいとこ取り
この進め方は、アジャイル開発とDevOpsの考え方を組み合わせたものです。ただし、どちらも教科書どおりには採用していません。
アジャイル開発から採っているもの
アジャイル開発は、短い開発サイクルを繰り返し、動くものを早い段階で出し、フィードバックを受けて方向を修正していく考え方です。弊社が取り入れているのは、この反復と対話のリズムです。
一方で、スクラムのような厳密なフレームワーク（固定長のスプリント、専任のスクラムマスター、毎日の朝会など）はそのまま持ち込みません。少数精鋭の開発体制と、通常業務を抱えながらプロジェクトに関わっていただくクライアントの実情には、運用が重すぎるからです。
DevOpsから採っているもの
DevOpsは、開発と運用を分断せず、テストやデプロイを自動化することで、変更を速く安全に反映し続ける考え方です。弊社はプロジェクトの早い段階で検証環境を立ち上げ、クライアントがいつでもブラウザから最新版を確認できる状態を保ちます。
「触ってもらう」ためには、いつでも触れる場所が必要です。特別な準備をしないと動かせない状態では、フィードバックのサイクルは回りません。
つまり、アジャイルからは反復と対話のリズムを、DevOpsからは常に動くものが置かれている環境を。この二つを組み合わせたものが、弊社の進め方です。
ひとつだけ、お願いしていること
この手法には、クライアント側にもご協力をお願いする点があります。
定期的に画面を触り、率直な感想をお返しいただく必要があります。「ここは違う」「これは使いにくい」と言っていただくことが、この進め方の燃料です。
ご負担をおかけすることは承知しています。ただ、この時間は納品後の受入検査を前倒しして分割しているものだとお考えください。最後にまとめて検証し、そこで初めて問題が見つかる状況に比べれば、確実に負担は小さくなります。
そして何より、出来上がったときに「思っていたものと違う」となる可能性を、大きく減らすことができます。
この方法が合わない場合もあります
弊社によくご相談いただくシステムの形態や事業規模には、この手法が適しているため、多くの案件でこの進め方を採っています。
ただし、すべてに当てはまるわけではありません。極端に小規模な案件、機器制御を伴う開発、認証や監査の要件から成果物と工程があらかじめ定められている案件などでは、ウォーターフォールをはじめとする別の手法を採ることもあります。
手法は目的ではありません。何を作るかによって、最も確実に届く方法を選ぶだけのことです。
おわりに
システム開発の失敗の多くは、技術的な難易度ではなく、認識のズレから生まれます。そしてズレは、気づくのが遅いほど修正が高くつきます。
弊社は、そのズレを早く、小さいうちに見つけるために、この進め方を選んでいます。
現行システムの刷新や新規開発をご検討中で、「何から決めればいいか分からない」という段階の方こそ、一度ご相談ください。要件が固まっていないことは、着手できない理由にはなりません。まずは現状のヒアリングから、一緒に整理していきます。
まずはお気軽にご相談ください。
お問い合わせはこちら