ダメ出しされない資料作り

あまり他人のことを言える立場では無いのだが、企画兼コンサルティングのプロジェクトに参画している他所の年配エンジニアの資料作りはとてもユニーク(オブラートに包んだ表現)である。

プロジェクト立ち上げの初期は、こちらも前のめりというか担当範囲以上に色々とやらなければとそんな気持ちでやっていたので、他所の年配エンジニアに対してもああしろ、こうしろと散々ツッコミし続けていた。

アプローチも思想も全く並行線の世界で交差するのは極まれだった。しばらくして、距離を保った方がお互いのためと気づいて役割分担も綺麗に分かれるようにするとその分のしわ寄せはプロジェクトオーナ側に押し付けることになるのだが、全体的にはそうした方がお小言的な指摘をする必要がなくなったので他所の年配エンジニアに取っても平和だったかもしれない。

こうした企画兼コンサルティングの資料作りであまりにもユニークな資料を作り、周りから総ツッコミをされないためのコツは、実はエンジニアが要件整理や仕様を詰める検討資料作りの参考になるのでは無いかと思った。

 

  • 必要最小限で十分な情報収集、課題の中の本質、仮説とストーリ
    資料作りでは、作成する資料のテーマに応じた結果を実現するための準備を行う。要件を確定したいのであれば、要件を確定するための準備をしなければならない。そのようなテーマであっても標題の3つのステップで進めれば良い。

    必要最小限で十分な情報収集とは、目的はあるマイルストーンの期日までに実現しなければならないものである、という前提がある。要件が後続工程のインプットになる場合、要件は後続工程の開始日前に決着している必要がある。更に言えば、要件を整理する側の都合に良い状態になっている必要がある。

    期日、都合の良い状態は制約になる。以上から、資料作りでは締め切りを設け、それに収まるように作業を完了させるためにタイムボックスの考え方を取り入れる。端的に言えば、作業前に終了時間を決めておき、その中で収まるように作業を調整する。ただし、次工程のインプットになることから中途半端ではいけない。

    課題の中の本質とは、見えるキーワード、ステークホルダが発するキーワードに囚われずに課題の根っこを必要最小限で十分収集した情報から自分のフィルタをかけ探さなければならない、とうことである。

    得てして、与えられるキーワードが課題であると鵜呑みにし、それを解決するためのアクティビティを設定しがちであるが、それでは期待されている課題解決には至らない。なぜなら、キーワード自体がそれを発した人の仮説であり、仮説の背景にある『なぜそれが必要か』に辿り着けないためである。

    仮説とストーリとは、タイムボックスの中で得た情報の分析から自分で設定した真因を解決する骨格となる台本を組み立てるということである。この台本がいい加減であると課題設定自体を疑われることもある。

 

  • 資料の構成、曖昧さを排除する、伝えたいことを伝える
    資料の構成はいわゆる章節項という目次のことである。たとえ目次を作らないとしても、標題を設け、親子関係を取らなければならない。構成を取るということは、親となる目次で全体を表し、その範囲の中でのみ記載するテーマを設定する。前方もしくは上位の目次で述べられていないことをいきなり書くと読み手が混乱し、資料の目的である要件の整理はストップしてしまう。

    曖昧さを排除するとは、章節項の構成の上位もしくは前方で示す記述の範囲について述べる範囲をさし示すことと示した範囲の中で重複や漏れをしないようにコンテンツとしてのムラを排除するという観点がある。更に、主張することについての表現でいくつもの受け取られ方をするような言葉は選ばないようにするということである。

    伝えたいことを伝えるということは、標題と内容が一致しているか、それを必ず確認しなければならないということである。資料の標題、とくにスライドなどで資料を作る場合、標題から手をつけることが多い割に本文を書いていると次第に標題と内容がずれ始め、全体の構成からとも違う資料を作っていることがままある。

もっといくらでも出てきそうであるが、資料作りの根幹は資料作りの骨格と資料自体の明快さにより資料作りの目的が達成できる。年配エンジニアの資料を見ていてそう思ったのだからそれほど外してはいないと信じたい。

 

 

 

 

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める