今回はカスタムメイド事業についてお話をお聞きします。

今回の対談者

お問い合わせの敷居が低くなったシステム開発

栗野

カスタムメイド事業は、クライアント専用のシステムを一から作っていくというものです。 ですが、教育ITシステムをはじめて作る方にはどう話しかけていけばいいか、不安に感じやすいところです。というわけで、Mogicのカスタムメイドのスペシャリストお二人に来ていただきました。それでは、瀬尾さん、祖川さん、よろしくお願いいたします。

最初に、カスタムメイド案件としてシステムを作る場合はどういう流れになるのでしょうか？お問い合わせがあり、プロジェクトが始まり、サービスが完成していきます。大枠を教えてください。

瀬尾

「ゼロからシステムを作りたい」というのもありますし、「別業界にあるシステムを自分たちの分野で応用したい」「既存の紙媒体から脱却してIT化を進めたい」というお話もあります。 新規事業の立ち上げから、既存事業での改革といった側面で幅広いです。Mogicは教育ITシステム全般にノウハウがあるので、幼児教育、小中高、大学や専門学校、社会人教育までありますね。

栗野

そもそも、どこからご相談が来ることが多いのでしょうか？

瀬尾

一つ目はウェブからの問い合わせ。10年以上前はITシステムの相談がウェブからくるなんて考えられなかったのですが、今は普通になりました。現在はあちこちでクラウドソーシングで開発したり、オフショアでの開発もありますから、相談しやすくなったのではないでしょうか。クラウドサービスのeラーニングシステムLearnOの問い合わせから、もっと開発したいとなってカスタムメイド案件になることがありますね。

二つ目は、知人や知り合いからの紹介です。割と多くて「そのシステムだったら Mogicさんが作れそうだよ」とお話しいただけるようで、直接その方から電話やメールがきます。あとはこちらは知らないけれど先方はMogicのことを知っていて、なぜかご紹介いただくことがあります。「面白い、変な会社を知ってる」と言われていたりして（笑）。

栗野

ウェブでの問い合わせと知人からの紹介ということで、どちらが多いのでしょう か？

瀬尾

昔は紹介ばかりだったのですが、最近はeラーニングシステム、LearnOの問い合わせ経由が多くなっていますね。ハードルが下がってきてるんだと思います。

栗野

クライアントはどのぐらい検討されてから相談にこられているのでしょうか？

瀬尾

正直にいって、かなりバラついています。RFPがあり、このサービスを作りたいという方は具体性がかなり高くなっていますので、要件を整理するまであまり時間がかかりません。反対にビジネス的にこうやってみたいけど、システムはさっぱりでLearnOをうまくやれば何とかならないかという相談もあります。これは時間をかけて、ヒアリングが必要になりますね。

栗野

Mogicとしてはどちらが好ましいなどありますか？

瀬尾

どちらもメリットとデメリットがありますから、一概には言えないですね。具体性があれば、精度の高い見積やご提案までのスピードはかなり速くなります。ですから、クライアントとしてはスピード感があって良いと感じられるようです。

要望はあるけどシステムのイメージがついていない場合は、過去の蓄積から数パターンの進め方をご提案できるメリットがあります。何度かコミュニケーションを取って一緒に具体化させていきますから、Mogicのノウハウを共有しやすいです。場合によっては、やっぱりここまで投資するのはもう少し先にしようということがあります。それはそれで判断が明確になりますから、お手伝いできたという点でいいかなと思っています。

お問い合わせいただければ、率直なコミュニケーションをさせていただいています。

10年の知見で、お客様の“やりたいこと”を形に

栗野

次はシステム面からの話を教えてください。クライアントから最初に要望が来てから、要件をまとめ、お見積を作ったりすると思いますが、どういう点が揃っているとスムーズになりますか？

祖川

もちろんRFPという要件をまとめた書類があればやりやすいのですが、必ずしも必要ではないと思っています。まずは成し遂げたい気持ちといいますか、将来像があれば大丈夫です。私たちはシステム的な質問が得意ですから、そこではじめて明らかになることはたくさんありますから。

やりたいことに対して質問を重ねていくことで、必要な機能が決まり、構成が決まり、ボリュームがでてきます。予算オーバーなら、うまくフェーズに分けます。「この機能はサービスをリリースした後にログデータを見てから判断しても遅くないですよ」というアドバイスをさせていただいたり。

