読者です 読者をやめる 読者になる 読者になる

こう対象を囲い込んで除々に攻略していくイメージ

メソッド

はじめに

複雑さにどう向き合うか。 

問題の理解

「なぜ作業に取り組むのか」、作業するにあたってその基盤となる明確な意思を培う。
そこを曖昧にしたまま取り組み始めると、作業中に迷子になってふりだしに戻るみたいなことが起きる。
徐々に攻略している対象が見当違いである可能性を配慮して、作業が思うように進まなかったらまずここに立ち返る。

  • 自分の責務・曖昧な要素(意図、用語の定義)を明確にする。
    曖昧にしたまま進めると、どんどん拡散していってしまう(収集がつかなくなりやがて…)。
    例.
    ① 機能の仕様を策定するときに、技術的な正確さに固執せず、そもそもなぜこの機能が必要なのか、当事者意識(1ユーザとして)を持つ。
    技術に関するさまざまな制約(インフラ不整備等)からの立往生を避け、ユーザビリティ性に注目する。
    すると、逆説的に技術的な問題が解決したりすることがある(データ量の問題が解消されてインフラを拵える必要がなくなったり等)。
    ② コードを読むときにただ漠然と読みだすのではなく、「全体の構成(ディレクトリ構造)を把握したい」等の目的を持つ。
    ③ 「○○なんて常識だろ」に対して、「え、○○って何ですか」と咄嗟に言えること。

  • 問題を再改修して自分のものにする。
    例.
    些細なことであっても、「これだけは...」というような課題を必ず設定する(例えば今日1日○○しないとか)。

戦略

上述のステップで定めたゴールに辿り着くためにすべきことを洗い出す。ここで、作業全体を見渡すようにする。
次に、作業内容を明確にし、その内容の妥当性について吟味する。各作業をシュミレーションしてみて、無駄と判断したことは省略する(この作業は時間の許す限り何度か繰り返してフラッシュアップさせていく)。

取り組む課題によってレベルは異なるけれども、いくつか事例を挙げると...

  • あらゆるツールを利用する前に、あらかじめ全体の構成、その特徴/流儀/立ち位置(どういう経緯でつくられたのか等)を把握する。
    例.
    AWS関連のツールを使うときには、推奨されている作法・流儀に倣う。
    フレームワークを使うときには、リファレンスその他公式情報に目を通し基本的な機能を確認して、無駄な作業(車輪の再発明)を避ける。

  • コードを修正する前に、巨大なコンテキストを読み込み(システムの構成や該当箇所の依存関係の把握等)、
    時間が許す限りさまざなロードマップのパターンを想定したうえで最善の手法を考える。

  • ググる前に、考える(内容の推測、検索語の選定等)。
    ツールがどのように動作するのかを考えれば、自ずとやるべき作業が見えてくる。
    例.
    smartyはページ内容を動的に定めるとき(該当ページにアクセスしたとき)、
    「template」配下のファイルをコンパイルして「template_c」「cache」配下に格納する
    → 「template_c」「cache」のアクセス権限を変更する必要があることがわかる

施行

  • やっつけで作業しない(下手でもいいから丁寧に)。
    ヒューマンエラーによる出戻り(無駄な作業)を防ぐ。
    自分の状態を一つ一つ仔細に観察して、「心配しながら、焦りながら、重圧を感じながら」と「穏やかに、ゆっくりと、気楽に」の配分を調整する。
    リラックスした穏やかな状態であるか、意味のない仕草や動作をしていないか、確認する習慣をつける。

  • (全体の作業を見渡したうえで)逐次的に作業を進める。
    トランザクションを張るイメージで、部分部分の作業を完結させていく。
    何の作業に取り組んでいるのか明確にし、その作業にのみ取り組む。並列的に進めるのは、全体の作業を見渡すフェーズのみに留める。
    着手する作業内容を曖昧にし、複数の作業を並行的に推し進めるようなことはやってはいけない。レンズを使って太陽光を一点に集めると、同じ光線を分散させたときの何倍もの熱が生まれる

  • 物事を理解しやすい姿形に落とし込む(抽象化によるイメージ化)。
    調べ物をする際はその都度調べるのではなく、後で確認できるよう/記事にできるよう、要点を絞って簡潔にまとめる。

おわりに

やっていく。