上司や顧客へ丁寧に説明しようと思うあまり、長々と話しすぎてはいないだろうか。丁寧な説明と長い説明は、必ずしもイコールではない。むしろ長すぎる説明は相手の不興を買う元だ。相手の納得を得つつ簡潔に説明するには、開発生産性を高める「プロトタイピング」と、ものごとの概要を抜き出す「抽象化」のスキルを身に着けよう。
「岸井、仕事でうまくいってないのか？」
経営戦略室の西部和彦は、休憩室で情報システム部の岸井雄介に言った。
「西部さん、失礼なことを言わないで下さいよ。うまくやっていますよ」
「本当か？心当たりはないのか？」
「まあちょっとは…。もしかして部長代理ですか？」
「そのとおり、黒瀬さんだよ。黒瀬部長代理が、岸井は話が長いって不満そうなんだ」
＊ ＊ ＊
岸井雄介は35歳、西日本にある地方銀行A銀行の情報システム部で、課長補佐を務めている。入行以来、情報システム部でシステム開発を担当し、システムの設計、プログラム製作、テスト、移行などの仕事を担当。最近、システム企画の部署に異動した。
西部和彦は37歳、A行でシステム企画の仕事を長く担当し、多くの仕事を成功させてきたエース人材で、岸井の大学の先輩でもある。出向していたITコンサルティング会社から経営戦略室に課長補佐として復帰している。
岸井の現在の仕事は、システム開発の品質向上である。A行では預金、為替、融資といった基幹システムに加え、顧客情報管理、ダイレクトマーケティングといった情報系のシステムを保持し、A行の内部エンジニアによる内部開発をしている。
A行では最近システムトラブルが多くなっており、顧客に影響を与える事態がたびたび発生していた。トラブルの原因や傾向の分析と再発防止策を検討することになり、情報システムの黒瀬部長代理とシステム企画課の岸井が担当となった。
「その説明、まだ続くの？」
岸井は早速システム開発部門にヒアリングし、品質状況の分かる資料も読み込んだ。岸井は入行以来システム開発を長い間担当していたため、このあたりの知識は豊富である。一通り内容を理解すると、黒瀬部長代理に説明した。
＊ ＊ ＊
「当行ではこの2年間でシステムトラブルが5倍になっています。内訳は、要件定義工程が4割、設計工程が3割、製作工程が3割です。ちなみに、当行の要件定義はひな形があり、それに従ってユーザーからヒアリングをして要件を埋めるようにしています。これは私がシステム開発していたころに提案した制度です。
そもそも、当時はユーザー側に業務知識がない人が多く、要件定義の品質が悪いという状況でした。だから、私は原因を分析して、要件定義のやり方を根本的に見直す必要があると思ったんです」
「岸井、それは前の話だよね？今回の品質悪化も関係するのか？」
「いえ、違います。今回の結論は、設計レビューのやり方に問題があるのではないかと。現在の設計レビューのやり方は、開発担当者が設計内容を関係者に説明しますが、必要機能を一通り説明し、指摘を受けた内容を記録していないんです。
なぜ、記録しないのかはこれから詳細に分析しますが、指摘を記録しないことで、指摘事項の管理が甘くなっているようです。したがって、指摘事項の影響範囲の把握や修正が漏れて製作工程に進み、品質が悪くなっているように思えます。
本来、設計内容の不具合を指摘されたら、その箇所だけでなく、それによって引き起こされる影響も問題がないように修正する必要がありますが、現状ではそれが行われておらず漏らしてしまい、システムトラブルにつながっているということです。
対策としては、レビュー管理を厳密にして、指摘事項を管理して、誰が指摘したのか、それに対して、どんなアクションをとったのか、影響個所はどこか、いつ調査が終わったのか、誰が承認したのかを管理する運営が必要だと思っています」
「…岸井君、まだ続くの？」
「はい。そもそも、なぜ、レビューがそのような運営になっているかも説明する必要があります」
「うーん、君の言ってることは正しいとは思うよ。でも、説明が長いよな」
「それは意外です。これでも短くしているつもりです。この件はもっと丁寧に説明する必要があると思っていたのですが…」
「いや、今で十分長いよ。もっと短く端的に説明するのがビジネスの基本だと思うよ」
「部長代理、そうおっしゃいますが、今回のシステム品質の問題は根が深く、中身が濃いのでもっとじっくり説明が必要ですけど…」
「あのなあ、岸井、君の説明は長いよ。それでは上の人との仕事はうまくいかない。我々は決められた時間で成果を出す必要がある。限られた時間で説明して理解してもらう必要があるんだ。短く説明する方法を学んでから相談に来なさい」
＊ ＊ ＊