クライアントは意外と灯台下暗しといいますか、社内で当たり前の前提条件を見落としがちです。ですから、Mogicから質問をすることで見える化されます。あらゆる角度から議論していって、やがてRFPにまとまるのが理想的ですね。

クライアントだけでRFPを作るのはすごくカロリーがかかりますし、ハードルが高いですし、不安がつきまといます。やはり、ウェブ開発に慣れているという会社は少ないですね。ですから、ウェブにするかアプリにするか、管理者やユーザーの定義はどうするかなど網羅的に話していきたいですね。

一緒にRFPから作っていくことはできると思っています。ちょっと宣伝になりますが、 RFP制作プランという商品を提供しています。そこからはじめさせていただく方が、密にコミュニケーションが取れて、将来を見越したシステム設計ができますので、最終的に効率的かなと思っています。

栗野

RFPは一緒に作ることで、クライアントとMogicが一つのチームとしてプロジェクトを運営できるんですね。

祖川

サービスのリリース後にもメリットが出てきます。運用に入った時に社内のどの部署が担当するのか、または外部に委託するのかで管理システムの権限分けが必要になります。運用時のセキュリティや操作スキルを考慮することで、スムーズなサービス展開ができます。

あとは、エンドユーザーの体験設計をお話しできるのも大きいです。ユーザーにサービスを知ってもらい、求めるものを探してもらい、会員登録してもらって、場合によって購入になります。どういうステップを作っていけばいいか、過去の事例からお伝えしています。機能的にやるのか、デザインで誘導するのか、総合的なアプローチが必要になります。

栗野

そこまで事前に準備しなくても一緒に作り上げていけるということですね。そうなってくると次にクライアントが気になりそうなのは、スケジュール感です。標準的な目安はあるものでしょうか？

祖川

正直にいえばケースバイケースです。しかし、最短で6ヶ月、長いものは1年ほどかかるかなと思います。スケジュールに大きく影響を与えるのは、ユーザー規模、機能の多さ、他システムの連携、セキュリティレベルの設定ですね。

栗野

スケジュールに加えて気になるのが、予算感だと思います。どういうケースで見積金額が大幅に増えてしまうものでしょうか？

祖川

何と言いますか、ゴールに対してシンプルにアプローチできない時でしょうか。 「よく考えると、あの機能とこの機能も欲しい」「レアケースだけど、こんな使い方をされるかもしれない」「スマホ特有の機能を実装したい」と重ねていきますと、システム要件も予算も大きく膨らみます。

100人ユーザーがいるとして、3人しか使わない機能に全体の10％の工数をかけるのはコ スパに合わないように感じますし、機能が増えた分だけ不具合がでる確率が上がります。

ですから、人がやる業務とシステムが担う業務を切り分けずに「全部システムで自動化しよう」と思うと余分に費用がかかります。システム万能主義になると機能をたくさんつけたくなり、結果的に使いづらいものができて、やがて行き詰まります。できること、できないことを切り分けて、シンプルにシステムを作る。これが一番予算内に収まります。

栗野

ただ、やはりクライアントからどうしてもやりたいことがいっぱいあると言われたら、どうするのでしょうか？加えて予算も期間も限られていると。

祖川

うまいフェーズ分けしかないですね。小さく作れば、予算や期間に間に合います。最初のバージョンで捨てるところを決めます。最も重要な機能が最低限動くようにします。リリースしたのち、ログデータを見て、管理者の反応を確認して次の実装を優先づけする形です。

一つ一つの開発を細かいループで回していきます。今では主流の開発手法かもしれませんね。Mogicは細かく手を入れていくのが得意なので、小さい開発をお勧めしています。

型にはまらず、チャレンジングに開発を続けるMogic

栗野

話は少し変わりますが、Mogicのカスタムメイドは他の開発会社と比べて、どういう特徴があるのでしょうか？強みや得意なことを教えてください。

瀬尾

