JASTPRO DXの道 第6話「コード管理システム刷新プロジェクト（2）艱難汝を玉にす」

【初出：月刊JASTPRO 2022年6月号（第517号）】

前号で紹介した通り、このまま進めたら炎上必至のコード管理システム刷新プロジェクト。通常のシステム開発であれば、状況を把握した時点でプロジェクト責任者や組織のトップに中止を進言していたところです。

しかしながら、プロジェクトの発端であるシステム刷新の動機、つまり「これまでの問題を解決し、かつコスト削減と柔軟性の強化」自体に罪はありません。それどころか、JASTPROコードの未来を考えれば、絶対に避けては通れない道であることも確か。

そして、こんなヤバめのプロジェクトにおいても、一筋の光がありました。それは、当協会コード部門トップであるKコード部長の存在です。K部長はコード事業の責任者としてこのプロジェクトをリードしており、刷新に向けたシステムの在り方づくりや具体的な仕様策定を先頭に立って進めておりました。コンピュータシステムの専門家でないにも関わらず、K部長の示した新しい業務体制や要求仕様は非常に現実的で、しっかり実装できればシンプルかつ強靭さのあるコード運用管理体制を構築できると思わせるものがありました。また「システムのことはわからない」と言いつつもシステム業者に丸投げするようなことは一切なく、しっかりと議論に参画し、必要な時には自ら手を動かすこともいとわないという、システム開発側から見るとユーザー側に一番居て欲しいと思える存在です。

もうひとつ、このタイミングで筆者が入職したという事実にも、何か因縁めいたものを感じていました。以前の連載記事「日本のベース・レジストリ戦略とJASTPROコードの未来」にて紹介したとおり、筆者はこれまで通関、倉庫、配送といった物流業界に長く在籍し、情報技術に関わる職務に携わってきました。その中でも特に通関での仕事が長く、JASTPROコードを利用者側からさんざん使い倒していたこともあり、その仕様や仕組みに関するそれなりの理解と、ちょっとした愛着のようなものがあったのです。

筆者と本プロジェクトの出会いは、入職初日のK部長との打合せから始まりました（その過程でいろいろな事実確認を進めた結果が前号後半の話です）。プロジェクトそのものには暗雲が立ち込めていたものの、JASTPROコードや輸出入通関手続きについてはお互いの知識や経験に重なるところが多く即座に意気投合し、相当にマニアックな話まで楽しめたことをよく覚えています。

K部長には、率直に本プロジェクトの（システム屋の視点から見た）状況やリスクをお伝えしました。中止するという選択肢も含め、時間をかけて議論を重ねました。そして得た結論は、「リスクもあるし大変であることはわかったが、それでも進めよう」というものでした。現状維持によるマイナスは、システム刷新プロジェクト失敗のリスクよりも大きいと判断したのです。筆者も、議論を尽くした結果、この結論を支持することに決めました。今思えば、中止という選択肢はそこに自分が飛び込む覚悟がなかったことの裏返しだったのかも知れません。

そうと決まれば、あとはやるだけです。幸い（？）筆者は炎上プロジェクトに巻き込まれたことが何度かあり、その経験から何が足りないのかがある程度見えていました。

足りないのは、プロジェクトマネジメントです。これまでの状況を整理した結果、今回依頼した業者は「システム開発」のプロではなく「言われた仕様をそのまま構築する実装屋」でしかないことは明らか。本来であればシステム開発業者には業務プロセスの改善を踏まえたフローやモデルの設計から実装、テスト、リリースまでの工程管理までを予算内で実施するというプロジェクトマネジメントを期待しますが、今回の業者はおそらく「実装とテスト」しか想定していない。だからあんなに安い金額だったのだろうと合点がいきました。

この時点で、入職から約1か月。当初のスケジュールでは、システムリリースまで残り2か月という状態でした。しかし、肝心のシステムは（仕様書もないのに）製造中でまだ何も触れない状態。とりあえず当時稼働していた旧システムの仕様を把握しながらデータ移行プランなどを練りつつ、最初に別の業者によって作成された要件定義書を紐解きながらどこから手をつけるべきか、プロジェクトマネジメントの基本に立ち返りながら考えてみます。

