アプリ開発は現在のIT産業において非常に重要な位置を占めています。多種多様なアプリ・サービスが星の数ほど生み出され、生活がどんどん便利になっていくのは誰もが感じているのではないでしょうか。
今回は、アプリ開発というものがどういうものか、私が関わったアプリ開発について経験談を交えながら解説していきます。将来的にアプリ開発に携わりたいと考えている人はぜひ参考にしてみてください。
アプリケーション開発とは？システム開発との違い
アプリケーション開発について知る前に、まずは「アプリケーション」というものがどういうものか解説しておきましょう。「アプリケーション」というのはOS上で実行されるソフトウェアのことです。
身近なところでいえば、Microsoftから出ているWord 、Excel、PowerPointなどのMicrosoft Officeが挙げられます。このほか、インターネットのサイトを閲覧するInternet ExplorerやGoogle Chrome、マックならSafari、こういったものもすべてアプリケーションです。
いまでは「スマホアプリ」という名前のほうがわかりやすいかもしれません。多くの人がスマホでたくさんアプリをインストールして利用していると思います。こういったさまざまなデバイス、OS上で実行されるソフトウェアを総称して「アプリケーション」と呼んでいます。
では、アプリケーション開発とシステム開発の違いはどこにあるのでしょうか。
広い意味ではシステム開発もアプリケーション開発の一部です。単純にいえば、システム開発はある企業向けに行われるもので、こういったものは「業務用アプリ」という名前で呼ばれることもあります。
ただ、IT業界においてはアプリケーション開発＝コンシューマー向け、システム開発＝企業向けというような形で呼び分けられているように感じます。
コンシューマー向けアプリとは？
コンシューマーというのは「一般消費者」のことです。つまり、コンシューマー向けアプリというのは我々一般消費者でも手に入れることができるアプリということになります。反対に、企業向けアプリを我々一般消費者は利用することはできません。
いまではBtoCというような単語で呼ばれることもあります。“Business to Consumer”の略でまさに「企業からコンシューマーに向けた商品やサービス」のことです。
では、アプリケーションにはどのような種類や特徴があるのでしょうか。
アプリケーションの種類と特徴
アプリケーションには大きく分類すると
- ネイティブアプリケーション
- ウェブアプリケーション
の2つに分けることができます。それぞれ特徴を見ていきましょう。
ネイティブアプリケーション
OS上にインストールして実行されるアプリケーション。WordやExcel、AdobeのPhotoshopなどがこれに当たります。実行される環境によって開発手段は異なります。たとえば、WindowsアプリとMacアプリはまったく別物で、両方に対応したアプリケーションを開発するためには別々に作り直す必要があります。iOSとAndroidも同様のことがいえます。
ネイティブアプリケーションは実行するデバイス（PCやスマートフォン）のスペックによっては非常に高速で処理することができ、デザインや使いやすさを重視した開発ができます。ただし、インストールしたデバイスでしか実行することができないという弱点もあります。
ウェブアプリケーション
インターネット上で実行されるアプリケーション。たとえば、GmailやDropBox、Evernoteといったものはウェブアプリケーションに該当します。いま例に挙げた3つのウェブアプリケーションはネイティブアプリケーションも開発しており、各OSにインストールすることも可能となっています。
インターネットにつながったウェブブラウザ（Internet ExplorerやChrome、Safari）があれば、世界中どこでも利用できるというのは大きなメリットです。ただし、ネイティブアプリケーションと違うのはUIがHTMLで可能な範囲に限定されるのと、実行速度がインターネット回線やデバイスのスペックに依存する点です。
アプリケーション開発で主流の「アジャイル」って？
アジャイルというのは短いスパンで要件定義、設計、実装、テスト、リリースという工程を非常に短い期間で繰り返し行う開発手法のことです。従来まで開発はウォーターフォールで行われるのが一般的でした。しかし、ウォーターフォールにはアプリケーションやサービスが公開されるまでに時間がかかりすぎるという大きな欠点がありました。
そこで生み出されたのがアジャイルです。アジャイルでは非常に短いスパンで開発を繰り返す手法で、やること自体はウォーターフォールと大きな違いはありません。ただし、一つひとつの作業の粒度がウォーターフォールほど細かくないという特徴を持ちます。そのため、作業スピードを確保できるのです。
ウォーターフォールモデルについてはこちらの記事を参照してください。
現代ビジネスにおいてスピードというものは最重視される要素の1つであり、一度開発が始まると数ヶ月～数年も時間がかかるウォーターフォール開発では対応しきれないことが多くなってきました。
システム開発に1年も2年もかけていたら、その間に経済情勢、経営方針が変わっているかもしれません。膨大なコストをつぎ込んだシステムが使い物にならないのでは目も当てられません。長い時間をかけて開発するというのはそれだけでリスクとなるのです。
アジャイルは英語で書くと“Agile”＝「機敏な」という意味の単語で、その名のとおり非常に短いスパンでアプリケーションを開発していきます。ウォーターフォールとの大きな違いは、ウォーターフォールが完璧な状態まで開発が終わらないのに対して、アジャイルでは限られた期間で開発可能なアプリ（機能）を考える点でしょう。
ウォーターフォールではすべての機能が揃った状態でクライアントに提供されますが、アジャイルでは機能ごとに区切ったアプリケーションを短期間で開発、公開することを繰り返していきます。1つの期間は1週間、2週間という短いスパンを設定されるのが一般的です。
この期間をイテレーション（反復）と呼びますが、プロジェクトメンバーはこのイテレーションで開発できる機能を優先順位も含めて話し合い、開発を進めていくのです。こうすることで、より柔軟かつスピーディにシステムを開発することができます。
では、アジャイルを採用するメリットやデメリットはどこにあるのでしょうか。
●アジャイル開発のメリット・デメリット
＜メリット＞
・変更に柔軟に対応できる
アジャイルでは、ウォーターフォールのように事細かにすべての仕様を決定していきません。チームメンバーがその場その場でコミュニケーションを取り、目の前の目標に必要な作業の確認を綿密に行っていきます。ガチガチに決めないことで、仕様変更にも柔軟に対応できるのがアジャイルの大きなメリットといえます。
・動くシステムを早く提供できる
アジャイルは1週間、2週間という非常に短期間で動くシステムを提供できます。これによってクライアントはすぐに実物を確認し、フィードバックを行うことができます。開発チームはそのフィードバックをもとにさらなる改良、機能追加を実装してくことができます。
・バグ対応のコストが最小限で抑えられる
もし、システムにバグがあったとしても、修正範囲がイテレーション内に限定されやすいという特徴があります。システムが複雑化していくと、どうしても修正の影響範囲が大きくなってしまう可能性があるのですが、アジャイルではバグ対応のコストを最小限に抑えることが可能です。
・顧客満足度の高いシステムを提供できる
短いスパンでシステムを確認しながら開発できるため、クライアントは要求ニュアンスを細かく伝えやすい、そして、開発チームはそれを実現しやすくなります。お互いが目標に向かってシステムをブラッシュアップしやすいので顧客満足度は自然と高まります。
＜デメリット＞
・方向性がブレやすい
アジャイルのメリットは柔軟に仕様を変更できる点ですが、これがそのままデメリットになるケースもあります。テストとフィードバックを繰り返していく内に、当初の目的としていたコンセプトから大きく外れてしまう可能性があります。
・全体進捗を把握しにくい
ウォーターフォールとは異なり、アジャイルは細かなスケジュールを組みません。そのため、チームメンバーがそれぞれやっていることを小まめ（基本的に朝・夕）にミーティングすることで確認する必要があります。全体に気を配れるマネージャーがいないといつの間にかスケジュールが遅れているということがあります。
・大規模開発だとスケーラビリティを見通せない
システムを開発するときはこのスケーラビリティを意識して開発することが必須です。スケーラビリティというのは「拡張性」という意味ですが、あまりピンとこない人もいるかもしれませんね。
たとえば、ユーザー登録機能を開発するにあたり、将来的に有料会員情報を追加する可能性があれば、データベースに一般会員と有料会員を識別するフラグをも持たせるようにしておく、というのも拡張性の1つになります。さらに複数の会員分類があるのであれば、フラグではなくコード（1：一般 2：有料 3：プレミアム会員など）にするのも拡張性です。大規模なシステムになると、こういった将来的な変更に対応するのが難しくなってしまうのです。
アプリケーション開発の面白い点
アプリケーション開発ではシステム開発とは違った面白い点があります。それは、クリエイティビティです。システム開発では「クライアントの求める機能」が正解となりますが、アプリケーション開発では「ユーザーが使ってくれる機能」が正解となります。
そのため、答えは1つではなく、そのために開発メンバーはさまざまなアイディアを出し合い、それを形にしていくという作業を繰り返していくことになります。詳しく見ていきましょう。
自分が良いと思ったことを形にできる
システム開発ではユーザーにとって使いやすい機能であったり、デザインを提案したりすることはあまりありません。もちろん、UIを担当する人のようなプロジェクトでも重要な役割を担う立場になれば、そういったことも可能になります。
アプリケーション開発では、プロジェクトメンバーは全員がより良いプロダクトを作る意識を持っているため、誰でも自分が良いと思ったことを提案しやすい雰囲気があります。とくにアジャイルでは話し合いが頻繁に行われますので、そこでさまざまな提案がなされます。
初めてアジャイルのプロジェクトに入ったとき、最初は何がユーザーにとって良いものかというものが見えない時期がありました。もともと私はBtoB畑の人間というのもあり、求められる最低限の仕様を実現することに必死だったというのもあります。
アプリケーション開発では「自己満足ではいけない、ユーザーが使ってくれるものを作るのが大切」といわれます。しかし、ユーザーにとって良いもの＝自分が使いたいと思えるものであることが大前提だと私は思います。
基本的に、自分が「良い」と思えるものはユーザーも良いと思ってもらえる可能性があります。それをどのように形にするかが大切で、そこで求められるのが客観的な分析と判断なのです。私の場合は、その機能をユーザーが使って喜んでいる絵が想像できるのであれば、恐れずに提案していました。
自主的に企画や開発を進められる
ウォーターフォールほど細かいスケジュールを立てないアジャイルではメンバーが各自で作業を進めていきます。そのため、機能を開発するために自分は何をするべきなのか、どういう作業が必要なのかを考えることができます。
ウォーターフォールでは概要設計者、詳細設計者、実装者、テスターのように明確な役割がフェーズごとに割り振られます。しかし、アジャイルでは開発に必要な機能が決定したら、そこからToDoリストが切り出され、チームメンバーはそのToDoを消化していくように動くことが求められます。
もちろん、ある程度タスクの割り振りは行われますが、どのように進めていくのかは個人の裁量に任される部分も多いです。
アジャイル開発は新人には難しいかもな、というのが私の感想です。新人もメンバーに組み込むのであれば、中堅メンバーからのバックアップ体制が必須になるでしょう。そうしないと、最短距離でどう動けばよいのかが判断できないからです。
私の場合は全体を管理するマネージャーがいたので、その人から指示を仰いでいました。しかし、指示の粒度が粗く、「さて、何から手をつけよう？」と一旦考えることも多かったです。
それでも技術者としてのスキルはアジャイルを経験した方が伸びやすいと思います。短いスパンで要件定義から開発、ローンチ（公開）を何度も繰り返すアジャイルは、短期間でいくつものシステムを開発しているのと同じです。反復して作業を繰り返すことで「開発」には何が必要で、どういうことをするべきなのかが理解しやすくなるためです。
リアクションがダイレクトにユーザーから届く
自分が作ったプロダクトのリアクションがダイレクトにユーザーから届くというのもアプリケーション開発の楽しみの1つです。企業相手にシステム開発をする場合、そこまでユーザーのリアクションというのはこちらまで届きません。こちらに何かフィードバックがあるのは「問題が起きたとき」くらいなのです。
しかし、アプリケーション開発では利用するのは一般ユーザーです。そのため、レビューという形でユーザーからさまざまなリアクションが届きます。当然、良いレビューもあれば悪いレビューもありますが、自分の担当した機能を喜んでくれていると嬉しくなりますし、次の機能改善でも熱が入ります。
ユーザーからの声が直接届くというのは私にとってかなり新鮮な体験でした。私はWindows Storeアプリの開発に関わっていましたが、Windows Storeでもアプリにレビューをつけることができるので、ユーザーからのフィードバックを見ることができました。
中でも、自分で考えて実装した機能を使ったユーザーが「使いやすい」「カッコいい」という評価をしてくれたのは大きな自信になったのを覚えています。
アプリケーション開発の大変なところ3選
反対にアプリケーション開発で大変なところもあります。それは、ミクロではなくマクロの視点をもつ必要がある点でしょう。ただの技術者視線ではなく、事業を成功させるという大きな視野が求められます。
システム面だけでなく、トータルで「ウケる」パッケージづくり
いくらシステム的には文句ない作りになっていても、ユーザーに使われなければ意味がありません。これがアプリケーション開発の一番難しいところといえるでしょう。たとえば、
- デザイン
- 音
- アイコン
- フォント
など、ユーザーが一番気にする部分はUI（ユーザーインターフェース）の部分ですので、ここがしっかりできていないとそもそも使ってもらえません。ユーザーからすれば、システムがしっかりしているのは「当たり前」なのです。そういう意味ではシステム開発よりもシビアといえるでしょう。
私の場合、ここの部分でかなり苦労したのを覚えています。私のようにシステム開発でバックエンド（サーバー処理）をメインに担当してきた人間は、フロントエンド（デザイン）も任されるととても困ります。
たとえば、アプリアイコンの制作を任されたことがあるのですが、ベースの素材があるからといってどうすれば正解なのかわからないのです。配置は？配色は？大きさは？結局無難なところに落ち着いてしまい、デザイン経験者に修正されてしまいました。
しかし、こういった「魅せ方」というのは勉強しておいて損はありません。機会があればどんどんチャンレンジしたほうがよいと思います。
開発だけ気にしていればいいわけではない
アプリケーション開発では、開発だけに集中していれば良いわけではないという側面があります。これは、言われたものを作っておけばOKというわけではないという意味です。システム開発でも同じことがいえますが、アプリケーション開発の方がよりシビアに見られる傾向があります。
どういうことかというと、アプリケーションは公開されてからが本当の勝負です。ユーザーがどうやって利用しているのか、どの機能に満足して、どの機能に不満を持っているのか、そもそも使われているのか、などを総合的に分析・評価していきます。
そこから機能改善や機能追加が行われていくため、作っているアプリケーションが本当にユーザーフレンドリーなのかを常に気にする必要があるのです。
「ユーザーフレンドリー」どの仕事にしても重要な考え方です。どのような機能がユーザーに使ってもらえるのか、使いやすいのかということを常に気にするのはとても勉強になりました。
これはライティングの道に進んだ今でも役に立っています。どうすれば、読んでもらえるのか、読みやすいのか、そういう文章を作れるように日々勉強しています。
こうしたスキルを身につける最短ルートは、たくさん類似のサービスに触れることです。実際に使ってみて「ここのボタン配置は使いやすい」「図を入れるとわかりやすい」などのように考察するのです。これが自分の血肉となっていきます。
バージョン管理が複雑になることも
アプリケーション開発ではリリーススケジュールの都合で次のバージョンと、さらに次のバージョンを同時並行で作っていたりします。通常、プログラムコードは変更履歴を残すためにソース管理ツールを使って開発しますが、まったく違うバージョン（ブランチ）のソースを変更してしまってトラブルが起きてしまうことが稀にあります。SEは研修のときから「コミットは慎重に行うように」と散々言われていますが、人間ミスはするものです。問題はどうすればミスを防げるのか、ミスをしたとしても被害を最小に食い止められるかの仕組みづくりができているか、です。
複数のバージョンを同時に開発するときはとにかく慎重に作業をするようにしました。自分が編集しているファイルはどのバージョンのものなのかをチェック、編集をコミット（記録）するときにもチェックしました。
それでもミスは起こるもので、何度か別のバージョンのファイルを編集してコミットしてしまったことがあります。幸い、そこまで大きくないプロジェクトだったので二次災害にはならず、人知れず元に戻しておきました。
大切なのは大きなミスをしたかな？と思ったときはかならず確認することです。「大丈夫だろう」という希望的観測は重大なトラブルの原因になります。
どこが違う？BtoCアプリケーション開発とBtoBシステム開発
BtoCのアプリケーション開発とBtoBのシステム開発、両者の違いはどこにあるでしょうか。
BtoCではマーケティングの素養が求められる
これは言い換えればいかにユーザー目線でプロダクトを作ることができるか、ということです。アプリケーションは使ってもらうことで収益が上がるものですから、どうしたら使ってもらえるのかを常に考える必要があります。
BtoBではクライアントが求める「仕様を実現する」ことが正義であり、それについてのみ追求していれば良いという側面があります。しかし、BtoCは明確な正解がなく、マーケットのみが正義、ということになります。
そういう意味では、BtoCの方がプロダクトを「売る」というマーケティング的な素養が求められるでしょう。これは一朝一夕で身につくスキルではありません。常にユーザー心理を理解し、それに合わせたプロダクトを提供できるビジネス感覚を磨く必要があります。
BtoB＝特化型、BtoC＝汎用型
BtoBでは企業特有のオペレーションなどにすべてカスタマイズすることで使いやすいシステムが出来上がります。いわゆるフルオーダーメイドのシステムです。その分、誰でも使えるというわけではありません。
BtoCの場合は真反対のアプローチが必要で、誰でも使いやすい、汎用性の高さが求められます。もちろん、ターゲットユーザーが狭ければある程度特化することはできますが、それでも幅広いユーザーが使える、使いやすいプロダクトを作る必要があるのです。
技術面ではBtoBよりも進歩的
BtoBのシステム開発ではある程度枯れた（長く使われて安定している）技術の方が重宝される傾向があります。企業が運用する技術は何よりも安定して動作することが求められるためです。もちろん、新しい技術も導入されますが、そこまで思い切ったチャレンジは多くありません。
対して、WebサービスやスマホアプリなどのBtoCのサービスは、より快適なUX（ユーザーエクスペリエンス）を提供することが求められます。そのため、新しい技術は貪欲に取り入れていく傾向が強いです。また、BtoCの技術者のほうが新しいもの好きが多く、どんどん新技術を試していく人が多い印象があります。
アプリケーション開発についてその特徴やメリット・デメリットを私の経験を交えながら解説してきました。
アジャイルは最近の開発手法のメインストリームでもあります。刺激的で勉強になる開発手法なので、興味がある人はアジャイル開発を行っている企業やスタートアップなどに応募してみてください。
コメント