JASTPRO DXの道 第7話「コード管理システム刷新プロジェクト（3）百里を行く者は九十を半ばとす」

【初出：月刊JASTPRO 2022年7月号（第518号）】

年が明け2022年。本プロジェクトも要件定義→プログラミング→テストという過程をどうにかこなしてきました。ここからは、プログラミングやテストだけではない、リリースに向けて怒涛のように押し寄せてきたタスクを紹介しつつ、リリースまでの足跡を振り返ってみます。

ユーザー受入試験

まずは、当協会コード部職員によるユーザー受入試験の実施です。この試験は、ここまで行ってきたシステム観点からの仕様確認・不具合検出のためのテストとは異なり、実際の業務を滞りなく進められるかを実際のシステム利用者の視点から判断するものです。

今回のシステム刷新は、ただシステムを新しくするだけではなく、業務プロセス自体を抜本的に改める機会でもありました。具体的に言うと、これまではいくつかの担当分野に別れた分業制、いわゆる「縦割り」であった業務を再構成し、段階的に作業を完了させていくというワークフローの構成に改めました。これによって「〇〇の仕事は□□さんしかできない」という状況を解消することができるわけです。業務プロセス改善という観点から言えば「属人化の解消」です。

また、この受入試験は新しいシステムを使った新しい仕事の進め方に対応するための習熟訓練も兼ねて行うこととしていました。こういった業務プロセス改善は、システム設計を行う側としては野心的でやりがいのある試みですが、実際にシステムを使うユーザーからすると日々の仕事のやり方が大きく変わりますので、とまどいや不慣れによる生産性の低下が（特にシステム導入初期には）起こりがちです。その生産性の低下を出来る限り少なくするため、本番リリース前にある程度システムを触ってもらって慣れてもらうわけです。

そのため、システム利用者用の説明書を用意して操作デモを交えた説明会を実施し、随時質問を受けつける体制を作ります。良くないプロジェクトの典型例どおり素材に使えるドキュメントが絶望的に少ないので、この説明書もほぼ一から作ることに。文字だけで説明してもわかりづらいので、画面イメージを取得してサイズを整えて矢印や枠線で説明文と上手に紐づけて・・・という説明書づくりを進めていきます。

他にも問題があります。例えば、これまで紙ベースの作業のほとんどをシステム上でのオンライン作業としたため、今まで以上に画面に向かう時間が増えます。そのため、これまでよりも大きなディスプレイを用意する必要があります。これは当初からの想定通りではありますが、システムの移行までは旧システムとの同時利用になるため、作業スペースが窮屈になってしまいます。移行が完了してしまえば、旧システム用の専用端末やたくさんの書類が不要になり、すっきりするのですが・・・。

さらに、日常業務に加えて新しいシステムを触るというのは、ユーザーにとってはこちらが考える以上に業務上の負担が増えます。リソースが充分なプロジェクトであれば、受入試験を担当するユーザーの通常業務量を減らすという手段を取れる場合もありますが、今回はそこまでの人的リソースの余裕がありません。ユーザー受入テストはこういった要素が重なり、いくつかの重要なフィードバックを通じた不具合の発見や使い勝手の改善を行ったものの、充分と言えるまでの検証を行いきるには至りませんでした。

実は完了しきっていないシステムテスト

本来であれば、製造サイドで品質確認工程（仕様通りに動くか）が完了したシステムをユーザー受入試験に回す、というのが正しいやり方です。特に、それぞれを行うプレイヤーが異なる場合はそうしないと責任問題にもなりかねません。ただ、今回はスケジュールが厳しいことと、JASTPROコード利用者が利用する部分を除けば当協会内部で調整ができること。この2点から、ある程度工程を重ねて同時進行させることにしました。

