第1回目の前半は、Mogicのシステム開発の提案・要件定義の秘密に迫ります。
Mogicのシステム開発は他社とどう違うのか？なぜその違いを実現できるのか？を提案・要件定義の進め方や強みから、掘り下げて聞いてみたいと思います。

今回の対談者

教育は楽しめる要素も入れる

- 記念すべき1回目ということで、初歩的なところからお聞かせください。率直にいって、普通の開発会社やウェブ制作会社との違いはどんなところにあるのでしょうか？

栗野

やはり教育ITサービスを10年以上作ってきた部分でしょうか。自分たちで考えた教育ITサービスLearnOなどもありますし、クライアントから特注で依頼を受けて作るものも相当な数になりますから。

瀬尾

開発して終わりじゃないのも大きいですね。運用しながら培った経験をノウハウとして、より良くするために次に依頼された方にも共有している感じですから。具体的な情報ではなく、汎用的に使える形にしてお伝えしますけれど。そういうプロセスが、システム開発会社やウェブ制作会社では難しいんじゃないかと思っています。

栗野

言い換えれば、教育システムでの提案力になりますね。普通は、クライアントからの要望リストを超えた内容を提案書にまとめられない。なぜなら、作って終わりだったり、数多くこなしてきていないからです。

- なるほど。数多く開発運用していく中で目に見えないノウハウが蓄積されて、提案という強みになってるんですね。では、多種多様な教育システムでどのような相談が多いのでしょうか？

瀬尾

社員向けの教育管理システムを作るパターンと、あとは自分たちで作ったコンテンツを販売するパターンが多いですね。特にプラットフォームといいますか、販路を拡大させたり、利用者が増えたりしても大丈夫なシステムが求められます。

栗野

あとは、他ではちょっと金額的、技術的に厳しくて困っている場合に最後に相談がきたりします。

瀬尾

振り返ってみると、確かにそうです。何回かコンペして結局うまくいかなかったり、無理だと断られて相談にこられることがありますね。

栗野

逆にそこが強かったりする（笑）。なぜかといえば、これまでスライドと動画とテスト機能を持つeラーニングだけを作ってきたわけじゃないから。大学にはレポート提出できる授業支援システムPhollyを作ってますし、職場のコミュニケーションシステムとしてCaiwani、あとエンタメアプリを半年に1回出しています。ですから、お堅いものばかりじゃなくて、すごろく遊びも作れる。実際に、教育は授業とテストだけじゃないですから。楽しく学んでもらう要素も作れないといけないんだと思います。

瀬尾

それこそ、小学校、中学校、高校、大学から一般企業や資格団体まで関わってきてますから、教育ITシステムだと網羅的に対応できるといえばいいんでしょうか。

クライアントから言われたものを作るだけではない

- 網羅的に対応できるということは、逆にいえば提案や開発は要望に応じて変化させなきゃいけないと思うのですが、スムーズにいくものなのでしょうか？

瀬尾

クライアントは業界のプロフェッショナルであって、システムのプロフェッショナルではないから、バラバラな要望をどううまくまとめるか、ということでしょうか

- そうですね。最初に問い合わせフォームから、こんなシステム作ってほしいと要望がきますよね。でも最初に書かれた情報ってすごく少ないと思うんです。だから、そこからどうやって打ち合わせや提案に持っていくのかなと。最初の関門ですよね。

瀬尾

それはちょっと探偵みたいですが、想像力でしょうか。問い合わせが来ましたとなって、自分たちのチームでこれは一から開発した方がいいパターンかどうかと少し話して、その企業や組織のサイトにいってニュースや商品から課題感を想像するんですね。

栗野

そういう想像をしてから、打ち合わせのアポイントを取ります。一旦思考を広げてから話に入るので、大きくブレることはないですね。

瀬尾

