稼働率と生産性
—— 人を時間で測ることの限界

注記：この記事は稼働率管理そのものを否定するものではありません。筆者自身、コンサルティングファームやSES企業での経験を通じて稼働率管理の有効性を理解しており、状況に応じてその導入を支援することもあります。ここで論じるのは、稼働率という指標が持つ構造的な限界と、AI時代におけるその変容です。

1. 稼働率が測るもの

稼働率とは、労働時間のうち売上に直結する業務（ビラブル業務）に費やした時間の割合だ。

• コンサルティングファーム — 稼働率80%が目標。クライアントワークに費やした時間÷総労働時間。残りの20%は提案活動、研修、社内業務
• SES（システムエンジニアリングサービス） — 人月単価×稼働率が売上。エンジニアが客先に常駐している時間が収益の源泉
• 受託開発 — 見積もりは人月ベース。「この機能は3人月で開発できます」。時間が単位であり、通貨であり、成果の尺度
• 法律事務所 — ビラブルアワー制。弁護士の時間単価×稼働時間が請求額

これらに共通するのは、「時間を売っている」という構造だ。人間の労働時間を細分化し、価格をつけ、顧客に販売する。稼働率は、その販売効率を測る指標として合理的に機能してきた。

2. 稼働率が測れないもの

だが、稼働率が測れないものがある。

考える時間の価値。13種類の外部サービスを検討してすべて不採用にした——この判断にかかった時間は、ビラブルではない。だがこの判断が、1000年の持続性を設計している。稼働率の世界では「何も導入しなかった時間」はゼロ時間と等価だ。だが設計判断の質は、考えた時間の長さとは相関しない。

やらない判断の価値。Google Analyticsを入れなかった。Salesforceを導入しなかった。App Storeに出さなかった。これらは「やらなかったこと」であり、稼働率ゼロの成果だ。だがこの「やらなかったこと」が、ランニングコストゼロと外部依存ゼロの構造を生んでいる。稼働率は「やったこと」しか測れない。

成果の時間軸。稼働率は月次で集計される。だがトキストレージの成果が判明するのは、10年後、100年後、1000年後だ。今月の稼働率レポートに「1000年後にコンテンツが届く設計をしました」とは書けない。

稼働率は「どれだけ働いたか」を測る。
だが「どれだけ正しく判断したか」は測れない。

3. 人月の神話、再び

フレデリック・ブルックスが1975年に『人月の神話』で指摘したことは、50年後の今も変わらない。人月は見積もりの単位としては便利だが、成果の単位としては根本的に誤っている。10人で1ヶ月の作業を、1人で10ヶ月でこなせるとは限らない。そして1人が10分で下せる設計判断は、10人が100分かけても出せないことがある。

トキストレージの設計は、人月で見積もれない。「HTML + CSS + JavaScript + WASMだけで1000年持つサービスを設計する」——これは何人月の作業か。答えようがない。なぜなら、この設計判断に至るまでにAWS、GCP、Azure、Salesforce、Datadog、Fortify、Jira——全スタックをハンズオンで回した経験が必要だからだ。その経験を人月に換算することはできない。

人月は「時間の量」を測る。だが設計判断に必要なのは「経験の質」であり、それは時間の量に比例しない。

4. AIが壊す等式

「時間をかけたこと＝価値を生んだこと」という等式が、AIによって崩壊しつつある。

かつて、Webサイトの全ページからGoogle Fontsを除去する作業は、手作業なら数日かかっただろう。510ファイルのHTML、3つのCSS、README——一つひとつ開いて、該当行を削除して、保存して。ビラブル時間として計上すれば、相当な人月になる。

Claude Codeで実行したら、数分で終わった。

この事実は、稼働率の前提を根底から揺るがす。同じ成果を、100分の1の時間で出せるとき、稼働率という指標は何を測っているのか。時間を売るビジネスモデルで、AIが時間を圧縮したとき、売るものがなくなる。

コンサルティングファームが「この調査に3人月かかります」と提案した案件を、AIが3日で完了させる。法律事務所が50時間のビラブルアワーで請求していたリサーチを、AIが5時間で終える。SESが「エンジニア3名×6ヶ月」で見積もっていた開発を、AIを使えるエンジニア1名が2ヶ月で仕上げる。