プロジェクトマネジメントには、PMBOK（Project Management Body of Knowledge、「プロジェクトマネジメント知識体系ガイド」。プロジェクトマネジメント協会発行。最新版は2017年9月発行の第6版）に代表されるような手法が確立されています。ざっくりいえば「品質とコストと期限を守りながら、独自の（毎回同じではない）成果物を仕上げる」ことがその使命です。特に品質（Quality）とコスト（Cost）と期限（Delivery）については、その頭文字をとって「QCD」と表現されます。このQCD、それぞれをバランスよく満たさないといけませんが、どれもこれも最優先だと言い始めてしまうと、そのプロジェクトはまず失敗します。そのため、可能な範囲で最優先する要素を決め、それ以外には多少目を瞑る覚悟が必要です。

今回は、何をおいても「品質（Q=Quality）」を最重要視することにしました。日本の輸出入を支えるコードの管理システムなので、多少の不具合はあるにせよ、全面的な移行の失敗とそれによるコード発給業務の停止だけは何としても避けなくてはいけません。

「コスト（C=Cost）」については、当初の安価な見積もりによって予算的な余裕が生まれたため、開発リソースに万が一の事故が発生するリスクへの対処策として、もう1社のパートナー開発業者を追加し、共同でシステム開発を行う体制が組めていました。そのため、この時点においてはあまり憂慮することのない要素であったと言えるでしょう。

残るポイントは「期限（D=Delivery）」です。現実的に考えると、当システムの規模は決して小さくないので、各工程にはそれなりの時間がかかります。その工程群を足し算してみると、あと2か月ではどう考えても足りません。残り2か月のうち1か月がプログラミングに使われるため、残りの工程である「初期バージョン検証→詳細仕様の検討→実装→テスト→ユーザー受入検査→微調整・最終テスト」を1か月で。そんなことできるわけがないのです。さらに恐ろしいことに、この1か月は間に年末年始をはさんでおり、実質的には約1週間動けない期間が存在していました。これは決してホラー映画などではなく、半年前に存在していたプロジェクトの実話です。

このような背景から、本プロジェクトにおける筆者の最初の仕事は、リリース時期を遅らせることでした。具体的には、K部長とも相談した上で、1月中旬を想定していたリリース日を3月中旬に変更。これによって、初期バージョン完成から約3か月を確保しました。決して余裕があるわけではないものの、どうにか現実的な線が引けそうです。

スケジュール延長に伴うコストの増加についても想定予算内に収まり、プロジェクトの進行に現実感が見えてきました。ここからは各工程で必要な作業を割り出し、業者側と当協会での分担を決めていきます。これまでは、業者に何を尋ねても「大丈夫です」としか返ってこなかったようで、それが却って当協会側の不安を増大させていました。そこで、まずは週ごとに行われていた打合せに筆者も参加し、不足している点をどんどん指摘していきます。業務フローの再整理や、それに伴う画面構成・画面遷移の詳細を図示化し、業者に対してコード業務への理解を深めてもらうための取り組みを続けました。

これと並行して、筆者もK部長からコード業務に関する現状やこれから目指す姿、また実務者ならではの細かい勘所を教わりつつ、筆者からはシステム開発に必要な知識を少しずつお伝えし、お互いの知識・経験の共有を図りました。このサイクルは、システム開発プロジェクトの渦中にいる者が味わう独特の不安感とともに過ごす毎日の中、それぞれのスキル向上を実感できる機会として非常にありがたい時間でした。

この「システム開発にきちんと関与してくれる利用者側トップ」と「システム開発対象の業務をそれなりに理解しているプロマネ」という組み合わせは、今思えばこの炎上プロジェクトを鎮火させるための、かなり強力な消火器だったのではないかと感じています。

そして季節は秋を過ぎて冬本番。12月の第2週に「とりあえず触っていただける」という状態のシステムが業者側から公開されました。よし、早速アクセス。

ナニコレ・・・？？？

