7.事例
本文でも書きましたが事例は特定されない範囲でボカシを入れています。
特定はmajiでやめてください
ここでは自分の経験したことのあるシステム実装の事故事例を紹介しようと思います。できる限り可能な部分はぼかして企業や私自身を特定されないようにしていますのであまり深堀はしないでください。
案件と教訓として原因、対策を理解していただければと思います。
最初に紹介するのは共有資料が違っていたという問題です。
これは途中参画のプロジェクトだったのですが要件定義後に細かく設計を入れていくために業務で使用している計算ファイル等を共有してほしいと依頼したことがありました。
私より前にもこの依頼は何度か行われておりその都度少しずつ参照範囲が変わっているようでした。
問題になったのはこの共有資料で毎回少しずつ内容が異なるということでした。
開発的にはその資料を前提に作るということもあり前提が変わってしまうと開発ができずどうすれば良いのかという問題になります。
幸いにして変更されていた点は影響が軽微な部分だったためやり直しはあまりなかったものの重要な部分が変更されていた場合には炎上案件となっていた可能性もあり少し嫌な感覚を覚えます。
この事例では絶えず修正が行われるという状況を共有されていなかったこととその前提に立ってファイルのバージョンを決めておくという取り決めがなかったことに終始します。
こういう業務フローの自動化にも似た話ではどうしても最新バージョンとのずれが発生しやすくそれをあえて止めることでシステム実装を待ってほしいという合意が無いと永久に開発が終わりません。
よって要件定義時点でその合意を得ておくべきですし変更可能性に気づいた時点ですぐに再定義することが重要です。
次に紹介するのはもう少し深刻です。
この時の問題は、ある新規開発においてかなり後の工程で問題が発覚しました。
概要としては処理内容の中に処理すべき計算の一部が抜けているのが見つかったというものになります。
これも厄介なことに要件定義の段階で詰めるべき箇所があったという結論にはなってしまうのですが、いくつかのパターンに分かれる計算処理がありそのそれぞれがいくつかの条件分岐を持っているという二重構造が要因となっていました。
この二重構造の内でいくつか条件が分岐していないことが判明したという次第です。
原因をこのように書くとシンプルなのですがこれが発生した経緯は少し厄介なものがあります。
案件の初期に少し上の職位の人が開発を提案しその提案が上手くいって開発をすることになったというのは良いのですが、その後実際に開発内容を定義、設計する段階で実際にやるべきことは何かという具体的な部分が現場の人間から吸い上げきれなかったという失敗が起こりました。
この連係ミス、伝達ミスにより開発は一時中断されある程度の期間を置いて作り直しとなりました。
この案件はまだ良いことに開発しきる前に現場の人物から設計書についての質問がありその質問から問題が発覚したため本番稼働が行われてしまい影響がという話にはならずにすみました。
これについては開発側ではどうしても気づけない部分である以上発注側の方で対策をしてもらわなくてはならない事例なのですが、例えば要件定義段階で現場でのメンバーを数人入れたり設計書の段階で内部での回覧があればもう少し早くに気づいていた可能性はあります。
教訓として要件定義、設計書が出来上がったら一度関係者には連携することの重要性がわかります。
勿論全員から承認を得よ、というわけではなく質問が出なければそのまま進めるということで問題ありません。またその対象者も全部署内の人間ではなくある程度絞っておきつつ全階層としておけば最低限の責任は果たしてもらえるかと思います。
次に微妙に責任問題として厄介なものを取り上げようと思います。
開発の例では凡そ大体の物が要件定義や設計書作成の後に発注側でのレビューが入ります。勿論要件や設計内容で数学的に高度なものだったりかなり複雑な条件分岐を伴うものであればその前後では発注側の社内レビューが入ります。
私が経験した事例ではこの社内レビューが疎かで結果的に開発が非常に遅れ、最終的には開発の破棄が行われました。
少し具体的な過程として本来は開発側の人間とやり取りを行う主担当とそのレビューを行う上位者の存在があったはずなのですが段々とその存在が形骸化したためか、主担当のみのやり取りで全てが終始しレビューの存在が無いという状態に陥っていました。
そのため各種計算の理論的妥当性のダブルチェックしかり、設計チェック然りと言った点でほぼスルーと言う状態が出来上がったという次第です。
この問題は開発の遅延や延期、停止という問題にとどまらず、本来の開発レビューがないというガバナンス上の問題を孕んでいます。
特に金融、ファイナンス、個人情報を扱う企業においてはその扱いにかなりの制約が課されますし処理内容に関して透明性も求められます。
これはその処理内容についても十分にチェックが入ることの要請としても同等であり通常であれば開発者と、開発者とは利害関係を別とした存在の人間の検証を要求します。
また仮に利害関係の存在があるにしても十分な能力と可能な限りの中立的姿勢による検証を求めます。
つまりは主担当者に対して同等以上の能力を持つ検証者を用意したダブルチェックが必要と言えます。
勿論、その両者の能力は実装したい内容の要件次第で決定されるため絶対的にどの程度必要とはいえず高度な内容を含む際には当然高度な能力が要されるということは注記しておきます。
またこの実装の検証についてはある程度基準も存在します。一部の国際基準においては(モデル検証という枠組みではありますが)検証体制についても記載があります。
詳細については触れることはしませんが凡そは上記で述べたことと責任体勢を分離して両者の責任を明確にしたうえで作成・検証を実施せよということが述べられています。
これについては基本的原則ともいえるため必ず実施せよという意味ありかと言われるかというと微妙ですが、余程軽微な案件ではない限り実施するという心づもりの方が良いかと思います。
むしろ特段理由が無ければすべての案件でも実施するとしても良いですし、何より形骸化してしまい結果的にガバナンスの深刻な問題となってしまうよりはずっといいものと思われます。
本事例では問題の見つかった経緯はあまり明確なものではありませんが、明確にわかってたいのは体制的不備の一言に尽きます。
内容が重要になるにつれてその設計と検証は同程度の重みを以て必要なリソースを用意すべきですしそれが実際に出来ない以上は開発含め案件は非常に雲行きの怪しいものとなります。
扱う内容によってはミスそのものが一発で会社の営業に関わる致命的影響にもなりかねません。
開発側からすればあまり立ち入れない部分の話でもあるため得られる教訓は多くないかもしれませんがそれとなく検証体制を確認することや、もし発注側であれば案件のドラフト案が出た時点で検証体制の想定までは入れておくべきです。
あまり嫌な話はしたくないですが、金融関連の不祥事は体制に基づく問題行動の観測と牽制機能が弱いがゆえに発生したものが数多く必ずしもそこまでの不正事例にはならないにしても体制をしっかりと構築できていないことに対しては懸念を持つことは備えとしては必須でしょう。
最後にちょっとした小話のような事例で終えたいと思います。これは色々理由があったもので私自身も参画はそう長くなかったので曖昧ですがわかりやすいので書いておきます。
結論として計算の設計が誤っていたことに起因する開発の停止でした。
具体的には分散が0になるという不思議なことが起こっていました。
統計に不慣れな方にたいしては分散とはあるデータが平均値からどの程度ずれているかを表した数と思っていただいて結構です。この分散はデータが完全に同一の数でない限りは0にはならないはずなのですがその案件では0となっていました。
思い出す限りでは途中計算上で操作がいくつか入った上で分散の計算が合ったのですがそこで計算を本来すべき値と別の物を導入されていたがために定数扱いの数値が入ってしまい全く分散が無いという出力となっていた形です。
具体的に開発に入るまで何故か気づかれなかったのですが、その後ある程度既知のデータに対して実装したシステムの出力を突合して異常が見つかったという次第になります。
本当であれば設計段階でも気づかれておかしくはないはずなのですがそこがスルーされたので何故かという事例でした。これに関してはこれまでの事例同様のチェックもそうですが、既にある程度情報が分かっているデータとの突合をすることで確認をしたというところに評価点があります。
数値計算という分野もそうですが基本的にはシステムの改修・新規開発ではこれまでの蓄積されたデータに対して同様の出力を出せるか、もし蓄積データが無ければ情報のわかっているデータをダミーとしてそのダミーに同様の出力が出るかという点で検証を行います。
この辺りが実装の正しさを保証するちょっとした工程となります。
ちょっとしたとは言いつつもプログラムの内容によっては項目が多くなるので相当に泥くさい作業にはなります。とはいえこうした小さい積み重ねをしないと何時何処かで破綻が起きるかはわからないのでとても重要な仕事でもあります。