長くeラーニングシステムLearnOや教育支援システムPhollyを開発し、運用していますので作りっぱなしにはならない点ですね。クライアントからの要望を、エンジニアやデザイナー、ディレクターで作られるチームに相談し、メンバ全員がクライアントと同じ方向をみて考えることが多いです。システム開発と運用は、マラソンのような長距離走です。将来を見据えて、クライアントといい関係が長く築けるように考えます。それはお互いにとって中長期的にメリットがありますから。

リリースして、徐々に良くなるシステムづくりを目指しています。リリースがゴールになると古びてくるのも早くなります。リリースしてからのバージョンアップこそ大事だとみんなが分かっているのでやりやすいかと思います。

反対にいいますと、クライアントからの要望を鵜呑みにしないので「これを実装するとこういうデメリットもありますが、どうでしょう？こんな方法がありますよ」という提案を細かくしていくことが多いです。

栗野

現在のシステムはバージョンアップありきなところがありますよね。ユーザーもバージョンアップするんだろうと思っていますから、長期戦ですね。

瀬尾

だから1年を越えるような開発をするのはリスクが高いと感じてます。細かくフェーズを切って開発していく。何事もスタートしないとフィードバックがかかりませんから。フィードバック次第では方向性が変わりますので1年未満の案件に縮めてフェーズを切らせていただきますね。

あとは1年あたりの予算感を共有いただいて、その予算内でできるアイデアをご提示することがあります。通常の開発会社だとなかなか難しいことですが、長くお付き合いしているので可能になります。

栗野

それでは最後の質問をさせてください。これまで印象に残っている提案やプロジェクトの進め方を教えてください。

瀬尾

ちょうど1年前に、これまでシステムをお作りしたクライアントから新規事業の相談を受けました。長年の信頼関係がありましたから、方向性だけお聞きして要件定義、画面仕様、デザイン、開発、テストを丸ごとお任せいただきました。もちろん、区切りごとにチェックしていただきましたが、Mogicのノウハウをうまく注ぎ込めました。

新規事業ですから、リリースしてからどんどん要望が増えたり、方向性が変わることがあります。ですが、それもクイックにスムーズに対応できました。Mogicのチームメンバがよく理解していますから、すぐに動き出せるんです。

すぐに仕様をまとめ、費用の算出をして、パターン分けを提示していく。一般的にこういう時にすぐスケジュールが伸びたり、止まったりしそうですが、それはありませんでした。

クライアントとMogicでうまくコミュニケーションを取り合い、満足度を高めていきました。終盤でも可能な範囲で仕様変更を行いました。システム開発を依頼する時、普通はなかなか柔軟に対応できないと思うんですね。仕様書をガチガチに作って、業務フローに従って作っていきますから、切り戻すような仕様変更はつらいはずです。

ですが、できたサービスを触ってはじめて分かることもありますよね。開発を依頼する側がすべてを見通せないので仕方ありません。そこにどうやってフィットさせて修正していくのか、話し合いながらスケジュールをずらさずに対応できました。仕様変更を吸収しながら、開発改善していく、Mogicらしい進め方でした。

祖川

私はエンジニアをしていたので、3年後、5年後を見据えたシステム開発を提案できたときが一番うれしいですね。そこはサービス運営を続けているからこそ、効率的にうまく考えられると思っていますし、エンドユーザー、クライアントなど利害関係者のバランスを総合的に考えていける醍醐味があります。

最初にクライアントから希望された要件に付け加える形にはなるのですが、それが受発注の関係ではなく、一つのプロジェクトとして進んでいくことかとも思っています。率直にお伝えできる関係性があるから、議論ができたり、アイデアが生まれたりします。

システム作りを依頼されたら、ただそこで終わるような作り方はしたくないなといつも 思っています。そういうプロジェクト運営をしてこれたのが良かったです。

また教育以外でAIを使うシステムの相談などもあります。社内で実験的プロジェクトとして半年に1回MicroTechサービスを世に出していますから、チャレンジングな開発も慣れています。他には断られた実験的な案件もぜひご相談ください！

栗野

ありがとうございます。私もMogicはいい意味で型にはまらない提案や開発ができる会社だと思っています。他社でできないと言われたようなシステムも Mogicだから実現できることはあります。

教育に限らず、ウェブシステム開発にご興味ある方は Mogicまで気軽にお問い合わせいただければ幸いです。では、長くなりましたが、本日も座談会をありがとうございました！

瀬尾・祖川

ありがとうございました！