見出し画像

既存システムの成果物が無い案件

Takashi Suda / かんた

最初にお断りしておくと、そういった状況は「ごく一般的に」よく起こります。理由は簡単。大別すると３点。

　「お客さまの情報資産に対する認識が杜撰だから」
　「設計書なんて無くていいと本気で考えているエンジニアが増えたから」
　「お客さまが開発を知らず短納期／低コストを求めるようになったから」

です。以降は、既存システムを「旧システム」と読み替えて説明していきます。

旧システム検収時にはすべて揃っていたケース

まずは、現在稼働している旧システムからリプレイス（再構築）しようとした際に、旧システム検収時には納品物の中に

　「成果物一式」

として要件定義工程からテスト工程までの全ての成果物が納品されているケースです。まぁ多くの場合、これが最も多いのではないでしょうか。

ですが、お客さまの中には情報資産を正しく管理できていないことがままあります。単純に管理が杜撰なケースもあるでしょう。そもそもリプレイスまでには５～10年の歳月がかかってしまっていることも多く、当時の担当者も出世や異動などによって次の担当者に引き継がれていることもよくあります。

この時、当時の納品物等を受領した担当者が、当事者ではなかったがために重要な情報資産であるという認識を持てず杜撰な扱いを行い、挙句、どこにしまったのかわからなくなってしまったり、紛失してしまったり…というのはよくあることなのです。

そもそもISMSに照らし合わせてもビジネスモデルや、企業業務の仕組みが記載された仕様書や設計書等の情報資産は「社外秘情報」「機密情報」として扱われて何ら不思議ではない代物です。

『機密性』だけでなく、『完全性』『可用性』などもとても重要になってきます。特に今回の場合は可用性がポイントです。ISMSにおける可用性とは

情報を必要に応じて「常に」利用できること

です。言い換えるなら「必要な時に、必要な分だけ、情報が利用できる状態に常にあること」です。だから、次期システム開発時に旧システムの仕様書や設計書が存在しない状況というのは「可用性」が保証されていない状態であることを意味します。

ISMSなどのISO規格を取得している企業であればご存じかも知れませんが、これらの規格は『トップダウンアプローチ』によって実施されることが求められており、特にマネジメントの遂行のためには予算などの捻出も必要なことから"決裁権"を持つ相応の役割を持つ人が最高責任者となって、組織運営することが求められています。

つまり、社長を含む経営陣がしっかりと情報資産管理に対して決定や判断をしている企業であれば、このような杜撰な管理は行われないことを意味しています（個人管理なんてさせないだろうし）。

しかし…実際には、CDなどで納品されていても、個人担当者の机の引き出しに格納されていて、何度か担当者が引き継いでいるうちに「これなんだっけ？」「さぁ？」「じゃあ捨てるか」と言った流れになってしまっているのではないでしょうか。

というか、実際にそういうお客さまを何度も見てきました。

お客さまの中には、そういった運用自体が「企業の取り組み」としても相当にマズいものだと理解していないケースも多々あり、挙句悪びれるでもなく

　「（プログラム）ソースが正だから」

と言って、そのまま開発を始めることが当たり前であるかのように押し付けてくることも珍しくありません。

ですが、リプレイスするにせよ、既存改修するにせよ、

　当時、そう作った経緯や思想

がわからないと「なんでこんな作りになってんの？」ということまではプログラムを見てもわかりません。そしてそういう問題は往々にしてよく起こります。お客さまの「ソースが正」という言葉を鵜呑みにしてより大きなトラブルを招いた例も実際に起きている点から見ても、そのことがよくわかります。

お客さま自身がよほどソフトウェア開発についての知見をお持ちなのであればともかく、そうでないのであればあまり「ソースが正」という言葉は鵜呑みにしない方がいいでしょう。まずこのセリフを吐き捨てた時点で相応に信用できないことがわかります。

とはいえ、実際に設計書等を紛失してしまって存在しないのは確かですから、そのことを前提に開発するしかないのは変わりません。

