まとめ

サービスを開発するということは、ビジネスを推進するという責任感を持つということだ
システムがビジネスにどう貢献するかは、最初の設計から始まっているかもしれない
懇親会に参加すると楽しいと言われた。本当に楽しかった

本文

サービス開発をずっとしていると、技術的な負債が沢山溜まってきてつらい。
でもつらくても、それでサービスが利益を生んでいる以上はメンテナンスを欠かすことはできない。

レガシーになったコードを改善しよう。

使わなくなった機能のコードがそのまま残ってデッドロジックになっている。
使い勝手のわからないテーブルがある。
Gendarテーブルに1,0のフラグだけではなく、「男」、「女」と入っているヤバいテーブル。

まさかサービスが長期で運用されるとは思っておらず、テストコードも書かれていないアプリケーション。

でも長い間保守されてきたアプリはそんなもんかもしれない。
それでも前を向く。メンテナンス性を高めないといけない。
そうしないと変更が大変になり、ムダなコストが掛かるから。ビジネスの価値を生み出す直接的な部分、つまり、売上に貢献しない部分で、修正コストがかさんでしまう。

いくらリファクタリングを頑張っても、それ自体が売上に結びつかないこともある。
変化に早く対応できる、といっても、それはソースコードや設計が読める人にとってはメリットが分かりやすいけれど、それ以外の人には余計にコストが掛かるとしか思ってもらえない。

「なぜ、画面に項目を一つ追加するだけでこんなに修正コストが掛かるの？！」と言われても仕方ないことだ。

もしかしたら、最初にビジネス特性を考えて設計できていれば、ビジネス特性に合わせた設計が出来たのかもしれない。というわけで、設計当初のビジネス上の意思決定をドキュメント化しておくことには価値があると思う。

変化に強い、というのはメンテナンスコストが低くて済むということだが、ビジネスサイドとからは、保守にコストが掛かりすぎると言われる。

これは、システムが単なるトールゲートではないということを指している。
変化が当たり前。変化の仕方はビジネスが成長してみないとわからない。
だから最初に設計をしきるのも、１年先の見積もりをするのも、ムリである。
ビジネスの成長に合わせて業務の在り方が変わるのだ。業務体系そのものがあっという間に変わることだって少なくない。

でも、だからこそ、技術による解決を、ビジネスサイドに価値のあるものとして認めて貰わなければならない。

「システムによる自動化」から、「システムでなければ提供できない価値」を作るところへとビジネスが変わっていくなかで、リファクタリング一つ取っても、売上は上げないけれど今後の売り上げを加速するためには絶対に必要なものなので、それを信じて、相手にも信じてもらえるように、コツコツと積み重ねてゆくことを忘れないようにしたい。

懇親会は楽しかった。めっちゃ楽しい。普段話せない人たちと話せるのは楽しい、面白い。
知らないことを知るのは面白い。参加できて良かった。

最後までとても満足できた内容だった。懇親会は楽しいものだ。