![見出し画像](https://assets.st-note.com/production/uploads/images/142101004/rectangle_large_type_2_8665c1af4ac5b1b4fbeedc3f16ab7fb5.jpeg?width=1200)
5月24日 標準化がなぜシステム開発に必要か
5月24日ですね。
前から標準化、標準化と言い続けています。
なぜ標準化が必要なのか。
それはコーディングしたプログラムのバグ発生率など、品質の維持だけではありません。
他にも理由があります。
同じコードを一人の方がずっと見続けるのであれば、標準化は不要です。
ところが、複数の方が同じコードをメンテナンスする場合、書き方が統一されていないと、その読み解きに時間がかかります。
また、保守も含めて長い期間使われるようなコードの場合、世代を超えて保守され続けます。その書き方が統一されていないと、読み解きだけでなく.更新が必要になった際にバグの危険が増します。
私もそうだったので分かりますが、技術者はこうした標準化を嫌います。コードぐらい自分の好きに書かせろ。要はバグが無く動けばいいんでしょ、という技術者はまだ大勢います。
少なくともkintoneのようなローコードツールの場合、コードを書く量は少なく、代替するツールでシステムが動かせてしまいます。
だから一人で賄えてしまいます。行数も少ないのでなんとかメンテできます。
ところが、そうでないフルスクラッチのコードの場合、その行数は跳ね上がります。
さらに、一つのコードをさまざまな方がメンテナンスしますから、その読み解きの工数も必要となります。
関数や変数の名前の付け方だけでも、その場の勢いでつけてしまい、後々のメンテナンスを考えていないコードはよく見かけます。
最初にそのコードを書いた瞬間は、誰でもそのコードに対しては唯一無二の最高の権威です。単体テストをして品質もバッチリでしょう。コーディング仕立てほやほやですから、内容も完全に理解しています。
ただ、そのコードを一年後に自分がもう一回見直した時、そのコードの意味がすぐわかるか。ましてやそのコードを他人が見ることを考えたときに、変数や関数の意味がすぐ伝わるか。
結局、標準化とはそういうことです。
以前の私は自分一人でずっとやるつもりでいたので、自分だけがわかれば良い、と自分なりの標準化を決めるだけで済ませていました。
ところが、今は複数のメンバーで同じコードをメンテナンスすることが増えています。そして、自分だけがわかるオレオレコードではダメだと言うことに気づいています。
そもそも、kintoneのようなローコードツールの場合、JavaScriptの存在そのものが標準化の妨げになるため、一切利用禁止というポリシーを掲げる会社もあるほどです。
弊社の場合、お客様の環境によってさまざまであるため、JavaScriptを使わざるを得ない会社も多いです。JavaScriptを使うしかないのなら、標準化を考えないと。
例えば最以前からESLintのようなチェックツールも盛んに用いられています。
また、kintone更新の際にコードが動かなくなるリスクを管理するためのツールもあります。
こうしたツールを導入し、標準化に沿ったコーディングを行うようにして、人によって能率が著しく落ちないようにすることが必要です。
私の感覚では、数年にわたって複数人で同じプロジェクトに携わる場合、標準化のための手間をかけてもなお、品質に十分なコストが見込めます。
私も、最近kintoneの伴走開発をする中で、必ずお客様には標準化の大切さを伝えています。
例えばフィールド名を入れたら、必ずフィールドコードにも同じ文字列を入れてもらっています。
福島の事故資料や書籍を数多く読んで見ていると、標準化の必要性が理解できます。
ありがとうございます。 弊社としても皆様のお役に立てるよう、今後も活動を行っていこうと思います。