当然ドンピシャではないんですけど、方向性はカバーしているので、次の提案というステップまでかなりスムーズにいく方かと思っています。打ち合わせの後に、ヒアリングした内容をエンジニア、ディレクター、デザイナーで提案に向けた会議をします。エンジニア目線でより良いこと、デザイナー目線でより良いことってあるじゃないですか。それを取捨選択して、クライアントに一番良い提案を出すことにしています。早ければ1週間ほどで出しています。

栗野

そうですね。セールスだけ資料を作ることはなくて、必ず社内あちこちに蓄積されている、あらゆるノウハウを動員して提案書を作りあげていきます。

- 最初のヒアリングに戻るのですが、どのクライアントもこういう風なシステムにしたいというイメージというか、要件は固まっているのでしょうか？

瀬尾

まちまちですね。かなり固まっていて機能表を作られている場合もあれば、ざっくりと口頭ベースの相談までありますから。

- クライアントからの要望が明確であればスムーズに進みそうですが、ざっくりとした場合にどうやって提案の精度を上げていくのでしょうか？こういう技術でこうやりたいとだけ決まっているものもありますよね。

瀬尾

打ち合わせで明確にまだイメージがついていないのかなと感じたら、想像が付きやすいような話題を広げています。1回目の打ち合わせでガチッと決まるところまでは進めずに、クライアントが分かりやすいものを提供していきます。
例えば、概算の金額が分かりやすい目安になるようだったら金額を出しますし、システムの構造がイメージしやすそうだったら、システムの実績を話してみたり。複数のパターンで検討したそうなら、松竹梅と3パターンで資料を出したり。それはもうクライアントが置かれている状況次第ということですね。

- クライアントのイメージを高めながら、次のアクションにつながるように、こちらから過去のシステム開発や運用の視点で話をしていくんですね。

瀬尾

整理を手伝うといえばおおげさかもしれませんが、もし提案から先に進むとして一緒にうまくやれるように整理すると心掛けていますね。要件が固まっている、固まっていないに限らず、Mogicとしてはクライアントから言われただけを作るという方針はないんですね。
要件が固まっていたとしても、もっと良いものを提案できるんじゃないかっていう視点で打ち合わせにのぞみます。クライアントのサービスがより良く成長できれば、お互いにいいわけですから。見積金額を上げたいわけじゃないですよ（笑）。

- 提案書を出してから、クライアントの検討フェーズに入りますよね。そこはどのような形で進んでいくのでしょうか？

瀬尾

クライアントといっても、1人で検討するわけではないと思います。大勢が集まって検討を進める中で、担当者が説明に困っていないか、追加情報は必要ないかなどフォローするようにコミュニケーションをとっていますね。資料で説明しにくいところがあれば、それをこちらでもう少し分かりやすく言い直したりとか。
あと、どのクライアントであっても必ずスケジュールはあります。なので、どこ期日までに検討を終わらせないとプロジェクトが遅延してしまうなど、全体のスケジュール管理も見ています。

- 提案書を出して終わり、ということじゃなく、クライアントの状況に応じて対応を変化させていく感じなんですね。

瀬尾

はい。追加で打ち合わせしますし、見積を出しなおしたり。提案の後にもどうやっていきたいかのヒアリングを重ねて、すり合わせていくことが多いですね。良いものを一緒に作っていくには、相互理解がベースに必要なんだと思います。

システム開発は未来に向けた拡張性が必要

- 提案内容で無事に契約できたとします。そうすると次は要件定義（システムを作る前提条件のこと）のフェーズということでしょうか？

瀬尾

そうですね。原則としては、要件定義はクライアントが思い描いているものをより細かく明確にしていきます。ですから、定例の打ち合わせを設けてヒアリングして、条件を確定させて資料を作って、先に進めていく感じです。

祖川