そう言った場合には、多少コストやスケジュールに影響が出るとしても

「では、要件定義の中で旧システムのソースから解析し、現在の設計と
　機能仕様を確認させていただきます。一度、結果が出ましたらお客さま
　にもご確認いただき、その内容をベースラインとして今回追加・変更等
　を加えていく形にしたいと思いますが、いかがでしょうか。
　重ねて、仕様や設計について不明点がありました場合は、『なぜそうし
　なければならないのか」といったお客様固有の事情もあるかと思います
　ので、そちらについてもお教えいただければ幸いです。」

と言って、調査／解析コストが余分にかかってしまう件をお伝えしましょう。その際

「そうしないと、旧システムの中に含まれた潜在的な問題や、ビジネス上の
　当時と現在のギャップを解析できず、結果として旧システムが抱えている
　現在の課題が解消されない可能性が非常に高くなります。
　本来であれば、そういった内容を検証するためにも当時の仕様書や設計書
　、あるいは議事録などが不可欠ではあるのですが、今回はそういったもの
　はないということですので、その分の追加予算およびスケジュールをご検
　討いただけますでしょうか」

といって合意を得られるように尽力するべきでしょう。なにせ、お客さまはシステム自体が稼働していれば、旧システムの成果物一式を紛失させてしまっても大した問題ではない…と考えてしまっている可能性があるわけですから、その発想自体が誤りであることをしっかり認識していただいた方が私たち開発側としてもリスクが減ってよい面もあるのですが、なにより

　お客さまにとって望む結果が得られる

可能性がグンと高くなるという点においても必要不可欠となるのではないでしょうか。


エンジニアがドキュメントの重要性を理解していない

案外規模の大きな企業でも、そういう「仕様書」や「設計書」を軽視し、最後には「作る必要がない」とまで豪語するエンジニアは日々増え続けています。なぜ増え続けているかというと、理由は色々あるのですが大きなところで

　①極小規模のプロジェクトでは無くても作れてしまう
　　（ライフサイクルや次期開発を考慮せず作るだけならできる）
　②アジャイル開発モデルが間違って拡散されてしまった
　　（別に設計書を書かなくてもいいモデルと言うわけではないのに）
　③上記のような背景を言い訳にできるようになった
　　（本音はさっさとプログラミングしたいだけ）

と言ったものがあります（他にもまだまだあるでしょうが）。しかも、それをＩＴ企業が企業ぐるみで暗黙のうちに容認してしまっていることが一番の問題です。

なかでも①は大規模であれ小規模であれ、そもそも「仕様書」や「設計書」の目的自体を履き違えているケースです。社会も、企業もまともに教えていない証拠です。

設計書は確かに「作るため」という目的を有していますが、それだけではありません。「作るため」だけのものだと勘違いし、かつその考え方をしている自分自身を"正しい"と思い込んでいるからこそ起こってしまっている問題です。

たとえば「品質が悪い」と言えばイコール「バグがある」ことだと勘違いしているのと同じくらいの隔たりがあるのですがそのことに気づいていません。

それは非常に危うい考え方です。

そもそも１つの成果物に目的が１つしかないと誰が決めたのでしょうか。大抵のものには何かしら２つ以上の目的があるものです。たとえば食事に

　・空腹を満たす
　・栄養分を吸収する

という目的があるのと同じです。

では設計書には「モノをつくるため」以外にどんな目的があるのかというと、それは『情報を正確に未来に伝えるため』というものです。実装の工程に伝えるという意味で「モノをつくるため」という目的と合致しますが、それ以外にもたくさんの"未来"があります。

画像1

　「仕様書や設計書を作らない」

それでも製品／サービスを作るだけなら出来るかも知れません。でもそれだけです。いずれ自分ではない誰かに引き継ぐかもしれない情報を「記憶」だけに頼ることが本当に正しいエンジニアリングなのでしょうか。

所詮、

　「自分がやりたいようにやるだけ」

という本音のために体よく設計書を書こうとしないだけのようにしか見えません。そんな方法を許している企業も（社会的信用を得る立場として）どうかとおもいます。

