本記事は「AI技術を駆使した仕事術」の解説ではありません。逆であり、AI技術の進展に左右されない「仕事の本質」を意識した仕事方式の解説となります。弊社の公式内容ではなく、執筆者が心掛けている内容です。
はじめに
第一に、「AI技術が将来的にどこまで仕事に良いインパクトを与えるのか」、「どのような仕事（タスク）レベルまでAIによって自動化されるのか」は想像が難しいです（とくに実現タイミングの予測も含め、少なくとも私には）。
第二に、AI技術の進展の早さを考えると、現時点（2025年3月末）の「AI技術を駆使した仕事術」を解説しても、おそらく1年後の「2026年3月末」には、その記事内容は陳腐化している可能性が高いでしょう。
（※とはいえ短期的には、「（現時点での）AI技術を駆使した最強の仕事術」の紹介記事にはとても価値があると思います。）
本記事では、AI技術に取り組む弊社にて、私（および私のチーム）が、AI技術の進展度合いに左右されない「仕事の本質」（だと思う部分）を意識しながら、どのように研究や開発、その他Bizに取り組んでいるのかを紹介します。
はじめに10個の仕事術（仕事方式）を解説します。
最後にAI技術の進展に左右されない「仕事の本質」（と私が考えている内容）について解説します。
本記事の目次です
1.「パーキンソンの法則」を意識した期限設定方式
パーキンソンの法則（第一）とは、
「仕事（の内容量）は、利用可能な時間を全て満たすように拡大していく」
という有名な法則です。
パーキンソンの法則（第一）に注意し、仕事（タスク）に取り掛かる前には、自ら制約条件として、期限を「今日1日で」や「3日間で」など、厳密に設定することをおすすめします。
期限を厳密に設定しない場合、以下の3つのケースが想定されます。
（1）ダラダラと仕事に取り組んでしまう
（2）締切が外部から突然与えられて、焦って実行する
（3）そして最悪なケースが、 「その仕事の芯を食っておらず、本質的には重要ではない、やってもやらなくても良いような仕事（タスク）まで実行してしまう」、すなわち法則通り「仕事の内容量が増える現象」が発生するケースです
この重要でない仕事の膨張を避けるために、自ら設定する期限は、これでは短すぎではないかと感じるくらいのが望ましいです。
期限が短いと、「その仕事の "真の答え" にたどり着けないのでは？」と不安に感じるかもしれません。
しかし多くの場合において、「期限設定が長ければ、たくさんの時間をかけることができて、"真の答え"にたどり着ける！」というケースは少ないです。
それよりも、設定した期限内での 「暫定解」 を導出する方が有用なことが多いです。
なぜならその「暫定解」に基づいて、次の行動を選択し、実行できるからです。
そして「暫定解」を前提とした次の実行や、時間の経過で増える新たな情報を通じて、「暫定解」をより洗練し、「暫定解 ver.2」 に更新する方が有用なケースが多いです。
なお少なくとも期限後時点には、暫定解であることを前提として、上司・メンバに現状を報告・相談します。
暫定解は自分の中に閉じておくものではなく、「暫定ですが現状こう考えています」と関係者に報告・共有するものである点に注意してください。
仕事（タスク）を実行する際には最初に、短すぎると感じるくらいの期限を自ら設定します
2. 結果と成果を区別した成果優先方式
多くの人は仕事（タスク）において、「結果（output）」 と 「成果（outcome）」 を混同しがちです。
以下に言葉の定義を整理します。
・なんらかの仕事（タスク）を実行した際、必ず生まれるのが「結果」です
・「結果」をその仕事の文脈のなかできちんと位置付けて、解釈・整理したものが「成果」です
そして重要なのは、結果ではなく、「成果」です。
とくに会議・ミーティングの場面で私が最初に知りたいのは、 「目的と問題定義」、「成果（アウトカム）」、そして 「結論」 です
（「目的と問題定義」については後の章で解説します）。
「結果・アウトプット」については、成果・結論を伝える際に、必要に応じた補足程度の解説で十分です。
なお 「結論」 とは、成果内容に加え、成果をふまえて導出される「ネクストアクション」や、場合によっては「手戻りの必要性の説得」など、「次にどうしますか？」 という問いへの回答に近しいものです。
なんらかを実行すれば、良くも悪くも、必ず「結果」が生まれます
（だからこそ多くの人は自分の取り組みの「結果」について、ダラダラと言及・解説しがちです）。
なお、成果の良し悪しについては、運や状況にも左右されます。
そのため、良い成果を生み出す確率を上げる行為は重要ですが、「良い成果」を確約することはできません。
「結果（アウトプット）」と「成果（アウトカム）」をきちんと区別し、成果を意識して仕事を実行します。そして結果についてダラダラと説明せず、成果について端的に述べ、成果優先方式で進めていきます
3. 構造整理を実施してから実行方式
私は直感・思いつきタイプではあるのですが、思いつきで何らかの仕事（タスク）を実行し始めないように注意しています。
一呼吸置きましょう。
思いついた内容自体は否定されるものではありません。
しかし、「他にもっと重要なやるべきことはないか？」、そして 「そもそも、その思いついた内容はなぜ良いと判定できるのか？」 について、立ち止まり、顔を上げ、抽象度を上げて、考えるようにします。
そして「他の選択肢」についてリストアップします
（選択肢は突然思いついたこの1つのみです、という状況は通常少ないでしょう）。
ここで他の選択肢をリストアップするためには、問題構造を整理・分解する必要があります。
多くの場合、問題構造の基本系は以下の通りです。
- 「大目的」が存在（ビジョンや経営目標、KGIなど）
- 「大目的の達成を阻む大きめの課題」≒「Issue（イシュー）」が存在
- 「Issue（イシュー）」を分解し精緻に言語化した「目的と問題定義」（※）
- 実行可能な単位に落とし込まれた「タスク」
（※）「目的と問題定義」については後の章で解説します
最初に思いついた内容について、「問題の基本構造」の整理に当てはめ、その上で、やはり重要だから実行することは、まったく問題ありません。
傍から見ていると、思いついて突然実行！と同じように見えるかもしれませんが、大きく異なる行為です。立ち止まって整理した上での実行は、より大きな成果へと繋がりやすいです。
また、構造関係を整理していれば、「とある問題」について、時間をかけて「暫定解」を導出したり、解決しても、後続のタスクに影響がほぼないケースも、きちんと自己認識・自己発見しやすいです。
「後続タスクでの選択や決定に影響力を生まない問題」に対して、解決および暫定解を導出する行為は、基本的に時間とリソースがもったいないです。
「思いついたら即実行」ではなく、大目的からロジカルに構造整理し、思いついた内容を構造関係に当てはめる行為をスキップせず実施し、整理した後で実行に移るように注意します
4. 目的の明確化と問題定義駆動方式
とある問題（やタスク）を実行する前には、必ず、なぜその問題を解決しに行くのかという 「目的の明確化」 を実施します。
要は、「その問題が解決・完了できたら、何が得られそうで、どう嬉しいの？」 という問いに回答できるように言語化し、整理します。
そして「目的の明確化」と同等かそれ以上に大切なのが、「解決しようとしている問題（今、倒したい対象）」を「解決状態の定義（達成条件）」と「解決に際しての制約条件」とともに精緻に言語化する、「問題の厳密な定義」 です。
なお、「目的部分」はこの問題定義の冒頭部分に記載されることになります。
「問題の厳密な定義」と「タスク設定」は異なります。
問題定義は非常に精緻な言語化です。
この言語化をスキップし、タスク設定のみで進めると、「後になって、周囲・メンバ・上司と齟齬が生まれてしまった」という状況は、誰しもが経験しているでしょう。
そして、問題定義をした後は、「●●をしてください」と、自分で自分に指示を下します（定義した問題を自分に出題します）。
これには2つの意図があります。「アライン（調整）」と「リード」です。
自分で「●●しよう」と意識的に行動していても、いつのまにか問題からズレがちです。
「集中」状態がいつのまにか「夢中」状態になり、そして「無我夢中」状態に陥り、その結果、「我を忘れ、いつのまにか元の問題定義からブレていく」という現象が発生しがちです。
そうならないように「精緻な言語化による問題定義を自分へ出題する」ことで、自分の思考と行動がブレないように、アライン（調整）します。
2つ目の目的はリードです。
基本的に難易度が高い仕事ほど大変です。おっくうになります。
そこで、まるで上司が部下に指示を下すかのように、「もう一人の冷静な自分」が「実行役の自分」に指示を下すように問題を出題し、自分の中で二人三脚で挑戦する体制を作ります（甘えてしまう実行役の自分をなかば強制駆動させるイメージです）。
そして冷静な自分は実行役の自分を見守り、コーチングし、実行役の自分が折れないように優しくリードします。
突然実行に走らず、「目的をきちんと明確化する」、そして「問題を精緻に言語化して定義する」、そのうえで「定義した問題設定を自らに出題して、自らを駆動させる」を意識します
5. 決着をつけてから次に進む方式
仕事をする際、なんとなくレベルから非常に深いレベルまで、その程度はともかく誰しもが「なんらかの仮説」をもって、実行に取り組むかと思います。
この際、最初に立てた仮説が途中でなんとなく、「この仮説・解決方法は思っていたよりも筋が悪そうだ」と感じることもあるでしょう。
このような場合、「方向調整」や「方向転換」は大切です。
ただしそれは、最初の仮説にきちんと決着をつけてから実施する（区切ってから次に進む） のが望ましいです。
すなわち筋が悪そうだと感じたなら、 「筋が悪いというファクトの結果図を示す」、もしくは「論理的に筋が悪いと判断した理由を記述・報告する」などして、きちんと決着をつける（区切る）ことが大切となります。
決着をつけるための行為に時間をかけすぎる必要はありません。
ですがこの「決着をつける行為」をスキップしてしまうと、周囲の人間は 「あの人はやっている内容がころころ変わっているな～」 と感じます。
また、「一体、今は何をやっているの？ 前まで取り組んでいた内容はどうなったの？」 と周囲の人間はあなたの仕事内容を理解・認識できなくなります。
「第一候補は筋が悪いと決着付けた」もしくは「環境が変化し、第一候補の遂行が無理になった」などときちんと報告・相談してから、第二候補の解決策に移ることを宣言・報告し、その上で次々と高速にイテレーションを回すのが望ましいです。
なお「決着をつける」行為は、筋が悪い場合だけでなく、うまくいった場合も同様です。
その場合は「きちんと成果（アウトカム）と結論を整理する行為」が、決着をつけるという意味になります。
とくに、
- 解決策のどの部分が重要な成功要因だったのか？
- それは対象がどのような性質を持っていたからだと思われるのか？
- Next Actionの第一候補は何ですか？
の3点は、うまくいった場合に知りたいポイントです。
「決着をつけてから次に進む方式」を実施するには、丁寧な仮説立てが重要になります。
丁寧な仮説立てがあれば、実行結果が仮説通りなのか、それとも仮説とは異なるのかを判断できるところまで、すなわち「決着をつけられるところまで」、きちんと仕事をやり切ることができます。
多くの人は仕事（タスク）に取り組む前に、「どのような結果・成果・結論が得られるであろうか」の仮説立てがなんとなくレベルです。
そのため「どこまでやり切るべきかの判断」が曖昧になり、取り組みやすいところまで、もしくは思いついたところまでを実行して、勝手にそこまでで切り上げて終了とし、そこまでの結果でなんらか言えそうな考察や結論を出す行為に走りがちです
（そのようにして導出された考察や結論は、次のフェーズで生かされることはほとんどありません。なぜなら、きちんと決着がついていない状態でひねり出した結論だからです）。
「決着をつける」という行為は、次のフェーズで、前に取り組んだ仕事（タスク）の成果・結論を活かすためにも非常に重要である点を押さえておくと良いでしょう。
仕事の方向性を調整・修正・転換する際には、先に「きちんと決着をつけ」、区切ってから次に進むことを意識します
6. 思考実験優先方式
研究・開発の場面において、なんらかのプログラムや機能（Function）を実装する際にはリソースの消費を伴います（時間と人を消費します）。
また研究・開発以外においても、「イベント開催」や「講演・執筆」など、何らか大き目のアクションの実行にもまずまずのリソース消費を伴います。
そのため、「投資対効果の事前検証」 は重要です。
とくに研究・開発系の場合、「プログラム（や機能）を実装して、実行させ、結果を得て、考察し、結論を出す」という一連の流れには、一般に多くの時間と労力・リソースを要します。
「思考実験優先方式」 とは、「この解決策を実施すると、何がどのように変化し、最終的にどんな結果が出そうで、そこから得られる成果は何で、どう嬉しい状態になるのか、そして言えること＝結論は何になりそうか？」を、実際に手を動かして実行にする前に、脳内で細かくシミュレーションする方式です。
「思考実験で想定された結論は、実際に実装して実行してもきっと変わらなさそうだな～」や、「わざわざ実行したからこそ生まれる新たな知見・嬉しいことはなさそうだな～」 という状況であれば、時間とリソースを割いてまでプログラムを実装・実行するのは無駄かもしれません。
研究寄りの場面で、「実装していろいろパラメータいじって動かしていたら、何か嬉しいことが見つかるかも」という可能性や考え方は否定しません。
ただし、「何か見つかるかも探索」は、「アジャイルな進め方」や「高速なイテレーション試行」とは異なる点を認識し、混同しないように注意してください。
また実際に実装する場合は、バグ確認（テスト）・バグ修正にも時間が奪われる点にも注意が必要です。
「本当に実装リソースを割けば、事前の思考実験だけよりも、大きな価値≒成果と結論 が見いだせるのか」 について、一度立ち止まって考えてから進めるのが良いでしょう。
「思考実験」は、単なる結果・成果の予想・予測とは異なります。「これを実行すると、まず◎◎が発生し、それがＸＸを引き起こし、そして△△となって、結果、〇〇になる。その結果、hogehogeという結論が言えそうである」といった、実際に実行していく過程を追いながら一連の出来事を綿密にシミュレーションします。
この「思考実験優先方式」と関係深いのは、先に紹介した仕事方式の 「4. 目的の明確化と問題定義駆動方式」 です。
構造関係を意識した「明確な目的記述」、精緻な言語化による「問題定義」を行い、定義された問題への解決策が「プログラムの実装と実行」や「実行して模索」であれば、ぜひ実装・実行しましょう。
一方で、「精緻な言語化で定義された問題」に対する「解決策」を確定するあたり、解決策の各候補について「思考実験」を実施した結果、それで十分な結論・暫定解が導出できた場合は、わざわざ実装・実行する必要はないかもしれません。
研究・開発での「プログラム実装」に限らず、Biz面での各種イベント開催や講演・執筆など、何らか大き目の施策についても同様です。
上記以外にも多々該当するタイプの仕事は存在しますが、「実行するとリソース消費が大きい仕事（タスク）」については、事前の綿密な「思考実験」を意識すると良いでしょう。
重要な点は、「何かやれば、そりゃ、嬉しいことは何かしらは得られるよね」という認識です。
しかしながら時間とリソースを消費するので、その分、他に実行可能であった別の施策が実施できなくなる点に注意してください。そしてその別案の方がより大きなインパクトがあった可能性もあります。
「プロダクトの機能（Function）の実装」であれば、その実装コストとその機能から得られる（直接的・間接的）経済的リターンの比較をすれば良いのかなと簡単に思えますが、比較軸はそれだけではありません。
上述した「機会費用」の概念の通り、「別の異なる機能」の実装にリソースを割けば、もっと良いリターンが得られる可能性があります。その点も踏まえて、各選択肢を事前に「思考実験」することになります。
何かを実行する前には、しっかりと事前に「思考実験」を実施して、選択肢を絞ります。
そして思考実験だけでは不明確な点がある場合や、実際に実行することで思考するだけでは得られない大きな価値が得られると想定された場合に、実行へと移ります
7. システムシンキングを土台とした仮説思考方式
再掲ですが、仕事のおいては「Issue（≒課題・大タスク）」に対して、「〇〇を目的に、△△という制約条件の下で◎◎を達成させてください」といった、精緻な言語化を伴う問題定義を自らに課します。
その後は 「その課題の原因仮説は◇◇であり、そのため XX という解決策を実施します」 という「解決策の策定」フェーズになります。
ここで上記の「原因仮説◇◇」を導出する際には、「システムシンキング（問題を全体として捉え、因果関係や相互作用を理解しながら解決を目指す思考法）」 の実践を心がけます。
システムシンキングの流れを簡単に紹介します。
- まず「Issue（≒課題・大タスク）」に内包されている「構成要素」、もしくは関連している「構成要素」を書き下します
- そして各要素間の関係性を矢印で繋いで図解します（影響を与える要素から別要素に矢印を書く）
その結果、Amazonなどで有名な「フライホイール（弾み車）」と似た「課題・大タスクの全体像」が描かれます（以下、一例です）。
システムシンキングにおいて各構成要素の粒度は、独立に測定可能、もしくは問題定義が可能な大きさが望ましいです。
そして、「問題対象がこのようなシステム（≒方程式）で構成されているので、仮説◇◇が考えられ、システム内のこの構成要素にテコ入れすると全体としての最大化に繋がります」や、「全体の中のボトルネックになっている要素はここなので、この要素の改善が最大効果を生みます」といった、ロジックを通してから（≒ストーリーを構築してから）、実行に取り組むようにします。
このロジック（ストーリー）こそが、仮説です。
上記のように、大きな問題（対象システム全体）を俯瞰して捉え、構成要素群のロジックに基づく「全体最適化（もしくはKGI達成）」に繋げる仕事方式が、「仮説思考型の仕事方式」 であり、システムシンキングを活用した仕事の進め方です。
問題全体を俯瞰せず、「目の前の小さな問題だけを見て、その原因仮説を考え、解決策を策定し、実行する」という、「木を見て森を見ずの状態」 を避けるように気をつけます。
また、現在取り組んでいる仕事（タスク）は、「全体の中のどこに位置しているのか、その前後にはどのような仕事（タスク）を想定しているのか」 についてはきちんと言語化して整理しておき、大きな問題（対象システム全体）のどこに今いるのかを明確にしておきます。
仮説思考型の仕事方式は「思いつき」や「セレンディピティ」を否定するわけではありません。
「思いついた内容」を即実行ではなく、それをヒントにシステムシンキングを実施し、システムの構成要素の列挙と全体像の作成を試みます。
システムの構成要素を整理すると、その「構成要素」が満たしている、もしくは満たすべき「性質・特性・特徴」が見えやすくなります。
そして、この「構成要素が満たすべき性質・特徴」の情報は、問題解決に向けた仮説立ての良い手がかりになることが多いです。
なぜなら「構成要素が満たすべき性質を現状きちんと満たしていない場合には、最終ゴールへの到達が難しくなる」という点から逆算して思考できるからです。
構成要素が満たすべき性質（暫定解でも良い）が言語化できれば、そこからロジック（ストーリー・仮説）を立てやすいです。
「思いついたこの施策を頑張ったら今期は最終的にKGIを達成し、約〇〇%向上しました」や、「浅い仮説がたまたまヒットしただけ」ですと、その成果の再現性が乏しいのは想像できるでしょう。
この調子で進めると、翌期や翌年は達成できないかもしれません。
継続的に成功・達成、成長し続けるためには、対象をシステムとして捉えることが重要です。
そして重要な点がもう一つあります。
それは時間経過とともにシステム内で変化する「ボトルネック部分」に注意を払うことです。
ただしこれはシステムの「現在のボトルネック部分」に注意を払うという意味ではありません。
この先、「短・中期的に次のボトルネックになる場所・要素」に注意を払い、先手を打つ という意味です。
システムシンキングを活用すれば、事前対応・予防措置がとれます。
「事前対応」はボトルネックが顕在化して悪影響を及ぼし始めてからの「事後対応・応急的解決」よりも、少ないリソースで実行可能である場合が多いです。
ボトルネックが生まれてから（正確にはボトルネックは常に存在するので、ボトルネックが顕在化して、全体や最終ゴールへの悪影響を生むようになってから）、応急措置的な対応・解決策に追われることのないように心がけます。
例1：〇〇をする人員が足りないので今、これを進められません
⇒〇〇をする人員を先に確保しておくように事前対応しておいてください
例2：〇〇を実装するのに、手法Aでうまくいくか判断がつきません
⇒スパイクの時間（チケット・スプリント）を先に確保・実行して、事前対応しておいてください
など
応急対応・解決策に時間・リソースを奪われるのではなく、常に先手を打つように心がけます。
これもまた、「システムシンキングを土台とした仮説思考方式」の仕事方式です。
もちろん実際の仕事（とくに研究系でなく、人や顧客や企業、社会、国家などが絡む仕事）は、非常にノイジーな環境下のシステムであり、想定通りにいかないことも多いです。
しかしそれでもシステムシンキング方式で進める方法は、そうしないよりは有用だと私は感じています。
問題対象を構成要素に分解し、要素間の関係性を整理して、システムシンキング（≒方程式化）で全体像を描く。そして全体を俯瞰して、倒すべきはここであると仮説立てしてから実行する。その実行結果・成果として、「この要素が〇〇%向上したので、KPIの〇〇が向上し、最終的なKGIを達成、〇〇%向上しました」、といったストーリーを描くイメージで取り組みます
8. LNOフレームワーク方式
「LNOフレームワーク」 は、PM・PdM（プロダクトマネジメント）の文脈で有名な「タイムマネジメント、および仕事（タスク）の優先度整理」の手法です（後ほど外部紹介記事も案内します）。
このフレームワークはPM・PdMの方だけでなく、どのような職種の方も活用できる手法です。
最初に「LNOフレームワーク」の概要を説明します。
LNOでは仕事（タスク）のタイプを以下の3種類に分類します。
- Leverage（L: レバレッジ）
- Neutral（N: ニュートラル）
- Overhead（O: オーバーヘッド）
「Lタイプ」は最も重要な仕事であり、その仕事成果が10倍以上のインパクトを生み出す性質を持ちます。
そのため「レバレッジ」という名称が付けられています。
私の感覚では、「後続の仕事や他の仕事（タスク）に大きな影響を与え、それらの質を高めたり、より良い仕事（タスク）を生み出したりする仕事タイプ」 と捉えています。
例えば、「戦略策定・全体構成の設計」などが代表です。
こうした仕事内容は後続の仕事（下流の仕事）や他の仕事（タスク）に大きな影響を与えます。
Lタイプの仕事は一般に抽象度が高く、上流の仕事（もしくは土台的な要素）であることが多いです。
その他のLタイプの仕事例としては、とあるコンセプトやプロダクト・ソリューションに関する、「その中心部分や差別化要素となる部分の定義と構築」などが挙げられます。
「Nタイプ」は時間とリソースを費やして、一定の成果を生む仕事（タスク）です。
実行しても他のタスクの質を高めるまでの影響・成果は生まれず、その成果のレバレッジが約 x1倍であるため、「ニュートラル」と呼ばれます。
ですが、Nタイプだから実行しなくても良い無駄タスクという意味ではありません。
ただし、「成果の質としてどのレベルを目指すべき仕事（タスク）か？」 と問われれば、Nタイプは「合格点が取れれば良いレベル」であり、費やす時間などの注力度合い（リソース投資）は「Lタイプ」よりも低くします。
なお、「Lタイプ」の場合、その目指す成果の質は「自分史上最高得点」です。
「Oタイプ」は実施に時間を費やしても、インパクトがほとんど生まれない仕事（タスク）です。
誰かが実行する必要がありますが、自分がやる必要は必ずしもありません。
そして成果の品質は「最低合格点が取れればよい」というレベルです。
そのため注力度合い（リソース投資）はLやNよりもさらに低めにします。
以上が「LNOフレームワーク」の概要です。
以下にLNOフレームワークに関するおすすめ記事を紹介します。
- 日本語参考記事（曽根原さん [X（旧Twitter）] の御講演より）
- 本家（シュレイヤスさん）の最新記事
続いては「LNOフレームワークでの仕事方式」について、私なりの解釈・進め方を解説します。
まず第一に、多くの人は「Nタイプ」の仕事に夢中になりがちです。
Nタイプの仕事は、時間を費やして完了させる仕事タイプが多いです。
例えば "単なる実装" など、下流の仕事が多いです。
また、Nタイプの仕事は、自分のコンフォートゾーンやそのちょっとだけ上レベルの難易度であることが多く、さらに 「実行に取り掛かりやすい」 という性質があります。
そのため多くの人は無意識的に、このNタイプの仕事に時間やリソースを費やしてしまいます。
さらに他にも、以下に示す2つの落とし穴があります（と私は感じています）。
- Nタイプの仕事（タスク）は自分にとってほどほどに取り組みやすいがため、「よし、私は今日も仕事した！」という、自己満足感と充実感が生まれやすい
- 周囲に、「私はさぼっていません、私は仕事を頑張っています」という、保身とアピールを意識的・無意識的に図りやすい
（一般に周囲の人は、とある人が取り組んでいる仕事がLタイプかNタイプかや、その仕事の困難さを簡単に把握できないので、Lであろうが、Nであろうが、たくさん仕事（タスク）をしている人を評価しがちです）
続いて「Oタイプの仕事（タスク）」について。
Oタイプの仕事（タスク）は、やらなくても良いとまでは判断できませんが、少なくとも注力度合い（リソース投資）は最低限にすべきです。
自分やチームが、このOタイプに注力し集中している状況は最悪です。
気持ち的には最低合格点で即座に完了させる（もしくは前章で紹介した「思考実験」で完結させる）で済ませたいです。
このOタイプの仕事も、仕事に夢中になっているときはNタイプのように感じてしまいます。
そのため、チームで振り返りを実施したり、上司からのフィードバックをもらったりして、自分が実施していた仕事が実はレバレッジが1倍すら効いていない、非効率な内容でなかったかの内省やフィードバックが大切です。
「1年前のあの仕事って結局やった意味あったの？」、「 半年前のあの仕事って、結局今期の取り組みの何に繋がっているの？」 みたいなものは、意外に多いのではないでしょうか（少なくとも私の場合は多いです）。
本章の最後に「Lタイプ」の仕事について。
Lタイプの仕事はその性質として、一回の実行で完了できる仕事ではありません。
目指すべき品質は、「自分の中での完璧・自分史上最高得点」です。
そのため、継続的に改善し、見直し続ける仕事タイプになります。
このような「Lタイプ」の仕事を扱ううえで便利な言葉が 「暫定解」 です。
「暫定解」という単語はここまでの文章でも使用しましたが、現状の情報とリソース投下の結果導出できている解・結論です。
この「暫定解」をどんどんブラッシュアップしていくという考え方を意識すると動きやすいです。
多くの人は 「Lタイプの戦略洗練系・全体俯瞰系」よりも、「Nタイプの実行系」に走りがちです。その結果、Nタイプに時間とリソースが奪われ、「Ｌタイプの仕事に取り組む余裕がありません状態」になりがちです。
LとN、そしてOに費やす時間のバランス取りは難しいですが、重要な点は、「私は本当にやるべきLタイプの仕事に時間を費やしているだろうか？」と定期的に振り返ることです。
私が実践しているLNO方式は、「この曜日のこの時間は、Ｌタイプの仕事をやると決めており、その他の予定をブロックする。そしてＬタイプの仕事として解決すべき問題を精緻に言語化して定義しておき、その時間は、自分自身にそのお題を出題してそれを解くことに集中する」、という作戦です。
また自分の意識をLタイプの仕事へと変えるために、極力、仕事場所もNタイプの仕事場所とは変えるようにしています。
なお、Ｌタイプの仕事は集中して考える系が多いので、「一度に長い時間」を確保する必要はありません。
どちらかというと、「ブラッシュアップを繰り返すための回数」を確保する方が重要だと私は感じています。
仕事（タスク）の優先度整理は「アイゼンハワー・マトリクス」が一般的ですが（緊急度 x 重要度の2軸マップ）、「LNOフレームワーク」での優先度判断についても、自身やチームで意識すると良いでしょう
9. 分からない部分を先に倒す方式（別名：村を出たら最初にラスボス方式）
仕事では、「きちんと計画を立て、重要な部分から取り掛かるようにします」。
「いやいや、そんなのは当たり前でしょう」と感じるかと思います。
しかし仕事の難易度が高く、抽象的であったり、上流過程の仕事であるほど、その仕事は「不確実性の高い部分」を多く含むため、仕事全体の中に 「分からない部分」 が必ず存在します。
「分からない部分」が存在していると、多くの人は計画を立てる際、その「分からない部分」を回避して、分かる部分だけを対象に細かく計画を立案し、実行に移りがちです。
すなわち、「分からない部分」は後回し（≒放置）して、分かる部分から実行に移りがちです。
ですが「不確実性が高い and/or 情報不足で分からない部分」は、全体戦略上、非常に重要であるケースが多いです。
とはいえ、すぐには分からないから後回しにしがちであり、思考実験しづらいから避けがちです。
「分からない部分」への取り組みは、前章で解説した「Lタイプの仕事」であり、心理的にも取り掛かりにくいです。
重要な点はまず、この「分からない部分」が全体にとって本当に重要な部分なのか、の判定を下すことです。
1か月後の1時間天気予報はほぼ分からない部分ですが重要ではありません。
一方で、大きな仕事の完遂に向けて、この「分からない部分」が重要なブロックであれば、逆に分かれば後続タスクに大きなインパクトを与えてくれます。
最初の計画立案時には、「分からない部分」については、ひとまず仮説思考と思考実験で暫定解を導出して仮置きをし、「分からない部分」をきちんと盛り込んだ「全体像の描画と全体計画」を立案します。
そして仕事の実行順序は、この「分からない部分」を倒すことからはじめます。
多くの人は倒しやすい部分（Ｎタイプ）から取り掛かりがちです。
その方が、仕事をした充足感を感じますし、私はさぼっておらず仕事しています感を無意識的に周囲にアピールできますので（ここは前章で解説した通りです）。
例えばRPGゲームであれば、一番倒すのが困難なラスボスは、その名の通り、最後に倒します。
しかし仕事は「RPGゲーム」ではありません。
仕事においては、最初の村から出たら、いきなり一番難しい「分からない部分」≒ラスボスを倒しにいきます。
最初の村で揃えた初期装備でラスボスに挑むので、当然ですが倒せないでしょう。
ですが、それで良いのです。
ここまでに解説した通り、その試行で暫定解が求まればそれでよく、Lタイプの仕事なので、その暫定解をどんどんブッシュアップしていきます。
イメージとしては、何回もいろんなタイミングでラスボスに挑む感じです。
そしてそのラスボス（分からない重要な部分）を倒せたタイミング次第で、その大きな仕事のストーリーは変化するでしょう。
「分からない部分」について無意識的に迂回したり、後回しにせず、まっさきに倒す、もしくは倒せなくても暫定解を得て全体を進める方式を意識します
10. 情報発信駆動方式
記事も長くなってきましたが、最後の項目です。
仕事において「情報収集」は非常に重要です。
「自分の身体」に例えると、食事等（≒入力）と行動・運動など（≒出力）の結果として自分の身体が構成されるように、「仕事力」は、自分の脳に入力した情報と出力した行動および思考から構成されます。
そのため、「高品質な情報 と 自分の思考と行動に対する高品質なフィードバックが得られる環境」に常に自分自身を置くように意識すると良いでしょう。
私が実践している「情報収集手法の詳細」（チェックしているサイトや登録しているニュースレターなど）を以下の記事で紹介しています。こちらもご参照下さいませ。
なおフリーランチ（タダ乗り）は難しいものです。
「自分は与えないのに、得ることだけが叶う」という、都合の良い状態には到達しづらいです。
高品質な情報を得るには、まず自分自身が可能な限り少しずつでも、「良質な情報を発信する存在になること」を意識すると良いでしょう（自らの学びについて、ブログ記事を執筆するなど）。
初期の頃の発信内容は粗末なレベルで問題ありません。自分へのメモ・備忘録レベルで良いです。
高品質な情報発信者も（その多くは）、最初は粗末なレベルの発信から始まり、成長して今の状態に至っている方々が大多数です。
また「外向けに発信する行為」は「他人に教える行為」に近く、自分がその内容をきちんと丁寧に理解する必要があるため、内容への理解が深まります。
そのため、結果的に自身の成長にも繋がります。
定期的に情報発信を実施しながら自らの学びを深め、情報発信を通じた自身の成長・育成方式を意識します
11. さいごに
長い記事でしたが、最後までお読みいただき、ありがとうございました。
最後に10方式を再掲します。
- 「パーキンソンの法則」を意識した期限設定方式
- 結果と成果を区別した成果優先方式
- 構造整理を実施してから実行方式
- 目的の明確化と問題定義駆動方式
- 決着をつけてから次に進む方式
- 思考実験優先方式
- システムシンキングを土台とした仮説思考方式
- LNOフレームワーク方式
- 分からない部分を先に倒す方式（別名：村を出たら最初にラスボス方式）
- 情報発信駆動方式
上記の10法則の根底にある私の考え方として、「仕事の本質」とは「高度な不確実性」に対する迅速かつ効果的な対応と解決である、です。
「不確実性の少ない仕事（タスク）」は、まずまず簡単にプログラムで置き換え可能です（なケースが多いです）。
そして「LLM・AI・AI-Agent」がますます勃興するであろう2025年・2026年以降においては、「低難易度～中難易度の不確実性」 レベルの仕事にまで、AIプログラムやAI-Agent（AI-ワークフロー）は進出してくるでしょう（度合いは不明ですが）。
その結果ホワイトワーカーに残る仕事は、「本質的に高難易度の不確実性を含むもの」がメインとなり、そのような仕事に立ち向かう能力がこれまで以上に重要になります。
もちろんこれまでの時代においても、「不確実性への迅速かつ効果的な対応と解決」は経営や仕事の本質におけるメインファクターでした。
これからの時代は、AI技術によりさらに進展していき、上記の重要性がより向上する（と私は考えており）、その点を踏まえた「仕事術（仕事方式）」が、本記事で紹介した10方式です
（そして本記事の内容もまた暫定版であり、ブラッシュアップしていきます）。
また、本記事では仕事術＝仕事の ”やり方” について、私個人（およびチーム）の例を紹介しました。
注意していただきたい点は、”やり方” とはその土台にある、「考え方・価値観・バリュー・メンタルモデルなどから構成される、”あり方”」 から生まれるという点です。
私には私のあり方があるから、本記事のようなやり方になります。
「あり方」が全く異なる状態の人が、「やり方」だけを真似する（もしくは他人に押し付けられる・指導される）といった場合、いくら良い「やり方（方式）」であったとしても、その効果は発揮されづらいです。
この点は注意が必要となります。
偉そうに色々な手法を解説しましたが、私もまだまだ修行中であり、上述の内容を心掛けて日々精進の最中です。どれも完璧に実践できているわけではありません。
ですが本記事で紹介した10個の仕事方式については、とくに意識的に仕事を進めています。
以上、拙い文章でしたが、読者の皆様にとって本内容に何かしらお役に立つ部分があれば幸いです。
長文を一読いただき、誠にありがとうございました。
小川 雄太郎
株式会社松尾研究所 シニア・リサーチャー。「知能を創る」PJTに従事
Discussion