Zenn
🧙‍♀️

「楽してぇ」と思った時のチェックリスト

2023/05/01に公開
ポエム
エンジニア
メモ
idea

皆さんは楽をすることは好きでしょうか？
私は大好きです。楽をするために日々努力しています。
「楽してぇ」と思うのはタスクや文化は、以下のような特徴を持っていないでしょうか。

  • 冗長
  • 高頻度
  • 非効率
  • 不透明な目的

ふと思いついたので、オズボーンのチェックリスト[1]に沿って上記のようなタスクや文化にテコ入れをして楽をするための手段を整理してみました。何かの改善のきっかけになれば。

1.Put to other uses (転用)

  • 汎用化されたツールやモジュール(関数)を流用する
    • 個人ブログ/GitHubから入手
    • リポジトリから入手
    • 公式サイトや技術サポートや営業担当から入手

2.Adapt (応用)

  • タスクや文化が自社固有の場合
    • まずは課題を一般化して言語化する
      • 検索ボックスに入れたり、他者に説明できる状態にする
  • タスクや文化が自社固有でない場合
    • 先行事例を探す
      • 先行事例と自社の違いは何か？
      • 100％ではないにせよ、大枠の応用は可能か？

3.Modify (変更)

  • ツールに新しい機能を追加する
  • ツールのパフォーマンス改善のためにリファクタリングをする

4.Magnify (拡大) ＆ Minify (縮小)

  • 無駄なタスクを省略する/頻度を拡大する(日次でやっていたものを週次に)
    • 省略/拡大の障壁になることは？
      • 技術(ルールチューニングなど)
        • チューニングは可能か？
      • 社内ルール(誰かが決めたルール)
        • ルールの妥当性は？コンテクストは当時と変わっていないか？
      • コンプライアンス(監査要件など)
        • コンプライアンスを満たすために必要な要件を再検討する

5.Substitute (代用)

  • 手作業(GUI)を文字(CLI/プログラム)に代替する
    • OSコマンドで代替する
      • 例)Powershell/MS-DOS/Shellコマンド
    • CLIツールで代替する
      • 例)AWS CLI/Azure CLI/Azure PowerShell
    • SDK/ライブラリで代替する
    • (広い意味での)APIで代替する
      • 例)OSのAPI(Win32APIなど)
      • 例)REST API(I/P/SaaS全般、OSS/アプライアンス全般)

6.Rearrange (置換)

  • タスクの役割分担や責任担当を見直す
    • これは根本的な解決にならない大企業病かも…

7.Reverse (逆転)

  • そもそも必要であるという前提をひっくり返して、問題とするタスクや文化を廃止する
    • 本当に必要なものなのか？必要だとしたらその目的や効果は？
      • 具体的にどのような効果やメリットがあるのか？
    • タスクや文化が登場した経緯や背景は？
      • 当時と現在で背景に差異はないか？

8.Combine (結合)

  • 組織の拡大や分化で重複するようになった複数のタスクを統合する
    • 目的を同じくする部分を洗い出す
    • 関係者間で合意を取って統合する

チェックリスト以外で大事にしたいポイント

「楽をする」という意味ではコスト(かかる時間)とリターン（楽できる時間）まで加味して最も楽ができる選択肢を選ぶという観点は重要と考えます。例えば1,2,7あたりは時間的に楽をできる選択肢になる可能性が比較的高いです。

よって以下のような観点も、厳密である必要はありませんが考えてはおきたいところです。

  • コスト
    • どれくらいの工数で実現できるか？
    • 将来的にメンテナンスは発生するか？
      • 発生するとしたら、どの程度のボリュームで？
  • リターン
    • 日/月/年換算でどれくらいの工数が削減できるのか？
    • リターンはいつまで得られるのか？
    • リターンは一定か？変動か？

5で挙げたような自動化は楽をするための一番わかりやすい手段であり成果としての見栄えもよいのですが、保守性が考慮されていない自動化ツールが技術的負債のような扱いを受けたりツール開発やメンテナンスに時間をかけすぎて本末転倒になるケースをたまに観測します。

まとめ

考える粒度や抽象度がバラバラですがとりあえず思いつくものをぱっと書いてみました。
私自身が楽をするためにしていることを振り返ると、

  • 4,7,8でまずは簡素化や廃止の可能性を探りつつそのタスクの目的や役割を考え直す
  • 1,2のような先人の知恵をなるべく活用しながら5の自動化に持っていく

というやり方に持っていくことが多い気がします。

脚注

  1. アレックス・F・オズボーンの著書『Applied Imagination』を原典として、MIT Creative Engineering Laboratoryがアイデアを出すための切り口を9つの項目にまとめたもの。この記事ではこの9つの項目を「オズボーンのチェックリスト」と定義しています。
    https://kotobank.jp/word/オズボーンのチェックリスト-1125434
    https://en.wikipedia.org/wiki/Applied_Imagination ↩︎

Discussion