要件定義の問題点

負債の本質

技術的負債には、設計負債やコード負債がある。金銭的な負債であれば借入金やマイナスの表記で数字化できるのだが、技術的負債においては数字化できないことがとても難しい点である。経営に関するほとんどのことは定量化や定性化が可能だが、たとえば企業創業者の発想する「野生の勘」を直接的に数字化できないように技術的負債も一筋縄では見える化しない。

設計時の対策

技術的負債の中でもコード負債については、システム開発の現場からよく発想されるリファクタリングや再構築などを行うことで比較的わかりやすい返済方法となる。知らない人が作ったプログラムや古くなったプログラムのバージョンなど、リスクを表現し対応することができる。何よりも最初の企画設計段階で負債が積みあがりにくい仕組みを考えることが大切である。

高負担な設計

技術的負債の中でも利息の高い負債が設計負債である。単体機能における設計であれば、モジュールごとの再設計によって返済が可能である。しかし、プログラムは複数のモジュールが絡まり合っていることがほとんどなので、複雑なオペになってしまう。また、稼働中のシステムにわざわざ再設計したプログラムを導入するリスクに対して、得れるメリットも少ないので見過ごされがちである。設計能力は例えば、紙というオブジェクトのメソッド（振る舞い）とプロパティ（保持する情報）を聞いて正しい答えが帰ってくれば多少安心であろう。紙の振る舞いは燃えるであり保持する情報は面積などがある。

根本的解決

しかし、技術的負債はこのように目に見えやすい設計負債やコード負債が致命的になることは少なく、やはりその上層でどのような指針に基づいてシステム運用がなされてきたか、また長期視点で一貫したメンテナンスを行うことが必要である。システムの維持には保守費用や運用費用を払っていることが多いと思うが、これだけでは将来の負債を減らしていくことはできない。やはり、鳥の目を持つITコンサルタントやITアナリストなどの役割を持つメンバーが必要である。

まとめ

ITコンサルタントやアナリストは、すぐに利益も生まない、経費を削減するわけでもないといったコストセンターとしてのポジションなので、あまり起用していない中小企業も多いようである。投資に対する効果が見えにくいのは、料理でいう香辛料と同じなのかもしれない。その少しの投資が未来を大きく変えることになる。IT技術は日進月歩で発展するからである。

提案と負担

「なぜ、自社のシステム担当者や社外から常駐するSEは、システムの改善提案をしてくれないのだろう？」と思うことはないか。それは、提案することで自分が大変になってしまうことを理解しているからである。

現状維持の理

自分たちが大変になるだけであるため、普通に考えれば、それを「やろう」と思うはずがない。それがシステム担当者から提案が出てこない理由であろう。

知と意欲

そうなると、非エンジニアやシステム営業が発想する提案は、システムの要件や縛りを無視した案になってしまう。問題解決意欲の高い非エンジニアが指揮するシステム開発を成功させるには、同じ温度感を持つエンジニアを味方につけるほかない。

人材の見極め

システム担当として向いている人材を探すことは非常に困難である。仮に全社的な問題解決意欲の高いエンジニアを採用したとしても、本当のスキルがどの程度であるか知ることができない。システムの開発のほとんどは巻き戻すことができないからである。

まとめ

システム開発や運用の大変さを知る人材ほど、モチベーションがない限り全力を出し切らせるには、相当の熱量を伝えることが肝要である。

SE常駐の負連鎖

システム開発会社側の立場からすると、時間ばかり取るよくないクライアントはできるだけ減らさないと、他の優良クライアントに迷惑がかかる。特に横にいてくれないと進めることができないというニーズが、SE常駐の常態化してしまっている要因である。

常駐要請の心理

SEへの安心感の欠如が常駐しないといけない理由のひとつである。隣にいれば、何かあった時にすぐに指示が出せる。たとえば、サーバが止まったときにすぐに復旧させることが可能である。

対症療法の克服

隣にSEを常駐させて対応できてしまうがゆえに対処療法になってしまいがちである。本来であれば、サーバが止まらないようにすべきであり、リカバリのプランがしっかりと計画されていることが理想である。

脱属人化の施策

SE側も、すぐに復旧させられるからといった怠慢により、事前に問題や対策を考えておくといった準備を怠ってしまう。そう考えると、発注側のITリテラシーも非常に重要である。属人化しないように仕組化するにはどうするかを常に整理する意識を持つことが大切である。

まとめ

発注側は感情だけでプロジェクトを遂行すると、何かあった時に何でもSEを急かしてしまう。これによって、発注側はオオカミ少年化してしまうため、本当に急がないといけないときに対応が遅れてしまうのである。