ベテランのシステムエンジニアでもユーザの心を掴むパワーポイントがつくれない理由

プレゼンテーションの意図に合わせたスライドを作ることは仕事上良くあるものです。身近なところではプロジェクトの仕様検討とか、結果の報告とか。管理資料でも現時点でのシステムの品質状況やコストの執行状況など色々な場面にあります。

組織の中でもプロジェクトで経験したノウハウは貴重な資産になりますから、それを知らしめるためにスライドを作り、プレゼンすることも良くあります。成果発表もこれに近いでしょうか。

様々に作られるスライドも目的とその意図に合わせた表現が単純、つまり、誰が作っても大体同じ様な形になるならスライドを作ることにそれほど労力もチェックに掛ける時間も少なくて済みます。予算執行状況のような資料であれば、案件と補足情報と予算の予実と見通しのようなものがあれば空振りすることはありません。

一方、ノウハウや成果発表のようなものの場合、意外と簡単そうに見えますがそんなことはなかったりするものです。


ベテランにスライドを作って欲しい期待の裏には
ベテランになればなるほど、後進育成とgivebackがマネジメントから要求されるものです。自分の仕事もして、人も育てる。それがベテランが若手より高い給与をもらえる理由の一つです。

成果発表のように経験をスライドでプレゼンテーションさせるには、3つのケースがあります。一つは本当に経験を汎化させてノウハウとして普及させたい。二つ目は、フィージビリティスタディのように組織の中でも先行して実証したことを組織の中に展開したい。三つ目は、発表者の訓練。

一つ目の目標のときが難しい。ここでのスライドの目標は、自分の経験から得られた効果を組織として展開したいというマネジメントの強い要求も含まれます。このような要求下であっても、そのベテランにスライドを作らせるとやっぱりシステムエンジニア魂が燃えるのか手順書のように作ってしまう。

二つ目の目的を言い換えると、自分の経験から得られた効果が有効、つまり、コストダウンの効果があるとか、コミュニケーション上の抜け漏れを防止できることからの手戻作業を防止できるようなムダな作業の排除など日常業務の効率化ひいては固定コストの削減という費用効果を狙えるんじゃないか、という期待です。


スライドの目的>自分の気持ち
そこまで深読みしなくても、それでも組織の中で先行してその実証実験の結果に期待が持てるのであれば、それは、その観点だけしか目的を知らなくても最低限の目的は知ったうえでスライドを作れるのです。

例えば、tracのようなチケット管理と構成管理ツールとwikiというナレッジポータルをプロジェクトなどで実際使ってみてプロジェクトの中の意思疎通がそれまでのexcelWBS、ファイルサーバ、課題管理台帳とそれぞれ比べたら、やっぱりexcelなんて必要最小限に減らして、tracで一元管理したうえで、必要な情報をワンストップでメンテナンスした方が楽チンでコミュニケーションでのメリットも効果が大きいとしたときのスライドをどう作ればいいか。


書き手の気持ちを目的に混入させるな
ベテランのエンジニアでもやりがちな間違いは、目的以上に自分の気持ちを優先させてしまうことです。目的は“普及”であるなら、使ってみようという見込み客を“捕まえる”とか、使おうという“信者”を作ることです。

どのライフハックのブログや書き方指南の本であっても最初に出てくることは“目的をはっきりしろ”となっていますが、大体そのいう意味が伝わりにくい。書き方を知ろうとする方は、書きたい気持ちが先走っているからすでに何かあぁしなさい、こうしなさいと書いてあってそのとおり目的を据えたつもりでも、そこに現れない逸る気持ちが目的を知らずに超えてしまう。


スライドを見せて成功体験を疑似的に与えよ
信者を増やすスライドにツールの操作手順は要るでしょうか。答えは単純です。手順が必要になるのは“いつからかだろう?”と問えばわかります。今作っているスライドは、その前のシーンのスライドです。スライドの読み手に疑似的に成功体験を与えるのです。

(...スライドを作るエンジニアのみなさん聞こえますか...今、...あなたの心に...声を...直接届けています...。あなたが...作る...スライドは...手順書ではありません...。スライドに...画面や項目説明は...要りません...。今...必要なのは...読み手が...疑似的に...成功体験を得られる...スライドです...。...聞こえますか...。)


訴えたいこともなぜなぜで本質を掴んでから
なんでベテランのエンジニアでさえも作るスライドが手順書になってしまうのか。それはたった一つのことをしていないからです。

スライドの目的が信者の獲得なら、なぜ自分自身がそれを使ってよかったと感じたか、自分がそのツールを使って成し遂げたかった要件がどのように充足されたか“なんでかなー”と純粋に掘り下げよ。


たったこれだけす。

自分がプロジェクトマネージャをしていて、excelでのWBS管理にはexcelファイル自体の構成管理=ファイルの版管理が必要でそれ自体が面倒だし、そのexcelを配り、プロジェクトメンバにメンテさせて回収し一元管理するとなるとどこにどうメンテナンスされているかわからない状態になってとてもハンドリングも煩雑になることを解消したと思っていたとします。
偶然にもtracでできると知って、その知見者もいて、実際にtracの機能を一つ一つ時期を追って試行錯誤しながら使ってみたら実はWBSをチケットに置き換えたとき、excelWBS管理のファイルとファイル管理の作業から解放され、その結果、削減できた時間をプロジェクトのメンバとのコミュニケーションに回せたことがプロジェクトマネージャとして「うれしかった」が自分の成功体験なら、それをスライドの大きなテーマにした方が読み手は疑似的にあなたの成功を追体験できるのでより共感が得られでしょう。

端的には、例のプロジェクトマネージャとしての課題をtracを使って解決した、ですが、それは表面的な話であって、それより2つも3つもなんで?をやって、プロジェクトマネージャとして得られた喜びからアプローチするのです。

Q プロジェクトマネージャの仕事は多用多量で本来プロジェクトを成功裏に導くための時間が割けない。どこで時間が割けないのはなんでかなー。
 →プロジェクトマネージャの業務を書き出して見える化しよう。
  あれ、管理資料の更新と管理作業が多い。
Q なんで管理資料の更新と管理作業が多いのかなー。
 →WBSを作って、配って、戻して、チェックして、進捗状況を聞いて、以下ループ。
Q なんでそんなにIOが多いのかなー。減らせないのかなー。
 →ファイルサーバに置いてメンバで更新する?
  でもそれ、二重更新時煩雑になるし。
Q でもsbversionならファイルは一つになるねー。それでも何が問題になるかなー。
 →所詮excelなのだから、幾らでも中身が変わっちゃう。行列を勝手に変えられるのも困る。
  でも各メンバは自分のWBSは更新してほしい。
Q ならチケットあるけどなー。
 →チケット使うとフォームは一つで固定だな。
  メンバは自分で自分のWBSを更新できるな。
  ビューでWBSを一覧表示できるな。
  :

と言うことは、スライドの中身は解消したい課題と解決して得られた経験に置き換わりますが、そのスライドのタイトルからして変わってくるのです。
 × tracのプロジェクト管理適用事例
 ○ いかにしてプロジェクトマネジメントの時間を捻り出したか