５月２４日　標準化がなぜシステム開発に必要か

５月２４日ですね。

前から標準化、標準化と言い続けています。
なぜ標準化が必要なのか。
それはコーディングしたプログラムのバグ発生率など、品質の維持だけではありません。
他にも理由があります。

同じコードを一人の方がずっと見続けるのであれば、標準化は不要です。

ところが、複数の方が同じコードをメンテナンスする場合、書き方が統一されていないと、その読み解きに時間がかかります。
また、保守も含めて長い期間使われるようなコードの場合、世代を超えて保守され続けます。その書き方が統一されていないと、読み解きだけでなく．更新が必要になった際にバグの危険が増します。

私もそうだったので分かりますが、技術者はこうした標準化を嫌います。コードぐらい自分の好きに書かせろ。要はバグが無く動けばいいんでしょ、という技術者はまだ大勢います。

少なくともkintoneのようなローコードツールの場合、コードを書く量は少なく、代替するツールでシステムが動かせてしまいます。
だから一人で賄えてしまいます。行数も少ないのでなんとかメンテできます。

ところが、そうでないフルスクラッチのコードの場合、その行数は跳ね上がります。

さらに、一つのコードをさまざまな方がメンテナンスしますから、その読み解きの工数も必要となります。
関数や変数の名前の付け方だけでも、その場の勢いでつけてしまい、後々のメンテナンスを考えていないコードはよく見かけます。

最初にそのコードを書いた瞬間は、誰でもそのコードに対しては唯一無二の最高の権威です。単体テストをして品質もバッチリでしょう。コーディング仕立てほやほやですから、内容も完全に理解しています。

ただ、そのコードを一年後に自分がもう一回見直した時、そのコードの意味がすぐわかるか。ましてやそのコードを他人が見ることを考えたときに、変数や関数の意味がすぐ伝わるか。

結局、標準化とはそういうことです。

以前の私は自分一人でずっとやるつもりでいたので、自分だけがわかれば良い、と自分なりの標準化を決めるだけで済ませていました。

ところが、今は複数のメンバーで同じコードをメンテナンスすることが増えています。そして、自分だけがわかるオレオレコードではダメだと言うことに気づいています。

そもそも、kintoneのようなローコードツールの場合、JavaScriptの存在そのものが標準化の妨げになるため、一切利用禁止というポリシーを掲げる会社もあるほどです。

弊社の場合、お客様の環境によってさまざまであるため、JavaScriptを使わざるを得ない会社も多いです。JavaScriptを使うしかないのなら、標準化を考えないと。

例えば最以前からESLintのようなチェックツールも盛んに用いられています。

また、kintone更新の際にコードが動かなくなるリスクを管理するためのツールもあります。

こうしたツールを導入し、標準化に沿ったコーディングを行うようにして、人によって能率が著しく落ちないようにすることが必要です。

私の感覚では、数年にわたって複数人で同じプロジェクトに携わる場合、標準化のための手間をかけてもなお、品質に十分なコストが見込めます。

私も、最近kintoneの伴走開発をする中で、必ずお客様には標準化の大切さを伝えています。
例えばフィールド名を入れたら、必ずフィールドコードにも同じ文字列を入れてもらっています。

福島の事故資料や書籍を数多く読んで見ていると、標準化の必要性が理解できます。