DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

こんにちは。
引き続き、若手のみなさんとOJTの中で一緒に取り組んだことをご紹介します。
今回は、「わかりやすい」報告書作成を目指した取り組みです。

「わかりにくい」とよく言われるケース
あるシステム開発の部門では、顧客から資料の内容が「わかりにくい」と、不評を買うことが何度かありました。
「わかりにくい」という不評にはいくつかのパターンがあるのですが、以下のような２つのケースがよく見受けられました。

１． 提案書において
ITの専門用語が多すぎて、意味がわからない
２． システム障害報告書において
事実（根拠）が不明瞭で、この結果（結論）になった経緯（理由）がわからない

１のケースは、皆さんにいちばん心当たりがあるケースかと思います。普段使い慣れている用語ほど、専門用語だということを忘れがちです。ITの専門家ではない相手には、内容のレベルは高いけれど易しく読めるよう、平易な文章でレベルは下げない必要があります。

２のケースは、事実の説明が不足していたり、説明が論理的でなかったりします。原因が単なる事実でしかない、真因は他にもありそうだ、この対策を打っても問題が解決すると思えない、など読み手は違和感を覚える状態です。

今回は２のケースについて、若手と一緒に改善したことをご紹介します。
文章そのものの表現だけに終始せず、システム障害の問題の原因から対策を、論理的にどう考えて導くのかということに焦点をあてました。

ロジックツリーで論理を構造化して可視化する
若手の方に、今回の障害報告書のケースについて、問題から原因を分析して対策までをどのように考えたのか、私の目の前でロジックツリーに組み立てて書き出してもらうことになりました。
ロジックツリーとは、論理的なつながりをツリー状に図示するものです。箱を線でつないで表現します。
一番左側に問題をひとつ記述して、そこから右へ枝わかれして原因が広がり、枝を伸ばして原因を深め、右端の枝の末端のいくつかには対策を書いてもらうようにしました。

若手がホワイトボードへ、思いつきでツリーの枝数を増やし、のびのびと枝を伸ばして描く傍らで、私は、いくつかの確認を投げかけました。

・その分岐は、何の切り口で考えましたか
・その切り口で、抜け漏れが無い分岐になっていますか
・枝の伸びは、論理が飛んでいませんか
・枝を逆から読んでいくと論理が成り立ちますか
・表現が変化しているだけで原因が深くなっていないのではありませんか

自らの考え方の癖を知る
このように構造化して整理することで、若手は、いつも頭の中で考えて文章にしてきたことが、いかにあいまいだったのか気づけます。

・広く考えて対策を出したつもりだったが、狭い範囲の分析しかしていないことがわかった
・論理が飛躍しているところは、自分の思い込みがあった
・システムのユーザーにとって意味のある対策ではなく、自分だけの範囲でできる対策にしかなっていなかった

あらためて構造的に書き出すことで論理が可視化されて、第三者の私にも論理展開が適切かどうか判断できるし、ご本人にとっても自分の考え方の癖がわかり、今後にも生かされるのです。

問題と真因と対策の関係を確かめる
そして、どこの原因に手を打てば問題が解決するか、ロジックツリーの右端の原因から左へ向かってひとつずつ確かめていきました。すると、末端の原因ではなく、ひとつかふたつ左へ遡った、その原因に手を打つと問題が解決する、というところがありました。

私は若手の方に、
・今回のシステム障害は、そこが真因であり、対策の直前にある箱が真因ではないこと
・ロジックツリー上の原因分析はここまでであること
・それ以降の右への枝は、対策を具体化するにあたって、いかに効果のある対策を選ぶかという分析に入っていること
を説明しました。
今回の報告書は、問題と真因と対策の関係が論理的でなかったので、読み手にとって、違和感を覚えることになってしまっていたのでした。

わかりやすい報告書を目指して
読み手にとって報告書の内容に違和感のある時、報告を書く本人が論点をうまくまとめられないとき、論理展開を簡単にでも構造化して可視化する習慣をつけるといいと思います。
その一手段として、ロジックツリーの活用をお奨めします。

響子さんプロフィール

響子さん
部署名：コンサルティング本部
入社年：2006年

独立系ソフトハウスで、中小企業向けのアプリ開発や、病院向けシステムのカスタマイズに従事。その後、コールセンターでユーザーのサポートに着任。2006年より現職。
プロジェクトマネジメント標準策定、大規模プロジェクトのマネジメント支援、IT組織の戦略策定支援、IT人材育成支援に従事。