Chapter1/4

ユーザーに使われるためのアプリの開発にコミットする

林：アイミツアワード受賞おめでとうございます。企画提案力、とりわけ”使われるためのアプリ”にこだわり、お客様の要望を「ユーザー目線での要件定義」に落とし込んで開発を進めていく、という点が高く評価されています。それを示すように、「他社と比較するまでもなく提案の総合力が優れていると思った」などの発注者のコメントもありますね。

芝：ありがとうございます。私たちは、言われたままに開発するのではなく、ヒアリングや提案を通じた導入プロセスを重視しています。それが企画提案力という形で評価されたのだと思っています。

林：導入プロセスのところをもう少し詳しく説明していただけますか。

芝：分かりやすい例を挙げると、大手のクライアントは、開発プロジェクトの計画立案やプロジェクトの共有・コミュニケーション、進捗状況や納品物の管理など、言ってしまえば大手のSIer（システムインテグレーター）が当たり前にやっていることをちゃんとできるかということを重視します。

林：それがしっかりできていると。

芝：ええ。その過程では、それぞれのフェーズでこちらから企画・提案が必要になりますから。アイミツ経由で受注して最近、ファイナンス用のアプリをリリースしたQUICKの案件も、こうした点が評価されて話がトントン拍子に進みました。

林：なるほど。一方で、同じ発注でもアプリとシステム開発では、やはり異なる要素も多いと思いますが……。

芝：そうですね。システム開発と比べると、アプリの場合はフワッとした要望で来ることが多いと思います。そのため、最初の段階でうかがった話をもとにプロトタイプを作るなど、お客様の作りたいものを形に落として検証しながら、使われるアプリにしていくというプロセスを基本にしています。このプロセスを一言でいうと「ユーザー目線の要件定義」ということになるんですね。

林：プロトタイプを作ったりするというのもその1つだと思いますが、ユーザー目線の要件定義をしていくというプロセスを踏むと、通常の開発とどう違ってくるのですか。

芝：プロジェクトにもよりますが、基本的には実際にユーザー調査を行うことから始めます。そのために、クライアントの持っているイメージをまずデザイン・モックアップなどの形に落とします。それをユーザー見せ、フィードバックを受けることによって、事前に「こういう機能はやはりいらない」「これでは使い勝手が悪い」といったことが理解できるんです。

こうした検証をしてから開発フェーズに移るほうが、結果的にクライアントが最初に出してきた機能要件を全部入れて、てんこ盛りのアプリにしてしまうよりも確実にいいものができます。

林：アプリに限ったことではないと思いますが、IT系のプロダクトの場合、ともするとお客様は「これを作れば何でも簡単にできるようになる」と考えている面があるように思います。

芝：結局、よく考えないで作ると、「何でもできる」って往々にして「何もできない」と同義語になっちゃうんですよね。一見、ユーザー調査フェーズとかを挟むと時間やコストの無駄なような感じがしますが、作ったけれど使われないアプリになってしまうよりも、使われるという肌感覚のあるものを作るということが重要だと考えています。

林：ちょっと観点はズレますが、アプリ開発では機能要件とUX、UIのそれぞれが相互に微妙なバランスの上に成り立っていると思うんです。

芝：そうなんですよ。両方がちゃんと融合していないと「使ってもらえるアプリ」になりません。システム開発、特に業務系では、きちんと動くことが重要なので機能要件が優先する傾向がありますね。一方、web系では裏の動きがユーザーに直接的には関係ないのでUX、UIが優先する傾向があります。

アプリはその中間で、このケースならUX、UI優先だけど、このケースなら機能要件優先というさじ加減を分かった上での判断が必要になるんです。一般的にはむずかしい部分なんですが、弊社はこれまでの経験から、そこを担えるポジションにいるというのも強みと言えるかもしれません。

Chapter2/4

「言われたものを作る」だけの受託開発に感じた限界

林：いつ頃からアプリ開発を手がけているのですか。

芝：2013年くらいからです。もともとPCサイトをスマホサイトに変換するエンジンを持っていたので、スマホサイトの作成は鬼のようにやっていました。その流れでスマホサイトを作ったところから、「スマホのUIに慣れていますよね」という形で相談を受けてアプリを作るようになったのです。

林：その頃から、ユーザー目線の開発という意識はあったのですか。

芝：いや、当初は普通の受託開発の流れでアプリ開発をしていただけで、そんなことまで考えていなかったですね。意識するようになったのは2016年前後だと思います。

