#01-他社作成プログラムのクレンジング案件

まだ20代半ばの頃、独立系SI会社のアプリケーションSEとして仕事をし始めている時の経験です。まだまだ勉強中の身だったので、早く実績を作りたいとも思っていた時期でしたね。一通りプログラミングも身についていたので、お客様から信頼されるSEに1日でも早くなりたいと思っていた頃でした。

当時のお客様は、とてもコスト意識が高く、依頼すべき案件が発生すると常に何社かと比較検討されていました。この時も、我々の会社と他社に見積もり依頼を実施し、コスト比較した結果、小規模の開発案件を他の会社に依頼されました。

もちろん、我々はサービス料金の内訳の説明として、保守段階の重要性を意識して工数をかけた対応を実施する様なことを記述していましたが、やはり提案金額の絶対額が低い方に軍配が上がってしまったのです。このような現象は今でも多く発生しているのではないでしょうか?

 お客様としては、準備できる予算枠の中で発注できれば、余計な社内プロセスを考えなくていいというのも理由の1つとしてあるかもしれません。
さらに、購買部門からすれば、少しでも安いところに発注できたという実績が重要なのかもしれません。いずれにしても、コスト比較で負けた案件だったのです。

我々からすれば、開発して稼働した後にかかってくるコストのことも考えて欲しいと思ってはいるのですが、それは先のことだからその時に検討すればいいという対応も多々ある様です。そんなことは、きちんと作られていれば発生すらしないかもしれないという淡い期待があるのかもしれません。
結果的には、なんらかの問題が発生して多くのコストを必要とすることになるのかもしれませんが、会計年度をまたがることで次年度の予算ということになり、当年度予算へのインパクトが見えなくなるのかもしれません。

当時はメインフレーム・コンピュータが主流でCOBOL全盛期でした。今回の事案も当然COBOLで組み上げるプログラム群ということになります。

もともと、しっかりとした発注仕様がなかったので受注する側が、どの程度気を使って作ることができるかということになります。
システム開発において、発注する際の仕様が完全に出来上がっているということは稀かもしれません。大抵は、その後の打ち合わせやヒアリングで曖昧な箇所を確定してプロジェクト開始となります。

当時この事案を請け負った会社は、お客様にシステムのInputとOutputをしっかりと事前確認し、それを元に開発を終え、正しい結果が出力されることを確認して納品をしました。

当然ですが、納品の際の受け入れテストもお客様は実施され、期待通りの結果が得られていルことを確認されていました。
したがって、検品は合格、料金の支払いも終了ということで丸く収まったわけです。納品の際に、テストした結果に問題がなければ、プログラム・ソースのチェックまでは実施しないことは珍しいことではありません。
しかも、お客様としては、我々の会社に発注するより、安いコストで手に入れることができたため、満足度も高かったのではと思います。

我々としては、小さな案件ではありましたが、お客様から受注できなかったことが、ちょっとだけ残念でした。わかってもらえなかったかなと反省していました。

と、ここまでは、よくある話です。

ところが、納品から数ヶ月経過した時に問題が発覚しました。

その納品されたシステムに改善を加えなければならない事案が発生し、お客様は自らソースコードと対面することになったのです。

その時、お客様は気づいたのです。

小さなシステムなのに何処を修正すればいいか判別できないことに。。。

問題はプログラミングの仕方にありました。

もともとは、10本程度のプログラムになることをお客様は予測していたようなのですが、実際には3本で構築されていました。お客様は簡単な仕様書を10個に分けて記述されていました。当然、結果も10本のプログラムとなって戻っくるだろうと考えられていたのだと思います。
10本が3本に収まったのなら、本数だけ見ればとても効率的なプログラミングが実施されたのかと思えますが、実際には違っていました。

なんと複数人のプログラマーが共同で1本のプログラムに組み立てて作っていたのです。

自分の担当箇所のロジックを正しく稼働させるために、余分な項目保存のロジックがあったり、プログラム内で利用するWork項目の名称もバラバラだったりということで、1本で軽く5000ステップ以上になっており、解読が困難な状態を作り上げていたのです。

