より安くなる提案として、非本質的なソフトウェア更新を最小にしたい

「記事のカテゴリーを減らす」という些細な更新をするために、前職では、3万円の見積もりを出したことがあります。

営業さんが巧みだったこともあって、「技術費」としてクライエントさまは納得してくださったことがあります。

変更容易性が低いつくりだと変更や更新にお金がかかる

この「3万円」が高いとか安いとかの話をしたいのではなく、当時の私の人件費と工賃を考えると、会社の利益を平均的に含めれば3万円でした。

なぜなら、時間がかかるからです。

もっと言えば、そのウェブサイト（ウェブシステム）は、どこか直そうと思うと時間がかかるような複雑で難解な〈つくり〉になっていたからです。

3万円の工賃を1000円ぐらいにプライスダウンしたい

弊社では、この「30,000円」が「0円〜1,080円」になるような〈つくり〉にこだわっています。

大前提として、ホームページにとって「更新」という行為は非常に重要です。

事業の時流や、市場のセンチメンタルや、顧客の変容に合わせて、あらゆる情報発信はリアルタイムで変形していきます。その変化のアウトプットが「更新行為」です。

その更新を受け取った顧客や市場は、頭のなかを書き換えます。もちろん自社にとって有利になるために、自社の理念を実現するために。

その更新にかかる費用のなかで、重要なのは「発信に最適化された文章作成」や「顧客にとってわかりやすい図解デザイン・資料づくり」などであって、ソフトウェア（ホームページ）を更新するための費用ではありません。

そういった非本質的なソフトウェアの更新が最小になれば、そこにかかる工賃・人件費も最小になります。

弊社では「0分〜15分」に収まるように努力していきます。

本質的に価値のある更新にはお金をかける

一方で、ソフトウェアこそが価値を持つ更新もあります。いちばんわかりやすいのは「機能開発」です。

「メールを一斉送信する機能」とか、

「mp3をmp4にする機能」とか、

「画像から文字を読み取って抽出する機能」とか、

「WordPressのバージョンを検知する機能」とか、

「全SNSに投稿する機能」とか。

〈機能〉は、長年の問題を一瞬で永遠に解決することもあります。その機能を開発する前と後とでは、世界が正反対に裏返る魔法と言えます。

それに加えて、機能自体は、AIの台頭で非常にスピーディーに開発できるようになりました。機能の大部分は、すでに誰かがつくったことのある「車輪の再発明」の性質を持つため、似たようなニーズは既にカバーされている世界だと言えます。

残りの、カバーしづらい〈そのビジネスに固着の関係の在りかた〉のことを「ビジネスロジック」と言ったりしますが、このビジネスロジックを適切にとらえて的確にソフトウェアのかたちにするところが技術者の腕の見せ所だと言えます。

「割引」機能ひとつでも変更しやすいようにつくるのは大変

たとえば、オンラインショップをつくるときに「割引」の種類や種別が複数あるとします。

その割引は併用できたり、

優先順位があったり、

購入価格と連動していたり、

購入価格を超えた場合にお釣りがあったりなかったり、

利用者の年齢と関係があったり、

割引利用履歴によって制限があったり……

たくさんのルールが生まれていきます。

最初にあったルールもあれば、あとから追加されるルールもあります。冒頭で「事業の時流や、市場のセンチメンタルや、顧客の変容」と言ったとおり、いろいろな事情で割引ルールも増減・変化します。

割引のビジネスロジックをつくるときに、最初に考えに考えて（ときに時間をたくさんつかって、レベルの高いITエンジニアに担当してもらって）、後からルールを追加しやすいように、あるいはルールを削除しやすいように設計できていれば、割引ルールの更新は常に最小のコストで行えるようになります。

しかし、ビジネスロジックをまともにつくり込めなかった場合、冒頭の「3万円の見積もり」が発生しやすくなります。これは詐欺とか悪徳とかそういう話ではなく、ソフトウェアがスパゲッティのように絡みあって、どこが、どこと、どのようにつながっているのかわからないので、壊しながら開発しないと何ひとつ変更できない状態のため、時間がかかって、その分の工賃がかかって、最終的に3万円を請求しないと割に合わなくなるというだけのことです。

天才（画伯）がつくった最強で最凶なスパゲティ

余談ですが、私がメンテナンスを任せてもらっている中規模システムがあって、それは過去に天才みたいなひとがすごい速度でカジュアルに土台をつくったもので、それ自体は間違いなく皮肉なしの偉業なのですが、いかんせん天才以外には俯瞰しづらく、いまとなっては長年メンテナンスを担当してきた私しか全体を把握できていない属人的な状況です。

つまり、私以外のひとがやると工数がかかりすぎるけれど、かといって私がつくったわけではないので理路整然とした資料をつくってあげることもできずに、スパゲッティの雁字搦めに遭っているプロジェクトもあります。

「いま動いているもの」のことがわからないとつくりなおせない

こうした場合、「つくりなおせばよくない？」と思いますが、すでに動いているソフトウェアをつくりなおすというのは、「すでに動いている」についてすべて言語化して、それに対応するあたらしいソフトウェアを完璧に設計するところから始まります。

スパゲッティの雁字搦めにおいて、いちばん肝心な、その〈動いているもの〉というものがよくわかっていないので、物理的に「対応するソフトウェア」が書けないという葛藤があります。

この葛藤を乗り越えるためには、強いチームと強い予算が必要です。

ソフトウェアをずっと安価な魔法のままに

ソフトウェアは、魔法にも、魔窟にもなります。

更新が最小になるようにこだわることが、魔法を魔法のまま生かすベストな方法だと私は信じています。

そのこだわりが、低コストにつながったり、魔窟回避につながったり、お客さまのベネフィットに直結するという信念で、今日も技術と向き合っています。