# チャットツールでは限度があります、そこで QWINCS の出番！

## サマリー
- Slack や Teams などのビジネスチャットだけでは限度があります
- 主なコミュニケーションツールには実は六種類あります、QWINCS です
    - Q&A
    - Wiki
    - Issues(Ticket)
    - Note
    - Chat(Business Chat)
    - Sticky board
- チャットは QWINCS でいう C にすぎません。他にも 5 つあります

## 背景

### 未だにチャットツールのみという悲しい現実
普段のコミュニケーションは **エンジニアであっても** チャットに頼っているのが現状でしょう。Slack や Teams などです。

チャットはわかりやすく、使いやすいですが、それだけです。対面口頭コミュニケーションの下位互換でしかないですし、その癖デメリットが多いです。たとえば通知が多い、ナレッジマネジメントやタスク管理ができない、チャンネルが乱立して混乱する、階層的かつ中央集権的でボトルネックが生じやすい、言及や参照がしづらい等です。

パンデミックが落ち着いた後、出社回帰が再燃しています。これも単にチャットツールしか知らないからです。**コミュニケーションのあり方はツールで決まります**。チャットしか使っていない人は、チャットのメンタルモデルから脱せません。

### チャット以外のコミュニケーションツールはある
エンジニアの皆さんなら、すでにある程度は触れたことがあるはずです。

たとえば Wiki を読み書きした人は多いでしょう。GitHub で Issuses を日々書いているでしょうし、Issues にはコミュニケーションそのもののポテンシャルがあるわけで、GitHub は Discussions をリリースしました。Miro などデジタルホワイトボードを使う人もいるでしょうし、Google ドキュメントや Notion など同時編集型ノートもすっかり定着しました。

## QWINCS
チャットへのとらわれから脱却するために、端的な概念をつくりました。

QWINCS です。これはアクロニムであり、以下の略となっています。

- Q&A
- Wiki
- Issues
- Notes
- Chat
- Sticky boards

チャットは Chat に相当します。これ以外にも、あと 5 つの手段があるということです。

最後に、それぞれについてかんたんに整理します。

### Q&A
たとえば Stack Overflow が相当します。

質問（Question）に対して、誰でも回答（Answer）を書き込むことができ、質問者がベストアンサーを決めます。コミュニケーションの大半は質疑応答に帰着できますから、優れた世界観と言えます。**アンサー指向（Answer Oriented）** と呼びます。

実はビジネスとしてはブルーオーシャンでもあります。企業レベルで、たとえばエンジニアのチームで使われている Q&A ツールを思い浮かべられますか？出来ないと思います。そのようなツールがまだ無いからです。

ですので、Q&A ベースのコミュニケーションをしたい場合は、他のツールを使ってフォーマットとファシリテーションで工夫しましょう。

### Wiki
チャットよりも古い概念で、ブラウザでプレーンテキストで素早く編集できることや、ページ間をリンクでつないでネットワーク構造をつくれることが特徴的な手段です。wiki はハワイ語で「速い」を意味します。

実は Wiki の先進国は日本であり、特に [Cosense](https://scrapbox.io/) はエンジニア界隈の歴史に残る素晴らしいツールです。どれだけ素晴らしいかは、Cosense のリンク記法が `[]` であることを見ればわかるでしょう。平凡な開発者は `[[ ]]` などとしてしまいますが、大胆に短くしています。サンプルを見たければ、日本語ですが[私のページにお越しください](https://scrapbox.io/neoterizer/)。

Wiki がいまいちだと考えている人は、単に昔の Wiki しか知らないからです。現代は色々技術も揃ってきて、かつての不便さも解消されつつあります。ぜひ現代的な Wiki を試していただければと思います。私は Cosense をおすすめしますが、他にもあるはずです。

ちなみに、Wiki は参加者全員に役立つナレッジを頑張ってつくるとの価値観があります。Wikipedia はまさにわかりやすいでしょう。これを **ナレッジ指向（Knowledge Oriented）** と呼びます。ですので、あまり個人的なことをたくさん書くのは好ましくありませんし、これを放置すると Wiki は形骸化します。皆にとって有益なナレッジを、皆で協力してつくらねばなりません。そういうわけで、実は少人数が適しており、Cosense も少人数での利用を推奨しています。

### Issues
チケットと呼ぶこともできます。元々は BTS（Bug Tracking System）であり、Redmine、Trac、Backlog などが知られていますが、本質は違います。本質は 1-話題 1-ページ で管理できるという独立性であり、**トピック指向（Topic Oriented）** と呼びます。

ある話題 A について議論したければ、A のページに行けばいいのです。状態も管理できるのでタスク管理もできますし、メンションを撃って気づかせることもできます。

特に重要なのはクローズの概念で、用が済んだものを閉じることができます。何が終わっていて、何が終わっていないかも管理・可視化できるということです。

### Notes
同時編集を行えるノートを指します。たとえば Notion、Google ドキュメント、Microsoft Word Online、Box notes、Dropbox Paper などです。

ノートは **ギャザー指向（Gather Oriented）** であり、皆で一つのノートに集まってコラボレーションする用途に適しています。発散的に書き込んでもらってもいいですし、テンプレートをつくっておいて埋めてもらうのも良いです。

その代わり、収束つまりは意思決定には弱いです。今のところ、意思決定者が自らの決定をサマリーとして書き、皆に読んでもらうようリマインドするくらいしか方法がありません。しかしながら、意思決定は難しいことではありません。最も難しいのはその前段階の、情報を集めきるところであり、ノートがまさに得意とするところです。**ノートを知らない人は悲惨ですらあります。なぜなら、情報を集めるために、いちいち原始的に会議を繰り返すことになるからです**。会議過多から抜け出せるかどうかは、ノートを使ってギャザー指向的にコラボレーションできるかどうかにかかっています。

今後は生成 AI により、「AI メンバーによる書き込み」も盛り上がってくるでしょう。ノートには今のうちにぜひ慣れておくことをおすすめします。それもただのドキュメント用途ではなく、ギャザー指向的なコラボレーションとして、です。

### Chat
Slack や Teams などビジネスチャットを指します。

まずビジネスチャットとは、LINE その他単純なメッセージアプリとは違って部屋の概念があるものです。ワークスペース、チャンネル、スレッドなどですね。組織構造を反映するために、階層的に部屋をつくる機能があるわけです。これにゆえにビジネス用途にも耐えることができ、ビジネスチャットと呼ばれます。

ビジネスチャットは **時系列指向（Timeline Oriented）** であり、メッセージを時系列に表示するだけです。人間にとっては一見するとわかりやすいですが、それだけであり、デジタルなコミュニケーションや非同期なコミュニケーションを行うには明らかに力不足です。ビジネスチャットから脱却しない限り、デジタル前提で、非同期も想定したコミュニケーションは行えません。

そういう意味で、ビジネスチャットからの脱却は CX（Communication Transformation）と呼ぶことができます。DX と同様、変革（Transformation）であり、根本からあり方を変えないといけないわけです。よくエンジニアは DX すらできない非エンジニアを下に見ますが、私に言わせれば、未だにビジネスチャットしか使えないエンジニアも同じ穴のムジナです！

### Sticky boards
名前付けは強引ですが、デジタルホワイトボードを指します。たとえば Miro です。

無限に広がったボード上にいくらでも付箋を貼れるという世界観ですが、付箋以外にもオブジェクトを扱えます。それこそパワーポイントのようなビジュアルな成果物もつくれます。

しかし本質は資料づくりではありません。デジタルホワイトボードは **空間指向（Space Oriented）** であり、建物や住所が存在する現実世界と同じような、空間的な世界観です。ゲームが好きな人はマインクラフトを思い浮かべてください。マイクラは 3 次元ですが、デジタルホワイトボードは 2 次元です。

大胆に言えば、**デジタルホワイトボードは 2 次元的なバーチャルオフィスです**。Miro の場合は、アバターではなくただのカーソルですが、見た目に騙されないでください。本質は空間指向であり、バーチャルオフィスです。デジタル上で一緒に過ごすものであって、系統としては Gather のようなバーチャルオフィスツールだと思ってください。

## おわりに
ビジネスチャットから脱却するために、QWINCS という形で 6 つの手段を整理しました。

仕事のボトルネックはコミュニケーションであり、コミュニケーションはツールが司ります。チャットしか使えない人は、それ自体がボトルネックになるわけです。エンジニアも例外ではありません。だからこそ、QWINCS を参考にして、チャットからの脱却を目指してみてください！

---

# 1on1 はテキストベースでも良い

## これは何？
**テキストベース 1on1（Text based 1-on-1）** とは、テキストコミュニケーションのみで完結させる 1on1 ミーティングを指します。

## 例
たとえばマネージャー🐶さんとエンジニア🐱さんとで、30 分の 1on1 を行う場合、以下のようにします。

- (Before) 従来
    - ミーティングにて会話する
- (After) テキストベース 1on1
    - 事前に共同編集ノートをつくっておき、お互いに聞きたいことを書いておく
    - ミーティングでは **会話は行わず、ノートを開き、お互いに答えや追加の質問を書く**

## 背景
文脈次第ですが、1on1 ではしばしば「情報」が重要です。対面や会話による非言語情報よりも、**言語で表現できる情報の量と質こそが重要** なのです。後者を広くしたい、また深くしたいのなら、テキストコミュニケーションが最適です。

私たちはなぜか会話をしたがります。これは単に、エンジニアならば比較的実践できる「高度なツールを用いた賢いコミュニケーション」を知らない人がマジョリティだからです。マジョリティの力には抗えず、エンジニアも巻き込まれてしまいます。

だからこそ、とりあえず会話という単純な思考を脇において、本当に必要なコミュニケーションとその手段を考えて実践したいところです。テキストベース 1on1 は、1on1 においてそれをしたものです。

私は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として、コミュニケーション含む「やり方の最適化」にメスを入れます。1on1 は、比較的わかりやすくて、かつ導入もしやすいので、入口としては最適なのです。

## メリット
背景でも述べたとおり、情報の量と質を最大化できます。少なくとも口頭による会話よりは圧倒的に増やせます。

## デメリット
非言語コミュニーションができません。親睦を深めたり、カジュアルに気分転換したり、非言語的に感情を交換したりといった目的には合いません。

## やり方

### まずはノートを用意
共同編集ノートを使います。、**複数人がリアルタイムに同時編集できるノート** のことです。Notion、Google ドキュメント、Box Notes、Cosense その他何でも構いません。

たとえば🐶さんと🐱さんが 1on1 を行う場合、🐶さんと🐱さんのみが見れる場所を用意します。オープンな文化を許容できるなら「チーム全員が見れる場所」で構いませんが、1on1 は通常プライベートな話題にも踏み込むため、案外許容されづらいです。まずは DM と同様、1対1 のクローズドな場所を用意するのがいいでしょう。

### フォーマットについて
フォーマットについては、箇条書きを用いて、次のようにします。🐶さんのセクションと、🐱さんのセクションの二つをつくってください。また各行の先頭に、誰の意見かを示す文字を書いてください。名前を書いてもいいですが、私は絵文字を使うことをおすすめします。視認性が抜群ですし、かわいい絵文字は（マイクラと同様）気分を和らげる効果があるからです。

以下は Markdown による例です。

```
- 🐶：ジョン
- 🐱：クリス

# 🐶 -> 🐱
- 🐶～～について今現在、考えていることはありますか？
- 🐶プロジェクトAの進捗をかんたんに教えてください
- 🐶来年の長期出張をそろそろ検討せねばなりません、現時点の所感を教えてください
- ……

# 🐱 -> 🐶
- 🐱会社費用で申請したい資格が3つあるのですが、見解をお聞かせください……
- 🐱アンナさんのうるさい打鍵音がストレスであり、何とかしてほしいです
- 🐱プロジェクトAは中止するべきと思っていますが、見解をお聞かせください
    - 🐱中止すべきと考える根拠は次のとおりです。1: ……
- ……
```

上記は **1on1 ミーティングの前に用意しておきたい** ところです。ミーティングの最中は、書かれている質問への回答と、書いていて・読んでいて思いついた、さらなる質問や回答の書き込みに集中したいからです。私の経験から言っても、事前に質問を書いてないとテキストベース 1on1 は上手くいかないと感じます。

これは事実上、1on1 の前に、ある程度時間をつくって、ちゃんと質問を書いておくことを要請します。「そんな時間や気力なんてない！」とよく言われますが、言い訳にすぎません。上司やメンバーとのコミュニケーションは重要であり、その手段として 1on1 は有益なのですよね？ならば、時間と気力をかけるべきです。逆に、重要でないのなら、1on1 そのものをやめてしまいましょう。あるいは、情報交換ではなく感情交換を行う「イベント」や「カジュアルな会話」をすればいいと思います。

### ミーティング中
ミーティング中は、ひたすらノートに質問と回答を書き込んでいきます。

**他の作業は行わず、ノート上で 1on1 を書くことに専念してください**。慣れてくると、通常 30 分では到底足りなくなるくらいに白熱します。

これについても例を示しましょう。たとえば、次のようになるでしょう（Markdown 文法による例）。

```
- 🐶：ジョン（上司）
- 🐱：クリス（部下）

# 🐶 -> 🐱
- 🐶～～について今現在、考えていることはありますか？
    - 🐱何も考えてません
    - 🐱これを尋ねる背景を教えてもらってもいいですか？
- ✅🐶プロジェクトAの進捗をかんたんに教えてください
    - 🐱順調ですが、先方の反応が悪いせいで進捗が出ていません。予定は今月中にフェーズ1完了ですが、このままでは来月中になってしまいます
    - 🐶先方の都合であるなら致し方ないと思います。何が問題と考えていますか？
    - 🐱継続的に受注をいただくためには、それなりの速さで進めねばなりませんが、今はそうじゃないです。成果もあまり出てないように見えるので継続受注してもらえない可能性が高いです
    - 🐶プロジェクトA以外にも食い扶持はあるので、無理にこだわる必要はないと思っています。🐱さんはどうお考えですか？もっとプロジェクトAをやりたい？
    - 🐱特にこだわりはないです。ので、流れに任せたいと思います。ありがとうございます
- 🐶来年の長期出張をそろそろ検討せねばなりません、現時点の所感を教えてください
- ……

# 🐱 -> 🐶
- 🐱会社費用で申請したい資格が3つあるのですが、見解をお聞かせください……
    - 🐶資格A、Bは OK です。こちらに申請の解説があるので対応してください: ……
    - 🐶資格Cについては、部門内で枠を設ける計画があります。3人くらいだと思います。来週以降、お知らせがあると思うので注視してください。勝手に申し込んで構いません
- ✅🐱アンナさんのうるさい打鍵音がストレスであり、何とかしてほしいです
    - 🐶難しい問題かもしれません。実はアンナさんからも、🐱さんが神経質でうるさいとの相談をいただいており、一度私という第三者も交えて会話してはどうかと考えています。アンナさんからは許諾いただいています
    - 🐱それで構いません
- 🐱プロジェクトAは中止するべきと思っていますが、見解をお聞かせください
    - 🐱中止すべきと考える根拠は次のとおりです。1: ……
- ……
```

終わった話題には、質問者が ✅ をつけましょう。まだ終わってない話題には、回答や追加の質問を書き込んでいきましょう。箇条書きが長くなって見づらくなるようなら、セクションやページを分けても構いません。

## おわりに
テキストコミュニケーションで 1on1 を行うテキストベース 1on1 を紹介しました。

1on1 では情報の量と質も重要です。テキストの方が増やせます。ぜひお試しください！

---

# カジュアル・アジャイル ～ソフトスキルとしてのアジャイル～

## 背景

### アジャイルはソフトスキル
アジャイルはソフトウェア開発の手法や原則に留まらず、ソフトスキルの一種と言えると思います。

ウォーターフォールを計画主義またはプロセス原理主義とするなら、アジャイルは探索主義とでも言えるでしょう。計画やプロセスといった「仕事のための仕事」にとらわれず、さっさと探索して学びを得ることを優先します。

※もちろん探索だけではすべての仕事をカバーできません。探索して「見えてきた」後は、しっかりと遂行するフェーズに移る必要があります。このフェーズは探索では難しいです。

### エンジニアとて身に付けているとは限らない
エンジニアの皆様は、おそらく日頃からアジャイルに取り組まれているでしょう。「私は身に付けているはずだ」と思うはずです。

本当にそうでしょうか？

ここで言っているのは、**ソフトスキルとしてのアジャイル** です。開発におけるそれではありません。仮に開発者としてアジャイル開発をしていたとしても、ソフトスキルとしてのアジャイルはできていない可能性があります。できているかどうかの確認（※一つの目安です）は、以下本編をご覧ください。

### ソフトスキルとしてのアジャイルを整理する
このアジャイルというソフトスキルを言語化するのは容易ではありません。もちろん、私達エンジニアが使っているものをそのまま伝えたところで、専門的すぎますし特化も強くて汎用的ではない。

そこで[ソフトスキル・エンジニアリング](https://dev.to/stakiran/soft-skills-engineering-34mg)の出番です。現役のエンジニアであり、この概念の提唱者でもある私自ら言語化をしてみました。

アジャイルらしく、さっさと言語してみたものです。

## カジュアル・アジャイル
**カジュアル・アジャイル** とは、ソフトスキルとしてのアジャイルを整備したもので、その名のとおりカジュアルにアジャイルを実践するための TIPS です。

今のところ、私が整備したものを 5 つ挙げていますが、他にもありえます。というより、エンジニアの皆様で集めていくといいのではないかと思います。awesome list じゃないですが、オープンソースでリストにしてみたいですね。もちろん、チームや組織の中で整備するのもアリです。組織ごとのカラーが出るでしょう。

では、挙げていきます。

### 1: 3R サイクル
アジャイルの流れは 3R に当てはめられます。

- 1 Rough Plan
- 2 Run
- 3 Retrospective

Rough Plan では、ラフな計画をつくります。「大体こんなことをする」くらいのラフさでいいです。Excel やスプレッドシートは登場せず、テキストで済むはずです。シートが登場した場合は黄信号です。

次に、Rough Plan を参考に、実際に進めていきます。考えを洗い出したり、議論したり、ドキュメントを書いてみたり、もちろん実装もあります。ひょっとすると知識が足りないからと書籍の読解、関係者へのヒアリング、その他リサーチをするかもしれません。とにかく思いついたことは何でもやります。主体性を発揮します。Rough Plan はあくまで参考なので、別にこの通りにできなくてもいいです。

最後に Retrospective です。Run を終えた後に振り返りをして、次はどうするかを考えます。これを **3R サイクル** と呼びます。

3R サイクルは、一言で言えば「大体何するかを決めて、きりのいいところまで動いてみて、その結果どうだったかを振り返る。これを繰り返す」です。

生成 AI もわかりやすいと思います。おそらくラフにプロンプトを投げて、それをベースにあれこれ試行錯誤して、きりがいいところまで進んだらいったん振り返ると思います。同じようなものです。

### 2: [Mechanical Style](https://dev.to/stakiran/submitting-ai-generated-outputs-as-they-are-1e9n)
メッセージや資料を見てもらうときの話ですが、従来は人間がしっかりつくっていたり（パワポ）、雑につくったりしていました（プレーンテキストやノートの1ページ）。そうではなく、生成 AI につくらせたもの、特にチャットのセッションをそのまま見せることもできます。

これを **Mechanical Style** と呼んでいます。

- 人間がしっかりつくる: Formal Style
- 人間が雑につくる: Rough Style
- AI の出力で済ます: Mechanical Style

アジャイルは探索的なものなので、案外 Formal や Rough でなくても良かったりします。AI のチャットセッションを見てもらうだけでも学びはありますし、微細なニュアンスも伝えられます。そもそも **チャットセッションを見ることすらできないほど受動的な人に、アジャイルは務まりません**。

これはアジャイルという探索行動ができるかどうかを測る目安にもなります。

### 3: エフェクチュエーションの Affordable Loss
エフェクチュエーションというアジャイルな理論があります。これは 5 つの原則を提示しており、その一つに **許容可能な損失（Affordable Loss）** があります。リソースに対して「ここまでなら最悪ドブに捨ててもいい」というラインを設定した上で、この分を一気に与えるのです。つまり **使い放題** ですね。

このシンプルな考え方は、アジャイルと相性がいいです。使い放題なので管理が発生しません。Affordable Loss 分のリソースを与えたということは、その時点でもうそのリソースは捨てたようなものなのです。リソースの管理者としてはやりづらいかもしれませんが、アジャイルに動く側としてはこれほど嬉しいことはありません。探索に必要なのは自由だからです。管理は邪魔です。

### 4: 助言プロセス
ティール組織に **助言プロセス** の概念があります。

これは以下の二つから成ります。

- 意思決定権は持たないが、助言はする
- 暴走やクリティカルな失敗を防ぐために、助言自体は請わなければならない

従来だと助言者≒上位者であり、助言という名の命令になりがちでした。そうではなく、助言プロセスでは **助言者に意思決定権はありません**。つまり、助言を受ける担当者が自ら意思決定できるのです。たとえば、助言が微妙だと思ったら無視してもいい。

しかし、担当者の独断専行を防ぐという意味でもガードレールは敷きます――つまり助言自体は必ず請いましょう、との原則をつくります。これは思っているよりも重要で、ティール組織ではしばしば「助言を意図的に請わない姿勢を続ける者は解雇の対象となる」とのルールをつくるくらいに根幹です。

### 5: 管理よりもモニタリング
開発者体験の重要性は認識されています。また私は[Beyond Productivity: Embracing Experiencity](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)という記事を書きました。ウォーターフォールが時代遅れとなったように、管理もまたそうなりつつあります。

この感覚を端的に表現するのが、この **管理よりもモニタリング** です。

モニタリングとは以下を二つとも満たします。

- 1: 自動計測。勝手に計測されること
- 2: 因子ベース。目標ではなく因子として扱うこと

自動計測については、人間が記入したりヒアリングしたりするのではなく、勝手に計測されるという意味です。なぜ自動にしたいかというと、人間が手で日々記入するのは面倒かつ不正確だからです。形骸化しやすいのです。といっても、常に自動化できるとは限りません。

たとえば Engineering Effectiveness の一環で「割り込まれた回数」をモニタリングしたい場合、これを自動で記録するのは難しいでしょう。たぶんシンプルなボタンなどを用意してカウントすることになるはず。

次に因子ベースについては、**計測指標をノルマにしない** ということです。ログと言っても良いでしょう。あとで振り返るときに見て参考にする「因子」でしかありません。KPI のように目標にして、それを満たすために死に物狂いで頑張りましょうといったことはしません。

## おわりに
ソフトスキルとしてのアジャイルとして、カジュアル・アジャイルを紹介しました。

特に私が整備した 5 つの TIPS をお届けしました。アジャイルの本質を何となく理解できるのではないでしょうか。皆さんもぜひ自分なりの、組織なりのアジャイルを開拓してみてください！それではまた。

---

# これまで投稿してきたソフトスキルを分類してみました

## サマリー
- ソフトスキルに関する過去記事 40 件を分類しています
    - 分類は複数の AI モデルに頼りました
- 眺めてみてください。あなたの何かを変えるスキルやテクニックとの出会いを期待します

## はじめに
私は[ソフトスキル・エンジニア]として、2025/12/07 時点で 40 記事を書きました。タスク管理や発想法といった **新しい** ソフトスキルを開発してお届けしたり、もちろんコミュニケーションやマネジメントといった **既存のソフトスキルの実装を支援する** ための道具（ソフト・テクニック）もご紹介しました。

記事が貯まってきたので、分類してみようと思います。[Asking n People (n Generative AI Models) Simultaneously - DEV Community](https://dev.to/stakiran/asking-n-people-n-generative-ai-models-simultaneously-2ef7) に従い、複数の AI モデルに整理してもらいました。なお筆者による補足があれば 🐰 をつけて書きます。

ぜひ眺めてみてください。あなたの何かを変えるスキルやテクニックと出会えることを期待します。

## ======== gpt-4.1 ========

### コミュニケーション & コラボレーション
- [Rapid Q&A](https://dev.to/stakiran/rapid-qa-c83)
- [MAMA (Meeting as an AMA)](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)
- [Text Based 1-on-1s are Effective](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)
- [Online Meeting Sucks!](https://dev.to/stakiran/online-meeting-sucks-1g7l)
- [ChatGPT Projects as a Means of "Indirect Conversation"](https://dev.to/stakiran/chatgpt-projects-as-a-means-of-indirect-conversation-gf9)

### タスク・自己管理
- [Task Engineering](https://dev.to/stakiran/task-engineering-2l78)
- [List of "Task Attributes" for Implementing Task Management](https://dev.to/stakiran/list-of-task-attributes-for-implementing-task-management-5e87)
- [Continuous Reminding](https://dev.to/stakiran/continuous-reminding-14h1)
- [HQRST is Recommended for Lightweight Task Management](https://dev.to/stakiran/hqrst-is-recommended-for-lightweight-task-management-3nlg)
- [Dry Behavior](https://dev.to/stakiran/dry-behavior-13gl)

🐰Dry Behavior はコミュニケーションの両分なので分類違いです。

### 自己啓発・思考法
- [Mastering Personal Retrospection: KPT YWT 4Y](https://dev.to/stakiran/mastering-personal-retrospection-kpt-ywt-4y-2p1m)
- [If You Want Serendipity and Transformation, Embrace "Newest Literally"](https://dev.to/stakiran/if-you-want-serendipity-and-transformation-embrace-newest-literally-10b1)
- [Beyond Productivity: Embracing Experiencity](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)
- [In-House Production and Introspection](https://dev.to/stakiran/in-house-production-and-introspection-kkg)
- [What is Knowledging?](https://dev.to/stakiran/what-is-knowledging-2229)

🐰Knowleding はソフトスキル・エンジニアリングと同様、私が新たに構築した概念です。カテゴリとしてはナレッジマネジメントにしたいかも。あと Newest Litelly と Experiencity は個人にも通用しますが、チームにこそ通用するので、コラボレーションに含めたいかも。

### 役割・組織設計/リーダーシップ
- [Senior Roles' Context Revealed in the Calendar](https://dev.to/stakiran/senior-roles-context-revealed-in-the-calendar-lja)
- [Engineers, Managers, and Spreaders](https://dev.to/stakiran/engineers-managers-and-spreaders-4fl7)
- [Full-Four: Full Remote, Full Flex, Full Async, Full Mask](https://dev.to/stakiran/full-four-full-remote-full-flex-full-async-full-mask-270)
- [Role, Reward, Regard：The 3Rs of Output Incentives](https://dev.to/stakiran/the-3rs-of-output-incentives-role-reward-regard-418m)
- [Soft Skills Engineering](https://dev.to/stakiran/soft-skills-engineering-34mg)

🐰Full-Four は後述の多様性やウェルビーイングに入れたい。あとソフトスキル・エンジニアリングはやはりそれ自体をカテゴリにしたいところ。「メタ・ソフトスキル」かなぁ。

### 多様性・ウェルビーイング・倫理
- [Engineering and DEI](https://dev.to/stakiran/engineering-and-dei-2k51)
- [On Engineers Having to Do Emotional Labor](https://dev.to/stakiran/on-engineers-having-to-do-emotional-labor-5d59)
- [Let's Stop Overprotecting Confidential Information](https://dev.to/stakiran/lets-stop-overprotecting-confidential-information-1m0l)
- [Closed Anonymity](https://dev.to/stakiran/closed-anonymity-2n07)
- [What is a "Retreat" Suitable for Engineers](https://dev.to/stakiran/what-is-a-retreat-suitable-for-engineers-g12)

## ======== gpt-5 ========

### 非同期コミュニケーションと会議設計
- [RAP Framework for Asynchronous Work](https://dev.to/stakiran/rap-framework-for-asynchronous-work-1mge)
- [MAMA (Meeting as an AMA)](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)
- [Text Based 1-on-1s are Effective](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)
- [There's a Limit to Chat Tools — Enter QWINCS!](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb)
- [Online Meeting Sucks!](https://dev.to/stakiran/online-meeting-sucks-1g7l)

🐰MAMAは非同期コミュニケーションではない。会議設計ではあるけれども、非同期コミュニケーションと会議設計を一つのカテゴリにするのは分かりづらいと思う。

### タスク設計・自己管理・内省
- [Task Engineering](https://dev.to/stakiran/task-engineering-2l78)
- [List of "Task Attributes" for Implementing Task Management](https://dev.to/stakiran/list-of-task-attributes-for-implementing-task-management-5e87)
- [Mastering Personal Retrospection: KPT YWT 4Y](https://dev.to/stakiran/mastering-personal-retrospection-kpt-ywt-4y-2p1m)
- [Continuous Reminding](https://dev.to/stakiran/continuous-reminding-14h1)
- [HQRST is Recommended for Lightweight Task Management](https://dev.to/stakiran/hqrst-is-recommended-for-lightweight-task-management-3nlg)

### ナレッジ化・発信・生成AI活用
- [What is Knowledging?](https://dev.to/stakiran/what-is-knowledging-2229)
- [The 3Rs of Output Incentives: Role, Reward, Regard](https://dev.to/stakiran/the-3rs-of-output-incentives-role-reward-regard-418m)
- [TIL in the Age of Generative AI: Writing with a Focus on Soft Skills](https://dev.to/stakiran/til-in-the-age-of-generative-ai-writing-with-a-focus-on-soft-skills-3k93)
- [ChatGPT Projects as a Means of "Indirect Conversation"](https://dev.to/stakiran/chatgpt-projects-as-a-means-of-indirect-conversation-gf9)
- [Asking n People (n Generative AI Models) Simultaneously](https://dev.to/stakiran/asking-n-people-n-generative-ai-models-simultaneously-2ef7)

🐰ナレッジングと生成AI活用を同じカテゴリにするのは興味深いですね。ナレッジングは言語で概念を扱うものであり、生成 AI 活用は自然言語を扱うものなので、実は似ています。

### 組織づくり・リーダーシップ・カルチャー
- [Engineers, Managers, and Spreaders](https://dev.to/stakiran/engineers-managers-and-spreaders-4fl7)
- [Engineering and DEI](https://dev.to/stakiran/engineering-and-dei-2k51)
- [On Engineers Having to Do Emotional Labor](https://dev.to/stakiran/on-engineers-having-to-do-emotional-labor-5d59)
- [Senior Roles' Context Revealed in the Calendar](https://dev.to/stakiran/senior-roles-context-revealed-in-the-calendar-lja)
- [In-House Production and Introspection](https://dev.to/stakiran/in-house-production-and-introspection-kkg)

### 働き方・環境設計・セーフティ
- [Full-Four: Full Remote, Full Flex, Full Async, Full Mask](https://dev.to/stakiran/full-four-full-remote-full-flex-full-async-full-mask-270)
- [Notes and Boards as Virtual Offices: A Lightweight Approach](https://dev.to/stakiran/notes-and-boards-as-virtual-offices-a-lightweight-approach-59n4)
- [Let's Stop Overprotecting Confidential Information](https://dev.to/stakiran/lets-stop-overprotecting-confidential-information-1m0l)
- [Change the Color of the Production Environment Screen](https://dev.to/stakiran/change-the-color-of-the-production-environment-screen-53a2)
- [Closed Anonymity](https://dev.to/stakiran/closed-anonymity-2n07)

## ======== gpt-5.1 ========

### 1. 個人の生産性・自己マネジメント
- [Task Engineering](https://dev.to/stakiran/task-engineering-2l78)
- [List of "Task Attributes" for Implementing Task Management](https://dev.to/stakiran/list-of-task-attributes-for-implementing-task-management-5e87)
- [HQRST is Recommended for Lightweight Task Management](https://dev.to/stakiran/hqrst-is-recommended-for-lightweight-task-management-3nlg)
- [Mastering Personal Retrospection: KPT YWT 4Y](https://dev.to/stakiran/mastering-personal-retrospection-kpt-ywt-4y-2p1m)
- [Continuous Reminding](https://dev.to/stakiran/continuous-reminding-14h1)

### 2. コミュニケーション設計・対話のしかけ
- [Rapid Q&A](https://dev.to/stakiran/rapid-qa-c83)
- [MAMA (Meeting as an AMA)](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)
- [Online Meeting Sucks!](https://dev.to/stakiran/online-meeting-sucks-1g7l)
- [Text Based 1-on-1s are Effective](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)
- [On Engineers Having to Do Emotional Labor](https://dev.to/stakiran/on-engineers-having-to-do-emotional-labor-5d59)

🐰On Engineers Having to Do Emotional Labor は #discuss 前提のポエムなので、カテゴライズすること自体が間違いだったかも

### 3. ナレッジ共有・ドキュメント/情報設計
- [What is Knowledging?](https://dev.to/stakiran/what-is-knowledging-2229)
- [Notes and Boards as Virtual Offices: A Lightweight Approach](https://dev.to/stakiran/notes-and-boards-as-virtual-offices-a-lightweight-approach-59n4)
- [TIL in the Age of Generative AI: Writing with a Focus on Soft Skills](https://dev.to/stakiran/til-in-the-age-of-generative-ai-writing-with-a-focus-on-soft-skills-3k93)
- [The 3Rs of Output Incentives: Role, Reward, Regard](https://dev.to/stakiran/the-3rs-of-output-incentives-role-reward-regard-418m)
- [What is a "Retreat" Suitable for Engineers](https://dev.to/stakiran/what-is-a-retreat-suitable-for-engineers-g12)

🐰Retreat はカテゴリエラーだと思います

### 4. 働き方・組織設計・コラボレーション
- [Soft Skills Engineering](https://dev.to/stakiran/soft-skills-engineering-34mg)
- [Examples of Soft Skills Engineering](https://dev.to/stakiran/examples-of-soft-skills-engineering-1f62)
- [RAP Framework for Asynchronous Work](https://dev.to/stakiran/rap-framework-for-asynchronous-work-1mge)
- [Full-Four: Full Remote, Full Flex, Full Async, Full Mask](https://dev.to/stakiran/full-four-full-remote-full-flex-full-async-full-mask-270)
- [Engineers, Managers, and Spreaders](https://dev.to/stakiran/engineers-managers-and-spreaders-4fl7)

🐰やっぱりソフトスキル・エンジニアリングはそれ自体をカテゴリーにしたいところ

### 5. 生成AIとの協働・メタスキル
- [ChatGPT Projects as a Means of "Indirect Conversation"](https://dev.to/stakiran/chatgpt-projects-as-a-means-of-indirect-conversation-gf9)
- [Asking n People (n Generative AI Models) Simultaneously](https://dev.to/stakiran/asking-n-people-n-generative-ai-models-simultaneously-2ef7)
- [Submitting AI-Generated Outputs as They Are](https://dev.to/stakiran/submitting-ai-generated-outputs-as-they-are-1e9n)
- [HireMe Tag and Generative AI](https://dev.to/stakiran/hireme-tag-and-generative-ai-m57)
- [If You Want Serendipity and Transformation, Embrace "Newest Literally"](https://dev.to/stakiran/if-you-want-serendipity-and-transformation-embrace-newest-literally-10b1)

🐰なるほど、もしかすると生成AIも汎用的なスキルつまりはソフトスキルの一種と言えるのかもしれませんね

## ======== o1 ========

### カテゴリ1: コミュニケーション & コラボレーション
- [Rapid Q&A (2025-12-07)](https://dev.to/stakiran/rapid-qa-c83)
- [Text Based 1-on-1s are Effective (2025-11-20)](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)
- [MAMA (Meeting as an AMA) (2025-11-27)](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)
- [There's a Limit to Chat Tools — Enter QWINCS! (2025-11-20)](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb)
- [Full-Four: Full Remote, Full Flex, Full Async, Full Mask (2025-11-24)](https://dev.to/stakiran/full-four-full-remote-full-flex-full-async-full-mask-270)

### カテゴリ2: 生産性 & タスクマネジメント
- [Task Engineering (2025-12-03)](https://dev.to/stakiran/task-engineering-2l78)
- [List of "Task Attributes" for Implementing Task Management (2025-11-27)](https://dev.to/stakiran/list-of-task-attributes-for-implementing-task-management-5e87)
- [HQRST is Recommended for Lightweight Task Management (2025-11-21)](https://dev.to/stakiran/hqrst-is-recommended-for-lightweight-task-management-3nlg)
- [Mastering Personal Retrospection: KPT YWT 4Y (2025-11-25)](https://dev.to/stakiran/mastering-personal-retrospection-kpt-ywt-4y-2p1m)
- [RAP Framework for Asynchronous Work (2025-12-06)](https://dev.to/stakiran/rap-framework-for-asynchronous-work-1mge)

### カテゴリ3: リーダーシップ & 組織文化
- [Senior Roles' Context Revealed in the Calendar (2025-12-05)](https://dev.to/stakiran/senior-roles-context-revealed-in-the-calendar-lja)
- [Engineers, Managers, and Spreaders (2025-11-26)](https://dev.to/stakiran/engineers-managers-and-spreaders-4fl7)
- [Engineering and DEI (2025-11-25)](https://dev.to/stakiran/engineering-and-dei-2k51)
- [The 3Rs of Output Incentives: Role, Reward, Regard (2025-11-27)](https://dev.to/stakiran/the-3rs-of-output-incentives-role-reward-regard-418m)
- [Divergent Work Using GitHub (2025-11-25)](https://dev.to/stakiran/divergent-work-using-github-2kk8)

### カテゴリ4: セルフアウェアネス & エモーショナル・インテリジェンス
- [On Engineers Having to Do Emotional Labor (2025-11-24)](https://dev.to/stakiran/on-engineers-having-to-do-emotional-labor-5d59)
- [Beyond Productivity: Embracing Experiencity (2025-11-29)](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)
- [In-House Production and Introspection (2025-11-24)](https://dev.to/stakiran/in-house-production-and-introspection-kkg)
- [Full Mask (2025-11-24)](https://dev.to/stakiran/full-mask-ek8)
- [If You Want Serendipity and Transformation, Embrace "Newest Literally" (2025-12-06)](https://dev.to/stakiran/if-you-want-serendipity-and-transformation-embrace-newest-literally-10b1)

🐰Full Mask がなぜこのカテゴリーに入っているのかがわかりません。しかし造語ですし、記事タイトル以上の情報も与えていないので致し方ないかもしれません。たぶん Mask の単語から、本心を隠す、のような状況を連想したのでしょう。ある意味、合っています。

### カテゴリ5: ソフトスキル & 次世代アプローチ
- [Soft Skills Engineering (2025-11-30)](https://dev.to/stakiran/soft-skills-engineering-34mg)
- [Examples of Soft Skills Engineering (2025-12-03)](https://dev.to/stakiran/examples-of-soft-skills-engineering-1f62)
- [TIL in the Age of Generative AI: Writing with a Focus on Soft Skills (2025-11-22)](https://dev.to/stakiran/til-in-the-age-of-generative-ai-writing-with-a-focus-on-soft-skills-3k93)
- [ChatGPT Projects as a Means of "Indirect Conversation" (2025-12-04)](https://dev.to/stakiran/chatgpt-projects-as-a-means-of-indirect-conversation-gf9)
- [Asking n People (n Generative AI Models) Simultaneously (2025-11-21)](https://dev.to/stakiran/asking-n-people-n-generative-ai-models-simultaneously-2ef7)

🐰次世代アプローチとは面白い言い方ですが、ソフトスキル・エンジニアリングもナレッジングもどちらも次世代アプローチなのですよね。「次世代」だけでは情報量が無いですし、新しいものばかりだと読者も恐れます。だからこそ既存のカテゴリーに落とし込みたいのですよね。

## ======== ここまで ========
以上です。いかがでしたか？何か面白いものと出会えたら幸いです！

以降はおまけです。

### 今回使ったプロンプト

```
    ```markdown
    - (2025-12-07): [Rapid Q&A](https://dev.to/stakiran/rapid-qa-c83)
    ... (https://stakiran.github.io/knowledging/index_devto.html の Markdown 原稿の内容です) ...
    - (2025-11-19): [What is Knowledging?](https://dev.to/stakiran/what-is-knowledging-2229)
    ```

上記は私のブログ記事一覧です。
私はソフトスキル・エンジニアリングを掲げており、ソフトスキルに関する記事発信をしてきました。そこで上記ブログ記事一覧を主なソフトスキルでカテゴライズしたいです。

1. 上記記事一覧を見て、ソフトスキルのカテゴリを 5 つで提案しなさい
2. 提案した 5 つのカテゴリーに対して、代表的な記事を最大 5 つ挙げなさい

フォーマットは次のとおりです

    ```
    ## カテゴリ1
    - [記事1-1](url)
    - [記事1-2](url)
    - [記事1-3](url)
    - ...

    ## カテゴリ2
    ...
    ```

```

### 今回の学びや思ったこと
- 記事タイトルだけでは文脈が乏しいので、記事内容も少しは与えた方が良さそう
- ソフトスキル・エンジニアリングとナレッジングは新しい概念なので、文脈として別途与えるべき
- たぶんソフトスキルのカテゴリーを洗い出してもらうよりも、私が定義した上で、それに從って分類してもらった方が良さそう

---

# ソフトスキルを 5C に分類する

## サマリー
- エンジニアにとっても面白くて役に立つ、ソフトスキルの分類をつくりました
- また、各分類にあてはまる過去記事（これまで開発してきたソフトスキルや概念）も紹介しています
- 今の時代、ソフトスキルは万人にとって重要と思います。ぜひお役立てください！

## 背景
- 私は[ソフトスキル・エンジニアリング](https://dev.to/stakiran/soft-skills-engineering-34mg)を立ち上げました
- ソフトスキルのカテゴリーに正解はありません
- 生成 AI に頼めばいくらでもつくってもらえますが、大して役に立ちませんし面白くもないです

そこで、エンジニアにとっても面白くて役に立つカテゴリーをつくりました。

## 5C
**ソフトスキルの 5C 分類（5C）** とは以下の五つを指します。

- Communicaiton
    - A と B によるやり取り（`A <-> B`。二者間のやりとり。直接的）
- Collaboration
    - アウトプットを通じたやりとり（`A <-> Output <-> B`。間接的）
- Consolidation
    - 高密度な体験をつくること
    - 例: ペアプログラミング、モブプログラミング、コミュニケーションタイム、リトリート、その他イベント
- Culture
    - 個人やチームや組織の国の文化に関すること
    - 例: ビジョン、働き方、役割と階層性、組織パラダイム、使用ツール等
- Care
    - 人間である自分をどう世話するか、制御するか、上手くメンテナンスするか
    - 例: 個人のタスク管理、ウェルビーイング、その他セルフマネジメントでくくられるもの

## 5C のポイント
三点で整理します。

### ポイントその1: マネジメントやリーダーシップは含んでいない
ソフトスキルと聞いて「マネジメント」や「リーダーシップ」を浮かべる人は多いと思いますが、5C では扱いません。

どちらかと言えば、5C では「やり方」にフォーカスしています。

たとえば、Communication をするのか（二者間のやりとりをする）、Collaboration をするのか（アウトプットを育んでいく）、あるいは Consolidation をするのか（高密度な体験を演出して満足度を高める）を選びます。この 3 つのバランスを考えてください、と提示しています。**3C バランス** と呼びましょうか。

残念なことに、単一的なやり方を強要するマネージャーやリーダーはあまりに多い。たまたま噛み合うのならばいいですが、強要する形になっているのだとしたら最悪です。搾取に他なりません。このあたりを軽減する考え方が [DEI](https://dev.to/stakiran/engineering-and-dei-2k51) ですが、大事なのは、より具体的な議論です。5C では Communication、Collaboration、Consolidation の 3 点で捉えます。

よくあるのが「Communication しか知らないパターン」と「常に Consolidation を強要するパターン」です。別にこれらの強要型に合わない人材は解雇して、合う人材が来るまで待つのでもいいですが、少なくとも人件費はかかりますし、現場も疲弊します。長期的に見ると競争力も落ちる。

私達は人間なので、やり方こそが重要なのです。3C バランスをぜひ意識してください――といわれても、どうすればいいかわからないでしょう。そこでソフトスキルが役に立ちます。

### ポイントその2: 自分で自分の世話をする Care という視点がある
ソフトスキル、特にセルフマネジメントというと、一部のフリーランスか上級エンジニアが始めて触るもののように聞こえます。

私はそうは思わなくて、エンジニア万人が身につけるべき視点であり素養であると考えます。なぜならエンジニアリングは創造的なものであり、正解がないからです。したがって自分の、自分による、自分のための過ごし方を開拓するのが、最も快適で高いパフォーマンスを出すための近道になります。

- 関連記事: [Beyond Productivity: Embracing Experiencity - DEV Community](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)

しかし、自分のことを自分で管理するには、それなりのスキルが要ります。まさにソフトスキルでカバーできることです。

### ポイントその3: Culture を据えていること
文化はやはり大事です。

現代はチームの時代と言えますが、チームがなぜ重要かというと、皆で一丸になって進むのが最も高いパフォーマンスが出るからです。グループはただの集まりですが、**チームは「一丸になれたグループ」を指す** と私は思います。

問題は「どうやったら一丸になるか」ですが、答えは文化です。何らかの文化 C1 がインストールされたら、そのチームは C1 をベースとして一丸になれます。別に C2 でも C3 でも構いませんし、もちろん C1 であっても長い目で見ると変化はありえます。

SSoT（信頼できる唯一の情報源）という言葉がありますが、これと同様で、文化はいわば SSoV――Single Source of Values です。

もちろん、その文化をどうやってつくるのか、また皆に従ってもらうのかという問題はあります。これは本当に難しいことです。「文化は結果論だ」という人も多いくらいには難しいです。

ヒントはあります。ソフトスキルです。ソフトスキルをどれだけたくさん知り、試して回せるかどうかが鍵です。たとえば心理的安全性という概念を知っている人と知らない人とでは、そのチームに合った文化をつくれる率にも差が出るでしょう。このような「概念」は数多くありますし、何なら **新たにつくることもできます**。

## 5Cに基づいた過去記事の分類
私はソフトスキル・エンジニアとして、様々なソフトスキルと概念を開発してきました。その一部は、この DEV ブログにも投稿しています。

そこで、過去記事を 5C に基づいて分類してみます。せっかくなので生成 AI を使いましょう。3 記事ほど分類してもらおうと思います。つまり 15 記事のリンク集です。また、せっかくなので複数モデルの出力を並べてみます。

ぜひ眺めてみてください。使えそうなソフトスキルや概念と出会えることを祈っています！

## ======== GPT-5.1 ========

### Communication
- (2025-11-20): [Text Based 1-on-1s are Effective](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)
- (2025-12-01): [Online Meeting Sucks!](https://dev.to/stakiran/online-meeting-sucks-1g7l)
- (2025-11-24): [On Engineers Having to Do Emotional Labor](https://dev.to/stakiran/on-engineers-having-to-do-emotional-labor-5d59)

### Collaboration
- (2025-11-25): [Divergent Work Using GitHub](https://dev.to/stakiran/divergent-work-using-github-2kk8)
- (2025-12-04): [ChatGPT Projects as a Means of "Indirect Conversation"](https://dev.to/stakiran/chatgpt-projects-as-a-means-of-indirect-conversation-gf9)
- (2025-11-28): [Change the Color of the Production Environment Screen](https://dev.to/stakiran/change-the-color-of-the-production-environment-screen-53a2)

### Consolidation
- (2025-11-30): [What is a "Retreat" Suitable for Engineers](https://dev.to/stakiran/what-is-a-retreat-suitable-for-engineers-g12)
- (2025-11-24): [In-House Production and Introspection](https://dev.to/stakiran/in-house-production-and-introspection-kkg)
- (2025-11-22): [Notes and Boards as Virtual Offices: A Lightweight Approach](https://dev.to/stakiran/notes-and-boards-as-virtual-offices-a-lightweight-approach-59n4)

### Culture
- (2025-11-24): [Full-Four: Full Remote, Full Flex, Full Async, Full Mask](https://dev.to/stakiran/full-four-full-remote-full-async-full-mask-270)
- (2025-11-25): [Engineering and DEI](https://dev.to/stakiran/engineering-and-dei-2k51)
- (2025-11-26): [Engineers, Managers, and Spreaders](https://dev.to/stakiran/engineers-managers-and-spreaders-4fl7)

### Care
- (2025-11-29): [Beyond Productivity: Embracing Experiencity](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)
- (2025-11-25): [Mastering Personal Retrospection: KPT YWT 4Y](https://dev.to/stakiran/mastering-personal-retrospection-kpt-ywt-4y-2p1m)
- (2025-11-27): [List of "Task Attributes" for Implementing Task Management](https://dev.to/stakiran/list-of-task-attributes-for-implementing-task-management-5e87)

## ======== o1 ========

### Communication
- (2025-12-01): [Online Meeting Sucks!](https://dev.to/stakiran/online-meeting-sucks-1g7l)  
- (2025-11-20): [Text Based 1-on-1s are Effective](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)  
- (2025-11-27): [MAMA (Meeting as an AMA)](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)

### Collaboration
- (2025-12-06): [RAP Framework for Asynchronous Work](https://dev.to/stakiran/rap-framework-for-asynchronous-work-1mge)  
- (2025-11-25): [Divergent Work Using GitHub](https://dev.to/stakiran/divergent-work-using-github-2kk8)  
- (2025-12-04): [ChatGPT Projects as a Means of "Indirect Conversation"](https://dev.to/stakiran/chatgpt-projects-as-a-means-of-indirect-conversation-gf9)

### Consolidation
- (2025-11-30): [What is a "Retreat" Suitable for Engineers](https://dev.to/stakiran/what-is-a-retreat-suitable-for-engineers-g12)  
- (2025-11-29): [Beyond Productivity: Embracing Experiencity](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)  
- (2025-12-05): [Senior Roles' Context Revealed in the Calendar](https://dev.to/stakiran/senior-roles-context-revealed-in-the-calendar-lja)

### Culture
- (2025-11-25): [Engineering and DEI](https://dev.to/stakiran/engineering-and-dei-2k51)  
- (2025-11-24): [Full-Four: Full Remote, Full Flex, Full Async, Full Mask](https://dev.to/stakiran/full-four-full-remote-full-flex-full-async-full-mask-270)  
- (2025-11-26): [Engineers, Managers, and Spreaders](https://dev.to/stakiran/engineers-managers-and-spreaders-4fl7)

### Care
- (2025-11-25): [Mastering Personal Retrospection: KPT YWT 4Y](https://dev.to/stakiran/mastering-personal-retrospection-kpt-ywt-4y-2p1m)  
- (2025-11-27): [List of "Task Attributes" for Implementing Task Management](https://dev.to/stakiran/list-of-task-attributes-for-implementing-task-management-5e87)  
- (2025-11-21): [HQRST is Recommended for Lightweight Task Management](https://dev.to/stakiran/hqrst-is-recommended-for-lightweight-task-management-3nlg)  

## ======== GPT-5 ========

### Communication
- (2025-12-07): [Rapid Q&A](https://dev.to/stakiran/rapid-qa-c83)
- (2025-11-20): [Text Based 1-on-1s are Effective](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)
- (2025-11-20): [There's a Limit to Chat Tools — Enter QWINCS!](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb)

### Collaboration
- (2025-12-06): [RAP Framework for Asynchronous Work](https://dev.to/stakiran/rap-framework-for-asynchronous-work-1mge)
- (2025-12-04): [ChatGPT Projects as a Means of "Indirect Conversation"](https://dev.to/stakiran/chatgpt-projects-as-a-means-of-indirect-conversation-gf9)
- (2025-11-19): [What is Knowledging?](https://dev.to/stakiran/what-is-knowledging-2229)

### Consolidation
- (2025-11-30): [What is a "Retreat" Suitable for Engineers](https://dev.to/stakiran/what-is-a-retreat-suitable-for-engineers-g12)
- (2025-11-27): [MAMA (Meeting as an AMA)](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)
- (2025-12-01): [Online Meeting Sucks!](https://dev.to/stakiran/online-meeting-sucks-1g7l)

### Culture
- (2025-11-24): [Full-Four: Full Remote, Full Flex, Full Async, Full Mask](https://dev.to/stakiran/full-four-full-remote-full-flex-full-async-full-mask-270)
- (2025-11-25): [Engineering and DEI](https://dev.to/stakiran/engineering-and-dei-2k51)
- (2025-11-21): [Closed Anonymity](https://dev.to/stakiran/closed-anonymity-2n07)

### Care
- (2025-11-29): [Beyond Productivity: Embracing Experiencity](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)
- (2025-11-21): [HQRST is Recommended for Lightweight Task Management](https://dev.to/stakiran/hqrst-is-recommended-for-lightweight-task-management-3nlg)
- (2025-11-25): [Mastering Personal Retrospection: KPT YWT 4Y](https://dev.to/stakiran/mastering-personal-retrospection-kpt-ywt-4y-2p1m)

---

# クローズドな匿名

## サマリー
- 実名のデメリットは「常に配慮が必要」であること、つまり高負荷であること
    - ゆえに本質的な議論に集中しづらい
    - 心理的安全性が謳われるが、構築と維持が難しいし、これだけでは足りない
- そこで「クローズドな匿名」が役に立つ
    - 実名の本質的高負荷を回避するためには匿名を使いたいが、ガバナンスも確保したい
    - そこで「特定の組織範囲内で匿名にする」との塩梅を使う

## 背景

### まだ実名を使っているの？
私達は現代であっても未だに実名で仕事をしています。

言うまでもなく、実名は高負荷です。なぜなら自分と相手の顔が具体的に見えているがゆえに、常に言動に配慮しなければならないからです。恒常的に情報量（特に非言語的な情報量）が多いと言ってもいいでしょう。これがプライベートやエンターテイメントであれば問題ないですが、私達はエンジニアであり、仕事をしています。一体いつまで原始的な非言語コミュニケーションに溺れるのでしょうか？

本当は非言語コミュニケーションそのものを変革したいですが、長い道のりです。今回は割愛します。代わりに、本記事では **実名を使わない発想** をお届けします。つまりは匿名です。

### 匿名の力
匿名コミュニケーションのメリットは、配慮が要らないことです。というより、できません。具体的な相手が見えない以上、配慮のしようがないからです。もちろん人として最低限の礼節は持つべきですが、最低ラインをクリアできるなら、あとは何をしていいわけです。

なぜインターネットがここまで発展したかを考えてください。匿名のおかげです。あるいはハンドルネームやアバターといった仮想人格のおかげでもありますが、いずれにせよ、実名はあまり使われていません。皆さんが当たり前のように使っているオープンソースもそうです。実名を晒すことなく、匿名か、それに近しい仮想人格であって、いや、だからこそ、ここまで発展できました。余計な配慮をせず、その分を議論や開発に費やせたからです。

この匿名の軽さを使いこなしたい。

## クローズドな匿名

### これは何？
**クローズドな匿名（Closed Anonymity）** とは、ある組織単位内で匿名を導入することです。

たとえば Slack や Teams のチャンネルを考えます。あるチャンネルに 7 人がいるとします。ここにクローズドな匿名を導入すると、チャンネル内のすべての発言が匿名になります。しかし **匿名とはいえ、7 人のうち誰かがであることはわかりきっています**。これがクローズドな匿名です。限定的な範囲内で匿名にしているだけなので、その範囲内に存在するメンバー全員が候補となるわけです。

### 「たったそれだけ？」
「たったそれだけ？」

と思われたかもしれませんが、これが実に強力なのです。

すでに述べたとおり、実名は高負荷です。匿名は無負荷です。低負荷ではありません。無負荷です。**「無い」** のです。

小さな違いかもしれませんが、小さな違いが生み出すパワーはエンジニアの皆さんならわかるはずです。生成 AI もそうですよね。AI コーディングアシスタントを使っている皆さんは、もし「ChatGPT にコピペするのと大差ないでしょ」と言われたらどう感じますか。「そんなことはない」ですよね。たかがコピペ、されどコピペ。コピペの小さな手間の違いは、非常に大きいものなのです。

同じです。そのような発想を、実名という概念にも適用するだけです。ね？かんたんでしょ。

……理解できなくても落ち込まないでください。概念の理解は難しいです。だからこそ[ナレッジング](https://dev.to/stakiran/what-is-knowledging-2229)というジャンルがあり、私のようなナレッジ・アーキテクトがいます。概念の開発と啓蒙は我々にお任せください。皆さんはただ一つ、クローズドな匿名という概念だけ持ち帰ればよろしい。

### お試しください
皆さんが普段使っているコミュニケーションツール上で、ぜひクローズドな匿名を実装してみてください。

シンプルに試したいならフォームを使いましょう。Google フォームや Microsoft Forms のことです。フォームを一つつくり、コメント欄を一つだけつくります。名前を収集しない設定（つまり匿名）にします。これを皆に共有するのですが、フォームだけでなく **フォームに集まった回答を見るためのリンクやシートも共有してください**。これにより、全員が匿名で投稿しつつ、その結果も確認できるようになります。これを **匿名コメントフォーム（Anonymous Comment Form）** と呼びます。ACF と略します。

ACF を使って、カジュアルな議論や相談をしてみてください。雑談でも構いません。ファーストペンギンが数人くらい必要でしょうが、実名とは違った、圧倒的な投稿のしやすさと楽しさを体験できるはずです。

ACF と聞くと、何とも原始的に聞こえるかもしれませんが、そういうものです。匿名の概念、特に仕事において使うという発想は全く縁がないかと思います。既存ツールで実現するのは難しく、ACF が最もかんたんだと思います。

## おわりに
実名のデメリットは匿名により解消できますが、匿名だけでは使いづらいです。そこで組織単位内での匿名というものを考え、「クローズドな匿名」としてご紹介しました。

コミュニケーションは常にボトルネックになります。実名もそうです。だからこそ、クローズドな匿名を上手く活用して突破してみてください。ではまた。

---

# Communication As A Task ～非同期ワークを成功させるための考え方～

## 背景

### 非同期ワークが有用なのは言うまでもない
私達エンジニアは集中を要しますが、集中に必要な道具や方法や手順は人それぞれです。オフィスという単一的な環境では限界があります。

また私達はエンジニアである以前に人間であり、人間なので実生活の負荷は抑えたい。たとえば通勤で疲弊するのは馬鹿げています。片道 30 分だとしても、準備や片付けやコンテキストスイッチングがあるので **実際は片道 1 時間くらいはかかっているに等しい**。往復すると 2 時間ですね。2 時間あれば何ができるでしょう。

個人個人の集中を確保し、また人間として労るにはリモートが必須です。そのためには非同期ワークが必要です。

### 未だに出社回帰しがちという現実
GAFAM や MATANA でさえも、未だに出社回帰を唱えています。大前提として出社して生産性が出るのは当たり前です。時間や場所を拘束することは搾取であり、搾取して成果を出せるのは当たり前だからです。それこそ王様の暴政として、奴隷のように酷使しても成果は出せます。

そうでなくとも、大半の人はなぜか集まりたがります。たしかに集まると賑やかで楽しくて退屈しませんし、社会的にも満足度が高いですが、それだけです。中には合う人もいますが、集中と負荷の観点では好ましくない。少なくとも万人に押し付けることではないのです。

なぜこのような押し付けが横行しているか。単純な話で、そういう集合的な働き方を好む人達が権力を握っているからです。また組織規模が大きくなると、構造的に無駄が増えてサボタージュも増えるので、それを防ぐために出社を踏み絵にしがちです。

### 一見するとフルリモートだが……
また、一見するとフルリモートか、それに近しい組織であっても **内情はオンライン会議ばかりしている** ケースが少なくありません。これでは出社と大差ありません。

出社は場所と時間の両方を束縛しますが、オンライン会議は時間を束縛しています。束縛していることにかわりはない。集中と労りを手に入れるには、束縛自体を減らさねばなりません。オンライン会議も減らす必要があるのです。

したがって **非同期ワークとは、リモートかつオンライン会議にも頼らずに働く** ということです。

### 非同期ワークを成立させるための考え方
長年私が啓蒙してきて気付いたのは、非同期ワークを成立させるための前提をそもそも押さえていない、ということです。

今回は、この前提を言語化します。コミュニケーションをタスクとして捉えます。

## Communication As A Task
**Communication As A Task** とは、コミュニケーションをタスクと捉える考え方です。**CaaTと略します**。

非同期ワークにおけるコミュニケーションは無論非同期コミュニケーションになります。非同期コミュニケーションを嫌う人は多いですが、それは単に前提を理解していないからです。

非同期コミュニケーションはタスクとして捉えるべきなのです。

タスクとはオープン・クローズの概念がある事柄を指します。オープンしたら始まり、クローズしたら終わります。つまりコミュニケーションの機会や、そこで扱われる話題を全部タスク化して処理するということです。クローズしたら終わり、という基準に持ち込むことでメリハリがつきます。

## 例
マネージャー M とエンジニア E が、45 分の 1on1 をしたとします。トピックは以下とします。

- 1: アイスブレイク
- 2: Eのキャリアについて
- 3: プロジェクトPに関する話題1と話題2
- 4: PのメンバーM1とM2の相性の悪さと対処について
- 5: クロージング

これを CaaT として捉えるとどうなるでしょうか。以下のようになります。

- タスク1「アイスブレイク」、3分で終わらせる
- タスク2「Eのキャリアについて」
- タスク3「プロジェクトPに関する話題1」
- タスク4「プロジェクトPに関する話題2」
- タスク5「PのメンバーM1とM2の相性の悪さと対処について」
- タスク6「クロージング」、2分で終わらせる

見てのとおり、全部タスクにします。その上で、この 6 のタスクを全部終わらせることを考えます。

- アイスブレイクとクロージングは制限時間型が良いでしょう。指定時間が過ぎたら自動的に終了させます
- その他のタスクは通常型で良いです。つまり、どちらか片方または双方の合意でクローズをしたら終わりです

もちろん、**これら 6 のタスクをミーティングとして行う必要は全くありません**。非同期でやればいいのです。Slack を使うなら、E と M の二人が入ったチャンネルをつくって、スレッドを 6 本つくればいい。GitHub Issues でやるなら Issue を 6 本立てればいい。

そもそも非同期ならアイスブレイクやクロージングは要らないので、4 本で十分です。あるいは雑談が欲しいのなら、それ用のスレッドや Issue を立てて、そこで半永久的にやればいいでしょう。

と、このように考えます。コミュニケーションとしてやりとりする話題をタスクと捉えて、オープンとクローズをするのです。

## 味気ないと思いますか？
CaaT を受けて「味気無い」「人間味がない」と思われた人も多いでしょう。

たしかにそのとおりですが、別に構わないのではないですか。私達はエンジニアであり、仕事をしているのです。友達と遊んでいるわけではない。学生ではないのだから、もっとプロフェッショナルとしての自覚を持つべきです。

もちろん私達も人間ではあり、社会的な営みはある程度必要ですが、それはそれとして機会を設ければ済みます。週に一度、月に一度、あるいはもっと低頻度で集まればいいでしょう。リトリートを行う組織もよく見ます。

私は **コミュニケーションタイム** と呼んでいますが、社交的な時間は「仕事はしないが業務時間の一部として」確保することをおすすめしています。マインクラフトでも、ボードゲームでも、もちろん雑談でもいいです。確保の仕方についても、定期的にやってもいいですし、各自が好き勝手に調整してもいい。後者の例として [GitLab の Coffee Chat](https://handbook.gitlab.com/handbook/company/culture/all-remote/informal-communication/) があり、これはいつでも誰でも誰にでも 1on1 を申し込めるというものです。

---

# 継続的リマインディング

## 背景

### リマインダーが最強
自身のタスク管理には悩まれているかと思います。最も強力なのは **リマインダーです**。タスクリストはすぐに形骸化しますし、カレンダーはミーティングが仕事のマネージャーや経営者はともかく、エンジニアには力不足のツールです。

エンジニアを救うのはリマインダーだけです。なぜならリマインダーをセットしておくと、たとえ集中していたとしても気付けるからです。たとえばミーティングや外出を忘れてしまうこともなくなります。

「カレンダーにリマインダー機能があるじゃないか」って？

そうです。ですからリマインダーは偉大でしょう？逆に考えてみてください、リマインダーのないカレンダーを……。私はすっぽかすのが怖くて怖くて、とても仕事に集中などできやしません。

### リマインダーは重い
しかし、リマインダーは重たいです。タスクリストだと、それこそプレーンテキストベースであれば一行書いておしまいですが、リマインダーは違います。おそらく GUI のカレンダーを開いて、あれこれ画面をいじくってようやく設定できるでしょう。面倒くさいですね。

### リアクティブワークの呪い
ところで、私は **リアクティブワーク(Reactive Work)** という概念をつくりました。その名のとおり、反応的に仕事をすることです。Slack に通知が来たから反応する、誰かから話しかけられたから答える、会議を設定されたから参加する――忙しい皆さんが陥っているワークスタイルです。忙しい状況を凌ぐのには適していますが、創造的に難しい問題に取り組む際は不適切です。

しかし、**これ以外の働き方ができないのも割と事実でしょう**。

優秀なエンジニアリングマネージャーやスタッフエンジニアでさえ、リアクティブワークから逃れるのは容易ではありません。もちろんそんな人達が難しい問題に取り組めるはずがない。面倒な問題や、時間をかければできる程度の問題を早く解くのは得意ですし、まさにそれができることに価値があるわけですが、それだけです。

私は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として脱リアクティブワークに取り組むことも多いですが、正直難しいです。たぶん人々が脱せるようになるよりも、中堅エンジニアを AI が完全に代替する方が早く到来します。それくらいに難しいです。

### リアクティブワークと創造を両立する
そこで私は発想を転換しまして、リアクティブワークになるべく頼ったまま、しかし反応的ではなく創造的に過ごせる余地も確保するにはどうすればいいか、を考えるようになりました。

リマインダーに目をつけて、ようやく一つの解が見えてきたので共有します。

## 先送り可能なタスク
**継続的リマインディング(Continuous Reminding)** とは、先送り可能なタスクを管理することを指します。その手段としてリマインダーを使います。このようなリマインドを **コリマインド(Coremind)** と呼びます。

### 例と Before/After
例として、3 時間後くらいにタスク A をやりたいとしましょう。リマインダーをセットします。3 時間が経過して、A がリマインドされました。しかし、きりが悪くて今は取り組めず、あなたは「20 分後にしてほしい」と思いました。どうしますか？

Before から論じましょう。従来だと「セットするのが面倒くさいリマインダー」をもう一度セットする羽目になります。あるいは、タスク A だけなら頑張って腰を上げられるかもしれませんが、このようなタスクが 2 個あったら？ 3 個あったら？確実に腰は上がらないでしょう。そしてタスク A を忘れるのです！

次に After です。コリマインドを使うとどうなるでしょうか。これは単純で、 **リマインダーが提示した「20分後にお願い」という選択肢を選ぶだけ** です。これだけで、このタスク A のリマインダーが即座に 20 分後に延長されます。

もちろん 20 分後にもう一度リマインドされますが、そのときもまた即座に判断すればいい。5 分後でも、20 分後でも、1 時間後でも、明日でも、もちろん「やっぱりやらなくて良くなったので破棄」でもいい。

## 🔧プロトタイプをつくりました
ぜひ触ってみてください。

- Prototype
    - 👉️ <https://stakiran.github.io/continuous_reminding/>
- GitHub
    - 👉️ <https://github.com/stakiran/continuous_reminding>
    - Cline でつくっています。日本語です

動作を早く確認するため、1～60 秒後しかセットできないようになってますし、指定がなければ 3 秒後にリマインドされます。このおかげで、コリマインドの感じを手早く体感できると思います。

## リマインドを数十個抱える未来
継続的リマインディングを実現できたとしたら。

私達は数十個以上のコリマインドを抱えることになるでしょう。なぜなら **自分の感覚で先送りできるため、リマインドのペースが次第に落ち着いたバランスに収束していくからです**。

重要度の低いタスクは遠くに押しやられますし、そうでないものは何度もリマインドされるでしょう。また、重要度の変化を直感的に反映できます。たとえば 20 分後ではなく 3 時間後にしたり、それこそ明日に回したりもできるわけです。もちろん、すべてリマインダーとして仕込まれているため **忘れることはありません**。というより、忘れていてもリマインドされるので思い出せます。

継続的リマインディングは、リアクティブワークを地で行きます。あなたはリマインダーを設定し、かつリマインドされた内容に応えるだけ。それだけで回るようになります。

このように多数のコマインドをセットして、ならしていくことは、まるでリマインダーを飼っているかのようです。私はこれを **育つリマインド** と表現します。リマインダーは生き物なのです。これはタスクリストでもカレンダーでもない、第三のパラダイムだと思います。

---

# クリエイティブ・シンキング入門

## サマリー
- クリエイティブ・シンキングの現状
    - 未開拓のジャンルであり、各自が好き勝手に定義・解釈している
    - 本質を捉えたものは一つとして見当たらない
- クリエイティブ・シンキングとは
    - Open-Ended Situation に対抗できる唯一のアプローチ
    - 管理を一切行わず、かわりに探索を行う
- クリエイティブ・シンキングのアプローチ
    - コミュニケーションでもドキュメンテーションでもなく「スプレディケーション」
    - チームワークよりも「ソロワーク」
    - 探索の営みを絶対守るための「シールド・アンド・パージ」

## 背景

### 革新が求められる時代
現代は VUCA と呼ばれ、正解がないのに変化が激しい時代です。また DEIB ともいわれるように私達自身の要求水準も上がっています。開発者についても DevEx や DevRel といった尊重、配慮、顧客化のアプローチが重要視され始めています。

このような時代を生き抜くには革新が必要です。

別に社会そのものを変える必要はありませんが、少なくとも私達とその周辺は変えていかなければならない。それを持続的に行えるだけの力と仕組みがほしい。これは目の前の技術的問題を解決すればいいという「硬い仕事」ではありません。むしろ、硬い仕事を発見するまでの探索であり、全く違った戦略が必要です。

### Open-Ended Situation と創造性
このように正解がなく、方向性も見えない状況を **Open-Ended Situation（OES）** と呼ばせてください。その名のとおり、どこまでも開かれていて、ゴールと呼べる建物や地点がない。むしろ何がゴールなのかを自ら決めねばなりません。

そういうわけで、OES には本質的に創造性が必要なのです。

### クリエイティブ・シンキングを履き違えている人達
創造性に再現性をもたせるべく、クリエイティブ・シンキングと呼ばれるジャンルがすでにあるようですが、既存のそれらは履き違えているように思います。

たとえば次のような説明をします。

- ブレインストーミングが重要だ
- ブレストで出したアイデアの検証が必要だ
- マーケティングチャネルの開拓を推し進めよ etc

違います。全然違います。**創造とは探索です**。実際に計画を立てたり作業に入ったりする **前** の営みであり、具体的な成果物は何一つありません。あるのは言語で表現されたテキストだけです。生成 AI でたとえるなら、プロンプトをつくるところまでです。

創造には深いダイブと高く遠い飛躍が必要であり、計画も管理も作業もあらゆる「仕事に関する営み」が邪魔になります。すべてを排除して、真に思考と言語化に集中できなくてはならないのです。クリエイティブ・シンキングはそのために設計されねばならない。

ですので、私は立ち上がりました。クリエイティブ・シンキングとは何たるかをお教えします。

## クリエイティブ・シンキング

### 概要
**クリエイティブ・シンキング** とは、革新との出会いを最大化するためのメソッドです。

目的は Open-Ended Situation の打破であり、実際に何らかの仕事をする前段階の営みに相当します。

クリエイティブ・シンキングの本質は探索であり、「見えてきた」と思えるまで、ひたすら思考と言語化を行います。あらゆる制約を無視して、真にテーマのことだけ考えて、何ならテーマから逸れて寄り道もして、そうして探索して探索して探索します。その果てに「これだ！」という何かが見つかります。見つかるまで粘れるかどうかがすべてです。

そのためには「創造」の名前のとおり、深いダイブと高くて遠い飛躍が必要になります。これを邪魔するすべてを排除しなくてはなりません。計画もしませんし、管理もしませんし、タスクも課しません。チームワークやコミュニケーションといった免罪符を使って自らの粘り弱さや寂しさを誤魔化すこともしません。

### クリエイターの営みに再現性を持たせる
今のところ、クリエイティブ・シンキングを身に付けているのは一部のクリエイターだけです。

**エンジニア、マネージャー、経営者はおそらく 99% は当てはまりません**。なぜならこの人達は単に上位からの命令や周囲の傾向を見て、從っているだけだからです。それは創造ではなく、ただの作業にすぎません。行動力とパフォーマンスと解釈の仕方に違いがあるだけです。ただのハイパフォーマーや賢い人にすぎない。クリエイターではない。

クリエイターというと、私は日本のマンガや小説、あるいはイラストレーションを思い浮かべます。日本は最先端であり、1日12時間以上の創作を何年も続けるような怪物がたくさんいます。そんな侍の国で生まれ育った私だからこそ、探索を天才の営みから再現性のあるメソッドにしたいと考えました。

## クリエイティブ・シンキングの 3 要素
クリエイティブ・シンキングの考え方とやり方を示すために、3 つの要素で整理してみました。

### 1: スプレディケーション
コミュニケーションでもなく、ドキュメンテーションでもなく、**スプレディケーション（Spreadication）** です。スプレディケーションとは発散、収束、蒸留から成るアイデア整理の営みを指します。

比較してみましょう。

コミュニケーションは 1 対 1 でやりとりします:

```
A <---> B
```

N 対 M もありえますが、コンピュータのマルチタスクが実際にはシングルタスクの高速な切り替えであるように、コミュニケーションも最小単位は 1 対 1 です。単にこの単位が複雑に変化し、積み重なるだけです。

次にドキュメンテーションはドキュメントをつくって、それを介してやりとりします:

```
           C
           |
           v
A ---> Document <--- B
```

リアルタイムな聞く・話すではなく、書いておく・読んでおくといった遅延的なやりとりが可能になります。また複雑な情報も伝えきることができます。

最後にスプレディケーションはワークスペースをつくって、そこで各自探索します:

```
                         c
                         |
        +----------------|---+
     A----->             |   |
        |                v   |
        |     Workspace      |
        |                    |
        |                 <------B
        +--------------------+
```

ワークスペースの中には大量のアイデアその他情報があります。各自は好き勝手に膨らませていきますし、他の人のも積極的に利用します。

### 2: ソロワーク
**ソロワーク** とはチームワークの対義語であり、ひとりで活動することです。

ソロワークの最中は、以下をしません:

- 同期的なコミュニケーション全般。ミーティングや雑談も含む
- 計画の踏襲。計画をつくる、予実管理をする、進捗管理する等
- タスクの遂行。締切やその他定量的な保障を確保できるまで粘る等
- 特定の働き方に合わせること

他人とコミュニケーションを行わず、計画も締切もなく、働き方も自分の好きにできます。そのかわり **ソロワークは孤独です**。またサボっていては意味がないので、探索は進めなくてはなりません。正解がなく、終わりも見えず、誰も指針を示してくれない Open-Ended Situation を、ひとりで探索し続けなければならない。

例外はありますが、

- いつまで探索するのかという期間（スコープ）は与えられる
    - たとえば「今から2週間だけやろう」など
- 他の人が書いたものを読んだり、それを使って膨らませたり、コメントを書いたりはできる

これだけです。本質的には孤独です。ソロと名付けているのもそのためです。

なぜソロになるかというと、一切の邪魔がなくなるからです。邪魔をゼロにして、自分ひとりで深く入り込むことだけが創造に至る唯一の道です。孤独から逃げることはできないのです。

### 3: シールド・アンド・パージ
**シールド・アンド・パージ** とは、ソロワークを守ること（シールド）と、ソロワークを阻むものを排除すること（パージ）を指します。

容易に想像できるとおり、ソロワークを維持しながらスプレディケーションを続けることはかんたんではありません。厳格なセキュリティやガバナンスと聞いて思い浮かべる水準くらいに、徹底的に心がけねばなりません。

CPPF という言葉があります。子供、パートナー、ペット、友達の略で、クリエイターならこれらを徹底排除せよとするものです。これが正しいかは人次第かつ状況次第ですが、クリエイターはこれくらいしてもおかしくはないのです。クリエイティブ・シンキングでも、この本質から逃げてはいけません。むしろ持続させるためにシールドとパージの両方を掲げます。

## おわりに
クリエイティブ・シンキングの考え方と三つの本質についてご紹介しました。

Open-Ended Situation に対抗するためには、クリエイターが行っているストイックな営みを私達もやらねばならないのです。これは決して天才の営みではなく、再現性を持たせられるメソッドです。私はそう信じていますし、そのために[ソフトスキル・エンジニア](https://dev.to/stakiran/soft-skills-engineering-34mg) として
方法と概念を開発しています。

エンジニアの皆さんも、いや、エンジニアの皆さんだからこそ、ぜひ実践してみてください！

---

# 深い貢献と広い貢献

## サマリー
- 深い貢献とは、プロジェクトワークのこと
- 広い貢献とは、[トランスジェクト](https://dev.to/stakiran/project-vs-transject-cpd)ワークのこと
- 現代は「深い貢献」至上主義だが、求める人材レベルが高くなるため人材不足になりがち
    - これを軽減するために、広い貢献というパラダイムにシフトすると良い

## 背景

### 仕事≒プロジェクトワークであり、役割≒枠であるという現実
割とあらゆる組織で人材不足が叫ばれているかと思います。これは当然のことで、単に「仕事の捉え方」の融通が利かないからです。

例を挙げます:

- 仕事と言えば、現代ではほぼプロジェクトワークを指します
    - メンバーにはプロジェクトとチームに適応する総合力が必要です
    - これがない場合、優秀であっても戦力とみなされません
- 役割と言えば、現代では枠のモデルです
    - 事前に枠をつくっておき、ここに当てはまる者を探しています
    - ジョブディスクリプションの記述は千差万別ですが、これは枠の素材や色を変えているようなものであり、ポジションやロールの名前という「枠」自体は静的なものです

要は **総合力があり、かつ枠にはまる人材だけが通過する** というシビアさなので、そりゃ中々見つからないですよねという話です。

### エンジニアも例外ではない
私達エンジニアも例外ではありません。

特にマネージャーや上級エンジニアは人材の連携や調達も責務に含まれますので他人事ではありません。もちろん総合力の呪いと枠の呪いにとらわれているので人材が見つからず、苦労します。ですので通常は長い目で見て育成しなければなりません。コミュニケーションコストもかかります。まるで先生です。それを「必要だから」とか「育成も楽しいものだ」などと自分に言い聞かせて正当化します。大変ですね。

### パラダイムを変えるときが来ました
上述した文化は、私が **深い貢献（Deep Contribution）** と呼ぶあり方です。プロジェクトがまさにそうですが、特定のスコープに入り込んで、その中で忙しなく何でもやるわけですね。

ですが、このあり方だけでは限界があるのです。もう一つ、新しいパラダイムを導入するときが来ました！

## 深い貢献と広い貢献
**深い貢献（Deep Contribution）** とは、プロジェクトワークを指します。その名のとおり、あるスコープの中で、想定された結果に至るまで頑張ります。できない場合はできるまでやります。深く深く潜っているわけです。

一方、**広い貢献（Wide Contribution）** とは、プロジェクトに入りこまない、横断的な後方支援を指します。プロジェクトには一切所属せず、ベストエフォートで済みますが、その代わり影響を与える範囲が広いです。たとえば経営層でもないエンジニア **個人** が社内数千人以上の全社員に対して毎日ブログ記事を届けたり、全社員からの問い合わせを受け付けたりします。

数字で対比しましょう。

- 深い貢献は、ある 1 つのプロジェクトにおいて 100 のバリューを出します
- 広い貢献は、100 のプロジェクトに対して 1 のバリューを提供します

## 広い貢献の例
深い貢献はプロジェクトと呼びました。実は広い貢献にも呼び名があります。**トランスジェクト（Transject）** です。すでに記事を書いており、具体例も載せているので、こちらを読んでください。

- 👉️ [Project vs Transject - DEV Community](https://dev.to/stakiran/project-vs-transject-cpd)

## 広い貢献により人材不足が軽減する
なぜかというと、組織と仕事の構造化が進むからです。

深い貢献のみのあり方、つまりプロジェクト至上主義は、コードでたとえるならモノリシックです。スピード優先で突貫で書いた、汚くて見るに堪えないコードです。技術的負債もあったものではない。ですので、この汚さに耐えるだけの **総合的に優秀な** 人材が必要とされます。

では、広い貢献を認めて、広い貢献者を増やしていくとどうなるでしょうか。

広い貢献者を立ち上げるとは:

- 既存の仕事や組織を意図的に見直して、言語化して、モデル化して、その上でどこをどう切り出すかといったことに等しいです。これは共通データを変数したり、共通処理を関数化したりするようなものです
- 知って取り入れると便利になる考え方ややり方をつくって、整理して届けることにも等しいです。これは Linter や Formatter や型システムを導入したりする営みにも等しいです

いずれにせよ、短期的にはかえって手間がかかりますが、中長期的に見れば構造化が進みます。構造化に分があるということは、エンジニアの皆さんならよくわかっているはずです。

---

# ドライな振る舞い

## 背景
エンジニアの本懐はエンジニアリングであって、コミュニケーションではない。コミュニケーションなんて誰であろうと、必要なときに、必要な分を端的にやればいいのです。それで済んでいた。

それが、いつの間にかチームの時代となり、人間性だの尊敬だの心理的安全性だのといった社会的な営みが重視されるようになった。それらに適応できないエンジニアは相手にされなくなった。たとえば出社や対面ミーティングばかり求める者の、何と多いことか。顧客を相手にするならまだわかるが、なぜ同僚ごときにそんな手間をかけなきゃいけない？テキストコミュニケーション、非同期コミュニケーションでいいだろ。エンジニアの邪魔をするんじゃねぇ。

最近になって、一つの機運が訪れました。生成 AI です。この機会を逃してはいけない。エンジニアの時代を取り戻すのです。

## 概要
**ドライな振る舞い（Dry Behavior）** とは、生成 AI に対する態度を指します。

具体的には、テキストコミュニケーションかつ非同期コミュニケーションを行います。プロンプトを出して、相手の返事を待って、返事が来たらそれを確認して、追加のプロンプトをまた投げる――そんなサイクルを繰り返します。

**このサイクルを人間に対しても適用します**。つまり、生成 AI という機械に対してはある種ドライに振る舞っているわけですが、そんな振る舞いを人間に対しても行うわけです。

## メリット
コミュニケーションコストを浮かせることができます。

エンジニアにとっては、エンジニアリングに必要なコミュニケーションを最低限だけ行えます。空いた分はエンジニアリングに費やすことができます。

マネージャーにとっては、不器用なエンジニアと頑張ってコミュニケーションを営む苦労がなくなります。別に仕事ですので仲良くなる必要はないですし、必要なやりとりをドライな振る舞いで行う程度でも仕事は成立しますし、信頼関係もつくれます。

## デメリット
ドライな振る舞いを適用できる人の特定が難しいことです。

ドライな振る舞いは、言ってしまえば「人間扱いをやめますね」のようにも見えます。適用できる人を選べないと、ハラスメントになってしまうリスクがあります。

## サイクルの設計
ドライな振る舞いはサイクルとして設計します。

たとえば PDCA サイクルを使うと、次のようになるでしょう。

- Plan：相手に渡す文面を考える
- Do：相手に文面を送信する
- Check：相手の返事が来たら、確認する
- Act：次の文面を考えて渡すか、いったん終わる

ですが、PDCA は抽象的すぎてわかりづらいです。使いやすいサイクルを各自つくった方が便利だと思います。

参考までに、一つだけ私の方でつくったので、ぜひお使いください。

### 4Pサイクル
4P は以下から成ります。

- 1: Prompt。相手に渡す文面をつくって、渡します
- 2: Polling。相手からの返事を待ちます。ポーリングすれば良いです
- 3: Proofread。返事が来たら対処しますが、こちらで校正するつもりで望みます
    - つまり相手は下書きをつくる段階まで行うのであり、以降の清書はこちらでやるとの分担を敷きます
- 4: Plan。まだやりとりするのか、それともいったん終えるのかを考えます

```
 +---> Prompt ----+
 |                |
 |                V
Plan           Polling
 A                |
 |                |
 +-- proofread <--+
```

このサイクルは汎用的ではありませんが、その分、具体的で使いやすいと思います。

## おわりに
生成 AI と接するときのような「ドライな」態度を、人に対しても適用するという考え方をご紹介しました。余計なコミュニケーションを落として、エンジニアリングに集中する（してもらう）ために有益です。ぜひお試しください。

適用できる相手を見極めるのが難しいですが、1on1 で探りましょう。やってみたい、と答えるエンジニアもそれなりにいるはずです。もちろん、いない場合はおとなしく諦めましょう。

それではまた。

---

# エンジニア、マネージャー、そしてスプレッダー

## 背景

### エンジニア vs マネージャー
私達エンジニアはエンジニアリングをしていたい。エンジニアだけならいいのに、と言いたいところですが、そうも行きません。50 年以上前から、もう一つの役割「マネージャー」が必要不可欠だとされてきました。

ごく一部の優秀な少人数パーティか、ティール組織のような先進的な組織を除けば、必ずエンジニアとマネージャーの二つの役割が必要となります。しかし、どちらも生態が違うので、よく衝突します。私が好きな議論を一つ置いておきましょう。

- [Maker's Schedule, Manager's Schedule](https://www.paulgraham.com/makersschedule.html)

### どちらでも拾えない領域がある
最近気付いたのは、エンジニアでもマネージャーでも拾いきれない第三の領域があるということです。

たとえば [Glue Worker](https://www.noidea.dog/glue) はわかりやすいと思いますし、スタッフエンジニアのような上級職もすでに定着しています。要するに、典型的なエンジニアリングやマネジメントではまかなえない数々の細かい作業やフォローが実態として存在するわけです。それをこなすには、優秀なエンジニアやマネージャーによるボランティアか、あるいはスタッフエンジニアのような「権威を持った」縁の下の力持ちが必要というのが現代のコンセンサスです。

### 忙しい！人手が足りない！
しかし、そのような役割は絶対数が少ない。もちろんチーム全体、組織全体をまかなえるものではありません。

もう一歩踏み込まないといけません。エンジニアでもマネージャーでもない、第三のあり方を定義するときが来ました。

## スプレッダーについて
**スプレッダー（Spreader）** とは、その名のとおり「広める」ことに注力する役割です。

### 情報を広める
何を広めるかというと、**情報** です。

エンジニアやマネージャーが取りこぼしている情報を拾って伝えたり、外部のナレッジを内部に持ち込んで伝えたり、逆に組織全体のために内部のナレッジを整理して外部に出したりします（社内外ではなくチーム内外の話です）。手つかずの調査や整理をこなした上で連絡したりもします。エンジニアもマネージャーも苦手とするドキュメントその他執筆や共有もやります。

### 縁の下の力持ち
エンジニアは主に仕事に直接関係するエンジニアリングを行います。マネージャーは主にプロジェクトに直接関係する管理（プロジェクトマネジメント）を行います。あるいはプロダクトやピープルなど管理対象はいくつかありますが、いずれにしても仕事と直接関係がある事項のみを扱います。

一方、スプレッダーは、**直接関係があることは扱いません**。代わりに、そうではないすべてのことを担います。プロジェクトとメンバーのドメインを理解し、その人達が取りこぼしていることを回収するわけです。あるいは、お節介さながらに、もっとこうした方が良いというアイデアを形にして勧めたりもします。

### 活動内容に正解はない
スプレッダーの活動スコープに関しては、正解はありません。何をすればいいかはチームやプロジェクトや組織によって異なりますし、同じ場所でも状況次第で変わります。唯一守るべきことは、仕事に直接関係があることはしない、これだけです。言い換えると仕事に関する直接的な責任を負いません。しかし、エンジニアやマネージャーを支えるために全力を尽くさねばなりません。

## スプレッダーの例
スプレッダーは私が開発した「新しい概念」ですが、例はいくつかあります。

### Glue Worker
Glue Work とは[Being Glue — No Idea Blog](https://www.noidea.dog/glue)によると、次のとおりです。

> Like noticing when other people in the team are blocked and helping them out. Or reviewing design documents and noticing what's being handwaved or what's inconsistent. Or onboarding the new people and making them productive faster. Or improving processes to make customers happy.
> 
> I call all of this glue work.

ですので、Glue Worker とは Glue Work の専任者です。エンジニアやマネージャーがボランティアでやるのではなく、第三の役割スプレッダーとして、責任を持って取り組みます。

### カタリスト
[ナレッジング](https://dev.to/stakiran/what-is-knowledging-2229)においては、スプレッダーのことをカタリストと呼んでいます。チームの内外にナレッジを流したり、人に渡したりといった具体的な流通を重視しています。

## 時間の使い方
エンジニア、マネージャー、スプレッダーの違いを知るために、時間の使い方に注目しましょう。元の議論は[Maker's Schedule, Manager's Schedule](https://www.paulgraham.com/makersschedule.html)が参考になります。

### エンジニアは「まとまった時間」を欲する
たとえば「午前いっぱい」「午後いっぱい」などです。数字で言えば 3 時間くらいの枠になります。

エンジニアリングは創造的ですし、文脈も複雑でかなりの頭脳労働です。邪魔されることなく、自分のペースで集中し続ける必要があります。これにはまとまった時間が必要です。

### マネージャーは「会話の時間」を欲する
一方で、マネージャーは誰かと会話するのがメインなので、30～60 分の枠をたくさん持っておいて、そこに誰を入れようか、と考える。

元の議論でもあるとおり、エンジニアとの相性は最悪です。折衷案としてハイブリッドが推奨されています。エンジニアリングタイムとマネジメントタイムの二つをつくって、たとえば午前をエンジニアリングタイム、午後をマネジメントタイムにするわけです。エンジニアリングタイムの間は、マネージャーはエンジニアに会議を入れません。マネジメントタイムの間は、会議を入れてもいいです（エンジニアも会議が入ることを想定して過ごします）。

### 余談: ハイブリッドについて
ハイブリッドは折衷案としてよく使われます。本来は複数が混ざっている様を指し、二要素である必要はないのですが、二要素の混在という意味で使われる事が多いです。

働き方もそうですよね。たぶんあなたの職場もハイブリッドワークと称して、リモートと出社の比率を指定されていると思います。経営層がよほど独裁的でなければ、基本的にはハイブリッドのはず。もしそうでないなら、その職場は多様性がないので今すぐ転職しましょう。もちろん給与や仕事内容が素晴らしいのなら、あえて耐えてもいいですが。

### スプレッダーは時間枠を欲さない
ではスプレッダーは、どのような時間の過ごし方をするでしょうか。

実は時間枠そのものに頼りません。数字で言えば数分から 30 分くらいの、小さな枠を自由に切り替えながら、あちこちに影響を及ぼします。あのチャンネルにかんたんなコメントを書いて投稿して、あそこのドキュメントをちょっと直して、あれの進捗を確認して状況をリマインドして、勉強会用のネタを集めるための 5 分ライティングを消化して、AさんとBさんのあの議論を忘れてるからミーティングをセットしてあげて――、といろんなことを迅速に進めていきます。

一見するとエンジニアと似ていますが、エンジニアと違って創造的ではありません。どちらかと言えば「時間さえかけたら終われる作業」です。だからといって無限にできるものではないですし、コンテキスト・スイッチングが多いですから意外と疲れます。認知的な体力がフルタイムすら保たないことも珍しくありません。スプレッダーは第三のあり方であり、れっきとした役割なわけで、それなりに難しいわけです。

### 三つのあり方を共存するには？
では、エンジニアとマネージャーとスプレッダーの三つの役割が共存するには、どうしたらいいのでしょう。もちろんハイブリッドですが、あり方は二つではなく三つになります。

- **エンジニアリングタイム**
    - 孤独に深く集中する時間帯
    - 他者とのコミュニケーションはしないか、非同期的に行う
    - ただしペアプロ・モブプロなど、高密度なリアルタイムコミュニケーションを行うパターンもある
- **マネジメントタイム**
    - 会話する時間帯
    - 基本的に同期的コミュニケーションを行い、非言語コミュニケーションも伴うことが多い
    - カジュアルだろうとフォーマルだろうと、あるいはオープンだろうとクローズドだろうと、ミーティング全般はここに当てはまる
- **スプレッディングタイム**
    - ちょっとした共有や協力を行う時間帯
    - 従来ボランティアとして扱われていた作業、共有、回答や発信を行う

これら三つの時間帯を使い分ける必要があります。具体的には、一日のうち、どれをどれだけ行うかという比率を考えることになります。おおよそではなく目安でいいです。この比率を **アクティビティ・ポートフォリオ（Activity Portfolio）** と呼びます。

以下、それぞれ ET、MT、ST と略することにして、ポートフォリオの例を挙げます。持ち時間は（ランチタイムを除いた）7 時間とします。

| Engineering | Management | Spreading | 印象 |
| --- | --- | --- | --- |
| 2 | 5 | 0 | よくあります。エンジニアが悲鳴を上げます |
| 6 | 1 | 0 | 少人数だと機能しますが、大体マネージャーが悲鳴を上げます |
| 4 | 2 | 1 | エンジニアリング優先で、悪くないと思います |
| 3 | 3 | 1 | コミュニケーションを重視する組織だと思います |
| 2 | 2 | 3 | 見たことがありません。どんな組織でしょうかね？ |

ポートフォリオに正解はありません。また、会社が推奨するポートフォリオとチーム内の標準的なポートフォリオが同じとも限りません。そのチーム、そのプロジェクト、その組織に合ったポートフォリオを動的に調整することが重要です。

### 役割と過ごし方の早見表
最後に早見表を置いておきます。

|  | Engineer | Manager | Spreader |
| --- | --- | --- | --- | 
| ET | Engineering | Management or Engineering | Spread or Engineering |
| MT | Management  | Management | Spread or Management |
| ST | Spread      | Spread | Spread |

エンジニアはわかりやすいですね、その時間帯のとおりに過ごしてください。

マネージャーは、エンジニアリングタイムのときはエンジニアリングをしてもいいですし、マネジメント（つまりは引き続き誰かとの会話）に充てても構いません。

スプレッダーは、基本的にその時間帯のとおりに過ごせばいいですが、スプレッディングをしてもいいです。

なお、これも目安であり、組織次第で変えて良いです。ただしポートフォリオとは違って、動的に変えると混乱してしまうので、静的に決めてください。一度決めたら、少なくとも数カ月以上は変えずに運用してください。

## おわりに
エンジニア、マネージャーに続く第三の役割としてスプレッダーを定義しました。また時間の使い方という観点から三つの違いを比較しました。

現代は難しい時代です。そもそも私達は人間であり、いくら技術が進歩したところで、組織のあり方など原始的なのです。なのにエンジニアとマネージャーの二つしかなかったわけですから、融通が利きませんでした。スプレッダーという第三の役割で、この膠着を打破できることを祈っています。

ではまた。

---

# エンジニアリングと DEI

## 背景

### DEI を毛嫌いする理由もわかりますが……
皆さんが DEI を毛嫌いする理由もわかります。一部の過激なマイノリティが暴れているせいです。米国の DEI 廃止は記憶に新しく、心の中で賞賛したエンジニアも少なくないかもしれません。実際にテック企業はウェブサイトから DEI の表記を削除したりもしています。

### しかし DEI は重要です
ナレッジ・アーキテクトの立場から言わせてもらうと、DEI は実はエンジニアの皆さんにとっても重要です。

一部マイノリティの暴走を受け入れろという話ではありません。もっと根本的かつ先進的な話題なのです。皆さんの身を守ることにもつながりますし、特にエンジニアリングマネージャーやスタッフエンジニアのようにチームや組織の視座に立つ者にとっても参考になります。というより前提となります。

現代は VUCA ですし、私達の生活水準とリテラシーも上がっています。この難しい時代に対抗するためには、面倒でしょうが DEI の視座が必要なのです。

### DEI を考慮できない組織の弊害
以下が起こります。

- 人材不足になる
    - これは単純で、組織に合う人材と出会えるまで採用やマッチングを続ける羽目になるからです。好き嫌いが激しいとも言えます。そしてそれをカルチャーマッチングなどといった言葉で正当化します。まるで食わず嫌いの多い子供のようです
- 静かな退職が発生する
    - 組織に合わない人材は、解雇されないために表面上は取り繕います。取り繕っているので気づきづらいですが、思っているほどパフォーマンスが出ません。それは静かに退職しているからです。合わないので当たり前です
- エンジニアリングとプライベートに時間を使えない
    - DEI が無い集団とは、「単一のあり方」に支配された宗教集団のようなものです。集団に隷属するためのコミュニケーションコストを相当支払うことになりますし、他のあり方ができないので変化にも弱いです。無論、個人の目線では転職すれば済みますが、転職もそれなりに大変です

## DEI とは
エンジニアにもわかりやすいように、本質的な解説をしたいと思います。

### 多様性とは
**多様性（Diversity）** とは、複数のあり方が共存している様を指します。

働き方を例にしましょう。

全員が同じ時間帯に勤務し、出社し、ミーティングやワークの形で時間の使い方さえも拘束されるとします。これは多様性が無い状態です。

逆に、以下の 3 つのあり方がすべて共存している場合、

- 1: 朝型の勤務時間、毎日出社、一日の半分以上はミーティング
- 2: 夜型の勤務時間、ハイブリッドワーク、一日の半分未満がミーティング
- 3: 勤務時間は不定、フルリモート、ミーティングは一日一件あるかどうか

これは多様性があると言えます。働き方に関して **多様性のレベルが 3 である** と表現します。3 つのあり方が共存できているからです。

ここで共存とは、以下二点を **どちらも** 満たします。

- 1: 基本的に自身のあり方（ここでは働き方）が犯されないこと
- 2: 上位役職者においても、それぞれのあり方（働き方）がバランス良く配分されていること。また少なくともすべてのあり方が許容されること

ですので、プロジェクトやチームのレベルでは多様的であっても、管理職や経営層のレベルでは多様的でないこともよくあります。見極めは単純で、ある集団の顔ぶれを見ればいいだけです。**実際に共存できているかどうかがすべてです**。共存の光景が見られない時点で、多様性がないのです。

### 公平性とは
**公平性（Equity）** とは、全員を一律的な水準に引き下げる様を指します。

対象は色々ありますが、いくつか挙げましょう:

- 給料
- 十分なスペックの PC
- 生成 AI サービス（チャットおよび API）へのアクセス
- キャリアやメンタルヘルスやファイナンスといったアドバイザーへのアクセス
- 自律的にリモートワークをこなせるだけのリテラシー（を鍛えるための機会へのアクセス）

全従業員に対して、最低限の保障をします。**平等とは全く違うことに注意してください**。給料を例にすると、全員の給料を平準化すると言っているのではなく、最低ラインを定めた上でその額は必ず保障すると言っています。

たとえば日本では「年功序列」という文化があって、若手は（著しくパフォーマンスを上げたとしても）中堅の 35 %、シニアの 20% の給料しかありません。これでは生活が苦しく、大手企業であっても若手は残業により生活費を稼がねばならない事態となっています。当然ながら、これでは生活の質も悪いですし、自己投資もできません。これを公平性の観点で是正すると、生活に困らない程度の給与ラインを定めた上で、全社員にそれを支給します。2000 ドル足りない人は +2000 しますし、300 ドル足りない人は +300 です。**すでに足りている人は 1 ドルも足しません**。

### 包括性とは
**包括性（Inclusion）** とは、あらゆるあり方を受け付けることです。

仮に「全員を受け付けるために 11 種類の受け口が必要だ」としたら、11 種類を全部用意します。1 種類だけ用意してこれに合わせてね、ではなく、全員が機会を享受できるように、11 種類全部用意するのです。

またもや日本の例ですみませんが、**申請主義** という現象があります。何らかの支援を受けたり制度を使ったりするためには、自ら自主的に申請しなければなりませんが、これは **申請先の存在を知り、かつ申請作業を行える能力を持つ人のみ** の特権です。そうではない者がこぼれ落ちているのです。これを包括性の観点でとらえると、そのような脱落者に対して、よりきめ細かいフォローやサポートを複数種類用意する等になるでしょう。

私達エンジニアにもわかりやすい例も挙げましょう。あるマネージャーに申請やレビューを依頼する状況を考えてください。その人は対面の会議しか受け付けないとします。また、恒常的に忙しいため、上手く空きを調整しなければなりません。さて、これは包括的でしょうか。

言うまでもなく「いいえ」です。これでは対面会議が行える者にしか開かれていませんし、空きを調整するとなると事実上政治的な立ち回りが必要でしょう。たとえば有能で、礼儀礼節にも優れているが、テキストコミュニケーションしかできないエンジニアはどう扱われるでしょうか。おそらくまともに相手にされないはずです。このエンジニアは相手にされず、評価もされず、おそらく解雇されるでしょう。

これを包括性の観点で捉えると、**マネージャーが** 対面会議以外の受け口も用意するべきです。たとえばテキストコミュニケーションで完結する手段を用意します。用意できて、かつ機能できて初めて包括性があると言えます。

この場合、包括性のレベルは 2 です。2 通りの口があるのでレベル 2 です。包括性とはレベル 2 以上であることを指します。もちろんレベルは多い方が良い。

## DEI を実現するためには
結論を言うと、エンジニアリングが必要です。

レベルという言葉が登場しましたが、**レベル** とは DEI の度合いを示します。多様性に関しては「あり方が何個共存できているか」、公平性については「保障された水準がいくつ存在するか」、包括性については「受け口が何個あるか」がレベルになります。

**レベルは勝手には上がりません。レベルを上げるためには、具体的な概念と道具が必要です**。それをつくれるのはエンジニアだけです。主にソフトウェアやシステムといった道具を思い浮かべるかもしれませんが、[ナレジニア](https://dev.to/stakiran/what-is-knowledging-2229)のように概念をつくることもできます。

これを **DEI の実装** と呼びます。たとえば多様性のレベルを 1 つ上げるために、何かをつくることは多様性の実装と言えます。エンジニアリングの範疇です。要件を調べて、言語化して、設計して、ソフトウェアや概念に落とし込んで、それを使ってもらって検証していくわけです。

## エンジニアだからこそ DEI が可能となる
DEI を声高に叫んでいる人の大半は、全く生産性がありません。「マイノリティの私を受け入れてよ！」の一言しか言っていないからです。それはそれで大事ですが、ビジネスとしては致命的です。具体的な議論や進展が全くないのです。

だからこそのエンジニアリングです。多様性にせよ、公平性にせよ、包括性にせよ、レベルを上げるためには一体どんな道具や概念が必要なのかを考え、つくって、試すのです。このようなことが行えるのはエンジニアだけです。

## おわりに
私はエンジニアだからこそ DEI を意識してほしいと思います。そして実装していってほしいと思います。

私達は所詮人間であり、人間である以上、あり方には限度があります。単一のあり方に無理やり合わせるのには、もうウンザリしませんか？この長年の問題を解決できるのは、私達エンジニアだけなのです。

---

# 生産性よりも体験性

## 背景
長らく生産性は測定対象として扱われてきました。コードの行数、PR やレビューの回数、バグの密度、カバレッジ率――。断言してもいいですが、生産性を測るのは不毛です。

理由は単純で、プロジェクトという生き物が本質的に複雑だからです。また人間が本質的に怠惰で、自分本位で、かつ解釈にブレのある曖昧な生き物だからです。

## 体験性
**体験性（Experiencity）** とは、快適に働ける度合いを指します。

似た概念として開発者体験や [Engineering Effectiveness](https://ee-handbook.io/getting-started/what-is/)があります。もっとわかりやすいフレーズをいくつか並べましょう:

- 集中できる
- 割り込みがない
- 思考がブロックされない
- ノイズがない
- 自分に合った働き方と道具が使える
- 創造的である
- 難しすぎず、かんたんすぎない
- 退屈でないが、忙しすぎない
- 無知なマネージャーやブリリアントジャークといった「邪魔者」がいない
- ビジネスや営業の仕事を丸投げされない

エンジニアやクリエイターの皆さんは、この感覚はすでに知っているはずです。私達の直感はやはり正しかった。重要なのは管理でもなければ、チームの歯車となることでもありません。快適であることです。

体験性では、**快適であれば自ずとベストなパフォーマンスが出るものだと考えます**。これを **体験性の原則** と呼びます。この原則があらゆる状況で常に当てはまるとは限りませんが、現代のプロジェクトであればおおよそ当てはまるか、当てはめることができます。

## 体験性の実装
体験性を実際に運用するには、個人なりに、または組織なりに指標を定義せねばなりません。

### まずは EE を参考にする
すでに述べた Engineering Effectiveness はわかりやすいです。thoughtworks 社が提唱した概念であり、出力ではなく入力を測れ、と謳っています。以下、比較を引用します。

|Measure ... (INPUT METRIC)|Don't measure ... (OUTPUT METRIC)|
|--|--|
|The time it takes to do code reviews|The throughput of pull requests|
|The amount of interruptions affecting engineers|How many hours engineers have been working|
|The amount of unplanned work affecting a sprint|Sprint points burned by the team|

これはまさに体験的です。「エンジニアリングの仕事に集中できる」という体験を尊重し、その集中の最大化を良しとしています。そして、これを維持するために、集中を削ぐ要因をモニタリングしています。

私が知る限り、体験性をちゃんとつくった例は EE だけです。ですので、まずは EE を使ってみることをおすすめします。自組織なりの体験性をつくるのは、その後でもいいでしょう。

### 開発者体験の定義を追いかけることも参考になる
「開発者体験とは何か」と聞かれたら、あなたはどう答えますか？

正解はありません。軽く Deep Research してみるだけでも、様々な組織が様々な定義を使っています。私の方で軽く整理すると、開発者体験の捉え方にはざっくり三つの派閥があります。

- 1: 実感派
    - 自分の仕事にはちゃんと意義があること、価値につながっていることの実感
    - Microsoft や Atlassian、日本で言えば日本CTO協会など、典型的な組織は「ビジネス上の価値」に繋げるために実感派になりがちです
- 2: UX 派
    - 開発者が普段触れる道具と環境の UX
    - 近年、この観点は特に重要になってきました。Platform Engineering などがそうですよね
- 3: ストレスフリーの度合い派
    - 開発者自身が感じる、仕事のやりやすさを阻む要因の少なさ。ストレスの無さ

つまり、開発者体験という軸で体験性を実装する場合、この三つの派閥の見方について、それぞれをどの程度取り入れるかを考えることになります。

正解はありません。Platform Engineering は「UX 派」にフルコミットしていますし、現代のエンジニアリング組織やビジョンやチームワークといった点を重視していて「実感派」を重視する傾向にあります。

私個人は「ストレスフリーの度合い」が一番重要だと思っており、[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として体験性の実装に携わる際は、各人のストレスフリーの最大化を目指します。たとえば役割分担や多様性といった考え方を使ったり、[ティール組織](https://dev.to/stakiran/full-async-4hem)の概念を取り入れたりします。

## おわりに
生産性に代わる概念として体験性を紹介しました。生産性の管理や向上に悩まれている方は、ぜひ参考にしてみてください。それではまた。

---

# Full-Four ～フルリモート、フルフレックス、フルアシンク、フルマスク～

## 背景

### 出社回帰のせいで人材が不足する
パンデミックが落ち着いた後、出社回帰が再燃しています。対面によるコラボレーションは生産性が高く、満足度も高いと言われますが、私は懐疑的です。集合と拘束は搾取的であり、これで高い成果を出せるのは当たり前です。

一方、現代は生活水準が上がっています。技術も方法も概念も発展しているのですから当然です。エンジニアの皆さんは嫌いかもしれませんし、米国ではトランプ大統領が撤回もしましたが、DEIB の概念もあります。出社回帰による高密度なコラボレーションは、（Belonging はともかく）DEI のかけらもありません。なぜなら私達は人間であり、人間の生活様式は人それぞれだからです。**出社や対面といった単一的な過ごし方ではカバーしきれず、カバーされないすべての人を取りこぼすことになります**。あるいは静かな退職といった形で「やり過ごされる」形になります。

IT も含めて人材不足といわれます。というより、昔からいつも言われ続けているように感じます。理由は単純で、過ごし方が単一的であるがゆえに多様性がなく、こぼれる者が多いからです。**過ごし方を拡張せねばなりません**。

### 過ごし方を拡張する 4 つの視点
過ごし方の言語化とカスタマイズは、まさに[ナレジャー](https://dev.to/stakiran/what-is-knowledging-2229)が得意とする領域です。私もナレッジ・アーキテクトとして、小さなチームから大きな会社まで、様々な組織の過ごし方をデザインしてきました。

今回は、どの組織にも通用する「汎用的な視点」を 4 点に整理して紹介します。

- **フルリモート（Full Remote）**
    - 常にリモートワークを行います。出社（あるいは出張）は無いか稀ですし、少なくとも定期性はありません
- **フルフレックス（Full Flex）**
    - コアタイムがなく、従業員は好きな時間帯に勤務できます。
- **フルアシンク（Full Async）**
    - 常に非同期コミュニケーションを行います。対面またはリモートのミーティングは無いか稀です。
- **フルマスク（Full Mask）**
    - まず **プレーン・アイデンティティ（Plain Identity）** とは自身の本名、容姿、性別を指します
    - 私達はなぜかプレーン・アイデンティティを使わされますが、フルマスクではその必要はありません。プレーン・アイデンティティは隠せますし、ダミーのアイデンティティも使えます

いずれもフルの形容詞がついています。デフォルトと言い換えても構いません。基本的に常に適用するという意味です。たとえばフルリモートは、ハイブリッドワークのような中途半端な塩梅ではなく、全面的にリモートに寄せています。例外的な出社や出張はありえますが、それでも例外的です。安易にハイブリッドなどと名付けて逃げたりはしません。だからこそ、見えてくるものがあります。過ごし方を拡張するには、原始的なあり方から徹底的に逃れないといけないのです。

では、各々の詳細を見ていきましょう。

## 長くなるので記事を分けました

### 👉[フルリモート](https://dev.to/stakiran/full-remote-57k0)

### 👉[フルフレックス](https://dev.to/stakiran/full-flex-1kfn)

### 👉[フルアシンク](https://dev.to/stakiran/full-async-4hem)

### 👉[フルマスク](https://dev.to/stakiran/full-mask-ek8)

---

# フルアシンク

## 概要
**フルアシンク（Full Async）** とは、全面的に非同期コミュニケーションを行う働き方を察します。

ミーティングは対面・リモートを問わずありません。事前調整すれば可能ですが、頻度で言えば月に一回未満ですし、月一でもまだ多いです。年に一回もミーティングをしなかったとしても珍しくはありません。なおこれは社内の話であって、社外には適用されません。したがって社外向けの同期コミュニケーションを多数行う者は生じえます。しかし、少なくとも社内では非同期的です。

通知の解釈は自由です。メンションなどの形で通知を飛ばすことは自由ですが、受け手に即座に反応する義務はありません。即座の反応を強要することはハラスメントとなります。

## 概念
フルアシンクの構成要素を整理します。

- 1: 3T（Talk、Topic、Task）
- 2: 脱関係（De-Relation）
- 3: ティール組織

難しい議論になりますが、一つずつ解説していきます。

### 1: 3T（Talk、Topic、Task）
**3T（Talk、Topic、Task）** とは、コミュニケーションの捉え方を Talk、Topic、Task の三段階で捉える考え方です。

従来のコミュニケーションは「正解が各自の頭の中にある」「それを会話によってすり合わせる」ものですが、これは同期的なあり方でありフルアシンクでは採用しません。かわりに、すべてのやり取りの単位を 3T で捉えます。

ランチタイム中に雑談を行ったときを考えます。従来ではただの雑談であり、どう解釈・処理したかも各人次第です。一方、3T で捉えると、この雑談は n のやりとりから成ると捉えます。やりとり一つ分を **COIN（Cluster Of INformation）** と呼びます。コミュニケーションは COIN の単位で構成されると考えます。ですので、たとえば次のような構造になります:

- ランチタイム中の雑談
    - COIN-1（Talk）
    - COIN-2（Talk）
    - COIN-3（Topic）
    - COIN-4（Task）
    - ...

次に 3T について見ていきましょう。

Talk は発散的かつ無目的な段階であり、単に情報が集まっている段階です。雑談もここに含まれます。

Topic は「お題」が定まった段階です。「お題」に関する情報のみを集めます。「お題」とは関係のない話題は、別の COIN に移します。必要ならリンクを張ることで関連を示すこともできます。

Task は「やると決めたこと」が定まった段階です。といってもタスク管理ツールほど厳格な管理はしません（それはタスク管理ツールまたはプロジェクト管理の中でやるべきです）。開始・終了・中止といった状態、意思決定を行う担当者、期限やスケジュールやモチベーションといった進捗情報を軽く扱う程度です。

つまりフルアシンクでは、私達はたくさんの COIN をつくることになります。COIN をつくったり、既存の COIN を読んだり、もちろん書き足したり、その中で議論したりもします。COIN は流動的で、最初は Talk から始まりますが、Topic や Task に移していきます。

もちろん、COIN の数はそれなりになります。5 人から成るフルタイムのプロジェクトにおいて、1ヶ月間フルアシンクを行った場合、雑談も含めると COIN の数は軽く数百は超えます。千くらいはかんたんに届きますし、慣れた組織なら万に届くかもしれません。

### 2: 脱関係（De-Relation）
**脱関係（De-Relation）** とは、人と人の関係を深めるという営みそのものを想定しないあり方を指します。

ここで脱関係を示す、象徴的な台詞を紹介します。

> 誰が言ったかではなく、何が書かれているかを見よ。

そもそも同期コミュニケーションが廃れないのは、私達が関係の営みを大切にしているからです。関係性をつくり、深めることは人間の原始的な欲求ですし、認知的にも関係のある人物を相手にした方が節約できます。しかしこれは、関係をつくるためのコミュニケーションにそれなりに時間をかけなねばならないという弱点も抱えます。また、関係のある人物ばかりえこひいきしてしまい、政治につながります。プライベートではともかく、仕事としては賢いとは言えません。

そこでフルアシンクでは、この **関係という営みそのものを手放します**。「誰」でフィルタリングするのではなく、「何」を見て、その「何」が問題ないのなら利用するべきです。もちろん、フルアシンクでは同期的な会話はしませんから、「何」は言われるものではなく書かれるものです。書かれたものを読む営みになります。

この脱関係という概念はわかりづらいかもしれませんが、エンジニアの皆さんであれば比較的理解しやすいと思います。生成 AI を思い浮かべてください。「誰」という観点では向き合わないですよね。生成 AI が「何」を出力しているかを見て、必要なところを使っていると思います。同じです。その考え方を、対人間に対しても適用します。冷たく思えるかもしれませんが、 **非同期前提にするためには、そのネックとなっている「関係の営み」をなくすしかないのです**。

ここで以下の疑問をよく投げられます。

「では、関係を満たしたいという私のこの欲求は、一体どこで満たせばいいのだ？」

答えましょう。**プライベートで満たしてください**。

辛辣に言えば、公私混同をするなということです。極端な話をすると、性欲を満たしたいからといって仕事で満たそうとは思いませんよね。ハラスメントです。同じことです。原始的な欲求を Bindful（相手の拘束を伴う）に満たすのは良いとして、それを仕事でやるのがそもそもおかしいのです。私達は獣ではありません。人間です。人間は理性的なはずです。さらに厳しいことを言いますが、仕事において関係性を求めて満たそうとする人達は、仕事で性欲を満たそうとする猿と同じようなものです。

### 3: ティール組織
**ティール組織** とは、フレデリック・ラルーが提唱する組織パラダイムです。

この概念の詳細は割愛しますが、私達が今現在「組織」と聞いて思い浮かべるのは十中八九、階層的な組織です。これは同理論ではオレンジ組織と呼ばれます。犯罪組織（レッド組織）や宗教団体（アンバー組織）ほどひどくはありませんが、階層性というボトルネックは変わらず抱えています。皆さんの会社もそうですよね。上司がいて、部下がいて、自分の所属があって越権はしづらいはずです。上に行くための競争に明け暮れている組織も少なくないでしょう。

**オレンジ組織では、フルアシンクはできません**。オレンジ組織は時間の使い方が不平等な世界であり、階級の高い者の 10 分のために、階級の低い者が 1000 分を費やさねばなりません。また、階級の高い者は、そのような「短時間の意思決定」に慣れており、頭を使わない条件反射装置（Reactive Machine）と化しているから、できることが相当限られます。当然ながら非同期コミュニケーションなんてしませんし、できません。皆さんの組織、または周囲の、役職の高い人を浮かべてみてください。フルアシンクを行えると思いますか？フルアシンクを阻む根源は組織パラダイム、特に階層的な組織という構造そのものにあるのです。

では、階層的な組織のかわりに、一体どのような組織構造を使えばいいでしょうか？

その答えは実はまだ安定していませんが、現時点で確度が高いのがティール組織なのです。**ティール組織は一言で言えばネットワーク型組織** です。私は 3P として整理しています。

- パーティー（Party）
    - 一人～十数人の小集団。特定の仕事を行える程度に完結している
    - 社員は単一または複数のパーティーに所属して仕事する。所属は動的
- プロトコル（Protocol）
    - パーティー全体のガバナンスを効かせるための憲法や法律
    - 文書し、かつ社外に公開できねばなりません
- 平和（Peace）
    - 資本主義的な利益の追求を第一目標にしてはいけません
    - 真に平和的なミッションを抱え、そのために本気になります。利益はその結果としてもたらされます

パーティーはノードのようなものだと思ってください。会社とはノードから成るネットワーク構造です。ただし、これだけでは全体最適が効かないので、プロトコルで制御します。もちろん（従来の用語でいう）CxO のようなチーフ役やリード役もいます。もう一つ、資本主義的なお金儲けが第一だと、今のように階層的かつ搾取的になってしまうので、Peace の形でそうではないと掲げる必要もあります。

### まとめ
フルアシンクを実現するためには、従来の同期コミュニケーションを、その根本原因を取り除いた「新しいモデル」を採用せねばなりません。具体的には以下三点を紹介しました。

- コミュニケーションを、COIN（やりとりの単位）を介して行うものと捉えること
- 関係を満たすという営みそのものをやめること
- 階層的な組織から脱して、ネットワーク型の組織を採用すること

いずれも 2025 年時点では、確たる成功例はありません。つまりフルアシンクは先進的な概念なのです。私は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として、リタイアするまでにこの世界観をつくりあげたいと考えています。

## メリット
フルアシンクのメリットは次のとおりです。

ミーティング、関係構築の営み、階層的組織といった従来パラダイムのボトルネックが解消されるため、変革と適材適所が起きやすくなる。その結果、**従業員ファーストで多様性の強い組織でありながら、持続的に事業を継続できるようになること**。

## デメリット
フルアシンクのデメリットは **理解も定着もされづらい** ことです。

フルアシンクは、端的にたとえるなら聴覚障害者になるようなものです。

その前提で普段どおり仕事をこなすようなものです。多様性のある会社に勤める読者であれば、聴覚障害者と働いたことはあるかと思いますが、おそらく普段のパフォーマンスは出せなかったはずです。単純な話、聴覚障害者側に寄り添って、一切会話することなく全面的に非同期で完結すれば済むだけですが、それさえもできなかったはずです。なぜかというと、単純に難しいからですね。そもそもエキスパートであるはずの聴覚障害者側でさえ、非同期的に仕事を行うスキルを持っていなかったりします。

大胆に言えば、非同期という働き方を人類はまだ開拓できていません。この時点でいかに理解が難しいかがおわかりいただけるかと思います。本記事でもわかりやすく解説してきましたが、それでも COIN、脱関係、ティール組織と難解な概念が続いてしまいました……。

ハードルはここだけではありません。仮に理解ができて、組織としてフルアシンクを実現できたとしても、その維持が大変なのです。なぜかというと、反対勢力が手強いからです。

フルアシンクでは、以下の反対勢力が生じます。

- 非同期ではこなせない仕事を担う者。これを **Syncer** と呼びます。Syncer はその仕事の部分は同期的に働きますが、それ以外はフルアシンクが必須です。しかし、同期的な仕事をしているせいで感性も同期派に傾いてしまい、フルアシンクを緩和または撤廃する運動に傾注しがちです
- 関係欲求をプライベートで満たせない者。これを **Beast** と呼びます。Beast に脱関係について納得してもらうことは、男尊女卑社会における男性に対して男女平等を説いて納得してもらうようなものです。マイノリティな方はよくわかると思いますが、これは非常に高くて厚いハードルです

この二大勢力を放っておくと、フルアシンクは維持できません。次の組織再編で一掃されてしまうでしょう。

## 実装
フルアシンクを実装するには、概念の項で挙げた COIN と 3T、脱関係、ティール組織のすべてを実装できればいいのです。本記事の残りでは、実装に必要な手段を紹介します。

- 複数のコミュニケーションツール、たとえば [QWINCS](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb)
- バーチャルオフィス、特に[軽量で Daily Park を実現できるもの](https://dev.to/stakiran/notes-and-boards-as-virtual-offices-a-lightweight-approach-59n4)
- タスク管理
- SSoT なドキュメント

順にかんたんに見ていきましょう。

### 複数のコミュニケーションツール、たとえば QWINCS
フルアシンクでは非同期コミュニケーションを行いますが、これには専用のツールが必要です。チャットだけでは足りません。以前 QWINCS の記事を書きましたが、チャット（Chat）以外にも Q&A、Wiki、Issues（Ticket）、Note、Sticky boards（デジタルホワイトボード）があります。

全従業員がこれらを使いこなせねばなりません。つまりは **全社的に導入して、全社員が無許可で自由に使える必要があります**。たとえば Issues で言えば、全社員が読み書きできる Issue スペース（GitHub の場合はリポジトリ）があって、誰でも自由に議論や投票ができるくらいは当然です。

余談ですが、このような考え方は [Plurality](https://github.com/pluralitybook/plurality) として開拓されつつあります。

### バーチャルオフィス、特に軽量で Daily Park を実現できるもの
フルアシンクでは物理的に集まれませんが、皆の注意を惹きつける仕掛けは何かしら必要です。バーチャルオフィスで代替できます。特に以前ご紹介した **軽量バーチャルオフィス（Light-weight Virtual Office）** を使って、日単位のワークスペースをつくって、皆がそこに集まって各々書いていけばいいのです。自然と集まる場になりますし、皆に周知したいことや相談したいことも、単にそこに書くだけで非同期的に進めていけます。

### タスク管理
フルアシンクにおける最重要事項です。フルアシンクをするということは、各自のタスクは各自で管理することを意味します。

たとえばあなたが 30 のタスクを持っているとします。Must なものもあれば、Should や Want なものもあります。これらのすべてを支障無く、かつバランス良く進めることはできますか？おそらく 98% の人が「いいえ」だと思います。エンジニアであっても、です。

なぜかというと、30 ものタスクを管理しつつ、自分の状況（Context）と調子（Condition）も踏まえながら、持続的に行動していくことなど不可能だからです。これを可能にするのがタスク管理なのですが、この分野はまともに体系化もされていなければ啓蒙もされていません。実際、私が体系化しなければなりませんでした。

- 日本語版: [タスク管理を噛み砕く](https://zenn.dev/sta/books/taskmanagement-kamikudaku)
- 英語版: [Breaking Down Task Management](https://zenn.dev/sta/books/tasukami-english)

しかしながら、私の見解としては「道具化が必須だろう」です。いくらタスク管理の体系を理解したところで、行動に移せねば意味がありません。私がナレッジ・アーキテクトとして、またタスク管理の専門家として多くの人間を見てきた上での印象を述べると、基本的に現代人にはタスク管理の才能がありません。ソフトスキルで食べているビジネスマンでさえも、です。ですので、タスク管理を支援するソフトウェアの開発が急務だと考えています。

### SSoT なドキュメント
ティール組織の肝は 3P であり、そのうちの一つに Protocol があると述べました。Protocol とは組織の憲法や法律やルールを文書化したもので、社外にオープンに公開するものです。オープンにできるほど開放的でなくてはならないということですね。端的な例は [The GitLab Handbook](https://handbook.gitlab.com/) や [Holacracy Constitution v5.0](https://www.holacracy.org/constitution/5-0/) です。

これに限らず、フルアシンクでは「これこれの場合はこのドキュメントに頼れ」を徹底します。原典を「各自の頭の中」や「偉い人の頭の中」ではなく、外に出された「ドキュメント」にするのです。これを信頼できる唯一の情報源と呼びます。

SSoT はエンジニアリングにおけるデータソース全般に対して使う言葉ですが、フルアシンクではドキュメントに対して使います。**ドキュメントは常に SSoT にする**、くらいに考えてください。ここまで徹底して SSoT 化することにより、私達はドキュメント駆動的に働けるようになり、フルアシンクも実現できます。

## おわりに
非同期コミュニケーションのみで仕事を行う、組織を成立させるというフルアシンクについてご紹介しました。現代でもまだ開拓されていない先進的な概念であり、その道のりも難解です。

だからこそ、実現できたときの効果も計り知れません。ミーティング、関係構築、階層的な組織といったパラダイムから脱せた世界を想像してみてください。決して妄想ではなく、現実的に手が届きうる世界なのです。届きうるということを、この記事で示せたと思います。

もし本気で実現したい方がいらっしゃれば、ぜひ私を頼ってください。雇ってください。[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229) として力添えいたします。それではまた。

---

# フルフレックス

## 概要
**フルフレックス（Full Flex）** とは、特定の勤務時間帯を設けず、いつ働いても良いとする働き方です。

コアタイムはありません。また **事実上のコアタイム（de facto core time）** もありません。フレックスを謳っていながらも、事実上チームやプロジェクトにコアタイムが存在するケースは非常に多いですが、そのようなあり方は詐欺であり、フルフレックスとは言えません。

フルフレックスには所定労働時間の義務もありません。非常に多くの企業では導入していますが、本来そのような法的制約は無いのです。たとえば日本では月 150 時間以上の所定労働時間を課すことが多いですが、日本の労働基準法にそのような制約はありません。

## 概念
フルフレックスの構成要素を整理します。

- 1: 一時的なコアタイム
- 2: 計測可能な成果主義
- 3: 省力化された打刻

### 1: 一時的なコアタイム
一つ目は **一時的なコアタイム** です。

フルフレックスにコアタイムはありませんが、かといって「一緒に過ごす時間」が全く無いのはさすがに不便です。必要に応じて設けることは許します。これはコアタイムを一時的につくると解釈できます。会議の調整と同様、事前にコアタイムを調整することで確保します。

よくあるアンチパターンが **定例イベント化** です。フルフレックスが上手く行っていることの目安は **定例イベントが一切無いこと** です。わかりやすいですね。定期的なミーティングがある時点で、あなたのそれはフルフレックスではありません。フルフレックスは、各自が各自に合った時間帯で働くことができるというものであり、定例イベントはこの原則を壊します。アジャイルにおける朝会や、週に一度の定例会議や勉強会などは典型例です。ここで、

「自由参加制にすればいいのでは？」

と思われるかもしれませんが、いけません。定例イベントはそれ自体は Must または Should なものであり、そんなイベントに対して自由参加を導入すると、参加しない側がネガティブに扱われます。これは情報格差を生み、情報格差は政治を生みます。

### 2: 計測可能な成果主義
二つ目は **計測可能な成果主義** です。

そもそも従業員に特定の勤務時間を課したりコアタイムを設けたりするのは、会社が従業員を信用していないからです。出社回帰もそうですが、会社は従業員という「本質的な怠惰な人間」を出来るだけ働かせるために、物理的に同じ場所と時間に拘束して相互監視させます。経営者目線ですと気持ちはわかるのですが、これは前時代的な搾取のあり方であり、抗わねばなりません。そうは言っても、拘束を解除するとサボタージュが大量発生します。どうすればいいでしょうか。

成果で測ればいいのです。日本の皆さんはともかく、英語圏の皆さんはすでに成果主義が当たり前かと思いますが、まだ足りません。サボタージュを防ぐための、相互監視的な意味合いを持つ仕組みが必要です。それが計測可能な成果主義です。

といっても単純な話で、普段のコミュニケーションを **アウトプットベースで行う** だけです。記録が残らない会話や、二者にしか見えない Slack や Teams のダイレクトメッセージではなく、チーム全員に見える場所でテキストコミュニケーションをします。または会議の場合は、必ず録画を残します。**必ず** です。

こうすると、普段のコミュニケーションは「アウトプットした何か」を介する形になります。つまり普段からちゃんと仕事をしている（仕事のためのコミュニケーションをしている）様子が残るようになるのです。これを計測することでサボタージュを防げます。勤務時間なんてどうでもいいんですよ。重要なのは、各自頭と手を動かして具体的な意見や結果――つまりはアウトプットを出せていることです。ならば、アウトプットを見れば良い。

この考え方は一見するとディストピアに見えるかもしれませんが、むしろ逆です。勤務時間やコアタイムで縛る方がディストピアです。計測可能な成果主義を導入すると、私たちは自分にとって過ごしやすい時間帯で働けるようになります。アウトプットを出さないといけないのは、仕事だから当然です。その手段が変わるだけです。時間で縛るディストピアから、各自の自律的な努力に任せるユートピアへと。

最後に、計測可能な成果主義における最重要事項を述べておきましょう。アウトプットを必ず残してもらうことです。**必ず** です。大事なので二回強調しました。私がナレッジ・アーキテクトとしてフルフレックスを設計するときは、（人事その他個人的なやり取りを除いて）プライベートでやり取りする者にはペナルティを与えます。**アウトプットを出さないことは、遅刻と同じくらいの罪として扱います**。

### 3: 省力化された打刻
三つ目が **省力化された打刻** です。

これは労務の事情によるもので、従業員は通常労働時間を管理せねばならず、管理には定量的な記録が要求されます。日本に限らず、どの国でも法律として定まっていると思います。個人事業主や少人数のベンチャー企業でもなければ、労務管理の理からは逃れられないはずです。ですので、 **フルフレックスであっても定量的な労働時間管理が必要** なのです。

もちろん、だからといってこの作業にコストをかけるのは愚かなことです。ですから省力化と名付けています。自動化ではなく **省力化** です。完全に自動化するのが一見すると望ましいですが、自動化と監視は表裏一体です。

一つ問いたいですが、あなたは勤怠管理が自動化されるからといって、自分の PC にエージェントツールをインストールしたいでしょうか？経営者や情シスの人は「はい」と答えるかもしれませんが、厳格な監視が生産性やエンゲージメントを高めることはありません。なぜなら恐怖政治にすぎないからです。

ですので、恐怖政治につながる自動化は避けて、省力化にします。私の感覚ですと、デジタルツールで出勤と退勤を打刻してもらうのが良いバランスだと思います。API やコマンドラインツールもサポートすれば、慣れたエンジニアは勝手に自動化します。打刻のインターフェースは究極的にシンプルにしてください。`start_work()` と `end_work()` の二つで足りるはずです。

打刻ツールのシームレスな呼び出しは、実はブルーオーシャンでもあります。たとえば打刻用の小さなボタンを製品として販売できたら、このジャンルで覇権を取れるでしょう。

## メリット
フルフレックスのメリットは次のとおりです。

- 自分に合った生活リズムで仕事ができるようになり、パフォーマンス向上はもちろん、「頭を使う仕事」ができるようになること
- 日頃からアウトプット・ベースド・コミュニケーションが行われるため、情報格差が減り、社内政治も減らせること
- コアタイムを都度調整するため、本当に必要なイベント（時間や場所を拘束する機会）を設計できるようになること。これにより無駄なイベント、特に会議を減らせてワークライフバランスを増やせること

政治を減らせることも大きいですが、一番大きいのは **頭を使う仕事ができるようになること** だと考えます。

私は **スラック（Slack）** と呼んでいますが、ただただがむしゃらに受身に仕事をするのではなく、変革的に前提を疑いつつ、創造性も発揮した「本質的に良い仕事」をするためには、物理的な余裕が必要です。時間も、精神も、体力も、認知資源もです。そして **スラックは自分の生活リズムに合わない過ごし方に合わせることでゴリゴリと削られます**。フルフレックスの最大のメリットは、この浪費を抑えられることなのです。

## デメリット
フルフレックスのデメリットは、従業員に自律性が要求されることです。

私は **雰囲気リマインド（Atmosphere Remind）** と呼んでいますが、同じ時間を一緒に過ごすことで「場」が生まれ、「雰囲気」が生まれます。そこに浸っているだけで、次に何をすればいいかが自ずと決まりますし、従うのも楽です。子供は学校に通って、同じ時間割で過ごしますが、まさに同じことです。これは辛辣に言えば、**自律的に動けない人を動かすために環境の力を使っている** と言えます。

さて、フルフレックスはコアタイムを基本的になくすものですから、雰囲気リマインドもなくなります。計測可能な成果主義があるとはいえ、アウトプット自体は自ら動いて出していかねばならないわけです。フルリモートと合わせると、それこそひとりで、自宅で、自席で出すことになります。このような **「孤独に耐えながらも自律的に動いていける人」が実は圧倒的に少ない** のです。

フルフレックスの実現が難しい点もまさにここにあります。自律的でない人のカバーも考えないといけないのです。私も確たる解はない（あれば巨万の富を築けます！）のですが、今のところ一時的なコアタイムを工夫して「密度の濃いコミュニケーションの機会」を設けるしかないと思います。

たとえば二日に一回、一時間くらいカジュアルに雑談するためだけの「雑談タイム」を都度設けることで、自律的でない人のフラストレーションを解消できます。他にもマネージャー側にオフィスアワーを開催させて、その間はいつでも誰でも会話しにいっていいですよ、としてもらうことも多いです。無論、実際はそんな単純ではなく、複数の機会とその頻度を入念に調整することになります。

## 実装
フルフレックスはどのように実装していけばいいでしょうか。

組織次第なので一律には言えませんが、私がよく使う流れをご紹介します。

- 1: ミュートデイを成功させる
- 2: アウトプット・ベースド・コミュニケーションの型を網羅する
- 3: フルフレックスを就業ルールと評価方法に組み込む（まずは全社ではなく限定的で良い）

順に見ていきましょう。

### 1: ミュートデイ
まずは **ミュートデイ（Mute Day）** です。

これは **一日誰とも一言も喋らずに過ごす** ことを意味します。もちろん、仕事なのでこれで仕事を成立させる必要もあります。

私がフルフレックスの導入をリードする際に、最初に課すのは以下です。

- 「ミュートデイを成功させてみてください」

それができたら、続けて以下も課します。

- 「ミュートデイを一週間の間、安定的に二日以上成功させてください」

そして最後に「**ミュートウィーク（Mute Week）** を成功させてください」と言います。

何がしたいかというと、もちろんフルフレックスをさせたいのです。ミュート的に過ごすということは、同じ時間を過ごさなくても仕事が成立できるようにすることとほぼ同義です。たとえばミーティングは行えないので、アウトプットをつくって非同期的にやりとりすることになります。そのために知恵を絞ったり、仕組みや体制を考えたりします。

なんだか丸投げのようですが、私の経験として、**フルフレックスをどう実装するかの解は千差万別です**。私が「こういう概念と仕組みに従えばいい」と提示したところで、あまり意味はありません。その組織の文化にあったやり方を、その組織自身がつくらねばならないのです。ミュートデイはそのための実践練習になります。ただし、完全な丸投げだと先に進めませんから、背中は押します（次項でコラムとして述べます）。

この段階で、フルフレックスの実装可否も判定できます。仮に「ミュートデイはどうしてもできない！」と主張する組織がいたとしたら、その組織ではフルフレックスはできません。逆を言えば、ミュートデイができるのだとしたら、もう 7 割、いえ 8 割はクリアしたようなものです。

余談ですが、私が仕事として携わるのも基本的にはここまでです。次で述べますが、以降では組織固有の事情に基づいた推進になるので、抽象的な概念を扱うナレッジ・アーキテクトはさして力になれないのです。アーキテクトは開拓こそしますが、推進はしませんし、するべきでもありません。両者の才能は完全に分かれています。推進は専門外です。

### (コラム) ミュートデイのスタートアップ
私がよく使うのはアイデア出しです。

3時間くらい確保して、仕事はいったん置いてもらって、飲食物も自由に持ち込めますし入退場も自由です、とした上で、アイデア出しを始めます。

テーマは「ミュートデイを実現するためには？」です。

いわゆるブレイン・ストーミングと考えて差し支えありませんが、重要なのは発言ではなく情報です。頑張ってファシリテーションしてひとりずつ喋ってもらうことに価値はありません。十中八九、口頭だけでは足らないので、私はノートやボードを用意して、そこに書いてもらうようにしています。つまり **3 時間のカジュアル・アイデア・ライティング大会** です。これを Casual Writing Camp（CwC）と呼びます。

CwC のゴールは「ミュートデイを再現性を持って成功させられそうだ、が見えること」です。もしくは「いやミュートデイはどう頑張っても無理そうだ、とわかること」でも構いません。一回の CwC で足りなければ、日をおいて複数回実施します。3 時間である必然性はありませんが、午前か午後を丸々使うくらいの余裕はほしいです。私は 3 時間をおすすめします。2 時間は短いですし、4 時間はダレます。

### 2: アウトプット・ベースド・コミュニケーションの型を網羅する
フルフレックスを適用すると、すでに述べたとおりコアタイムがほぼなくなります。ミーティングやペアプログラミング、モブプログラミングを始めたとした高密度なコラボレーションも（一時的なコアタイム以外では）しません。

では普段のやり取りはどうやるかというと、アウトプット・ベースド・コミュニケーションです。アウトプットをつくって、それを見てもらう形で、非同期でやりとりするのです。

ここで困るのが **どういう型を使えばいいか** という話です。たとえば 1on1 一つを取ってみても、どんな型が必要かは組織次第でしょう。

参考までに、私は 1on1 を「情報交換の場」ととらえた上で、[テキスト1on1](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)を開発しました。Q&A 形式でお互いに書き込むというものです。Q&A のテンプレートを複数用意すれば、1on1 に関するコミュニケーションはカバーしきれるでしょう。もちろん、テキストだけでは「非言語コミュニケーション」はカバーできませんから、その分は一時的なコアタイムを使います。では、一時的なコアタイムは具体的にどうやって使う？――ここにも型があるので、ちゃんと突き止めて、言語化して決めます。

**ドメイン駆動開発のようなものだと思ってください**。型の把握は、ドメイン知識の把握と同義です。つまりそれなりに深いコミュニケーションやヒアリングが要ります。この時点ではフルフレックスは難しいでしょう。ミュートデイもできません。ですので私もしっかり入り浸って、たっぷりお話を聞くことになります。もちろん、私に対してそれだけの用意をしてくれない組織の場合は、申し訳ないですがフルフレックスはつくれません。把握しきれないからです。

ともかく、型を整理できたら、全社的に共有かつ啓蒙します。これらの型を使い分ければ、仕事上のあらゆるやりとりをカバーできる――というところを検証します。できるようになるまで型を充実させてください。というより、このメンテナンスは一生続きます。

### 3: フルフレックスを就業ルールと評価方法に組み込む
ここまでくると、あとは会社として正式にインセンティブをつくる段階です。

就業ルールと評価方法にフルフレックスを組み込みましょう。組織ごとに然るべきプロセスがあるはずです。人事と経営の仕事ですから、これ以上は割愛します。

---

# フルマスク

## 概要
**フルマスク（Full Mask）** とは、本名・容姿・性別を開示しない働き方を指します。自分の素の本名・容姿・性別を **プレーン・アイデンティティ（Plain Identity）** と呼ぶことにすると、フルマスクとはプレーン・アイデンティティを開示しない働き方と言えます。

プレーン・アイデンティティの開示は想定されません。また強要してもいけませんし、それはハラスメントとみなされます。代わりに普段はダミーのアイデンティティを使います。別の言い方をすると、プレーン・アイデンティティは健康状態や住所、また国によっては国籍や政治信条に相当するほどのセンシティブな情報だと考えてください。

ダミーのアイデンティティは複数つくったり使い分けたりできます。たとえば同じアイデンティティ A を、常に同じ人が使うとは限りません。あるときは🐶さんが A を被り、別のときは🐱さんが被っていることがあります。そういう意味では、アイデンティティは **仮面（Mask）** です。仮面を自由につくったり被ったりできるのです。

## メリット
フルマスクのメリットは次のとおりです。

- プレーン・アイデンティティを開示しないためマイノリティが阻害されにくく、組織の多様性が上がるため、真に仕事の質と生産性を両立できる
- 構造的に正体がわからず、言動と成果とマスクから判断することになるため好き嫌いや政治による腐敗を防げる。これにより組織が腐敗しづらくなり、組織の持続性と透明性が増す

## デメリット
フルマスクのデメリットは、従業員間で深い関係を築きづらいことです。

あなたが自身の病歴、住所、あるいは政治信条を伝える場合は、どのようなときでしょうか。どんな従業員であれば伝えられるでしょうか。よほど信頼できる相手か、親密な相手に限られると思います。それこそ友達やパートナーといった間柄になるでしょう。フルマスクも同様で、プレーン・アイデンティティを伝える相手も、そういう相手に限られます。

もちろん、フルマスク環境下では、常に仮面を被っていますから、ただでさえそのような間柄になるのは困難です。インターネット上で完結するコミュニティやマッチングサイトにおいて、リアルで会う仲になるようなものです。

そう、インターネットは良いたとえです。仕事上の関係は、素顔も本名も晒すことなく、オンラインで完結します。その先に踏み込むのは例外的であり、踏み込むことを前提にはできないのです。

## 実装
フルマスクを実現するためには、何を用意していけばいいでしょうか。以下に挙げます。

- 1: Full Three。フルリモート、フルフレックス、フルアシンク（完全ではないが相当なところまでは必要）
- 2: Account Management。プレーン・アイデンティティを晒さずに、しかしアカウントとその成果を結びつける仕組み
- 3: Mask Platform。マスクを自由に作成し、着脱するためのシステム
- 4: ボイスチェンジャー。発声を強制的に変更させる仕組み

### 1: Full Three
Full Three とは[フルリモート](https://dev.to/stakiran/full-remote-57k0)、[フルフレックス](https://dev.to/stakiran/full-flex-1kfn)、[フルアシンク](https://dev.to/stakiran/full-async-4hem)を指します。いずれも完全に実現させる必要はありませんが、少なくとも全社的に相当なところまでは定着させねばなりません。

たとえば以下の **すべて** を **全社的に**、かつ当たり前のように満たせるかどうかを考えてください。

- 月に一度も出社せずに済む
- 事実上のコアタイムが週に数時間程度で済む
- 同期的なコミュニケーションが一日一時間以内で済む

この程度ができていない場合、フルマスクは時期尚早です。なぜならフルマスクはプレーン・アイデンティティを晒さないあり方であり、出社や会議や同期コミュニケーションといった「原始的な働き方」との相性は最悪だからです。

### 2: Account Management
フルマスクでは全面的に仮面を被ります。つまりダミーのアイデンティティを使うことになります。これはプレーン・アイデンティティを晒さないアカウントを使い分けることを意味します。普段、皆さんも、特にプライベートでは SNS などで別人格・別名義のアカウントをつくっているかと思いますが、そのイメージで合っています。

概念的には、以下が必要です。

- **仮面（Mask）**
    - 何らかのダミーのアイデンティティ
    - ユーザー名や人物名として見えるもので、必ず誰か一人が被っている
    - 仮面には二種類の状態――「誰もつけていない」と「誰かがつけている」があり、「誰もつけていない」仮面は誰かが使うことができる
    - いつ、どの仮面を使うかは、場面ごとに設定できる
        - たとえば、ある三人席のミーティングでは🐶、🐱、🐵の三つの仮面が用意されているかもしれません
- **アカウント（Account）**
    - 特定の一人だけが被るマスク
    - SNS アカウントのように外見えのプロフィールがある
    - 従業員は複数のアカウントを持つことができるし、自分でつくることもできる
- **コア・アカウント(Core Account)**
    - 仮面やアカウントを紐づける先の、クリティカルなアカウント
    - ある仮面やアカウントの正体が誰か、という対応を紐づける。つまりそれらダミーのアイデンティティによる成果を入手する「本人」を指定する
    - 従業員はコア・アカウントを複数持つことができる。たとえるなら銀行口座のようなものである
    - コア・アカウントは他の従業員には見えない（見せることもできる）
- **プレーン・アイデンティティ（Plain Identity）**
    - 自分の素の本名、容姿、性別のこと
    - フルマスクでは一切晒さないが、**会社には提出する必要がある**
    - センシティブな個人情報の扱いと同じと考えれば良い
    - 必ずコア・アカウントに結びつける必要がある。複数のコア・アカウントに結びつけても良い

これは絶対的な正解ではなく、私がつくった参考です。しかし、フルマスクを実現するためには、この四つのレイヤーは必要だと思います。

これを全社員が扱えるような仕組みとシステムを実装してください。

### 3: Mask Platform
**仮面基盤（Mask Platform）** とは、仮面を誰でも自由につくったり共有したり着脱したりするためのプラットフォームです。社内向けの社内プラットフォームと考えてください。前述の 2: とも重複しており、仮面の部分のシステムに相当します。

Slack や Teams などビジネスチャットではチームごとに部屋が分かれますが、仮面も同じです。所属が違えば、どんな仮面を使っているかも変わります。この融通を実現できるだけのプラットフォームが必要です。

### 4: ボイスチェンジャー
プレーン・アイデンティティに肉声は含まれませんが、肉声から特定に繋がることがよくあります（特に性別）。1: にも書いたとおり、そもそも発話の機会が無いか、少ないはずですが、それでもゼロにはできませんし、必要なときはやります。

ですので、**発声を変化させるボイスチェンジャーも事実上必須です**。それも任意利用ではなく **強制** です。典型的には、仮面基盤とセットで実装して、仮面ごとにボイスを付与するといいでしょう。つまり、ある仮面 A を被った人の声は、A に搭載されたボイスチェンジャー越しになります。

## おわりに
フルマスクとは本名・容姿・性別を開示しないことです。代わりに仮面を被ります。

コンセプトはシンプルですし、現時点でも実現は可能ですが、それでも実際に実装するとなるとそれなりのコストがかかります。

---

# フルリモート

## 概要
**フルリモート（Full Remote）** とは、常にリモートワークで過ごすことです。

出社や出張は無いか、あっても稀です。ある場合でも定期性は無く、必要に応じて計画されます。頻度に指定はありませんが、 **四半期に一回未満** が目安と考えてください。これより高い頻度で出社や出張がある場合、フルリモートではありません。

勤務先は自宅である必要があります。会社が許すならカフェでもコワーキングスペースでも構いませんが、いずれにせよ **働く場所を完全に自分で選べる必要があります**。これを満たせない場合はフルリモートではありません。たとえば最寄りのサテライトオフィスへの出社を命じるパターンがありますが、これはフルリモートではありません（ただの分散拠点です）。

## メリット
- 移動に伴う時間的・精神的・体力的消費を抑えられて、その分を仕事に費やせること
- 各自の生活リズムに合った働き方ができて、パフォーマンスが上がる（というより下がらない）こと
- 職場の人間と深い関係を築くという **関係義務（Relationship Obligation）** から解放されて、その分を仕事に費やせること

フルリモートのメリットはプラスを得るというよりも、**マイナスを減らせること** にあります。

同じ時間帯に出社させることは極めて暴力的です。冷静に考えてほしいのですが、これだけ技術と方法が整った現代で、なぜ時間も場所も拘束されねばならないのでしょう？この感覚を理解できていないことに私は危機感をおぼえます。日本に限らず、欧米もアジアも BRIC も世界的に例外ではありません。

**単一の時間と場所へのとらわれから解放する手段がフルリモートなのです**。フルリモートにより、まず私達は移動や関係義務から解放されて、圧倒的に時間的・精神的・体力的余裕が生まれます。この分を仕事に費やせます。当然ですが仕事には勉強、練習、内省、休息も含みます。

## デメリット
フルリモートのデメリットは次の三点です。

- 1: 欲求充足。社会的な欲求を満たしづらくなること
- 2: サボタージュ。環境や集団の圧力がなく、自律的に動けない怠け者にとってはサボりの好機となること
- 3: 仕事環境の喪失。自宅で仕事できないなど、プライベートが整っていない者は仕事自体ができなくなること

これらをフルリモートで満たすのは難しいです。2: のサボタージュについてはカバーできますが、1: と 3: はどうしようもありません。

ですので、実際は **働き方の多様性（Workstyle Diversity）** を受け入れねばなりません。つまり、出社する人とフルリモートワーカーが共存できなくてはなりません。そうなると、全従業員はデフォルトでリモートワークの術を習得する必要があります。オンサイトとリモートとの情報格差などあってはならないわけです。

## 実装
フルリモートはどのように実装すればいいでしょうか。

結論を言うと、「コミュニケーションツール」と「ライティングツール」と「シームレス・ミーティングツール」です。

### コミュニケーションツール
まずはコミュニケーションツールです。先日 [QWINCS](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb) について書きましたが、チャット以外のツールも使わねばなりません。

皆さんは QWINCS のうち、いくつを知っていますか？また使っていますか？エンジニアであっても、普段のコミュニケーションツールはチャットだけだという人は多いですが、残念なことです。これはプログラミング言語で言えば「C 言語しか書けません」と言っているようなもので、昔ならさておき、現代では時代遅れにも程があります。危機感を持ってください。

フルリモートは出社をしないわけですから、その分リモートでコミュニケーションを済ませねばなりません。そのためにはチャットだけでは明らかに力不足です。料理するときは多数の小さな道具を使い分けますし、エンジニアも普段は小さなコマンドを使い分ける（KISS 原則）はずです。**コミュニケーションも同様** なのです。そのためには様々なコミュニケーションツールを、純粋に知っておくこと、また使えることが肝心なのです。

正直言って、QWINCS くらいは当たり前に使えるようにしたいです。開発プロセス中の限定的な利用じゃないですよ。**普段の日常的なコミュニケーションの用途で使えるようにしたい** という意味です。

### ライティングツール
次にライティングツールです。

エディタでも IDE でもウェブアプリでも構いませんが、とにかく言語を読み書きするための手段です。フルリモートでは対面で非言語コミュニケーションをする代わりに、リモートで言語でコミュニケーションをします。文字通りのリテラシー――言語の読み書き能力が絶対に必要です。

そしてそれを支えるのがツールです。私達エンジニアはすでにコードを書くために、エディタを含めとことんこだわり抜いているはずです。**コミュニケーションも同様** です。言語でコミュニケーションをするために、自然言語を読み書きするツールにこだわらなくてはなりません。

もう少し具体的に言えば、プレーンテキストの読み書きと共有のスキルです。Excel や Word や重たいウェブアプリを使わず、プレーンテキストで書けるでしょうか。読めるでしょうか。Markdown はわかるでしょうか。文章における「見出し」や「リンク」や「コードブロック」の概念はわかるでしょうか。そもそも段落と箇条書きと空行は使い分けられるでしょうか。そもそもタイピング（あるいは音声入力とその修正でも良い）はできるでしょうか、たとえば 1 日 5000 文字以上打てるでしょうか。

ここで文章の作法や言語化の素養について取り上げるつもりはありませんが、**ボトルネックは常にツールです。言語の読み書きが苦手あるいは遅い人は、十中八九ツールが未熟です**。

キラークエスチョンを一つお出しします。

**「コーディングではなくライティングの用途で、愛用のエディタはあるでしょうか？」**

ない場合、おそらくあなたはライティングに関して未熟です。フルリモートはできないでしょう。ライティングについても、コーディングと同等にこだわってみてください。

### シームレス・ミーティングツール
そして **シームレス・ミーティング** のツールです。

シームレス・ミーティングとは、その名のとおりシームレスに、つまりはスムーズにミーティングに移行できる様を指します。たとえば Slack にはハドルミーティングがあり、ワンクリックで会話を開始できます。このレベルで滑らかに開始できるものを指します。また[軽量バーチャルオフィス](https://dev.to/stakiran/notes-and-boards-as-virtual-offices-a-lightweight-approach-59n4)にも同様の機能があります。

フルリモートでもできるだけミーティングは減らしたいのですが、現実的にはそうはいきません。だからこそ、ミーティングを開始する手間は出来るだけ落としたいのです。

※だからといって、ペアプログラミングやモブプログラミングのような高密度な働き方はおすすめしません。こういった働き方は「働き方の多様性」を削ぐからです。無論、ミーティングの一環として、必要なときに一時的に行うのは良いです。

---

# HireMe タグと生成 AI

## サマリー
この記事の TEA（Target、Effect、Action）を示します:

- Target: エンジニアの採用や仕事へのアサインに悩むマネージャー、上級エンジニア、HR
- Effect: 採用やアサインのマッチング機会が何倍にも増えます（仮説検証的なマッチングを実現できます）
- Action: HireMe の名のもとに自己 PR をしてもらい、それを読むことでマッチングを検討します

## 背景

### 採用は一方的
採用は未だに一方的です。募集側が求人票（より形式的になるとジョブ・ディスクリプション）を書き、これと応募者をマッチングさせます。マッチングルートは「採用サイトに掲載された分からの応募」だったり「募集側からのアプローチ（スカウト）」しますが、ともかく **求人票という「定義」が存在します**。この定義とのマッチングを見る、との構図は変わりません。

### 一方的な採用は人材不足の主因
いつの時代も人材不足が叫ばれますが、その主因は明らかで、採用の仕方がこのように一方通行だからです。

アジャイルやリーンスタートアップに取り組まれた人は痛感しているでしょうが、事前の計画や設計が上手くいくことはほぼありません。だからこそ素早い仮説検証が重要とされていますし、今も生成 AI によりプロトタイピングが加速しています。**採用も同じことで、募集側が事前につくった定義が正解であることなどまずない** のです。大胆に言えば、**ジョブ・ディスクリプションも仮説にすぎないのです**。

さて問題です。仮説検証的でない、ウォーターフォールのようなヘビーなやり方で上手くいくでしょうか。答えはもちろんノーです。人材不足になるのも当然のことです。流動性の激しい欧米はまだマシですが、正社員の解雇がほぼ不可能な日本ではそれはもう悲惨です。

## 双方向にする
この問題を軽減する方法はシンプルです――双方向にするだけです。具体的には **「仕事を探している側」が自己アピールを書き、それを「人材を欲しがっている側」が読む** との逆方向を追加します。

この逆方向の取り組みは色々ありますが、今回は HireMe タグを紹介します。

## HireMe タグ
**HireMe** とは、その名のとおり「私を雇ってください」とのメッセージを込めたものです。タグと書きましたが、やり方はタグに限らず色々あります。

- SNS で行うとしたら、`#HireMe` タグをつけて投稿するでしょう
- GitHub 上で行うとしたら、hireme リポジトリをつくるでしょう
    - たとえば私の場合（サンプルなので空です）: <https://github.com/stakiran/hireme>
- Slack では `#HireMe` チャンネルをつくるでしょう
- 組織として hireme リポジトリをつくって、Issues として書かせてもいいかもしれません

エンジニアの皆さんなら、やり方は色々思いつくでしょうし、すぐにつくれると思います。現実的に HireMe を導入する場合、リードを行うのはエンジニアリングマネージャーでしょう。組織規模が大きいとスタッフエンジニアが良いと思います。

ともかく、重要なのはただ一点で、**個人から自己アピールする** との発想です。

## HireMe のメリット
メリットは一つで、**マッチングの機会を増やせること** です。一方通行の採用よりも桁違いにマッチングの機会が増えます。もちろん、機会が増えれば増えるほど出会いも増えますし、流動性も上がります。

言い換えると、雇用やアサインの **仮説検証** を実現できるようになります。双方向通信が通信の世界を変えたのと同じです。アジリティが上がります。

## 議論
ここで、主な議論を Q&A 形式で整理します。

### Q: HireMe を生成 AI に解釈させるのはアリ？
Ans: もちろんアリです。

むしろ、コンテキストとして「仕事を探している側の情報（HireMe）」だけでなく「人材を欲しがっている側の希望や状況」も用意した上で、AI に評価してもらうのが良いと思います。

セレンディピティというと大げさですが、意図しない出会いや思わぬダイヤの原石を大事にしたいのです。どうせ後半では我々人間がレビューするのですから、まずは可能性を広げておきたい。人間離れした生成 AI はまさに役に立ちます。

### Q: HireMe のフォーマットはどうすればいいですか？
Ans: そのうち決まってくるでしょう。

HireMe は、私が[ソフトスキル・エンジニア](https://dev.to/stakiran/soft-skills-engineering-34mg)として開発した概念です。皆さんに使ってもらって、広めてもらうことを期待します。インフルエンスの力を持つエンジニアに期待します。オープンソースのように、そのうち標準化の動きが出てくるでしょう。

私としては、生成 AI による多様化かつ省力化が良いと思っています。そうなってくると重要なのは、人間向けの形式よりも情報量です。Markdown で書く程度を守ったら、あとはどれだけ情報を込められるかにかかっています。

### Q: 誇張や嘘を書く人が出てくるのでは？
Ans: 大した問題にはならないと思います。

HireMe は個人に結びつくものなので、誇張や嘘を書くような「信用できない人」はすぐに淘汰されます。それがわかっているので、HireMe を書く側も無茶はしません。

### Q: HireMe には実績だけを書く？それともビジョンや戦略や自慢を描いても良い？
Ans: 良いです！むしろ推奨します！

前でも少し述べましたが、セレンディピティやインスピレーションを大事にしたいのです。別の言い方をすると、**採用もまたクリエイティブな営みである（というより、HireMe によりクリエイティブになる）** ということです。

ぜひ HireMe を書く側は思う存分に書いてください！HireMe を読む採用側も、常識にとらわれず、どう生かせるだろうかと頭を柔らかくして考えてみてください。もちろん、後の会話や選考の場でも、遠慮なく議論しましょう。

きっと、従来の一方向の採用では無かった体験がもたらされます！

---

# ChatGPT Projects は「間接的な会話」手段である

## 背景

### ChatGPT Projects ではチャットセッションを共有できる
2025年10月、ChatGPT Projects に共有プロジェクト機能が追加されました。

以下を見てください。

- Project/
    - Uploaded Files/
        - File 1
        - File 1
        - ...
    - Chat Session 1
    - Chat Session 2
    - ...

共有プロジェクトは、この Project に複数人が参加できるものです。つまり誰でもチャットセッションを開始できますし、他人のセッションを見ることができます。

### 「チャットセッションの共有」について
私達は普段 Slack や Teams などでコミュニケーションを取っています。このビジネスチャットと呼ばれるジャンルを支えているのはワークスペースやチャンネルといった「区分」の機能です。**関係者のみを集めた部屋をつくり、全員が自由に投稿と閲覧を行えるという、この部屋の概念が革新的だった** のです。

さて、この潮流が生成 AI のチャットにも到来しています。ChatGPT Projects もその一つです。

## 静かに、多くを伝えるために
会話というと、対面で口頭で行うイメージが根強いと思います。このやり方は使い勝手は良いですし、その気になれば汎用的に使えなくもないですが、原始的かつ瞬発的です。少なくともエンジニアにとっては好ましくない。

そこで間接的な会話を使います。**間接的な会話（Indirect Conversation）** とは、言語的に表現された成果物を見せ合うことでコミュニケーションを図ることです。以下に例を示します。

- コード
    - エンジニアなら言わずもがな、ですよね
- プレゼン・スニペット
    - 私の造語ですが A4 一枚の文書、スライド一枚、スクロール不要な程度のページなど「一枚」で整理された資料を指します
    - 皆さんの会社でも、特に提案の文脈で、プレゼン・スニペットを前提としたフォーマットを使うよう指示されていることがあると思います
- チャットセッション
    - 元々 ChatGPT にはセッションを共有する機能がありました

ChatGPT Projects は、ここに加わった新入りです。

- **対話ワークスペース**
    - AI とのチャットセッションを複数人で共有するワークスペース。例は ChatGPT Projects

## 対話ワークスペースの活用例
たとえば、ある難しい技術的な議論がしたいとします。

半人前のエンジニアリングマネージャーであれば、おそらく自分と周辺の同僚、または目上の仲間とだけ議論するでしょう。逆に一人前であれば、現場や顧客とも会話するはずです。

しかし、現場や顧客との会話は難しいです。彼らはマネージャーほど俯瞰していないことが多いですし、言語化の能力も時間もないからです。だからこそドメイン駆動設計、また近年のアジャイルのように、プロジェクトに入り込んで高密度に会話して引き出していく営みが重要視されてきました。

こういうときに、まさに対話ワークスペースが使えます。やり方は単純で、

- 1: その議題を名前にしたプロジェクトをつくる
- 2: 関係者をプロジェクトに招待する
- 3: 各自、チャットセッションを行う。また他人のセッションを見て続きをフォークしたり、思いついた観点でさらにセッションをする

このようにして皆でセッションを増やしていくだけです。そういう意味では、コミュニケーションよりもコラボレーションと呼んだ方がいいかもしれません。

## おわりに
間接的な会話という概念をご紹介しました。また ChatGPT Projects は（最近のアップデートにより）このポテンシャルを有するようになりました。

生成 AI 時代だからこそ、私達人間のコミュニケーションと議論が重要です。対面口頭では限界があります。間接的な会話をぜひ実践してみてください。それではまた。

---

# Influence sucks

## サマリー
- インフルエンスはエンジニアの責務ではない
    - エンジニアリングマネージャーや上級エンジニアの仕事だろ
- 目標設定時にインフルエンスを入れるな、詰むぞ
    - インフルエンスには相応の権威と権限が要る。現場レベルのエンジニアには無理に決まってんだろ

## 背景

## インフルエンスはエンジニアの責務ではない
ここで **インフルエンス** とは、具体的な影響を与えることを指します。売上が上がった、工数を減らした、顧客や社員の n 人に採用してもらえた等。

私は声を大にして言いたい――インフルエンスはエンジニアの責務ではない、と。

エンジニアリングマネージャーや上級エンジニアを除き、現場のエンジニアの責務はタスクに取り組むことです。トップダウンまたは合意形成で決めたタスクに取り組むことであり、したがって **エンジニアの責務はタスクの完遂まで** です。

そのタスクがどれだけインフルエンスを与えるかは、タスクを定義するマネージャーや上級エンジニア、あるいは経営者の責務のはずです。

## なのにインフルエンスが目標設定に組み込まれる
皆さんの目標設定はどうしてますか。業績評価はどのように行われますか。

たぶん、高確率でインフルエンスに関する目標も組み込まれているでしょう。そして評価を下されます。もちろんインフルエンスなんて専門外ですし、権威を持たないエンジニアがこなすなんてそもそも無理ですし、達成できなければ低評価になります。最悪解雇の対象にすらなります。このような悲劇を避けるために、**エンジニアなのにインフルエンスの活動に従事しなければならなくなります**。アピールせよ、といわれたりしますね。政治ともいいます。

## どうすればいいのか
二点あります。

### 1: 目標設定にインフルエンスを組み込むな
まずは、とにかく目標設定にインフルエンスを入れないようにします。

そもそもインフルエンスは相応の権威と権限を持つ役割の仕事です。それを与えられているエンジニアリングマネージャーや上級エンジニアの仕事であって、現場レベルのエンジニアがやることではない。にもかかわらず、目標に入れてくるのは放棄ですらあります。

主張してください。**インフルエンスではなくパフォーマンスで勝負してください**。

ここでパフォーマンスとは能力と成果のことです。たとえば、あるモジュール M の機能追加と品質に責任を負うエンジニアがいたとして、この人の責務は M の機能追加と品質確保までです。M がどれだけインフルエンスを与えたか、与えねばならないか、といったことは責務ではない。それはマネージャーや上級エンジニアが定義または調整することなのです。

### 2: インフルエンスはお前の責務である、と啓蒙しろ
加えて、インフルエンスはエンジニアリングマネージャーや上級エンジニアの責務である、と伝えてください。みんなでしつこく伝えてください。

ビジネスですのでインフルエンスは必要です。誰かがやらねばなりません。インフルエンスを行うのは、相応の権威と権限を持つ役割だけです。仮にインフルエンスを行うとの発想がなかったとしても、「持つ者」がやらなければなりません。

もし、どうしても彼ら管理職や上級職がやりたがらないのであれば、できる人に委譲するよう進言してください。もちろん権威と権限もセットで。これは通常飛び級レベルの抜擢になります。

---

# アウトプットのインセンティブは 3R（Role、Reward、Regard）

## 背景
脱属人化、ナレッジや情報の共有、透明性の確保などのためにアウトプットが推奨されます。しかし、これに取り組んでくれないエンジニアが多いという点は言うまでもないでしょう。

単純な話で、インセンティブがないからです。特に普段から仕事で忙しいのに、なぜアウトプットしなきゃいけないのだと反感すら抱かれます。

※ここでアウトプットとは社内の、比較的広い範囲への共有を指します。10 人未満のチームというよりは、その外です。部門全員だったり、全社全員など。通常は社員全員が見れる場所に公開することを意味します。勉強会などイベントの形を取ることもあります。

## インセンティブを確保する
結局のところ、インセンティブは以下の三種類しかないように思います。

- Role。アウトプットを仕事の一部にできること。そのような役割に就けること
- Reward。経済的、時間的、または役職的なインセンティブがあること。ナレッジとして明らかに工数削減につながるか、あるいは昇進や昇給の足しにできるかの二点です
- Regard。自分の名前や専門性やキャラクターなどを、自分の存在感を認知してもらえること

最も多いのが Reward ですが、個人的におすすめはしません。なぜなら **Reward が得られる分のアウトプットを最低限行うだけ** だからです。無いよりはマシですが、持続性がありません。

最も強力なのが Regard ですが、人を選びます。Regard を好むのは、元々プライベートでもブログや SNS などでアウトプットを行うほどの猛者だけです。このようなエンジニアは 5% もいません。

そういうわけで、一番現実的で汎用的なのが、実は Role だったりします。Role とはどういうことでしょうか。これは仕事としてアウトプットを堂々と行えるということです。たとえば一日のうち、半日くらいをアウトプットに使えたりします。そのような贅沢な過ごし方が許される役割という意味です。もちろん、仕事であり、正当な役割なので評価もされますし、キャリアの一部にもできます。これは魅力的に映ります、なぜならアウトプットが好きなエンジニアはそれなりにいるからです。

## インセンティブを設けるかどうか
アウトプットを促進したい？

ならばインセンティブを設けよ。話はそれからだ。

---

# 「キャリアラダーは逆三角」というバイアス

## サマリー
- 以下のバイアスが根強く染み付いています:
    - キャリアラダーが上に上がるほど、できることが多い。定義されていない問題を解く
    - キャリアラダーが下に行くほど、できることが少ない。具体的な問題や指示された問題を解く
    - つまりラダーの高度と抽象性が比例する、とのバイアスがある
- バイアスは捨てましょう
    - 役職が高くない者の中にも、抽象的な問題を解ける者はいる
    - 逆に役職が高いからといって解けるとも限らない
- ただし影響を与える段階では高さが必要です
    - 関連記事: [Influence sucks - DEV Community](https://dev.to/stakiran/influence-sucks-151i)

## 背景

### キャリアラダーと抽象性は比例する
ラダーを上がるほど、つまり役職が高くなるほど抽象的な問題を扱うようになります。人や組織といった曖昧な事象も扱うため、ソフトスキルも重要になってきます。逆にラダーが低いうちは常に具体的で指示的な問題ばかりを解きます。技術的で「硬い」問題に取り組めばいいだけなので、ソフトスキルの出番はありませんし、むしろ忌避されます。

このバイアスを私は **逆三角型のキャリアラダー（Inverted Triangle Career Ladder）** と呼んでいます。ラダーを上がるほど広く、ラダーが低いうちは非常に狭いわけです。

### キャリアラダーと「抽象性を扱う能力」は無関係
しかし、ラダーの上にいるからといって、実際に抽象性を扱う能力が高いとは限りません。逆に昇進していないか、一度しかしていないようなエンジニアであっても、抽象的な問題に取り組む力を持っていたりします。

さあ、バイアスを解き放ち、組織の機動性と柔軟性を上げましょう！

## バイアスを捨てても上手くいく運用
では、逆三角型のキャリアラダーバイアスを捨てたとしたら、組織やプロジェクトの役割分担はどのように変化するでしょうか。もっというと、どのように運用すれば上手くいくのでしょうか。

### 1: 探索とパフォーマンスと影響を区別する
まずは以下の三点を区別することです。

- 探索
- パフォーマンス
- 影響

**探索** とは、抽象的な問題を解く（ために検討をする）ことです。プロジェクトほど見えていないのでプロジェクトワークはしません。全く新しいアプローチが必要であり、私は[トランスジェクト（Transject）](https://dev.to/stakiran/project-vs-transject-cpd)と呼んでいます。具体的な手法としては、先日[クリエイティブ・シンキング](https://dev.to/stakiran/introduction-to-creative-thinking-5em0)について解説しました。

**パフォーマンス** とは、ここでは能力と成果物を指します。たとえば OpenAI API の利用方法と諸性質を比較してドキュメントにまとめたり、実際に会社のガバナンスに則って試してみたり、その検討や試行の結果をナレッジ化して共有したりといったことができるエンジニアがいたとします。この人に調査、プロトタイピング、ドキュメンテーションや共有といった能力があるのは明らかです。また成果物もあります。パフォーマンスがあると言えます。

最後に **影響** とは、実際に数字の改善につなげることを指します。パフォーマンスとの違いに注目してください。影響を与えるには、相応の権威が必要不可欠です。マネージャー以上の立場の責務です。ですので、権威を持たない現場のエンジニアに影響の責務を与えるのは、実は職務放棄ですらあります（唯一の例外は「影響が出ると確定している作業を割り当てること」）。この点は [Influence sucks](https://dev.to/stakiran/influence-sucks-151i) でも強調しました。

### 2: 探索を解禁する
上記の三要素を区別できたら、次に **探索の仕事を現場レベル含めて誰でも行えるようにします**。

わかりづらいので Before/After で説明します。またキャリアラダーは単純化して、lv1 現場、lv2 マネージャーまたは個人貢献者、lv3 上級エンジニア、lv4 経営層としましょう。

以下は各要素をどのレベルが行うかを示したものです。Before が従来のバイアス、After が今回の提案です。

|  | Before | After |
| --- | --- | --- | 
| 探索 | Lv3～ | Lv1～ |
| パフォーマンス | Lv1,Lv2 | Lv1,Lv2,Lv3 |
| 影響 | Lv1～ | Lv2～ |

具体的な変化は次のとおりです:

- まず影響は Lv1 は負わないようにします
- 次に **探索を Lv1 からでも行えるようにします**
- そうすると Lv3 の一部が空きますので、パフォーマンスの責務に入れる可能性があります

従来は Lv3 以上が行っていた探索を、Lv1 でも行えるようにするのです。しかし Lv1 はすでに述べたとおり、具体的な影響を与えられるだけの権威がありませんから、影響の責務は Lv2 以上が担います。

### 3: 探索と影響を接続する
探索を Lv1 でも行えるようにしたところで、その結果がビジネスに繋がらなければ意味がありません。その部分はもちろん影響として行います。Lv1 には影響を与える権威がないので、Lv2 以上が引き受けなくてはなりません。

つまり、**Lv1 が探索した結果を、Lv2 以上の者が受け取って影響を及ぼしに行く** との連携が必要になるわけです。

このような提案をすると、よく「無責任ではないか」のような意見が来ますが、それこそがバイアスです。Lv1 に影響を与えるのは無理なんですって。でも Lv1 でも探索を行える者はいるのです。だったら、行える Lv1 に探索を任せて、その結果をどう勝利するかを考えればいい。役割分担ですね。

## おわりに
キャリアラダーの高さと抽象的な問題を扱う能力は比例しません。しかし、抽象的な問題を探索した結果を適用するには影響力が必要で、影響力には高さが要ります。

そういうわけで、以下のような連携が実は可能なのです。

- 抽象的な問題の探索は、それが得意な現場レベルのエンジニアに任せられるかもしれない
- その結果を使った影響の行使は（現場レベルでは）できないから、権威を持つ者が引き継いで実施する

もしあなたがラダーをそれなりに登っていて、しかし抽象的な問題に苦しんでいる場合、ぜひバイアスを捨ててみてください。抽象的な問題を扱えそうなメンバーが、たぶんいるはずです。上手く連携しましょう。

---

# IVVV Stack
PERN でも JAM でも LAMP でも MEAN でもありません。

IVVV Stack は **フロントエンドのみで完結する** シンプルな構成であり、以下の略です。

- Indexed DB
- Vanilla JS
- Vanilla HTML
- Vanilla CSS

ね、シンプルでしょ？

## サンプル
IVVV でつくったメモアプリです。

- アプリケーション
    - <https://stakiran.github.io/memoapp1/>
- リポジトリ
    - <https://github.com/stakiran/memoapp1>
- プロンプト
    - <https://chatgpt.com/share/6926aad9-faf0-8007-bcb8-9e64cd1f86b1>

## IVVV は生成 AI で開発する
現代のエンジニアがバニラの JS、HTML、CSS で開発するのは無理があります。小規模であっても、おそらくやりたくないことのはず。

生成 AI を使ってください。ある程度の言語化能力があれば、ちょっとしたプロトタイプくらいはつくれてしまいます。ランダムや非同期を使えば、擬似的に複数人が使用している風に見せることも可能です。IVVV だけでもそれなりのものがつくれます。

---

# ナレッジングとは何か

## ビジョン
> マネジメントをマネージャーが担うように、ナレッジングはナレジャーが担う。
> 
> これにより、エンジニアはエンジニアリングに専念できるようになる。

## はじめに
暗黙知、ナレッジ共有、ナレッジマネジメントなどナレッジに関する営みは古くから知られていますが、あまり整備されていません。生成 AI 時代の現代だからこそ、ナレッジを上手く扱えるようになりたいところです。

しかし、ナレッジを扱うのは **とても** 難しい。マネージャーやエンジニアが片手間でできることではないのです。**専門的な役割が必要不可欠です**。

ようやく整備できましたので共有いたします。ナレッジを扱う営みを **ナレッジング** と呼ばせてください。これは新しい領域であり、エンジニアリングやマネジメントといったレイヤーに位置するものです。以下をご覧ください。

| 営み | 役割 | 扱う対象 | 対象に対して行うこと | 
| --- | --- | --- | --- |
| マネジメント | マネージャー | 人 | 接する、御する、促す |
| エンジニアリング | エンジニア | ソフトウェア | 設計する、開発する、運用する |
| ナレッジング | ナレジャー | ナレッジ | 言語化する、生産する、啓蒙する |

ナレッジングとは第三のパラダイムなのです。

## この記事について
ナレッジングの概要を整理します。

## ナレッジングとは

### ナレッジとは
まずは「ナレッジ」について定義せねばなりません。

定義を言えば、次のとおりです:

- ナレッジとは、**第三者に伝わるように表現された概念** を指す

定義だけではわかりづらいので、例を挙げましょう。

- ナレッジの例:
    - ドメイン知識
    - 組織やチームや個人のルール、プロセス、原則、文化
    - 仕事のやり方、考え方、働き方
    - 道具の存在や使い方、また道具が持つ概念
        - 🐰たとえば X におけるフォローの概念は、X という道具が持つ概念です
    - 学問、その他学問ほど体系化されてはいない理論

おそらく、あなたが思い浮かべた「ナレッジ」よりも広い意味合いだと思います。そのとおりです。

私達は普段抱くであろうナレッジの意味合いは極めて狭義的です。たとえば、私達はなぜかナレッジに優劣を付けたがりますが、ナレッジがいつ誰の役に立つかなんて誰にもわかりません。また、ナレッジを「すでに検証されて価値があると判明した事象」を言語化したものだ、とする人も多いですが、それは「ベストセラーとしてランキングに載った本だけ読む」ようなものであり、狭いです。

ナレッジングにおけるナレッジには、以下が当てはまります:

- 暗黙知も形式知も含む
- 検証されている必要はない
    - 🐰つまり机上で考えて言語化しただけの概念もナレッジです。もちろん、検証されていないよりは、されていた方が良いのは言うまでもありません
- 漂白されている必要がある

漂白について補足しましょう。漂白されているとは、外部に公開できるということです。もっと言えば機密情報が含まれていないことを意味します。エンジニアの皆さんはブログやドキュメントをオープンに公開すると思いますが、まさに漂白を経ています。社内の自分の外、という程度ではいけません。社外である必要があります。端的にはインターネット上に、誰でも読めるように公開できるかという話です。つまり **ナレッジとはオープンなもの** なのです。

まとめると、ナレッジとは **第三者に伝わるように表現され、かつオープンに公開することもできるような概念** を指します。

### ナレッジングとは
次にナレッジングの定義に入りましょう。

ナレッジングとは **ナレッジを扱うこと** を指します。具体的には V O S E の 4 つのステップから成ります。

- 1: 言語化（Verbalization）ステップ
- 2: 生産（Output）ステップ
- 3: 共有（Share）ステップ
- 4: 啓蒙（Enlightenment）ステップ

**言語化ステップ** では、言語で表現します。この時点ではカジュアルで構いません。言語化時点ではナレッジは「未完成」であり、誰もが好き勝手に加工したり、ダシにしたりする余地があります。Wiki みたいなものですね。

その他、言語化ステップに関する重要な事項を挙げます:

- 収束されている必要はない。発散したものでも良い
    - 🐰たとえば「Miro で発散させた 100 枚の付箋」でも構いません
- 最低限 **お題（タイトル）が明示されていなければならない**
    - 🐰タイトル無き言語化は言語化ではありません
- 可能であれば **文脈** も添付したい
    - 🐰文脈とは背景、前提、理由、方針や戦略、その他リソースの制約などのことです。ADR(Architecture Decision Record) やデザインドキュメントなど文脈を書くことの重要性は今や周知と思います。そもそも生成 AI を使うときも、プロンプトに明示的に文脈を書きますよね。同じことです

次に **生産ステップ** では「本格的な言語化」または「道具化」を行います。前者はドキュメントをつくり、後者はソフトウェアなどの道具をつくります。いずれにせよ、言語化ステップでラフに言語化したナレッジを下地にして生産します（天才ならいきなり生産ステップから始められるでしょうが）。

その後、**共有ステップ** にて、言語化したナレッジや生産したナレッジを公開します。そうです、生産したナレッジに限らず、生産ステップの前段階の「言語化しただけのナレッジ」を公開しても良いのです。むしろ推奨します。その方がナレッジングが捗るからです。このように、カジュアルにナレッジを出し合ってコミュニケーションすることを **ナレッジ・ベースド・コミュニケーション** と呼びます。

話を戻しましょう。**公開** と書いたことに注意してください。いつでも誰でも使えるように置いておく、ということです。古典的な組織や閉鎖的な組織では、しばしば以下のようなことを言います。

> 聞かれたら答えるよ。だから情報共有はできているし、うちはオープンでフラットだと言える。

違います。そのような言い分はただの伝達にすぎません。共有とは公開であり、誰に対しても開かれていなければなりません。これはナレッジングにおける定義にすぎませんが、重要なことです。

最後に、**啓蒙ステップ** では、共有したナレッジを使って、それを教える機会を設けます。勉強会、ワークショップ、ティーチングやコーチング、1on1、オフィスアワー、非同期的な Q&A など何でも良いですが、機会をつくるだけに留めてください。言い換えると、機会を使うかどうかは（ナレッジの提出先となる）相手次第です。相手に強要していけません。この点は次でも詳しく掘り下げます。

### ナレジャーとは
ナレッジングを行う専門職を **ナレジャー** と呼びますが、**ナレッジの適用はナレジャーのスコープ外です**。

ナレジャーはあくまでも上述した VOSE に専念します。ナレッジは極めてクリエイティブな営みだからです。ナレッジの適用は、マネージャーやリーダーなど然るべき役割の人が行ってください。もちろん、適用の中でナレジャーを使うのは構いません。

別の言い方をすると、ナレッジを適用するには結局権威や信頼が必要なのです。ナレジャー単体はそのようなパワーを持ちません。ナレジャーが行うのは行使ではなく VOSE だからです。行使は、パワーを持った従来からの役割に任せます。

## ナレジャーを細分化する
ナレジャーの下には、いくつかの役割がぶらさがっています。

- ナレジャー
    - ナレジニア
    - ナレッジ・ライター
    - カタリスト
    - ナレッジ・アーキテクト

ナレジニア 100% やカタリスト 100% のナレジャーもいれば、普段はカタリストだがナレッジ・ライターもできるというハイブリッドもありえますし、もちろん全部できるケースもあります。

では、それぞれ見ていきましょう。

### ナレジニア
ナレジニア（Knowledgineer）とは、生産ステップにおいて道具化を行うナレジャーです。たとえばソフトウェアをつくります。**既存用語のナレッジエンジニアと区別するため、あえてナレジニアと略している** ことに注意してください。

ナレジニアは、ナレジャーの血が多少混ざったソフトウェアエンジニアと言えるでしょう。もちろんインフラエンジニアでもシステムエンジニアでも SRE でも何でも構いません。要するに、生産ステップにおいて、言語化を捨てて、代わりに道具をつくるわけです。「ナレッジ」を道具で表現するということです。

### ナレッジ・ライター
ナレッジ・ライター（Knowledge Writer）とは、生産ステップにおいて本格的な言語化を行うナレジャーです。ドキュメントをつくります。

ナレジャーとしては最もわかりやすいと思います。ナレジニアは言語化から道具化に逃げているとも言えますが、ナレッジ・ライターは逃げません。ちゃんと言語化と向き合い、ドキュメントというレベルで成し遂げます。

もちろん、長ったらしくて厳密なマニュアルや法規のように長々と書けばいいというものでもありません。ナレジャーの本懐はナレッジをつくって共有して啓蒙することにあります。つくりやすく、共有しやすく、啓蒙しやすいものでなくてはなりません。ライティングというよりは概念のエンジニアリングであり、ナレッジ・ライターもまた極めて高度なクリエイティブと言えます。

### カタリスト
カタリスト(Catalyst)とは、組織の内外を行き来してナレッジを行き来させるナレジャーです。

ここで組織とは、自分が普段属している組織単位を想定してください。チーム、部門、事業部、会社など階層的にカスケードしていると思います。会社の外には出ません。つまり会社の中で行き来します。わかりづらければチームの内と外、と考えてもらって構いません。

カタリストは直接ナレッジをつくる（言語化や生産をする）わけではありませんが、代わりにナレッジを運びます。触媒の概念は名著「デッドライン」や「ピープルウェア」でも出てくるように、人と人を繋ぐニュアンスがあります。同様に、ナレッジングにおけるカタリストも、人から人にナレッジを運びます。外から内に持ち込みもしますし、内でつくったナレッジを外の誰かに届けもします。

カタリストは中々に難しい仕事です。ナレッジは基本的に「言語で表現された概念」であり、そのままでは伝わりにくいものです。これを何とかして使ってもらうなり議論してもらうなりしてほしいのです。働きかけるわけです。もちろん、自身が扱うナレッジそのものも理解していなければなりません。カタリストはナレッジをつくりはしませんが、理解と伝達はするのです。難しい仕事です。

### ナレッジ・アーキテクト
ナレッジ・アーキテクト（Knowledge Architect）とは、組織としてナレッジングを行っていくための「仕組み」をつくるという前提で、その仕組みの全体像を考えて提示する役割を指します。また現行を理解して説明責任を果たす役割を負うことも多いです。

別の言い方をすると **ナレッジング・プロジェクト（Knowledging Project）** における設計統括者と言えるでしょう。ナレッジング・プロジェクトとは、組織として何らかのナレッジングをちゃんとやっていこうよ、を考えて形にする活動を指します。ソフトウェアやマネジメントと同様、ナレッジングにも戦略や仕組みといったものがあります。組織として行うとなれば、どうしても全体を見る立場が必要です。もちろんナレッジングに関する深い見識も必要です。その名のとおり、アーキテクトなわけです。

一つ注意したいのは、ナレッジング・プロジェクトは顧客向けのプロジェクトではないということです。自チーム、自部門、自事業部、自社など自組織に関する改善または投資の活動を指しています。つまり **ナレッジ・アーキテクトには社外への説明責任を果たす能力は要りません**。むしろ、そんなことに費やす分を、社内のナレッジングを考えたり関係者と協調したりするのに費やすべきです。

## ナレッジはどのように役に立つか
ここまでナレッジング、ナレッジ、ナレジャーと概要を説明してきました。では、そこまでしてナレッジをつくって伝えることには一体どのような価値があるのでしょうか。何の役に立つのでしょうか？

**Ans: 仕方の改善に役立ちます。**

大前提として、人間は合理的ではありません。しかし仕事は合理的に進めた方が良いです。

合理的というと資本主義的な搾取や労働への献身を思い浮かべるかもしれませんが、違います。合理的とは人間の性質を踏まえた上でベストなパフォーマンスを出すということです。別の言い方をすれば、**持続的にベストなコンディションとパフォーマンスを出す** ことです。

たとえば働き方を考えましょう。

- A: 全員に毎日出社と同じ勤務時間を課したチーム
- B: リモートとフレックスを駆使して、朝型と夜型、ハードワーカーとライトワーカー（残業無し）が混在したチム

A と B はどちらが合理的でしょうか。無論、状況次第でもありますが、標準的には B が合理的です。B の方がより人間に優しいからです。A のように高負荷を課して成果を出せるのは当たり前です。極端な例は奴隷です。

では、合理的になるにはどうしたらいいでしょうか。B でも成立させるためには、一体どうすればいいのでしょうか。

概念です。合理とは仕方であり、仕方は概念から構成されます。**概念を理解し、使いこなすことで合理的になれるのです**。この本質を理解し、実践しない限りは、A のように極めて原始的な営みしかできません。これでは一部のスーパーマンしか機能しませんし、構造的に権力とボトルネックも生じやすくて政治も生まれます。早い話、好き嫌いの話になります。好き嫌いの戦いを勝つための、くだらない政治に多くを費やすことになります。皆さんにとってもよくあることでしょうし、たぶん現在進行で苦しんでいることでしょう。

ナレッジングは、その概念に目を向けるところをまさにやります。ナレッジとは概念のことです。人間は言語により理性的になれるように、人間は概念により合理的になれます。

別の言い方をすると、合理を構成する仕方があり、仕方を構成する概念があるという構造において、概念の視座に立ち、概念を操作することによって合理を操作できるようにします。概念をいじくることで、合理性をカスタマイズできるのです。

現代は VUCA と呼ばれます。先が読めず、変化も激しい時代です。また DEIB ともいわれます。多様なあり方を許容しつつ、結束を固めねばならないという難しい時代でもあります。原始的な営みでクリアすることなどできません。合理的に立ち向かわねばならず、ナレッジングはその手段として重宝します。これはマネジメントでもエンジニアリングでもカバーできない第三の領域です。

## おわりに
本記事では第三のあり方「ナレッジング」について整理しました。

ナレッジングとは、第三者に伝わる概念をつくって伝える営みです。この専門職をナレジャーと呼び、ナレジニア、ナレッジ・ライター、カタリスト、ナレッジ・アーキテクトなどに細分化されます。エンジニアがソフトウェアをつくってコミュニケーションするように、ナレジャーはナレッジをつくってコミュニケーションします。

私のアカウントでは、ナレジャーとしての取り組みや成果物を紹介していきます。ナレッジングが有益であり、そして楽しくてエキサイティングでもあるということをお伝えしたいと思います！ぜひお楽しみください。それではまた。

---

# 個人レベルの振り返りを身につける：KPT → YWT → 4Y

## サマリー
- 自分に関する振り返りを自分ひとりでじっくり行うことも重要
    - KPT を始め、振り返りはチームで行うものと思われがち
    - **それとは別に**、自分の振り返りを自分でやるといい
- 個人の振り返りの肝は以下二点
    - 1: 指定フォーマットに従って、ログを書き残していくこと
    - 2: 書き残したログを定期的に振り返ること
- 問題はフォーマットだが、三点ほど紹介する。後のものほど優秀
    - 1: KPT
    - 2: YWT
    - 3: 4Y

## 背景

### 個人の振り返りも重要
皆さん、振り返りはしていますか。アジャイルなチームであれば、定期的にやっていると思います。

では **個人では** どうですか？

自分をよく知るのも自分なので、自分の振り返りは自分自身で行うのが良いです。すでにアジャイルの形で振り返りの重要性は理解しているはずです。個人レベルでも、やらない理由はありません。

### どうやって？
ここで問題が一つあります。

自分の、自分による、自分のための振り返りはどうやって行えばいいのでしょうか？

アジャイルのフレームワークに則って行うのは大げさすぎます。GTD®のようなオープンではないフレームワークも使いづらいです。自分で新しく模索するのはもっと面倒くさいでしょう。

私はナレッジ・アーキテクトとして多くの人を見てきましたが、人は怠け者であり、あまり難しいことはしまｓねん。個人レベルならなおさらです。できないのではなく、**しない** のです。本質的にシンプルで、かつ持続的なやり方を考案せねばなりません。

## 振り返りの概論
そもそも振り返りについて知らない方のために、軽く解説しておきます。

※日本では国民の誰もが知るくらいメジャーな概念ですが、他国ではそうとも限りません。エンジニアならアジャイルの形で触れているはずですが、ライフワークとして染み付いているわけではないでしょう。というわけで解説をしておきます。

### 振り返りとは
毎日記録を取り、定期的に（不定期でも良い）それを見て洞察を得ることです。

要件は以下の二点です。

- 毎日記録を取ること
- 記録を見て洞察を得ること

たとえば Slack で「ひとりでつぶやく用のチャンネル」をつくって、X のようにあれこれポストします。これを、たとえば毎週日曜日に読み返します。読み返した上で何を得るかは自由です。やり残したタスクを捉えてもいいですし、今週手を付けたいアクションやアイデアを宝探し感覚で漁ってもいいですし、今週やることと捨てること一つずつ選んでも良いのです。

自由と言えば、記録の書き方も自由です。日記やブログのように雑にやってもいいですし、仕事のように厳格なフォーマットに基づいても良い。

### 振り返りのメリット
振り返りのメリットは、記録をベースとした「明示的に考える機会」を得ることです。

私達人間は怠け者ですし、恒常的に忙しいので、立ち止まって考えることをしません。また記憶も信用できないので、立ち止まったとしてもあまり有意義な思考はできません。これを防ぐ唯一の方法は、ちゃんと書いて、ちゃんと読み返すことです。

### 個人で振り返りをする際の最適な塩梅
以下の三点を心がけると良いでしょう。

- 1: フォーマットを事前に定義し、それを埋めるだけで済むようにする
- 2: ローカルのメモや SNS へのポストのように気軽に行えるようにする
- 3: プレーンテキストとして残し、後で素早く振り返れるようにする

つまり **プレーンテキストベースで、理解も運用も用意で、日々楽しく書き込めるようなフォーマットが望まれます**。

これより雑だと振り返りが成立しません。また、これより煩雑だと形骸化するので、やはり成立しません。エンジニアの皆さんにとっては、これくらいが最適な塩梅だと考えてください。

※ちなみに、この塩梅でもできない人はいます。振り返りに向いてない性格や特性はあります。その場合は申し訳ないですが諦めてください。あるいは、生成 AI からリマインドしてもらうような仕組みを自分でつくりましょう……。 

## 振り返りのフォーマット
本題に入りましょう。個人で振り返りを行うためのフォーマットを三つ紹介します。

### 1: KPT
**KPT** は Keep、Problem、Try の略です。

Keep として「良かったこと」や「続けたいこと」を挙げます。ポジティブです。Problem では「悪かったこと」や「やめたいのに続いていること」を挙げます。ネガティブです。Try は、Keep や Problem を受けて「次に試したいこと」を挙げます。アクションです。

元々はチームで、付箋で行うものでした。以下のようなシートをつくって、各自が付箋を張っていくわけです。Miro のようなデジタルホワイトボードでもできますし、もちろんアナログでも可能です。

```plaintext
 +---------+---------+
 |         |         |
 |  Keep   |         |
 |         |         |
 |---------|   Try   |
 |         |         |
 | Problem |         |
 |         |         |
 +---------+---------+
```

今回は個人の振り返りですので、これを一人でやります。もちろんプレーンテキストベースでもあるので付箋は要りません。以下で十分です。

```markdown
# 2025/11/25

## K
- Keep-1
- Keep-2
- ...

## P
- Problem-1
- Problem-2
- ...

## T
- Try-1
- Try-2
- ...
```

**KPT ですが、正直言って使いにくいです**。具体的には以下二点。

- Keep はその名のとおり「続ける」ニュアンスがあり、どうしても「続けたさ」が頭をよぎります。これはとても書きにくいものです。そもそも私達は「続けたいこと」なんてあまり考えません。やりづらい！
- Problem は最も盛り上がりますが、ネガティブな愚痴大会になりがちです。生産性がありません。また気分も下がります。そして、ネガティブなことは通常、中長期的に続いているので、項目として残り続けます。ええい、うっとうしい！

### 2: YWT
使いづらい KPT の代わりに開発されたのが **YWT** です。YWT は以下の略です。

| アルファベット | 日本語 | 英語 |
| --- | --- | --- | 
| Y | Yatta（やった） | Did |
| W | Wakatta（わかった） | Learned |
| T | Tsugi-ni-yaru（次にやる） | Next |

※この略語は日本語からつくっています。**英語で名付ける DLN となるでしょう**。本記事では YWT で統一します。

Y（やった/Did）には、「やったこと」を書きます。この Y に、W（わかった/Learned）として「わかったこと」をぶら下げます。つまり、1 つの「やった」に対して n の「わかった」がぶら下がります。

「やった」と「わかった」を書いていくと、次にやることも自ずと見えてきます。それを T（次にやる/Next）として書きます。

フォーマットを示すと、たとえば次のとおりです。

```markdown
# 2025/11/25

## YW
- Did-1
    - Learned-1-1
    - Learned-1-2
    - ...
- Did-2
    - Learned-2-1
    - ...
- Did-3
- ...

## T
- Next-1
- Next-2
- ...
```

Markdown でなくてもいいですが、「やった」に「わかった」をぶら下げた方が書きやすく、読みやすいので、**少なくとも箇条書きは使った方が良いです**。

さて、YWT のメリットですが、「やったこと」から書くゆえに **圧倒的に書きやすい** ことです。やったことを雑に書いていくだけで、わかったことや次やることも思い浮かんできます。

YWT は強力です。個人の振り返りは YWT で十分です。しかし、いささか退屈でつまらないフォーマットでもあります。**飽きます**。そこで、もう少し飽きにくいフォーマットがあると便利でしょう。

### 3: 4Y
飽きやすい YWT に替わるフォーマットを開発しました。**4Y** です。4Y はは以下の略です。

| 日本語 | 英語 |
| --- | --- |
| Yaru（やる） | Will do |
| Yatta（やった） | Did |
| Yokatta（よかった） | Good |
| Yokunakatta（よくなかった） | Not good |

※この略語は日本語からつくっています。**英語で名付ける WDGN となるでしょう**。本記事では 4Y で統一します。

「やる」には、やることを書きます。TODO でもタスクでもアイデアでも、Must でも Want でも Should でも何でも構いません。ラフな TODO リストと考えればいいでしょう。「やった」には、やったことを書きます。この二つにより、未来の行動と過去の行動の両方が書かれます。この二つは X のポストや息抜きのチャットのように、こまめに書きます。もちろん後でまとめて書いても良い。

「やる」と「やった」が貯まったら、残る二つも書けます。「よかった」には、良かったことを書きます。ポジティブなことを書きます。「よくなかった」には、良くなかったことを書きます。ネガティブなことを書きます。「悪かった」ではなく「よくなかった」であることに注意してください。「否定」と「肯定ではない」は違うのです。前者は強い言葉なので気が滅入りますが、後者は比較的柔らかい言葉です。

フォーマットを示します。この例では Markdown ですが、別に何でも構いません。Markdown も意外と面倒くさいですし、エディタ上で読み書きするだけならもっと雑なフォーマットでも良いです。

```markdown
# 2025/11/25

## やる
- 直近やること
- 直近やること
- ...

## やった
- 今日やったこと
- 今日やったこと
- ...

## よかった
- 今日の良かったこと
- 今日の良かったこと
- ...

## よくなかった
- 今日の良くなかったこと
- 今日の良くなかったこと
- ...
```


さて、4Y のメリットですが、YWT と同様、やったことから書き始めるので **書きやすい** ことです。そしてその後、**良かったことと良くなかったことを自ら考えて書かないといけないため、退屈しません**。何が良いか、あるいは良くなかったかの正解はないため、あなた自身が考える他はないのです。無論、「やった」と「やる」を書いていないと、中々上手く思いつきません。

YWT よりも難しいですが、慣れたら、飽きることなく毎日続けられます。やめどきがあるとすれば、良かったことや良くなかったの言語化が面倒くさくなったとき、あるいは必要なくなったときです。その場合は YWT に戻るといいでしょう。

## おわりに
自分に関する振り返りを自分でやるという「個人の振り返り」に焦点を当て、フォーマットとして三種類紹介しました。

振り返りの力は普段仕事で散々痛感しているでしょう。個人で行うのは何とも面倒くさそうですが、フォーマットをシンプルにして、プレーンテキストベースでラフにやるなら十分可能です。個人レベルでも振り返りの力に頼れます。また、振り返りは純粋に楽しい営みでもあります。ぜひ使ってみてください。

それではまた。

---

# 軽量タスク管理には HQRST がおすすめです

## サマリー
- タスク管理にはチームタスク管理と個人タスク管理があり、本記事では後者を扱います
- 個人タスク管理の一手法として、HQRST を取り上げます
- HQRST は以下の略であり、タスクの種類に応じて、どの構造で管理すればいいかを最適化します
    - Hash（ハッシュ）
    - Queue（キュー）
    - Random（ランダム）
    - Stack（スタック）
    - Tree（ツリー）

## はじめに
まずタスク管理には二種類あります。チームレベルのタスクを皆で管理するチームタスク管理と、単に自分のタスクを自分で管理する個人タスク管理です。本記事では個人タスク管理の話をします。**以降ではタスク管理 = 個人タスク管理と考えてください**。

## 背景

### タスク管理は難しい
タスク管理を行うには、何らかの「整然としたフレームワーク」が必要であり、かつそれに愚直に従う行動力も求められます。とても難しいことです。エンジニアに限らず、社会人の 95% には到底できないことです。

たとえば GTD® を思い返してください。GTD は、言ってしまえば「9 個の箱」と「6 つの視座」を使い分けるフレームワークです。上手く使えれば日々のタスクから人生の長期的な目標、はたまた己の哲学から「やりたいことリスト」まで、すべてを死角なく、整合性を持って管理できます。しかし、解説本は数百ページにもなりますし、そもそも®であってオープンでもありません。こんなものを習得するのはほぼ不可能ですし、できたとしても、実際に毎日実行するには相当な体力とメンタルを要します。

**タスク管理は難しいのです**。ですので、現実的には、私たちは忙しい環境に身を置いて、環境の流れに従うだけでうまくいくようにします。これほど技術と方法論の整った現代であっても、未だに出社回帰が叫ばれるのも、まさにそういう理由です。余談ですが、これを **雰囲気リマインド（Atmosphere Remind）** と呼びます。環境がもたらす雰囲気が、次何するかをリマインドしてくれるわけです。

### 軽量タスク管理の出番
そこで、できるだけ軽量にして、少しでも実践しやすくすることを考えます。それが **軽量タスク管理（Light-weight Task Management）** です。

軽量タスク管理では、かんたんなフレームワークと目安だけを与えます。あとは利用者の運用に任せます。

一番わかりやすい例はポモドーロ・テクニックでしょう。実は結構重量のあるメソッドなのですが、軽量にとらえることもできます。キッチンタイマーを用意して、25分でセットして作業をし、その後 5 分をセットして休憩する――。このサイクルを繰り返すだけです。細かい運用は、皆さんの側で調整すればいい。たとえば私は、2～3サイクルごとに、長めの休憩を入れます。

## 軽量タスク管理「HQRST」
本記事では、軽量タスク管理の一つである **HQRST** を紹介します。

これは私が[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として開発したものであり、基本的なデータ構造を使います。エンジニアの皆さんであれば容易に理解できるはずです。

## HQRST の概要
HQRST では、タスクに応じて以下の 5 つの構造を使い分けます。

|  | 構造 | 用途 |
| --- | --- | --- | 
| Hash | 観点ごとの入れ物を用意する。入れ物はフラットに並べる | よく使う情報の整理 |
| Queue | 先に入れたものが先に出てくる | 緊急性はないが、必ずやりたいタスクの処理 |
| Random | 情報を一つの箱に詰める。取り出すときは常にランダムに一つずつ | 正解がないときの取っ掛かりを探す |
| Stack | 先に入れたものが後に出てくる | 割り込みタスクの処理 |
| Tree | 階層 | たまに or 稀に使う情報の保存（アーカイブ） |

### 保存系は Hash と Tree
よく使うものは Hash として、フラットに持ちましょう。それ以外は Tree としてアーカイブ的に扱います。

**よくあるアンチパターンは「よく使うものを Tree で階層的に管理したがること」** ですが、これは完全に非効率的です。しばしば整理が目的になったり、後々ノイズになります。Hash で十分です。観点ごとに入れ物を用意して、入れ物はフラットに並べる。これで十分です。これで処理できないとしたら、それはあなたの処理能力の限界だということであり、仕事量自体のコントロールに手をいれるべきです。

### タスク系は Stack と Queue
Must なタスクはよくあります。タスクには Must も Want も Should もすべて含まれますが、仕事においては「やると決めた」こと、つまり Must なタスクだけがタスクであると扱われることも多いです。

さて、Must なタスクは、どのみちやらないといけないのですから、シンプルに管理して優先順位をつけて漏れなく行うのがベストです。Stack と Queue で十分です。

具体的な運用を見ていきましょう。

基本的には先着順が望ましいです。つまり Queue で管理します。しかし、割り込んでくることがあるので、Stack に入れて管理しましょう。Stack は LIFO なので、後から割り込んできたものが先に対処されることになります。

問題はここからです。**Queue と Stack をどう組み合わせるかは、腕の見せ所です**。システム設計に携わる人なら日常的な作業でしょう。

以下は比較的単純な例です。

```
--> Stack1 --+--> Stack2 (High-prio)
             |
             +--> Queue1
             |
             +--> Queue2
```

- Stack1 は入口です
    - 割り込みも、それ以外もすべてのタスクをまずはここに入れます
    - ここは **デフォルトで空にします**。つまり、すぐにすべて処理して常に空になるよう心がけます
    - 処理するとは、後続のデータ構造に移すことです
- Stack2 は高優先度スタックです
    - ここにタスクがある場合、まずはこのスタックが空になるまで対応します
    - 🐰高優先度なタスクはここに入れて管理するわけです
    - 🐰「もし高優先度なタスクが複数来たら……？」、考えたくありませんが、その場合は、LIFO なので後から入れた方が先に対応されます
- Queue1 と Queue2 は、好きに使ってください
    - FIFO なので、先に入れたものから処理することになります
    - 🐰キューの使い分け方は各自で考えましょう。たとえば「頭を使う作業」と「それ以外」、「楽しいもの」と「楽しくないもの」、「ブルシット・ジョブ」と「それ以外」など色々考えられます

経験則として、**思っているよりも単純にした方がいいです**。このシステムを動かすのは人間である私たち自身なので、煩雑だと形骸化します。

### くじ引きに身を委ねたい場合は Random
残る一つが Random ですが、これは言ってしまえばくじ引きです。日本ではガチャ（ガチャポン）の概念があり、ランダムに何か一つ出てくるという体験は極めて日常的でありながら、ソシャゲ（ソーシャルゲーム）にも取り入れられているように巨額の富さえ生みます。

Random はただの集合（Set）構造ですが、**取り出すときは常に一つずつ、かつランダムに取り出されます**。

タスク管理では役に立たないと思いがちですが、締切や正解がないような状況で、かつ多数の「やりたいこと」や「ネタ」がある場合に重宝します。つまり、Random にネタを入れておいて、引けばいいのです。くじを引くみたいに。

## HQRST の実装
実は HQRST に相当する製品は **ありません**。

ご自身でつくってください。本記事では個人タスク管理の話をしていますから、ウェブアプリやスマホアプリほど本格的に開発する必要もありません。コマンドラインツールで十分ですし、手作業を許容するなら VSCode + Markdown ファイルなどで原始的に管理してもいいでしょう。もちろん、Tree や Queue についても、OS デフォルトのファイラーか、あるいはクラウドストレージで十分です。

タスク管理は人類の「未解決問題」でもあるため、事業化前提で HQRST のアプリをつくるのもアリかもしれません。私はオープンなので、HQRST の権利は主張しません（クレジットを出していただけると嬉しいですが）。どうぞご自由にお使いください！

## おわりに
軽量タスク管理として HQRST を取り上げました。

といっても単純な話で、Stack や Queue、Tree や Hash などエンジニアにはお馴染みのデータ構造の使い方を少し述べただけです。

私は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として、このような実用的な概念（ナレッジと呼びます）をつくっています。他にも様々な概念をつくっているので、よろしければ見に来てください。

---

# MAMA(Meeting as an AMA)
ミーティングとして AMA(Ask Me Anything) を行うことを **MAMA(Meeting as an AMA)** と呼びます。

## 概要
15 ～ 60 分のミーティングを開催しますが、内容は全面的に AMA にします。

AMA とは Ask Me Anything の略です。元々 Reddit の文化で、「私は～～ですが、何か質問ある？」という文句で人々からたくさんの質問を集めるものでした。MAMA では少し異なる使い方をします。MAMA では **回答者を一人だけ** 設定して、その人に誰でも何でも好きなだけ質問できるというミーティングです。回答者は途中で変更しません。別の回答者を設定したい場合は、新たに MAMA を開催してください。

参加人数は少人数でも大人数でも構いません。数人など少人数だと同じ人が何回も質問をして深堀りできます。逆に大人数だと、深堀りはできませんが、様々な観点の質問を出せます。

MAMA の例をを挙げます。

- 経営者が MAMA を開き、従業員からの質問を受け付ける
- 上司が MAMA を開き、部下からの悩みや相談に答える
- プロジェクトの改善担当が MAMA を開き、メンバーからの希望や要望を吸い上げるとともに、自身のスタンスや価値観を（回答の形で）伝える

## メリット
MAMA のメリットはメンバー駆動（Member Driven）であることです。

よくあるアンチパターンが上位者や推進者からの一方的な展開ですが、多くの場合、刺さりません。何なら余計なお世話ですらあります。ビジネスにおいて顧客の声が大事なように、組織やプロジェクトにおいても **メンバーの声が大事です**。そのメンバーの声を出してもらうのに、MAMA は最適なのです。

## 議論
よくある議論を Q&A 形式で整理します。

### Q: 誰も質問してくれません
Ans: ペナルティをなくしてください。またインセンティブを見せてください。

まず「下手なことを言ったら怒りますよ？」のようなペナルティがある場合、当たり前ですが誰も質問しません。

次に、ある程度の心理的安全性が確保されていたとしても、具体的な旨みがなければ「ただ面倒なだけ」ですので、やはり質問はしません。唯一の例外は「知らない情報を教えてくれる」場合であり、この状況に限定するのであればインセンティブは不要です（情報を知れること自体がインセンティブになっているため）。

しかし、質問者の目線では、実は **回答を知ることよりも、ちゃんと行動をしてくれるかどうか** を期待します。回答として、具体的な意思決定やコミットメントをしてほしいのです。回答者がそれをしてくれる、という事実と信頼こそがインセンティブになります。

### Q: MAMA に事前準備は必要？
Ans: 必要です。

誰が、どういう立場で、どういう質問を受け付けるかを事前に決めた上で、会議開催に含めてください。また少人数で深く行うか、それとも大人数で広く浅くやるのかも決めてください。前者の場合、参加人数や上限を必ず絞ってください。

開催発信については、できれば前日以前がいいでしょう。参加者（質問者）側で何を質問するか考える時間があるからです。

### Q: MAMA で質問ネタが尽きました。どうすればいいですか？
Ans: 制限時間中は続けてください。

ブレインストーミングのようなアイデア出しを思い浮かべてください。質問が枯渇しても、粘ってください。こういうときこそ重要な質問が飛び出します。むしろ、**質問が枯渇してからが本番** であり、私の経験から言っても、クリティカルな質問が飛び出しやすいです。

### Q: MAMA の途中で雑談ムードになってしまい、質疑応答のムードが途絶えてしまいます
Ans: ファシリテーションしてください。

MAMA は質疑応答に特化した場であって、**雑談の場ではありません**。ある質問を出して、それに対する回答を出す――このシンプルな構図をひたすら繰り返します。

私のおすすめはキッチンタイマーを用意することです。雑談に逸れたなと思ったら、ファシリテーター（通常は回答者です）が 30 秒タイマーをセットして、タイマーが鳴ったら強制的に質疑応答に戻します。ちなみに、30 秒以内に戻ったら、それはそれで良いです（無理に 30 秒待つ必要はない）。

### Q: 誰がいつ質問するかといったファシリテーションはどうやればいい？
Ans: ご自由にどうぞ。

MAMA の健全な目安は **沈黙が全く生じないか、ほぼ生じないこと** です。この状態を **サイレントレス（Silentless）** と呼びます。サイレントレスを保てない場合、その MAMA は未成熟です。

改めて回答を述べると、**サイレントレスになるようにファシリテーションしてください**。何もせずともサイレントレスになるのなら何もしなくていいですし、ファシリテーションが無いとサイレントになってしまうのなら形式的なファシリテーション――たとえば質問トークンを順に回したり、スタックやキューを用意して質問を募集したりといった形が必要です。

## おわりに
AMA を行うミーティング MAMA を紹介しました。

メンバー駆動的なコミュニケーションとして非常に使い勝手が良く、1on1 の代替または後継としてのポテンシャルすらあります。ぜひご活用ください。ではまた。

---

# 機能としてのマネージャー

## 背景

### DevEx は重要です
DevEx（開発者体験）とは、機械のように単に生産性を最大化することではなく、**開発者もまた人間なのだから人間としての体験を尊重するべきだ** の考え方を指します。

定義にはいくつかの派閥があり、Microsoft などビジネスが得意な会社は[タスクをこなす上での障壁の無さ](https://microsoft.github.io/code-with-engineering-playbook/developer-experience/)と考えます。私はこれは狭義だと思いますし、生産性の理から脱せてないので好ましいとも思っていません。

私は[Beyond Productivity: Embracing Experiencity](https://dev.to/stakiran/beyond-productivity-embracing-experiencity-h91)という記事を書きました。もっと広義に捉えています。

### DevRel も重要です
DevRel(Developer Relations) とは、開発者も顧客とみなして丁重に扱おう、良好な関係を築いていこうという考え方です。

元々は **外部的** でした。開発者をターゲットユーザーとした製品を開発する企業が、自社製品を末永く使ってもらい、また広めてもらうために、ユーザーと仲良くするのです。ユーザーは開発者ですから、開発者の価値観に寄り添うのがポイントです。一般ユーザーよりも情報発信と参加型イベントの比重が重くなります。ですので、まさにそのあたりを専任して行うエバンジェリストやアドボケイトが重宝します。

近年は **内部的** な DevRel も合流しています。Platform Engineering がまさに当てはまりますが、社内の開発者を顧客とみなして、丁重に寄り添っていこうと考えます。結局のところ、会社を支えるのはエンジニア達であり、エンジニア達が一番大切ですから、もっと寄り添おうというわけです。たとえば社内のエンジニアが使う API プラットフォームは、社内エンジニアという顧客を相手にしたビジネスだとみなせるわけです。

### DevEx と DevRel が合流する（DevRelEx）
私は DevEx と DevRel が合流し始めていると感じます。つまり **内部的な DevRel として DevEx の向上を目指す** のです。言葉がないと不便なので、これを **DevRelEx** と呼ばせてください。

もっとも、こんな小難しい言い方をしなくても、すでにエンジニアリングマネージャーはチームのために尽くしています。ですが属人性が高いものでした。

私はこのような「もったいない」現状を変えたくて、またスケールさせたくて[ソフトスキル・エンジニアリング](https://dev.to/stakiran/soft-skills-engineering-34mg)をつくりました。DevEx と DevRel はテクニカルな側面だけでは足りません。もう一つ、ソフトスキルが重要なのです。特にその個人そのチームその組織に合った、きめ細かい実装と運用が必要になります。これはエンジニアリングの素養を持つプロフェッショナルでないとできないのです。

さて、ソフトスキル・エンジニアとして活動する私は、DevRelEx に役立つ概念をつくりました。ご紹介します。

## 機能としてのマネージャー
**機能としてのマネージャー（Manager As A Function）** とは、マネージャーを機能とみなすことです。メンバーは機能を使うようにマネージャーを使います。**MaaF と略します**。

### Before/After
従来はマネージャーが上位者が、半ば一方的に管理を行っていたと思います。優れたマネージャーは傾聴や関係構築が得意ですが、それでも上位という立場に変わりはありません。

MaaF では逆に、DevRel らしくメンバーを丁重に扱います。メンバーのニーズを優先します。そのためにマネージャー自身は機能となって、どうぞ私をご自由にお使いください、とします。

## 機能としてのマネージャーが提供するもの
MaaF は機能として、インターフェースを提供しなくてはなりません。

たとえば次のようなものがあります。

### 1: Direct Appointment
すでに使っている組織も多いかと思いますが、マネージャーの予定表の空きに、誰でも自由に予定を追加できるようにすることです。

マネージャー側は、もし追加された予定に問題がある場合は拒否します。そうではない場合はデフォルトで承認します。

### 2: AMA と RMA
Ask Me Anything と Request Me Anything です。会議の形でも行えますし、非同期でも行えます。

詳細は以下を見てください:

- [MAMA (Meeting as an AMA) - DEV Community](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)
- [From AMA to RMA - DEV Community](https://dev.to/stakiran/from-ama-to-rma-15bb)

### 3: オフィスアワー
主に大学で教員が学生向けに使うもので、「この時間帯は開放していますのでいつでも誰でも遊びに来てください、何でもお答えしますよ」というものです。

### 4: マネージャーチケット
造語ですので少し詳しく解説します。

**マネージャーチケット** とは、「1時間で対応できる範囲で検討と回答を行う」というチケットのことです。検討と回答は非同期的に行い、回答としてはメッセージや文書やプロトタイプを書きます。マネージャーは、このチケットを必要に応じて配ります。メンバー側からチケットを提示されたら、1h を使って調査や回答をします。

マネージャーチケットの良い点は次のとおり

- 1: チケットの運用を定量的に追えるようになること
    - チケットが少なそうなら増やせばいいですし、逆に多すぎるのなら減らさなくてはなりません
- 2: DevRel の観点で、メンバー側のニーズを満たせること
- 3: DevEx にリーチしやすいこと
    - メンバー側が開発者体験の向上に関するお願いを出してくるようになるためです

### 5: メンテナンス期間
MaaF だからといって、四六時中受け付けるわけにもいきません。マネージャーにも色々仕事があります。ですので、MaaF としてのリクエストを受け付けないメンテナンス期間は **それなりに** 設ける必要があります。

典型的には、マネージャーの時間の使い方は以下 3 種類に分かれるでしょう。

- 1: 打ち合わせとして
    - 従来どおりマネージャーとして行っているもの
- 2: MaaF として
    - MaaF として、ひたすら応える時間
- 3: 個人ワークとして
    - ひとりで作業や思考に専念する時間
    - 1: も 2: も入れないのが理想ですが、割り込みにより侵食されることがあります

私のおすすめは、メンテナンス期間は最低限でも半日のスパンで取ることです。日単位で取れるともっと良いです。普段の打ち合わせと MaaF に応えるだけでは確実に病んでしまうので、主体的になるための孤独な時間が必要なのです。

## おわりに
背景として DevRelEx が来ている話をしました。

次に DevRelEx として使える道具を一つ紹介しました。機能としてのマネージャーです。そのために使えるインターフェース（窓口）の案も 5 つ整理しました。

現代は VUCA であり、DEIB であり、生成 AI の時代でもあります。変化が激しい上に正解がわからず、従業員側の水準も高くなっているという厳しい時代です。だからこそ DevRelEx の視座が求められるように思います。皆さんもぜひ意識してみてください。また MaaF を使ってみてください。それではまた。

---

# 生成AIの出力をそのまま提出する

## サマリー
- 資料の「形式のパラダイム」は次のとおり
    - 1: Formal。たとえば形式的なパワーポイントの資料
    - 2: Rough。たとえばノートアプリ、Wiki、Markdown で書いたメモ
    - 3: Mechanical。たとえば生成AIに出力させたレポートや会話ログ
- 文脈次第だが、内部での提出であればパラダイムを上げられる
    - 特に第三パラダイムの Mechanical に適応するといい
- Mechanical のパラダイムにシフトすることで資料作成・提出のスピードが上がり、したがって意思決定のスピードも上げられる

## 背景

### 重要なのは形式よりも中身
私達はなぜか資料の形式にこだわります。プレーンテキストの箇条書き 5 行で済むものを、あれこれと太らせたり着飾らせたりするのです。その結果として、皆さんもよく見かけるであろうボリューミーでノイジーな文書やスライドができあがります。

近年ではブラウザだけで読み書きを完結させるパターン――ノートや Wiki やチケットといったページにラフに書いたメモを提出する機会も身近と思いますが、まだまだ通用しないことも多い。たとえばマネージャーや顧客に見せるときは、しばしばフォーマルな形式が要求されるでしょう。下手をすると、フォーマルな形式をつくれないというだけで無能の烙印を押されてしまいます。

文脈にもよりますが、正式な提出や発表でもない限り、形式は過剰です。重要なのは中身であり、中身を最低限伝えられたらそれでいいのです。

### 形式にもパラダイムがある
資料の形式にもパラダイムがあります。

第一パラダイムは **Formal Style** で、たとえば形式的なパワーポイントや文書が相当します。

第二パラダイムは **Rough Style** で、たとえばノートアプリ、Wiki、Markdown で書いたメモなどが相当します。利便性を考えるなら、ブラウザから HTML として読めて、かつページも独立して URL が備わっている形態がいいですが、エンジニアなど慣れた仲なら Markdown ファイルでも可能です。

しかし、パラダイムはここでは終わりません。

## Mechanical Style
**Mechanical Style** とは資料形式の第三パラダイムであり、たとえば生成 AI による出力や会話ログが相当します。

つまり Mechanical Style で資料をつくるとは、生成 AI の出力をそのまま使うということです。出力をそのままチームなり、上司なり、顧客に提出します。

どちらかと言えば **生成 AI の会話ログを提出する** と考えてください。会話ログを除いた成果物そのものだけでなく、それを生成するに至った指示も資料の一部だからです。

## メリット
Mechanical Style により、資料を用いた意思決定をより加速させることができます。

## Q&A
よくある疑問に答えます。

### Q: 生成 AI の結果は信用できないのでは？
Ans: 人間の結果も信用できません。

基本的に人間だろうと、生成 AI だろうと、結果を絶対的に信用しなければならない場面は少ないです。あるいは、そういう文脈であるなら、もちろん人間による確認や洗練のプロセスを入れればいいだけです。

私達はエンジニアであり、デスクワーカーです。**仕事の大半は「情報という名のヒント」を上手く使うもの** であるはずです。情報はヒントにすぎず、その正確性やクオリティは必ずしも重要ではない。より重要なのはヒントの量と幅（種類の豊富さや多様さ）、そして何よりそれらを踏まえて、私達自身が具体的な意思決定を下すことです。

資料なんてものは、ある程度のクオリティをさっさとつくって提出すればいいのです。読み手も、情報という名のヒントだと割り切って、さっさと読んで活用すればいいのです。生成 AI は、精度の高さを除けば、すでに人間離れしています。情報という名のヒントをつくるという意味では、もはや人間は敵いません。人間が自力でつくるよりも、生成 AI と一緒にコラボレーションした方がはるかに高速かつ高品質です。

### Q: Mechanical Style の資料を読むためには何が必要？
Ans: 意思決定と慣れです。

まずは意思決定です。言われたことだけをする受身人間ではなく、情報という名のヒントを活用して「自分で」何かを決断し、行動する、との前提が必要です。意思決定できない人は、Mechanical Style の資料は読めませんし、読んだところで「じゃあ何をすればいいの？」と当惑するだけです。

このような人間（私は **Reactive person** と呼んでいます）は、単純な仕事を命令に従ってやらせるのに便利ですが、それ以外ではポンコツですし、おそらく第一パラダイムすら越えないでしょう。相手にするだけ無駄です。おとなしく第一パラダイムに従うか、どうしても嫌なら離れましょう。

あとは慣れです。ナレッジ・アーキテクトとして断言してもいいくらいですが、私達は **思っている以上に形式にとらわれています**。箇条書き 5 行で済むのに、それを受け入れようとせず、何倍にも何十倍にも膨らませたリッチな資料を好みがちです。これは特に合理的な経営者クラスの人達であっても例外無く当てはまります。

**だからこそ** 意識的に Mechanical Style な資料に触れることで、慣れていかねばなりません。といっても単純な話で、単に生成 AI を使う経験を増やしてください。ChatGPT のようなチャット型で構いません。一つの目安としては **検索エンジンへの問い合わせよりも AI に問い合わせる方が多い** かどうかが挙げられるでしょう。それくらいメンタルモデルが変化したのであれば、Mechanical Style にも慣れていると思います。

### Q: Mecanical Style でつくった資料が長ったらしくて、読むのが大変です
Ans: プロンプトを工夫してください。

それは Mecanical Style が悪いのではなく、資料の作り手（のプロンプトエンジニアリング）が下手なだけです。資料の作り方の問題にすぎませんので、作り方を変えてください、学んでください、鍛えてくださいという話になります。

---

# Minimum Main Member Principle

## サマリー
- 性能には敏感、クラウドの従量課金にも敏感、でもコミュニケーションコストには鈍感
- しかしコミュニケーションは複雑であり、減らすのは難しい
    - だからこそ端的な原則が欲しかった
- Minimum Main Member Principle をつくりました
    - 根拠と主なパターンを紹介します

## 背景

### 性能とクラウドコストには敏感なのに、コミュニケーションコストには鈍感
私達はエンジニアですので、おそらく性能には敏感だと思います。また API 利用料やインフラの稼働といったクラウドの従量課金にも敏感なはずです。（もう一つ、技術的負債もありますが、これは人次第プロジェクト次第なので割愛しましょう）

もう一つ無視できないものがあります。**コミュニケーションコスト** です。残念ながら、こちらについては技術的負債と同様か、それ以上に軽視されているように感じます。ここで一つ問いません。

> あなたは一日三時間以上、誰にも邪魔されずひとりで作業または議論に集中できる時間帯を確保できますか？

Yes の人、あるいは No だけど「二日に一回くらいなら Yes」の人は問題ありません。これ以外の場合、たぶんコミュニケーションコストがかかりすぎています。

### コミュニケーションコストを減らすための原則が必要
容易に想像できるとおり、コミュニケーションの改善は非常に複雑で難しい（ですから私は[ソフトスキル・エンジニアリング](https://dev.to/stakiran/soft-skills-engineering-34mg)を立ち上げました）。

それでも改善、特に軽減に向かうためには、シンプルでわかりやすい原則があるといいでしょう。というわけで一つつくりました。

## Minimum Main Member Principle
**Minimum Main Member Principle** とは、メインとなるメンバーを最小限に留めましょうという原則です。

- メインとは「主たる仕事として請け負っている」ことと「意思決定権を持つこと」の **両方** が当てはまること
    - 文化的にどうしても厳しい場合は片方で構いません
- 最小限とはできるだけ少ないこと、しかし上限でも自分を入れて 4 人以下であること

本当は Minimum Core Member としたかったのですが、**3M の略称** で揃えたかったので Main としました。

## 3M Principle はなぜ必要か？
コミュニケーションコストの肥大化を防ぐためです。

理想は一人ですが、一人だとバイアスがかかる点と能力や権威が偏る点がネックです。しかし、人が多いとそれだけコミュニケーションに時間がかかります。皆さんも会議や資料作成、あるいはオンボーディングやメンタリングにウンザリした経験があるかと思います。

よりわかりやすいたとえは、小説やブログ記事、その他ドキュメントの執筆です。一人でも大変な仕事なのに、これを二人で一緒につくるとしたら？と考えてみてください。三人なら？四人なら？――考えるだけで恐ろしいことです。論理的なソフトウェアの世界は、創造的ではあるけれどももう少しマシですが、それでも創造的な世界ではある。**「ひとりでつくって」「それを確認してもらう」スタイルが必須なのです**。

ですので 1 人よりは多いが、できるだけ少なく済ませるのがベストな塩梅となります。

## 3M Principle の主なパターン
3M Principle に則ったチームにはいくつものパターンがあります。

最適なパターンを各自模索してください。ここでもいくつか紹介します。

### 1: 作業者とレビュアー
- 作業者：つくります
- レビュアー：つくったものをレビューします

最もシンプルかつわかりやすいですが、レビューを終えた後（アフターレビュー）にどちらが何をするかが不明確です。

典型的にはレビュアー側が上位者であり、アフターレビューを担います。しかしティール組織の助言プロセス（上位者は助言するだけであり意思決定権はない）のように、作業者に任せるスタイルもあります。ただ、アフターレビューには影響の行使が必要ですが、[影響は権威がないと与えられないことが多い](https://dev.to/stakiran/influence-sucks-151i)ため、作業者では厳しいこともあります。

### 2: エンジニアリング、デザイン、マネジメント
- エンジニア：つくります
- デザイナー：UI、UX、その他ビジュアルを担当します
- マネージャー：マネジメントを行います

役割別の分担です。どの分野も一人で二つ以上行うのは難しい（できるなら独立できます）ので、一役割一人を据えようというわけです。

どれも難しいです。エンジニアはフロントエンド、バックエンド、SRE などフルスタックな知見が要求されます。デザイナーは GitHub や CSS などエンジニアリング寄りのツールも覚えないといけません（でないと 3M ではエンジニアの負担が大きくなりすぎて破綻します）。マネージャーはプロジェクトマネジメントとプロダクトマネジメントを両方行わねばなりません――ね、どれも難しいでしょう？

このパターンでやるなら、本格的なプロジェクトよりも PoC レベルに留めたいところです。

### 3: Worker、Helper、Advisor
- Worker：実作業を行います
- Helper：Worker を直接支援します。マネジメントも含みますが、これに限りません
- Advisor：Worker を改善・変革するための調査や検討を行い、Helper に連携します

これは私が **Worker Triangle** と呼ぶパターンです。

まず一番大事なのが手を動かす Worker であり、この人を最大限尊重します。しかし、Worker だけではまかなえない部分が出てくるので、Helper を置きます。わかりやすく言えば、Worker は直接作業、Helper は間接作業を担います。従来だと全員が直接作業も間接作業もやらされますが、そうではなく、優秀な Worker にだけ任せるイメージです。そのかわり、間接作業は Helper がやる。

次に、これだけだと改善や変革ができないので、もう一つ据えます。Advisor です。その名のとおり助言を行うのですが、対象は Worker ではなく Helper です。というのも、Worker は直接手を動かすことに特化しているので、改善や変革といった目線には弱いからです（エンジニアがソフトスキルを嫌うのと一緒です）。しかし、それでは何もできないので Helper を経由させるわけです。

```
 Worker <--> Helper <--> Advisor
```

そういうわけで、一番重要なのは Helper だったりします。Worker の事情を理解して Advisor に伝えるのはもちろん、Advisor からの先進的な提案も理解した上で、それを Worker に伝えなければならないからです。そういう意味では、Helper ではなく Transolator と呼んでもいいかもしれません。

---

# 同時にn人（nの生成AIモデル）に尋ねる

## サマリー
- 生成 AI の API 利用の話
- 複数のモデルに並列的に問い合わせすると捗る
- 発想
    - 生成 AI モデルは人のようなものであり、モデルが n 個あるとは「異なる n 人がいる」に等しい
    - n のモデルに対して並列的に問い合わせをすることで、n 人に同時に尋ねる体験ができる
    - API を並列処理で叩くことで実現できる
- 具体例:
    - pgpt.py [cosense](https://scrapbox.io/stao/pgpt.py) [Code](https://scrapbox.io/stao/za_eHAyhG)

## 背景

### 少しでも速く。少しでも滑らかに。
ChatGPT との往復は原始的であり、改善の余地があります。Copilot、Cline、Cursor などの内蔵型 AI エージェントを使っているエンジニアは、もはや原始的なコピペには戻れないでしょう。

**これは何もコーディングに限った話ではなく**、問い合わせ全般に対して言えることです。たとえば知らない用語を尋ねたり、ブレストとして 10 個挙げてもらったりする場合も、エディタや IDE からシームレスに呼び出せた方が良いに決まっています。

このように **少しでもシームレスにする** ことは非常に大事です。日々の利便性も、魔法のようなイノベーションも効率化の先にあり、効率化の大黒柱はシームレスです。少しでも手間をなくし、滑らかに使えるようにすることはエンジニアリングの本懐の一つでもあると思います。

### 並列にしよう
私はナレッジ・アーキテクトとして、発散的・創造的な仕事にあたることが多いです。だからこそ、生成 AI をいかにシームレスに呼び出せるかは生産性に直結します。

目をつけたのは並列の概念です。つまり、n のモデルに同時に問い合わせるのです。

## アプローチ

### 1: モデルを人として捉える
OpenAI API を例にします。

モデルとして、たとえば以下があります:

- GPT-4o
- GPT-4.1
- GPT-5
- GPT-5.1
- GPT-o1
- GPT-o3-mini
- GPT-o4-mini

各モデルは微妙に性質が異なります。まるで人のようです。そこで人だと捉えてしまいます。

- 4o さん
- 4.1 さん
- 5 さん
- 5.1 さん
- o1 さん
- o3-mini さん
- o4-mini さん

この場合、7 人の異なる人が存在しているようなものです。

※余談ですが、自身が使える OpenAI API モデルは [ここから確認できます](https://platform.openai.com/settings/organization/limits)。

### 2: 同時に尋ねる
この 7 人に同時に尋ねる、と考えます。

コードで示します。pgpt.py という小さなツールの一部を抜粋します。

```python
def request_to_model(model_name, prompt, timeout=130):
    try:
        response = client.chat.completions.create(
            model=model_name,
            messages=[
                {'role': 'user', 'content': prompt},
            ],
            timeout=timeout
        )
        return response.choices[0].message.content
    except Exception as e:
        return f"[ERROR in {model_name}]: {str(e)}"

def main():
    with concurrent.futures.ThreadPoolExecutor() as executor:
        future_to_model = {
            executor.submit(request_to_model, model, prompt): model
            for model in MODELS
        }
        for future in concurrent.futures.as_completed(future_to_model):
            model = future_to_model[future]
            content = future.result()
            save_response(args.input, model, content)
```

Python の並行処理を使って、**同時に** リクエストを投げています。処理を終えた人（モデル）の回答から順次保存していきます。

### 3: 同時に尋ねた分の結果を取得する
これは単純で、単に **7 人分の結果（の出力先テキストファイル）をすべて開いておく** だけです。

pgpt.py では p-gpt-4.1.md、p-gpt-4o.md のように `p-(モデル名).md` のファイル名で保存します。これを全部 VSCode で開いておきます。他のエディタでも構いません。

エディタには **外部から更新されたときに自動でリロードする仕組みがある** ので、これで十分です。**7 人同時に尋ねた結果が並列に処理され、自動で表示される** 体験が手に入ります。これで私はエディタ上でショートカットキーで即座に pgpt に尋ね、その 7 人分の結果も即座にショートカットキーで辿れます。ブラウザで ChatGPT を行き来するよりもはるかに体験が良いです。

## 余談: 個人的な感想
各人物の印象を述べておきましょう。

- 4o さんは、とにかく応答が早くて助かります
    - 創造的なタスクのクオリティは正直微妙ですが、ここ数年に出た新しい概念 **以外** の多くの情報にはすでに精通しており、わからないことは大体答えられます
- 5 さんは、応答は遅いですが密度の濃い情報を出してくれます
    - しかし Keep 4o 運動などで散々指摘されているように、温かみは皆無です。また安直にフレームワークや改善策を押し付けてくるきらいがあります
- o1 さん、o3-mini さん、o4-mini さんは、4o さんと 5 さんの間を行くバランスを持っています
    - 3 人とも微妙に異なる回答を出すので、非常に参考になります
    - 3 人分の回答を見比べれば、たいていの取っ掛かりは得られます。得られない場合は、おそらく私が未熟なだけです（プロンプトが不十分な点も含む）
- 4.1 さんは、あまり印象がありません
- 5.1 さんも、あまり印象がありません。2025/11/21 時点で新人なので、これからに期待します

## おわりに
n のモデルに並列にリクエストすることで、n 人分の意見を素早く入手する――そんな体験を実現できます。

私は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)であり、普段は概念をつくるところまでやりますが、小さなツールであればこのように実装もします。私はエンジニアとしては下手くそなので、実装はあくまで参考程度にしてください。

それよりも **「モデルを人のように扱い、かつ同時に n 人に尋ねる」** との考え方をぜひ持ち帰ってください。私よりも優秀な皆さんなら、もっと便利に実装できるでしょう。n 人同時に尋ねる体験のパワーを体感してください！

---

# 内製と内省

## 内製と内省は両方マスターしたいです

### 内製とは
**内製** とは、ソフトウェアや概念を自組織でつくることです。

内製により他組織に依頼せず、自組織で完結できるのでコミュニケーションコストを抑えられます。もちろん自社のドメイン知識も反映しやすいです。ドメイン駆動開発などという困難も少なくて済みます。仮に開発者が自社にいなかったとしても、他組織に任せるよりは、自組織で育成した方が安上がりだったりします。

### 内省とは
次に **内省** とは、自身について一人で振り返りを行うことです。

内省により自分の現状や信念を無視することもなく、また殺すこともなく、純粋に向き合えるようになります。実際にどこまで尊重できるかは現実の制約とあなたの力量次第ですが、それでも全く内省しないよりははるかにマシです。内省しない人の末路は悲惨です。特定個人か、組織か、あるいは資本主義の奴隷になるだけです。稼げるかもしれませんが、エンジニアとしての体験は削がれます。そのような現状を「仕事だから」「そういう立場だから」などといって正当化します。

### 両方手に入れたい
エンジニアとして、またエンジニアリング組織としても、両方手に入れたいものです。

内製ができないとコミュニケーションコストに忙殺されます。私達の本懐はコミュニケーションではなくエンジニアリングのはずです。

内製ができないと自分を保てずに奴隷化します。エンジニアは創造的なはずですが、ただの「作業員」あるいは「忙しいビジネスマン」に成り下がってしまいます。

これらを回避したいのなら、内製と内省を手に入れる必要があります。

## 内製が苦手な日本、内省が苦手な欧米
現状を振り返る意味でも、国ごとに整理しましょう。結論を言うと、日本は内製が苦手です。欧米は内省が苦手です。

### 日本は内製が苦手
内製は欧米では当たり前の価値観でしょう。ユーザー企業にエンジニアが属しており、自社に関する開発を任せられます。

一方、日本では **ユーザー企業にエンジニアがいません**。代わりに、SIer という専門組織に依頼します。もちろん費用は高額になりますし、コミュニケーションコストも甚大ですし、自社のドメインに合った製品なんてつくれるはずもありません。どころか中抜きなどという悪しき文化もはびこっており、下請けが n 重に重なっていてマージンを引いていきます。日本がその勤勉性にもかかわらず、IT 後進国なのも、間違いなくここに原因があります。

現在、日本では内製を手に入れる機運が盛り上がっています。特に DX やローコード、ノーコードの文脈に絡めて議論されます。自社をデジタル前提に変革するためには、自社のドメインをよく知る人物自身が開発できなければならない。しかし一からエンジニアを育成するのは大変だ。そこで比較的習得しやすいローコードやノーコード、もちろん最近では生成 AI が使えるぞ、という言説です。

### 欧米は内省が苦手
一方、欧米は内省が苦手です。たとえば毎日仕事の日記を書いたり、週末に半日以上の孤独な時間を確保して自由な思索と活動を楽しんだりといったことはしないでしょう。

というより、できないのです。**文化的に孤独に慣れていない** せいで、そういう発想すら抱けません。強いて言えば内向的なナードなら可能でしょうが、現代では少数派です。エンジニア全体の数 % 未満でしょう。

幸いにも孤独の価値、もっと言うと内省の価値は先人が残しています。私達エンジニアの界隈にもいくつか持ち込まれています。いわゆるマインドフルネスや瞑想はまさにそうです。禅の概念を見かけたことのある人も多いでしょう。Google など一部の大企業が率先したこともあって、今ではソフトスキルの一部に含めていいくらいに広まりましたが、正直言ってまだまだです。真に孤独な時間を **恒常的に** 確保できない限り、内省ができているとは言えないのです。

## 必要なのは経営陣の投資
内製にせよ、内省にせよ、取り入れるためには投資が必要です。内製の場合は IT 人材を育成または雇用するための予算が必要ですし、内省の場合は全従業員に孤独な時間を取ってもらうための教育と啓蒙が必要です。

いずれにしても個人の力やボトムアップの思索でどうにかできるものではなく、トップダウンで一気に推進しなければスタートラインにも立てません。ということは、それだけの力を持つ経営陣がやるかどうか次第なのです。もっと言えば、経営陣が内製や内省の価値を知っていなくてはなりません。

## ナレジャーの出番
[ナレジャー](https://dev.to/stakiran/what-is-knowledging-2229) とはエンジニアとマネージャーに代わる、第三の役割であり、ナレッジをつくったり広めたりする責務を持ちます。

この「内製と内省」という言い方も、まさに私がナレジャーとして言語化したものです。ナレジャーであれはこの程度は造作もないことです。また、エンジニアやマネージャーに変わって、これらの概念を教育・啓蒙することもできます。人を扱うマネージャーにも、ソフトウェアを扱うエンジニアもできないことですし、もちろん会社を扱う経営者にもできないことです。**ナレッジを扱うナレジャーだからこそできることです**。

私はこれを **ナレッジの自製** と呼んでいます。ナレッジがわかりづらければ概念でも構いません。概念の自製です。自社にナレジャーがいると、このように概念をつくったり広めたりといったことが行えるようになります。

## おわりに
内省と内製について整理しました。いずれにせよ経営者による投資が必要不可欠であり、経営者含め、このような概念をつくったり広めたりする役割が必要です。ナレジャーなら可能です。

---

# セレンディピティと変革が欲しいなら、「文字通りの新着」を

## サマリー
- 真の意味での新着情報を得るのは難しい
    - プラットフォーム側が妨害してくるし、私達にもバイアスがあるから
- だからこそ、意図的に文字通りの新着を手に入れる動きを取り入れたい
    - セレンディピティにもつながりやすい
    - 変革のヒントも見つかりやすい
    - もちろんゴミも多く、キャッチアップするのは疲れます
- この問題はエンジニアも他人事ではなく、だからこそ文字通りの新着を飼い慣らせると強い

## 背景

### インプレッション競争は至るところで見られます
あらゆるプラットフォームのあらゆる検索機能において、「新着」コンテンツを探すことは困難です。なぜかというとサポートされていないからです。あるいは、一見サポートされているように見えても、厳密に新着コンテンツを更新日時降順で表示されることはありません。

ではなぜサポートされていないかというと、インプレッションを稼げないからですね。YouTube、Tiktok、あるいはこの DEV Community でもいいですが、あらゆるプラットフォームは「より注目されやすいコンテンツ」を優先的に扱った方がインプレッションが伸びます。ですので、**文字通りの新着** は軽視されるか、無かったことにされます。

### 同じ顔ぶれの、似たようなコンテンツ
皆さんもうんざりしていませんか。私達が日々目にするのは、同じような顔ぶれによる、同じようなコンテンツばかりです。もちろん、プラットフォームが選ぶ顔ぶれは優秀な人が多く、有益なコンテンツも多いですが、それでも明らかに偏りがあります。

多様性が足りません。これではセレンディピティも変革も生まれにくい。なぜなら両者はどちらも **既存の規範からは外れたところにある** ことが多いからです。わかりやすく整備された道ばかり歩いていては未知は見つかりません。

## 文字通りの新着
**文字通りの新着（Newest Literally）** とは、新着コンテンツを厳密に更新日時降順で表示することです。

これにより、文字通りに新着が表示されるので、利用者は新着コンテンツを探索しやすくなります。もちろん新人の大半はベテランや注目ユーザーよりも弱いので、大したコンテンツがないことが多いですが、それでも原石はあります。そもそも何が役に立つかは人によって違うし、タイミングによっても違う。文字通りの新着にリーチできることは、セレンディピティや変革（のヒント探索）の観点からは非常に有益なのです。

### 例
文字通りの新着は私が言語化した概念ですが、昔からこれを得意とした国があります。日本です。

ブログサービスで言えば、[はてなブログ](https://hatena.blog/)と[note](https://note.com/)は、どちらも文字通りの新着を実装しています。ですので全く無知の素人も、コンテンツさえ優れていれば見出されることがあります。

## エンジニアと「文字通りの新着」
本題に入りましょう。

文字通りの新着は私たちエンジニアにとっても無関係ではありません。

### あなたもフィルターバブルの中にいる
あなたはエンジニアとして、普段どのようにして情報収集をしていますか？おそらく権威によるフィルターがかかっているはずです。上級エンジニアの発信だから読む、知り合いの発言だから見る、社外の典型的に盛り上がっている個人やイベントの情報ばかり見る、などをしているはず。もちろんプラットフォーム側でインプレッション用の小細工が働いていて知らずのうちに影響を受けています。平たく言えば、**あなたはフィルターバブルに包みこまれている可能性が高い**。

文字通りの新着という考え方があれば、あなたはバブルを取り除けます。たとえばあなたが普段使うシステムやツールで、更新頻度降順でフィルターしてみるといいでしょう。あなたに余力と、ある程度の実力があるなら、日々投稿される発言やナレッジを文字通りの新着で表示する仕組みをつくってもいいです。

無論、バブルを取り除くという発想が得られたところで、いざあなたが文字通りの新着を見たところで、役に立つ情報と出会えるかどうかは未知数です。あなたの実力とスタンスにもよります。たとえば毎日平均 30 件ずつ増えていく「文字通りの新着」を眺めてキャッチアップできるでしょうか。これは想像以上に難しいし、疲れることです。上級エンジニアでも難しいですし、個人的にはスタッフエンジニアクラスの視座を持つ人材で、ようやくできる人が増えてくるかなぁという印象です。

### メリット
文字通りの新着により、以下の恩恵が得られます。

- 普段触れない情報や視点に触れる率が上がる。そのため:
    - セレンディピティと邂逅しやすい
    - 変革のヒントが見つかりやすい、思いつきやすい
- 表立って報告されていない課題や問題が見つかる
    - 現場のエンジニアがこっそりと本質的な話を書いていたりするためです

---

# バーチャルオフィスとしてのノートやボード ～軽量バーチャルオフィス～

## サマリー
- バーチャルオフィスというと三次元のマイクラや VRChat、あるいは二次元の Gather を思い浮かべるが、これに限らない
- その名も「軽量バーチャルオフィス」
    - たとえば Miro はボード型のバーチャルオフィスと言える
    - たとえば Google ドキュメントや Box Notes はノート型のバーチャルオフィスと言える
- 軽量バーチャルオフィスは共同分報と相性が良い

## 背景

### バーチャルオフィスはバランスが良い
バーチャルオフィスの必要性が謳われています。理由は単純で、リアルとバーチャルのバランスを保てるからです。リアルで集まるのは生活上の負荷が高いです。フルリモートやフルフレックスでは、上手く集まれずにエンゲージメントが高まりません。両者の間を取るのに、バーチャルオフィスは良い選択肢です。つまり **バーチャル上で** 集まるとの塩梅を取っています。

### バーチャルオフィスの難点
しかしバーチャルオフィスツールにも難点があります。ツールの動作が重たかったり、エンタープライズレベルのセキュリティを確保できなかったり、また操作や順応が純粋に難しかったり、仕事への接続もしづらかったりします。

たとえば世界的に有名なマイクラを考えましょう。マイクラを仕事の動線にできるでしょうか？動線というのは、普段多用している場所のことです。おそらく皆さんは Slack や Teams といったビジネスチャットを使っているはずです。マイクラに移行できるか？と考えてみてください。完全移行は非現実的なので、チームやプロジェクト内のみで結構です。答えはおそらく「いいえ」でしょう。

## 軽量バーチャルオフィス

### 具体例
バーチャルオフィスの恩恵は、もう少し軽量なツールでも可能です。

**たとえば Miro は、実はバーチャルオフィスと言えます**。世界はボードですし、アバターもただのカーソルですが、バーチャルな世界でリアルタイムにやりとりできます。れっきとしたバーチャルオフィスです。あるいは Google ドキュメントや Box Notes、あるいは Notion や Cosense でもいいですが、**リアルタイムに共同編集可能なノートもバーチャルオフィスです**。ただ世界がノートで、アバターがただのカーソルであるというだけです。

また、まさに軽量なバーチャルオフィスに当てはまる製品もあります。日本の製品ですが、[Remotty](https://ja.remotty.net/) や [Teracy](https://teracy.io/ja/) です。Remotty はチーム全員の顔社員を並べた UI であり、顔写真は PC カメラにより 2 分ごとに更新されます。Teracy はスクロール不要な二次元の部屋上に各自のアイコンを表示、今何をしているかを自動で表示します（クライアントにエージェントをインストールし、アクティブウィンドウを監視することで特定します）。いずれもワンクリックですぐに会話を開始できるシームレスな会話体験を持っています。ただし本記事では割愛します。

### 定義
このような軽量なバーチャルオフィスを **軽量バーチャルオフィス（Light-weight Virtual Office）** と呼びます。

## メリット
軽量バーチャルオフィスのメリットは、次のとおりです。

バーチャル上で集まる（Virtual Gathering）体験を現実的に実現できるため、リアル派またはバーチャル派のいずれかに偏る必要がなく、人材の多様性を保ちやすいこと。 

## おすすめは共同分報
軽量バーチャルオフィスにはノート型とボード型があると書きました。

では具体的に、これらを普段からどのように使っていけばいいでしょうか。私がおすすめするのは **共同分報（Daily Park）** です。一言で言えば、

- 一日一つのノートやボードを作って、
- メンバー全員がそこに集合して、
- 各自のエリアをつくった上で書き込んでいく

という営みです。

以下、順を追って説明していきます。

### まずは分報について
まず日本では Slack を使った **分報（Times Channel）** の文化があります。一人一チャンネル（`#xxxx-times`）をつくって、X のようにあれこれポストするのです。誰でも見に来れますし、参加してコメントもできます。

欧米の方は理解しづらいかもしれませんが、日本はハイコンテクストな文化であり、率直なコミュニケーションが苦手です。意見も出づらいです。そこで各自のスペースをつくって、自由に書いてもらうことで、出してもらうのです。

### 分報のデメリットは「アクセスのしづらさ」
単純な話、7 人チームの場合は 7 つのチャンネルが乱立することになります。マネージャーを覗くと 6 人です。マネージャーは 6 人分のチャンネルすべてに参加して、こまめにチェックしなければなりません。大変ですね。

これの進化系が、言うまでもなく X ですが、チーム内の範囲で X のような SNS を実現するツールはありません。さてどうしたものでしょうか。

### そこで軽量バーチャルオフィスを使って、一工夫する
軽量バーチャルオフィスの出番です。

次のようにします。

- 一日一つ、ノートやボードをつくります
    - たとえば今日が 2025/11/23 なら、2025/11/23 という名前のノートやボードをつくります
    - これを **デイリーエリア** と呼びます
    - 以降では **ノート型を例にして説明します**
- デイリーエリアにメンバー全員が集まり、各自のスペースを設けます

以下は擬似的な例ですが、🐶さん、🐱さん、🐏さん、🐵さんの ４ 人のスペースがあります。

20251123.md

```markdown
# 🐶
（🐶さんはここに何でも書き込む）

# 🐱
（🐱さんはここに何でも書き込む）

# 🐏
...

# 🐵
...

```

コメントを促進したいなら箇条書きが良いです。箇条書きは行指向的であり、行単位で割り込みできるようになるので便利です（★の部分）。

```
# 🐶
- 🐶さんのコメント
    - 🐶さんのコメント
    - 🐶さんのコメント
        - 🐱さんのコメント ★
- 🐶さんのコメント
    - 🐵さんのコメント ★
- 🐶さんのコメント

```

各行でも「誰が書いたか」が知りたいので、絵文字を割り当てましょう。以下は一例です。🐶さんのエリアでありながらも、どの行で誰が発言したかが一目瞭然です。

```
# 🐶
- This is the worst, I forgot to bring my lunch...
    - 🐱 Oh my God
    - 🐏 How about we have lunch together today?
        - 🐶 Sounds good
        - 🐱 Nice, can I join too?
        - 🐏 Of course!
- I see potential in ChatGPT Atlas
- ......
```

いかがでしょうか？

このやり方なら、毎日デイリーエリアが動線になります。みんなが自然と集まり、各々書きたいことを書いて、それを皆が読むような世界観になります。リアルほど拘束が強くありませんし、バーチャルのように繋がりがないわけでもありません。リアルタイムな編集という形で各自の存在感と情報がわかる程度の塩梅であり、静かすぎず、うるさすぎない、バランスの良さだと考えます。

もちろんテキストとして残っているので、生成 AI に与えて洞察を導くこともできます！

## おわりに
軽量バーチャルオフィスとして、ノートやボードをバーチャルオフィスとして使う考えを紹介しました。特にノートによる例を深堀りしました。

---

# Online meeting sucks!
[Collaboration sucks - by Charles Cook](https://newsletter.posthog.com/p/collaboration-sucks) は良い記事です。コラボレーションの名のもとにマイクロマネジメントするな、フィードバックは成果物に対して行えよ、を強調しています。

もう一つ、最悪なものがあるので、私の方が取り上げておきましょう。オンラインミーティングです。

## オンラインミーティングでは出社をなくせない
当たり前のことですが、Slack よりもオンラインミーティング、オンラインミーティングよりも対面ミーティングの方が良いに決まっています。単純な話、シームレスだからです。エンジニアの皆さんは開発環境やエディタという形で、シームレスであることがいかに重要であるかを知っているはず。コミュニケーションも同じです。

Slack のようなチャットにせよ、Zoom のようなオンラインミーティングにせよ、どちらも対面ミーティングの下位互換でしかありません。主にパンデミックにより対面で会話できなくなったので、その代替として下位互換的なソリューションをつくって凌いだに過ぎません。

構造的に **対面ミーティングが最も良いことは明らか** です。ですので、**チャットやオンラインミーティングに頼っている限り** は 出社回帰は必然的に起こります。誰だってシームレスな方がいいですから。

## ミーティングの限界
そもそもミーティングの良くない点は何でしょう。

別にミーティングそのものが悪いと言っているわけではないのです。良いことはありますし、完全にゼロにするのは非現実的です。ただ **現状はあまりにも乱用されすぎている**。一つの手段に依存しすぎなのです。

**ミーティングは本質的に高コストです**。私は拘束と呼んでいますが、時間と場所と話題を拘束します。もちろん拘束されにいく前と、拘束から解放された後とで二回ほどコンテキストスイッチングも起こります。割り込みとは違って「事前に計画されている」、特に「定期的にセッティングされている」場合は多いですが、そのせいで深く集中できません。

こんなもの、最悪以外の何者でもないでしょう。できるだけ使わない方がいいに決まっています。それでも多用してしまうのは、他に手段がないからです。昔はそうでしたが今は違います。様々な技術や、方法や、道具があります。

## ミーティングのモデルから脱さないといけない
私達エンジニアであっても、まだまだミーティングに依存しています。この原始的で高負荷なモデルから脱さないといけません。

ヒントはすでに数多くあります。私も Full-Four の形で整理しました。

- [Full-Four: Full Remote, Full Flex, Full Async, Full Mask - DEV Community](https://dev.to/stakiran/full-four-full-remote-full-flex-full-async-full-mask-270)

私は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)であり、組織がナレッジをつくって循環させるためのお手伝いをしていますが、脱ミーティングはしばしば提案するテーマです。

そうです、脱ミーティングとは一言で言えば **情報源のパラダイムシフトを起こす** ことに他なりません。

従来ミーティングは Image Based Origin――つまり、各自の脳内のオリジナルがありました。これを同期するために密に会話する必要があり、ミーティングを使うわけです。

そうではなく、Record Based Origin――つまりは「外に出した情報」をオリジナルにする必要があります。情報共有しろとかドキュメントを書けとの形で表現されますが、そういうことです。私達エンジニアはコードやドキュメントという成果物で語ります。これに対してレビューを行います。この **アウトプット・ベースなモデルをコミュニケーション一般に適用するのです**。

そのためには非同期コミュニケーション、言語化のスキル、情報を書いたり読んだりするための道具やプラットフォーム、など多様な手段が求められます。ナレッジを扱う専門職ナレジャーの出番ですし、これを組織としてちゃんとやるために私のようなナレッジ・アーキテクトが存在します。

## 出社させたがるのはマネージャーの怠慢
先日、Ruby の父 **Matz** の記事が話題を呼びました（日本語です）。

- [Ruby父 まつもとゆきひろ「出社させたがるのは、マネジャーの怠慢でしかない」](https://type.jp/et/feature/29782/)

これも主張としては、冒頭の Collaboration sucks と同様です。また、Matz はこうも述べています。

> まあ、そういうウェットなつながりが欲しい人は、どうぞ求めてくださいって感じです。ただ、その価値観を全員に押しつけないでほしい

半分冗談混じりに述べられていますが、私は全面的に同意します。

マネージャーを始め、立場が上の者が出社させたがる理由の一つに **職権乱用** があります。自分が寂しいから、退屈だからと、これを満たすために部下を使っているのです。そんなものはプライベートで勝手に満たせば済む話です。私達は仕事上の同僚であって、友達ではない。公私混同をするな。

ジェンダーバイアス指数の低い日本では女性の扱いが不遇であり、長らく男性は自身の性欲を軽減させるために女性社員を使ってきました。たとえば制服がスカートなど露出の多いものだったり、コンパニオンとして女性社員を同席させたり、接待要員として確保したりといったことが平然と行われていました（今もゼロではありません）。これはいわば職権乱用して性欲を満たしていると言えます。**出社させたがるのも、構造的にはこれと同じです**。退屈や孤独を満たすために、職権乱用しているからです。

## おわりに
そろそろ脱ミーティングしませんか。

そのためにはオンラインミーティングから脱さないといけません。オンラインミーティングは対面ミーティングの下位互換であり、このモデルにとらわれている限りは、ミーティングはなくならないからです。

脱ミーティングというパラダイムシフトは中々に難しいですが、だからこそ取り組んでいかねばなりません。この問題は私達の多くが薄々感じていることと思います。実現できたら覇権を取れるポテンシャルさえあるでしょう。

---

# 機密情報の過保護をやめてみませんか

## 背景

### 機密情報とは
機密情報とは、ここでは **社外に出せない情報全般** を指します。従業員の個人情報や顧客の個人情報といったセンシティブなものもありますし、インサイダーに繋がるような未公開の重要情報もあれば、単に社内で決めただけのルールやプロセスもあったりします。

### 機密情報を過保護する人達
クラウドにば置けないとか、生成 AI サービスは使えないといった文句は、エンジニアなら一度は聞いたことがあるでしょう。

なぜでしょうか。本当に置けないのでしょうか？

実は、単に過保護なだけだったりします。辛辣に言えば、大したことがない情報なのに、なぜか頑なに外に出すことを拒む。まるで箱入り娘のように。

もちろん本当に出せない重要な情報やセンシティブな情報も多いですが、そうではないものも多いはず。にもかかわらず、社内で扱う情報＝センシティブ＝外に出さない、と決めつけているのです。.gitignore を知らないようなものです。過保護は非常に古典的かつ融通が利かない、悪しき文化ですらあります。だってそのせいでクラウドが使えないのですから。Webサービスが使えないのですから。

## 過保護をやめよ
機密情報の過保護はやめましょう、と提案したいです。また私が[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)としてお客様の課題に取り組む際も、高確率でこの提言を言います。

では、過保護を減らすにはどうすればいいか。かんたんな話で、次の二点です。

- 機密情報の性質や種類を言語化して分類すること
- 外に出せない「本当の機密情報」は拒否リスト的に指定すること

.gitignore と同じです。外に出したくないものを特定して、指定するだけです。この拒否リストを **保護ポリシー** と呼ぶことにします。

### 保護ポリシーの運用
保護ポリシーは二段構えにします。

- 1: 全社的に統一的に定めるもの
- 2: チーム内またはプロジェクト内で定めるもの

つまり最低限全社レベルのポリシーは存在しており、これは守らねばなりません。言い換えると、全社レベルのポリシーさえ守っているのなら、他は外に出してもいい（クラウドに置いたり生成 AI に入れたりしてもいい）わけです。

ただし、これだけだと現実的な運用ができません（チームや PJ ごとに扱う機密情報は違います）ので、個別のポリシーもつくれるようにします。それが 2: です。

ちなみに、**保護ポリシーをちゃんと機能させるには、1: の全社レベルをどれだけ緩和できるかにかかっています**。そもそも全社レベルのポリシーが厳しいものを過保護と呼んでいます。

### 顧客にも提案する
このような過保護と保護ポリシーの話は、顧客にも提案できます。というより、まともにエンジニアリングするために、ぜひとも積極的に提案して、一緒にポリシーをつくりこんでいくのが良いとさえ言えます。専門的には[ナレジャー](https://dev.to/stakiran/what-is-knowledging-2229)が担うこともあります。あるいは、ソフトウェアエンジニアが担えるようにトレーニングもできます。

顧客の過保護を軽減できない場合、その先に待つのは地獄です。過保護前提でエンジニアリングをしなければならないからです。無駄に大きな開発が発生したり、別に守らなくてもいいものに過剰なセキュリティを構築したりします。無論、コストや期間の形で膨らみますから、顧客としても印象がよろしくない。それをセキュリティだから、機密情報だから、の言い分で正当化する――。

地獄はもうコリゴリだというのなら、ぜひ過保護を軽減することを考えてみてください。

---

# エンジニアなのに感情労働をしている件
コミュニケーションは大事だという。出社回帰も再燃している。私はエンジニアとして「これでいいのか？」と思っている。

私達の本懐はエンジニアリングだ。そしてエンジニアリングとは創造的であり、創造的であるためには孤独と静寂が不可欠だ。なのに現実はどうだ。出社させられ、会議に参加させられ、テキストコミュニケーションの大半も未だにチャットなどという30年前の技術に頼っている……。

さすがにブリリアントジャークは私も勘弁してほしいが、かといって感情労働もコリゴリだ。私はエンジニアであって、エンジニアリングにフルコミットしたいのであって、チームメンバーや顧客に接客がしたいのではない。関係をつくりたいわけでもない。いや、こういうと私のわがままに聞こえるね。言い方を変えよう。「したい」ではなく「するべき」だと思っている。

いいか、接客や関係づくりは手段でしかない。必要ならやるが、少なくともメインであってはならない。メインはエンジニアリングであるべきだ。だってエンジニアリングは私達エンジニアにしかできないのだから。そもそもエンジニアリングは創造的なものだ。かんたんではない。接客や関係づくりにうつつを抜かしてる半端者にできるわけがないだろう。

最近で言えば、生成AIは良い流れだと思う。非同期テキストコミュニケーションの流れが少し戻ってきたように感じる。この調子で人間とも非同期テキストコミュニケーションができたらいいなと思う。出社回帰なんて要らないだろ。会議も要らないでしょ。エンジニアリングの素人ならともかく、私達には非同期テキストコミュニケーションで済ませられるだけの力量があるはずだ。

みんなはどう思う？私は感情労働なんてもうコリゴリだと思ってるよ！

---

# 私を雇ってください！
現在、職を探しています。私にご興味がある方は、ぜひお問い合わせください！

最終更新: 2025/12/21

## 私について
プロフィールと成果は [GitHub](https://github.com/stakiran) をご覧ください。

現在の貢献領域は DevRel と DevEx です。エンジニアリング、ライティング、知的生産の三つの専門性を掛け合わせて、開発者とマネージャーのパフォーマンスを底上げします。特に重要なのが「ソフトスキル」と「ナレッジの言語化と共有」だと考えており、新しい役割として Soft Skills Engineer や Knowledge Architect を整備しています。

直近ではプロジェクト支援の傍ら、社内におけるブログ記事発信に従事し、2 年間で 120 記事と 9000 ユニークアクセスを達成しました。これはつまり 9000 人の社員が、少なくとも一度は能動的に私の記事を読みに来たことを示します。特定プロジェクトにコミットするわけではありませんが、会社全体に広く浅く影響を与えています。

私の発信が契機となった出来事をいくつか挙げます:

- イノベーション戦略部門における Notion や Miro の採用
- システムエンジニアリング部門における IaC および CI/CD の採用
- 中途採用者向けの「社内用語解説サイト」の創設
- 非エンジニアリング部門における AI リテラシー（AI チャットボット自作）の拡大

## 私がやりたいこと
「ソフトスキルの開発」と「ナレッジの言語化」をもって、組織内の DevRel と DevEx を押し上げたいです。

## 私にできること
- 1: Internal Evangelism

全社員に対してブログ記事やドキュメントを投稿します。全社員に読んでもらい、叩いてもらうことを前提とします。

私は「既存のソフトスキルその他ナレッジをわかりやすく伝える」こと、「組織の文化や現状を言語化して伝える」こと、そして「必要に応じて新しい概念や手法をつくって届ける」ことができます。これを記事やドキュメントに載せて、たくさん届けます。

これにより全社員は「自組織の文脈に沿って表現された、有用かもしれない概念や手法」とたくさん触れることになります。各人各組織の体験向上と関係性向上に役立てられます。というより、私という「自由に揉んでもいいエバンジェリスト」が触媒となって、皆さんの利活用を起こします。

これは毎日更新を年単位で持続するほどの力を持ち、かつ全従業員の目とコメントに晒されても耐えうるメンタルを持つ私だからこそできることです。

- 2: Deep Contribution

会社、特定部門、特定チームやプロジェクトの依頼を受けて、中長期的な課題解決や問題発見を支援します。具体的には、アンサーとなる概念や手法を開発して提出します。

何らかの KPI を直接満たすことはできませんが、最初の一歩を踏み出すためのヒントをゼロからつくることができます。

通常、新しい概念や手法は「実践により検証された後で」言語化されるものですが、私は検証前に、いきなり言語化して届けることができます。それを皆さんに見せて、思考と議論により検証してもらいます。これを **概念的な仮説検証** と呼んでおり、ゼロからイチを **スピーディーに** 生み出すために必要なものです。私だからこそ可能です。

- 3: Soft Skills Engineering の整備

私ひとりでは限度がありますので、再現性を持たせねばなりません。

そのためには体系化が必要です。私はソフトスキルにエンジニアリングを持ち込んで、体系的に整理をすれば良いと考えています。Soft Skills Engineering（SSE）と呼んでいます。

すでに私はタスク管理（Task Engineering）やクリエイティブ・シンキングなど、いくつかのソフトスキルのジャンルを体系化しており、体系化の力は持っています。

## 私を雇いませんか？
DevRel と DevEx は重要です。そして開発者に限ったことではありません。組織内のエンジニアやマネージャー、その他全社員の体験と関係性の構築は急務です。しかし、ソフトスキル的なものであり、ビジネスとの相性も悪いのが現状です。

ここにメスを入れるのが私です。体験と関係性をソフトスキルによって底上げする――これによって組織は持続的に強くなり、選ばれるようになり、結果としてビジネスも拡大かつ安定します。その始まりを開拓できるのが私なのです。

ご共感いただけましたら、ぜひお問い合わせください。一緒に組織を底上げしましょう。VUCA で DEI なこの難しい時代を生き抜く、新しい組織づくりに、ぜひ私をお役立てください！

---

# 本番環境の画面は色を変えろ
開発環境、ステージング環境、本番環境――複数の環境を切り替えて使い分ける運用はよくあります。最も避けるべき展開は **開発環境で行う操作を本番環境で行ってしまうこと** です。

人間なのでミスはします。かといってチェックを強化すると普段の運用がうるさくなります。AI はまだ完全には信用できません。ではどうすればいいでしょうか。

## 本番環境の色
人間の直感に頼ります。色です。私は **本番環境の色（Production Color）** と呼んでいますが、本番環境だとわかる色を適用するのです。赤色が良いでしょう。

## つくりかた
色の変更はクライアント側（ブラウザ側）の機能を使います。[Tampermonkey](https://www.tampermonkey.net/) のようなスクリプトエンジンか、あるいは[拡張機能を個別に開発](https://tech-blog.monotaro.com/entry/2025/09/25/090000)します。

画面上のどこを変えるかは環境次第ですが、ヘッダーか全体の背景を丸ごと塗りつぶせばいいです。

もちろん AI でつくれます。環境ごとに個別につくらねばならないのは手間ですが、本番環境でミスする手間とミスしないために神経を張り詰めるストレスと比べればマシでしょう。四の五の言わずに、さっさとつくりましょう。

---

# プロジェクト vs トランスジェクト

## サマリー
- 「プロジェクト」というあり方だけではカバーできない領域があります
- 新しいあり方「トランスジェクト」をつくりました
    - プロジェクトは pro-、前に進みます
    - トランスジェクトは trans-、越境します

## 背景

### プロジェクトの時代
言うまでもなく現代はプロジェクト・エコノミーであり、仕事≒プロジェクトです。私達エンジニアも例外ではなく、ほぼ必ず何らかのプロジェクトにジョインする形となるでしょう。

### プロジェクトでは横断できない
プロジェクトというあり方には限界があります。まず **横断的に立ち回れません**。自分が属するプロジェクトに関することしかできないからです。当然ながらプロジェクト外の支援もしづらくなります。プロジェクトは、実は階層的組織よりも強いサイロになっていることがあります。

### プロジェクトは人材コストがかかる
もう一つ、プロジェクトは人を選びますので人材コストがかかります。具体的には、

- メンバーとして合う人と出会えるまでマッチングを続ける必要がある
- コアメンバーの中に「良くない人」――たとえばブリリアントジャークのような――がいた場合に、メンバーが定着しない
- 密に過ごすため、純粋な実力よりも「人間的な相性」が要求されがち
- 炎上プロジェクトの場合、人月の神話により多数の人材を投入しようとしてしまう
- プロジェクトは本質的に管理を行うものであり、管理を行えるマネジメント人材が必要、かつ管理の作業や会議に相当な時間を費やす必要がある

などです。

### 新しいあり方が必要
このとおり、プロジェクトは実は万能ではありません。新しいあり方が必要でしょう。

## トランスジェクト
**トランスジェクト（Transject）** とは、プロジェクトに変わるあり方です。

プロジェクトは Pro- のとおり、前に進めるために管理と集中に徹していますが、トランスジェクトは違います。トランスジェクトは Trans- の接頭辞のとおり、越境を前提としています。特定のプロジェクトにジョインすることはなく、全社員を幅広く支援します。

DevEx や DevRel など、社内の開発者を顧客とみなして真摯に取り組む例が増えてきましたが、このようなものを一般化したものだと考えてください。現在のところ、DevEx や DevRel もプロジェクトベースで遂行されているかと思いますし、たしかにプロジェクトも必要ですが、それだけでは実は不十分です。プロジェクトという制約の強いあり方がそもそも間違っています。

### プロジェクト vs トランスジェクト
違いを比較していきましょう。

- 1: 永続性

プロジェクトには終わりがあります。**トランスジェクトには終わりがありません**。トランスジェクト・メンバーは、その都度できることややるべきことを自分で考えて動きます。あるいは要求に応えます。

- 2: 計画性

プロジェクトは本質的にウォーターフォールであり、計画をつくってそのとおりに動きます。破ってはならない締切が事実上存在することも多いです。しかし **トランスジェクトには計画も締切もありません**。もちろん、羅針盤や説明責任のためにラフなものをつくることはありますが、絶対ではありません。

- 3: 保証性

プロジェクトは通常、特定の成果物を保証します。これは契約として定められ、破ると組織として大きなダメージを負います。だからこそ破らないためにはデスマーチすら厭わなくなります。一方、**トランスジェクトでは成果物は保証はしません**。

- 4: 変動性

変動とはリソースの話です。プロジェクトでは予算、人員、期間といった予算は変動しません。一度決めたリソースを使い切ります。あとで追加投入したり、逆に削ったりすることもありますが、例外的です。ウォーターフォールのようなものですね。

逆に **トランスジェクトでは変動します**。トランスジェクトではミニマムリソース（許容可能な最低限のコスト）を割り当てて、その間は好き勝手に動いてもらいます。足りなくなれば足します。まるで API の従量課金やクレジット補充のようです。

### トランスジェクトは真にアジャイル
トランスジェクトを一言でいうと、アジャイルです。

アジャイルを取り入れたプロジェクトは数多いでしょうが、実は **プロジェクト自体が本質的にウォーターフォール的** なので、さしてアジャイルになりません。真にアジャイルにしたいなら、プロジェクトというあり方そのものを変える必要があります。

それがトランスジェクトです。前の vs の項で比較したように、プロジェクトがいかにウォーターフォール的であるかはおわかりいただけましたよね。その対抗として、トランスジェクトがいかにアジャイルにつくられているかもおわかりいただけたはずです。ここまでしなければならないのです。

### Work and Busy から Play and Slack
プロジェクトは Work and Busy と言えます。忙しく働くことが要求されます。なぜならプロジェクトは前に進めるものであり、前に進むことが正義だからです。

トランスジェクトは、この理から外れます。Play and Slack です。余裕を持って遊びます。

### トランスジェクトがプロジェクトを支える
プロジェクト・メンバーは、前に進むことだけ考えればいい。それ以外をトランスジェクト・メンバーがやります。

プロジェクトは必要です。ビジネスですから、ストイックに前に進むことにはこだわらねばなりませんし、この大変な作業は誰かが負わねばなりません。

ですが、それだけでは足りない。プロジェクト・メンバー達の取りこぼしを回収したり、彼らを鍛えたり楽しませたり悟らせたり、そもそも組織のために中長期的な取り組みをしたりといったことも必要です。またプロジェクト・メンバーに向いてない人材もいて、このような人材を排除していては人材コストも高くつきます。だからトランスジェクトです。

トランスジェクトが広く後方で支援する。プロジェクトは狭く前線で戦う。役割分担なのです。

## トランスジェクトの例
トランスジェクトとしての具体的な役割は、必要に応じて自由につくってください。プロジェクトにおける役割ほど固定的ではありません。何なら役割名がなくてもいいです（そのうち見えてきます）。

いくつか例を示します。

### 1: Internal Evangelist
**Internal Evangelist** とは、社内での発信や啓蒙を務める役割です。テーマはエバンジェリストによって違います。私の場合、ソフトスキルになるでしょう。あるいはもっと狭く「タスク管理」「クリエイティブ・シンキング」「非同期ワーク」でも立ち回れます。

具体的な活動は三つあります。

- 1: 継続的に全社員に向けて発信をする。社内ブログなど
- 2: 問い合わせに随時回答する
- 3: オフィスアワー、勉強会や相談会、その他個別の打ち合わせ依頼に応える

あくまでエバンジェリストなので、特定の仕事は負いません。伝えるところまでやります。

### 2: Glue Work Engineer
**Glue Work Engineer** とは、その名のとおり Glue Work に専念するエンジニアです。プロジェクト・メンバーではなく、トランスジェクト・メンバーとして様々なプロジェクトに出入りします。

かんたんに見えますが、テクニカルな理解とドメインの理解、そしてもちろんプロジェクトに入り込んでコミュニケーションを取る必要もあります。向き不向きが明確に分かれるほどの、難しくてやりがいのある仕事です。

注意点として、トランスジェクトなので具体的な責任は負わないことに注意してください。つまり Glue Work Engineer が何かをこなせなかったとしても、それはそのエンジニアの責任ではない。この原則を忘れないでください。トランスジェクト・メンバーであるからこそ、Glue Work Engineer は融通を利かせた立ち回りができます。プロジェクトのように縛っては意味がありません。

### 3: [Soft Skills Engineer](https://dev.to/stakiran/soft-skills-engineering-34mg)
私が何度か伝えている役割で、ソフトスキルに関して越境的に立ち回ります。

活動は以下二つです。

- 1: ソフトスキルに関する Internal Evangelist 的な活動
- 2: 組織やプロジェクトからの要望に応えること

2: については、たとえば「形骸化しないナレッジ・マネジメント」の仕組みを考えてほしいとか、メンバーともっと深く関係を築ける手軽な 1on1 の手法を開発してほしいといったものです。最適なソフトスキルや概念を提示、もしくは開発します。

### 4: Transtester
**Transtester** とは、越境的なテスターを指します。「～～を試してほしい」といったテスト的な要望にひたすら応える役割です。Q&A エンジニアやデバッガーほどプロジェクトに入りこまず、もっとカジュアルに応えます。

プロジェクト・メンバーから見ると、「ちょっと誰かに試してほしい」「部外者の意見を聞きたい」といった場合に重宝します。あるいはアンケートやヒアリングを伴うような仕事を行う人達が頼る先でもあります。

社内には Transtester のプールがあり、プールに対して依頼をすると、中の Transtester たちが答えてくれるというイメージです。もちろん Transtester 個人に直接依頼しても構いません。

こう書くと、Transtester は「サブの」役割に思われがちですが、意外とそうでもありません。引っ張りだこなので、実は専任か、少なくともメインとして据えた方がいいでしょう。

## メリット・デメリット

### ⭕メリット
一言で言えば、**プロジェクトのあり方ではこぼれ落ちていたことを回収できます**。

例:

- Glue Work を拾えます
- 中長期的な議論や検討が行えます
- 肩の力を抜いて取り組めるので、イノベーションが生まれやすくなります
- ソフトスキルや仕組みの改善といった「通じづらいが重要な強化」を行えます
- 社内の情報共有を活性化させ、従業員の体験を上げます
    - トランスジェクト・メンバーの手によって、社内にコンテンツが溢れるようになるからです。まるでインターネットのように

### ❌デメリット
- 1: **トランスジェクト・メンバー自体は直接売上には貢献しません**

ですので無尽蔵に増やすわけにはいきません。目安としては、トランスジェクトとして働ける何らかの強み（とできれば熱意）があることです。

また、契機としては「プロジェクト・メンバーとしては合わない」「代わりの役割が欲しい」が多いと思います。従来、このような状況だと別のプロジェクトに回されていたか、最悪クビにしていましたが、この記事を読んだ皆さんには選択肢が一つ追加されました。トランスジェクトメンバーを検討してください！

- 2: **思っているよりも難しい仕事です**

見ての通り、トランスジェクトは **全社員を** 相手にします。たとえば全社員が読むブログ記事を持続的に更新したり、全社員から問い合わせが来ることを想定したりといった立ち回りは当たり前に行えないといけません。これは思っているよりも難しいことです。

また、vs の項でも述べたとおり、計画や管理も無いので、自律的に動けないといけません。サボっていないことを示すためにはアウトプットも向上的にやらねばなりません。そういう意味でも適性が分かれます。

---

# RAIS(Regular Asynchronous Information Sharing)

## サマリー
- 情報はマネージャーが握っていますが、マネージャーは出し惜しみます
- 組織やプロジェクトをもっと上手く回したいなら、日頃から情報を共有していきたいです
- そのためには「定期的に」「非同期的に」共有すれば良いです

## 背景

### 情報はマネージャーが握っている
Will Larson のスタッフエンジニア本（日本人向けインタビューも拡充した日本語版）を読みました。補章にて **組織の情報流通はマネージャーを中心に設計されている** とあり、そのとおりだと思いました。

[GitLab](https://handbook.gitlab.com/) のように、非同期ファーストかつ SSoT であらゆる情報を共有できる組織は稀です。通常は上層部の中で内密な会議が行われ、その決定事項が必要に応じて中間層や現場層にも落とされます。要は会議という原始的な手法を使っているせいで、どうしても伝達が人伝になってしまう。これは **構造的な問題** なのです。

この構造における肝がマネージャーです。中間管理職と言ってもいい。なぜ肝かというと、経営層と現場を繋ぐ存在だからです。あるいは経営層が絡まない現場の意思決定においては、事実上の王様です。彼らが情報を降ろさない限り、現場層は情報を知ることができない。

### マネージャーは情報を出し惜しむ
すべてのマネージャーではありませんが、たいていのマネージャーは情報を出し惜しみます。もしくは渡さないこともある。

これも構造的な問題であり、情報共有≒会議として伝える、と思い込んでいるからです。会議にはコストがかかります。仮にメンバーが 5 人いるとして、5 人との会議を毎回設定するのでしょうか？

よくマネージャーの立場の人から言われるのは「聞いたら答えるからオープンだ」ですが、そんなものはオープンではありません。**いつでも誰でもアクセスできるように公開して、はじめてオープンと言える** のです。

## この記事について
エンジニアリングマネージャー含むマネージャー向けに、情報の出し方をお教えします。

これにより、マネージャーであるあなたは定期的に、負担をかけないやり方で情報を共有できるようになり、メンバーの信頼を勝ち取れるでしょう。また、メンバーは情報に基づいた行動がしやすくなるので、純粋にプロジェクトも回りやすくなります。一見すると、定期的な共有の手間に顔を歪めてしまいますが、それだけの価値があるのです。

## 定期的な非同期的情報共有
**定期的で非同期的な情報共有(Regular Asynchronous Information Sharing)** とは、その名のとおり定期的に、しかし非同期的に情報共有を行うことです。***RAIS と略します**。

## RAIS の具体例
- 週に一度、マネジメント会議で決まったことのサマリーを、チャットに流す
- 週に一度、マネージャー間や上級エンジニア間で行った会議のサマリーを、メーリングリストに流す
- 毎日、その日行った会議の概要とサマリーをウィキに書き込み、その URL をチャットでも展開する

## RAIS のやり方
パラメーターを決めて、実践するだけです。

パラメーターは 3 つあいます。

- 1: 頻度
- 2: 共有する内容
- 3: 共有先

詳しく見ていきましょう。

### 1: 頻度
頻度については毎日、週一、月一などがあります。

私は **DWMY** と呼んでいますが、手元で日次で整理し、週次では日次の整理内容をもとに整理し、月次では週次の整理内容をもとに整理します。もちろん年次では月次の整理内容で整理します。このように積み上げていくことで、整理の負担が現実的になります。

逆に考えてみてください。日次や週次の整理なしに、いきなり月次で共有するとしたら？おそらく 30 日分の振り返りが必要です。大変すぎます。これが、DWMY を心がけていると（週次で整理した分を見ればいいだけですから）4～5 個で済みます。

### 2: 共有する内容
基本的には **あなたが会議して得たことのすべて** です。このすべての情報からどれだけ引き算するか、と考えてください。

どの情報が誰の役に立つかはわかりませんので、あなたの意思で選定するというよりも、なるべく広く情報を出すことを心がけてください。

内容のつくりかたですが、DWMY をおすすめします。特に日次で――つまり毎日 **その日行った会議で得たことを整理する** ことです。5 分のスロットをつくって箇条書きするだけでも構いません。無理にすべての会議について書かなくても構いません。

仮にその日 7 個ほど会議をしたのなら、理想は以下のようなリストですが、

```
- 会議1
    - 要約
    - 要約
    - ...
- 会議2
    - ...
- ...
```

会議4と5はプライベートすぎて出せないから書かない、でも別に良いのです（むしろこのような会議の内容を共有する方が問題です）。また、2-3行でもいいのです。

さて、実際に共有する内容ですが、**週次がバランスが良い** と思います。しかし週次の分をつくるためには、日次で毎日こまめにつくっておいた方がやりやすいです。人によっては週次のタイミングでまとめて振り返った方がやりやすい人もいるようです。細かい運用は各自調整してください。あなたが行うことなので、あなたがやりやすいやり方で良い。

### 3: 共有先
少なくともチームの動線となっている場所に流します。おそらく Slack などのチャットでしょう。プロジェクトによってはメーリングリストもありえるかもしれません。

チャットだと書きづらい場合は、ウィキやノートやリポジトリ（に置いた Markdown）でもいいですが、その URL を動線に流すことも忘れずに。

---

# 非同期ワークのための RAP フレームワーク

## サマリー
- 非同期ワークで仕事を回すコツはフレームワーク化
    - 「フレームワークを埋めるだけ」なら各自のペースで進めやすいし、区切りも見えやすい
    - 逆にフレームワークがないと「密な会話」で探る他はなくなる → 同期的になってしまう
- 汎用的に使えるフレームワークとして RAP がある
    - Reply。相手の発言や成果物の一部を指定して、返信する
    - Add。相手の発言や成果物には無いが、追加するべき観点を出す
    - Prune。相手の発言や成果物のうち、今現在は要らないと思われる部分を指摘する
- RAP を意識してコミュニケーションを往復すると、死角の無いやりとりができる

## 背景

### 非同期ワークは難しい
**非同期ワーク（Async Work）** は難しいです。なぜなら私達にとって、仕事の大半はコミュニケーションであり、コミュニケーションの大半は密な会話だからです。密に会話を行うことによって、お互いにリアルタイムにすり合わせていきます。

この **リアルタイムの呪い** つまり同期的なあり方に抗えるのは人間だけです。人類は技術と方法を発展させて、非同期ワークを確立しました。しかし、現状でもまだまだフル活用はされていません。GAFAM や MATANA のような企業でさえも出社回帰してしまうくらいには、この呪いは手強いのです。

### そもそも同期ワークはなぜダメなのか
単純な話、同期的な働き方は負担が高いからです。極端な話、王政のもとで奴隷のごとく一箇所に集めてこき使えば生産性は出ますが、そんなことは当たり前ですし許してはいけません。残念なことに、現在も資本主義の名のもとに平然と搾取が続いています。それを報酬とやりがいで誤魔化します。日本には「やりがい搾取」という言葉もあるほどです。

しかし生物には同期的に連携する機能しか備わっていない。だからこそ非同期ワーク――そのための手段と考え方を意識的に、厳しく使っていかなければならないわけです。

### 非同期ワークの肝はフレームワーク
非同期ワークを持続的にこなすのは難しいですが、端的なコツがあります。フレームワークを使うことです。

テンプレートと言い換えてもいいでしょう。「これとこれを埋めればいい」「ここまでやれば良い」といった **基準を設ける** ということです。これにより、各自は自分のペースで基準を満たせばいいことになります。密な会話のように、その場で頑張ってすり合わせなくてもいいわけです。基準を満たしたものを渡して、見てもらって、また埋めてもらって、を繰り返せば良くなります。

だからといって、あらゆる場面ごとにフレームワークを個別につくっていてはきりがないです。ですので汎用的なフレームワークに頼ります。これは難題ですが、私は[ソフトスキル・エンジニア](https://dev.to/stakiran/soft-skills-engineering-34mg) として一つ整備しました。次で紹介します。

## RAP フレームワーク
**RAP フレームワーク** は、非同期ワークをやりやすくするためのフレームワークです。

まずコミュニケーションを以下のように捉えます。

- **送信者** と **受信者**
    - 送信者は **コンテンツ** を送ります
    - 受信者はコンテンツを受け取り、返事を書いて送信者に返します。送信者も同様に返事を書いて、さらに受信者に返します――と繰り返します。これを **ラリー** といいます
- ラリーは複数本並行したり、分岐したりしても構いません

RAP とはラリーを返す際に使うフレームワークで、以下の三つの略です。

- R: Reply
    - コンテンツの一部を指定して、コメントを書きます
- A: Add
    - コンテンツには含まれていないが、含めるべきコメントを含めます
    - 例: 観点、議題、追加の指示や質問
- P: Prune
    - コンテンツのうち、今回は扱わなくてもいい部分を指定します
    - 必要ならそう判断した理由も添えます

つまり RAP ではコンテンツそのものに関するコメント（指摘）、コンテンツには見当たらないが追加するべき内容（不足）、コンテンツに含まれているが省いていいもの（過剰）の三点を扱います。

## 例

### 例1: コードやドキュメントをレビューするとき
RAP のうち、R については従来どおり、コメントしたい場所を指定した上でコメントを書きます。GitHub なら行単位で指定できますし、Box なら矩形で範囲選択してコメントを残せます（アノテーション機能）。また直接指定できないなら、該当部分をコピペした上で引用して書きます。

A については、R とは別の枠をつくって、箇条書きなどで書けば良いです。枠がないなら別途送信しなければなりません。できるだけ R のコメントを書く場所から離れない方がいいです。バックログなどで別途管理するのは構いませんが、このコンテンツに対してこれこれの Add を出したという事実は必ず追えるようにしてください。

P については、R と同じ形で指定します。ただし Prune であることを示す視覚的な強調があった方がいいです。私は絵文字をおすすめします。たとえばハサミの絵文字 ✂ ✄ を採用して、「この絵文字がついているコメントは Reply ではなく Prune を示す」とすれば良いです。

### 例2: Slack 上で行うようなやりとり
たとえば次のようなフォーマットを使って返事をします。

```markdown
## Reply
> 発言の一部を引用
これに対するコメントを書く

> 発言の一部を引用
これに対するコメントを書く

...

## Add
発言に含まれていないが、追加するべき話を書く。あるいは追加の質問を書く

## Prune
Reply と同じく、引用ベースで書く
```

もう少しライトなフォーマットにするなら、こうでしょう。

```markdown
> 発言
これは Reply です

> 発言
これは Reply です

> 発言
✄これは Prune です（✄がついているので Prune だとわかります）

...

Add:

- 追加したい議論その1
- 追加したい議論その2
- ...
```

Slack 上でいちいちこのようなフォーマットを使うことに抵抗を覚えるかもしれませんが、慣れてください。もちろん Slack でやりづらい場合は、他のコミュニケーションツールに誘導しても構いませんし、普通はそうなります。たとえば [QWINCS](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb) ですね。

私の感触では、**Slack のようなチャット上で RAP フレームワークを採用できるかどうか** が分かれ目と感じます。この程度ができない組織に、非同期ワークを定着させるのはほぼ不可能です。別の言い方をすると、非同期ワークを定着させるには、これくらいの手間とメンタルモデルの変更が必要だということです。

### 例3: 1on1 その他対面で行うような雑談
まず純粋に非言語コミュニケーションを行って関係性を深める目的があるなら、RAP でも代替できませんので、素直に同期コミュニケーションをしてください。

しかし、情報のやりとりや議論や合意形成がしたいだけであれば、RAP でも足ります。**対面で交わす情報を全部テキストに落として、RAP でやりとりすればいいだけ** だからです。

## おわりに
非同期ワークを上手くやるために、RAP フレームワークを紹介しました。

RAP はシンプルですが、これを採用できるかどうかが分かれ目です。シンプルですが、同期ワークとは何もかもが違うのでかんたんではありません。それでも、非同期ワークがしたいなら試してください。練習してください。フルアシンクの道も一歩から。

※もちろん非同期ワークが常に正しいと言っているわけではありません。ただし、現状はまだまだ非同期ワークが軽視されていますので、もっと勉強してはどうですか、投資してはいかがですかと勧めています。

---

# Rapid Q&A

## サマリー
- 社内の Q&A は数の力で解決しましょう
    - 全社員が参加するチャットチャンネルを一つつくり、誰でも質問・回答できるようにします
    - これだけで解決します。ね、簡単でしょう？
        - 細かい実装や運用は手強いですが、どうとでもなります
- ただし大企業の話です。従業員は少なくとも 1000、できれば 10000 以上欲しいです

## 背景

### Q&A は未だに開拓されていないジャンル
コミュニケーションツールとして [QWINCS](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb) があります。Q&A、Wiki、Issues（Ticket）、Notes、Chat、Sticky boards（Digital Whiteboard）の略です。

この中で唯一、ビジネスレベルで成功していないのが Q&A です。Q&A というと Quora、エンジニアであれば Stack Overflow を思い浮かべるでしょうが、to C 向けのサービスにすぎません。たとえば to B 向けに、社内に導入するとのジャンルはまだありません。

Q&A がなぜ難しいかというと、「質問」と「それに回答できる者」とのマッチングが難しいからです。事実上、多くのユーザーを集められるインターネット上で、多くの人が回答できる「くだらない」ネタでインプレッションを稼ぐことになります。ビジネスモデルとしても広告に頼ることになるので、なおさらです。

### しかし Q&A は強力……
しかし Q&A は強力なソリューションです。質問に対する回答がぶら下がり、質問者がベストアンサーを選ぶことでクローズする――とのモデルはシンプルながら明瞭です。この概念で社内の、多くの社員を救えることは間違いない。ただマッチングが難しいだけです。

この難題を解決するために、私はシンプルな解を出しました。

## Rapid Q&A
**Rapid Q&A** とは、全社員が参加する Q&A チャンネルです。

ポイントは三点あります。

- 単一のチャットチャンネルに **全社員を** 参加させる
- 誰でも、いつでも、何でも質問してもいいし、回答してもいい
- 質問は重複しても良い
    - 過去に行われた質問かどうかは関係がありません
    - わからないことがあったらとりあえず質問すればいいですし、聞いても反応がなかった質問もまた投稿していい

これだけです。これだけで全社員という数の力に頼った Q&A を実現できます。

### なぜ実現できるか
なぜかいうと、このチャンネルは面白くなるかです。

全社員の質問と回答が集まる唯一の場所であり、流速も速いので **気になって覗きます**。質問の大半は（人によっては）初歩的なものであり、答えたくもなります。そうして盛り上がって、さらに面白い場所になります。むしろ **仕事をサボって入り浸ってしまうのを警戒したいくらいです**。

### より具体的な実装
Rapid Q&A を始めるのはかんたんです。Slack にせよ、Teams にせよ、Q&A チャンネルを一つつくって、全従業員を参加させればいいだけだからです。そこさえクリアできれば、あとはどうとでもなります。エンジニアの皆さんならなおさらです。

とはいえ、無駄に遠回りするのも馬鹿らしいので、論点を置いておきます。

- Q: Rapid Q&A のチャンネルの通知がノイジーです
    - Ans: 各自の設定で工夫してください。別にミュートしてもいいです
    - ミュート等の設定を知らない社員がいるのなら教育してください
- Q: チャンネルから勝手に抜けた人はどうすればいい？
    - Ans: 放っておいてください
    - チャンネルが面白くなってきたら、どうせ後から入ってきますし、たぶん面白くなるのでどうせ入っています
- Q: 質問する内容に制限は設けるべき？
    - Ans: はい
    - **すぐに答えが得られるような質問に絞ってください**。何らかのトラブルシューティング、不明な用語、設定や設計や実装上の疑問点、あるいは社内固有の質問などです
    - 逆に **Quora のように議論が盛り上がるようなトピックはダメです**。DEV Community でいう #discuss のようなトピックもいけません。Rapid Q&A はあくまでも質問者の議論を迅速に（数の力で）解決するものなので、議論や対話やエンターテイメントは要りませんし、むしろ排除するべきです。
        - モデレーターが欲しいところです。Rapid Q&A が成功するかどうかは、実はここを死守できるかどうかにかかっています
- Q: ベストアンサーはどうやって実現する？
    - Ans: 実装は色々考えられます
    - たとえば「質問者が✅のようなリアクションをつける」、かつ「Bot などで "✅のついたメッセージ" をアーカイブし、元のメッセージは削除する」などです
    - この感覚はわかりづらいかもしれませんが、Rapid Q&A の目的は **質問者が迅速に回答を得ること** ただ一点です。質問と回答というナレッジが貯まる、なんてことは考えません
- Q: 社員の規模はどのくらいを想定する？
    - Ans: 少なくとも 1000、できれば 10000 以上欲しいです
    - まず組織力学として、1000 人未満の会社だと「Q&A チャンネルを見る暇すらないほど忙しい人」がマジョリティになります。Rapid Q&A は機能しません。一方、10000 人に近づくほどの規模になると、組織に余裕もでてきて、むしろこのようなチャンネルがあった方が全体最適が働きやすくなります
    - ただし、テキストコミュニケーションに慣れた組織（たとえば数日くらい一度もミーティングせずにテキストだけで仕事を進められる組織）であれば、数百人以下でも機能します

---

# AMA 改め RMA

## AMA(Ask Me Anything) の亜種として RMA を開発しました
**RMA(Request Me Anything)** とは、主にマネージャーがメンバーや部下に対して「何でもリクエストしていいよ」とリクエストを受け付けるものです。

メリットは **メンバー側のニーズに応える形で貢献を最大化できる** ことです。DevEx や DevRel の観点では重要です。マネージャーが理想を押し付けるのではなく、メンバーからの要請に応える形になるので、より現実に即した形で貢献を増やせるのです。サーバントリーダー的と言ってもいいでしょう。

## やり方
同期と非同期があります。

### 同期の場合、会議として行う
- リクエストを受け付けるためだけの会議をします
- 会議はスロットで区切ります
    - 1スロット1～3分にします
    - 1スロットにつき、1人からのリクエストを一つ受け付けます
    - 1スロット内で「リクエストの説明」と「それに対する一次回答」を済ませます
- スロットをひたすら回します
    - たとえば1スロット3分で、45分の会議を行う場合、単純計算で15個のリクエストに応えられます

AMA についても似た概念をつくったので、こちらも見てください: 👉️[MAMA (Meeting as an AMA) - DEV Community](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb)

### 非同期の場合、カテゴリー分けした方がいいでしょう
非同期の場合、フリーフォーマットだと送る側も受ける側も負荷が高いので、カテゴリーに分けた方がいいでしょう。

私はひとまず **Five Category** を提案することが多いです。これは以下のとおり、主なリクエストをまとめたもので、フリーフォーマットよりは使いやすいはずです。

- 1: 承認してほしいです
- 2: 共有してほしいです
- 3: 調整してほしいです
- 4: 上申してほしいです
- 5: 回答してほしいです

1: ～ 4: については、リクエストを受けたマネージャーはそのとおりの対応をします。承認の場合は何らかのシステムで承認を出したりチャット等でその旨を書いたりしますし、共有の場合は具体的に何か情報を共有しますし、調整の場合はおそらく社内外の他の人物との接触や連携を図るでしょうし、また上申の場合はマネージャー自身の上司となる上級エンジニアあるいは経営層や組織長にエスカレーションするでしょう。それ以外は「その他」も含めて全部 5: に入れてください。これは単に回答するだけです。

Five Category のシステムは、ノーコードやローコードなどで整えるといいでしょう。たとえばメンバー向けには RMA 用のフォームを用意し、マネージャー側にはその投稿内容をチャットチャンネルに流します。反応や回答はそのチャットメッセージ上で行います。もちろん、GitHub Issues と連携しても構いません。何でもいいので、**リクエストした内容とその回答の SSoT 化は最低限行ってください**。

---

# 上級職の文脈はカレンダーに表れる

## まとめ
- 上級職の動向はブラックボックスですが、カレンダーは正直です、カレンダーを見ればある程度はわかります
- 手作業で見比べるのは大変なので、API で取得 → Markdown 化 → 生成 AI に投入をして分析しましょう

## 背景

### 上級職の動向はブラックボックス
マネージャーや上級エンジニアなど、上級職の動向は基本的にブラックスボックスです。上級職の間でクローズドに議論を行い、現場はその結果をトップダウンで受け取るだけです。

現場の意見を聞いたり、部分的に対話したりといった歩み寄りは珍しくありませんが、惑わされてはいけません。その後の、意思決定を伴う議論の場はおそらくクローズドであるはずです。これが政治と揶揄される所以です。政治でないのなら、透明にできるはずだからです。透明性がない時点で、その組織とその営みは政治的なのです。

### 上級者の動向は知りたい
トップダウンで受け取ってから適応するのと、その前から察知した上で備えておくのとでは初動が違います。また物理的にも精神的にも負荷が変わります。そういうわけで、**降ってくる前から動向を知れておくと多少は楽できます**。

## カレンダーを見よ
結論ですが、**上級職らの文脈はカレンダーに反映されます**。カレンダーは正直です。

あらゆる組織に当てはまるとは限りませんが、ある程度大きな組織であれば十中八九スケジュールは全社的に開放的な運用になっているはずです。たとえば MS365 を導入した組織では、全社員が Outlook の予定表を使うことができ、誰でも全社員の予定を自由に閲覧できます。何なら追加もできます。もちろん上級職の予定も閲覧できるはずです。

### まずは身近な上級職のカレンダーをウォッチする
最もかんたんなソリューションは、単に身近な上級職の予定をウォッチすることです。

一日一回、確認しておくだけでも色々と知れますし、もちろん社内通知のようにこまめに見ても良い。色々知れて面白いですが、ネットサーフィンのようにハマリすぎないようには注意してください……。

### できれば AI と連携したい
しかし手作業は面倒なので、生成 AI で分析できたらいいですよね。

発想としては単純で、以下のとおりです:

- 1: API を使って、指定した人物達の指定期間内の予定データを入手する
- 2: 1 の情報を Markdown で表現する
- 3: 2 の情報を生成 AI に渡して分析する（もちろん分析プロンプトも必要）

1 と 2 の部分も生成 AI が使えます。以下に例を示します。

```
We have an organization-wide contract with Microsoft 365. I want to retrieve the scheduled events for specified employees over a designated period.

For example, if I want to obtain the schedules for individuals A and B for November 2025, the format should be as follows:

    ```
    # (Name of A) (Email of A)

    ## 2025-11
    - 2025-11-01
        - hh:mm Event Name
        - hh:mm Event Name
        - ...
    - 2025-11-02
        - ...
    - ...

    # (Name of B) (Email of B)
    ...
    ```

In other words, create a main heading for each person, sub-headings by month, and list daily events with the event's start time and name.

I would like to create a script that generates this output.
```

具体的な実装やプロトタイプは示しませんが、このようにして上級職の文脈を分析できるようになります。動向についても、（あなたの分析プロンプトの作り方次第ですが）かなりのところまで追えるはずです。

---

# 環境にはソフト、ハード、そしてボディーがある

## サマリー
- 環境には Body もある
    - 物理的な Hard
    - 電子的な Soft
    - 身体的な Body
- Hard や Soft の設定やメンテナンスにこだわるように、Body についてもこだわった方が良い
    - Body についてこだわってない人は、Hard や Soft を素の設定で使っているようなもので機会損失が大きすぎる
- エンジニアでも Body Environment にこだわれるように、体系をつくりましたのでチラ見せします

## 背景

### 環境にこだわることの重要性は、エンジニアならわかるはず
**Hard Environment** とは、物理的な環境を指します。オフィス、自宅、デスク、ネットワークなど。

**Soft Environment** とは、電子的上の環境を指します。OSの設定、ソフトウェアとその設定、開発環境や本番環境など。

どちらも重要であり、すでに皆さんは最適な設定にこだわっていると思います。常にこだわるとは限りませんが、必要に応じてこだわるはず。少なくとも無頓着はありえない。

### 環境はもう一つあるが、軽視されがち
しかし、もう一つの環境については、なぜか軽視されています。

**Body Environment** とは、身体的な環境を指します。

……と聞いて、「うげえ」と感じた人も多いかもしれません。そうです、なぜか Body Environment は軽視されがちなのです。

### Body Environment にこだわらない人は機会損失を被っている
私はエンジニアでも、いやエンジニアだからこそ Body Environment にもこだわってほしいと考えます。

Hard Environment にこだわらない人は、安物の椅子やデスクやキーボードを使っています。Soft Environment にこだわらない人は、OS やソフトウェアをデフォルト設定のまま使っています。そういった無頓着がどれだけの損失につながっているか、想像に難くないでしょう。

別に絶対的にこだわるべしと言っているわけではなく、エンジニアの話です。エンジニアリングという高度な営みと付き合う我々エンジニアは、おそらくこだわった方が良いという前提で話をしています。

同様に、Body Environment についても、こだわらない人はそれなりに損失を被っています。もったいないことです。私は DevEx や DevRel として、この Body Environment についても扱いたいとさえ思っています。

## Body Environment Engineering
というわけで、一つ体系をつくりました。

**Body Environment Engineering** とは、Body Environment を工学として捉えたものです。私達エンジニアが――開発者もマネージャーも Body Environment にこだわるための理論と道具を整備します。

以降では Body Environment Engineering について軽く踏み込みます。Body Environment にこだわるために、どんな考え方ややり方を使えばいいのかがわかるはずです。

## Body Environment の本質は Constant Care
最初に Body Environment の本質を一言で述べておきましょう。他の環境とも比較します。いずれも CC で統一しています。

- Hard Environment の本質は Capital Configuration
    - 具体的に物理的な何かを調達・設置する
    - 物理的作業を伴うし、空間もある程度必要で準備完了までが大変だが、一度整えたら、壊れるまでは使い続けることができる
    - 物理的空間の確保と物理的作業への慣れを手に入れなければならない
- Soft Environment の本質は Continuous Customization
    - OS やソフトウェアの設定から使い方まで継続的にカスタマイズしていく運命である
        - 新しいツールや設定も積極的に試す文化がある
        - 少なくともアップデートとはそれなりに付き合う
    - 継続的にカスタマイズしていける営みに馴染めるかどうかは、エンジニアとして定着できるかどうかの分水嶺と言える
- Body Environment の本質は **Constant Care**
    - こまめに補充しなければいけない
        - 例: 水分、食事、睡眠、休憩など
    - 人間は生理的にはリズミカルであるため、リズムを安定させることが大事。そのためにはこまめに補充する、特にコンスタントに補充するのが一番良い

Hard Environment では物理的な空間と手先が必要でした。Soft Environment では継続的なカスタマイズという営みへの適応が必要でした。同様に、Body Environment ではコンスタンスに自らをメンテナンスすることが必要なのです。

## Body Environment のアプローチ
最後に、Body Environment にこだわるために用いると良いアプローチをいくつか紹介して終わります。

### 健康状態の可視化とモニタリング
- How: 健康を司る因子を測定する
- Why: 調子が良いときの因子や、調子が悪いときの因子を特定するため

システムやプロジェクトと同様、Body Environment もデータドリブンが良いです。具体的には健康を司る因子を測定します。

例:

- 睡眠時間
- 日光を浴びた時間
- 水分消費量（水筒の減り具合やコップの使用具合）
- 食事したタイミング、
- カフェインを入れたタイミング
- 20分散歩以上の運動をしたタイミング

また、値の種類としては以下があります。

- タイムスタンプ
- 回数
- 量
- `y | n`

何の因子を測定すればいいかは人次第、状況次第ですが、上手く因子を定義できたのなら健康状態を測れます。調子が悪いときの因子や、逆に調子が良いときの因子がわかります。わかったら、あとはかんたんです。悪い因子を潰し、良い因子を増やすだけです。

### 行動を取り入れる
- How: 改善対象を影響を与えるための小さな行動を設計し、実際に検証する
    - 開発の流れは設計 → 実装ですが、Body Environement Engineering の流れは設計 → 行動です
- Why: Environment を改善・強化するためには、具体的な行動が必要だから

Hard Environment や Soft Environment にこだわるために、私達エンジニアは日々手を動かします。そうでなくとも新しい技術を習得するために手を動かすはずです。

**同様に、Body Environment を改善し、強化するためにも手を動かす必要があります**。いわゆるライフハックや自己啓発のジャンルになってしまいますが、以下のようなことです。

- 睡眠時間を5時間から7時間に増やすために、ナイトルーティンを設計して試しに動かしてみる
- 	毎日朝に30分以上日光を浴びるために、毎朝30分の散歩を始める。とりあえず靴と服だけ整えてから実際に散歩してみる
- 水分の消費量を計測するために水筒を購入し、かつ飲み物も麦茶（毒やカフェインでないなら何でもいい）で統一する
    - ※麦茶はアジア圏ではポピュラーなお茶で、ノンカフェインかつ手軽に調達できるのが特徴。味が濃くて人を選びます。余談ですが私はルイボスティーの方が好きです
- SNSデトックスを行うためのツールを調達または開発して適用する

問題は **このような行動をコンスタントに行うにはどうすればいいかですが、後述のロボット化を使います**。

### ロボット化
- How: cron のようなジョブスケジューリングを自分自身に適用する
- Why: Body Environment はコンスタントにメンテナンスするのが最適だから

**ロボット化** とは、ある行動をコンスタントに行えるようにするための仕組みやスキルを整備することです。
Body Environment Engineeing における最重要概念です。一部のエンジニアは cron、その他ジョブやタスクのスケジューラーを設定したことがあるでしょう。これの人間版をやります。

主なアプローチとして習慣化、動線化、日課化、ダイナミック・リマインドがあります。

- 習慣化
    - その名のとおり、習慣です
    - 放っておいても勝手に身体が動くレベルを目指します
    - 厳しいトレーニングを必要とします。通常、外部からの強制力が必要です
- 動線化
    - ここで動線とは **毎日頻繁に通る場所** です
    - このような場所を物理的でも、電子的でもいいので確保できると、**動線上に指示を置いておけば「目に入る」ので気付ける → 実行できる** との仕組みが手に入ります
- 日課化
    - 日課とは「毎日やらないといけないが、いつやってもいいこと」です
    - 習慣も動線も合わない人には、日課が合う可能性があります
    - やり方は色々あります。単純にリストをつくってもいいですし、私は以前 [Continuous Reminding](https://dev.to/stakiran/continuous-reminding-14h1) を提唱しました
 - ダイナミック・リマインド
     - リマインダーアプリほど厳密ではないが、リマインダーの機能を持つものを指します
     - ≒人
     - 要するに同僚や同居人に話しておけば、たぶん思い出させてくれるでしょうということです！

人によって、また状況によってどれが適するかは異なるので、上手いやり方を見つけてください。

### 毒を入れない、また取り除く
- How: 原因そのものに働きかけたり、「毒を抜く期間」を設けたりする
- Why: 毒は身体を蝕むものだが、すぐには消しきれないため。長い目で見て軽減や除去していかねばならないため

私達エンジニアは毒の有害性を知っています。ブリリアントジャークや技術的負債は、今すぐ私達を破滅させることはありませんが、長い目で見て、じわじわと腐らせていきます。しかし今すぐに除去することはできず、日頃から軽減・除去していく必要がありますよね。Body Environment も同様なのです。

まず **清涼飲料水、タバコ、アルコールといった毒は摂取しなければしないほど良い** です。特にアルコールは研究の動向次第で良し悪しがブレますが、現代ではすでに「百害あって一利なし」とわかっているため毒とみなして良いです。

※もちろん気分転換や心の支えになっているという人もいますし、事実だと思いますが、私はそもそもそんな状態が好ましくないと考えます。薬物と一緒だからです。じゃあ薬物を認めていいのか、となります。必要悪ではありますし、個人が好きにすればいいですが、私達はエンジニアでありプロフェッショナルです。そうした毒に頼らずに済む方が良いに決まっている――私はそう信じています！

これらの毒はできるだけゼロに近づけてください。多くの場合、ストレスの原因そのものを軽減・除去する必要があります。原因を知るには自分と向き合わねばなりません。以下の記事を参照してください。要するに振り返りと内省です。

- [In-House Production and Introspection - DEV Community](https://dev.to/stakiran/in-house-production-and-introspection-kkg)
- [TIL in the Age of Generative AI: Writing with a Focus on Soft Skills - DEV Community](https://dev.to/stakiran/til-in-the-age-of-generative-ai-writing-with-a-focus-on-soft-skills-3k93)

次に、**普段溜まる毒については、デトックス（全く触れない時間を設ける）を使います**。このような毒は溜め続けるとバイアスの強化につながります。多様性への耐性がなくなり、かつ生活の過ごし方も無頓着になって長時間労働になりがちなので、たまにはデトックスするのがおすすめです。

例:

- デジタルデトックス
    - デジタル機器に一切触れない日を過ごす
- SNSデトックス
- チャットデトックス
    - Slack などチャットの一切触れない
- ミーティングデトックス
    - 一切ミーティングをしない

またエンジニアならプログラミングデトックス（開発その他プログラミングを一切しない）やAIエージェントデトックス（AIエージェントを一切使わない）なども有益です。

デトックスの期間ですが、最低でも半日、できれば一日以上が望ましいです。これより短いと効果がありません。

### カフェインは適正量を死守する
- How: カフェインの適正量は探り、その分量を守る
- Why: カフェインは適正量ならば健全ですしブーストになりますが、適性を過ぎると毒になる。適正量の死守が必要だから

毒の中で唯一、適正量を守れば摂取しても良いものがあります。**カフェイン** です。カフェインの概要とメリットは割愛しますが、取り過ぎでなければ頼もしい相棒となります。私も毎朝お世話になっています。

カフェインの適正量は **本当に** 人によって違うので、自分で調べるしかありません。

具体的には、次のとおりです:

- **毎日同じカップ** を使って、**毎日同じ飲料** を注いでください
- そうして **摂取のタイミングと量を測定** してください
- その上で **睡眠に支障が出ないライン** を探ってください
    - 寝付きが悪くならなかったかどうか
    - 睡眠時間が減らなかったかどうか

睡眠に支障が出るかどうかがすべてです。出ない程度にまで頻度や量を落としてください。

---

# ソフトスキル・エンジニアリング
ソフトウェア・エンジニアリングではありません。ソフトスキル・エンジニアリングです。

## 背景

### ソフトスキルは軽視されている
はっきり言います。ソフトスキルは軽視されています。いくつか例を挙げましょう:

- マネージャー以上が使うものと考えられており、エンジニアは使わない
- ビジネス臭がするし、技術的で具体的でもないため、エンジニアからは毛嫌いされがち
- ソフトスキルとして想起されるものはごく一部であり、たとえば以下の重要なスキルはほとんど扱われていない:
    - [発想法](https://dev.to/stakiran/divergent-work-using-github-2kk8)
    - タスク管理
    - 非同期コミュニケーション
    - 情報発信、情報共有、透明性の確保
    - プレーンテキストや Markdown

### VUCA で、DEIB で、生成AIな時代だからこそソフトスキルが重要
現代は難しい時代です。

- 現代は VUCA です。先が読めない上に、変化が激しい時代とされます。
- 現代は DEIB の時代でもあり、私達ひとりひとりの生活水準と基本的なリテラシーは向上しています。これを考慮しないと「選ばれない組織」になります。
- て言うまでもなく生成 AI が盛り上がっています。エンジニアリングやプロジェクトの **ボトルネックは私達人間自身です**。

このような難しい時代だからこそ、ソフトスキルが重要となります。

わかりやすい例で言うと、生成 AI の活用により、皆さんは「AIの出力を待つ」時間が増えたと思います。その間、どうやって過ごしていますか？

抽象化して言えば、皆さんは何十もの AI メンバーを管理するマネージャーのようなものです。その AI 達にお願いしたタスクの確認や、追加の依頼などはどのような優先順位で行いますか？また、頭の切り替え方や休憩の仕方も工夫せねばなりません。どうやっていますか？――このあたりの話は、ソフトスキルの一種である「タスク管理」を使うことで大部分を軽減できます。

しかし、**タスク管理というジャンルはろくに開拓すらされていないのです**。みなさんも聞いたことがないでしょう。プロジェクトにおけるタスク管理ではないですよ。自分のタスクを自分で管理する「個人タスク管理」の話です。

## ソフトスキル・エンジニアリング
ソフトスキルの重要性に伴い、この度、私は新たなエンジニアリング・ジャンルを提唱します。

**ソフトスキル・エンジニアリング** です。SSE と略します。

SSE では以下を行います。

- ソフトスキルの学習、キャッチアップ、整理
- ソフトスキルのカスタマイズ
    - **既存のソフトスキルを微修正して**、会社やチームや個人に当てはめやすくします
- ソフトスキルの開発
    - **新しいソフトスキルをつくります**
- ソフトスキル・コンテキストの整理
    - 会社やチームや個人の、現状のソフトスキルの利用状況やスタンスを **ソフトスキル・コンテキスト** と呼びます

太字に注目してください。ソフトスキル自体に手を加えたり、新しくつくったり、もちろんスキルを使う実体の現状（コンテキスト）を調べたりもしています。**SSE は専門的な営みです**。ソフトウェアエンジニアがソフトウェアを扱い、エンジニアリングマネージャーが組織や人を扱うように、ソフトスキルエンジニアはソフトスキルを扱うのです。

## 私はソフトスキルエンジニアです
さて、私はソフトスキルエンジニアです。

普段は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)を名乗っていますが、この概念は難解ですし、身近でもないためわかりづらいのです。ソフトスキルの方が伝わりやすいとわかってきたので、今後はまずソフトスキルエンジニアを名乗ろうと考えています。

### 私の成果物をご覧ください
SSE の例として、私がつくってきたソフトスキルをご紹介します。

- 私が開発したソフトスキルは、ここ DEV Community ブログにて日々お届けしています
    - <https://dev.to/stakiran>
- また、GitHub Pages でも公開しています
    - <https://stakiran.github.io/knowledging/>

## おわりに
ソフトスキルの重要性が増していると思います。この度、ソフトスキルのエンジニアリングなるものを提唱させていただきました。

皆様もぜひソフトスキルと向き合ってみてください。生成 AI に頼ってもいいですが、正直言って **生成 AI がカバーするソフトスキルはごく一部であってきめ細かくありません**。だからこそソフトスキルエンジニアが必要です。何かお困りのことがあれば、私に頼ってください。

それではまた。

---

# ソフトスキルの構成要素 6T

## サマリー
- ソフトスキルは創発的なものです
- 構成要素としては以下の 6T があります
    - 道具
        - Tool
        - Technique
        - Thought
        - Tenet
    - 行動
        - Trainig
        - Test

## 背景

### DevRel や DevEx の観点でもソフトスキルは重要
ですので私は[ソフトスキル・エンジニアリング](https://dev.to/stakiran/soft-skills-engineering-34mg)を立ち上げました。**SSE と略します**。

ソフトウェアエンジニアは最適なソフトウェアを提案し、必要に応じて現状分析から開発や改造まで行います。同様にソフトスキル・エンジニアも最適なソフトスキルを提案したり、現状を分析したり、現行のそれを改良したり、もちろん新しく開発もします。

### ソフトスキルとは何？
しかし「ソフトスキル」はイメージしづらいものです。そこで定義と構成要素を与えます。

## ソフトスキルは創発的なものである
そもそも **ソフトスキルは（というよりスキルは）創発的なもの** です。

創発とは「全体は部分の和よりも大きい」性質を指します。スーパーモジュラリティと呼ばれることもあります。創発的なものは、単純に A と B と C から成ります、のようには言えません。

ソフトスキルも同じです。たとえば「コミュニケーション」というソフトスキルを考えたとき、これが単に A + B + C + …… のように、構成要素から成るかというと No です。スキルはもっと複雑で多用で曖昧なものなのです。その証拠に、コミュニケーションの構成要素を語ってもらうと、おそらく 10 人 10 通りの答えが出るでしょう。

## ソフトスキルの構成要素 6T
創発的であるとはいっても、構成要素なるものは何かしらあるはずです。

SSE として 6 つの T で整理してみました。道具が 4 つ、行動が 2 つです。**能力の高低は扱っていないことに注意してください。**

- 道具
    - 1: Tool
    - 2: Technique
    - 3: Thought
    - 4: Tenet
- 行動
    - 5: Trainig
    - 6: Test

詳しく見ていきます。

### 1: Tool
**Tool** はその名のとおり **使う** ものです。ソフトウェアやハードウェアがわかりやすいですが、テンプレートやチェックリストといったものも当てはまります。

例:

- ソフトスキル「コミュニケーション」の Tool の例
    - Slack
    - Outlook や Google カレンダー（ミーティングを行うためのツール）
    - GitHub Issues（チケット型のツール）

### 2: Technique
**Technique** とは、やり方や手法や方法と呼ばれるものです。「言語的に記述されたステップとヒント」の集まりと考えてください。**記述されたとおりに、あるいは記述を参考にして動く** ものです。

例:

- ソフトスキル「コミュニケーション」の Technique の例
    - ブレインストーミングや OST（オープン・スペース・テクノロジー）といったワーク手法
    - [Text Based 1-on-1](https://dev.to/stakiran/text-based-1-on-1s-are-effective-328d)（1on1 をテキストコミュニケーションで行います）
    - [Rapid Q&A](https://dev.to/stakiran/rapid-qa-c83)（何百何千何万人の従業員を1チャンネルに集めて、数の力で Q&A を成立させます）

### 3: Thought
**Thought** とは、捉え方や考え方と呼ばれるものです。言語的に記述された解釈や概念と考えてください。変数名や関数名のように「何らかの構造の部品」としてつくることもあれば、まだ名前がついてないものを便宜上扱うために名前をつけることもあります。**記述されたものを理解し、議論したり、自分鳴りに使ってみたりする** ものです。

例:

- ソフトスキル「コミュニケーション」の Thought の例
    - 心理的安全性
    - [QWINCS](https://dev.to/stakiran/theres-a-limit-to-chat-tools-enter-qwincs-3cgb)（コミュニケーションツールの主な種類を整理したもので、Q&A、Wiki、Issues、Notes、Chat、Sticky boards）
    - [Dry Behavior](https://dev.to/stakiran/dry-behavior-13gl)（生成AIへの接し方はドライなものですが、これを人間にも適用します）

SSE において最も重要なのが、この Thought です。

私は **概念の仮説検証** と呼んでいますが、SSE では「動くソフトウェア」ではなく「理解できる概念」をつくって検証します。つくった Thought に対して議論をしたり、自分なりに Techunique 化や Tool 化をして試してみたりします。これは実は第三のパラダイムです。

| No. | 潮流 | 何を見せるか |
| --- | --- | --- | 
| 1 | ウォーターフォール | 計画 |
| 2 | アジャイル | 動くソフトウェア |
| 3 | ソフトスキル・エンジニアリング | 理解できる概念 |

※とはいえ概念を理解するのは難しいので、概念の理解を補助するソフトウェアの整備が急務と言えます。生成 AI が使えないかと考えています。進展がありましたら、またご報告いたします。

### 4: Tenet
**Tenet** とは、文化や力学や信念といったものです。Thought の一種と言えばそのとおりなのですが、Thought よりも根本的で変更しづらいニュアンスがあります。Tenet は **言語化して実体を理解する** ものです。

- ソフトスキル「コミュニケーション」の Tenet の例
    - 全社員に毎日出社を課す会社の文化
    - 「1on1 は必ず顔を見て話す」というマネージャーの信念
    - [「ブレストに始まりブレストに終わる」](https://www.kayac.com/vision/brainstorm)という企業文化や、GitLab が掲げる [all-remote company](https://handbook.gitlab.com/handbook/communication/) の文化

### 5: Training
ここからは「行動」に関する構成要素となります。

**Training** とは練習を意味します。ここで **練習とは「実際に動いてみる」か、あるいは「自分の理解を言語化して形に残してみる」こと** を指します。

特に **言語化という行動も練習に含めている** ことに注意してください。これは意図的であり、本質でもあります。コードや設定ファイルやドキュメントを書くのと同様に、ソフトスキル（の構成要素）についても書いてみるのです。

非エンジニアがコードを書きたがらないように、エンジニアもまたソフトスキル（の構成要素）を書きたがりません。非エンジニアがソフトウェアを試したがらないように、エンジニアもまた試したがりません。それでは前進できません。ソフトスキル面で前進するためには、書く必要があるのです。

Training は練習ですので、自分ひとりで、誰にも見せずに手元で行っても構いません。あるいは他者に見えるように公開しても良いです。いずれにせよ **ひとりで完結しています**。これより先は、次の Test で行います。

### 6: Test
**Test** とは試行を意味します。SSE としてつくった 4T を実際に試します。具体的には **自ら使ってみたり、他者に見せて反応をうかがったり、あるいは試しに使わせてみせたり** します。

SSE では **常に試行** だと捉えます。個人的に雑に試行を始めることも、チームでいったん正式に採用して使ってみることも、どちらも同じ Test と考えます。

## 改めてソフトスキル・エンジニアリングとは
以下を行います。

- New Development：新しいソフトスキルの開発
    - たとえば私は[タスク管理（タスク工学）](https://dev.to/stakiran/task-engineering-2l78)、クリエイティブ・シンキング、探索と横断（一例として[Project vs Transject](https://dev.to/stakiran/project-vs-transject-cpd)）などを扱っています
- Wide Contribution：広い範囲に向けて、おつくりした 4T や 2T を共有する。また支援の機会を提供する
    - たとえば社内全員に対してブログ記事発信、ドキュメント公開、勉強会やイベントの提供など
- Deep Contribution：狭い範囲に向けて、4T や 2T の開発や支援を行う
    - たとえば個人やチームや組織が求めるソフトスキルや 6T をおつくりします

私もまさにソフトスキル・エンジニアとして、この新しいジャンルを盛り上げたいと考えます。生成 AI 時代でもある現代だからこそ急務と考えます。ご支援が欲しい方や、私を雇いたい方はぜひご連絡ください。

## おわりに
いかがでしたか。SSE について、イメージを掴んでいただけましたら幸いです。

本記事では、まずソフトスキルは創発的なものだと述べました。その上で、構成要素として 6T があると紹介しました。道具面は Tool、Technique、Thought、Tenet の 4 つです。行動面は Traning と Test です。

---

# ソフトスキル・エンジニアリングの例
先日[ソフトスキル・エンジニアリング](https://dev.to/stakiran/soft-skills-engineering-34mg)について書きました。SSEと略します。

さて、本記事では、SSEとして私がやったことを紹介します。いずれも趣味で行ったものであり、ポートフォリオのようなものです。仕事として行う際は、さらにきめ細かく、深く、妥協無く行います。あなた個人に、あるいはチームや組織に合ったソフトスキルを開発または支援させていただきます。

では紹介に入りましょう。

## ソフトスキルの開発
いわばソフトスキルはジャンルであり、絶対的な体系こそありませんが、たとえば大カテゴリ「コミュニケーション」があり、その中に中カテゴリ「傾聴」「プレゼン力」「非同期コミュニケーション」などがあったりします。

**ソフトスキルの開発とは、新しいカテゴリーをつくること** です。大カテゴリや中カテゴリ、あるいはもう少し細かい小カテゴリをつくったりします。

私がソフトスキル・エンジニアとして得意とするのは「タスク管理」や「発想法」です。

タスク管理については、さきほど[タスク工学](https://dev.to/stakiran/task-engineering-2l78)の記事を書きました。また[タスク管理ツールの実装に役立つリファレンス](https://dev.to/stakiran/list-of-task-attributes-for-implementing-task-management-5e87)も整理しています。

発想法については、まだ体系的な整理はしていませんが、[アイデア出しを GitHub を使って行う手法](https://dev.to/stakiran/divergent-work-using-github-2kk8)など、いくつか記事を打ち出しています。

## ソフトスキルの実装支援
SSEとして最も多い仕事がこれです。何らかのソフトスキルを利活用してもらうために、具体的な概念をつくってお届けします。

たとえば「心理的安全性」を醸成するには、どうしたらいいでしょう？

私は [MAMA(Meeting As An AMA)](https://dev.to/stakiran/mama-meeting-as-an-ama-33nb) をつくりました。これは Ask Me Anything をミーティングとして行うというもので、質問者駆動と言えます。たとえば上司やマネージャーが MAMA を開催することで、部下は本当に知りたいことを知れるようになります。MAMA を通して「答えてもらえる」ことがわかるので、心理的安全性の醸成にも一役買います。

たとえば「当事者意識」をもたらすには、どうしたらいいでしょう？

私はティール組織が良い例だと考えており、[この組織モデルの本質を端的に 3P で整理](https://dev.to/stakiran/full-async-4hem)しました。ちなみに Part、Protocol、Peace です。

たとえば「振り返り」や「内省」を知ってもらうには、あるいは取り組んでもらうには何が使えるでしょう？

私は [TILS(Today I Learned Softly)](https://dev.to/stakiran/til-in-the-age-of-generative-ai-writing-with-a-focus-on-soft-skills-3k93) をつくりました。TIL をご存知の方は、ハードスキルではなくソフトスキルを書く TIL だと考えてください。生成 AI の利用も前提としています。また [内製と内省](https://dev.to/stakiran/in-house-production-and-introspection-kkg) という記事も書きました。内省が得意な日本と、内製が得意な欧米を比較することで、お互いの理解を促す試みです。

最後の「内製と内省」は（私がつくったものではなく）既存の概念ですが、もちろん使えるものは使った方がいいです、概念を新しくつくることにこだわる意味はありません。それでも通常は、顧客に合った実装支援をするためには、既存の概念では足りない事が多いです。ソフトウェアと同じですね。基本的に新しくつくることが多いです。

## ソフトスキル・コンテキストの整理
最適なソフトスキルは組織次第、プロジェクト次第です。エンジニアリングと同様、ドメインを知らねばなりません。私はソフトスキルの開発や実装支援に必要な文脈を調査・言語化し、整理できます。

例として、私が DEV Community で書いたものはまだありませんが、日本向けに書いた記事を紹介します。以下は日本の SIer 業界ついて言語化したものです（日本語です）。

- [誰も教えてくれないSIの本質、SIerの世界観 - Zenn](https://zenn.dev/sta/articles/2024-08-10-sat-what_is_si)
- [AISI - AI で SI を変革する - Zenn](https://zenn.dev/sta/articles/2025-06-12-aisi)

※SIについて補足します。日本ではソフトウェアの内製は稀であり、通常はSIer（System Integrator）という専門会社に外部委託します。日本のSIは製造業と建築業をモデルにしたものであり、現在でもウォーターフォールが根強く残っています。またコミュニケーションの介在層が多く、中抜きと呼ばれる悪しき文化も根強いです。このようにエンジニアから見ると滑稽に映る文化が多数あり、日本をIT後進国に押し留める主因だと考える識者もいます。私はこの改善のために言語化しました。

## (余談) ソフトスキル・エンジニアリングはAIでは代替できない
よくある質問が「生成AIに聞けば解決できるでしょ？」ですが、はっきりと言います。いいえ。

試しにやってみるといいですが、当たり障りのない助言か、いまいち的を得ない詳細プロセスしか返ってこないと思います。それもそのはずで、ソフトスキル・エンジニアリング自体が新しい概念だからです。生成AIもまだ十分に学習できていません。

たとえば、実装支援として新しい概念をつくりだすことができません。生成 AI は確率に基づいて、最もたしかな既存の知識やその言い換えを出力するだけです。知識量と比喩は人間離れしていますが、創造性がなく、ゆえに、きめ細かいソフトスキルの開発や支援が行えないのです。

だからこそ SSE には価値があります。今までこのようなジャンルが無かったのは、単にできる人がいなかったからです。私がパイオニアになります。

## おわりに
ソフトスキル・エンジニアリングの例をいくつか示しました。具体的には次の三点です。

- カテゴリーを新設する（新しいスキルを体系化する）
- 実装を支援する（ために具体的な概念をつくって届ける）
- きめ細かいアプローチのために文脈を言語化する

イメージが湧いたでしょうか。ご興味がある方は、ぜひ私のブログをお読みください。ソフトスキル・エンジニアとして私が日々つくったものをお届けします。

---

# ソフトスキル用のツールをつくるための Seven Lists 原則

## サマリー
- ソフトスキルを上手く発揮するにはソフト・ツールが必要
    - テンプレートやチェックリストといったソフトなツールのこと
    - ハードウェアやソフトウェアといったハードなツールではない
    - そもそもハードなツールだけでカバーできるほど、ソフトスキルは単純ではない（エンジニアはハードが好きだと思うが）
- ソフト・ツールをつくるのは難しいので、とっかかりとして 7 つの観点を与える:
    - それが Seven Lists 原則であり、以下の 7 つ

```
               Task    Span
     Trigger                  Question
            Check        Label
                   Fill
```

## 背景

### ソフトスキルに関するツールは難しい
現代はデジタルの時代であり、ソフトウェアをつくることが正義だと捉えられる節があります。しかしソフトウェアに翻訳できる事象など、ごく一部でしかありません。ソフトウェアで済むのならソフトスキルなんて言葉は要らないのです。

しかし、ソフトスキルに関する話は抽象論になりやすい。エンジニアにとっては「技術的でない」かつ「具体的でない」の二重苦です。タイトルを見るだけで逃げ出すほどのアレルギーになってしまう。

ではどうするのかというと、テンプレートやチェックリストといった「すぐに使える形の何か」をつくります。これをツールと呼びます。

わかりづらいなら、ソフトウェアやハードウェアのような実際に使う道具を **ハード・ツール**、テンプレートやチェックリストのような運用可能な言語的成果物を **ソフト・ツール** とでも呼びましょう。ソフトスキルを活用するにはソフト・ツールが必要なのです。

### ツールはどうやってつくる？
では、そのソフト・ツールはどうやってつくればいいのでしょう？

要するにテンプレートやチェックリストといったものをつくらねばならないのですが、そんなことを言われてもとっかかりが得られません。

そこで、今回はとっかかりを得るための観点をご紹介します。

## Seven Lists 原則
**Seven Lists 原則** は、ソフト・ツールを 7 種類で捉えると便利ですよという原則です。

```
               Task    Span
     Trigger                  Question
            Check        Label
                   Fill
```

ソフト・ツールをつくる際は、この 7 つのうちのどれにしたいかをまずは考えてみてください。ぴったり当てはまるか、そうでなくともヒントは得られます。

また名前には「リスト」がついていますが、リストでなくても構いません。別にマトリックスでもマップでもレフレームワークでも何でも良い。名前も、可視化の仕方も重要ではない。単に要素を並べるものという意味でリストという言葉を使っているだけです。

では、各々の詳細を見ていきましょう。

### 1: Task List
- これは何？
    - 指示を列挙します
- 読者への期待
    - 読者に従ってもらうことを期待します
- 例
    - SOP など手順書の類はここに含まれます

### 2: Span List
- これは何？
    - 期間単位（時間的な長さを持つ事柄）を並べます
    - 並べた期間単位の中に、さらに要素を置くこともあります（分類機能）
- 読者への期待
    - 期間の全体像と現状を知ってもらうことを期待します
- 例
    - ロードマップ、スケジュール、WBS

### 3: Trigger List
- これは何？
    - 発想の参考になりそうな事柄を雑多に並べます
- 読者への期待
    - 発想の助けになることを期待します
    - 各項目は使っても使わなくてもいいし、いいかげんに解釈しても良いです
- 例
    - GTD®のトリガーリスト、オズボーンのチェックリスト、SCAMPER法

### 4: Question List
- これは何？
    - 質問、特にオープン・クエスチョンを並べます
- 読者への期待
    - 質問に一つずつ答えていくことを期待します
    - 答えていくことで色々見えてきます、特に「読者自身の意思」と対峙し意思決定してもらうことを期待します
- 例
    - インタビューやサーベイ全般

### 5: Check List
- これは何？
    - Yes/No で答えられる事項を並べます
- 読者への期待
    - 指定事項が Yes なのか No なのかを確定させることを期待します
- 例
    - 割愛

### 6: Label List
- これは何？
    - 対象に付与する分類項目（ラベル）を並べます
    - 読者はこの中からラベルを選んで、対象に付与します
    - 1対象1ラベル（カテゴリー方式）、1対象nラベル（タグ方式）があります
- 読者への期待
    - 指定された分類項目を使って分類してもらうことを期待します
- 例
    - GitHub Issues のラベル、文書システムで用いるタグ

### 7: Fill List
- これは何？
    - 読者に埋めてもらう枠を並べます
    - いわゆるテンプレートです
- 読者への期待
    - 枠を埋めてもらうことを期待します
- 例
    - テンプレート全般

---

# 使いやすいファシリテーション手法 ～発言キューと発言スタック～

## 背景: ミーティングのファシリテーションは難しい
エンジニアであってもミーティングはあります。議論やレビューなど白熱するものもありますし、話題もソフトウェアの開発のみならず組織開発に及ぶことも多い。

しかし私達エンジニアはファシリテーターではない。ミーティングの品質はファシリテーションに依存しますが、そのスキルが無いのです。ゆえにミーティングの品質がブレてしまい、以下が起こります。

- 品質のブレを抑えるために「合うメンバー」を選ぶ → 採用やオンボーディングのコストがかかる
- 現場のエンジニアを議論に参加させず、マネージャーや上級エンジニアのみで行う → 現場に伝えるコミュニケーションコストがかかる

## ソリューション: キューとスタックを使う
ミーティングの品質を決めるのはファシリテーションだけではありませんが、今回はファシリテーションに絞ります。

ファシリテーションをシステム化できると安定します。その手法として **発言キュー（Speaker Queue）** と **発言スタック（Speaker Stack）** を紹介します。

これによりキューやスタックを使って発言権を制御することになるので、ファシリテーションが安定しやすくなります。また可視化もされるのでミーティングの品質の定量化もしやすいです。

## 発言キューと発言スタック
これはキューとスタックを介して発言を行うシステムです。

### 基本
発言する際は、以下の流れに沿います。

- 1: ボタンを押す（キューに自分の名前が入る）
- 2: ファシリテーターは、単にキューから一つ取り出し、その人に発言権を渡す

システムのアーキテクチャにおいてキューイングは鉄板ですが、同じことをします。発言権をキュー経由で行うことで FIFO を確保でき、参加者全員の体験が安定します。

### スタックも使う
実際にはキューの他にスタックも使います。**スタックは「割り込み用」であり、LIFO として処理する、かつ中身が空になるまで優先的に処理します**。キューだけではミーティングの複雑性を捌ききれないので、こうしてスタックで割り込めるようにします。

### 応用
上述したとおり 1-Stack 1-Queue が基本形と言えますが、これ以外のパターンも可能です。

ファシリテーションの話からは逸れますが、以前[HQRST is Recommended for Lightweight Task Management - DEV Community](https://dev.to/stakiran/hqrst-is-recommended-for-lightweight-task-management-3nlg)を書きました。これは個人のタスク管理を n つのデータ構造の組み合わせでカバーするもので、同じアイデアを採用できます。

たとえば 2-Stack 1-Queue の運用ができます。

- 優先度1: わからない用語を聞くスタック
- 優先度2: 割り込み全般
- 優先度10: 発言全般

こうすれば、ミーティング中にありがちな「わからない用語がある」「でもすぐに尋ねられる雰囲気ではない」もファシリテーションできます。

---

# GitHub を用いた発散ワーク

## サマリー
- いわゆるアイデア出しの営みがある
    - 発散（出す）、収束（整理する）、蒸留（本質や結論を導く）
    - 従来は Miro などデジタルホワイトボードで行うようなもの
- 実は GitHub + プレーンテキストでも可能
    - リポジトリを一つつくる
    - 各自アイデアや意見を書き込んでいく
        - 自分の意見は `(theme)-(myname).md` として書く
    - 各種ビューはスクリプトまたは生成 AI につくらせ、また gitgnore で無視する
- これにより衝突(Conflict)することなく自分の意見を書き、他の人の意見も読める
    - それもローカルで、慣れたエディタやターミナル上で行える

## 背景

### 発想法と呼ばれる営みがあります
私が **発想法（Creative Thinking Methods）** と呼ぶ営みがあります。手法としてはブレインストーミング、ツールとしては Miro が有名ですが、まずアイデアをたくさん出して、それを整理しつつも、さらに出していって、最後には本質や結論を導く――そのような営みです。

### 発想法は軽視されている
現代は VUCA であり、変化が激しくて正解もない時代です。そんな時代だからこそ、自分は何ができるのか、何をするべきなのか、何がしたいのか、今何をして何を捨てるべきなのかといったことを自分で考えねばなりません。考えるためには情報が必要で、人間の頭だけでは扱える情報量は限られています。だからこそ発想法が役に立ちます。

また、エンジニアの皆さんは普段設計をしたり、チームのビジョンや戦略を検討したりするのに苦戦しているかと思います。ただのコミュニケーションでは歯が立ちません。ここでも発想法が重要になってきます。

**まずは情報です**。とにかく各自が持つ情報――知識も、制約も、アイデアや意見も、何でもたくさん出すのです。話はそれからです。逆を言えば、出しさえすれば、あとは整理と取捨選択の問題ですからどうとでもなります。

このような営みを体系的に行うのが発想法です。エンジニアにも、いいえ、創造的なエンジニアだからこそ重要なスキルです。

### しかし Miro を使うのはなぁ……
このジャンルの鉄板は、アナログにはホワイトボードや付箋、デジタルには Miro です。

しかしエンジニアにとっては、どちらもやりづらいものです。エンジニアは聞いたり話したりすることよりも、読み書きの方がはるかに慣れています。また、情報はプレーンテキストで残さないと、あとで利活用しづらいことも知っています。

というわけで、エンジニアの皆さんにも合った手法を今回開発しました！

## GitHub を用いた発想法
GitHub を使って、プレーンテキストベースで、各自のローカル環境で発想法を行う手法をご紹介します。

### フェーズ
三つのフェーズに分かれます。

- 1: 発散フェーズ
- 2: 収束フェーズ
- 3: 蒸留フェーズ

発散フェーズでは、各自の意見を集めます。n 人いるなら n 人分の意見が集まるはずです。この時点では整理や選択は行わず、各自に任せます。たくさんの意見が出ると思います。

収束フェーズでは、発散フェーズで出した意見を整理していきます。似た意見を固めたり、構造化したりします。無理に綺麗に整える必要はなくて、皆にとって理解しやすい整理ができればそれでいいです。ベストエフォートで構いません。また、この段階で、さらに意見が思いつくことも多いので、引き続き出しても構いません（つまり **発散フェーズと行き来します** ）。

最後、蒸留フェーズでは何らかの本質または結論を出します。文書 1 ページ未満の文章で書きます。行動を伴わせたいならタスクリストも書きましょう。

### 発散フェーズのやり方
- 1: リポジトリを一つつくります
    - .gitignore に `*view*` を追加してください
- 2: 各自コメントを書きます
    - 自分のコメントは `(theme)-(myname).md` として書いてください
    - 他の人の更新は git pull で取り込みます
    - 要約、翻訳、その他ビューは各自でスクリプトや生成 AI でつくってください
        - その際、皆で共通して使うと決めたもの以外は、ファイル名に `view` を含めてください（つまりバージョン管理の対象外にします）

つまり、リポジトリには (theme)-james.md、(theme)-mary.md のようなファイルが並んでいくことになります。テーマ、もっというとお題に対する各自の意見が存在しています。

ファイル名として分かれているので、Conflict の恐れはなく、git pull でガンガン取り込んでください。それをローカルで眺めつつ、さらに思いついた意見を追加していきます。

たとえば James が「ミーティングの頻度について」を議論したくて、meeting_frequency_james.md をつくります。他の人、たとえば Mary は、pull したときにこのファイルが取り込まれます。James の内容を見て、意見があれば meeting_frequency_mary.md をつくって push します。

このようにしてお題ごとの意見が貯まっていくので、スクリプトなり生成 AI なりに頼ってビューをつくりましょう。たとえば James は単純なマージスクリプトをつくって、meeting_frequency_view.md を生成させています。Mary は Cline を使って meeting_frequency_summarize_view.md をつくっています。いずれにせよ、ファイル名に view の文字が入っているのでバージョン管理はされません。

### 収束フェーズや蒸留フェーズのやり方
今回は割愛します。本記事では、最も重要な発散フェーズに絞って解説したかったからです。

収束フェーズのやり方は様々です。最近ですと、Claude Code でも Codex でも何でもいいですが、AI エージェントに任せて収束してもらったものをインプットにして、人間がミーティングをして蒸留するのが潮流だと思います。

一方で、私のような[ナレジャー](https://dev.to/stakiran/what-is-knowledging-2229)は、まさに収束や蒸留を生業としていますから、時間をかけて（もちろん生成AIの力も借りて）つくりこんでいきます。プロジェクトや仕事にもよりますが、100 時間以上かけることもあります。

いずれにせよ、発散フェーズによって情報が出揃っているので、どうとでもなるわけです。最も重要なのは発散フェーズであり、各自が出し切った意見の集まりなのです！

## おわりに
GitHub を用いた発想法、特に発散フェーズのやり方をご紹介しました。また発想法そのものの概要と意義も解説しました。

発想法はエンジニアの間でも軽視されており、これができないせいで苦戦をする人をよく見かけます。特にエンジニアリングマネージャーやスタッフエンジニアといった上位職の人は、これができるかどうかで全然違います。私は必須のスキルとさえ考えます。ぜひ練習して、ものにしてください！

それではまた。

---

# タスク管理の実装に使える「タスクの属性」一覧
タスク管理ツールは通常、何らかの SaaS を使うと思いますが、チームや個人によっては物足りません。そこで  SaaS 側のカスタマイズ機能を使ったり、ツール自体を自製したりすることがあります。

そのような場合、タスクの属性を知っておくと便利です。本記事で網羅します。

## (記述系属性)

### 名前
- タスクの名前
- 一行

### 詳細
- タスクの詳細情報
- 名前だけではカバーできない、補足的な情報を文章で記述する
- 複数行

## (状態系属性)

### 状態
- 開始、終了、中止、進行中といった「タスクの状態」
- 少なくとも「未完了」と「完了」の二値は必要だが、選択肢は各自設計して良い
    - しかし煩雑すぎると認知コストが上がるため、4 以内で抑えたい

## (識別系属性)

### ID
- タスクの識別子
- 採番は機械的で良い
- 「名前」だと識別子として使えないことがあるため、内部的には持っておいた方が良い
    - 同じ名前のタスクが複数存在する、はよくあります

## (日付系属性)

### 実行日
- タスクを実行する日
- たとえば今日が 2025/11/28 で、でも 2025/12/01 に実行したいタスク A があるなら、A の実行日を 2025/12/01 にする

### 作成日
- タスクを作成した日
- タスクの「古さ」を感覚的に把握するのに役立つが、なくてもいい
- 自動入力必須。さすがに作成日を手作業で入力するのは面倒がすぎる

### 締切日
- タスクの完了期限となる最後の日
- よく使われがちだが、ウォーターフォール的な指標であってアジャイル的な昨今では全く合わないので無くても良い
    - 締切はスプリントやプロジェクトやマイルストーンなど「タスクを束ねた単位」に対して設定するのが良い

### 完了日
- タスクを完了した日
- 実行日と組み合わせると「計画どおりに完了できたか」「遅れは何日か」を計算できる

## (時刻系属性)
日付系属性よりも小回りが効いて使いやすいですが、チームレベルだとマイクロマネジメントになります。時刻系属性は、個人のタスク管理用途でのみ使うのが望ましいです。

### セクション
- タスクを実行する時間帯
- 実行日は「日」だったが、こちらは「時間帯」。午前、午後、朝、昼、夕方など

### 開始時間
- タスクを開始した時間
- たとえば hh:mm
- どちらかといえばタイムトラッキングの側面が強い
    - 日単位の管理で十分という場合は、必要ない

### 終了時間
- タスクを終了した時間
- 開始時間と合わせると、タスクにかかった時間を導出できる
- ただし割り込みやマルチタスクには弱く、常にシングルタスクで進めること前提の属性ではある

### 見積時間
- タスクの完了にかかる時間の見込み
- 開始時間と終了時間から「かかった時間（実績）」が出せるので、この見積時間と合わせると予実管理が可能となる

## (定期系属性)

### 繰り返し頻度
- タスクを出現させる頻度
- 「n 日ごとに x 回行う」の形で指定する
    - 毎日（1日ごとに1回）
    - 3日に1回
    - 週に1回（毎週水曜日、毎週金曜日など）
    - 1日2回（毎日頻度のタスクを2個つくってください）

### 繰り返し条件
- タスクを出現させる条件
- 特に **繰り返し頻度では表現できない、きめ細かい条件** を指定する
- たとえば:
    - 毎週月曜日かつ営業日
    - 月初の月曜日
    - 月末の金曜日

## (分類系属性)

### カテゴリー
- タスクに一つのみ付与する分類項目
- タグの一種であり、カテゴリーを削除してもその中のタスクは消えない

### タグ
- タスクに複数付与できる分類項目
- 主な用途はフィルタリング

### ラベル
- タスクに複数付与できる分類項目で、色情報がつく
    - ラベル名とラベルカラーがある
- 主な用途は「俯瞰したときの視認性」

### スター
- タスクに一つのみ付与する、カスタマイズ性のない分類項目
    - 内部的には単一のフラグであり、オンとオフしかない。デフォルトはオフ
- 主な用途はブックマーク

### 優先度
- タスクに一つのみ付与する分類項目
- タグとは別に存在し、タスクの優先度を示す
- ユーザー側でカスタマイズ可能にしてもいいが、可能ならツール側で固定してしまいたい（ツール側がコンセプトとして優先度の体系を提示するべき）

### トリガーコンテキスト
- タスクに複数付与できる分類項目
    - トリガーコンテキストとは、そのタスクを実行できる状況を指す
    - たとえば「移動中」「深い集中が必要」「会社」「自宅」など
- 主な用途はフィルタリング、特に「**今の状況でもこなせる** タスクの抽出」

## (主観系属性)
タスクに関する所感を表現するものです。

所感ですので主観的ですが、必ず定量的（0～100の数値、n段階から選択等）にしてください。

### 重要度
- タスクの重要度
- 意味的には優先度属性と同じようなものですが、重要度属性の方がもっと感覚的に運用できます

### 難易度
- タスクの難易度
- トリガーコンテキストでまかなえることが多いです
    - というのも、かんたんなタスクは場所やタイミングを選ばないですし、難しいタスクは逆に選ばないといけないことが多いからです

## (協調系属性)
タスクに紐づいた人を扱う属性です。個人タスク管理の場合は不要です。

### 担当者
- タスクを実行する人
- 実行の責任者を定めるものでもあるため、必須属性です
    - しかし挑戦的なジャンルとして **担当者という概念が存在しないタスク管理** もあります。この場合、後述の発行者と貢献者を使います

### 発行者
- タスクを発行した人
- 「誰が」タスクをつくったか、という情報が重要な場合は採用してください
- 通常はツール側で自動で記録させれば済みますが、重要でない場合はノイジーなだけですので表示しなくてもいいです

### 貢献者
- タスクに携わった人
- たとえば GitHub Issues などチケット型ツールだとわかりやすいです。そのタスクのページで何らかのアクションをした人全員を示します
- 主な用途は二点
    - そのタスクに誰がいるかを視覚的に表示する（アバター等を表示する）
    - あとで成果を計測する際に使う

### 購読者
- そのタスクに注目している人
- 主な用途は更新通知。タスクに関する情報が更新されたとき、購読者に通知を飛ばします

## おわりに
タスク管理の実装に正解はありませんが、基本的な属性は網羅しているはずです。これにより、皆さんが実装する際は遠回りせずに済むでしょう。それではまた。

## (参考)
- 英語版
    - [Task Attributes(1/2)｜Breaking Down Task Management](https://zenn.dev/sta/books/tasukami-english/viewer/attributes)
- 日本語版
    - [タスクの属性｜タスク管理を噛み砕く](https://zenn.dev/sta/books/taskmanagement-kamikudaku/viewer/attributes)

---

# タスク工学

## サマリー
- プロジェクトのタスク管理ではなく、個人のタスク管理の話
- タスク管理は「自律的に働くための必須スキル」
    - 自律的に働けないと、エンジニアリングに必要な「孤独な集中」を制御できない
- タスク工学なる分野を提唱します
    - 非常に重要なのに整備されていない。管理という言葉が悪いのでしょう、というわけで新たな言葉が必要です
- タスク工学の整備は近年の私の大仕事であり、書籍の形で整備した
- 本記事では書籍をベースに、タスク工学の構成要素をかんたんに紹介する

## 背景

### タスク管理は未整備
タスク管理はソフトスキルとして非常に重要ですが、未だにろくに整備されていません。

※プロジェクトのタスク管理ではなく、自分で自分のタスクを管理するという **個人タスク管理** の話です。

おそらく管理という言葉が良くないのでしょう。別の言葉で捉え直した方が良いと考えました。私達はエンジニアなのでエンジニアリングとして捉えるのはどうでしょうか。つまりタスク工学です。

### なぜタスク管理が重要か
そもそも、なぜタスク管理が重要なのかというと、**自律的に働くために必要なスキル** だからです。

自律的に働けない者は悲惨です。物理的に集合して、場の雰囲気やメンバーからの声掛けによって駆動する **反応駆動（Reaction Driven）** しか取れません。これが合う人や、このスタイルでこそ結果を出せる人もいますが、通常はそうではない。[Online Meeting Sucks](https://dev.to/stakiran/online-meeting-sucks-1g7l) でも述べたとおり、エンジニアリングの本懐は孤独に集中することにあります。そうしてつくったものを、ミーティングなりコラボレーションなりで揉めば良い。もちろんたまには雑談でもリトリートでもして交流すればいい。それでも、最も重要なのは孤独な集中なのです。

さて、孤独に集中するにはタスク管理（個人タスク管理）が必要です。自分を律さないといけないからです。また仕事なのでコミュニケーションの機会はあります。集中モードとコミュニケーションモードを切り替えねばならず、これも自分を律することに含まれます。

プログラミングを行うための道具であるエディタやターミナルのスキルが必要なように、**エンジニアリングを行うエンジニアという「人間」を律する「タスク管理」というスキルが必要** なのです。

## タスク工学
本題に入りましょう。**タスク工学（Task Engineering）** とは、タスクという概念を上手く扱うためのエンジニアリングです。

明確な理論や体系はまだありませんが、私は以前オンライン書籍として整理したことがあります。

- 英語版: [Breaking Down Task Management](https://zenn.dev/sta/books/tasukami-english)
- 日本語版: [タスク管理を噛み砕く](https://zenn.dev/sta/books/taskmanagement-kamikudaku)

必要な概念はおおよそ出揃っていると思います。

以降では、上述のオンライン書籍の内容をベースに、タスク工学の構成要素をピックアップします。おおよそどのような概念が要求されるかを感じ取ってください。そして、自分ならどうやって実現するか、特にエンジニアとして上手く取り入れるかを考えてみてください。

### タスク管理の 3P
本記事のフォーカスは個人タスク管理ですが、この目線での分類は 3 つあると思っており、私は 3P として整理しました。

| 名前 | 対象 | 主な性質 | 
| --- | --- | --- | 
| Project | プロジェクト（チーム） | 割り当て、調整、全体俯瞰と個別詳細 |
| Partner | パートナー（夫婦、親子） | タスクの共有とメッセージのやり取り | 
| Personal | パーソナル（個人） | 人それぞれ |

それぞれジャンルが全く異なります。特にプロジェクトタスク管理と個人タスク管理は分けねばなりません。

タスクと聞いて皆さんが思い浮かべるのはプロジェクトの方だと思いますが、タスク工学の主戦場は個人です。プロジェクトの方は、プロジェクトマネジメントや開発手法などでカバーしているので放っておいてもいいです。それよりも、各個人が自分に合ったタスクの扱い方を模索するとの観点が圧倒的に不足しているので、タスク工学として強化するべきと考えています。

### アスリートとアプライア
個人タスク管理はアスリートのような営みになります。結局のところ、タスクを可視化して、それを見ながら優先順位を判断して、一つずつ潰していくものだからです。可視化や優先順位付けも大事ですが、それ以上に ***「書いてあるタスクをちゃんとこなす」パワーが最も重要です**。

プログラムは書かれたコードのとおりに動作しますが、人間はそうもいきません。それでもそうしないといけないのです。これは身体的にも精神的にもキツイことであり、私は **アスリート** とたとえます。実際、普段から習慣に頼って健康的な肉体と健全な精神を維持することが不可欠です。

一方で、もう一つのタイプがあります。頭の中が普段から慌ただしくて、じっとしていられない性分の人がわかりやすいと思います。この人達はアスリートにはなれません（したがって個人タスク管理がそもそも向いてません）が、頭の処理能力は高いのでパフォーマンスは高い。これを私は **アプライア（Applier）** と呼んでいます。応用が得意です。

まとめましょう。

- アスリートは、自分なりのタスク管理システムを自分でつくってメンテナンスできます。
- アプライアにはそれができないので、環境の力に頼ることになります。
    - おそらくフルリモートで自律的に仕事するのは難しいでしょうし、できている人もオンラインミーティングが多いと思います。また、ペットなど「退屈をまぎらわせて」「ランダムももたらす」手段を持っていることが多いです。

長くなりましたが、この節で一番言いたい事を言います。個人タスク管理においては、

- アスリートは自分の、自分による、自分のためのシステムをつくりましょう。環境の力に頼るよりも、自分でシステムをつくった方が良いです
- アプライアは、おとなしく環境に飛び込んでその環境の力に頼りましょう。自分で整えるのは無理なので、諦めてください

つまり **アスリートなのに環境の力に頼ったり、逆にアプライアなのに自分でつくろうとしたりといったミスマッチはやめましょう**。

### タスク管理の戦略とスタンス
タスク管理の戦略とは、どんなやり方や考え方で望むかという方針のことです。これは「何を拠り所にするか」で分けることができます。

主な戦略を挙げます:

- (時間で区切る)
    - Dailer。タスクを「日単位」で捉える。に「今日」と「それ以外」に二分し、今日のタスクが全部終わったら今日はもうおしまいにする。メリハリをつけやすく、先送りもしやすい。
    - Calendarer。カレンダーに全部詰め込み、カレンダーの通りに動く「カレンダーロボット」。マネージャーや経営者など忙しい人はこれになりがち。
    - Slotter。30～60分の時間枠をつくっておき、ここに何かを当てはめると考える。タイムボックスを地で行く
- (話題で区切る)
    - Issueist。たとえば GitHub Issues に全部詰め込むようなものです
    - Topician。タスクも含めた「トピック（話題）」を 1-トピック 1ページ で扱う。現在では Obsidian が有名。古典的には Wiki。大量に読み書きするのでローカルかつプレーンテキストは Must かもしれない
- (一箇所にまとめる)
    - Richild。裕福な子供のように、何でも「おもちゃ箱」に詰め込む。単一の箱に詰め込んでおくという「信頼できる唯一の情報源」戦略。典型例は机上やデスクトップが汚い人。
    - Monolith。タスクを一箇所に記述する。たとえば tasks.md に全部書く、など。Topician を 1 ファイルで行うと思えば間違いはない。テキストエディタに長けた比較的高齢のエンジニアに多いかもしれない
- (繰り返しの力でまわす)
    - Robot。自分の生活を数十以上の「定期タスク」に分解した上で、毎日そのとおりに従う。起床 →トイレとカーテンと洗顔 → お湯沸かす → コーヒーとパンを持ってデスクに行く → ブクマの「毎日」フォルダをタブで開く……。ツールで言えば Todoist が近い
    - Tracker。すべてのタスクを日課（その日中にやるが、いつやるかは指定しない）ととらえる。Robotは実行順序やタイミングも定めていたが、Trackerは「その日やること」だけ決まっていてあとは自由。要は習慣トラッカー化です
- (自分の脳内が正義) 
    - Inboxer。タスク管理としてインボックス（未消化の対象を溜める何か）のみを使う。整理やノートテイキングはしない派。普段使っているメールやチャットやブラウザのブクマなどに頼る程度だし、下手するとそれさえもしない。

次にタスク管理のスタンスとは、タスクをどう処理するかという対応パターンを指します。メンタルモデルと言っても良いかもしれません。戦略は「どう扱うか」という管理の話でしたが、スタンスは「どうこなすか」という処理の話です。

主なスタンスを挙げます:

- (抱える量を減らす)
    - Deligator。自分で処理せず人に任せます
    - Sprinter。タスク管理をはさまずに、その場ですぐに処理します
    - Skipper。今日やると決めたこと以外はとりあえず先送りにします
- (省力化する)
    - Automaton。仕組み化（統一化とできれば自動化）します
    - Rejecter。断る対象やパターンを決めておいて、それらに当てはまるものは断ります
    - Focusist。直近取り組む対象を決めて、それら以外は無視します
- (盤外戦をする)
    - ※ **盤外戦** とは、タスクそのものの処理の仕方を考えるよりも、タスクの発生や抱え方の方に目を向けて干渉することです
    - Slackist。余裕の確保と死守に専念します。タイムボックスもここに入ります
    - Contexton。タスクの文脈を知ることに力を注ぎます
    - Mixer。タスクをまとめて一気に処理しようとします。関連するタスクをまとめて処理できるタイミングを狙ったり演出したりすることに注ぎます

いかがでしたか。皆さんも上記のいずれかの戦略とスタンスを取っているはずです。もちろん場合によって複数を使い分けるのも普通です。特に目新しいことは言っていませんが、こうして言語化して捉えることに意味があります。エンジニアリングも言語化と設計から始まりますよね。

### タスクのようでタスクでないもの
私はタスクのようでタスクでないものを **オルタスク（Altask）** と呼んでいます。オルタスクはタスクではないので、タスクとは違った扱い方をしないといけません。

オルタスクとして以下があります。

- コンテナ。タスクを分類するもの
- イベント。予定。もう少し詳しく定義すると「開始時間と開始場所の少なくとも片方を拘束され、かつ終了のタイミングも指定されているか調整が必要となる事柄」
- モットー。心がけること。人生哲学から昨日の振り返りで得た「次気をつけること」まで様々
- メモ。一時的に書いておいて、あとで処理するもの。アイデアもここ
- タスクソース。タスクを日々発生させる源泉。
    - 目標事項。達成可否が存在する、道しるべとなるもの。コンテナとして扱うことが多い
    - 維持事項。恒久的に維持したいこと。モットーはここに入ることがある
    - 連想事項。何らかの事物を思い出す・思い起こすためのヒントとして使うもの。トリガーリストなど
    - 発想事項。ひらめきや思いつきを促すもの、インスピレーションのもととなるもの

わかりやすいのがイベントで、イベントはおそらくカレンダーを使うでしょう。**イベントをタスクリストで管理しようとする人はいないはずです**。このようなオルタスクは、イベントの他にも色々あるのです。

### (コラム) タスクとは関係のない事柄も扱っている気がするが、気のせいか？
Ans: いいえ、気のせいではありません。

むしろ重要です。

タスク工学として向き合うのはタスクだけではありません。タスクとだけ向き合っていてもタスクはこなせないからです。たとえばタスクを発生させる原因（オルタスク）や、タスクを遂行する自分自身の性質やメンテナンスにも気を配らねばなりません。

タスク工学では、このような周辺領域もカバーします。ですので、見かけ上はタスクと直接関係がないことも扱っているように見えます。

### 動線とリマインド
タスクを全部頭の中に入れて、忘れることなく、怠けることもなく、もちろん迷うこともなくすべてを消化することなど不可能です。現実的には **必要なときに思い出す** しかありません。リマインダーはすでにご存知でしょうが、この「思い出せる仕組み」は非常に重要です。

動線とリマインドがあります。

#### 動線
**動線(Waypoint)** とは、普段私達が頻繁に通る場所を指します。PC のデスクトップがアイコンが散らかっていて日々あれこれ触っているなら、そこはその人個人の動線です。プロジェクトとして毎日必ずよく見る Slack チャンネルがあるのなら、そこも動線です。ダッシュボードやデイリーノートをつくっていたり、最近だと ChatGPT Projects のような「AI も居座っているワークスペース」も見かけます。

動線があると、**そこにタスクを置いておくことでそのうち目に入るので思い出せます**。これを **トラップ・リマインド** と呼びます。罠を仕掛けておいて、あとで引っかける（自らひっかかる）というニュアンスです。

#### リマインド
次に **リマインド** とは、「未来のあるタイミング」に「事前に仕込んでいた用件」を思い出させる仕組みを指します。

一番単純なのが目覚まし時計で、これは指定時間に、音を使って（起きるという用件を間接的に）知らせます。私達が普段使っているのはカレンダーによるもので、n 分前にアラームやポップアップが届いているかと思います。

また、物理的に集まって仕事をすると良くも悪くも場の雰囲気がわかり、次何をすればいいかが自然と（もしくは無理やり）知らされますが、これもリマインドの一種であり、私は[雰囲気リマインド（Atmosphere Remind）](https://dev.to/stakiran/full-flex-1kfn)と呼んでいます。

さて、リマインドですが、これは単純な話で **リマインドについて知っていれば知っているほど、より決めの細かいリマインダーを仕掛けやすくなります**。逆に考えてみてください。もしあなたが目覚まし時計しか使えないとしたら、どうでしょう。相当不便でしょうし、おそらく形骸化します。そして様々な打ち合わせや「あとでやるべこと」を忘れてしまうのです……。

### 割り込みと脱線
**割り込み** はエンジニアの敵である――この主張に異論は無いと思います。必要悪と諦めている人も多いと思いますが、違います。割り込みは減らせますし、何ならなくせます。そのためには「割り込みとはそもそも何なのか」「どういうメカニズムで発生するのか」「回避するために、どんな代替の仕組みをつくらねばならないか」といったことを考えねばなりません。

もう一つ、割り込みと区別したい概念があって、**脱線** です。割り込みは他者から強制的にもたらされますが、脱線は自分自身によって注意が逸れるものです。スマホに通知が来たからちょっと覗こう、といったことですね。

タスク工学では、この割り込みと脱線もしっかりと扱います。たとえば以下は私が開発した SWAP マトリックスであり、4 パターンに分けて対処できるようにしています。

|  | Strong (強い後回し) | Weak (弱い後回し) |
| --- | --- | --- | 
| (Active) 割り込み | パターン1 | パターン2 |
| (Passive) 脱線 | パターン3 | パターン4 |

※ちなみに **後回し** とは、タスクAをやっている最中にタスクBが来たときに、どちらか片方を後回しにしなければならないということです。Bを後回しにした場合、自分が強いので「強い後回し」と言います。Aを後回しにした場合、Bに負けたということなので「弱い後回し」と言います。

### 文芸的タスク管理
**文芸的タスク管理（Literate Task Management）** とは、文芸的に行うタスク管理を指します。LTM と略します。

日本で開発され始めている概念であり、文芸的プログラミングから着想を得ています。従来のタスク管理は、タスクという情報をチケットのように機械的に扱っていました。

LTM では、**まず日記や思考や調査まで文章として書き記します**。その上で、必要に応じてタスクの情報も記述します。タスクを抽出したい場合は、文章から上手く抽出します。つまり文章ファーストだと言えます。

なぜそんなことをするかというと、**文脈を意識できる** からです。文脈を意識せず、思考停止して目の前のタスクを処理し続けるのは愚かなことです。通常は相応の文脈があり、正解も無くて、文脈に応じた最適な戦略を考えねばならないはずです。LTM を使うと、文脈を意識しやすいのです。また、副次的なメリットとして、生成 AI に食わせて分析がしやすい点も挙げられます。

エンジニアにはまだ馴染みづらい考え方かもしれませんが、すでに Obdisian などを使って、ローカルで自分なりのテキストステーションをつくっている人もいるでしょう。

## おわりに
個人タスク管理は、自律的に働くための必須スキルです。その割には整備されていません。管理という言葉が悪いのでしょう……というわけで、タスク工学という新しい言葉を提唱しました。

私は[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)であり、[ソフトスキル・エンジニア](https://dev.to/stakiran/soft-skills-engineering-34mg)でもあります。近年の大仕事として、すでにタスク管理の基礎概念を整理しています（冒頭のオンライン書籍）。本記事では、書籍の内容をベースに、タスク工学の登場人物をかんたんに紹介してみました。

いかがでしたか。たかが個人タスクと言えど、そうかんたんではないことがおわかりいただけたかと思います。まだまだ発展途上であり、皆さんの試行と議論も必要としています。ぜひタスク工学の世界に、足を踏み入れてみてください！

---

# テキストエディタ・ベースド・リマインダー

## サマリー
- PC 上で使うリマインダーのバランスは難しい
    - CLI でクイックに、でもノイジーがすぎないようにしたい
- 良いアイデアが一つあります
    - 用件を書き込んでおいたテキストファイルを開くのです
    - これにより、アクティブウィンドウのフォーカスが移るので気付けます
    - これをテキストエディタ・ベースド・リマインダーと呼んでいます

## 背景

### デスクの前にいるときのリマインダーは難しい
まず CLI のようにクイックに仕込みたいです。GUI を触るだなんてカレンダーで十分だ。次にうるさすぎてもいけない。イライラするので。もちろん静かすぎて「リマインドされても気付けなかったです」もあってはなりません。

この二点を満たしたリマインダーは、実はとても難しい。巷にはまともなツールはないでしょう。

### リマインダーは自製するもの
そういうわけで、最適なリマインダーが欲しければ自製した方がいいのです。

さて、今回はリマインダーを開発したい人に向けた、ある面白いリマインド方法をご紹介します。

## お使いのテキストエディタでリマインドする
**テキストエディタ・ベースド・リマインダー（Text Editor based Reminder）** とは、要件が書き込まれたテキストファイルを開く形で行うリマインダーを指します。

※以降では Windows を想定します。他の OS の方は適宜読み替えてください。

### 仕組み
テキストファイルがテキストエディタで開かれると、アクティブウィンドウのフォーカスがそこに移りますよね。フォーカスが奪われているとも言えます。**フォーカスが奪われるので気付きやすいです**。かつ、音や振動や点滅といった鬱陶しさもありません。

つまりテキストエディタ・ベースド・リマインダーは次のような仕組みです:

- リマインダーを設定するとき:
    - 1: `%temp` など適当なフォルダに、ランダムな名前のテキストファイルをつくる
    - 2: 1 のファイルに用件を書き込んでおく
- リマインドを行うとき:
    - 上述のファイルを開く

これだけです。これだけで **用件の書き込まれたテキストファイルが愛用のテキストエディタで開かれます**。アクティブウィンドウのフォーカスも変わるので、すぐに気付けます。

### 例
私もいくつかのツールで採用しています。

- [stakiran/w.py: Waiter Launcher](https://github.com/stakiran/w.py)
    - 指定した URL を n 分後に起動するだけのプログラム
- [stakiran/aism](https://github.com/stakiran/aism)
    - A CLI tool that summarizes the contents of the clipboard, outputs it to a file, and opens it.

特に 生成 AI と相性が良いです。バックグラウンドで走らせておいて、処理が終わったらその結果をテキストエディタ・ベースド・リマインダーでリマインドさせるのです。愛用のテキストエディタなので読解やコピペもしやすくて重宝します。

---

# 生成 AI 時代の TIL(Today I Leared) はソフトスキル的に書く

## サマリー
- TIL(Today I Learned) は生成 AI 時代には無用の長物
    - 元々 TIL ではハードスキル的なスニペットを書いていた（たとえば手順、コマンド、設定値などのメモ）
    - しかし生成 AI により、AI に聞けば済むようになった
- Q: では TIL は不要になったのか？
    - Ans: いいえ
    - ソフトスキル的に書けばいい
    - たとえば普段の作業ログ、タスクやアイデアのメモ、思考や内省の記録など
    - そしてそれを生成 AI に与えて洞察を得れば良い

## 背景

### TIL をご存知ですか？
**TIL(Today I Learned) ** とは、その日学んだ知識を Markdown などでメモしておくことです。元は Reddit の文化ですが、GitHub でも一時期よく見られました。

いくつか例を挙げます:

- https://github.com/jbranchaud/til
- https://github.com/thoughtbot/til
- https://github.com/simonw/til
- https://github.com/milooy/TIL

たとえばコマンド、コードの構文、設定値といったスニペットを書き残しておくのです。GitHub だとブラウザからもかんたんに閲覧・検索できますし、もちろんローカルのターミナルや IDE で読むのも簡単です。よく使うスニペットを貯めれば貯めるほど便利になりますし、公開しておけば勤勉なエンジニアであることもアピールできてキャリア上も有利です。

### TIL は不要になった
しかし生成 AI のおかげで、「聞いた方が早い」事態となりました。

（外に出せないドメイン知識でもなければ）TIL はもはや不要です。むしろ、生成 AI の時勢に乗れず、原始的に TIL をメンテナンスしている様は滑稽ですらあります。無論、知識のメンテナンス方法など個人の自由ですが、これだけ生成 AI が盛り上がっている現代において、生成 AI ファーストで物事を捉えないのは長い目で見て危ないと思います。

### しかし TIL はまだまだ有益です！
やるか、やらないかの二値で考えるのは愚かです。その間があります。ハイブリッドがあります。つまり、**TIL を続けつつも、生成 AI の力を借りればいい**。

## TILS
**TILS（Today I Learned Softly）** とは、ソフトスキル的に TIL を行うことです。

従来、TIL はコマンドやコードや設定値などハードスキル的な知識を扱っていました。そうではなく、自分のタスクやアイデアや気付きといったソフトスキル的な情報を書きます。さらに、それを生成 AI に与えることで洞察を出させます。

## TILS の書き方
つくりかたに正解はありませんが、以下の概念を押さえてください。

- 日々のメモを貯めること
- 貯めたメモを生成 AI に食わせて洞察を得ること

たとえば VSCode + Cline で行う場合、以下のような初期構造をつくるといいでしょう。

- https://github.com/stakiran/tils

以下にも引用します:

```markdown
This repository stores TILS (Today I Learned Softly).

## About TILS
TILS (Today I Learned Softly) is a system for recording and organizing the soft skills learned daily. Originally, there was an initiative called TIL (Today I Learned) that organized hard skills such as commands, code snippets, and configuration values in Markdown. Please consider this as its soft skills version.

## About the structure of the repository
The directory structure is as follows:

- (project root)
    - daily/
        - 20251122.md
        - 20251123.md
        - ...
    - knowledge/
        - 20251122.md
        - 20251123.md
        - ...
    - agent/
        - taskmanager.md
        - peoplemanager.md
        - ...
    - insight.py
    - today.py

Under the daily/ directory, one file per day is saved, and you can write any daily memo. This includes work notes, memos about tasks and ideas, URLs to read later, brief diaries, etc.

The knowledge/ directory outputs the results generated by the **TILS Agent**. The input comes from the daily/ and knowledge/ directories, and insights corresponding to each day in the daily/ directory are output.

Under the agent/ directory, prompts for the TILS Agent are saved. One file represents one agent. For example, if you were to create an agent like a "Task Manager" that organizes remaining tasks and proposes the next tasks to undertake, you would create a file such as agent/taskmanager.md and write the appropriate prompt.

Additionally, there are several scripts at the root.

- today.py
    - Generates and opens today's memo. If it's already generated, it opens the existing memo.
- insight.py
    - Uses today's memo and the prompts from all TILS Agents as context to query a generation AI.
    - The answers are output to the knowledge/ directory.
```

## TIL ユーザーが TILS を始める際に意識するべきこと
- おそらく公開はできないと思います
    - ソフトスキルはしばしば個人的かつ機密的なものであり、そのまま公開することはできません
    - 公開するにしても、生成 AI に出力させた洞察の部分だけです
- メモとナレッジに分けて考えてください
    - メモとは、生成 AI に与える文脈であり、日頃あなた自身が書き殴るものです
    - ナレッジとは、メモを生成 AI に与えることで導いてもらう「洞察」や「知見」のことです
    - TILS を導入したい場合、メモの書き方と、メモを生成 AI に与えてナレッジを出してもらう仕組みの両方を実装する必要があります

## おわりに
生成 AI が使える現代では、TIL のあり方も変わります。ソフトスキルを扱えばいいのです。そのためにはメモを日々書くことと、それを生成 AI に与えて洞察を出してもらう仕組みが必要です。この一連の概念を TILS(Today I Learned Softly)と名付けました。

生成 AI 時代だからこそ、ソフトスキルが重要です。そしてソフトスキルは非常に個人的なものであり、エンジニアリングと同様、書いて考えることで深められます。TILS はその手段として有益だと思います。ではまた。

---

# お前はまだ本当のリトリートを知らない

## 背景

### 現状のビジネス・リトリート
ビジネスにおけるリトリートをご存知ですか。集中検討合宿またはリラックス多めの社員旅行を意味し、普段フルリモート寄りの働き方をする組織が、半年に一回くらいの頻度で集まるものです。

細かいやり方は組織次第ですが、唯一共通するのが **常にメンバーと一緒に過ごす** ことです。通常は何らかのカリキュラムが組まれて、皆で部屋に集まってワークをします。あるいは自由時間でも他メンバーとの交流、会話、議論を行わねばならないとの圧があります。

たしかに非日常的な空間でリフレッシュできますし、一時的に仕事から離れてリラックスできますし、メンバーとの関係も深まるとは思いますが、**それだけです**。最も大切なことを忘れています。

### 本当のリトリートを取り戻したい
本来リトリートには「撤退」「避難」「隠居」といった意味合いがあります。宗教的には修行のために寺院や山中に出向くことを指します。

**これらの本質は孤独な静寂** です。まず孤独でなくてはなりません。メンバーとの関係を育むことも大事ですが、リトリートはそんなしょうもない営みではない。次に、静寂である必要があります。この場合、静寂であるとは、仕事やプライベートから完全に離れていることです。たとえば **割り込みはありませんし、もちろん合宿や旅行のようなカリキュラムもありません**。リトリートの価値は、普段ではほぼ手に入らないであろう、この二つを手に入れるところにあります。

## 真のリトリート
**真のリトリート（True Retreat）** とは、孤独な静寂を手に入れるための社員イベントを指します。

泊まり込みのイベントです。最低でも一泊二日、できれば二泊や三泊以上を確保します。

このイベントでは一切のしがらみがありません。仕事は一切しなくていいですし、従来のリトリートと違ってカリキュラムを組まされて、やりたくもないワークや交流を頑張る必要もありません。もちろんやりたい人は各自でやればいいですが、少なくとも強要はしないですし、むしろ非推奨です。では、何をするかと言うと、**ただただ一人でくつろぎます**。同時に、**ただただ一人で内省をします**。自分の仕事と、組織と、人生と向き合うのです。手段は問いません。仕事の PC を持ち込んで書き物をしてもいいですし、もちろん私物の PC を使ってもいい。**とにかく、ひとりで孤独にくつろぎます**。

### 「だったら休暇と旅行費だけ渡せばいいのでは？」
と、そのように思われるかもしれませんが、違います。

真のリトリートはメンバー全員に孤独な静寂を課すものです。ですので、イベントとして対象者全員を参加させます。

### リトリート内容の共有
真のリトリートで行ってきたことは必ず共有します。

やり方に正解はありませんが、タイミングとしては以下の三つがあります。

- 1: 真のリトリートの道中（これを **チェックポイント** と呼びます）
- 2: 最終日
- 3: 真のリトリートを終えた後、速やかに

真のリトリートを完全に尊重したいなら、3: の事後で十分です。

しかし通常、何日も孤独でいると「飽きて」あるいは「辛くなって」停滞しますから、チェックポイントはあった方がいいでしょう。しかし、チェックポイントがあるということは、わざわざ集まらないといけないことを意味しますので結構な手間になります。ちなみに私も嫌いです。殺意すら湧きます。ですが、[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として、チェックポイントがあった方が現実的だとわかったので、こうして解説しています。

折衷案として、非同期的に共有できるノートやウィキやチャンネルを用意して、そこに放り込めるようにする手もあります。ただし、このやり方だと X その他 SNS で見られるように **みんなの投稿が気になってしまう** 弊害があります。真のリトリートは孤独に過ごしたいのに、情報に忙殺されてしまうわけです。

## おわりに
あなたはまだ本当のリトリートを知らないと思います。私が教えてさしあげましょう――というわけで、「真のリトリート」をご紹介しました。本質は孤独な静寂であり、孤独にくつろぐことに価値があるのです。

関係性を深める手段としてのリトリートも重要ですが、それ以上に、孤独な静寂のもとで、とことん自分を掘り下げる体験も重要です。ぜひ検討してみてください。ではまた。

---

# エンジニアに適した「リトリート」とは

## 背景

### 現状のビジネス・リトリート
ビジネスにおけるリトリートをご存知ですか。集中検討合宿またはリラックス多めの社員旅行を意味し、普段フルリモート寄りの働き方をする組織が、半年に一回くらいの頻度で集まるものです。別の言い方をすると、普段フルリモートに近い働き方を行える企業が対象であり、主にテック企業があてはまります。

リトリートの細かいやり方は組織次第ですが、唯一共通するのが **常にメンバーと一緒に過ごす** ことです。通常は何らかのカリキュラムが組まれて、皆で部屋に集まってワークをします。あるいは自由時間でも他メンバーとの交流、会話、議論を行わねばならないとの圧があります。

たしかに非日常的な空間でリフレッシュできますし、一時的に仕事から離れてリラックスできますし、メンバーとの関係も深まるとは思いますが、**それだけです**。

### エンジニアに不足しがちな「ハードに関する熟慮」
ここでハードとは、私達エンジニアの **人間としての器や性質** と考えてください。私達は人間である以上、人間に必要な営みをせねばなりません。具体的には **組織のあり方と個人のあり方** について考え、議論し、調整することです。

組織については通常はエンジニアリングマネージャーが選任しますが、現場を離れている彼らの方策と対策は「あまり刺さりません」。彼らが努力している点は痛いほど理解していますが、1on1 で個別にヒアリングする程度では足りないのです。現場で手足と頭を動かすエンジニア自身の **率直かつ正直な** フィードバックが必要です。また、個人については、言うまでもなくキャリアを日々メンテナンスせねばなりません。

さて問題です。そういったことを一体いつ行うのでしょうか。もちろん普段は忙しいし、プライベートも楽しみたい。そうですね、**そんな時間はありません**。

### リトリートを使って、ハードをメンテナンスする
ここでリトリートが役に立ちます。

リトリートの中で熟慮すればいいのです。リトリートは組織が用意するイベントであり、仕事の一部ですから、たっぷり専念できます。もちろん、それだけのリソースは組織の長が責任を持って確保せねばなりませんが。

ここで一つだけ大きな問題があります。冒頭で述べたとおり、**従来のリトリートを実施したところで、（ハードのメンテナンスという意味では）大して役に立たない** のです。メンテナンスをするためには、本来のリトリートを尊重して取り組まねばなりません。本記事では、この難しい捉え方を解説します。

### 本当のリトリートを取り戻したい
本来リトリートには「撤退」「避難」「隠居」といった意味合いがあります。宗教的には修行のために寺院や山中に出向くことを指します。

**これらの本質は孤独な静寂** です。まず孤独でなくてはなりません。メンバーとの関係を育むことも大事ですが、リトリートはそんなしょうもない営みではない。次に、静寂である必要があります。この場合、静寂であるとは、仕事やプライベートから完全に離れていることです。たとえば **割り込みはありませんし、もちろん合宿や旅行のようなカリキュラムもありません**。リトリートの価値は、普段ではほぼ手に入らないであろう、この二つを手に入れるところにあります。

## 真のリトリート
**真のリトリート（True Retreat）** とは、孤独な静寂を手に入れるための社員イベントを指します。

泊まり込みのイベントです。最低でも一泊二日、できれば二泊や三泊以上を確保します。

このイベントでは一切のしがらみがありません。仕事は一切しなくていいですし、従来のリトリートと違ってカリキュラムを組まされて、やりたくもないワークや交流を頑張る必要もありません。もちろんやりたい人は各自でやればいいですが、少なくとも強要はしないですし、むしろ非推奨です。では、何をするかと言うと、**ただただ一人でくつろぎます**。同時に、**ただただ一人で内省をします**。自分の仕事と、組織と、人生と向き合うのです。手段は問いません。仕事の PC を持ち込んで書き物をしてもいいですし、もちろん私物の PC を使ってもいい。**とにかく、ひとりで孤独にくつろぎます**。

### 「だったら休暇と旅行費だけ渡せばいいのでは？」
と、そのように思われるかもしれませんが、違います。

真のリトリートはメンバー全員に孤独な静寂を課すものです。ですので、イベントとして対象者全員を参加させます。

### リトリート内容の共有
真のリトリートで行ってきたことは必ず共有します。

やり方に正解はありませんが、タイミングとしては以下の三つがあります。

- 1: 真のリトリートの道中（これを **チェックポイント** と呼びます）
- 2: 最終日
- 3: 真のリトリートを終えた後、速やかに

真のリトリートを完全に尊重したいなら、3: の事後で十分です。

しかし通常、何日も孤独でいると「飽きて」あるいは「辛くなって」停滞しますから、チェックポイントはあった方がいいでしょう。しかし、チェックポイントがあるということは、わざわざ集まらないといけないことを意味しますので結構な手間になります。ちなみに私も嫌いです。殺意すら湧きます。ですが、[ナレッジ・アーキテクト](https://dev.to/stakiran/what-is-knowledging-2229)として、チェックポイントがあった方が現実的だとわかったので、こうして解説しています。

折衷案として、非同期的に共有できるノートやウィキやチャンネルを用意して、そこに放り込めるようにする手もあります。ただし、このやり方だと X その他 SNS で見られるように **みんなの投稿が気になってしまう** 弊害があります。真のリトリートでは孤独に過ごしたいのに、情報に忙殺されてしまうわけです。

### おすすめは「共有タイミングの実装」
私は **共有できるタイミングに制限を設ける** ことをおすすめしています。たとえば 3 泊 4 日のリトリートを行うとして、1 日に 1 回、12:00 から 13:30 の間だけ共有したい場合、以下を **実装** します。

- リマインダー。12:00 より少し前に、共有タイミングが始まる旨をリマインドすること
- 共有エリア。ノートでもウィキでもチャンネルでも何でもいいので、全員が自由に読み書きできるエリアを設けること
- 共有エリアの開放と閉塞。共有エリアは 12:00～13:30 の間だけ読めるようにすること。あるいは少なくとも **時間が過ぎたら「書き込み」は禁止すること**

**実装** と書いている点に注意してください。この点が必要ゆえに、私は真のリトリートはエンジニアのチームでないと難しいと考えています。あるいは少なくとも、この程度の実装をさっさと行えるだけのソフトウェアエンジニアが一人は欲しいです。

なぜ実装にこだわるかというと、真のリトリートに妥協は許されないからです。だらだらと SNS を見るように、だらだらと共有コンテンツを見たり、メンバーとやりとりしたりすることは許されません。個人で、孤独に向き合うことでしか本心は出てこないのです。だからこそ、ソフトウェアの形で仕組みをつくって、厳格に守らねばなりません。

## おわりに
エンジニアは技術的に多忙であり、組織のあり方や個人のキャリアについては後回しにしがちです。だからこそリトリートが使えます。仕事として、しかしリラックスして **集中的に** かつ **深く** 考える機会を与えるのです。

当たり前ですが、エンジニアは奴隷ではありません。人間です。そして人間なのでそれぞれ思いというものがあります。普段忙しくて、エンジニアリングばかりしていると、この点を見失いがちです。フルリモートならなおのこと。真のリトリートは、この中長期的な問題をクリアするのに役立ちます。ぜひお試しください。

それではまた。

---

# What You Want はナレッジである

## サマリー
- What You Want はライフハックジャンルの個人的な手法に留まらない
    - むしろ複数人で書き貯めることで、多くのメリットがある
    - ナレッジと呼べるほど価値がある情報にある
- やり方は単純で、単に複数人で書き込める場所を用意すればいい
    - たとえば Cosense、GitHub Issues、Miro など

## 背景

### 「やりたいこと」や「ほしいもの」は重要
「やりたいことやほしいものを逃さない」はソフトスキルの一つだと思います。見逃しても短期的に損害が出るわけではありませんが、見逃さずに確保していると中長期的に学びや豊かさが得られます。

これを満たすツール（特にリスト）の例として以下があります。

- やりたいことリスト
    - 単にやりたいことを書いておくリスト
    - このようなリストをつくってみることで、直近何をするかが自ずと見えてきます
- GTD®の Someday リスト
    - やると決めたことではないが、最悪ドブに捨ててもいい「いつかやりたいこと」を貯めます
- バケットリスト
    - 「死ぬまでにやりたいこと」を書きます
    - 100 個埋めることが多いです。人生をゲーミフィケーション化するのが狙いです

### What You Want
このようなジャンルを仮に **What You Want** と呼ぶことにします。**略称は wyw です**。

### エンジニアは wyw を軽視している
私が思うに、エンジニアは wyw を軽視しているように思います。現場のエンジニアも、エンジニアリングマネージャーも、そして上級エンジニアでさえもです。

なぜかというと、wyw が（エンジニアが嫌いがちな）自己啓発やライフハックの取り組みのように見えるからです。そのとおりでもあるのですが、実はそれだけではありません。エンジニアにこそ役に立つものです。

というわけで、本記事では wyw の価値を示します。特に複数人で wyw を共有する手法をご紹介します。

## What You Want Log
**What You Want ログ** とは、wyw を貯めることです。それも複数人で貯めます。プロダクトバックログにはタスクを貯めますが、あれの wyw 版だと考えてください。

wyw ログには誰でも何でも書いていいですが、**どこまで書いていいかのスコープは定めましょう**。わかりやすいのは「このプロジェクトに関してやりたいこと」です。

ちなみに私はスコープはもっと広くすることが多いです。プライベートでやりたいことやほしいもの、あるいは個人的なキャリアの話も含めて良いようにします。この方が会話が弾むからです。

## wyw ログのメリット
- メンバー間の会話が弾みます
    - 非同期的なやりとりを増やせます
    - 同期的に会話する際も、wyw をネタにできるので会話が盛り上がります
- セレンディピティが起こります
- メンバーの隠れたニーズがわかります
- コメントや起票に慣れていないメンバーの練習になります
    - ジュニアエンジニア、他業界から転職してきた新人、非同期的なコミュニケーションを学び始めたシニアなど、練習機会を要する者は意外と多いです
- プロンプトエンジニアリングに必要な「言語化」の練習になります
    - 私達エンジニアであっても誰もが言語化に慣れているとは限りません。特にコミュニケーションやマネジメントなどソフトスキルが絡む場面では「自分に関する文脈」の言語化がしばしば求められますが、これが苦手な人が案外多いのです。このようなカジュアルな取り組みにより練習できます

## やり方
何らかのツールを使って、複数人が誰でもいつでも書けるようにするだけです。

### 例1: Cosense
<https://scrapbox.io>

Cosense は日本産の同時編集ウィキであり、Slack 要らずで複数人で数万以上のページを運用できるほどの快適なウィキです。JavaScript により挙動をカスタマイズできる点も魅力です。

メンバー全員を入れた「wyw 用のワークスペース」をつくって、皆で wyw を書き込みます。ページ間をリンクでつないだり、画像や動画を埋め込んだりもかんたんなので楽しく盛り上がれます。

実はすでに例があります。[/wanna](https://scrapbox.io/wanna/) です。日本語のコミュニティですが、すでに複数人で wyw を書いています。私も参加しています。他の人の wyw も見れて楽しいですし、アドバイスをもらえたりもしますし、もちろん自分も書きます。wyw を通して相手を知れますし、自分を見つめ直すこともできるのです。

### 例2: GitHub Issues
wyw 用のリポジトリをつくって、1-issue 1-wyw で扱うようにします。

とにかく気軽に書けることが大事なので、以下を心がけたいです。

- ラベルやテンプレートは無いか、シンプルに
- 管理はしない。たとえば重複した投稿があっても気にしない。整理を担うメンテナも要らない

wyw が貯まってきたら、APIを使って色々な仕掛けがつくれます。Reader をつくってもいいですし、ランダムに表示する機能があっても面白そうです。今週の分を Slack チャンネルに流すといった連携をしても良いでしょう。

### 例3: Miro
Miro で wyw 用のボードを一つつくって、そこに付箋として書き込んでいきます。また、他の人が書いた付箋を見て、思いつく wyw があればさらに書き込んでいきましょう。非同期的にブレストを行うイメージですね。

注意点としては、整理をしないことです。散らかってもいいし、重複してもいいので、とにかく wyw の付箋を書くことに専念しましょう。付箋が貯まって、散らかってくるほど、面白くなります。

## wyw はナレッジである
このようにして複数人で貯めた wyw はナレッジだと考えます。メンバー達の個性やニーズや助言が含まれているからです。

生成 AI にインプットして対話や分析をしてもいいでしょう。メンバー自らが出した wyw だからこそ、そこから提案される情報は魅力的かつ実用的です。