システム絡みの節約術

どんなに儲かっていてイケイケの会社でも、予算の無駄遣いを続ければすぐに傾く。右肩下がりの縮小傾向の会社であればなおさらだ。

IT関係の書籍は高度なプログラミング手法など、「どうやったら実装できるか？」という観点で書かれている。しかし、現実のビジネスでは「どうやったらもっと安く作れるか」のほうが大事になる場面が多い。

ここでは、私が実際に体験した「安くシステムを作る手法」について紹介したい。

項目ではなく、値を新設する

新しい機能を追加する時、処理方法を分けるには何らかの値を参照して条件を分岐させないといけない。この時、まったく新しい項目を増やすと、受け渡す項目が増えてシステム間の"繋ぎ目"の部分に手を入れないといけなくなる。

すると、「ちゃんとデータ受け渡せてるよね？」と言う観点でテストをしなくてはいけなくなる。

テストのバリエーションが増えると当然工数がかさむ。少しでも安く作るためにこれは避けたい。

そこで使えるのが、既存の項目に入る値を増やす手法だ。今まで1か2しか値が入ってこなかった項目に、3とか4を増やすことで繋ぎ目に気を遣わなくても機能追加できるようにする。

初っ端で弾く

処理を分岐する上で「こいつは処理対象外だな」とバイパスすることがあるだろう。これをデータ投入した後のプログラムの中でやると、テストが増えるし条件が複雑になる。

だったらいっそのこと入力データの段階で「この条件に当てはまったら入力データから除外する」としてしまったほうがロジックがシンプルになる。

入力データの選別ロジックを見れば、対象外の条件も一目瞭然となるので、保守もしやすくなる。「似たような処理は一箇所に集める」というセオリーにも忠実だ。

他でカバーできているので最低限直す

処理がA→B→Cと三段階に分かれる処理があって、全部で10種類のデータを処理したいとする。

「Aで5種類、Bで3種類処理をしているから、Cでは残り2種類を処理すればよい」という見切りを行なって、最小限の改修で済ませるという方法である。

有識者が退職・異動した後に一番困るのはこのパターンだ。前後の「他でカバーしてくれている機能」が頭に入っていないとキチンと保守・改修することができない。

A,B,Cの三つが組み合わさることで全てがカバーできるので、たとえばAのカバー範囲を1種類増やすとダブりが発生して無駄になる。逆にカバー範囲を1種類減ると他で補わなくてはいけなくなる。

プログラムを見るだけでこれらを特定するのはほぼ不可能なので、ドキュメントでA〜Cの処理をひとまとめに記述しておく必要がある。

有識者の頭の中にだけ入っていて、異動するとなった時に引き継ぎが漏れるのはこういったシステム仕様だ。

あちこちに散らばった処理をゼロからつぶさに読み解いて全体像を描くのは至難の業である。

以上、私の体験した範囲での"安いシステム仕様"について書いてみた。

一度予算がついたら実績工数は厳しく問われない組織だと、同じ機能を安く仕上げることは人事評価に結びつきづらい(経営目線だと非常に大きな貢献なのだが)。

しかし、システム担当者は「自分たちの仕事をやりやすくしてくれた」恩をよく覚えているものだ。

こういったちょっとした創意工夫を、これからも大事にしてゆきたい。