これが何を意味するのかと言えば、K部長と筆者はこれまでの「想定した仕様通り、あるいは想定外の処理に対してシステムが正しく動く」「不具合を開発業者に伝えて修正してもらい、修正後も検証する」という作業に加え、「ユーザーに対するシステムの習熟訓練を進めながら、受入試験で得られたフィードバック内容もシステムテストに組み込んで一緒に片づける」という作業も行う事になります。予想通りではあるものの年末よりもさらに忙しくなってしまいました。K部長と筆者の体力に依存するやり方であり、決して好ましい手法ではありませんが、背に腹は代えられないということで濃い目に入れたコーヒーを片手にどうにか日々こなしていきます。しかしながら、ユーザー受入試験同様この時点で満足できるまで徹底的にやり切れたかというと、筆者としては悔いが残る過程でした。

保守サポート契約

このプロジェクトに限らず、システムは「作って終わり」ではありません。リリース後、実際の運用で不具合が発覚することがあります。また、システムが動くデータベースソフトや基盤となるオペレーティングシステム（OS）、それを動かすクラウド環境になんらかの不具合が起きることもあります。時間的な制約から諦めた機能や、今後必要となってくる新しい機能を追加開発することも良くある話。こういった変化に対応するため、日々新しい機能をリリースし続けるという継続的開発という手法も広まってきています。

そういった「継続的開発」までは実現できなくとも、最低限システムの健康を保ち続ける保守運用とサポートは欠かせません。そのため、保守サポート契約を結んだ業者と良好な関係を築きながら日々システムを育てていく・・・それが理想。このプロジェクトにおいても、保守サポート契約についてはずいぶん早い段階から、それこそ筆者が入職する前から課題として挙げられており、最初のスケジュール表からタスクとしてずっと記載されていました。ただ残念なことに、ここまでご紹介の通り実際のシステム開発・製造を優先し続けてきたため、この時点ではほとんど手つかずの状態でした。

とはいえ、いつまでも手つかずでは話が進みません。システムのテストや修正と並行して保守サポート契約の準備を開発業者と一緒に進めていきます。まずは核となる要素を列挙して契約書の骨組みを作成。開発業者側の手間を最小化するため、骨組みをもとに保守サポート契約に必要な情報の肉付け作業をこちらで実施することにしました。

具体的には、契約書のひな形も活用して各要素を条文として整理し、体裁を整えるという作業です。開発業者と当協会の双方ともリソースは限られているので、どちらかだけに負荷が掛かりすぎないように注意を払いながら、お互いが守るべき責務をしっかりと文面に落とし込みます。その後法務チェックを行って相互レビューを実施。どうにかリリースまでに契約締結にこぎつけたのでした。

システム連携トラブル

こんなこともありました。新しいシステムは、これまで手作業で行っていたことを出来る限り自動化する設計になっています。そのために必要な機能を、とある外部サービスとの接続によって実現しています。テスト中は、その外部サービス業者が提供するテスト環境への接続を行うことで機能の検証を行っており、特に問題なく動作していました。

本番リリースを迎えるにあたり、こちらのシステムと外部サービスの本番システムを接続することになります。ところが、ここで当協会と外部サービス提供業者とのやり取りのさなか、外部サービスの本番システム利用開始日が本番リリース日に間に合わないという事実が発覚。

よく話を聞いてみると、「サービス開始日」という言葉に誤解があり、当協会は「リリース前に本番システム同士で接続して開通試験をしたいから、外部サービスの利用開始日は当協会システムリリースよりも前の日付」をリクエストしていたにも関わらず、先方は「当協会のシステムリリース日＝外部サービスの利用開始日」として案内してきていたのでした。これだと、事前テストもできないうえに、当日に接続と検証を行わなくてはならなくなり、もし不具合が起きてしまえば大混乱に陥ることは必至。ということでこの外部提供サービス業者との調整が発生し・・・この件は、どうにか1日前に開通させて検証を行うことができましたが、双方が同じ理解をして事を進めるという当たり前のことができないと事故につながる、という恐ろしさを実感する出来事でした。

道半ば

そして3月。新システムのリリースを目前に迎えました。リリース日に焦点を合わせ、前後数日の細かい時間割やリリース直後のチェックリストを用意。旧システムからのデータ移行についても、リハーサルを行って動作確認を実施。不安を抱えつつも、リリースを遅らせないといけない事態にはならなそうです。