細かく機能やデザイン、システム構成を一つずつ決めていくわけですけど、良い意味でクライアントが見えていない部分も一緒に話しながら提案していきます。システムの視点でみれば、将来の拡張性を見据えてこうした方がいいのではという意見を伝えます。
システムは未来にボトルネックが発生しはじめたら、ほとんど改修ができなくなります。ですから、そういうリスクはエンジニアしか分かりませんから、お伝えしなければなりません。デザインでも同じことで、どういうユーザーを想定して、それがどう成長するかなども見据えた拡張性が求められます。

祖川

あとは、機能は付ければ付けるだけメンテナンスや運用の負荷が上がります。せっかく作ったシステムが、そういう負荷で使えなくなってしまうのはもったいない。そこも念頭に置きつつ、一つ一つを決めていくというのを心がけています。

- Mogicのプロジェクトで要件定義を責任者として進めていく人は決まっているのでしょうか？

祖川

プロジェクトごとにプロジェクトマネージャーが決まっていて、彼らがすべてをまとめていきます。もちろん、ディレクター、デザイナー、エンジニアそれぞれの専門知識や意見も大事ですから、あくまでまとめ役なんです。
ディレクターなら社内のリソース調整をしてくれたり、過去の運用ノウハウを教えてくれたり。デザイナーなら、デザインのコンセプト提示からモックアップ（画面イメージ）、コーディングを担います。エンジニアなら、サーバーサイドやデータベース設計、フロントエンドやアプリ開発まで引き受けてくれます。
プロジェクトはそのようなメンバ構成なので、一つ一つの要件でもそれぞれ専門的な立場から意見を言い合ってもらい、作り上げています。

- 冒頭に教育ITシステム開発に10年以上の経験があるというお話がありましたが、要件定義以降でどのように生きているのでしょうか？

祖川

Mogicとして自分たちのeラーニングシステムLearnOを運用していて、かつ今まで開発したクライアントの教育ITシステムを数多くメンテナンスしています。
そこから学んだことは、やはり長期間見ていないと分からない運用上のボトルネックや改善点ですね。ここはどんなシステムでもネックになるんだな、ここは時代によって変化があるんだな、ここはよく改善の要望がくるなとか、ここは利用者から問い合わせが多いところなんだなと。そういうところが知らず知らず蓄積されています。
なので、新しいシステム開発に最初から織り込んだ上で提案し、要件定義し、設計し、開発できるいうところがやはり、Mogicの強みかなと感じています。しかも、主体的にウェブサービスとして自分たちでマーケティングし、意見をもらい、改善してきたところがクライアントと同じ目線に立てやすいのかなと。

瀬尾

この機能を付けたら、運用にかなり負荷がかかりますよとアドバイスしてますね。その機能だとカスタマーサポートの負荷が上がりますよとか。あるいは、トラフィックが増えると、サーバのコストが上がりやすいので、こういう機能で代替するのはどうでしょうかと伝えますね。

- クライアントには喜ばれそうですが、Mogicとしては売上につながらないことも多そうです。そのあたりはどう考えているのでしょうか？

瀬尾

短期的には売上にならないかもしれませんが、やはり長い目でみれば信頼関係が大事かと思っていますね。お互いを信頼できないと、サービスを長く継続できない気がしています。本当にクライアントの未来のために言っているというのは、相手に伝わるものだと思います。

祖川

同じですね。最終的にどう判断されるかはクライアント次第です。その判断に至るのにクライアントしか知らない情報もありますし、提案したことがすべてだとも思っていません。ですが、クライアントが見えていない部分は当然ありますから、そこをお伝えするのは相手への礼儀だと考えています。もちろんシステム開発でもそうですし、運用していった先に見えるところもそうだと思いますし。
だからMogicとしてお出しできる情報を説明して、その上で判断していただくのが大事ですね。そのあたりでこれまで培ったノウハウが生かされているんじゃないかなというのはありますね。

第1回目のインタビュー前半は、Mogicならではの強みを提案から要件定義までになります。後半は、要件定義後のデザイン、開発、テスト、運用について詳しく聞いています。