その方法自体に対して自分なりの正しさを論理的に証明できるというのであればまだしも、挙句「でも、それでお客さまがいいって言ったし」なんて自分自身を正当化する根拠もなく、ただただ他責な言い訳を言い出したらもう末期と考えていいでしょう。エンジニアとしては三流です。そんなエンジニアリングを許容するプロジェクトマネジメントも当然三流となります。

そもそも、記憶に頼ったプロセスの進め方をして褒められるのは学生までです。学生時代はたしかに「テスト」によってその多くを暗記に頼らされ、とにかく記憶に詰め込むことを良しとされてきました。

まぁそれができなくても他人に迷惑をかけませんしね。

ですが、ビジネスマンになると話は変わってきます。
すべて記憶に頼った進め方をすることが、ビジネスとして褒められるか？というと全く真逆です。

どんなに記憶で済むことでも記録化する。

それがビジネスに対する真摯な姿勢です。ほんの少しでも後で問題になるような可能性の芽を摘む。それこそがお客さまに対して誠実な姿勢になるとは考えられないでしょうか。

ＩＴ企業というと兎角「プログラミング」の教育から始まり、そしてそれで終わりです。多少テストの教育…はするかもしれませんが、設計の教育はほとんど行われません。その理由には「明確な答えがないから」というのもあるのかもしれませんが、実践を通してでないと具体的に教えづらい…というのもあるのでしょう。

知識だけ教えても実践ではなかなか使えませんし、配属される部署やその部署の取り扱う技術要素によって使う設計書が異なったりしますからね。

ビジネスマンとしての基礎教育なんて最初の数日だけで、それらは技術教育の中で利用、反復する機会を設けるでもなく、ただただプログラミングのあれこれを教えているのではないでしょうか。

前職がそんな感じでした。

中堅企業以下にもなると、そもそも教育すらまともに行っていない企業も非常に多いもので、前職では希望する企業の新人を受け入れて無償で新人教育を実施していたくらいです。

とにかくプログラミング中心で教え、プログラミングの楽しさを覚えてしまい、かつ設計やテストの重要性を伝え忘れたままにしていると、そりゃあ設計することの大事さなんて身につきませんし、さっさとプログラミングがしたくて設計をおざなりにしてしまうエンジニアばかりになってしまうのは当然の帰結なのかもしれません。


顧客も開発の中身を知らず言いたい放題

もう20年以上前からずっと言われ続けていることですが、ソフトウェア開発の業界は長年、顧客の

　短納期化／低コスト化

要望に晒され続けています。その理由には

　・仕組み自体、歴史の浅い業界で非効率的な部分も多々残っている
　・物理的に組み上げられるわけではないため業務がイメージしにくい

といったものから、建築や製造業のそれと比べて「ドキュメント数百ページ分くらい〇ヵ月で十分じゃないのか」という（ちょっと乱暴な）お客さまの意見が大きくなったものまで多々あります。

たしかに、ソフトウェア開発の世界ではいまだに著しく優秀なエンジニアたちによってピンキリの開発方法論が提言されており、それらのどれを用いればよいかについてまともな基準もありません。

結果、各企業、各プロジェクト、各エンジニアが思い思いに自由な選択を行っているのが実情です。

他の業界…たとえば、医療、建築、食品、機械製品を主とした製造業のように法律による制約もほとんど存在しませんし、協会や団体などによる強い牽引もみられません。ＩＰＡ（独立行政法人 情報処理推進機構）などが存在はしていますし、様々な情報発信をしてくれてはいますが…

それが業界全体に対して一定の強制力を発揮しているか？というとまだまだ微妙です。あくまで「使いたければ使ってもいいよ」という姿勢を崩していません。

そのため、どうしても各方面の人たちから見てもソフトウェア開発業というものはその内実が色々謎に包まれており、そのことが

　ＩＴ企業ですら自社の開発がどうなっているか把握しきれていない
　（顧客に対して誠実な開発方法となっているか理解できていない）