林：どんなきっかけがあったのでしょう。

芝：普通の受託開発は、「こんなことのできるアプリを作りたい」という機能要件から入るのがほとんどです。制作件数を重ねるなかで「機能をてんこ盛りにした状態で作ったけれど実際使われていないな」と思うことが多くなり、実際そのままお蔵入り状態になったアプリがいくつもありました。それっておカネにはなっても開発者としては最も労力を無駄にしたと感じます。やっぱり、「これを作りました」と言えるものをやったほうがいいじゃないですか。

もう1つの理由は、言われるままに作る立場では価格競争に巻き込まれるからです。結局、そこでいくら戦ってもオフショアには勝てないので、いずれビジネスとして成り立たなくなると思ったんです。

林：ビジネス・技術の両面で単なる受託の限界を感じたわけですね。そこから「ユーザー目線の要件定義」という方向性が生まれるまでには、どんな経緯があったんでしょう。

芝：まあ、「何かないか」といろいろ考えているうちに、特にクライアントが事業会社だと、アプリ開発についてはなんとなく担当者になった人が明確な意識やアイデアを持たないまま発注してくる場合が多いことに気が付いたんです。もちろん、やる気があって勉強している人もいますが、なかなか現実的なアイデアにまで落とし込めてはいません。

それが使われないアプリになる大きな原因なので、その部分についてパートナー的なポジションで仕事するということができるだろうし、そうなることができれば価格競争に巻き込まれることもないなと考えたわけです。

林：なるほど。でも、いきなり「ユーザー目線に立った要件定義で使われるアプリを作ります。だからおカネもそれなりにいただきます」と言っても、そう簡単には受け入れてもらえないと思うんですが。

芝：おっしゃるとおりです。もともと2次請け、3次請けというポジションで仕事をしていた会社だったら「ユーザー目線云々」と言っても、クライアントとの直接的なつながりがないので相手にされなかったでしょう。弊社は幸いにして自社プロダクトを持っており、下請けではなくクライアントと直取引をしていたので、入りやすかったのは確かです。それでも、この方向性でやらないと付加価値を出せないということで必死でしたね。

林：具体的には、クライアントに対してどのように説明するのですか。

芝：先ほども触れましたが、事業会社がアプリを作りたいと言ってくる場合、たいがいは機能要件だけが決まっていて、どういうものにしたいのかということについて、担当者はほぼノーアイデアなんです。競合会社のアプリを示して「こんな感じで」とか、「細かいことは分からないが、この機能は入れたい」というのがよくあるパターンですね。

林：漠然と「こんな感じのものを作りたい」というのが多いわけですね。

芝：ええ。だから、そういうクライアントに対しては「それで作ることもできますが、UXなどに基づいてユーザー側のほうから作り直すと、コンセプトから新しい、優位性のあるものが作れますよ」と説明します。また、機能要件がガチガチに固まっている場合は、「安く早く作ってほしい」「UXとかUIはいらない」といったことになりがちです。そういうときは、効果などから要件を整理し直してあげると、付加価値を認めてくれることが多いですね。

結局、クライアントは「言ったものを形にしてほしい」か「相談相手になってほしい」のどちらかなんです。相談相手になってほしい場合は我々のアプローチがはまるんですね。逆に「言ったものを安く速く作ってほしい」という場合には、オフショアのほうが絶対に強いはずなので、無理してまで勝負しません。

林：ある意味で生き残るための必然的な変化だったわけですよね。仕事のやり方などもガラリと変わったと思いますが、例えばエンジニアの人たちの反応はいかがでしたか。

芝：うーん、どうだったのかな、正直よく分からないですね（笑）。アプリのダウンロード数が増えるとうれしいといったことはあったでしょうが、一方で開発でのむずかしさも増しますから。内容はさておいて、エンジニア的には“システムの言語”で書かれた要件定義に基づいて、言われたものを作るだけの下請け開発のほうが楽という面があるのも確かなんです。

弊社はそれをやらない、と決めたので、エンジニアも皆協力して各プロジェクトを進めてくれました。体感ではありますが、大幅な手戻りやお蔵入りなどがかなり減少したので、精神的な負荷の軽減といった面でも大きな効果があったと思います。

Chapter3/4

ユーザー調査に基づき、コンセプトレベルから大胆に提案

林：「ユーザー目線での要件定義」を行うことで、最初に相手の考えていた要件定義というかアプリの内容が、ガラッと変わってしまうこともあるんですか。

