仕事術は、いくら集めても体系になりません。
10年分の工夫を並べたところで、できあがるのは束であって構造ではない。ぼく自身、仕事術を書き続けた末にそこで手が止まりました。
理由ははっきりしています。工夫はどれも「ある場面での正解」でしかないからです。場面が変われば効かなくなる。だから次の工夫を探しにいく。その繰り返しに出口がありません。
そこで、工夫を足すのをやめました。かわりに手をつけたのが、工夫の一段下にある土台です。その土台を、仕事の言葉へまるごと翻訳しました。土台とは、ぼくが大学院で修めたコンピュータサイエンス（CS）のことです。
できあがったのが『仕事に効くコンピュータサイエンス』、全76ページ。無料で公開しました。ただ、この決断の起点は本を作ろうと思った日ではありません。8年前、あるBPR案件の現場です。
誰にも頼まれていないのに、76ページ書いた#
『仕事に効くコンピュータサイエンス』は、序章と全12章、終章とあとがきで構成した全76ページのWebブックです。誰にも頼まれていません。出版社もついていない。こちらで無料公開しています。
作りはこうなっています。
- コードを一行も書かせない 数式も端末も出てこない
- 1ページ10分ほど 隙間時間で読み切れる分量
- スマホ・音声読み上げでも通る文体 図がないと分からない説明を置かない
- 無料 会員登録もなし
序章のタイトルは「仕事術の本を閉じて、CSの教科書を開く」。そこから「マルチタスクの嘘」「その資料、先週も作りませんでしたか」と続きます。
最後は「その仕事、あなたが休んだら止まりますか」を経て、終章「CSという道具箱の持ち歩き方」で閉じる構成です。
CSと聞いて身構える人ほど読んでほしい。だからそこは徹底しました。
では、なぜ誰にも頼まれていないものを76ページも書いたのか。一言で言うと、仕事術をこれ以上足しても意味がないと確信したからです。工夫を百個集めるより、教科書を仕事の言葉に翻訳したほうが早い。あとがきにはそう書きました。
ただ、あとがきに書かなかったことがあります。その確信は、本を作る過程で生まれた発見ではありません。8年前から持っていたものを、ようやく形にしただけでした。
2018年、BPRの案件で「これ、コンピュータサイエンスそのものだ」と思った#
起点は2018年ごろ、業務プロセス改革（BPR）の案件を手掛けていたときです。現場で交わされている議論が、CSの教科書に書いてあることとそのまま重なって見えました。
ぼくにはもともと、省力化や効率化に価値を見出す回路があります。根本的な問いは一つだけ。限られたリソースを使って、最大限の効果を得るにはどうするか。
おそらくエンジニアの方々は皆そう思っているはずです。IT技術の世界では、この問いはアルゴリズムの領域で論じられてきました。少ないリソースで、なるべく多くの価値ある成果を導き出す。でも、それは普段の人間の仕事においても全部そうでした。
会社における人間は、メカニズムの一部にすぎません。感情を持った歯車ではあるけれど。
（自分勝手な物言いに聞こえるのは承知のうえです。それでもぼくは、ぼんやりした精神論より、この見方のほうが人を楽にすると思っています。）
BPRの現場で言われることを並べると、対応物がすぐ浮かびました。
| BPRで言われること | CS・ソフトウェア工学での対応物 | 該当する章 |
|---|---|---|
| 不要な業務プロセスの棚卸し | デッドコードの削除 | 9章 |
| よりショートカットできる効率的なプロセスの構築 | アルゴリズムの改善・計算量削減 | 7章 |
| 1箇所に集約できるものを集約して一元化 | 共通化・DRY・シェアードサービス | 8章 |
| 標準化・自動化で単位コストあたりのスループット向上 | リファクタリング／リアーキテクチャ | 3章・6章 |
同じ学問分野の考え方が、仕事の効率化という文脈にもそのまま適用できる。そうずっと長らく思っていました。
あとがきでは「10年分の記事を読み返して、あるとき気づいた」と書きましたが、正確ではありません。あれは発見ではなく、8年越しの回収です。
ただし、この確信にはさらに前史があります。BPRの案件より1年前、2017年のぼくは自著の原稿を抱えながら、まったく別のことを疑っていました。
実は、自分の本を書きながら「これに意味があるのか」と思っていた#
本を出すことは、書き手にとっての成就。世間ではそう受け取られます。ぼくの場合は違いました。2017年12月1日に出した自著を、ぼくは疑いながら書いていたからです。
『外資系コンサルは「無理難題」をこう解決します。』という本でした。「本を書く・本を出す」というイベント事に食いついて、正直に言うと舞い上がっていました。
けれど書いている最中、ずっと引っかかっていたことがあります。ビジネスノウハウ本を執筆することに、果たして意味があるのだろうか。
その気持ちは、担当編集者の方には伏せておきました。発売直前でしたし、言えるはずもありません。続編や別の書籍に手をつけなかった最大の理由が、これです。
引っかかりの正体は、繰り返しでした。あらゆる表現で、同じことを繰り返し言っている。根本となる考え方は変わらないのに、それを伝達する手法だけを、あの手この手で変えています。だったら最初から、その根本たる考え方を学ぶ方がいいのではないか。
誰かに何かを伝えるとき、語り口や事例の差異が効くことは重々理解しています。「この人の本だから読みたい」「この人の書き方だから分かった」は確実に存在する価値です。
それでも、CSを大学院で修めた人間としては、そこは本質論ではないと感じてしまう。この感覚がどうしても抜けませんでした。
だから、書き直したい章や項目は実際のところ、ほとんどありません。中身が間違っていたとは今も思っていない。ぼくが疑っていたのは、中身ではなく枠のほうでした。
発売の半年前に、その構造を自分で記事にしていた#
疑いが後付けの記憶でないことを示す物証があります。自著の発売のちょうど半年前、2017年6月19日の記事です。タイトルは『インターネット時代におけるビジネス本の価値と輪廻』。
骨子はこうです。
- ビジネスノウハウ本はピラミッドの形をしている。上に行くほど抽象的な法則や原則、下に行くほどシチュエーション特化のHow
- 具体的な話は、もうネットに転がっている
- だから下層の本の差別化要素は「著者の経験による裏打ち」と「語り口」の2点だけ。すなわち本の価値は事例にある
- 読者に響く事例は時代によって変わる。事例の賞味期限が、ビジネスノウハウ本の賞味期限
- 死にゆく本たちにかわり、新たな時代の事例にもとづく本が生まれる。輪廻
輪廻の構造を自分で図解した半年後に、ぼくは自分でその輪廻に加わりました。今読み返すと、なかなかの間の悪さです。
そして9年後に書いた『仕事に効くコンピュータサイエンス』は、ピラミッドの上ですらありません。法則や原則よりさらに下、それらを支えている土台のほうを書いています。
輪廻から降りるというのは、ピラミッドを登ることではありません。床を掘ることでした。
もっとも、床を掘れという話には、すぐに反論がつきます。3ヶ月前のぼく自身が、それに近い主張へ異を唱えていたからです。
「CSを全部学べ」とは違う、と3ヶ月前に書いた#
3ヶ月前のぼくは「CSを全部学べとは少し違う」と書いています。今回の翻訳は、その前言撤回ではありません。「学べ」と言わずに済ませるために翻訳したからです。
2026年5月31日の記事で、ぼくはこう書きました。
低レイヤの仕組みを理解することが大事なのは間違いありません。でもぼくが書きたいのは、もっと広い話です。ITエンジニアに限らない、すべてのビジネスパーソンに効く「基礎力」の話。
「すべてのITエンジニアは論理回路もレジスタもアセンブリも理解しなければならないのか」。そう受け取られかねない主張には引っかかる、とも書いています。
CSの基礎とビジネスの基礎は、対象こそ違えど構造はまったく同じ。当時からそこが言いたかったことでした。
コードを一行も書かせないのも、数式も端末も出てこないのも、同じ理由です。学べと言うだけなら翻訳はいりません。原著を読めと言えば済みます。仕事の言葉に置き換える手間をかけたのは、原著を読まずに済ませてほしいからです。
なお、同じ記事に書いた「AIはリトマス試験紙だ」という話は、今回のWebブックのあとがきとも重なります。論証をここで繰り返すことはしません。詳しくはそちらの記事に書いています。
「それ、AIでも書けますよね」への答え#
書けます。実際、ぼくもAIと壁打ちをしながら書きました。ここを隠すつもりはありません。
「CSの概念を仕事に翻訳して」とAIに頼めば、それらしい原稿は出てきます。章立ても、たとえ話も出るでしょう。だから「AIでも書ける」という指摘は、そのとおりです。
ただ、借りられないものが2つあります。
- 8年間ずっと同じ問いを持ち続けた事実 2018年のBPR案件から今日まで、問いは一度も変わっていない
- 12章のうち、どれがどの現場に効くかという選択の順序 どの章を先に置くかは、効かなかった経験の側から決まる
この2つは、プロンプトに書けません。書けたとしても、出てくるのは借り物の記述であって、判断の履歴ではない。
分かりやすく伝える部分をAIに手伝ってもらって、ぼくは初めて、書けなかったものが書けました。自分の思ったことを包み隠さず吐き出したうえで、伝えるところを任せた。そこに嘘偽りは一切ありません。
10年近く書けなかったものが短期間で形になったことには、正直、複雑な気持ちもあります。それでも、出さないよりはるかにいい。
まとめ：これは、コンピュータで言うと何の問題に近いか#
工夫を百個集めるより、土台を一つ借りたほうが早い。8年かけて出た結論は、それだけです。
ビジネス書の輪廻は、事例の賞味期限で回っています。回り続ける輪から降りる方法は、より新しい事例を持ってくることではありません。ピラミッドの下、床のほうに手を入れることでした。
そこに置いてあったのがCSです。限られたリソースで最大の効果を出すために、先人が積み上げてきた体系。翻訳さえすれば、そのまま仕事に効きます。
だから、次に仕事が詰まったとき、工夫を探しにいく前に一度だけ聞いてみてください。
これは、コンピュータで言うと何の問題に近いか。
答えが浮かばないなら、『仕事に効くコンピュータサイエンス』に12個の見取り図を置いてあります。あなたのその詰まりは、何章の話でしょうか。
