torum

主に開発中のアプリにまつわる技術系の事。

アプリは2度作り直して初めて使い物になる

まともなアプリケーションは1度作っただけでは不十分で、大抵もう2回はフルスクラッチで作り直し(再設計)が必要だ、という話しです。3度目の正直とも言います。

対象

対象となるのは、GUIのあるアプリケーションを一般向けに人様に使ってもらう為に開発する際の話しです。GUI(イベントドリブンの処理があるUI)が絡むと途端に複雑さが増すため、非GUIのライブラリとか単一機能のツールとは事情が異なります。単にリクエスト<->リスポンスしかないWebアプリも対象外です。

自分の場合、アプリはショボアプリ含めるとそこそこの数を作ってきましたが、振り返って考えてみると、今でも使っていて、満足できる仕上がりになったと思えるアプリは、大抵2回はフルスクラッチで作り直し(再設計)をしていました。個人的な経験ですが、ありがちなのではと思います。

前提

なぜなのか、というと、まず前提として、開発者が新しいアプリを作成しようとする際、システムの全ての必須要件と機能なんて初めから全部分かりっこないという事です。(出来合いのアプリやサービスを真似して作るなら大体想定できるけれど、しょせんモノマネは単なるモノマネで終わる)

これから新しいモノを作ろうという時に、特定のサービスや業務の構成要素と機能(つまりビジネスドメインビジネスロジック)を隅々まで初めから予見したり、全て理解している開発者なんていません。(業務システムの場合、SEが業務担当者に聞き取りをして要件定義だ、なんて言っていますが、しょせんITに疎い素人で全体像も見えていない担当者が業務内容に疎いSEつまりはその業務分野のド素人に教えるとかいう悪夢>補足エントリ「要件定義という時代遅れの慣習」)(私のように一時別の某業界で実際に働いていた経験のあるような人間は特殊)

アプリ開発では、まず間違いなく、作ってみなければ分からない、という事があるのです。この実際に作ってみて初めて見えてくるもの、というのは貴重な知見となります。

次に、アプリというかソフトウェアの開発では、小さく作って(スモールスタート)、大きく育てる、という原則があります。というのも、初めから全ての機能を全て揃えた「完成形」のソフトウェアを開発してリリースしようとすると、とてもじゃありませんが、形になるまで最低でも何年もかかってしまい、モチベーションもリソースも足りなくなるでしょう。途中で挫折するのが見えています。

例え出来上がっても、「完成形」の要件イメージ自体が間違っており、実際には使い物にならず、結局また一から作り直し、なんて事になるのがオチです。この手の失敗例は日本の大規模開発でも有名な失敗例は幾つもあります。そもそもハードウェアの製造業とは違い、ソフトウェアに「完成形」など存在しない、という考え方もあるのです。

ITの世界では、ソフトウェアやサービスはベータの段階などで早めにリリースして、フィードバックを得て改良、アップデートしていく(いわゆるアジャイル開発)のが正攻法であって、一度リリースしたら変更できないいわゆる製造業の製品サイクルとは大きな違いがあるのです。比較すると、ソフトウェアは「生き物」だ、という言い方も出来ます。

初回のリリース

このような前提があるため、ソフトウェアというものは、一度とりあえず作ってみて、出来たものを実際に動かしながらどんな機能が必要なのか(または不要なのか)を見極めていく、という走りながら行く先を決めるような所があります。実際に使ってもらってユーザーの方々からの反応も大いに参考になります。

なので、とりあえず最小の機能でとりあえず形になったものを公開する、というのは良くあることです。これは、別に不具合だらけの未完成のものをリリースする、という話しではなく、UI設計も含めて一通りカチっと完結したものでなくてはなりません。

これが、初回のリリースとなります。この段階で実際に使ってみて、公開してみて、ユーザーの反応も見るのです。もし、使ってみて、ピンとこなくて実用性も感じられなければ、そのアプリはそれまでです。一言でいうと必要とされていなかった、という事。単発屋で消えていく運命です。

ですから、この初回リリースまでの時点でアプリの内部設計や将来的な計画に力をいれすぎるのもリスクがあり、コストに見合いません。この段階ではとくかくアイデアとスピード重視です。

もし作ったものがそれなりに使われて、必要とされた場合、当然ながらもっと改善したい、という欲求が生まれます。自分が使う上でアレやコレや使いやすく改良したり機能を追加し、ユーザーからの要望を(取捨選択した上で)取り入れていきます。その結果、当初の想定とはまったく異なった用途のアプリに進化していった、なんてこともあるあるです。

第1回目

そうこうしているうちに、アプリのアップデートを重ねる度にとりあえず追加、追加、でソースコードの内容も複雑化していき、付け焼き刃的な対応も増えてきてメンテナンスが難しくなってきます。当初想定していなかった機能が増え、リファクタリングとかではすまない、設計上の問題でソースコードの見通しが悪くなってくるのです。

この頃になって初めて、開発者もアプリのあるべき構成と機能(コアのドメインドメインロジック)の全体像が見えてくる、と言えるでしょう。