芝：実際のところ、程度の差はあれほとんどの場合、変わっていますね。

林：言葉では表しにくいと思いますが、その違いはどのくらいのレベル感なんでしょう。

芝：うーん、そうですね……。極端な場合、コンセプトレベルから作り直すこともあります。最近の案件を例にしてみましょう。実はこれは開発はやっていなくて、UXとUIのところだけをやったものなんですが、最初に来たときの話は、利用履歴が確認できたりとかのよくある会員向けサービスの内容で、機能もてんこ盛りだったんです。

ただ、クライアントも「知名度のあまりない会社が普通のアプリを作っても使われないよね」という意識は持っていたので、「ユーザーに使われるアプリってどんなものだろう」「他社と同じことをやってもしようがない」というところから組み替える作業を行いました。

林：具体的には、どんなふうに変えられたのですか。

芝：会員制サービスのアプリで不満の対象になるのは大きく2つの点です。1つはログイン操作が煩雑なこと。もう1つは、アプリ内ですべては解決できず、結局分からないことがあるとコールセンターなどに連絡するようになっている上、そこで待たされてすぐには解決できないことです。

そこで、ログインをいかに簡易化させるかという作り変えと、ユーザーとの関係強化という意味も込めてコールセンターとのチャット機能を入れるなどして、「会社とユーザーの付き合い方が変わるアプリ」みたいなコンセプトを提案しました。

林：クライアントの反応はいかがでしたか。

芝：ネガティブな反応はなく、むしろリメイクしたコンセプトに基づいて、「こんな機能を入れたらどうだろうか」「こんな形でユーザーに利用してもらいたい」という声が出てきましたね。それを実際にユーザー調査で確認してみると「中途半端なものがあっても使わないし……」といった声がまたバンバン上がってくるわけです（笑）。その結果をフィードバックすることで「これダメか」「こっちのほうが受けるんだ」といったことをクライアントも理解するようになりました。

林：つまり、新しいコンセプトが魅力的であると同時に、ユーザー調査の裏付けがあるからクライアントも納得すると。

芝：ええ。明らかにユーザーの評価が低い機能を実現したいという会社はありませんからね。

林：その意味では、ユーザー調査というのがかなり重要なポイントになるんですね。

芝：ええ。ですから、ユーザー調査をするときには、競合はもちろん類似サービスからも必要なことを洗い出して設計をします。競合だけでは十分でない場合もあるからです。例えば、予約機能の場合、旅行やサロンなどいろいろ業種で使われていますから、ほかの業種から持ってきて、「こういう流れになっていれば、よりユーザーが使う」といったことも確認するんです。

次に、それに基づいてインタビューやヒアリングを行うわけですが、その際には「こんな機能があったら使いますか」といった質問をするだけではなく、モックアップ的なものなどを作ったりして、できるだけ回答者が具体的にイメージできるように心がけています。この一連の流れがノウハウとして確立しているのは強みですね。

林：確かに、「要件定義書」のようなものを見せられても、ユーザーは何のことやら分かりませんもんね。

芝：例えば、ゴルフアプリで「スコア管理機能」と書かれていれば、誰だって必要と答えるでしょう。それでは調査の意味がありません。だから具体的なイメージを示して、どんなインタフェースだったら使うかを聞くわけです。

林：サービス設計、プロトタイプの作成、ヒアリングがユーザー調査の一連の流れとのことで理解しましたが、具体的にユーザーヒアリングはどのように進めるのでしょうか。

芝：色んな手法がありますが、対面ヒアリングが主ですね。

林：その場合、ユーザーはどのように集めるんですか？

芝：想定のユーザー層はモニターを一定スクリーニングをした上で、弊社かクライアント先にて1on1、もしくはグループでインタビューを行います。目安としては、合計で5～8名くらいヒアリングするイメージですね。大体1回で1時間から1時間半くらいかかります。

林：思ったよりもガッツリとヒアリングするんですね。

芝：ええ、ただあまり数をこなしすぎるとプロジェクトに遅れが出るので、多くてもこのヒアリングは2サイクルまでに収めるようにしています。

林：なるほど。ユーザー調査を行うメリットはよく理解できましたが、やはりその分費用や時間もかかりますよね。

芝：確かに費用はかかりますし、期間もクライアントの要件定義のまま開発するほうが間違いなく短いでしょうね。規模やコンセプト設計だけやるのか、実際のユーザビリティテストまでやるのかで違うのですが、3ヵ月くらいかかりますから。