という状況を生み出していますし、顧客側から見ても

　開発の大変さや複雑度を理解できずに短納期/低コストを主張する

という状況が起きてしまっています。そして、そのことに対してＩＴ企業側もまともに説明責任（accountability）を果たすことなく、現場の

　「お客さまがそういったから」

という判断だけで、無理なスケジュールや予算を削減することも珍しくありません。経営的な判断というのであればまだしも、多くの企業では受注規模の大きさによって決裁権を配分するのが一般的なため、短納期化とそれによる低コスト化が行われたうえで見積もると否応なく、現場寄りの管理職が決裁することになってしまい、経営判断となることはまずありません。

実際、入札やコンペでも"価格点"と言って、発注側にとっても「安い方がいい」という思いはあります。仮に入札やコンペでなくても、安くしたいという思いはあるでしょう。

ソフトウェア開発に要する適切な価格というものを知らないのですから、多少無理強いしてでも開発側に「もっと安く」と要求することになります。

だからこそ、誠実なエンジニアであろうとするならば

　「適正価格」や「適切な進め方」

などをきちんと説明し、納得いただく努力を行う責務があります。

それを放棄して、顧客の言いなりになって「記憶に頼りトラブルが起こるともわからないプロセス」を実施してもロクなことはありません。

また記憶に頼るということは個人に頼るということです。「属人的とすることでプロジェクトリスクが最大化する」という側面も出てきます。具体的には、その記憶している人に重責や過負荷が集まりやすくなるため、その人一人が離脱（病欠や離職）した時点でそのプロジェクトが成り立たなくなるというリスクを負うことになります。

さらに「次プロジェクト以降に必要な情報を残さないことで顧客のビジネスモデルにもリスクを与える」ことになりかねません。仮に次プロジェクトで再度発注が来ても上記のリスクを抱えることになりますし、もし別社に発注するにしても設計書も何も残っていないような状況では依頼も難しくなるでしょう。場合によっては、より高い見積りとなってしまう可能性だってあります。自社としてベンダーロックインしやすくはなるかも知れませんが、そのために延々と上記の「属人的とすることでプロジェクトリスクが最大化する」リスクを抱え続ける企業体とならなくなってしまいます。そのリスクは非常に大きいこともわかると思います。

だって、続ければ続けるほど、そこで晒され続けるエンジニアは疲弊し、摩耗し続けるわけですから、長続きするはずがありません。長く続けば続くほど、顧客も他社には頼りづらくなり、いざ有識者となった個人が離脱した時には、色々な責任を問われることになるのは覚悟しておきましょう。

　「設計書」

というのはそこまで派生するほど、とても大事な成果物であり、ただただ「モノづくり」のためだけと安易に考えていいものではないのです。


開発側の立場から見た時、相手（お客さま）側に正しい認識と納得をしてもらう努力を続ける必要がありますが、しかしそれが必ずしも実現できるとは限りません。所詮、他人をコントロールするのは難しいわけですから。

ですが、私たち開発する側としては己の欲望にただ忠実であることよりも、もう少し相手に、ビジネスに、社会に対して誠実な姿勢であるべきではないでしょうか。

設計書が無くても、確かにモノは作れるかもしれません。

しかし、私たちは目先のプロジェクトのことさえ達成できればいいという考えでプロジェクトのライフサイクルという視点だけを持つのでなく、

　・システムのライフサイクル
　（納品後～廃棄されるまで（保守・運用や改修などが何度も行われる））
　・お客さまのビジネスのライフサイクル
　（ビジネスが生まれて廃れるまで（再構築や改修が何度も行われる））

という目線を忘れてはならないのではないでしょうか。

ソフトウェア品質(ISO 25010)には、その品質特性のなかに

画像2

保守性や移植性も含まれていることを忘れてはなりません。ただ作ればいいと思っているだけではエンジニアでもプロフェッショナルでもない…ということを覚えておきましょう。

いいなと思ったら応援しよう！

Takashi Suda / かんた
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。