短納期開発ゆえの障害多発・仕様変更遅延している状況での参画

案件管理システムを半年の開発期間でサービスインさせており、短納期であるがゆえに、仕様が詰め切れていない部分があり、障害多発の原因となっていました。

そんな中、中期経営計画に基づき、大規模仕様変更が必要な状況でした。

大規模仕様変更の要件定義を行っているタイミングで、情シス側PMOメンバが3か月後に退場することが確定し、PMOメンバの交代要員として参画しました。

参画後初めて参加した「情シス－ベンダ間仕様変更検討会議」にて、ベンダ、情シスともに要求仕様だけでなく、「システムの根幹仕様」さえも正確に理解できていない状況を目の当たりにしました。

このため、「システムの根幹仕様」を、ユーザ・情シス・ベンダの三者が共通で理解できる資料を作成し、共通認識を持つことが安定稼働に最優先であると考えました。

情シス・ベンダともに仕様を理解していない？

システム開発時の要求仕様資料は、集計表に数式が埋めてあるもののみであり、ユーザの一部担当者のみ理解しているものでした。ベンダはその数式と同じ結果になるように各種項目の編集定義を決めていました。

つまり、各項目の意味づけやあるべき姿を理解しないままシステムが構築されていたのです。

このため、仕様検討会議でも、ベンダに対して、この項目はどういう項目か？なぜこの数式なになっているのか？等の質問をしても、あいまいな答えになってしまう。

また、情シスもベンダからの質問に答えられない状態のため、仕様の確定に時間を要していました。

仕様変更の検討作業の中断。根幹仕様についてユーザ・情シス・ベンダの三者が共通理解できる資料の作成を最優先課題とした

仕様変更の検討を一度中断してでも、システムの根幹にかかわる「案件の構成と各項目の意味、編集仕様」を整理し、「ユーザ・情シス・ベンダの三者間で仕様を共通理解できる資料」を作成することを最優先課題としました。

では、ユーザ・情シス・ベンダの三者間で共通理解できる資料は、どんなものか？

・ユーザの直感へ訴えるよう図でデータ構成を表現する。
・主要な各項目について、項目の説明を追加。
・ユーザが理解しやすいよう編集仕様を日本語で表現する。

これら３点を意識して、ベンダに資料を整理させました。
これにより、集計表の数式に隠れた不明確な仕様をあぶりだすことができました。

情シスは本資料をレビューし、不明点をユーザ確認していくことで、仕様の理解が促進されました。ユーザも、図で表現され、項目説明が追加されたことで、担当者間の理解度レベルの差が少なくなりました。

仕様変更の検討作業の再開。検討会議の時間が約半分に

ユーザ・情シス・ベンダ間で仕様変更後のあるべき姿の認識合わせが容易に行えるようになったことで、仕様変更箇所が非常にわかりやすくなり、要件確定までの時間が大幅に減りました。

また、要件の取りこぼしが少なくなり、リリース後の不具合発生件数も大幅に削減されました。

このため、仕様変更検討を中断したにも関わらず、大規模仕様変更はリリース遅延なくリリースされました。作成した資料を基に不具合改修と仕様変更を順調にこなしていき、年度が明けることまでには、不具合がほぼ発生しない超安定稼働システムへ変貌を遂げていました。

翌年度にはベンダ－情シス間、ユーザ－情シス間の打合せ時間も半分に減らすことができました。

これにより、顧客からの高い信頼を得ることができ、維持管理担当の中心メンバとして稼働し、ミクレニティ枠の拡大に成功しています。