3月半ばに行われたリリース直前の定例ミーティングは、ずいぶん大変だった道のりを振り返って「いやぁ大変でしたけど、ようやくここまで来ましたね」「ひと段落したら打ち上げでもしましょうか」といった雰囲気だったことをよく覚えています。

しかし、そんな中で筆者だけが一人殺伐としたオーラを出し続けていました。確かに、このプロジェクトは当初から問題山積で、発注側も受注側もずいぶん大変な苦労をしてきました。ただ、ここで一仕事終えたような平和な雰囲気になってしまうとマズいのです。空気の読めない奴という誹りを受けることも覚悟のうえで「まだそういうのは早いです」と発言。温まりそうになった会議の温度を一気に引き下げました。

システム開発プロジェクトにおけるリリース日は、百里の中の九十に見えるかもしれませんが、実は「道半ば」です。リリース後にも間違いなく問題が発生するからです。システムが止まってしまったり重要な情報が欠落・漏洩したりすることはないにしても、後から見ると「なんで気づかなかったのだろう」という仕様の漏れや、「（出来ないはずの操作が、システムでの制御をし損ねた結果）そういう操作もできてしまうよね」といった不具合は必ず発生するのです。そして、開発期間中とは異なり実際の運用を行いながらお客様への影響を最小限に抑える必要があるため、対応の難易度はぐっと上昇します。

気が緩んだ状態で発生する不具合は精神的に受けるダメージが桁違いです。だからこそ用心するに越したことはないという気持ちを今しばらく持ち続ける必要があります。そういった意図から出た発言であることを、会議が終わってから関係者に伝えて理解を求めました。

エピローグ

果たして、新しいコード管理システムは2022年3月14日に無事リリースを迎えました。予想通り（？）いくつかの不具合が発生してその対応にはずいぶん苦労したものの、毎日（徹夜まではせず）終電までに帰宅できるレベルではあったので、巷で聞くような炎上プロジェクトと比べればずいぶんマシだったのかも知れません。

そして、システム刷新は当協会コード事業において効果てき面でした。しばらくは不具合対応に加えて旧申請様式による申込み（紙申請）の登録作業とのダブルワークによってコード部門の残業時間が増えてしまいましたが、落ち着いてからは対応スタッフの人数を減少させながらもコード管理業務を適時に行えるようになっています。自動処理やペーパーレス化によって作業を効率化できただけでなく、専用端末や専用ネットワーク環境の撤廃によって作業スペースの自由度も向上しました。

加えて、JASTPROコードの手続きをほぼ全てオンライン化したことで利用者からの問い合わせ内容にも少し変化が見られました。利用者の中にはこれまで紙ベースの申請を続けてきた方もおられるので、オンラインシステムを利用いただくためにこちらから操作手順や利用環境に対する説明を行う機会が増えました。そこで、利用者への説明をしっかり行うためコード部門においてもシステムの操作だけでなく、そのベースとなる情報技術やデジタルに関する知識を学び、それを問い合わせ対応に生かそうという気運が生まれています。

問合せといえば、こんなエピソードも。システム刷新と並行して、当協会ホームページのコードに関するよくあるご質問（FAQ）を、これまでの問合せ内容を参考に全面更新したのですが、FAQ掲載済みの事項についても問い合わせが多数発生したのです。そこで、利用者にお送りする登録期限更新案内のハガキに掲載しているQRコードの内容見直しに着手。最初は更新手続きページに加えてFAQページを掲載してみたのですが、状況は変わらず。そこで、思い切って更新手続きページへの直接リンクを削除して手続案内のページに変更してみたところ、問い合わせが激減。登山と同じで、最短ルートだけど険しい道よりも、回り道でも登りやすいルートをしっかり案内することが大事であると学んだのでした。

今回のシステム刷新によって、当協会コード事業のデジタル化を始めることができました。今後JASTPROコードに新しい価値を創りだし、それを核とした当協会全体のデジタル変革を進めていくための基盤づくり。その意味では、このシステム刷新プロジェクトを通じて当協会のデジタル変革は「道半ば」を迎えたと言えるのかも知れません。（つづく）