CaFeterria

最近、十数年ぶりに要件定義フェーズの重要性を再認識する状況に遭遇しました。

（詳細は割愛しますが、クロージングフェーズで要件の認識相違が発覚）

要件定義フェーズは、操作マニュアルやイメージ図等を使った所謂「紙芝居」で議論が進むケースが多く、認識相違が発生しやすいフェーズと考えています。

紙芝居を見ながら実際に動作しているシステムをイメージできるようにコミュニケーション頻度・密度を上げつつ、様々なモノを活用しながら進めたつもりでしたが、少しだけ足りていなかったなと反省しています。

「準備8割・実行2割」という言葉がありますが、PJの”準備”にあたる要件定義フェーズが非常に重要であることを改めて肝に銘じていきたいと思います。

【投稿担当：C.I.】

例えばデータ連携テストをする際、連携元システム、EAI、連携先システムと、システムごとに担当者を配置する体制がセオリーかなと思います。

しかし、セオリー通りでは上手くいかないこともあります。

私もセオリー通りの体制でデータ連携テストを実施し、なかなか解消されないエラーに四苦八苦する経験をしました。
EAI内のマッピングが複雑化・ブラックボックス化する中、連携元システム担当としてEAIの仕様を深く理解しないままテストを進めた結果、EAI側でエラー発生時に主体的に原因究明できず、EAIチーム任せとなり解決に時間を要してしまったのです。

もし体制として、システムを跨いで横断的な確認を行う担当者がいれば、上記のような苦労は無かったかと思います。

しかし実際はそのような担当者は不在でした。
テストをスムーズに進めるためには、担当システムを飛び越えて仕様理解を深める等、こうした体制の不備を姿勢でカバーしていくことが大切だなと感じました。

※EAI：複数の異なるシステムを連携させ、データやプロセスを統合する仕組み、またはそのツールのこと

【投稿担当：T.O.】

皆さんはユーザが安心して利用できるシステムを構築するには、何が重要だと思いますか。

導入実績、要件定義、セキュリティ・・・色々な観点が挙げられると思いますが、システム開発の最後の砦として、テスト工程が非常に重要であると考えます。

特に10～20年以上利用されている、いわゆるレガシーシステムとの連携が必要となる場合は、仕様がブラックボックス化していることが多く、改修した機能が他の機能に思わぬ影響を及ぼすことや、未知の仕様によって想定外の挙動になることもあります。

そのため、本番同様の検証環境を用意し、開発者の思い込みを排除した網羅的なテストを行うことが最低限必要です。

具体的には、第三者によるテスト仕様書レビューやツールを用いたテスト自動化、また、過去の失敗事例などナレッジの共有を図ることで、テストおよびプロジェクト全体の品質向上に寄与すると考えます。

【投稿担当：T.N.】

近年はITリソースの逼迫に伴い、

システムベンダに提案を依頼しても辞退されるケースが増えています。

私自身、プロジェクトの中でベンダの提案辞退を受け、

候補が限定された状況で選定を行った経験があります。

その経験からベンダに提案を依頼する際は、

「要件を具体化する」

「要件に優先度を付け、優先度が低い要件は代替案を提示する」

「提案前に直接重要な要件とその実装イメージのすり合わせを行う」など

ベンダが正しくプロジェクトのリスクを評価できる情報を伝えることが、

重要だと身をもって認識しました。

【投稿担当：S.K.】

新システムの導入や業務プロセスの再設計を行ううえで、

「現状分析」は不可欠であるとはよく言われることではありますが、

私自身、コンサルティングを通じて、日々その重要性を痛感させられています。

現状分析によって問題点・改善点を網羅的に明確化することは勿論重要です。

しかし、現状分析を通じて組織風土や業界の慣例、業務の複雑性・特異性に繋がる背景を理解することも、また、重要な一面であり、変革への現場の抵抗感など、取り組みの難易度を左右する要素の見極めに繋がります。

こういった側面にも注力しておけば、

より実現性の高いアプローチを選択できたはずだと省みることも少なからずあり、

その度に「未来の成功のために、現在に向き合う時間を惜しむべきではない」と、

自身に言い聞かせています。

【投稿担当：K.T.】