CaFeterria

多くのプロジェクトは複数チームで体制が構築されており、チーム横断の適切なコミュニケーションが重要となります。

チーム横断で検討が必要な事柄について、チーム間のコミュニケーションが不十分な場合、

後々他チームから「その話は認識できていなかった。その検討結果は許容できない。」と

自チームで一度検討が完了したことを再検討しなくてはいけないことがあります。

このような手戻りを防ぐためにも、検討時には「チーム内で検討を留めてよいか」

または「他チームとの認識合わせが必要なのか？またそのチームはどこか？」を都度考える必要があります。

また、チーム横断の課題は管理主体チームが曖昧なことが多いため、対応を漏らさないためにも、

管理主体チームを明確にしたうえで、横断課題としての管理が必要となります。

私はしばしば自身の視野の狭さを痛感することがあります。

そのため、チームを横断した適切なコミュニケーションを常に意識しなければならないと、

強く思っている今日この頃です。

【投稿担当：Y.N.】

私が参画しているプロジェクトでは、基幹システムはアジャイル型とウォーターフォール型を組み合わせたハイブリッド型、周辺システムはウォーターフォール型で開発している。

このように開発手法の異なるシステム間のインターフェース開発を行う場合、基幹システムと周辺システム間の積極的なコミュニケーションによってマイルストーンを同期したうえでスケジュールの調整を図り、自システムの開発を遅延させないよう対応することが重要になると考える。

私が担当する人事システムとの連携では、基幹システム側の要件検討が遅延しており、開発遅延リスクを抱えていた。
そこで、基幹システム側には、人事システムとして要件確定が必要な時期を提示し、その期限内に要件が確定できないか調整しつつ、人事システム側とは、基幹システム側からの要件に依存しない機能を先行して開発する方向で対応した。

両システムの間に立つ調整役として、今後も双方の進め方や作業内容を理解し、密にコミュニケーションを取りながら進めていく所存である。

【投稿担当：G.F.】

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

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

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

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

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

【投稿担当：C.I.】

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

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

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

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

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

【投稿担当：T.N.】