上流フェーズでの対面コミュニケーションを重視 アジャイル宣言の背後にある原則⑧のサムネイル
デジタルテクノロジー

上流フェーズでの対面コミュニケーションを重視 アジャイル宣言の背後にある原則⑧

このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。 

こんにちは、株式会社エル・ティー・エスでITコンサルタントをしている坂口沙織です。「アジャイルアプローチへの挑戦」第8回目の投稿です。

とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って、プロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。

「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」って何?という方は第1回でご紹介していますのでそちらを参照してください。

「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とは①

今回はアジャイル宣言の背後にある原則その6「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」についてです。

情報伝達において対面コミュニケーションが重要、というのはどんなプロジェクト現場でも皆さんが実感されていることかと思います。特にシステム開発の現場では小さな認識齟齬であっても実装後には大きな手戻りとなるため、とにかく粘り強く認識を合わせることが大切です。

実際、実装後の大半のトラブルはコミュニケーション不足に起因するといっても過言ではないように思います(これまで私自身何度も痛い目にあってきました…)。

その経験から、最近は特に上流フェーズ(要件定義、概要設計フェーズ)での対面コミュニケーションを重視しています。

概要設計書もできる限り対面レビューを設定する

要件定義フェーズではユーザーサイドとベンダーサイドでディスカッションを重ねて要件定義書を作成していきます。これはどのプロジェクトでも実施することかと思います。

このプロジェクトでは、難易度が高い場合には概要設計フェーズでも設計書の対面レビューを実施し、設計者に仕様を説明してもらいました。認識違いがあった場合には実装前に修正することができるため、これは非常に有用です。

また要件定義者と設計者が異なる場合、設計者は要件定義書をもとに概要設計を行うのですが、要件定義書には記載されない要件の検討経緯や背景となる業務課題には、設計者に知っておいてほしいものもあります。対面レビューはそうした内容を伝達する機会にもなります。

工数の制約上、書面レビューで終える場合もあるのですが、一人で書面でレビューするとどうしても自分に都合よく読んでしまう部分もあり、異なる解釈の余地があるような記載の場合にはミスコミュニケーションが生まれてしまうこともあります。複数名で対面レビューを実施すると他の人の指摘や質問でユーザサイド全体の仕様への理解が深まることもあり、その意味でも有用です。概要設計書の対面レビューは他のプロジェクトでどの程度行われているのか分かりませんが、あまりやっていないプロジェクトでは取り入れてみても良いかもしれません。

ドキュメントのメンテナンス

対面コミュニケーションは非常に有用なのですが、一方でやはりドキュメントもとても大切です。そこでプロジェクトでのドキュメント管理状況も紹介したいと思います。

「アジャイルって設計書書くの?」といったイメージを持つ方もいるかもしれませんが、このプロジェクトでは必ず設計書を書いて常に最新版にメンテナンスしていました。とにかく頻繁に仕様変更があるので、ユーザサイドにとっては設計書がよりどころで、私は「この仕様どうなってたっけ」と、1日1回は必ず参照している最重要ドキュメントです。システム更改プロジェクトの際、現行システムの仕様書が古い・そもそもないなどの理由で現行調査に苦労するのはあるあるだと思うのですが、このプロジェクトでは初期リリース後に改修を1・2年以上継続した段階でも最新化を保つ努力を継続しています。どーんと入れて終わりのプロジェクトではなく、60%で導入して細く長く開発を続けてきたことで、最新ドキュメントが保たれていることを考えると、仕様のブラックボックス化を防ぐ意味でもこのアプローチの良さを感じます。

苦労した点としてはシステム間インターフェースの設計書が機能単位ではなく、システム単位でドキュメント化されていて(AシステムとBシステムの間の連携10本がすべて1冊)、同時に複数の連携を改修する際に修正対象のドキュメントがかぶってしまい、バージョン管理が難しくなってしまったことがありました。ドキュメントの単位という一見些末な問題ですが、将来にわたっての保守性・管理のしやすさといった観点から検討すべき意外に重要なトピックだと感じました。

もちろん「設計書不要、そんなのアジャイルじゃない」という立場の方もいるかとは思います。いわゆる”アジャイル開発”とは違うかもしれませんが、あくまでもアジャイル的な考え方を適用しているプロジェクトということです。

ちなみにエンドユーザに公開する操作マニュアルもかなり頻繁に更新しています。操作マニュアルは、ただでさえエンドユーザさんからすると読むのが面倒なものです。古い情報が書かれていた時点で「使えない」と認識されて読まれなくなってしまうので、なるべく改修内容を即時反映するようにしています。


第8回はアジャイル宣言の背後にある原則その6「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」について、概要設計書の対面レビューの事例と、ドキュメント管理について紹介しました。

次回はその11「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」について書くつもりです。お楽しみに。


ライター

坂口 沙織(LTS コンサルタント)

基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター(CSM)。(2021年6月時点)