稼働率が高いことが価値だった時代は、終わりつつある。

AIは時間を圧縮する。
時間を売るビジネスモデルは、売るものを失う。

5. 稼働率100%の罠

稼働率が高いことは、組織にとっては望ましい。人的リソースを最大限に活用しているからだ。だが、稼働率100%の人間は「考える余白」を持たない。

すべての時間がビラブル業務で埋まっている状態で、「このプロジェクトにSalesforceは本当に必要か」と立ち止まって考える余裕はない。クライアントが「Salesforce導入をお願いします」と言えば、稼働率を維持するために導入する。導入しないという判断は、ビラブル時間を減らす判断だからだ。

引き算の設計には、稼働率の外にある時間——考える時間、調べる時間、迷う時間、そして「やらない」と決める時間——が必要だ。稼働率80%を目標とする組織で、残りの20%は提案活動と研修に充てられる。「何を導入しないか考える時間」は、どの予算項目にも計上されない。

6. トキストレージは稼働率の世界では生まれない

トキストレージの開発プロセスを、稼働率の世界で記述してみる。

• Google Analytics検討 → 不採用：ビラブル時間ゼロ
• Salesforce検討 → 不採用：ビラブル時間ゼロ
• Firebase検討 → 不採用：ビラブル時間ゼロ
• App Store申請検討 → 不採用：ビラブル時間ゼロ
• Stripe検討 → 不採用：ビラブル時間ゼロ
• 13項目の外部サービス検討 → 全項目不採用：ビラブル時間ゼロ

稼働率レポート上、この期間は「何もしていない」と等価だ。だがこの「何もしなかった」時間が、ランニングコストゼロの構造を生み、外部依存で死なない設計を生み、1000年の持続性を設計している。

稼働率の世界では、「やらない」に価値はつかない。だが「やらない判断」にこそ、最大の価値があることがある。稼働率100%の世界からは、トキストレージは絶対に生まれない。考える余白がなければ、引き算の設計はできない。

7. 時間という概念の溶解

問いの質と判断の質が重要性指標として優先される状況では、「働いた時間」は意味を消失する。

フルフレックス制度は、「何時に働いてもいい」という自由だ。だがそれは依然として「働いた時間」を前提としている。コアタイムなし、フレキシブルタイムのみ——しかし1日8時間、月160時間という枠は変わらない。出勤という概念も同様だ。リモートワークで「出勤」の物理的意味は薄れたが、「勤務開始」「勤務終了」のログは残る。

トキストレージの開発において、「出勤」は存在しない。「勤務時間」も存在しない。深夜3時に設計判断を下すこともあれば、日中に散歩しながら「なぜこのサービスを入れないのか」を考えることもある。散歩の時間はフルフレックスの枠にすら入らない。だが、その散歩中の判断が1000年の持続性を決定することがある。

有給休暇、残業時間、休日出勤——これらの概念は「労働時間」が測定可能であることを前提としている。だが「13種類のSaaSを検討して全部不採用にする」という判断は、いつ行われたのか。会議中か、通勤中か、入浴中か。判断が生まれた瞬間を特定することはできない。そして特定する意味もない。

問いの質が価値を決めるとき、
「何時間働いたか」は問い自体を失う。

8. 生産性の再定義

AIが稼働率の等式を壊した後に残るのは、「生産性とは何か」という問いだ。

稼働率の世界では、生産性＝単位時間あたりのアウトプット量だ。1時間で10本のメールを書くのと、1時間で1本の設計判断を下すのでは、前者の方が「生産的」と見なされる。

だが、AIが10本のメールを10秒で書ける時代に、メールを書く速度は生産性の指標にならない。残るのは「何を判断するか」——AIには委ねられない判断の質だ。

トキストレージの生産性は、稼働率では測れない。測るべきは「1000年後にコンテンツが届く確率を、今日の判断がどれだけ上げたか」だ。だがこの指標を計測する方法は、まだ存在しない。

稼働率は「どれだけ動いたか」を測る。
生産性は「どれだけ正しく動かなかったか」を含む。