当時COBOLの場合は、1本500ステップ程度が適正と言われていました。
多くても1000ステップ以下が標準でした。
当時のプログラミングをするための端末のスクリーンが24行程度しか表示できない時代だったので、大量にスクロールしなければならないプログラムは著しく保守性が悪くなっていたため、1プログラムのステップ数を小さくすることが標準としてガイドされていました。今は、PC上で多くの画面を立ち上げることができるので当時とは全く違った環境にあります。

また、このプログラムを作ったプログラマー達は、それぞれ自分の作成箇所のロジックが誤動作するのを防止するために、一時的に利用するエリアなどを専用で定義し、他のロジックで変更されないように設定していたわけです。ある意味、懸命な判断なのですが、全体で見れば、一時的に利用するエリアの定義が多くなり、プログラムは見づらくなります。

お客様は、最初、発注した会社にクレームをつけたようなのですが、きちんと納品も終わっており、不具合ではないので、対応するとしたら、修正対応ということになり、新規開発よりも料金は高くなりますと言われたそうです。
お客様も再度依頼してもっとひどい状態になって困るのは自分だと考え、修正依頼はされなかったようでした。

こんな状態に陥り、対応に困ったお客様は、仕方なく我々のところに相談にこられました。
発注していない会社なので、ちょっと気まずそうに。

「このシステム、保守できないのでなんとかできませんか。システムの仕様は変更せずに、見やすい形に2週間程度で改善して欲しいのですが。」

というものでしたが、私が回答したのは稼働日ベースで16日程度下さいというものでした。つまり見積的には16人日です。実は、人が作ったプログラムほど対応しずらいものはありません。標準化のルール通りにコーディングしてあれば別ですが、それぞれのSEが最適と考えて作成したシステムほど厄介なものはありません。

お客様希望の2週間だと稼働日ベースで10日間しかありません。
もし無理に受けて期間が伸びれば再度お客様を落胆させてしまうことになります。

依頼された瞬間に考えたことは、現状のプログラム3本の解析と再構成案作成に1週間、再構成作業とドキュメントに1週間、全体の確認テストと納品物整理に1週間、そして万が一の時は、土日が3回でリカバリーということでした。見積もりというより、このくらいの期間で仕上げないと要求とかけ離れてしまうなということも考えました。今考えれば、見積手法としては、失格だと思っています。

ロジックそのものは正しく稼働しているわけですから、プログラム自体を見やすく再構成するということが依頼内容になります。また、月曜日を納期にしておくことで予備の土日を1回多く含められるということも考慮しました。

お客様は思っていた予定より少し遅いけど他に選択肢がないこともあり、仕方なく了承されました。
ちょっと肩を落として帰って行かれたように感じました。

「うーん。なんとかしたいのは山々だけど。。。」

さて、この後が私のスキルと応用力が試されるわけです。
なんとか、納期を前倒しで実現することも考えてみます。

プログラムの動きは変えずに、保守しやすい形に変更しなければなりません。そうです。小さなシステムに対するクレンジング作業が目的でした。

まずは、全体の工期短縮のためには、1本に連結して整理することも検討しましたが、単純なプログラム群にすることが近道であると判断しました。プログラム構造図を書くことでプログラムの数が増加しても1本1本が理解しやすければ、保守性はよくなると考えたのです。

プログラムを細分化し、1本のブログラムは1機能の実装を実現するように単純化して、3本のプログラムを20本程度に分けました。
こうすることで、複数人で作成したプログラムを分断し作業エリアも標準化でき、不要な重複した作業エリアを削除することができました。

そして、20本程度のプログラムを連結してテストし、元のシステムと同じ結果が出る様になるまで確認と微修正を実施。これは、機能自体は変えていないので、出力結果を機械的に比較することで同じ結果になるかどうかの確認を実現できました。
まずは単純化された構成への変更、ここまでで5日間を使いました。

