Diezonにおける開発プロジェクトの進め方
『クレーム0』の原理
こんにちは。Diezon人事担当の宮田です。
Diezonでは、ECサイト構築事業「REGOLITH」や、ネットスーパープラットフォーム「Racker」といったECや流通の分野でのサービスを開発・提供し、事業を展開しています。
そんなDiezonは創業から今までに数百万円～数千万円規模の受託開発案件を請け負ってきましたが、『クレーム0』という実績があります。
もちろん『クレーム0』は当社の定義によるものですが、現時点で分かりやすく言い換えると、お客様から怒鳴られたり、抗議や謝罪のために打ち合わせを設定したことは一度もありません。これは自信をもって言えます。
創業間もなく、実績が少ないというのも大きいですが、当社は『クレーム0』にはセオリーが存在していると考えています。
そこで今回はシステム業界においてクレーム0を実現するために、Diezonではどんなプロジェクトの進め方をしているかについてお話ししたいと思います。
システム業界ってクレームが起きやすいけど理不尽なわけじゃない
お客様からのクレーム、、、言葉を聞くだけでげんなりするようなワードですね。
私も今までの人生において、バイトの経験などを含めてクレームを受けるという場面に遭遇したことがあります。就職してシステムの業界に身を置くようになってからも、クレームを受けたことがあります。そこで思ったことは、この業界はクレームを受けやすい環境であるということです。
ウォーターフォール型で開発を行う場合、一般的には、システム用語を使って要件を定義するため、お客様は完成イメージを明確に持てないまま、製造に進むことも少なくありません。
システム開発では、完成品を見てから「買う」・「買わない」の判断ができないという点で、お客様からの不満が出やすくなるのも納得ですよね。
しかしクレームが出やすい環境であることを理解すると同時に、多くのクレームは決して理不尽なわけでなく、お客様に理があるものが多いとも感じました。突発的ではなく、"起こるべくして起こったクレーム"だということです。
勤務していた会社の都合もあり突っぱねた経験もありますが、逆の立場を思えばお客様側の言い分もわかると思ったことも少なくなかったです。
クレームが起きないDiezonでのプロジェクトの進め方
そんなシステム業界において、なぜDiezonは『クレーム０』なのか？
まずは、実際にDiezonではどういったことを意識しながら開発プロジェクトを進めているのか、4つのポイントで分けて考えてみました。
①要件定義：お客様との齟齬を無くす
システム開発を伴うプロジェクトにおいては避けては通れない、要件定義。要件定義は要件を定める工程であり、システム業界の私たちからすると毎回のルーチンになりがちですが、多くのお客様にとっては初めての経験です。
加えて要件を厳密に定義していくため、要件定義の工程では、システム用語が多く飛び交います。初めての経験のうえに、システム用語が飛び交っては、お客様がイメージを膨らませるにも限界があります。 こんな状況でお客様の要望をテキストにまとめても、齟齬の多い要件定義になってしまうのです。
結果、要件定義を元に開発したシステムをお客様が見た際に、「思ってたのと全然違う！」と感じられることも多いです。
そんな不幸が起きないよう、Diezonではお客様に応じて、要件定義の段階から、画面設計書やデザインをも作成しながら、齟齬の生じない要件定義を行っています。
つまり、Diezonでは要件定義と画面設計の一部を平行して行っているということです。
実際に出来上がる画面を組み立てながら要件を決めることで、お客様の要望イメージの理解を深め、互いのイメージに誤差を無くします。
②画面設計：仕様バグを徹底的に無くすシステム設計
人がソースコードを書く以上、ソースコードの中には間違いも発生します。ソースコードレベルのバグが発生すると、システムが正常に動かずお客様に不自由が生じるので、クレームに発展することがあります。しかし、お客様はシステムバグに対してよりも『仕様バグ』に対しての方が、不満が大きくなる傾向にあります。
『仕様バグ』とは、要件を定めた後の工程の画面設計時に決めた仕様通りに製造したら、機能に矛盾が生じて実際のオペレーション上、使えない機能になるといったバグのことです。
システムバグは開発会社・お客様共に「瑕疵」として認識を共有できますが、『仕様バグ』に関しては両社の認識は食い違います。開発会社側からすると、要件通りに構築を行ったという認識になる一方、クライアント側からは要件通りに実装されていないという認識になるからです。
だからこそDiezonでは、システムを使う側の人に最大限に寄り添い、「どんなシステムなら使いやすいか」ということを追求して設計を行います。これはDiezon自身の、生産性を重要視する精神が反映されているからこそだと思います。
自分たちが使うときに、一番使いやすくて、オペレーションにおいて無駄が少ない、そんなシステム作りを目指しています。
③窓口担当者：お客様を不安にさせない信頼関係を築く
システム業界で典型的な失敗プロジェクトの流れは、営業担当が「なんでもできます！」と言って安く受注し、開発フェーズで開発費用が嵩み、重要な機能が漏れた状態で納品日を迎えるという流れです。お客様は、当初見積からの追加費用発生で不満がたまっている上に、システムがきちんと出来上がらなければ、当然たまった不満が爆発します。
想像しただけで、お客様に同情してしまうケースですが、実際には多いトラブルケースです。
プロジェクトの序盤から信頼を失ってしまうと、何か些細なトラブルが生じた場合でも、お客様との調整が難航します。 調整ができないと、スケジュールの進行や要件の調整に手間取り、リリース時期にエンジニアやプログラマーに大きな負荷がかかることになります。
私たちはお客様からの信頼を失い、不安にさせてしまうことを一番危惧します。そして、信頼関係を築くためには開発フェーズごとに窓口担当者がころころと変わることは、良くないと考えます。
こうした信頼低下を防ぐため、Diezonではコンサルタントという立場の人間が、営業から納品までのフロント（お客様窓口）を一括で担います。コンサルタントが自分のプロジェクトとして、当事者意識をもってコミットすることで、お客様との信頼関係を築くことができます。
システムは在りものではないので、初期の見積り時点で開発工数が読めないことも当然ありますし、進めていくうちに実現が困難なケースもあります。 しかし、知識を持ったコンサルタントがしっかりと対応することで、お客様の信頼を裏切ることなく、プロジェクトを前に進めることができます。
④問題対処：クレームは仕組の問題
システム構築に限ったことではありませんが、問題が起きたときは初動が大切です。上記に記したように、どんなに気を付けていてもシステムバグや小さなミスは起こりうるものです。開発するシステムの規模が大きくなればなるほど、その確率も上がります。
しかしDiezonは、「トラブルは会社の問題である」という考えを基本としているので、クレームに対して社員個人の責任として解決を迫ることはありません。 社内では問題が生じた場合のエスカレーションルールも明確化しており、お客様にできるかぎりご納得いただけるように、代表が対応チームにコミットするというエスカレーションルールもあります。
Diezonには、トラブルを起こさない仕組みと、クレームが起きた際の対処方法が明確にあるため、業界でよく見られるような、バグを起こしたエンジニアがお客様に怒られながら徹夜して修正するなんてことはありません！
これは余談ですが、Diezonのコミュニケーションルールの原則は、「悪いことほど早くに報告する」というホウレンソウの基本です。 この基本ルールを全員が意識した働きをするため、システム開発のみならず、早い段階で問題がチーム共有され、迅速に対応することで、大きな問題どころか問題に発展しないことも多々あります。
Diezonにおける対クライアントポリシー
最後に、Diezonの一番根底にある話をします。
私が入社間もないとき、ふと代表にこう聞かれたことがありました。
代表「開発プロジェクトにおいて、一番大切なことはなんだと思う？」
宮田（うーん。。。プロジェクトで一番大切なことかぁー）
少し考えましたが、私は迷いなくこう答えました。
宮田「納期を守って納品することです。」
代表「うん、違うね。」
宮田「えっ？」
はい、違うんです。私も思わずえっ？と言ってしまうほど、驚きました。
プロジェクトにおいて"納期”や”納品すること”はとても大切なことで、私は前職でも納品することをとても意識して働いていました。
宮田「では、一番大切なことはなんでしょうか？保守ですか？」
代表「お客様が満足することだよ。」
宮田「 ∑(・o・;) ｱｯ 」
代表「納期を守って納品することはもちろん大事なことだけど、早くに納品することが、お客様の満足とイコールとは限らないよね？お客様の状況にもよるけど、納期が延びても、要件が100％実現できなくても、よりお客様の目的を叶えるシステムを納品できれば、その方が満足してもらえることもあるよ。」
あまりに当たり前な答えです。
それなのに私は早く納品することばかりしか頭になかったのです。これは立派なIT業界病だと思いました。
Diezonでは、どんな案件であっても『顧客満足』こそ何より大事なことだと明確に示した上で、社員一人ひとりがお客様と関わっています。
これは開発部の人間だけの話ではなく、営業ももちろんそうです。お客様と直接かかわらなくても、全ての社員が「どうやったらお客様が満足するのか？」ということを追求することこそが、Diezonのクレーム0の原理へとつながるのです。
いかがだったでしょうか？
もちろん、クレーム0にするための開発プロジェクトにおけるテクニカルなことは、もっと山ほどあります。それはまた次の機会にでもお話しますね
少しでもDiezonに興味を持ってくださった方は、ぜひ採用ページをご覧ください！
この記事を書いた人 / MAYU
新卒にて中堅規模のITベンチャーに就職し、WEBディレクターとして約100件のお客様のコンテンツマーケティングを支援する。
現在はDiezonにてディレクター、QAマネージャー、人事・労務、ライターと幅広い業務を担当。