林：相当手間のかかる作業なんですね。芝さんはすべてのプロジェクトにかかわるのですか。

芝：いや。要所要所で相談に乗ったり話を聞いたりということは当然ありますが、現実的にプロジェクトが具体化した段階までかかわることはあまりないですよ。エンジニアとUX、UIのデザイナーがチームを組んでやる体制ができていますから。

林：なるほど。こんなことをうかがったのは、割とトップの方の個人的なノウハウや能力に依存していることが多い要素なんじゃないかなという気もしたものですから…。

芝：うーん、そこは半々じゃないですか。例えば、金融機関などは実績から私が入ると安心するという面はあると思います。ただ、自分自身はデザインワークができるわけではないので、実際にUX、UIで評価されているのは間違いなくデザイナーの力量によるものです。そういう意味では、個の力がチームとして噛み合う体制になっているということだと思います。

Chapter4/4

確かな裏付けでプロジェクトに対する安心感まで提供する

林：冒頭で、ユーザー目線の要件定義も含めて導入プロセスが評価されているというお話をされていましたが、ここのところをちょっと説明していただけますか。

芝：何度か触れましたが、多くのアプリ開発の場合、担当者に振られた段階では「こんなことができるものを、これくらい予算でね」といったフワッとした感じなんですね。そのまま要件定義をすると、UXやUIも詰められないのでデザインもワイヤーフレームのレベルだったりします。そうすると、この段階で見積もりを取ったとしても本当のところの予算感は分からないと思うんですよ。

林：なるほど。

芝：それで、要件定義と見積もりを上司に報告すると担当者は十中八九、「これで本当にいけるんだな」と言われるはずなんです。

林：確かに私も業務で見積もりを取るとそんなことを言われますね（笑）。

芝：2～3ヵ月の時間を使ったとしても、ユーザーの感触を事前に確認しているので、私たちの出す要件定義や見積もりは説得力が違います。仮に、当初5,000万円と想定していた予算が8,000万円とか１億円になったとしても、ある程度の裏付けがあれば、担当者は上申しやすいはずです。

林：つまり、より使われるアプリを開発するだけでなく、クライアントができないフィージビリティスタディに基づく裏付けやプロジェクトに対する安心感まで提供ししているということなんですね。

芝：極論すれば、フィージビリティなしで使われるかどうか分からないアプリを予算通りで作るのか、予算を超過しても裏付けのあるアプリを作るのか、どちらを選択しますかということだと思うんです。特に大手企業の場合は、ある程度予算があり組織文化や体制が保守的な分、後者のほうが重宝されるんです。

林：いま言われたように、大手企業に受け入れられやすいビジネスモデルだと思いますが、それは意図していたのですか。

芝：もともと持っていた自社プロダクトが大手企業にしか入らないようなもので、直取引をすることが多かったため、必然的に付き合い方が身についていた部分はありますね。逆に大手企業のなかには、“餅は餅屋”ではありませんが、ユーザー目線とかいう話なら私たちみたいな会社を使ったほうがいいぞ、ということで依頼してくるところもあります。

だから、そういうときにきちんとジャケットを着ていったら負けなんです。あえてカジュアルな格好でいって、向こうの考えにダメ出しをすることで仕事をいただけるポジションなんですよ（笑）。言うならば「四角四面のものを丸くする」みたいな役割ですかね。

林：お話をうかがっていると、フィージビリティスタディやUX、UIまでやって、実際の開発は他社がやるということもあるんですね。

芝：そういうこともよくありますよ。わたしたちは、「作る」ことにこだわっているのではなく、「使われるもの」を生み出すことにこだわっているので、どちらでもいいんです。現実問題として、「使われるもの」にこだわっていくと、サービスやビジネスのコンセプトメイキングといったビジネスの上流側にどんどん入っていくことになります。そこまでいくと、自分たちで何かを作るというレベルではありませんからね。

インタビュー後記

「顧客に訪問をする際に、あえてスーツを着ていかない」という芝さんの言葉からは、自社の立ち位置を理解しているというだけでなく、自社でやっていることに対する確かな自信がうかがえました。ただアプリを開発するのではなく、ユーザーに使われるために本質を追求するというスタンスは、顧客にとって非常に頼もしいものでしょう。自ら「多少は値が張り、手間もかかる」と認める仕事の進め方ですが、それに見合う、あるいはそれ以上の価値を生み出せる会社だと感じました。

株式会社アイスリーデザインに関する詳細情報はコチラ