業務を変えるkintoneユーザー事例 第2回

悩んだのは「紙ねんど」と「ブロック」の使い分け

ハンコヤドットコムが挑んだ起死回生のkintone導入

印鑑の通販サイト「ハンコヤドットコム」を手がけるAmidAは、サイボウズのkintoneをコマースサイトのバックヤード部分に導入している。5月に行なわれた「kintone hive」でのAmidA 経営戦略室／マーケティング事業部の大田 基樹氏の講演と取材をベースに、導入の経緯を紹介したい。

AmidA 経営戦略室／マーケティング事業部 大田 基樹氏

現場が使いたいシステムは「これじゃない！」

　ハンコヤドットコムは1998年に運営を開始した老舗の印鑑通販サイト。「お客様第一主義」をモットーに、高品質・低価格で印鑑を販売するハンコヤドットコムは、今では年間27万件以上の印鑑の出荷実績を誇っている。また、同サイトを運営するAmidAは、Google AdWardsを日本でいち早く導入したデジタルマーケティングに長けた会社でもある。

印鑑のインターネット通販No.1を謳うハンコヤドットコムのサイト

　「kintoneが可能にする『ブロック＋紙ねんど』スタイルの開発」というユニークなタイトルでサイボウズのkintone導入について説明した大田さんの話は1年前のシステム導入の失敗談にさかのぼる。リリース前から1年間がんばって作ってきた完成品が、現場で使いたいものと大きく異なっていたのだ。大田氏は「作り直しを繰り返した結果、膨大な開発コストがかかり、このままプロジェクトを続けて行くのは厳しいというところまで追い込まれた」と振り返る。この結果、リセットされたプロジェクトのおはちが回ってきたのが、大田氏の所属する非IT部門である経営戦略室／マーケティング事業部だ。

前回はなぜ失敗したのか？

　しかし、当然ながらやり直しプロジェクトにはさまざまな要件が課される。これは業務運用の効率化、事業拡大に対応できるシステムを、低コスト・短期でリリースする必要があり、しかも「今回は絶対に失敗できない。あとにひけない状態だった」（大田氏）という厳しいもの。こうした要件から大田氏が選択したのが、前職で実績のあったサイボウズのkintoneだったという。「kintoneだったら、要件の厳しいプロジェクトでも大丈夫じゃないかと期待した……というか、価格、API、サポートなどを考えれば、正直kintoneしか選択肢がなかった」と大田氏は振り返る。

kintoneであれば、絶対失敗できないリセットプロジェクトでも大丈夫？

現場とのギャップをなくすプロトタイピング

　大田氏がkintoneでチャレンジしたのが、ECサイトと基幹システムの間で製造と出荷のプロセスを管理するバックヤードのシステム。結論から言うと、導入は大成功。「初期バージョンを1ヶ月でリリースでき、現場との利用イメージのギャップもなかった。必要な部分以外はすべて社内で開発を行なったので、コストを大幅に削減することができた」（大田氏）とのことだ。導入効果も上々で、30％程度の効率化が図れた。「今まで4時間くらいかかっていた作業が、極端な話ゼロになってしまった」（大田氏）

結論からすると、プロジェクトとして成功

　この背景にはkintone自体の製品の充実ぶりもあるが、やはりプロジェクトの進め方も大きかったようだ。

プロジェクト成功の3つの鍵

　まずはプロトタイピングを徹底し、実際の画面を見ながら、現場部門と試作品を作った。同社ではまず利用者にヒアリングして、要望リストを作成する。「ユーザーからの要望が正確に伝わってなかったとしたら、なにを作っても、最後にひっくり返る。だから一番重視したのが、この要望リストの作成。本当にこの機能が欲しいのか、確認した」（大田氏）。このフェーズを経た後、画面イメージを作成し、フィードバックを繰り返しながら、80％程度の完成度で機能テスト。利用者とのコンセンサスができた段階で、ようやく100％の完成版をリリースするという流れになる。

プロトタイピングで現場とのギャップを解消

　また、スクラム型のプロジェクト管理を採用したのも大きい。従来、同社は利用者の要望を全部反映したシステムを1回でリリースするようにしていた。しかし、今回はリストの中で重要度の高いものを優先し、分割しながらリリースを進めた。1週間ごと分割してリリースされたものは修正と更新が進められ、まずは使える状態にする。その後、分割されたリリースをチューニングし、確定版に近づけていくという方法だ。「8階建てのマンションを4棟建てるのに、A棟の1階、B棟の1階という風に作っていくのではなく、まずはA棟を完成させてしまう。完成すれば、A棟に入居していただくことができる」と大田氏は語る。

　重要なのは、利用者とのコミュニケーションを密にしたところ。「利用者と開発者が話し合いをしているので、ギャップがないんです。kintoneで作っているので、なにかあってもすぐに修正できる。1回リリースしてみて、使ってみてもいいよといった具合に現場のハードルが下がるんです」（大田氏）とのことで、リリースと修正を何度も繰り返した。これにより、確定版までは時間がかかるが、効果を得られるまでは短い期間で済むという。

スクラム型のプロジェクトで、1週間ごとのリリース。さらに修正・更新を繰り返す

　大田氏がKPT（Keep、Problem、Try）というフレームで、今回のプロジェクトを振り返ったところ、プロトライピングとスクラム型プロジェクト、複数回のリリースと修正という流れは非常によかったという。一方で、完璧な状態でリリースできなかった場合の撤退ラインが決まっていなかった点が反省だった。「新システムにトラブルが起こった場合に、旧システムに戻すのか、新システムを修正していくのかがあいまいで、混乱があった」と振り返る。そして、最後の「Try」に関しては、基幹システムへの展開。今後は社内の効率化を目指して基幹システムにまで拡張できるのではないかという手応えが得られたという。

（次ページ、「紙ねんど」と「ブロック」はどのように使い分けるのか？）