ソフトウェアの内部的な設計というかアーキテクチャーは、付け焼き刃的な対応では変更できません。フルスクラッチで作り直さないとなりません。初めから分かっていればちゃんと設計しますが、前述したように、分からないのが当然なので、仕方がありません。

これで、第1回目の作り直しが発生します。と言っても、内部的な設計をやり直してコアドメインに合わせてスッキリさせるのが目的なので、重要部分のソースコードはコピペでそのまま再利用できます。問題なく動いている処理をわざわざ書き直す必要なんてありませんしバグを産む原因になってしまいます。

全体像が見えてからアーキテクチャーの再設計をする事により、将来的な機能追加やアップデートがしやすくなるのです。また、将来に備えて内部の技術をきちんと体系化して再利用可能にもしていく、という感じです。つまり、作っているアプリに将来性がある、とその価値が認められたことにもなります。

 

なぜフルスクラッチで書き直すことにしたのか

例えばアーキテクチャの文脈で言えば、素朴なMVCで作られていました。とにかくリリースを早めて検証するタイミングでは最悪の選択肢ではないと思いますし後悔はしていないのですが、年を経て同じ画面内での機能追加・仕様変更が重なるようになってくると、開発スピードの維持が難しくなってきました。データバインディングなどの仕組みもなく、処理を素直?な手続き的に書いていたのもあり、画面の状態数とそれに応じた条件分岐が増えていくほどメンテナンスの難易度も上がってしまっていました。

先述したリニューアルは、デザインの一新や仕様の見直しなどを行う、ある種0からプロダクトを見直す機会でした。既存のコードベースをリファクタしながら少しずつ変更を入れていくアプローチは、こういった状況で難易度の高いテーマです。APIも含めシステムとしての変更が生じることは分かっていたので、結局それなりの割合のコードを書き直す未来は見えていました。

https://atraetech.hatenablog.com/entry/2021/03/22/140624

 

分かるわ~。このケースではMVCからMVVMへのアーキテクチャー変更の話しをしていますが、初めからMVVMパターンで作っていた場合でも、異なるレイヤーの話しですがイベントドリブン寄りからドメインドリブン(ドメインに合わせたモデル)に寄せて再設計したくなるのです。外部のライブラリやAPIやDBとの連携が増えたので、全面的に非同期のマルチスレッドで設計し直し、なんてこともありました。

体力というか大人数で開発出来るリソースがある所は、既存のアプリをメンテナンスしつつ、並行して内部的な再設計とUIのリニューアルを同時にやっちゃうケースもあるかもしれませんが、個人レベルでチマチマ作っている開発体制だと3つを同時並行的に一気にやるのはまず無理です。それに、大きな機能追加などを行う前に、まず先にアーキテクチャーの再設計をして基盤整備をしておきたい所です。

第2回目

という事で最後に、第2回目の作り直しになります。これは大抵、GUIの操作性を含めた全面リニューアルです。第1回目で作り直したのは内部的なソースコードの刷新でしたが、GUIは初回リリースの頃からの継ぎ接ぎを引きずっています。必要となる機能が大体分かって内部の再設計と整理がされ、一通り大きな機能の実装も済んできた頃、改めてGUIも統一感のあるドメインに合わせた使いやすいUIにしたくなるのです。

この際、不要だと思った機能もバッサリ切り捨てる良い機会になります。「完璧とは、付け加えるべきものがなくなった時ではなく、取り去るべきものがなくなった時のこと」、なんて誰かが言っていましたね。KISS(Keep It Simple Stupid!)原則なんて言ったりします。

もともと、UIというのは機能が一通り揃って仕様が固まってからでないと画面設計が難しいのです。機能が1つか2の頃の画面設計と、10の機能とオプションが沢山ついた時の画面設計・デザインは根本的に異なります。UIデザインはどうしても面倒で一つの正解は無いなので、UIの作りこみはどうしても後回しになりがちです。

しかし、ユーザーがイタンタラクトするのがUIですから、ユーザビリティにも直結する、もっとも重要な部分とも言えます。UIの改善を怠った、またはユーザーを意識していないUI設計だと、せっかくのアプリも使いモノにならない、と判断されても仕方がないのです。理系の開発者が多い中、日本ではそういうUI/UXの面を手抜きしているアプリも多いのが残念な所ですが、そこまでやって初めて形になったと言えるのではないでしょうか。

感想

という事で、2度の作り直しを経て、やっと満足のゆく、一人前のソフトウェアになった、と言える段階に達すると思うのです。これは、どうせ後で作り直すのだから、と、始めは後先考えずにとりあえず形になるようガシガシと汚いコードを書きなぐる、という事の言い訳にもなっています。

あくまで、個人的な経験に基づく感想ですが、実際の所、他ではどうなんでしょうかね。まぁ、超がつく定番アプリは大抵、1度や2度では済まない作り直しをしているとは思います。(Web系でも、例えばTwitterFacebookは使用言語すら変えて、何度も根本から作り直していますね)