まず目がちかちかする。なんで配色が原色だらけなの？ これ業務システムなんですけど。当協会の職員が長時間操作するシステムなので、これでは目に悪い。すぐ直させないと。気を取り直し、目薬を差しつつデータの項目を確認。ん？ これまで何度も依頼してきた項目が全然入っていないぞ？ 確か表形式で渡してましたよね？

・・・まぁ項目はさておき、基本の業務フローをやってみようか。あれ？ データ一覧の表示がズレてる？ なんで日時の項目が3つもあるんだ？ チェックしていませんでした？ 詳細画面での作業はどうだろう。あれ？ チェックボックスを設けて作業確認する機能は？ え、まだできてないんですか？

システム確認初日。K部長と筆者は途方に暮れることとなりました。とりあえずの初期バージョンとは言うものの、あまりに未完成。これでは業務フローの確認もできません。システム開発側でのテストとQA（Quiality Assuarance。品質保証のための検査）は実施したのか？ という状態です。多少は覚悟していましたが、プログラミングと単体テストくらいしかやっていないように見えます。会議中にQAという言葉が通じなかったので、業者側は知らないのかも知れない。

ご存じの方もいらっしゃると思いますが、システム開発はひたすらプログラミングして、出来あがったらそれを動かして終わりというものではありません。むしろその後のテストが重要です。製造したプログラムが仕様通り正しく動くかどうか、それも、正しい処理をしたら正しい結果を返してくることを確認する「正常系試験」だけではなく、間違った処理をしたらきちんとエラーを返してくることを確認する「異常系試験」が欠かせません。間違った処理をしたら画面が真っ白、処理は正常に終わらずデータが壊れてしまった・・・といったことを防ぐためです。

しかし、この様子だと異常系試験どころか正常系試験すら満足にされていません。ないものねだりをしても仕方ないので、ここは我々でカバーするしかないと腹を括り、その旨をK部長にも伝えます。その日からK部長と筆者の二人三脚で、機能確認と詳細仕様の追加に加えて品質確認試験も実施することにしました。まずは課題管理表を作成して業者と共有します。その後は、何を触ったらこんな結果になって、本来はこうなるべきなので直して、といったことを全ての機能についてひたすら行っていきます。

最初は、K部長にシステムを触ってもらって期待通りの動作をしないところを筆者が目視確認し、それを文章に落とし込んだ上で課題管理表に記入するというプロセスを繰り返しました。不具合の状況を正確に伝え、こちらが意図する通りに修正してもらうための書き方には少しコツがあり、言葉で説明するのが難しかったので実践を通じてお伝えしようと思ったのです。K部長はこの手法をすぐにマスターし、二人で不具合を見つけては課題管理表に書き込み、優先順位をつけて修正指示を出し、修正がされたらすぐにチェック・・・というプロセスが出来上がってきました。

これと並行して、わざと間違った処理を行ったときに正しくエラー表示となるかのテストも進めていきます。例えば、JASTPROコードの登録時には英文会社名を入力していただく必要があります。そこで、「英文会社名」という項目には「入力必須、半角英数字、大文字のみで70文字まで」という仕様を決めていました。この場合「文字列を入力しない」「ひらがなを入力してみる」「小文字を混ぜて入力してみる」「71文字入力してみる」といった「正しくない入力」を行って登録を試してみるのです。システムがエラーメッセージを出して利用者に異常を伝え、利用者が入力情報を訂正できる状態に戻れば合格。

このようにして、間違った情報が登録されたりエラーが発生した状態で処理されたりしないように確認するテストを、すべての入力項目やボタン操作に対して行っていきます。これは非常に手間と時間を要する工程ですが、「あらゆる処理にはエラーや例外が発生しうる」ということを前提にシステムを設計する必要があることを、発注者の立場にもかかわらず、身をもって知る良い機会となりました。

不安を拭い去ることはできないものの、このまま進めればどうにかある程度の形には出来るかも知れない。そんな思いを抱えながら、年末年始をはさんでこの工程が続きました。

（次回「百里を行く者は九十を半ばとす」につづく）