「現行通り」は惑わせる言葉
少々気になる記事を見つけたので、私なりの見解を書き残しておきたいと思います。
こうした現場は少なくありません。
楽だなんてとんでもない！
こう言う話が出てきた時点で、通常なら「トラブルプロジェクトに片足踏み込んだ…」と嘆くのが当たり前です。もしも、「現行通りでいいんだ！今回は楽だな！！」なんて人がいたら、その人はおそらくプロジェクトマネジメントをあまりしたことが無い素人に近いのかもしれません。
もちろん、かなり小規模のシステムなら、楽…かもしれませんが、私が過去にトラブル解決としてかかわったことがあるプロジェクトでは、たかだか50kstep程度のシステムで、数千万の赤字になるほどトラブっていましたよ。ｳｰﾝ…家１軒建つ程度のお金をポンとあぶく銭にできてしまう。それがこの手のシチュエーションに起きやすい実態です。
ＩＴ業界を知らない人、これからＩＴ業界に足を踏み入れる人向けに少し説明しておくと、このような既に存在している『現行』システムにある程度沿って、新しいシステムを開発する（作り直す）スタイルを
リプレース（Replace：再構築）
と言います。今や、完全に新規でソフトウェアを開発する機会は殆ど無くなりました。それでも新規っぽいものに携われるとしたら、ほとんどがこのリプレース案件です。
ただ、この記事でも書かれているように
「新システム？ 現行通りの仕様で作ってくれればいいよ」
「その“現行”が分からないんですけれど……」
「………」
と言った事例や、
「現行でお願い」
「現行が分からん」
「設計書が欲しい」
「設計書が見当たらん」
「相談しよう」
「そうしよう」
……
「決まらん！」
と言う迷宮入りする事例、他には
「ソース(プログラム)が正だから」
「…（ソースがバグってるんだけど…このままでいいの？）」
なんて事例もありました。これは、取引先となる客が、ユーザーである場合でも、仲介に入っているSIerである場合でも、ほとんど同じ屁理屈をぶつけてきます。
ここで多くのエンジニア、多くのマネージャーは躓きます。ですが、こうした問題は非常に多くの現場で見られます。この際「誰が悪いのか」は言っても解決されないので、置いておきましょう。ですが、実際にこうした現場に関わってしまった時に、「わからない」と言って何もしないわけにはいきません。なぜなら、Ｂ２ＢのＩＴ業界においては、
内容を詳しく知る前に、先に契約を済ませてしまっているから
です。
もしも、見積り時点で上記例のようなことがあれば、撤退することも可能です。ですが、要件定義工程で…と言うことは、すでに受注（契約締結）していて、私たちエンジニアはその履行責任を果たさなければならない立場にいることが予想されます。
そこで「客がまともに要件を出さないから、できないんだ」と言ったところで、ＩＴ調停（裁判等）の場に持っていかないと誰も認めてくれません（ＩＴ調停では、この手の問題は客側に責任アリとして判断されます。もちろん、契約内容次第ですが）。
ですから、こう言う現場に関わってしまった場合、私たちがするべきことは大別して３つです。
①社内の上司、経営層に、プロジェクトリスクについて報告する
②お客さまに事情を説明し、「現行整理」する工程を設ける
③ソフトウェアの背景や利用者の事情はこの際考えず、
現行から機能仕様／非機能仕様をすべて洗い出す
です。一般的に、「要件定義」工程では、「何を問題としているのか？」「最終的にどうなっていることが理想なのか？」「なぜ、そうしたいのか？」と言った、お客さまの事情や今に至る背景を細かく整理します。なぜなら、お客さまの「〇〇を作ってほしい」と言うアプローチが、お客さまの真のニーズとかみ合っていない可能性があるからです。
ですが、「現行通りで」と言われた時点で、現行のソフトウェア自身に不満がほとんど無いと言うことがわかります。また、多くの利用者の"慣れ"もあって、いまさら真新しいモノを作って、それに慣れるまでのスイッチングコストを掛けることを嫌っているのでしょう。
ですので、まずは「現行」を調べ尽くすのです。
・どんな機能を有しているか
・どんなＵＩなのか
・各機能や操作性の共通点は何か
・どんなスペックで動作していたのか
・どんな判定処理が加えられているのか
それは、データを取り扱う上で不足が無いのか
・データベースにはどんなデータが蓄積されているのか
どのテーブル情報が多いのか
日々、月々、年々、でどれくらい増加しているのか
・過去ログはどうなっているのか
（利用ログがあるとなおベター）
・保守や運用の記録はあるか
初期リリーズ時から、何が変更されているか
どの程度の頻度で変更されているか
変更された機能は主に誰が使っているのか
とにかくいろんなことを調べ尽くします。
たいていのことはソース…すなわち現行で稼働中のプログラムで把握できます。その現行のハードウェアスペックやネットワークを含むシステム構成を調べれば、非機能要件として初期リリース当初にどんなことを要求していたのか、半分くらいは見えてくるでしょう。
ただ、リプレースによってＯＳやミドルウェアまでが変更されてしまっている場合、ＯＳやミドルウェアが現行で使えていた機能が無くなっている可能性があります。ハードウェアについても同様です。そのあたりを調査しきれず、あとになって「現行では〇〇できていたのに」なんてクレームを言われることがあるので、プログラムのみ調査すればいいと言うわけではないことも頭の片隅に入れておくと良いでしょう。
私が直近で覚えているのは、組込み系媒体に対して、WindowsCE上で実装されたタッチパネル式のシステムでしたが、それをモバイル媒体に対して、Windows8.1上で動作するアプリケーションに置き替えようと言うものでした。
この時、現行では、バッテリーを抜いても３分ほどは電源が切れなかったんだそうです。それと同じことを"携帯電話"と同じモバイル系の媒体で実施できなければ「現行通りではない」と難癖をつけてくるお客さまがいました。
もちろん、携帯電話…と言うよりはタブレットと同じ構造ですから、バッテリーを強制的に抜けば、電源が切れるのは当たり前です。物理的に電源供給を断とうとしているのに、それをソフトウェアでなんとかしろと言っても無理なものは無理です。
しかも、ハードやＯＳはこちらで選定したものではなく、要件の当初から指定されていたもので、開発側ではどうすることもできなかった…と言うことですが、そう言うことも含めてきちんと調査し、報告し、お客さまと協議さえしていれば、最後の最後にそんなクレームを受けずに済んだはずなんですけどね…。
もし可能であれば、
・実際の利用者に、現行を利用するシーンについてヒアリングする
機会を設けさせてもらえれば、より業務や操作に近いところがわかってくるはずです。ただ、業務に支障が出る可能性があるため、否がるお客さまもいますし、下手にヒアリングしようものなら、現場利用者の現行に対する不満や要望が湯水のように湧いてくるので、そのあたりのコントロールが苦手なチームは、「お客さま側の担当者にヒアリングの作業を依頼する」「あらかじめ明確なルールを決めたうえでヒアリングする」などの調整をしておくと良いでしょう。
もちろん、「ヒアリングしない」と言う選択肢もアリですが、必要な情報を揃えるためのピースが欠落すると、それだけ後々に大きな負担がかかりかねないと言う点は気にしておいた方が良いでしょう。
一つひとつの決断に責任を持たなくてはなりません。
こうして、現行のソースから逆算して設計書（基本設計書相当）を作成し、その内容を以って、お客さまとレビューしましょう。
「現行はこのようになっていました。
現行通りと言うことは、原則として機能仕様はこの通りに
実装していくことになりますがよろしいですか？
今回、リプレースされるにあたって、現場からの声を拾うのであれば
この段階で仰っていただかないと、後々変更依頼があると
スケジュールやコストの調整が必要になってくる可能性があります」
と言った感じです。一般的に、
要件定義：何を実現したいか？
基本設計：実現するためには、何を作るのか？
詳細設計：作るモノが決まったら、それをどう実装するのか？
と言った疑問を段階的に解決し、明確化していく進め方になります。プログラム言語にもよりますが、この際、詳細設計はあってもなくてもなんとかなりますが、基本設計相当の整理文書が無ければ、『いったい何を作ってほしいのか？』が明確になりません。
これが無いと、通常は『開発』そのものが進められないのは道理です。
基本設計には、大別して
・業務仕様
・システム仕様
・機能仕様
があります。
業務仕様は、システムを利用する上での業務上の制約の決定であったり、逆に業務上でのシステムに対する制約の決定などを明確にしたものです。要件定義の時点で業務フローなどを作成することもあると思いますが、そこにシステムとの関係性をつなげていくのも、この段階です。
このように、「業務のどのタイミングでシステムが関係してくるか」「どの業務をシステム化するか」などを決める作業になります。
システム仕様は、ソフトウェアが、ネットワークやハードウェア、ミドルウェアなどと、どのように関係していくかを明確にするものです。ソフトウェア自身のアーキテクチャにも深くかかわってきます。
たとえば、利用するデータベースがOracleなのかDB2なのか、それともSQL Serverなのかによって、その特性に合わせた設計が必要になってきます。他にも、「24時間365日稼働し続けてくれないと困る」「データが消えると事業が成り立たなくなってしまう」と言った場合は、災害対策用に大地震等が起きても影響しあわない２拠点間で全く同じシステムを構築し、それらの間でデータがほぼ同タイミングで共有（replication）されるような仕組みを構築しなければなりません。
機能仕様は、その殆どがソフトウェアの中身の話になってきますね。多くのエンジニアが知る「基本設計」とは、コレのことでは無いでしょうか。
・どんな機能がいるのか
・その機能はそれぞれどんな内容なのか
・客の目線から見て、どうなっていなければならないのか
などを決めます。なぜか、この段階で詳細設計紛いの「処理」まで設計しようとするＩＴ企業も多く散見されますが、いくら早くプログラムを作りたいと言っても、設計書にそれを書くのは止めましょう。それは詳細設計書に書くべきものです。
もしも、詳細設計工程がないのであれば、メモとしてあってもいいですが、詳細設計工程がきちんとあるのであれば、具体的処理、アルゴリズムに関する記載は、詳細設計で書いておくべきです。
基本設計でも、似たような記述をすることはありますが、それは常に「お客さま目線」でなくてはなりません。要するにＵＩが動的に変化する場合に限り、条件や制限によって、どうアウトプットされるのかを記述するものです。
お客さまの認知しない、システム内部の処理内容については、基本設計で書くものではありません。そんなものを書いても、お客さまはレビューできません。
設計工程は、企業によってさまざまな呼び方を持ちますが、通常
「基本設計」／「詳細設計」または
「外部設計」／「内部設計」
と呼ぶことが多いでしょうし、どの企業のエンジニアでも、この言葉は共通語として認識されます。この外部と内部と言うのは、
開発チーム内外
と言う意味です。「外部設計」とは、開発チームの外側…すなわちお客さまも加わって完成させる設計工程であるということ。逆に「内部設計」とは、ＩＴリテラシーが不足しているお客さまには加わることができない領域…すなわち開発チーム内だけで完成させる必要がある設計と言うことです。
ですので、詳細設計（内部設計）で記述するような内容を、ひいては「お客さまでは正しいかどうかを判断できないような内容を、基本設計（外部設計）で記述するべきではないのです。
このように、リプレースを主としたプロジェクトの場合、お客さまの「開発」に対する認識が甘いために
「現行が仕様」
「ソースが正」
と言った横柄な態度をとられることがありますが、珍しい話ではありませんので、その場合は、その場合に適したプロジェクトマネジメントをしなくてはなりません。
①で上司や経営層に報告をしておく必要があるのは、このシチュエーションの場合、「現行整理／調査」にどれくらいのコストがかかるか、まったくわからないからです。規模見積りではおそらく精度30%にもならないでしょう。なぜなら、解析難度が不明だからです。
・前回リリース時、プロジェクトは大トラブルだった
・長期運用してきた結果、幾度となくその場しのぎの改修が行われた
と言う事態が想定されます。こうした過去がある成果物（システム）のプログラムは、字の汚いレポートを読まされているようなものです。
当然、読解するメンバーのパフォーマンスは圧倒的に落ちます。従来なら１日で10kstep（1万行）は解読できる人でも、酷い場合は1/3以下に落ち込むケースだってありました。
ですが、既に契約として受注してしまっている場合、逃げると言う選択肢が無いため、自社持出しで赤字化する可能性があることを、上司や経営層に一言伝えておくのです。
もちろん、そうならないよう最大限務めるのが「仕事」と言うものですが、スタートラインが大幅にマイナスから始まるようなプロジェクトの場合、プラスに転じさせるのは、かなり難しいでしょう。メンバーの力量次第ではワンチャンあるかも知れませんが、その分、メンバー一人ひとりにかける負担も相当大きくなりますので、あまりおススメできません。かと言って、とにかく人員を大量投入しようものなら、スケジュールだけは何とか守れても、あっという間に赤字まっしぐらです。
そうならないために②でお客さまに事情を説明し、現行整理を行うために再スケジュールやコストの再調整を承認していただかなくてはなりません。
「『現行が仕様』ということですが、私どもは現行を把握していません。
ですので、まずは現行を調査させていただきたいのですが、
そのためには大きく
・スケジュールに組込む
・納品日／見積り予算内に収まるか再検討
する必要性が出てきます。
弊社で想定している「要件定義」ではお客さまのニーズを実現するため
ヒアリングを繰り返し、システム化に必要な規模を見定めていく予定
でした。
しかし、ニーズがすべて現行プログラムの中に詰まっている以上、
私たちは現行のプログラムと対話しなければなりませんが、当然、
プログラムにはそれを作った者の癖がついている可能性があり、
可読性が高いかどうか、現時点では不明です。
まずは１週間ほどかけてざっと上澄みを調査し、どの程度の期間で
調査が完了するか見積ります。それが当初見積もりの枠内に収まれば
良し、そうでない場合は、別途ご相談させていただいてもよろしい
でしょうか。」
「NO！」と言われた場合の対策も２～３講じておく必要はありますが、まずはこのようなアプローチで、本来の進め方とは異なるんだよ？と言うことを理解してもらうところから始めましょう。
また、この説得には、お客さまの中でも「担当レベル」に納めておくのではなく、かならず「決裁者クラス」の人も同席させてください。金勘定やビジネスもあまり知らない現場担当クラスでは、自身の評価や出世に目がくらんで、無理難題を突っぱねてこようとする人や、自分自身では何も決められず長々と保留にする人なんかもいます。
「決裁者クラス（できれば部長以上、役員が出てくるとなお良い）」がいると、この辺りはとてもスムーズに進むことが多いのではないでしょうか。
兎にも角にも、こうした
「『現行』と言うパワーワードで押し切ろうとする客がいる」
と言う問題は今に始まったことでは無く、この業界では長い因習となっている側面もあるため、「いまさら無くせない」「泣き寝入りはしたくない」以上、私たちＩＴ業界の人間は、そうなる可能性を常に頭の片隅に入れて、最適解を導き出せるよう試行錯誤を繰り返しておく必要があるのです（こういうのはＩＰＡ含め、どこも答えを教えてはくれません）。
ちなみに。
「現行通り」という言葉は、疑うためにあるものと言うのが通説です。本当に現行と寸分たがわず、全く同じもので良いなら、そのまま現行システムを延々と稼働していればいいじゃないですか。
ハードウェアやミドルウェアのライセンスや保守サポートが切れるから…と言っても、受注生産で作成したアプリケーション自体はいつまでも使えます。公共システムなんて、２０年とかザラに残っていますよ。
「それでも、リプレースをしたい。」
というのです。何か「現行の再利用」では済まされない理由があるはず、と考えるのは至極当然です。
「現行を再利用すればいいのに、リプレースしたい」
「でも現行が正で、現行と同じで良い（リプレースの意味ないじゃん）」
と言う。この二律背反をどのように成立させるのかと言うのは、普通にシステムを作るよりはるかに難易度は高いのです。だから、この手の要望がある開発をナメてかかると、大きなトラブルへと発展していくのです。
いいなと思ったら応援しよう！
