CaFeterria

最近、プロジェクトで「言った言わない」や誰の責任なのかという課題解決に直接関係ない話に時間を使われてしまう場面に遭遇しました。

従来のウォーターフォール型のシステム開発プロジェクトでは、

前工程までの意思決定が重視されるため、過去の経緯を振り返るプロセスが挟まり、

問題解決の意思決定までに時間が掛かっていました。

しかし、昨今のプロジェクトでは物事を迅速に前へ進めるスピード感が求められていると感じています。

特に海外のメンバが主導するグローバルプロジェクトでは、その傾向が強いと感じており、

私が経験したSAPロールインプロジェクトでは、

問題が発生すると海外メンバが即座に関係者と打ち合わせを設け、

取るべき対応を重点的に議論していたことが印象的でした。

基幹システムなど大規模なシステムであれば、

開発手法としてのウォーターフォール型は有効なアプローチではありますが、

長期間のプロジェクトの途中で、状況を一変する出来事が起こることは珍しくないため、

プロジェクトメンバには、そのような事態に柔軟に対応できるアジャイル的思考が必要だと感じています。

【投稿担当：K.Y.】

私はグループ各社に対し、共通会計システムの導入と業務プロセスの標準化を行うPJで、ユーザ側の各種検討を支援しています。

この“標準化”とは言うは易く行うは難しであり、実現に向けては大小様々な課題や衝突があります。

それらの解決に際し、私が心がけているのは、頭ごなしに方針を押し付けるのではなく、関係者にしっかりと納得してもらうことです。

業務プロセスを標準化することで、とある会社の業務が複雑化してしまうようなケースでは、（当たり前ではありますが） 現場担当者から反発がありました。
その際、“PJ方針だから“と推し進めることもできましたが、今後もPJを円滑に進めるためには、ここでしこりを残さない方が良いと考え、親・子会社双方の役員も交えた検討の場を設けました。
その結果、関係者間でPJ方針を再確認した上で、個社の事情を踏まえた現実的な落としどころ（ToBe業務）を見つけられ、今に至るまで大きな問題無くPJを推進できています。
今後も各社の事情にも配慮しつつ、グループ全体として最適な結論へ導けるよう、支援していきたいと思います。

【投稿担当：H.Y.】

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

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

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

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

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

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

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

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

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

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

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

【投稿担当：Y.N.】

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

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

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

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

【投稿担当：G.F.】

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

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

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

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

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

【投稿担当：C.I.】

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

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

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

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

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

【投稿担当：T.N.】