この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
データアナリティクス事業本部＠札幌の佐藤です。
以前、作業工数の考え方について書かせていただきました。 その中で、表の書き方についてすこし言及しましたが、もう少し具体的に書いたほうがよいかなと思い今回ブログにすることにしました。
若手社員向きの記事となりますので、当然だろという要素多々あると思います。 また、あくまで私の経験によるものとなりますので、本来のあるべきからそれている可能性、プロジェクトによってはあてはまらないケースあると思いますが、ご了承いただければと思います。
なぜ表で書くのか
普段仕事をしている中で表で記されたものを見ると思います。 ツールはエクセルだったり、Markdownで記載されているものだったりと様々だと思いますが、何かしらを表で書いてあります。 そもそもなぜ表で書く必要があるのでしょうか？ 私は大きく3点理由があるのではないかと考えています。
表現したいことが一目で見て分かるから
これが主な理由だと思います。
■パターン1
・開発-ジョブ作成:ZZZ.yml、工数(時間)3h。既存資源のコピペでいける
・開発-アプリケーション作成:XXX.py、工数(時間)1h。既存資源のコピペでいける
・開発-アプリケーション作成:YYY.sql、工数(時間)12h。設計見る限り結構重たそう
・開発-共通TBLへ追加:xxxテーブル、工数(時間)0.5h。
・単体テスト-テストコンディション作成:ー、工数(時間)4h。
・単体テスト-テストクラス作成:test_XXX.py、工数(時間)2h。
・単体テスト-テストデータ作成:testdata_xxx.csv、工数(時間)2h。
・レビュー-フィーバック修正:ー、工数(時間)4h。
・資源PUSH-リポジトリAへPUSH:ー、工数(時間)0.5h。
・ドキュメント修正-共通テーブルWikiへ追加:hogehogeページ、工数(時間)0.5h。
→工数計（時間）：29.5h■パターン2
どっちがパッと見てわかりやすいでしょうか。 これはまだ行数が少ないので読もうと思えば読めますが、100行になった場合の可読性は表のほうが高いと思います。
抜け漏れの有無が分かるようになるから
ここは失敗しないための重要なポイントとなります。 作業していて、あれこの作業抜けているなというのが後で気づくことが多々あります。 それはおそらく網羅性を失っていたために発生したものと考えられます。 網羅性の担保をするためにはセルフ・第三者レビューをして洗い出すのがよいと思いますが、上のような表になっている状態で網羅性があるかぱっとわかるでしょうか？ 恐らく難しいのではないかと思います。 表のほうが視認しやすいので、気づける確率は上がると思います。 文章で羅列すると網羅性がどうこうというよりも、そもそも情報が固まりすぎていて分かりにくく、今までの経験上ちゃんと読んでもらえません。（N敗） レビューする際にも文章で書いているより、読んでもらいやすくなります。
説明するときに説明しやすいから
これはどちらかというとExcelやGoogle スプレッドシートを用いての説明という点になりますが、たくさんある行をすべて説明するのは時間的な都合で難しいケースがあります。 フィルタを利用することで、対象を絞って説明ができ、表現したいことやぬけ漏れの検知につながります。 表は書いて終わりではなく誰かに伝えるための方法でしかないため、説明する人に対して説明しやすいようにするのがよいと思います。
表で書いてみる
表で何かを表現するためには、頼まれている作業の前提や伝える人などが分かっていないと基本的に書けません。 前提の考え方については、以前書いた以下の記事をご参照ください。 今回はもう前提が分かっていていざ書こうとするときの話からスタートします。
よくやりがちなケース
よくあるケースはこういうものになります。
恐らくこれは作業者の作業順番に並んでいます。 これはこれでいい、と言いのかもしれませんが、上で書いた表の書き方という点ではどうでしょうか。 これで開発の作業が何か一発でわかるでしょうか。 多分フィルターをしないとわかりません。 そして、作業が備考列の前にあるので、まずはフィルターをする列を探すところからのスタートになります。
表の右側に行くほど補足になる
上記表の場合、このような形にするほうがよいかと思います。
必要な情報であればあるほど左へ、どうでもいい情報（補足情報）ほど右へもっていくと、伝えたいことが明確になります。 デザインの話でよく言われる、レイアウトの視線誘導は表であっても適用されます。 そのため、一番目に入りやすいところを意識して書くのがよいです。
このような表を作成する際は、イメージとして自分がこの表を説明するときにどのようにすると伝わるのかというのを考えるのが近道です。
この表で言うと、何の作業にどのくらいの時間がかかるかという話をしたいのだと思います。
私であれば、まずどんな作業があるのかを説明したいので、開発などを定義するところを一番左へもっていきます。
そこから各作業がそれぞれどのくらいかかるかという点を説明します。
説明するときに修正資源は特に説明する必要もないので、右へもっていきます。
この図で言う大項目列を正しく持っていけないと、網羅性を見失います。
ただ、まず思いついて書くのは、作業列になると思います。
ひとまずは作業を書いて、そこから小さい作業はきっとそれをまとめるものがあるはずという考えで、まとめていくのが近道です。
慣れてくると自然にできるようになります。
セル結合は絶対にしない
この手の表でありがちなのはセル結合です。 これは悪手なので絶対にやめたほうがよいです。 なぜかというと、これがきれいに見えるのは上っ面だけです。 フィルタをしたときに必要なところが出てきません。
上で表で書く理由に説明しやすいためと書きましたが、これでは説明できないです。 しかも、セル結合している一番上を消すと空白になる上に、行追加されたときにセル結合外して付け直す必要もあり無駄な工数を使っているだけです。 セル結合はヘッダの調整程度のとどめておくのがよいと思います。 同じ名前のものをまとめておきたいのであれば、単純に罫線を消して、同じ記載をしているところの文字色を白あるいはグレーに変えておくだけで達成できます。 （私は白だと記載漏れに気づかないため、あえてグレーにしています）
連番は振るべきか
今回の図表には記載していませんが、振っておくのがベターだと思います。 振らない場合、説明の際に番号で呼べなくなる（あるいはエクセル行番号N番呼びになる）ためです。
どこに連番列を用意するかは作成する人の自由ですが、分かりやすいところに設定しておくのがよいと思います。 私は先頭に付けます。
MECEに書いてみる
MECEとは
「Mutually Exclusive, Collectively Exhaustive」の略であり、Wikipedia上は以下のように記載がされています。 書いている通りですが、もれなくダブりなくということです。
「相互に排他的な項目」による「完全な全体集合」を意味する言葉である。要するに「漏れなく・ダブりなく」という意味である。経営学、経営コンサルティングなどの領域でよく使われる言葉である。アメリカ合衆国の戦略系コンサルティング会社マッキンゼー・アンド・カンパニーに所属していたバーバラ・ミントによって開発された概念であり、ロジカルシンキング (論理的思考) の一手法として用いられている。 https://ja.wikipedia.org/wiki/MECE
以下の図で説明します。
B事業部とC事業部があった場合に、このようなことが考えられます。
- そもそも同じ事業部で同じチームが複数があるケースはあり得ないだろう
- 同じ事業部体系であれば、マーケチームもあるのでは？
そこを考慮して書くというものが今回のポイントです。
抜けがあるといわれないような書き方にする
同じものが重複しているのはすぐわかると思いますが、「同じ事業部体系であれば、マーケチームもあるのでは？」というのをどう表現するのかというのが表においてのひとつのポイントだと思っています。 例えば、運用時に様々な機能を修正していくと思いますが、このようなケースあると思います。
このような不要であったり、対象外であるケースは、運用で考えると修正対象機能の洗い出しなどで、 開発であれば対象外理由をお客様と調整するのに登場してくると思います。 このような場合、表として書いておく？書かない？というところがあると思います。 ケースバイケースではありますが、基本的には除外せず書いたほうがいいと思います。
理由としては「考えたけどあえて抜いた（消した）」というワード、経験上あまり効果的に働いたことがないためです。
あえて省いている場合、そうする戦略的な理由がない状況においては、事前に言わないといけないので、いうの忘れているとぬけ漏れを指摘されます。 そしてもれなくほかに漏れがないか横ぐしチェックの流れになります。 たまたまかもしれないですが、逆に書いたままにしておくことで冗長であることを指摘されるケースは今までありませんでした。 補足として対象外理由などを書き添えておけば、読み飛ばしてもらえますし、必要であれば必要であることが議論できます。 ちゃんと考えたのに、ちゃんと考えていないと指摘されるのも癪だと思いますので、基本的には考えているアピールをするためにも残しておくのが無難だと思います。 お客様向け資料でを書いている場合、最終的に外すかどうかは、戦略的な側面を見て相談して決めればよいです。
MECEの罠にはまらないようにする
私はわりとマトリックスで物事を表現しがちなので、陥る現象となります。 例えばテストコンディションを考えた際に、MECEであればテストとしては網羅できていることになります。 そのテストコンディションの条件が100個あったらどうしますか？
テストコンディションの条件が100個あった場合、すべての分岐を記載して、実施有無列を作って〇×つけていくと思います。 恐らく他のテストで担保できますし、完成したその表を後で自分が見直したときに見やすいとは言えないと思います。 網羅性を担保することに目が行き過ぎると、「表現したいことが一目で見て分かる」を見失います。 網羅的であるに越したことはありませんが、そこにとらわれず、やらなければならないことの本質をついて表を書くのがよいと思います。 今回のケースであれば私はマトリックスのような掛け算の表にはせず、ある程度の処理単位などで分けて、足し算的に組み合わせて最低限網羅できる組み合わせてテストコンディションを作ります。 （ゲームをプレイにするにはルールが必要ですので、足し算的にやっている定義をルールとして記載する必要はあります）
作った表を伝える
これは以前書いた内容と重複しますが、なぜ表を作っているのかというとその表を使って誰かに伝えたいからだと思います。 伝えたい人が誰なのか、それを正しく認識しておくのが表を書くにあたっての本当に重要なポイントになります。 伝えたい人が自分と同じ作業者なのか、自分の上司なのか、お客様なのか、この三者で既に大きく違うと思います。 もしこの三者全て同じ資料を使わざるを得なくなった場合、上で書いていることができていれば主要な要素をフィルタし、伝えなければいけないところだけ伝える（開発にN時間だけ伝えたいなら、作業列や修正資源列は話さないなど）で伝えることができるはずです。
伝える自信がなければ備考に手厚めに書いておく
何でも書ける欄なので、後で収拾つかなくなるでおなじみの備考欄ですが、 情報をサマリして提示する場合などは極力詳細な根拠を書いたり（工数であれば松竹梅でそれぞれN時間＊N本など）、考えに至った理由を整理して記しておくとあとで説明が楽だったり、事前に課題として伝えることができるので面倒くさらず書いたほうがいいと思います。 特に初学者などは自信がなかったりするところもあるという点、表を使って説明するときに覚えているかどうか分からない（説明する時大体数日たっている）点があるので、議論の中心にするためにも書いておくのが無難だと思います。
終わりに
私が若手時代に最初に指摘されたのが表の書き方で、当時はここまでのことができていないばっかりに説明で意味が分からない等よく指摘をされていました。 そこからいろいろ考えながら導いていったものを今回まとめた形となります。 特に若手社員の方などの参考になって、私と同じようなミスをしなくなれば幸いです。