機械的に良い感じの資料が作成できるアジャイル資料作成術
はじめに
エンジニアのみなさん、資料作成でお悩みではないでしょうか？
本を読んでパワポのデザインを作ったはいいものの内容が上司の想定するものと大きく違っていてなく最後にちゃぶ台返しにあったり、書籍の内容が抽象的すぎてうまく実践に落とし込めなかったりしないでしょうか？
正直、私は苦しみました。「エンジニアは技術力が命で資料作成なんてサブスキルだ。」と思いフラストレーションを溜めながら資料を作成しては上司からダメ出しをくらい続け、場合によっては資料作成に時間がかかりすぎて技術に触れる時間が削られることもありました。今考えるととてももったいなかったです。
今回はそういう私が苦しみながら会得した方法を紹介したいと思います。この方法で資料作成を効率化して技術に触れる時間を増やしましょう。
この資料作成術は「アジャイル資料作成術」と銘打ってます。これからその中のまず「資料作成術」について説明を行い、次に「アジャイル」について説明したいと思います。
資料作成術について
概要
ここからはまずベースとなる資料作成の方法について説明します。
資料作成は資料自体をプロダクトととらえるならソフトウェア開発と相通じるところがあります。よくある失敗例としてパワポをまず書き始めたところ、思いのほか熱中してしまい多大な時間を溶かした(あとに成果物を上司に見せたところ目指すところが思いっきりズレていて特大の手戻りとなる)というものがあります。これはソフトウェア開発でいうところのとりあえず闇雲に動くコードを書いた場合と似たところがあります。これは避けましょう。
ソフトウェア開発(特にウォーターフォール)に工程の概念があるのと同様に資料作成も段階にわけることができます。
まず資料の建付けを決める要件定義に相当する部分があり、その次に目次を決める設計に相当する部分があり、最後にパワポの作成という実装工程があります。
それぞれについて機械的に行うことができる方法を説明したいと思います。
ちなみにツールに関しては何を使ってもいいですが、私個人としてはマインドマップ(XMind)を使うことによって直感的に作業を進めることができるので、これからはマインドマップを使う前提で説明します。
コンセプト決め(要件定義)
ここが一番大切です。この部分の出来が資料作成の成否を決めると言って過言ではありません。
ここでは資料の建付けを「目的」「成果物」「成功基準」に分解して考えます。
この「目的」「成果物」「成功基準」には元ネタがありまして、ODSCというプロマネのフレームワークです。
原典では「目的」「成果物」「成功基準」を決めたうえでステークホルダーと議論して認識のずれを避けますが、資料作成でも同様です。
コツとしては上記のように平板に書くだけでなくもう一段、内容を具体化することです。
例えば目的の部分にさらっと「資料作成が苦手な人でも簡単に資料作成ができるようにする」という風に書いてますがこの後、どういう風に資料を作成すればいいか見えてきません。そこでコンパイラのごとく機械的に目的として書いた文中の単語を拾い上げ、その意味合いを具体化していきます。
今回の例で言えば「資料作成が苦手な人」「簡単」「資料作成」という単語に分解できます。そして「資料作成が苦手な人」なら「資料作成のどういうところが苦手か？」、「簡単」なら「どういう風に簡単か？」などを深堀していきます。
ここでのテクニックとしては
- 既存のフレームワーク(5W1Hなど)を使って整理する
- この資料作成をすることになった大目的や背景、状況を盛り込む
- 形容詞、曖昧語(ビッグワード※)を排して定量化しやすい言葉で表現する
- MECEを意識して抜けている観点がないかを探す
などです。
「なぜアジャイルか？」の部分で詳しく解説しますが、ここで考えた内容は一度は必ず依頼者と認識合わせをしましょう。
ビッグワード※
補足として「目的」に関してはやることが見えやすいですが、むしろ「成果物」や「成功基準」の部分が大切です。「飲食店でラーメンを頼んだはずがカレーで出てくる」「食事が食品衛生基準法に準拠していると期待していたが実は準拠していなかった」ことはほぼないですが、資料作成のような抽象的な作業ではそれに似たことが往々に起こります。なので「成果物」や「成功基準」の部分こそ綿密に具体化しましょう。
ここで深堀を綿密に(これはビッグワードですが…)行うことで資料の目次やその先の具体的なスライドがおのずと見えてくると思います。
目次決め(設計)
次にソフトウェア開発で言うところの設計工程に相当する目次決めです。この中でまずはじめにやることは一番最初に結論を考えることです。
※目的に関しては前工程である「コンセプト決め(要件定義)」の部分で考えた「目的」「成果物」「成功基準」の中の「目的を」そのまま持ってきます。
資料の種類によりますが調査や検討資料などの場合、作業としての「調査」は無限に近くできます。エンジニアをやるほど知的好奇心の高い皆さんなら好奇心に火がついて楽しくなるかもしれません。ただし資料作成にかけられる時間は有限です。そのため、効率化するためにまず結論を考え、その結論を補強する論点を目次として追加していきます。つまり結論が仮説で資料作成と同時に仮説の検証をしています。
内容としては
にここら辺の頭の働かせ方が詳しく書いてます。「イシューからはじめよ」で言うところの「イシューの設定」はこの前の工程である「コンセプト決め(要件定義)」に相当しており、今回紹介する方法論と親和性が高いのかなと考えてます。
パワポ作成(実装)
ここまでやると最後にパワポ作成です。ここは思い思いのデザインで資料作成ください。
なぜアジャイルか？
ここまで資料作成の方法を解説しましたが、注意点があります。それはここまでの資料作成を一気通貫でやらないでください、ということです。 それが「アジャイル資料作成術」の「アジャイル」の部分に繋がります。
理由はソフトウェア開発に通じます。
有名な話ですが後工程で致命的な不具合が見つかり、後からやり直す場合にかかる工数は多大なものです。特に発覚が後であればあるほど悲惨なことになります。それを防ぐことです。
出典：https://req-definer.com/entry/relative-cost-of-fixing-defects
おそらく皆さんの職場ではウォーターフォールなら週次の定例会、スクラムなら毎日の会議(デイリースクラム)が行われていると思います。その中で完成してなくても都度、持ち込んで意見をもらうのがいいでしょう。アジャイルではモックでも何でもいいからプロダクトをイメージさせるもを顧客に持ち込んでフィードバックを貰ってます。そのイメージです(かなり極端な例だとモックアップすら作ってなくアプリの画面に似せた絵を段ボールで作って表現したりもするみたいです)。
「コンセプト決め(要件定義)」「目次決め(設計)」「パワポ作成(実装)」の各工程内で終わりきってなくても問題ないです。むしろ終わりきってなくて煮詰まっているときに時間で切って持ち込むのがベターです。意外と思わぬところで資料の作成者と依頼者の間で認識の相違が生まれています。それを早い段階で見つけて手戻りを減らしていきましょう。
特に、「コンセプト決め(要件定義)」の部分は重要度が高く、考えが煮詰まりやすく、それでいて認識のずれが生まれやすいので、3回でも4回でも話し合うのが安全だと思います。
また人間は未知のものには恐怖感やストレスを感じるものです。それを反復的に認識合わせをしていくことで既知に代わります。また依頼者としては自分の意見が盛り込まれているという納得感も醸成されていきます。それにより最後にちゃぶ台がひっくり返されることも少なくなっていくのかなと思ってます。
補足
工程の分け方について
上記の工程の区分けについてはあくまで標準的なものです。例えば資料の分量が多い調査レポートなどの場合は、「目次決め(設計)」の部分を複数に分け、
「目次決め」
↓
「目次の中のキーメッセージの作成」
↓
「各スライドの大枠のイメージの作成(いわゆる空パック※)」
として各工程ごとに依頼者やチームメンバーと認識合わせするのも一つのやり方です。
空パック※
まとめ
いかがでしたでしょうか？私はこの方法で資料作成をやり始めてから手戻りが減ってきました。ただまだまだ発展途上です。もし気になった部分が出たり改善点が出た場合はアドバイスいただけると嬉しいです。
Discussion