次の週では、あまりにもステップが少ないプログラムの統合などを実施し最終的に14-5本の構成に再構成しました。もちろん、再テストも実施しました。
あまりに小さすぎるプログラムは、保守段階になったら何のための機能を実装しているのかわからなくなるからです。データベース設計で正規化を実施して、最終的には正規化を崩すプロセスと同じあると私は思っています。

再構成すると同時に、保守にとって大切な文書化(プログラム構成図、インターフェース説明、プログラムの機能説明(1枚/本)、新旧対比など)を実施しました。
システム開発では、この文書化が一番工数がかかりますね。しかし、文書化の作業は、自分自身の考えを再整理して見直すことができるので、重要だと思っています。その際、必要なら再度修正も可能になります。

そしていよいよ3週目、再度、プログラム・ソースを見直し、全体のテスト結果を整理し、納品物をまとめました。この週になると、ほとんど残業対応しなくてもまとめることができていました。

お客様に納品できたのは、3週目の週末になる前で、運良く、土日を潰すことも1度もなく終わりました。
日数だけで言えば、13日程度で完成させたことになります。
最も、残業したので実質は15人日程度の工数でした。本来、見積もりには残業は含んでいないので、ギリギリで対応できたなという感じでした。

お客様には納期を稼働日数で16日と伝えていたので、週明けの月曜日に納品されるものと思っていたお客様は予定より早い納品に満面の笑みでした。

「お願いしてよかった。次からは、まず最初に相談に来ます。」
と言ってくださいました。

小さな仕事ではありましたが、大きな達成感を感じた瞬間でした。
お客様から信頼される結果は、最高に嬉しいと感じました。

その後、何かにつけ、お客様は我々のところへ事前に相談に来られるようになり、我々の会社への発注も増加していったと記憶しています。

信頼を得るということはビジネス量も増加させる効果が大きいということを学んだ駆け出しの頃の小さな事案でした。

この時に、自分なりに考えていたことを思い起こして整理すると以下の様なことだったと思います。
当時は、しっかりと計画を書き出していたわけではありませんが、プロジェクト開始前にしっかりと目標を定義することはとても大切ですね。できれば常に文字にする習慣を持ちたいものです。

・プログラミング・スキルの確認のため、他人のプログラムを解読する時間の確認
・改善対応策を複数検討し、全体工期を短縮する施策の実施
・修正や変更すべき箇所を素早く見つけられ構成で保守作業工数の軽減を実現する
・お客様の期待を上回るような対応と自分自身の達成感を味わう

ここで学び取ったことは、自分で達成感を感じる仕事はお客様の満足度も得られるということでした。

さらに、見積もりでの対応の重要性も再認識しました。
適切な見積もりというのが如何に困難かということです。
しかも、見積金額で確定料金としてサービスを提供すると仮定したら、かかったコストを引いた分が利益となるわけなので、問題が発生するとあっという間に赤字転落ということもあり得るわけです。

この時は、16人日と見積もった内容に対して、実質15人日で終了できたので、結果的にはよかったのですが、何か問題が発生していたら、1日程度はすぐに使ってしまいます。余裕の持ち方、お客様への伝え方など色々と考慮しなければいけないなと反省しました。また、見積自体は、プロジェクトとして安全に開始するために重要な要素だなという感覚だけを体感しました。

もちろん、問題が発生していたら、先輩達が黙ってはいなかったでしょう。助け舟を出してくれたはずです。今でも、そう信じています。
それも含めていい勉強になった案件でした。そして、コストと売り上げを気にするようになったきっかけの小さなプロジェクトでもありました。
何はともあれ、そのきっかけを作っていただいたお客様に感謝です。

最後に、今回の事案が最初から我々に発注されていたとしたら、新規開発費用とクレンジング作業の費用を合算した額以下で対応ができていました。我々に最初から新規開発を依頼されていれば、結果的に安価だったという結果でした。しかし、あくまでも結果論です。どうしても、発注先を決定する際は、提案金額で低い方に流れる傾向は今でも変わっていないのではないでしょうか。提案時の説明の方法などを我々としても工夫しなければならないのかもしれません。

次は、チームで同じ様なことを試してみたいと考え始めた頃でした。