他にない、上質なITを

Column

プログラミング経験が無くても出来る、IT企画の立て方


Pocket

こういうアプリやシステムが有ったらいいな〜という企画は、プログラミング経験が無くても可能だと考えています。どんなITが欲しいのかというアイデアづくりは、IT屋さんの専売特許でもありません。

当社で作成しリリースしている「Handy」という、展示会での注文を管理できるスマホアプリがあります。Handyの誕生した背景・立ち上げた実例を元に、IT企画の立て方についてお話します。

このアプリのアイデアは、ITエンジニアでも何でもない、ある事業会社の専務から頂戴したものです。頂いたアイデアを当方が具現化しました。実際にアプリを作る所はエンジニアがプログラムを作る必要がありますが、構想立案から仮説検証までの流れは、プログラミング経験が無い方でも参考になるはずです。

業務用ハンディターミナルが高価すぎて手が出ない

Handyというアプリでやっていることは単純で、バーコードを読み込んで商品情報を取得し、注文取りを行うことです。イメージとしては、ファミレスの注文取りに似ています。ピッピと端末で商品を選択して個数を指定して操作するのと同じ使い方です。

展示会の現場では、バーコードスキャナーでバーコードを読んで効率化を図り、回転率を上げる試みはずっと前からありました。展示会は時間勝負の場です。注文取りにかかる手間は最小にしたいと誰もが思っています。コストに見え合えば。

トライアルが出来ればいいのに…

しかし、実際にバーコードを読めるハンディターミナルを導入して運営している会社はそう多くありませんでした。理由は単純で、業務用のターミナルが高かったからです。注文取りのアプリを含めても、初期費用として100万は最低必要になります。

展示会というのは、毎月毎月行うものではありません。年に4回もあるかな、という所です。日数も2日〜3日ですし、初日に比べて2日目以降はガクンと来場者が減ります。逆に言えば、初日さえクリアできれば2日目以降は手作業でも現場は回ります。

利用機会が限りなく限られているのに、初期費用に100万以上かかるものはそう簡単に手が出せない。お試しをしたくても、はじめの一歩が重たすぎて手が出ない。

そういった背景が非効率に映る展示会運営の現場であったことを知り、「スマホでサクッとできそうな気がするので、2週間ください。デモ作ってみます。使うとなったら、数万円だけ下さい」とお話をしたら、「ええやん」と。それがHandyの始まりです。

腰が重いのが課題だとしたら、簡単に始めることができるアプリを作って上げたら良い。そう考えました。

プロトタイプ作成→試験運用へ

現在のHandyはスマホのアプリケーションですが、プロトタイプではWebブラウザで動くWebアプリケーションでした。ネイティブのアプリはWebアプリを作るよりずっと時間を要します。Webブラウザなら直すのも簡単でした。

プロトタイプを作るには画面イメージが必要ですが、先方より「電卓のような感じで、個数だけ変更できて確定できればよい」と利用イメージをハッキリ頂いたので、問題なく作成することができました。操作イメージや望む使用感を明示して頂くだけでも、その後の仮説検証のスピードが全く違います。

試験運用の場では、東京国際ギフトショーを選びました。この場が主戦場だったので、ここでサクサク使えないと意味が無かったのです。あくまで試験運用であり、万が一不具合があったら使用するのを辞めて手書きに戻って頂くことをご了承頂きました。

開発者であった私は、展示会の開催日から終了日までずっと現場に張り付きました。試験運用の場で間近で利用して頂く所を見ることも重要ですし、その場で私に要望を言っていただくことが重要です。ふと思いついた内容は忘れてしまうのも速いですし、あとでまとめてと言ってもその時の感情や空気感がなくなってしまうと、熱がこもりません。鉄は熱いうちに打て、です。

Webブラウザからネイティブアプリへ

別段大きな問題はなく試験運用を終えましたが、下記の2点が課題として残りました。

  1. 商品の読み込みが遅い
  2. 入力した注文の再送信が出来ない

Webアプリだったため、バーコードを読む度にインターネット上にあるサーバにアクセスして、商品情報を取得していました。大量に人がいるためか回線が混み合うことがあるようで、やたら遅くなる時がありそれがストレスになっておりました。

