ソフトウェアは生き物なり
ソフトウェアとは、小さく作って大きく育ててゆく「生き物」であり、放置しておくと腐っていく「生もの」であります。
これは、古典的な「モノづくり」と言われるような製造業や建設業とは根本的に事なる異質な概念と言えます。ハードウェアに対して、ソフトウェアと言われるゆえんかもしれません。（今では、ソフトウェア・アプリケーション＝アプリ、ですが）
日本では、この点が長らく理解されてこなかったがゆえに、建設業になぞらえた「ITゼネコン」とその多重下請け構造といった悪習がはびこり、企業や官公庁などが、ITゼネコンに外注（丸投げ）し、モノが「納品」されたらおしまい、という悪癖が常態化してきました。
ITゼネコンにまつわる諸問題については「DXは脱『ITゼネコン』から始めよう」で書きましたので、ここでは割愛しますが、そもそも、ソフトウェアには「完成」などという概念は存在しないにも関わらず、ITゼネコンの人達が「納品」とか言っている時点で「分かってない」と言えます。
それに、「設計」という言葉も実は微妙です。一般の新聞などでは、ソースコードの事を「設計図」などと言っていた（今でも？）悲しくなるような時代もありましたが、混乱するだけです。ソフトウェアの世界では、「設計図」の後の「製造」や「建設」が存在しないからです。ソースコードという「設計図」そのものがソフトウェアです（ビルドというボタン一つの作業でソースコードが実行形式に化ける。スクリプト系では実質それすら不要）。
ソフトウェア開発においてはすべてが「設計」そのものなのです。プログラミング自体が「設計」とも言えますし、同時に「製造工程」でもあるのです。なので、開発における専門用語では「ソフトウェアの設計」というよりかは、より限定して「アーキテクチャー（の設計・デザインを採用する）」や「データベースのデータモデルを設計」、「UIのデザイン・設計」などと個別具体的なことを指していったりします。プログラマはこうした設計を普通に行っていますが、「設計者」などとは言いません。
英語的なニュアンスでは、わざわざ「設計者」つまり「アーキテクト」という場合、プログラミングなんぞ既に極めていて、1つのシステムを超えた、新しい概念（モデルやアーキテクチャー）や自らプログラミング言語自体を設計してしまうような「達人、偉人」を思い浮かべます。新しい世界観を作ってしまうアーキテクト、という感じ。
有名なアーキテクトの肩書きを持つ人の例だと、アンダース・ヘルスバーグとかです。Delphiという有名な開発言語環境を作った後にマイクロソフトに移ってC#という言語一式も作っちゃった御仁です。（今はTypeScriptを作ってるらしい）
日本のITゼネコン的な「仕様」を書く人や「設計」をする人は、そもそもプログラミングの知識や経験すらおぼつかないとか・・・比較するのもおこがましい・・・と感じます。もちろん、ドキュメントとして文書化するのは大事です。でも、ドキュメント化するのと設計はまるで違います。
IT業界では、しばらく前から「サービスとしてのソフトウェア」という概念が普及しました。しかし、日本では相変わらずITゼネコンを中心とした非効率的な搾取構造を維持する為に「要件定義」、「設計」、（下請け孫請け以下で開発、テスト）、「納品」、という形が残っています。この開発手法はウォーターフォール型とも言われ、上流から下流に流れるという概念です。
これに対して、アジャイル型、という開発手法が存在します。オンラインソフトを含め、世の中に存在する無数のソフトウェアの大多数は、意図してかは別として、自然とこのアジャイル型かそれに近いスタイルで開発されていることでしょう。そっちの方が良いソフトウェアが出来るからです。
それはなぜか。
まず第一に、開発者が新しいソフトウェアを開発しようとする際、システムの全ての必須要件と機能なんて誰も初めから全部分かりっこない、という大前提があります。（一部の天才を除いて）
既存のアプリやサービスを真似して作るなら大体想定はできるかもしれませんが、しょせんモノマネは単なる下手な二番煎じで終わります。なぜなら、そこにはオリジナルのソフトウェア出生にまつわる試行錯誤の歴史が存在せず、背景に背骨となる哲学や信念、ストーリーというものが存在しないからです。
既存のものが素晴らしければ、単にそれを活用するのが当然というものです。他人の為であれば、あえて請けずに既存のを利用することを提案すべきであって、自社の儲けの為に二番煎じを作ってお終い、というのは下衆の行いです。下手な二番煎じのモノマネを作るだけで終わらないためには、自ら開拓していかなければなりません。
ソフトウェアを作るには、それなりのモティベーションが必要であり、「プロダクト」として完成させるにはそれなりのコミットメントが要求されます。日本語で言うと、一言で「作る理由」ですね。ちゃんとした理由がなければプロダクトとして世に出る事もないし、メンテも続きません。
必要となるのはそういった事柄であって、これから独自の新しいソフトウェア、未知の新しいモノを作ろうという時に、そのサービスや業務の構成要素と機能（つまりビジネスドメインのビジネスロジック）を隅々まで初めから理解していたり、全て予見できる開発者なんていません。当然「設計」なんてできなくて当然です。
業務システムの場合、業務担当者に聞き取りをして要件定義と設計だ、なんて言っていますが、しょせんITに疎い素人で業務の全体像も見えていない業務担当者が、業務内容に疎いITゼネコンの担当者つまりはその業務分野のド素人に教える、とかいうどちらにとっても悪夢のような話しになるわけです。
私のように一時別の業界で実際に働いていた経験のあるような開発者はまれです。
ITゼネコンの場合、その担当は大抵プログラミングが出来ない開発経験すらない人（SE）が担当したりします。そして、それをさらに下請けに流して孫請け、曾孫請けに・・・と伝言ゲームが続きます。本来はプログラミングの知識と経験が豊富に無いと「設計」を云々するのも無理なことです。
こんな手法では、ろくなシステムは出来上がりません。発注側は単に、良く分からないから作ってもらった、という感覚でしょうが。
ソフトウェア開発では、まず間違いなく、作ってみなければ分からない、という事があるのです。この実際に作ってみて人に使ってもらって初めて見えてくるもの、というのは貴重な知見となります。
第二として、ソフトウェアの開発では、小さく作って（スモールスタート）、大きく育てる、という考えがあります。というのも、初めから全ての機能を全て揃えた「完成形」のソフトウェアを「設計」して、いざ開発してリリースしようとすると、とてもじゃありませんが、形になるまで最低でも何年もかかってしまい、モチベーションも（人的・金銭的・時間的）リソースも足りなくなるでしょう。途中で挫折するのが見えています。
例え「設計」通り出来上がっても、「完成形」の要件イメージ自体が間違っていた、なんてことが判明したり、既に需要も変化していたりして時代遅れになっており、実際には使い物にならず、結局また一から作り直し、なんて事になるのがオチです。この手の失敗例は日本の大規模開発でも有名な失敗例は幾つもあります。
ソフトウェアの世界では、一度リリースしたら変更できないいわゆる製造業の製品サイクルとは大きな違いがあり、ソフトウェアやサービスはベータの段階などで早めにリリースして、フィードバックを得て改良し、アップデートしていく（いわゆるアジャイル）ことが可能ですし、望ましいことなのです。
このような特徴があるため、ソフトウェアというものは、一度とりあえず作ってみて、出来たものを実際に動かしながらどんな機能が必要なのか（または不要なのか）を見極めていく、という走りながら行く先を決めるような所があります。
また、実際に使ってもらって、どんな評判なのかを観察し、ユーザーの方々の反応を見る、という事は大いに参考になることです。必須、と言っても良いかもしれません。ユーザーさんたちと直にやりとりする、直に声を聞く（厳しい洗礼を受ける）ことも重要です。下請け孫請けに丸投げしていたら、このような事は出来ませんし、やっても契約外で利益にもならないからやらないでしょう。
このようにして、とりあえず最小の機能でとりあえず形になったものを公開する、というのは良くあることです。ひと昔「Minimum viable product」という考え方が話題になりましたが、それです。
これは別に不具合だらけの未完成のものをリリースする、という話しではなく、一通りUI設計も含めてカチっとプロダクトとして完結したものでなくてはなりません。ここは重要なポイントです。minimum でも、viable でなくてはならないのです。
この段階で実際に使ってみて、公開してみて、ユーザーの反応も見るのです。もし、誰もピンとこなくて実用性も感じられなければ、そのソフトウェアはそれまでです。一言でいうと必要とされていなかった、という事。単発屋で消えていく運命です。無駄な時間と労力を使わないで済んだと考えましょう。
このように消えていく場合もあるので、この初回リリースまでの時点でソフトウェアの内部設計や将来的な具体的な計画立案に力をいれすぎるのもリスクがあり、コストに見合いません。この段階ではとくかくアイデアとスピード重視です。
もし作ったものがそれなりに使われて、必要とされた場合、当然ながらもっと改善したい、という欲求が生まれます。自分が使う上でアレやコレや使いやすく改良したり機能を追加し、ユーザーからの要望を（取捨選択した上で）取り入れていきます。その結果、当初の想定とはまったく異なった用途のソフトウェアに進化していった、なんてことも「あるある」です。
そのようにしてソフトウェアがある程度「育って」くると、ある時、フルスクラッチで作り直し（再設計）をしたくなる頃合いがあります。
これは、ソフトウェアのアップデートを重ねる度に、とりあえず追加、追加、でソースコードの内容も複雑化していき、付け焼き刃的な対応も増えてきてメンテナンスが難しくなってくるからです。当初想定していなかった機能が増え、リファクタリングとかではすまない、設計上の問題でソースコードの見通しが悪くなってくるのです。
ソフトウェアの内部的な設計というかアーキテクチャーは、付け焼き刃的な対応では変更できません。フルスクラッチで作り直さないとなりません。初めから分かっていればちゃんと設計しますが、前述したように、分からないのが当然なので、仕方がありません。だからこそ、初めに「完成形」の設計などそもそもしていないのです。
丁度この頃になって初めて開発者もこのソフトウェアに必要な機能とあるべき構成（コアのドメインとドメインロジック）の全体像がやっと見えてくる頃合いかもしれません。
これで、第１回目の作り直しが発生します。と言っても、内部的な設計をやり直して、実際の流れ（コアドメイン）に合わせてスッキリさせるのが目的なので、重要部分のソースコードはコピペでそのまま再利用できます。問題なく動いている処理をわざわざ書き直す必要なんてありませんし、バグを産む原因になってしまいます。
全体像が見えてからアーキテクチャーの再設計をする事により、将来的な機能追加やアップデートがしやすくなるのです。また、将来に備えて内部の技術をきちんと体系化して再利用可能にもしていく、という感じです。作り直しをするということは、つまり、作っているアプリに将来性がある、とその価値が認められたことにもなります。
つまり、まともなソフトウェアは１度作っただけでは不十分で、大抵もう何回かはフルスクラッチで作り直し（再設計）が必要だ、という話しです。これは決して初めの設計が悪かったとかいう話しではありません。説明してきたように、そういうものなのであって、その方がより良いものが生まれるのです。
自分の場合、ソフトウェアはショボアプリも含めるとそこそこの数を作って公開してきましたが、振り返って考えてみると、今でも使っていて、満足できる仕上がりになったと思えるソフトウェアは、大抵２回はフルスクラッチで作り直し（再設計）をしていました。場合によっては、元となるソフトウェアから派生させて、新たな別のソフトウェアを作ることもあります。個人的な経験ですが、ありがちなのではと思います。
一般論としても、一度あるソフトウェアを作った開発者が、リベンジで同じものを作り直す場合、最強のソフトウェアが出来たりします。実際に欧米のソフトウェアでよく見かけます。＊＊という有名なソフトウェアを作った開発者が、また別のプロジェクトを開始して、まったく同じ種類のソフトウェアを作っている、みたいな話し。日本でもありますね。もうその人のこだわりの表現というか執念というかライフワークみたいになっている。
別のプロジェクトで新たに始める理由は色々で、既存のが既に広く利用されているので、作り直すと影響がデカすぎるから、とか、まったく別のプログラミング言語を選択することになった、などがあります。
Web系のサービスでも、例えばTwitterやFacebookは使用言語すら変えて、何度も根本から作り直していますね。
しかし、これでまだ終わりではありません。
ソフトウェアの内部の設計（アーキテクチャー）がスッキリしても、画面（GUI）のデザイン（UI/UX）も、初回リリースの頃からの「つぎはぎ」を引きずっていて、内部設計と似たような問題を抱えているからです。
画面（GUI）のデザイン（UI/UX）とわざわざカッコに入れているのは、デザインと言っても、絵面的なデザインではなく、「使い勝手」を含めた総合的な画面設計を言うからです。
もともと、UIというのは機能が一通り揃って仕様が固まってからでないと画面設計（流れ、フローを含む）が難しいのです。機能が１つか２の頃の画面設計と、１０の機能とオプションが沢山ついた時の画面設計・デザインは根本的に異なります。UIデザインはどうしても面倒で一つの正解は無いなので、UIの作りこみはどうしても後回しになりがちです。
しかし、ユーザーがイタンタラクトするのがUIですから、ユーザビリティにも直結する、もっとも重要な部分とも言えます。UIの改善を怠った、またはユーザーを意識していないUI設計だと、せっかくのアプリも使いモノにならない、と判断されても仕方がないのです。
理系の開発者が多い中、日本ではまだまだそういうUI/UXの面を手抜きしているソフトウェアも多いのが残念な所ですが、そこまでやって初めて形になったと言えるのではないでしょうか。
また、UIを見直す際、不要だと思った機能もバッサリ切り捨てる良い機会にもなります。「完璧とは、付け加えるべきものがなくなった時ではなく、取り去るべきものがなくなった時のこと」、なんて誰かが言っていましたね。KISS（Keep It Simple Stupid!）原則なんて言ったりします。
取捨選択は難しいことですが、超重要なことだったりします。Appleの創業者スティーブ・ジョブズのように、自分を信じて「独裁者」のように開発者の独断で大ナタを振るう必要があります。独断といっても様々な観点から考えてユーザーの反応も踏まえて総合的に決断する、ということです。みんながあーだこーだ言うのに全部対応していたら、とてもちぐはぐで中途半端なものになるだけです。そこは心を強く持って、ブレないことが大事です。
この辺りで、ひと段落（一つのマイルストーンに到達）とも言えるかもしれません。年齢で言えば二十歳か。バージョンで言えば、1か2。
この段階でも決して「完成」ではないのです。また、単なるメンテや、建物や設備といったハードウェアの「保守運用」の段階（フェーズ）とも違います。基本的には、「アクティブな開発フェーズ」が続くのです。ひと時のようにガリガリ書くことはなくなっても、エクササイズのようにこまめに続けることが重要です。
他の新たなソフトウェアの開発に手を出しても構いませんが、定期的に戻ってきて新鮮な目で見直します。きっと足りなかった機能が見つかることでしょう。他のソフトウェアでの新たな「学び」を取り入れることも多いです。
場合によっては、ある時から「メンテナンスフェーズ」に入る事もあります。ソフトウェアの開発で、「メンテナンスフェーズに入った」とは、大抵、「もう（セキュリティや重要な不具合修正以外は）特に新しく何かをやるつもりはありませんので」、というニュアンスがあります。
メンテナンスフェーズに入る理由としては、ユーザー数は一定数いても、開発者自身が興味を失ってしまったり、状況が変わってもう時間を割けなくなったようなケースです。その場合、基本的にはソフトウェアの生涯としての先が見えていることになります。開発終了予告に近い延命措置です。有名ソフトウェアだとユーザーも多く、どこからともなく開発を引き継ぐ人が現れたりして復活する事もあります。
では、まったく何もしないで放置しておくとどうなるかというと、冒頭で触れたように、ソフトウェアは「生もの」なので腐っていくという性質があります。
実際、私の場合、転職したりして何も対応することが出来なくなり、放置して腐らせてしまったソフトウェアがいくつもあります。悲しい事です。
放置しておくと、具体的に何が起きるかというと、
１）周りがどんどん進んで活気もあるのに、追い抜かれて徐々に廃れて、忘れ去られていく。
ユーザーからの要望や不具合への対応を怠っていると、そのうち見捨てられます。ユーザーはその辺り、非常に敏感です。そして、いつの間にか他の似たようなソフトウェアが登場してきて、それに追い抜かれる運命となります。需要も微妙に変化していきますから、対応が必要です。
２）プラットフォーム側の変化により、急に動かなくなったり不具合が生じる。（見た目含む）
プラットフォームとは、そのソフトウェアが動作する環境を指します。例えばWindowsなどです。
Windowsが98の頃に作った自分のソフトウェアは、何とか動きますが、見た目がみすぼらしくなってしまい、恥ずかしくて使えません。また、Windows Vistaでは大きな変更があり、多くのソフトウェアが対応を迫られました。その他にも、Windows 8でのメトロなどWindowsの見た目の変更や、日々のアップデートでも影響が出る場合があります。Windows 11も出ますしね。常々、対応しておかないとなりません。
スマホとかモバイルのアプリの場合はプラットフォームの更新サイクルがもっとずっと早く、中々大変です。Webアプリでもブラウザーの更新があります。
また、これは特にWeb系のソフトウェア（サービス）での話しになりますが、セキュリティ上のアップデートは日々の情報収集を含めて、常日頃から対応していなければなりません。
ソフトウェアとは、常々ちゃんと水をやったり餌をやったりと、こまごまと世話をしてやらないといけない生き物のようなものなのです。
もし気に入ったソフトウェアを見つけたら、アップデートを楽しみにしながら、一緒に水をやって育ててやるような気持ちで付き合ってやってください。もしそういう気持ちを持てなかったら、さっさと別のに乗り換えるべきです（笑）
もし職場でITゼネコン製のろくでもないソフトウェア業務システムの使用を強制されているのであれば、それは盛大に文句を言って構わないと思います（ｗ）
以上。
この記事が気に入ったらサポートをしてみませんか？