2020-02-23   6f4bc697

大規模な作業のときは「付箋スタック」を積む

皆さんこんにちは。 今回は番外的な記事として、私個人で編み出した仕事術ふせんスタックについて紹介したいと思います(笑) おもしろ半分で読んでいただけると幸いです。

    人間には把握の限界がある

    まず最初に、人間には把握の限界があることを前提とします。 というのは、人間のワーキングメモリはコンピュータのように数 GB あるわけではなく、たいてい数単語分しかないということです。 参考文献 によると、人間のワーキングメモリは 7±2 チャンクの範囲だと言われています。 仕事などで大規模な作業を行うのに対して、短期記憶の使用は避けるべきだと言えます。

    作業の影響は連鎖していく

    当然のことではありますが、作業を行うとその影響を対応するために新しい作業が生まれていくことがあります。 たとえば、新しい元号へ対応するためにAというシステムを改修した場合、Aを利用しているシステムBCDも改修が必要になり、さらに……という連鎖が発生します。 このとき、見通しが浅く「平成の 2 文字を令和に置き換えるだけ」程度に考えてしまうと、その作業量の大きさに気付くことができません。

    作業漏れを起こさないコンピュータの構造

    これも当然ですが、コンピュータは指示された命令通りに漏れを起こすことなく作業を遂行しますね。 コンピュータが処理を漏れなく行う記憶構造として、スタックがあります。 これはコンピュータが現在何の処理をしているか、この処理が終わったら次は何をするか、といったプログラムの実行ステータスを記憶するためにも使われています。 これに似たような方法を取り入れれば、機械的ながらも作業漏れを減らすことができるのではないでしょうか?

    ふせんスタック

    それではふせんスタックの方法を例をまじえながら紹介します。 まず、作業ステータスを記録するためにふせんを使います。 ふせんに今回のタスク例として「平成 → 令和移行」と書きます。 そして、これから行うタスク「平成 → 令和移行」に「←」マークを付けます。

    次に、「平成 → 令和移行」のタスクを完了するにはどんな作業が必要かを書き出します。 ここでは、「文字列置換」と「画像に埋め込まれた文字の置換」をする必要があるため、 この 2 つをふせんに書き出して「平成 → 令和移行」の隣に貼ります。 このようにして作業の階層構造を表現します。 また、「文字列置換」のタスクに「←」マークを付けます。

    「文字列置換」のタスクを完了するには、app/ ディレクトリ配下のファイルと resource/ ディレクトリ配下のファイルを編集する必要があります。 この 2 つのディレクトリをふせんに書き出して「文字列置換」のタスクの隣に貼ります。 そして、resource/ 配下から着手するため「resource/ 配下」のタスクに「←」を書きます。 さらに、「平成 → 令和移行」のタスクを完了するには、西暦と和暦を変換するプログラムを改修する必要が出てきました。 そこで「西暦 → 令和変換実装」のふせんを追加します。

    resource/ 配下の文字列置換が完了したため、「resource/ 配下」のふせんを破棄します。 そして、次のタスク「app/ 配下」に「←」を付けます。

    app/ 配下の作業も終わったため、「app/ 配下」のふせんを破棄します。 これによって文字列置換のタスクもすべて完了したため、「文字列置換」のふせんも破棄します。 次に行うタスクを選び、ここでは「西暦 → 令和変換実装」を行うことにするため「←」マークを付けます。

    このようにタスクを消化していくことで、大きなタスクも詳細かつ全体を把握しながら遂行できます。

    全体を把握しながら再帰的に

    このような仕事術はいわゆる深さ優先 といえます。しかし、仕事上ではタスクの工数(全体の作業量)を把握する必要が出てくるため、なるべく細かいタスクをふせんに貼り出して 全体を把握できるように心がけたいです。 ふせんスタックは個人の裁量内で使えるものですが、大きなタスクは Backlog などのツールを使って共有することもお勧めです。

    この記事の執筆者

    hata6502

    Tomoyuki Hata   Follow @hata6502

    中学生の頃に 6502 という CPU からプログラミングの世界に入りました。 C/C++ で1から作ることも好きですが、最近は Web 系に移行しつつあります。