第1回目のインタビュー後半は、デザイン・開発・テスト・運用についてです。
Mogicが考える良いシステムとはどんなものなのか？どうやってそれを実現しているのか？を、外部からでは分からないチーム体制や仕事の流れを聞きながら明らかにしていきたいと思います。

今回の対談者

さまざまな視点を取り入れるデザイン

- 要件定義が終わったらデザインに入っていきます。ここはデザイナーが単独で進めていく形でしょうか？

瀬尾

ウェブデザインは、端末ごとのレイアウトやシステムの構造に影響してくるのでエンジニアやディレクターを含めてみんなで議論して進めていますよね。使いやすさや情報の整理も重要ですし。

祖川

デザインに限らず、要件定義も開発も同じですが、プロジェクトメンバ単独で作業することは少ないですね。組織内で本当に垣根があんまりないので。ここをどうしようみたいになったら、すぐ集まって議論するじゃないですか。

エンジニア的にはここはこういう造りにしたいけど、デザイナー的にはここをこうすると今までのUIとかUXのところから外れてしまうので、利用者が混乱してしまうんじゃないかみたいな意見のやりとり。

運用を考えると、ここをこうしないとオペレーションミスがあった時に困るんじゃないかとか。それぞれのメンバからの視点をうまくスピーディーに取り入れるのが特徴かもしれないですね。

瀬尾

システムのテストにしても、カスタマーサポートのメンバが入っていたりするから運用に入ってからの視点があり、全員で知恵を絞っている感じはしますね。

栗野

そもそもデザイナーやエンジニアが同じ社内にいるということ自体がMogicの大きな特徴かなという気もしていて。アウトソーシングは一切しないですし。組織の垣根がないというところがまさにそうですし、いい意味で役割分担がされていないんですよね。

- なるほど、そうやって作られるデザインはクライアントが一番気にするところかと思います。どのように提示しているのでしょうか？

祖川

サービスに対するイメージだったり、コーポレートカラーをヒアリングしつつ、いくつか案を作って議論してからクライアントに見てもらい、そこからゴールに近づけていく感じですね。

瀬尾

デザイナーが3パターンを作って、それぞれにテーマを持たせますよね。Mogicのデザイナーは、あれがすごく面白いなって、個人的に思ってますけどね。1パターン目は、初夏の爽やかさをイメージしましたとか、そういうのをいつも作ってるのはいいなと。

栗野

コンセプトボードですね。そういうのがあるから、クライアントはイメージが広がりやすいという効果もありそうです。

瀬尾

デザイン一つとっても深く考えている感は伝わります。お客さんのサービスのためにすごく考えている感じはあります。

祖川

レイアウト一つとっても、そうですよね。ここはボタンはいらないよみたいな。ここちょっとずれていて気持ち悪いみたいな。そういう違和感とか、実際に使っているユーザーさんを追体験する感じがしています。

ここからこう入ってきて、こういう操作をしたら、戸惑って、ブラウザを閉じるだろうな。こういうパターンはこういうふうな導線で来るから、いきなりここに来た時にこれだと意味が通らないというか、わけが分からなくなるよねという議論ですね。クライアントからは見えない部分ですが、いろんな場合の導線設、デザイン設計というのは徹底してやっているかなと思いますね。

システムは生きものみたいに成長する

- では、次に開発の流れをお聞きしたいと思います。要件定義で議論しながら進めているということは、どういうふうにプログラムを書けばいいか想像がついているのではないでしょうか？

祖川

それはそうですね。冒頭からシステムの設計イメージを持たせておかないと後から考え始めると大変なことになりますから。

- であれば逆に聞いてみたいのですが、要件定義の通りに進めて、実際作ってみたらうまくいかないということはないのでしょうか？

祖川

もちろん、ありますよ。もちろん要件定義で大事な要素はかなり念入りに調査しつつ進めていくんですが、それでもやっぱり細かい部分、想定しきれていなかった部分、途中で変わってしまう部分、技術のバージョンアップでどうしても変わってしまう部分がありますね。

ただ、それを考えてもどうしても譲れない本質がありますので、要件定義で外れないように明確にしていきますね。そうすれば開発でうまくいかなくなっても、今一度そこに立ち返ることができます。こういう制限はありつつも、ここが大事だからこういう造りにしようと変えていきます。

そういうのは出てきますし、システムというものはどれだけ完璧に作っても不具合は出てくるものです。当然、不具合があってゼロにはなりませんから、うまく着地できるように冗長性を持たせて作っていく。そうして、もちろん柔軟にも対応していく。最後はクライアントとコミュニケーションを取りながら、議論してやっていくというところが大事なのかなと思いますね。