もう1点は、せっかく取った注文が消えてしまうリスクが有ることでした。ネットワークの回線が遅くてタイムアウトになってしまうですとか、注文確定時に万が一技術的なエラーが発生した場合、再送信できませんでした。お客様も逐一注文内容を記憶しているわけではないので、これは大変なリスクでした。

読み込みを速くするには、端末に商品データを保存しておき、インターネットに依存しない仕組みが必要でした。また、注文データも送信前にファイルに保存して、何回でも再送信できるようにしなければならず、Webブラウザでは技術要件が合わないので、ネイティブアプリで作り直すことにしました。

バーコードリーダーがボトルネックに

ネイティブアプリ(iOS / Android)で作り直すのに半年ほどかかりましたが、展示会のサイクルが半年だったので丁度良かったです。前述した課題を乗り越えまして、アプリはサクサクと動くようになりました。残ったのは、バーコードリーダーの性能及び相性問題でした。

Android端末はハードウェア構成がメーカーによって異なるため、バーコードリーダの挙動が一致しないことが多々ありました。また、最も安価なバーコードリーダーを利用してためか、バーコードの読み込み速度が遅かったり、読み込むために光を当てても上手く読めなかったり、ペアリングしているのに動かなかったりと、怪しい挙動が散見されました。

調子の善し悪しで片付けるわけにもいかなくなったので、サポートする端末をiOS端末に絞りました。iOSであれば稼働実績が豊富な業務用途に耐えうるバーコードリーダーの選択肢が豊富だったからです。それらの紆余曲折を経て、おかげ様でHandyは高いリピート率でご高評を頂いております。

IT企画の骨子はこの2つ

  1. 誰にどんな喜びがあるのかを整理しよう
  2. 画面イメージを作ろう

最も重要なことは、どんな課題を解決するかです。「こういうことがしたい」という要望を洗い出すだけでははなく、「こういう意味があるから、こういうITが欲しい」という裏付けが絶対に必要です。それがないIT企画は、実行段階で方向性がどんどんブレてしまいます。

もう1つ絶対に欠かせないのが、画面イメージです。こういう操作がしたい!という熱い想いをお聞きしたいのです。
画面イメージなどは、紙にサラサラっと書くだけで充分です。どっかのサイトやアプリの画面キャプチャを貼り付けて頂いても構いませんし、ペーパープロトタイピングなる言葉があるぐらいです。

紙にイメージを書いて伝わらないものはITにしても伝わりません。もし、画面イメージが湧かない場合は似たようなことをやっているアプリやWebサイトを見て、イメージを膨らませて下さい。

どんな情報をどうやって表示させるのか、どういう操作を行わせたいのか。その情報を何故この画面で出すことが必要なのか。それらが「このアプリが持たねばならない機能」として整理されていきます。その整理は我々ITのプロがやりますので、何をどう表示したいのかを整理する所はご一緒に考えて下さい。そのベクトルが合うだけでも、大きな前進となるのですから。


おすすめ記事

最後までお読みいただきありがとうございました。
こちらの記事にご興味を持っていただいた方には、こちらの記事もおすすめです。

執筆者について

著者

(株) クオリティスタート 代表取締役

湯本堅隆(YUMOTO Michitaka)

略歴

1979年生まれ。ISPの電話サポートのアルバイトをきっかけにIT技術に興味を持ち、2003年にアイ・ティ・フロンティア(現タタ・コンサルタンシー・サービシズ)に新卒で入社。

SIer在籍期間からブログ「GoTheDistance」でSIerを巡るIT業界のあり方・エンジニアのキャリアについて記事を書き、累計はてなブックマーク数40,000を超えるブログになりました。

「ITを使いこなしたいなら、ユーザー企業は内製すべき」と主張しているうちに、2009年から雑貨卸の有限会社 エフ・ケーコーポレーションで内製化を1人で担当するはめに。メーカー送料ロットのない雑貨卸というビジネスモデルをITシステムを実装することで確立し、経済産業省が主催するIT経営実践認定企業に選ばれました。

「システムを作る人材や会社」はあっても「何が正しいITシステムなのか」を事業会社の立場で考え、デザインできる人材が枯渇している。

この課題を解決したいという思いから、会社を創業しました。

重度の野球好きで、東京ヤクルトスワローズのファンです。


お問い合わせはこちらから