- 100％完璧を目指すけれど、できない可能性も考慮して開発を進めるんですね。クライアントにも理解されるものでしょうか？

祖川

システム自体が生きものみたいだとお伝えできればと思っています。はい、生きているんです。ですから、変化していきます。使っていくにつれ、システムとしての性格が変わってきたり、時代に応じて違う意味を持つようになる。

そういう意味で作って終わりというシステムは、モノと同じく完成したときがピーク。生きものなら、時代に合わせて形を変えながら進んでいかないといけない。そういうシステムが良いシステムかなと思っています。

それをできるためのちょっと余裕を持った設計というか、将来を見越して変化を許容できるものにする。大幅にガラッと変えずに変化できるといいので、余白を用意して、吸収できるような仕組みにしておくのが大事ですね。もちろん根幹が変わると変えてしまわないといけないのですが。

- 生きものとしてのシステム。つまり、プログラムの塊とみるのではなく、システムを自分たちで環境にあわせて育てていくという印象を受けます。どのぐらいの未来まで見通しているのでしょうか？

祖川

3年から5年は見たりしますね。技術の変化が早くなってきているものの、よく設計をされてよく組まれたシステムは、10年たっても変わらず動いて、パフォーマンス出ているものです。バッと雑に作られてしまうと、もう2、3年で使い物にならなくなりますね。結構よく聞く話ですので、そのあたりは意識はしてます。

- リリース以降も長く使われることがクライアントにとっても、Mogicにとってもうれしいことですね。さて、最後にテスト工程についてお聞かせください。どのようなチェックが行われているのでしょうか？

祖川

システムのテストは、一般的にテストする部門があって担当者がいると思います。ここもMogicならではですが、関わる専門職種すべてのメンバがテストに参加します。当然全部じゃないですけど、部分的にテストに関わっていきます。

いろんな職種の人がテストをやるから、いろんな視点が入るわけじゃないですか。リテラシーが高い人もいれば低い人もいて、それぞれのレベルで混ぜてテストをすることに意味があります。

あまりウェブやアプリのシステムが分からない人だとこういう使い方をするんだなという気付きがあります。そういう点で幅の広いテストになっているので、サービスの使い勝手まで磨けるところがあるかなと思いますね。

栗野

不具合を見つけるだけじゃなくて、なかなか開発側では気づきにくい改善ポイントが上がってくるのもすごくいいところだなと。

祖川

まさにそうですね。テストを重ねていくと、今まで見えてこなかったところが分かるようになります。そうなると、プロジェクトメンバがプロジェクトと同じく成長していってる感じしますね。

リリース後はフィードバックを受けて細かく対応

- テスト後に修正して無事にリリースできたとします。リリース後の運用やサポート体制はどんな感じでしょうか？

栗野

リリース後の改善要望は結構ありますよね。使ってみて、こういう機能が欲しくなったという時に、そこも提案力と柔軟性とスピード感を持ってやっています。

祖川

本当に必要な部分は最初の開発できちんと作ってリリースするのが理想ですね。そこからフェーズ分けしてバージョンアップをくり返していく。初回のリリースですべて盛り込んで作ってしまうと、クライアントのリスクがかなり高くなってくるんです。リリース前には分からなかったフィードバックが利用者からあったりしますから。

出してみてから方向性を決めた方が効率的ともいえます。最初の段階で効果は読めないけど、開発の工数だけすごくかかる場合はフェーズ2、フェーズ3にしてはどうですかと提案したりします。サービスの成長を見ながら、開発を続けていくという提案はよくしますね。

瀬尾

実際に使われるか分からない機能でメインじゃない部分は先送りして、リリース後の反応を見て追加したりとか、別のものを追加したりとか。

あとは、要件定義や開発を通してMogicのメンバも理解が深まってきているので、システム面だけじゃなく、クライアントのビジネスモデルへの貢献をさらに考えられるようになりますから。

瀬尾

一般的な例になりますが、たいていはセールスがクライアントと話をして契約しますよね。でもセールスはそこまでデザインやシステムに詳しくない。だから、どうしても受注した後のズレが生まれてきやすいと思ってるんです。

でもMogicだとディレクターやプロジェクトマネージャーがプロジェクトメンバ全員をまきこんで議論するのでクライアントが思い描いているものを提案しやすい体制だろうなと感じています。

- 提案から要件定義、デザイン、開発、テスト、運用まですべての流れを教えていただき、ありがとうございました！他社と何がどうちがうのか、がよく理解できました。教育ITシステムを考えられている方はぜひ一度相談されてはいかがでしょうか？