gists

Module Index (shallow)

• mode: shallow

• description lines: 5 (requested 10, capped by skill constraint)

• 3R サイクル

  3R_cycle.md

  • see: カジュアル・アジャイル

• ソフトスキルの 5C 分類

  5c_of_softskills.md

  • この分類は、ソフトスキルという未だ体系化されていないジャンルに秩序をもたらす。マネジメントやリーダーシップといった構成要素ではなく、それら構成要素の先にある「基本的なあり方」を定めている。
  • ソフトスキルとは 5C をどう捉え、どう形にしたかという実装でしかない。実装は手段にすぎない。より重要なのは、5C と適切に向き合うことである。たとえば「マネジメント」と一口に言っても、Communication や Collaboration の塩梅がマッチしないのならば意味がない。逆に、マッチさせることができたのなら、マネジメントという言葉すら知らなくても問題はないのだ。
  • 無論、実装を多く知るほど応用と創造がしやすいのも事実であり、ソフトスキル自体を軽視していい理由にはならない。ただ 5C 分類は、実装という目先にとらわれるな、という点を教えてくれる。
  • Communicaiton
  • A と B によるやり取り（A <-> B。二者間のやりとり。直接的）

• 時限切断	auto_disconnect.md

  • *時限切断（Auto Disconnect）** とは、指定時間経過後にイベント（特にミーティング）を強制切断することを指す。たとえば 30 分を設定した場合、そのミーティングは 30 分後に自動で全員が切断される。
  • すでに Zoom のブレイクアウトルームがこの機能を持っているが、時限切断はブレイクアウトルームに限らず、あらゆるオンラインミーティングに当てはめることができる。むしろ、チームの文化として採用できるものである。
  • 時限切断を使うと、全員が残り時間を意識することになりミーティングの質が潜在的に向上する。また、一度強制切断された後で再び集まる動きはしづらいため、ミーティングが無駄に長引くのも防止できる。あるいは、それでも構わずミーティングを続ける者がいた場合、それはそういう者（区切りや休憩を意識しない無能な人間）であることをあぶり出せたと言える。総合的に見て、時限切断はミーティングの体験を向上させる。
  • 最大のハードルは実装であり、時限切断を採用したいなら時間指定と切断動作の両方はシームレスにしなくてはならない。ファシリテーターがユーザーにお願いするといった人力の運用は NG である。時限切断は、指定時間が来たら一瞬で全員を切断しなければならない。そこまで徹底するからこそ「自動で切断される」とのメンタルモデルが醸成される。ここまで徹底できないのなら、時限切断を導入する意味はない。Zoom のように API 豊富な会議ツールか、そうでなければ時限切断可能な手段を別途用意しなくてはならない。
  • また時限切断に「例外的な延長」の概念はない。指定時間後に必ず切れるという世界観をシンプルに実現するため、時限切断は例外を持たない。

• カジュアル・アジャイル

  casual_ajile.md

  • *カジュアル・アジャイル** とは、アジャイル開発の本質を実践するための端的なセットを指す。またはこれらを用いてアジャイル的な営みをカジュアルに実現することを指す。
  • カジュアル・アジャイルは プラクティス のカタログであり、好きなプラクティスを取り入れれば良い。また自らプラクティスをつくってもいいし、他のプラクティスをカスタマイズしても良い。
  • アジャイルの流れは 3R で表現できる。
  • 1 Rough Plan
  • 2 Run

• Casual Framework

  casual_framework.md

  • 難解な概念 XXXX をカジュアルに取り入れるために、すぐに使える軽量な概念的道具を揃えておくことを カジュアリング（Casualing） と呼びたい。
  • Casual Framework とは、XXXX のカジュアリングを行うためのフレームワークである。
  • 1: XXXX を決める
  • 2: Casual XXXX と名付けた後、これが何のための道具集であるかを定める
  • 3: 道具を拡充していく

• カジュアル・イノベーション

  casual_innovation.md

  • *カジュアル・イノベーション** とは、イノベーションの発生確率を上げるのに使える道具集である。もちろん、コラボレーションモジュールなので、概念的な道具である。
  • カタログとして整理されているため、好きなものを取り入れれば良い。あるいは自らつくっても良いし、既存のものをカスタマイズしても良い。
  • Slack
  • 1: 時間的な余裕が 1 日 3 時間以上ありますか？
  • 2: 時間的な余裕だけでなく、2 時間以上の発散ワークを行える「認知資源的な余裕」もありますか？

• 体内時計の多様性

  chrono_diversity.md

  • *体内時計の多様性（クロノ・ダイバーシティ）** とは、体内時計を多様性と捉えて、働く時間帯もこれらを尊重したものにしようと考えるものである。
  • 具体的には次に配慮する:
  • 朝型の者は朝型の時間帯に勤務し、夜型の者は夜型の時間帯に勤務する
  • 覚醒が早い者と遅い者がいるため、各々必要に応じてその旨を知らせる
  • 朝型なのか、夜型なのかは体質として表れる。年齢に応じて変化するとされ、一般的には 20 代前半など若いうちは夜型、それ以降は朝型にシフトしていく。

• クローズドな匿名

  closed_anonymous.md

  • *クローズドな匿名** とは、クローズドなメンバーの中で匿名を採用すること。
  • たとえば 10 人が属するプライベートなチャットチャンネルがあったとする。従来であれば誰が発言したのか、リアクションしたのかはすべてわかるが、クローズドな匿名を適用すると一切わからなくなる。無論、文面やタイミングなどから推し量ることはできるが、少なくとも直接的に名前やアバターその他個人につながる情報を表示することはない。まるで匿名掲示板のように伏せられる。
  • この概念は非同期的なコミュニケーションや情報共有の量を増やすのに使える。なぜなら、私達は日頃から自他のアイデンティティを意識して行動しているからだ。これがいかに疲弊するか、また行動を遅くするかという点は、生成 AI によってある程度示されただろう。生成 AI のコミュニケーションには遠慮が要らない。人間という複雑なアイデンティティを意識しなくていいからだ。この身軽さを手繰り寄せるのがクローズドな匿名である。

• コミュニケーションとしてのタスク

  communication_as_a_task.md

  • コミュニケーションとしてのタスク（Communication As A task）とは、コミュニケーションをタスクとして捉えるという考え方を指す。CaaT と略す。
  • たとえば、メンバー A さんとマネージャー B さんが 1on1 をするとして、以下の話題を扱ったとする:
  • アイスブレイク
  • プロジェクト1の落着について（Aさんから）
  • プロジェクト2が始まりそうなので共有（Bさんから）

• コミュニケーションカーソル

  communication_cursor.md

  • *コミュニケーションカーソル** とは、コミュニケーションにおける今現在の主役を明示させるという考え方である。またはそのために使われる表示物を指す。
  • コミュニケーションは口頭と非言語により暗黙的に行われやすいが、それゆえ探り合いや発散も生じやすい。建設的にやるためには、今現在の主役を明示的に設定・可視化した上で、その主役を前提とした立ち回りを全員が行うようにファシリテーションするのが良い。この主役となる何か（人物や話題など）を指し示すものがコミュニケーションカーソルである。
  • コミュニケーションカーソルにより、全員のフォーカスがカーソル先に集中する。またファシリテーションをカーソルの制御に帰着させることができ、属人ではなく仕組みと運用でカバーしやすくなる。
  • 今現在質問を受け付ける者を指し示す。特にデイリースクラムなど短時間でディスカッションまたはその発露を出したい場合に重宝する。Aさんにカーソルを向けるとは、Aさんが回答者となり皆からの質問を受け付けることを意味する。つまり 1-回答者 n-質問者の構図であり、回答者をカーソルによって切り替える。
  • デイリースクラムへの適用例:

• コミュニケーションタイム

  communication_time.md

  • *コミュニケーションタイム** とは、関係（特に親近や親睦など「一緒に過ごす」ことで育まれるもの）を育むための時間を指す。
  • コミュニケーションという言葉は多義語だが、親近感を抱いたり親睦を深めたりするためのコミュニケーションがある。雑談が好例である。何の目的も価値もないか、薄いだけの、とりとめのないコミュニケーションだが、これには意味がある。経験値ならぬ関係値を稼いでいると言っていい。人間は関係値を稼ぎたがる生き物である。このようなコミュニケーションを リレーショナル・コミュニケーション と呼ぶことにする。
  • さて、リレーショナル・コミュニケーションは「ついでに」実施されるものでだ。具体的には出社やミーティングの形で実施される。現代であっても未だに出社とミーティングが絶えないのは、どちらもリレーショナル・コミュニケーションを兼ねた営みだからである。原始的で負荷の高い出社とミーティングは、ワークやライフの観点で見れば明らかに減らせるし減らすべきなのに、人々がそれをしないのは、関係値を稼げないからにすぎない。
  • ならば分離すれば良い。
  • 仕事は仕事として集中し、その中ではリレーショナル・コミュニケーションはしない。ただし、人間である以上、全くしないわけにもいかないから別途確保する。リレーショナル・コミュニケーションをするためだけの時間を別途確保すればいいのである。これをコミュニケーションタイムという。本当は「リレーショナル・コミュニケーション・タイム」だが、わかりづらいため略している。これでも「関係値を稼ぐためだけの時間」とのニュアンスは伝わるだろう。

• 概念ドリブン

  concept_driven.md

  • イシュー・ドリブン
  • イシュー（何らかの課題）に対処するメンタルモデル
  • ギャザー・ドリブン
  • 実際に集合することで注意を集中させ、非言語情報も多用させることで、瞬発的な高満足と前進を求めるメンタルモデル
  • 概念ドリブン（Concept Driven）

• Context First, Concrete Second

  context_first_concrete_second.md

  • *Context First, Concrete Second** とは「具体とは文脈に基づいた実装である」という考え方に則るための端的なフレーズである。
  • ビジネスでは抽象論よりも具体的な行動、計画、記述（特に定量的な情報）を要求しがちであり、具体教とは具体主義と名付けたくなるほどメジャーなメンタルモデルである。しかし具体性は万能ではないし、むしろ特定の文脈においてのみ有効となる限定的で情報でしかない。具体は文脈に紐づくものでしかないのだ。
  • したがって、以下が言える:
  • ある具体的な情報を理解するためには、その具体が参照する文脈を理解しておく必要がある
  • 具体的な何かを要求されたときは、その実装先つまりは文脈が何であるかを提示してもらう必要がある

• デイリーエリア

  daily_area.md

  • *デイリーエリア** とは、日単位で新たに作成する共用ワークスペースを指す。
  • 以下をすべて満たさなくてはならない:
  • リアルタイムな同時編集が可能な手段を使うこと
  • エディット領域であること
  • 誰の書き込みであるかを行レベルで識別できること or そのための記法を導入すること

• 意思決定アーキテクチャ

  decision_making_architecture.md

  • *意思決定アーキテクチャ** とは、チーム内で意思決定を行う際の構造を指す。
  • ここでチームとは共通の目的を向かう小集団を指し、n 人の個人から成るものである。またチームを集めたチームをつくることもできるという Composite の性質も持つ。つまり大きな組織単位であっても、チーム単位で意思決定を行う構造は変わらないと考える。
  • Star パターン
  • n 人を束ねる代表者 1 人が意思決定を行う
  • 代表者はメンバー全員とのコミュニケーションを行い、またメンバーは代表者に意思決定を仰ぐ

• デデンス	dedense.md

  • *デデンス（De-Dense）** とは脱過密を意味し、指定したしきい値の過密を超えないよう立ち回る営みを指す。
  • 過密の定義を定めねばならない。確たる正解はないが、いくつか例を示す。
  • 昼休憩の時間
  • たとえば 12-13 時の昼休憩を、同時に 50% 以上の社員が取れないようにする
  • 混雑回避や「働き方の多様性」につながる

• DevRelEx

  devrelex.md

  • *DevRelEx** とは、社内の開発者を顧客とみなして体験を最大化することに尽力しよう、という考え方である。
  • 元々 DevEx と DevRel があった。
  • DevEx（開発者体験）。機械のように直接的に生産性を最大化するよりも、開発者自身の体験が持続的に良好になるようにした方が結果的に生産性も上がる。あるいは少なくとも体験が悪いと生産性も出ない
  • DevRel（開発者との良好な関係）。開発者をターゲットユーザーとした製品開発企業が、自社製品を末永く使ってもらったり広めてもらったりするために、ユーザーと仲良くすること。イベント、グッズ、キャラクター、その他 PR など純粋な露出とエンタメ体験に力を入れる。短期的な利益は求めないか、度外視する。また口コミを狙っており、ユーザーたる開発者達のアーリーアダプター化やエバンジェリスト化を狙っている。そうなるほどのインパクトを提供することに力点を置く
  • 上述した DevRel は外部的なものであり、自社が社外の開発者をターゲットにしている。よって External DevRel と呼ぶことにする。

• ドアレス・コミュニケーション

  doorless_communication.md

  • *ドアレス・コミュニケーション** とは、いつでも誰でも自由に参加と離脱が行える同期的コミュニケーションを指す。
  • ドアレス・コミュニケーションでは、いつでも誰でも 復帰アクション を行うことでそのコミュニケーションに参加できる。また、いつでも誰でも 離脱アクション を行うことでそのコミュニケーションから離脱できる。
  • 復帰アクションと離脱アクションの定義は事前につくっておく。たとえば復帰を「復帰します」の発言、離脱を「離脱します」の発言として定義してもいいし、挙手をつけてもいい。あるいは逆に発言はなしにして挙手だけにしてもいいし、挙手がわかりづらいなら何らかのジェスチャーを設定してもいい。
  • いずれにせよ、復帰アクションや離脱アクションを検出したら、場の全員がそれに了承しなければならない。A さんが復帰した 0.1 秒後から、A さんも今現在のコミュニケーションを行う一人であると認めなくてはならないし、逆に A さんが離脱した 0.1 秒後から、A さんはいないものとして続けなくてはならない。
  • 復帰や離脱は本人の自由であり、何人も邪魔できない。いつ復帰し、いつ離脱するかは、当人が自由に決めていいし、誰にも邪魔できないのである。大事なことなので二回書いた。これを ドアレス原則 という。ドアレス原則を厳格に運用できていないものはドアレス・コミュニケーションではない。無論、復帰や離脱の乱用によりコミュニケーションが成立しない可能性があるが、その点はコミュニケーションの中でカバーするしかない。復帰に難色を示されたり、離脱を拒否されたりしないようにコミュニケーションを重ねていけ、ということだ。

• ドライな振る舞い

  dry_behavior.md

  • *ドライな振る舞い** とは、生成 AI に対する態度のようにドライに振る舞うことを指す。
  • 具体的には以下をすべて満たす:
  • 「言語で入力を与える」「その入力を踏まえて処理をしてもらうのを待つ」「処理の出力が来るので確認し、フィードバックや続きも言語化して再び入力する」のフィードバックループを行う。相手をその対象とみなす
  • 非同期的にコミュニケーションを行う
  • ドライな振る舞いは人間に対して適用することを意図している。無論、こんな非人間的な態度は通常ハラスメントにしかならないが、これが有効となることもある。

• DWMY

  dwmy.md

  • *DWMY** とは Daily、Weekly、Monthly、Yearly の略である。
  • 特に以下のようなボトムアップを想定しており、振り返りや整理など定期的な営みに有効である。
  • Daily、毎日やる
  • Weekly、毎週やる。このとき、Daily の内容を使うことでインプットが 7 個になる
  • Monthly、毎月やる。このとき、Weekly の内容を使うことでインプットが 4～5 個になる

• 体験性	experiencity.md

  • *体験性（Experiencity）** とは、快適に働ける度合いを指す。
  • 似た概念として次のようなものがある:
  • 開発者体験
  • Engineering Effectiveness
  • ウェルビーイング

• エクスプロラトリ

  exploratory.md

  • 1: ウォーターフォール
  • 2: アジャイル
  • 3: エクスプロラトリ（Exploratory）
  • ウォーターフォールとアジャイルに関する説明は割愛するが、これらは開発手法のみならずビジネス一般にも持ち込まれている。
  • ウォーターフォールは計画的と言える。厳密な計画をつくり、進捗がそのとおりに進むかどうかを管理する。計画が憲法であり、計画の質よりも計画の踏襲が目的となる。計画は管理しやすく、解釈の融通も利かせやすいため、技術と方法に優れない大多数の人類にとっては未だに有益である。辛辣に言えば、政治との相性が良い。

• 実現性レイヤー

  feasibility_layer.md

  • see: イメージ実現性

• First-Second Framework

  first_second_framework.md

  • YYYY を行うためには、実は XXXX が先であるという原則を示すためのフレームワーク。
  • XXXX First, YYYY Second の形で、XXXX と YYYY を埋める
  • YYYY を先に行いがちだという現状を整理する
  • YYYY の前に XXXX が必要であることを整理する
  • おそらく新しい概念が必要だから、適宜定義する

• Fluid Role Paradigm

  fluid_role_paradigm.md

  • see: Fixed Role Paradigm

• Four-jects

  four-jects.md

  • Four-jects とは、プロジェクト以外の活動にも頼った方が良いことを提案したものである。現代はプロジェクト・エコノミーと呼ばれ、プロジェクトの名のもとに、そのプロジェクトに合ったメンバーが来るまでマッチングを試行しなければならず、人材獲得コストの増加と不確定性に繋がっている。またプロジェクト自体の働き方も高負荷になりがちである。
  • これを解決するため、プロジェクト以外の概念をつくった。それが Four-jects である。
  • Pro + ject、前に進むための活動
  • 指定されたリソースに基づいたプロジェクトマネジメントと、静的または動的なメンバーによるチームワークから成る
  • 一時的な営みであり、始まりと終わりが必ずある

• Full Four

  full-four.md

  • 現代的な働き方を 4 つに整理したものであり、以下の略:
  • フルリモート
  • フルフレックス
  • フルアシンク
  • フルマスク

• 役割マトリックス

  gathering_spredication_management_engineering.md

  • マネジメントとエンジニアリングだけではない。さらにギャザリング（Gathering）とスプレディケーション（Spredication）が存在する。
  • マネジメントは「かたい仕事」かつ「拘束する」ものである。
  • まず、仕事としてはかたい。つまり明確なゴールと制約があるか、一見無いように見えても暗黙のうちに存在することが多い。特にマネージャーは会社の文化と上位からの指示命令系統からは逃れられない。しばしば思考停止して「上から言われてるから」「うちの文化だから」などと正当化する。ほらね、「かたい」でしょう？
  • そしてマネジメントは人と人が向き合うものであり、拘束もする。おそらくミーティングを行うだろう。ミーティングをしないマネジメント――たとえば週に一度もミーティングをしないチームや仕事を想像できるだろうか。マネジメントレスとは、そういうことなのだ。想像できまい？ゆえにマネジメントは、本質的に拘束する営みなのだ。
  • *ギャザリング** とは、やわらかい仕事をするために拘束を行う営みである。

• ホフィス	hoffice.md

  • *ホフィス（Hoffice）** とはホテル + オフィスを組み合わせた造語であり、ホテルのあり方に取り入れて設計されたオフィスを指す。
  • 具体的なあり方は各自で設計可能だが、必ず使わないといけない制約（ホフィス原則）がある。ホフィス原則にしたがって、各社レイアウトを整備する。
  • リージョン と ゾーン
  • リージョンは地理的な単位を示す。たとえば東京オフィスと京都オフィスがある場合、リージョンは東京と京都で2つある
  • ゾーンはリージョン内の単一または複数存在する単位で、一つのオフィスレイアウトを定めた単位となる。より具体的には、後述するルームのタイプと比率とレイアウトを定める

• イメージ実現性

  image_feasibility.md

  • *イメージ実現性（Image Feasibility）** とは、理解ができて、かつ運用しているイメージも湧くという意味での実現性を指す。
  • イメージ実現性は、実現性の中でも低層に位置する。以下の 実現性レイヤー で言えば、Layer1 に属するものである。
  • 実現性レイヤーは 7 層から成る実現性のモデルである。
  • Layer1 概念的実現性（Conceptual Feasibility）
  • そのアイデアは概念的に実現可能か

• Independent Parallel

  independent_parallel.md

  • *Independent Parallel** とは、一つのテーマを複数人が別々に取り組むスタイルを指す。
  • 従来のチームワークは一つのテーマに皆で協調して取り組むものであった。1-テーマ 1-アウトプットであり、このアウトプットの質とスピードを高めるためにチーム全員で一丸になる。
  • しかし Independent Parallel では、1-テーマ 1-アウトプットをひとりで行い、これが n 人分存在する。仮に 5 人チームの場合、アウトプットも 5 つである。なお、Independent Parallel の概念自体は、どのアウトプットを選ぶか、またこれらをどのように統合するかといったことは扱わない。あくまでも各人が別々に取り組む様を指す。
  • チームワークによる初期段階の探索を進化させることである。
  • たとえ探索かつ初期段階であっても、チームワークである以上、既存のコンテキストやコアメンバーとの実力差の影響を受けてしまう。本質的な探究よりも、コンテキストの理解とコアメンバーへの迎合にエネルギーを費やす羽目になる。Independent Parallel を使うと、全員が自分の城を持ちながら、しかし他の人の取り組みから影響を受けることもできる。チームワークほど政治的ではなく、個人ほど孤独でもない、バランスの良い第三のあり方なのだ。

• 個別的配慮

  individualized_accomodation.md

  • *個別的配慮（Individualized Accomodation）** は、合理的配慮の代替となる概念であり、ニューロダイバージェントを最初から特別扱いするという考え方である。
  • 元々障害者向けの概念として合理的配慮があったが、これは既存の規範に合わせるとの前提が第一にあって、その上で障害者向けにどこまで緩和するかを考えるメンタルモデルとなっている。また配慮事項検討のリードも障害者本人ではなく会社側、上司側、チーム側など定型発達側が行う。したがって配慮が足りないか、搾取になりやすい。
  • 昨今ではニューロダイバシティの重要性も増している。手帳は持っていないがニューロダイバージェントの診断を受けているとか、同じニューロダイバージェントでも IQ の違いがあって一方は適用できるが他方は適応できないといったグラデーションが生じている。障害としても、身体的に見えるものではないため、ただでさえ配慮がしづらい。合理的配慮の実情では力不足である。
  • そこで個別的配慮の概念を使う。合理的配慮とは以下の点で異なる:
  • まず、対象個人の特性を踏まえることを第一とする。たとえば 8:30 ～ 17:30 勤務かつハイブリッドワークの会社に、その生活リズムでは仕事も生活もままならない ASD がいたとする。この者は自身のライフスタイルを最適化しており、朝型で生きていて、6:00 ～ 15:00 かつリモートメイン（出社は必要に応じて、月1以内が目安）なら逸脱しないとしよう。合理的配慮だと、8:30 ～ 17:30 への適応や、ハイブリッドワークへの適応をいかにさせるかが議論となるが、個別的配慮では逆にこの者の希望をどれだけ守れるかが議論となる。同じように見えて、違う。スタートラインが違えば、結果も異なったものになる。合理的配慮だと、おそらくこの者は朝型もリモートメインもどちらも手に入らないだろう。結果、明らかに合わないライフスタイルを敷いられ、当然仕事でパフォーマンスも出せずに衰退していく可能性が高い。合理的配慮では足りないのだ。

• 昨日やった/今日やる

  kyky.md

  • *ky/ky（昨日やった/今日やる）** とは、アジャイルに進捗確認する際に使えるもので、昨日やったことと今日やることだけを書くというもの。進捗確認の場に参加する前に ky/ky を書いておき、また読んでおく。最中では ky/ky を読んだ前提で、その内容についてディスカッションする。
  • ky/ky はデイリーエリアに記入するのが良い。つまり複数人が同時編集可能なスペースにアクセスして書き込む。無論、誰がどの行を書いたかを示すインジケーターは必要である。
  • …
  • …
  • …

• Meeting As An AMA

  mama.md

  • *AMA としてのミーティング（Meeting As An AMA）** とは、AMA（Ask Me Anything）を行うためだけのミーティングを指す。 MAMA と略す。
  • たとえばマネージャーが部下に向けて、30 分の MAMA を開催するとしよう。この MAMA では、参加した文化は誰でも何でもマネージャーに質問できる。マネージャーは回答者であり、ひたすら回答を行う。
  • 回答を支援するための解説や逆質問はしてもよいが、マネージャーはあくまでも回答に徹した存在であることに注意する。MAMA は質問者のためにあるのであって、回答者はただ回答するだけだ。回答者は、自身の持つ情報と権限を役立てるために、自らを一時的に開放するのだと言っても良い。使い放題というといいすぎだが、質問し放題であるのは間違いない。
  • MAMA には 1on1 を置き換えるだけの力がある。質問と回答のみを行う時間はドライに思えるが、そのやりとりから見えてくるものも多い。雑談や関係構築を担っていた 1on1 の代替として機能するのである。無論、回答者のファシリテーションスキルが要求されるのは言うまでもない。主役は質問者であり、質問者たちの体験を最大化するために尽力せねばならない。

• 管理3.0

  management3.0.md

  • *管理3.0** とは、理想な状態で居ることを最大化できれば良いとする考え方である。
  • 管理 1.0
  • 過程を管理する
  • 本質的に搾取的である
  • 例: 1日8時間の就業を課す

• Manager As A Function

  manager_as_a_function.md

  • *機能としてのマネージャー(Manager As A Function)** とはマネージャーを機能とみなし、メンバーが必要に応じてこれを使うという考え方。マネージャーは自身の部下またはメンバー n 人に対して、機能としての自身を提供する。
  • Direct Appointment
  • マネージャーの予定表の空いているところに、誰でも自由に予定を追加していいとする
  • AMA(Ask Me Anything)
  • RMA(Request Me Anything)

• マスクド・アイデンティティ

  masked_identity.md

  • *マスクド・アイデンティティ（Masked Identity）** とは、ダミーのアイデンティティを使って過ごすことを指す。
  • アイデンティティとは、ここでは本名と性別を容姿を指す。仕事ではアイデンティティを常に開示しなければならないことが多いが、本当にそうだろうか。本人確認さえできているのであれば、アイデンティティなどどうでもいいのではないか。実際、アイデンティティによる偏見や差別その他被害は根深く、これを隠すことはエンタメ業やサービス業では珍しくない。そもそも HN やアバターといった概念は言わずと知れている。
  • マスクド・アイデンティティは難しい概念であり、要件が二点ある。
  • 一つ目は マスク の概念だ。マスクド・アイデンティティではアイデンティティとしてダミーのものを被るが、これをマスクを被ると表現する。キャラクターを演じると言ってもいい。たとえばお嬢様言葉で辛辣に本音をいうキャラクター「シャーロット」があるとして、このシャーロットを必要に応じて被るのである。シャーロットというマスクがあるわけだ。もちろん、マスクは必要に応じてつくることもできるし、同じマスクは様々な人によって使用されるし、同時にシャーロットが二人存在することもありえる。
  • もう一つが センシティブ・アイデンティティ の概念であり、これはアイデンティティを開示しないという考え方を指す。つまり、マスクド・アイデンティティを採用した組織では、同じ社員であっても、お互いの本名と性別と容姿を知らないのである。個人を識別するための ID（古典的には社員番号）は存在するし、採用時には提出してもらい会社として管理することになるが、会社の中で使うことはまずない。たとえるなら他の社員に漏らしてはならないセンシティブな個人情報のようなものである。本名、性別、容姿のすべてがセンシティブな扱いになる。無論、容姿を見せないということは、全面的にリモートワークを行うしビデオも見せないことを意味する。あるいは集まる場合でも物理的に仮面や仮装を使うことになる。

• Minimum Main Member Principle

  minimum_main_member.md

  • *Minimum Main Member Principle** とは、メインとなるメンバーを最小限に留めましょうという原則であり、以下を定義する:
  • メインとは「主たる仕事として請け負っている」ことと「意思決定権を持つこと」の 両方 が当てはまること
  • 文化的にどうしても厳しい場合は片方で構いません
  • 最小限とはできるだけ少ないこと、しかし上限でも自分を入れて 4 人以下であること
  • パターンは各自つくれば良いし、組織の数だけ色があるため、おそらくつくった方が良い。

• MPRS

  mprs.md

  • *MPRS（マピルス）** とは、主な概念的道具を並べたものである。
  • M
  • メソッド(Method)
  • モデル(Model)
  • マインド(Mind)

• No XXXX Day

  nxd.md

  • *No XXXX Day（NXD）** とは XXXX をしない日を指す。
  • 例: No Meeting Day、会議しない日。
  • 「しない」とは、その日は一回だろうが一秒だろうが一切しないことを意味する。例外はない。一瞬でも「してしまった」場合、その時点で NXD は失敗とみなす。
  • NXD は個人ではなくチーム内で実行するものである。しかし組織内――たとえば 30 人からなる部門全員に適用するのは現実的ではない。なぜなら例外が発生して容易く失敗するからだ。一桁人数以下の、小さなチームでのみ通用するべきだろう。
  • NXD の適用方法はいくつか考えられる:

• オンボーディング・アウトライン

  onboarding_outline.md

  • *オンボーディング・アウトライン** とは、オンボーディングコンテンツをアウトライナー的な箇条書きで目次化したものである。
  • markdown における例を挙げる。
  • text
  • text
  • ===

• ペアコミュニケーション

  pair_communication.md

  • *ペアコミュニケーション** とは、二人で一つの道具を使って読み書きベースのコミュニケーションを行うこと。
  • ニュアンスとしてはペアプログラミングまたそれを一般化したペアワークやモブワークと同様であり、ドライバーとナビゲーターがいて、二人で一つの同じ道具を使っている。その名のとおり、コミュニケーションを行う。
  • 使う道具は様々考えられる。アナログで言えば一冊のノートを用意し、交互に書き込むことで行える。デジタルで言えばパソコンまたはポメラのようなデジタルメモ端末を使って、交互に書き込んでも良い。ただし文字ベースの読み書きに専念したいため、パソコンやスマホといった多機能デバイスは望ましくない。
  • ペアコミュニケーションにおける成果物は「やりとりのログ」であり、したがってチャットのようにやりとりを書き合いながら掛け合っていくことになる。
  • そのためペアコミュニケーションでは口頭による会話はないか、あっても主ではなく従の扱いである。一つの目安として、文字起こししたときの文字数を L1、道具に書き込んだ文字数を L2 としたときに、L2 > L1 であることが挙げられる。

• Proposal Triad

  proposal_triad.md

  • *Proposal Triad** とは、提案の内容や表現を考えるときに使う 3 要素列挙型のフレームワークを指す。
  • 以降では例を挙げるが、自らオリジナルのリストをつくっても良い。むしろ自身やチームの暗黙知を積極的に Proposal Triad 化していきたい。Proposal Triad とは共通言語としても機能できる。
  • Q1: Why を教えて。メリット、効果、妥当性など。
  • …
  • …

• Quest-Driven Access

  quest_driven_access.md

  • *QDA(Quest-Driven Access)** とは、クエスト（何らかの操作実績）をこなした者に段階的に権限を付与していくという権限付与モデルのこと。特に全社員や全メンバーなど広域に権限を付与したい場合に使える、バランスの良いソリューションである。
  • 従来は以下の二通りしかなかった:
  • ホワイトリスト方式。必要な者が個別に承認をして手に入れる方式である。これは申請側も管理側もコストがかかるし、承認側の承認判断が通常融通が利きずらく、またボトルネックにもなりがちである。
  • オール方式。全員に一気に与える方式である。通常、これは現実的ではない。ありえるとすれば MS365 や Slack といったものであり、以下条件をすべて満たす必要がある
  • 1: すでに広く知られていること

• RAIS(Regular Asynchronous Information Sharing)

  rais.md

  • *RAIS(Regular Asynchronous Information Sharing)** とは、定期的に非同期で情報共有せよ、というもの。
  • 情報はマネージャーなど少数の上位者が握っているが、彼らは出し惜しみをする。あるいは忙しくて出す機会がない。さらに、人間を相手にした政治の世界で生きており、慎重かつ敏感なので、情報が及ぼす影響をネガティブに考えがちだ。そういうわけで、情報共有はほとんどされない。構造的に、あるいは文化的に情報格差が生じてしまう。
  • これを防ぐには、定期的に情報共有すればいい。たとえばマネージャーは週に一度、自分が参加したすべての会議から得た情報を、可能な範囲で要約して共有すればいい。フォーマットを定めてもいいだろう。ミーティングや会話一つあたり、最大 5 行まで箇条書きをぶら下げるのはどうか。ちなみに、いきなり一週間分の内容を整理するのは難しいだろうから、毎日こまめに手元で行っておくのが良い。DWMY も参照すること。
  • しかし、共有をミーティングの形で行うのは双方負荷が高い。そこで非同期的に行う。たとえば投稿すればいい。あるいはノートやウィキなどで、毎週ページをつくって、そこに書いてもいいだろう。現代は AI も使えるので、手元ですべての議事メモを書いておいて、それを AI に整理させた後、最後公開する前にチェックをしてから公開する、などでも良い。方法はいくらでもある。
  • いずれにせよ、RAIS が言っているのは次の三点だ:

• Realtime AMA

  rama.md

  • *Realtime AMA(RAMA)** とは、AMA(Ask Me Anything)をリアルタイムに行うこと。
  • AMA は通常、Reddit のような掲示板や Slack のようなチャンネルなどで回答者がスレッドを立て、その中でベストエフォートで答える形を取る。しばらくスレッドに張り付いてリアルタイムに回答することもあるが、基本的には非同期的な営みである。
  • RAMA はそうではなく、ミーティングのように同期的に行う。既存の例として、ミーティングその他イベントの最中（特に終盤）に行われる Q&A コーナーは RAMA に近い。しかし RAMA は AMA ではあるので、あらゆる質問を受け付け、答えるニュアンスが強い。Q&A とは分けて考えるべきである。もちろん茶番を演じるといったこともない。したがって、RAMA では何が起きるかわからず、回答者の力量とその場その組織の秩序が試される。
  • だからこそ、RAMA を行うことで、回答者の誠意と熱意を示すことができる。リスクを取って、何でも回答してみせるとの気概を示すことになるからだ。回答者はしばしば上位者であり、意思決定者であり、多くの情報少なくとも権限を握っている。だからこそ、RAMA を行う価値がある。むしろ行わない理由がない。RAMA は、回答者が保守的で取るに足らない人間かどうかを測る試金石としても使える。

• Rapid Q&A

  rapid_qanda.md

  • *Rapid Q&A** とは、全社員を一つの Q&A 用チャットチャンネルに参加させること。
  • このチャンネルでは質問とそれに対する回答のみを書くことができる。過去の投稿は資産とはみなさず、質問者が素早く回答を得ることのみを目指す――つまり初歩的な質問や過去扱われた質問をしても良い。
  • Rapid Q&A は従業員数千人以上の大企業を想定する。それほどの数がないと、数の力として Q&A が成立しないからである。上手く行けば、常に多くの質問が集まり、流速が凄まじくなって「頻繁に様子を見に来る場所」になる。このような場所になれるかどうかがポイントであり、そのためには、少なくとも数千以上の人数が必要なのである。
  • なお、質問と回答に特化させねばならないことに注意。雑談、教養のひけらかし、宣伝などは一切行わせてはならないし、行う者は一時的に追放してもいいくらいに有害である。また答えのない質問ではなく、答えを知っている人がそれなりにいそうなものが良い。典型的には社内に関する手続き、制度、ルール、事例といった社内ドメインの話となるだろう。
  • なお生成AIも使ってはならない。あるいは Rapid Q&A のチャンネル以外の場所で行うべきだ。Rapid Q&A はあくまでも人間のみが参加し、人間臭さが蔓延する場所でもある。それゆえに多くの人を惹きつけることができる。

• リレーショナル・コミュニケーション

  relational_communication.md

  • see コミュニケーションタイム

• Request Me Anything

  rma.md

  • *Request Me Anything(RMA)** とは AMA(Ask Me Anything) の亜種であり、マネージャーなど多くの依頼を受ける側の者が使える運用である。メンバーや部下に対して「何でも依頼していいよ」とのスタンスで、依頼を受け付ける。
  • 具体的には依頼を受け付ける機会または窓口を設置する。
  • 機会としては、ミーティングなど同期的な形で設定する。たとえば定例会議において、開始前または開始後に 20 分の RMA 時間を取って、この間は何でも依頼してもいいよ、その場で処理するよ、とするのである。次に窓口としては、単にフォームのような統一的なインタフェースを設置して、緊急を除いた、あらゆる依頼をここから行ってもらうようにする。
  • 依頼の種類はいくつかのカテゴリーに分かれるだろう。カテゴリーごとにテンプレートを用意しておいたほうが、依頼する側も、依頼を受ける側も楽できる。
  • カテゴリーは自由に整備すればいいが、参考までに Five Category を挙げておく。

• スケジュールドメイン

  schedule_domain.md

  • スケジュールは予定を扱うものと考えられているが、他の概念も使える。これを スケジュールドメイン という。以下ドメインと略す。
  • つまりスケジュール（表示ツールはカレンダーであることが多い）はドメインを表示するものであり、ドメインとして予定もあるという構図になる。もちろん予定以外もある。
  • 1: 予定
  • 2: 勤務時間
  • 3: モード

• シームレスなコアタイム

  seamless_coretime.md

  • *コアタイム** とは、ここではコミュニケーションを積極的に取りに行っても良い時間帯を指す。またコアタイム中はコミュニケーションの機会が発生することに合意する。おそらくミーティング、協調的なワーク、イベント参加などの比重が上がるはずだ。
  • コアタイムは正午を中心に、シンメトリーになるように配置する。たとえば 11～13 時、10～14時、10:30～13:30 などが考えられる。
  • 昼休憩が入っているせいで、シームフルになってしまう。
  • コアタイムが 10～14 時だった場合、昼休憩が 12～13 時だろうから、実質的には 10～12 時と 13～14 時に分かれてしまう。これでは使いづらいし、昼休憩に入らないよう神経も使わねばならない。コアタイムとして活用しづらいのである。
  • *シームレスなコアタイム** とは、昼休憩をなくしたコアタイムを指す。なので 10～14 時のコアタイムであっても、12～13 時も使える。

• 分離リテラシー

  separate_literacy.md

  • *分離リテラシー** とは、機密情報やプライバシーといった外に出せない情報（センシティブな情報）を日頃から分離しておき、情報共有特に透明性の確保を行いやすくするための基礎素養である。
  • 開発者向けには .gitignore がわかりやすい。個人設定やトークンなどをハードコードするような者は分離リテラシーが低い。逆に、最初から分離しておいて、他のメンバーも問題なく使える状態にしている者は分離リテラシーが高い。このとおり、リテラシー（基礎素養）は必ずしも実力に比例しない。優れたエンジニアでも分離リテラシーを持たぬ者はいるし、その逆もある。
  • 分離リテラシーは、このような考え方を一般化したものである。
  • 主な構成要素を挙げる:
  • テンプレート：センシティブな情報を含まないテンプレートをつくり、具体的な成果物はこれをベースにして作成し、個別に共有する。このやり方ならテンプレート自体は広く公開できる

• サーヴァント・マネージャー

  servant_manager.md

  • *サーヴァント・マネージャー** とは、サーバントリーダーシップにフルコミットしたマネージャーを指す。
  • まずマネジメントに対するスタンスには三つの段階がある:
  • Lv1: 管理・監督的なマネジメント
  • Lv2: マネジメントレス
  • Lv3: サーヴァント・マネジメント

• セブンリスト原則

  sevenlists_principle.md

  • Task Span
  • Trigger Question
  • Check Label
  • Fill
  • *セブンリスト原則** とは、概念を道具化するのに有益なリスト（箇条書き）に関する原則であり、実用の観点では、主なつくりかたの方向性が 7 つあることを示したものである。

• シンプレート原則

  simplate_principle.md

  • *シンプレート(Simplate - Simple Template)** とはシンプルなテンプレートのこと。特に以下の原則を満たしたものを指す。
  • 読みやすさのためにカテゴリーや余白が設けられていること
  • 一枚以内に収めること
  • 補足説明は別のドキュメントに移すこと
  • 補足説明へのポインタを含む注釈も一切書かないこと

• 発言キューと発言スタック

  speakerqueue_speakerstack.md

  • ミーティング中のファシリテーションを円滑にするために使える。
  • *発言キュー（Speaker Queue）** と 発言スタック（Speaker Stack） は、どちらも発言したい人が自身（を示す文字列など）を入れる入れ物である。ファシリテーターは入れ物から一つずつ取り出し、その人に発言権を与える。キューは先入れ先出しであり、スタックは後入れ先出しとなる。
  • 発言キューと発言スタックへの挿入は、ファシリテーターではなく発言者自身が行う。ファシリテーターが行っても良いが、少なくとも発言者自身が行う分を最優先かつ必須にする。これにより発言を発言者に委ねつつ、しかし発言したい者に確実に順を回すことができる。必要なら、ひとりあたりの発言時間を設けても良い。
  • また、A さんが発言している際は、もちろん A さん以外も自由に喋って良い。ただし A さんのターンであり、A さんの話している話題を落着させることを優先するべきである。そういう意味では、キューやスタックに入れるものは「話題」が良いのでは、と思われるかもしれないが、ダメだ。この概念は、あくまでも発言者が確実に発言できて、その順番がシステムによって透明になっているという心理的な保障をつくるためにある。入れるものは「人」でなくてはならない。人の名前や、実装上可能ならばアバターでも良い。
  • 使う入れ物の数と連携については、設計の余地がある。キュー一本やスタック一本といったシンプルな運用もあれば、以下のような運用も考えられる。

• スプレッダーとスプレディケーション

  spreader_engineer_manager.md

  • エンジニア。エンジニアリングを行う者
  • マネージャー。マネジメントを行う者
  • スプレッダー(Spreader)。スプレディケーション(Spreadication)を行う者
  • *スプレディケーション（Spreadication）** とは情報の拡散と発散を行うこと。元々コミュニケーション（二者間のやりとり）とコラボレーション（ワークスペースを介したやりとり）があったが、これに続く第三のあり方としてスプレディケーションを据え置いている。
  • 拡散とは、情報がまだ届いていない相手に届けること

• 非利害関係者

  stakeunholder.md

  • *非利害関係者（Stakeunholder）** とは、利害関係者でない者を指す。
  • 組織やチームで過ごしているうちは、基本的に周囲は利害関係者のみから構成される。ここで利害関係者とは広義の意味合いを指し、株主や顧客のみならず、チームメンバーや上司、同じ会社の社員や同じコミュニティのメンバーなども含む。たとえば会社員はその会社の名前を背負っており、言動次第では個人のみならず会社そのもの、その会社の社員全体に影響を与えてしまう。
  • つまり利害関係者は思っているよりも広く存在し、かつ思っているよりも大きな影響を及ぼす可能性がある。だからこそ会社員も、組織の人間も、基本的には最大限の警戒心を持つ。公の顔を演じるのは公人だけではなく、誰もがある意味は演じているのである。
  • 一方、現代は VUCARD であり、自己開示を含めた率直なコミュニケーションができると心強い。これができるかどうかが現代的な組織になれるかどうかの分かれ目とさえ言えよう。しかし周囲は利害関係者であるため「怖い」。結局、演じきることで乗り切ろうとする。事なかれ主義の一つと言えるが、この心理的抵抗感を越えてもらうのは容易ではない。マネージャーはおろか、経営者でさえもできないか、やるにしても対面で、一対一で、クローズドで、信用できる相手とだけ行う。実際、これほど技術と方法が整った現代であっても、いまだに原子的な会食が盛んなのである。これは単に利害関係者を恐れているだけなのだ。
  • そこで発想を変えて、利害関係者でない者――非利害関係者を視野に入れる。別の言い方をすると部外者とも言える。当然ながら仕事を一緒に行うわけにはいかず、何の役にも立たないように思えるが、違う。

• 静的な会議

  static_meeting.md

  • *静的な会議（Static Meeting）** とは、開催や進行の仕方をできるだけ固定した会議を指す。
  • デメリットとしては、固定された事項に従う際の摩擦とコストは発生するし、セレンディピティその他肯定的なイレギュラーも発生しにくい。メリットとしては、その都度誰が何するかを調整しなくても済むため判断コストを減らせる。また会議の質がファシリテーター依存になりにくい。
  • デイリースクラムを例にする:
  • 開催時間を固定する
  • 投影する、しないを固定する

• Structure First, Relation Second

  structure_first_relation_second.md

  • *Structure First, Relation Second** とは、組織における対人的なつながりは、その組織構造次第で自ずと決まるという原則である。
  • たとえば階層的な組織だと社員間のつながりも階層的になり、典型的には自分の上司、自分の部下、同じグループの同僚、同じチームのメンバーとだけつながることになる。またチームの中にも階層性が反映され、おそらくマネージャーはメンバー全員とつながっているが、メンバーはそうとは限らない。また、階層的なつながりに抗うことも難しく、たとえば別のチームや部門の社員にアプローチしたところで一蹴されるか、下手すると叱責されるだろう。
  • つながりは各自の主体性次第で自由につくれるとの幻想を抱きがちだが、決してそうではない。組織構造から逸脱することはできない。したがって、つながり方を変えたいのあれば、まず組織構造を変えなくてはならない。
  • この変更の能力は、ベースとなる構造に依存する。仮に階層構造がベースとなっており、社員は必ず 会社/事業本部/事業部/部門/課 のヒエラルキーに所属させられるとしよう。ベースが階層なので、変更もこの範囲でしか行えない。仮に A事業部/B部門/C課 の平社員 D さんがいたとすると、D さんはどう変更しても「ある課の下に就く」ことしかできない。これは「課内の上司およびメンバーとつながることしかできない」制約を抱えていることに等しい。たとえ 10 回ほど組織再編をしようとも、所属した課が増えるだけであって、課という域を超えたつながりを持つことはできない。D さんの能力や主体性の問題ではなく、この会社の組織構造の問題なのだ。D さんにその域を越えさせたいのであれば、この階層構造を変えるしかない。
  • しかし、何の構造もないとすれば、それは秩序がないことと同義である。やはりつながりは生まれない。あるいは勝手に何らかの構造が規定されるだろう。特にわかりやすく親しみやすい階層構造が生まれる事が多い。実際、新しいイベントやコミュニティでは、しばしばこの構造が起こるし、人々も階層しか知らないから階層的なあり方を期待するまである。

• 職人性	toolonomy.md

  • see: Collaboration Model Dimensions

• 透明主義	transparencism.md

  • *透明主義（Transparencism）** とは、透明性を重視する態度である。透明性とは過程と結果の両方がオープンになっている度合いを指し、このようにオープンにすることを 透明化 と呼ぶ。透明化とはプロアクティブであり、透明化されたものはいつでも誰でも見ることができる。「聞かれたら見せる」などリアクティブなあり方は透明ではない。ただし、公開範囲はインターネットである必要はないが、少なくとも社内全体である必要はある。事業部内、チーム内など限定的な範囲の場合は透明化とは言えない。
  • つまり透明主義とは、プロアクティブな公開に取り組む態度である。それも熱心に取り組む。例としては次のようなものである:
  • 透明デスクトップ：デスクトップ画面に相当するフォルダを常時公開したもの。Box や Dropbox のような形で同期を取る
  • 分報：自分用のチャットチャンネルをつくって、日々のつぶやきを投稿する取り組み。X のようなものである。マネージャーはミーティングではなく、分報を見て状況を把握する。ミーティングの代替にならない分報に意味はない
  • ミーティングの録画義務：オードリー・タンの取り組みとしても有名だが、ミーティングは常に録画を行い、公開しなければならないとする。これに同意できない場合はミーティングを行わない

• 真のリトリート

  true_retreat.md

  • 以下を満たすリトリートのこと。
  • 最低でも 2 泊以上の宿泊を伴う
  • 業務時間帯の半分以上は、個人で自由に過ごせる
  • 業務は一切持ち込まず、「つながらない権利を行使した休日」と同じ状態で望む
  • 持ち込めるデジタルデバイスは私物、またはリトリート用に調達した社有品のみである。業務や会社に関する情報が必要な場合は、事前に整理・加工した上で持ち込む

• アンウォール

  unwall.md

  • *アンウォール（unwall）** とは壁を壊すこと。具体的に存在している壁を一枚でも多く減らすことを指す。壁を低くするのではなく、なくすかどうかの話であることに注意したい。なくすという判断と行動をしなければならない。
  • アンウォールの概念における壁とは、特別なアクションをしないと越えられないものを指す。
  • 例:
  • Paywall
  • 支払わないと見れない

• W&P(Welcome and Prod)

  welcome_and_prod.md

  • Q&A は質問に対して回答をぶら下げるモデルだが、W&P(Welcome and Prod) は歓迎に対して持参をぶら下げるモデルである。
  • まず 歓迎コンテンツ（Welcome Content） とは、何らかのおせっかいが欲しい者がその文脈を自由に記述したものを指す。質問とは限らないし、質問が単一であるとも限らない。また文章やプレゼンとして整っている必要もなく、メモやブレストのような発散的な内容でも良い。
  • 次に、歓迎コンテンツに対しては 持参コンテンツ（Prod Content） をぶら下げる。持参コンテンツとは、その歓迎コンテンツに対する所感を指す。所感なので何でも良い。単に助言をしてみたり、不明点を挙げてみたり、自分なりに状況を理解して要約してみたり、あるいはそのコンテンツをヒントにして新しいアイデアを導いたり、など何でも良い。
  • 言ってしまえば、W&P とはお題に対するコメント全般を募集するものである。ただし以下に注意:
  • 歓迎コンテンツは情報量が多い。Q&A その他の募集ではお題は短文以内に済まされがちだが、W&P ではそうではなく、お題はできるだけ細かい方が望ましい。

• アダプタビリティ

  adaptability.md

  • *アダプタビリティ（Adaptability）** とは、その組織や仕事に適応する能力を指す。ソフトスキルの一種であり、暗黙のうちにほぼ必ず要求される重要スキルである。
  • いくらハードスキルが高くとも、その組織の文化・ルール・実態に適用できなければ戦力とはみなされない。下手をすると有害とみなされて排除されるだろう。たとえばフル出社を社員全員に化している組織に入った場合、あなたもフル出社しなければならない。これは事実上、フル出社に納得し、フル出社を継続し、またそのような現状に耐え続けるだけの能力が必要ということである。
  • 体系化されてはいないが、たとえば以下が存在する:
  • 慣例（Convention）
  • 暗黙的なルールを指す。特に社内規定そのものではなく、それを踏まえた実際の運用を指す

• 認知的コンテキスト特性

  cognitive_context_traits.md

  • *認知的コンテキスト特性（Cognitive Context Traits）** とは、人間の認知能力を「コンテキスト」でたとえて表現するモデルである。以下 CCT と略す。一言で言えば、口頭コミュニケーションに必要な短期記憶が乏しいことを「コンテキストウィンドウが狭い」とたとえる類のたとえである。このたとえを拡張して、4つの軸を用意したものだ。
  • CCT では、以下の 4 つの軸を使う。
  • Window：コンテキストウィンドウの広さ
  • 脳内で処理を完結させるために必要な情報を留めておく能力
  • 短期記憶もここに含まれる

• Collaboration Model Dimensions

  collaboration_model_dementions.md

  • *Collaboration Model Dimensions** とは、組織のコラボレーション特性を知るための 8 つの評価軸を指す。
  • 各軸は「はい」または「いいえ」で答えられる判定項目を持ち、「はい」が多いほどコラボレーションがしやすい。具体的には「はい」が多いほど多様性と持続性を確保しやすく、それゆえ融通を利かせやすくなって、個々の深い集中（木）と全体の整合・連携（森）のバランスも取りやすくなったり、役割分担も柔軟に行えてワークライフバランスの分担もしやすい。
  • ここで分担というのは、ワーク重視の者からライフ重視の者まで役割を分担しながら共存できるということである。ライフ重視にワーク重視を押し付けたり、その逆があったりはせず、各自のスタイルを尊重しながら共存できるのである。そもそもコラボレーションとはそういうものであり、そのために満たすべき観点が整理されていると考えて良い。
  • 定例会議をないかどうか
  • ないなら Yes であり、非同期的である

• コンセモニー

  consemony.md

  • *コンセモニー（Consemony）** とは合意形成主義かつ儀式主義を指す言葉である。
  • 合意形成主義と儀式主義について定義しておく。どちらも意思決定に関するあり方を指す。
  • 合意形成主義とは意思決定を権限委譲して任せるのではなく、合意形成をもって足並みを揃えていくあり方を指す。前提として合意形成を行うメンバーは全員対等である必要がある。なので、部下が上司に合意を取るといった場面は合意形成ではない。対等でないものは単なる承認である。
  • 次に儀式主義とは、意思決定は然るべき場（儀式）でのみ行うものであるとするあり方を指す。儀式とは会議またはイベントを指す。たとえ事前に根回しをしていたり、非同期で意思決定まで終えていたとしても、それだけでは決定とはみなされない。あくまでも儀式の中で取り上げることで、初めて意思決定したとみなされる。したがって儀式をしなければ前に進めない状態となり、しばしば「儀式を開催すること」や「開催した儀式が終わるまでに何らかの決定を出すこと」自体が目的になってしまう。
  • つまりコンセモニーとは、儀式の中で合意形成を行うあり方である。

• Fixed Role Paradigm

  fixed_role_paradigm.md

  • *Fixed Role Paradigm** とは、固定的な役割やポジションを定義し、そこに人材を当てはめるという考え方を指す。
  • 仕事に応じた役割が定義されている。ジョブ・ディスクリプションの形で明示的に定義されるか、あるいは明示されていなくとも暗黙的には存在する
  • 職位の概念が存在し、全社員に必ず付与される。また職位が高いほど待遇と権限も増える
  • オープン・ポジション。この概念は一見すると非固定的だが、内情は「既存ポジションのどこに当てはまるかを採用側で判断する」ものでしかない
  • Fixed Role Paradigm における、ある一つの役割やポジションをスロット（Slot）と呼ぶ。

• オープンエンド

  open_end.md

  • see reuseism.

• Paper-Trail Fair

  paper_trail_fear.md

  • *Paper-Trail Fair** とは、書いたものが残ることに対する恐怖を指す。
  • 出世競争含む社内政治に従事している者は、社内の人間関係をコントローラブルなものと捉える。逆を言えばコントロールできない事象には手を出さない。書くこともその一つであり、書いたものはいつ誰に読まれてどんな影響を与えるかが不明である。この恐怖を Paper-Trail Fair と呼ぶ。
  • Paper-Trail Fair の耐性はかんたんに判別できる。（ゴーストライターやイベントによる公式なものを除き）自身による書き込みがどれだけあるか、また広い範囲（たとえば社員全員に見えるブログや SNS など）に向けた書き込みがどれだけあるかを見ればいい。一度もない場合は耐性がないと考えて良い。
  • 組織によるが、現代において書いて残す、書いて伝えることのメリットは明らかであり、これを一度もやっていないというのは意図的に避けていることも他ならないからである。
  • 特に社内政治とは相性が悪い。そういうわけで、書き込みがほとんどないか、全く無い者は、社内政治に従事している可能性が高い。社内政治の従事者というと出世競争に明け暮れた妙齢をイメージするが、Z 世代でくくられるような若者も含む。特に静かな退職の文脈で「いい子症候群」と呼ばれたり、日本人の気質として「和を乱すことによるデメリットを受けたくないから仕方なく迎合しているだけであって個人主義」と考察されたりするが、令和の若者もまさにそうで、すでに組織が政治的であることを知っているため表面上は真面目に取り繕い、余計なことは一切しないのが標準的なスタンスとなっている。

• プロジェクト・パラダイム・マトリックス

  project_paradigm_matrix.md

  • see Exploratory.

• PWEP

  pwep.md

  • *PWEP** とは Powerpoint、Word、Excel、PDF の総称であり、コラボレーションの拙さを示す黄色信号とみなせる目安である。
  • コミュニケーションや情報共有においては、QWINCS やプレーンテキストなど、よりコラボレーティブに行える手段がすでに揃っている。にもかかわらず、古典的な PWEP に固執しているのは、自転車やバイクがあるのに車しか使わないようなものである。数百メートル以下、場合によっては数十メートルの近距離移動であっても毎回自動車を使うくらいに馬鹿げたことなのだ。
  • PWEP は正式な文書や高度な計算（Excelの場合）には重宝するが、その前段階の、組織内で完結するような大部分の仕事ではもはや不要である。PWEP を使っている、特に重用している組織があるとするなら、その時点で黄色信号なのである。

• QWINCS

  qwincs.md

  • *QWINCS** とは主なコミュニケーションツールを整理したアクロニムであり、以下の略:
  • Q&A
  • Wiki
  • Issues（チケット型）
  • Notes

• 流用主義	reuseism.md

  • *流用主義（reuseism）** とは、報告や提案を行う際の資料を常に流用ベースでつくろうとする考え方を指す。
  • 再利用や拡張がなく、手間なく済ませられる場合なら良い手段だが、そうでない場合は有害となることが多い。なぜなら作成者本人が自分の思考と検討を使わず、他人の内容に乗っかって、ツギハギ的に見せているだけだからである。また、特にスライドの場合はビジュアルが豊富であり、仕事した気になっても良いとの暗黙的な合意が形成されやすい。
  • 主従を見ればいい。流用した資料を主にして、どのように説明するかを組み立てると考えるのは流用主義的である。逆に、流用した資料はインプット程度に使い、後のコンテンツは自身で改めて構成するのであれば、流用分は従であり、流用主義的ではない。最もよくあるパターンとして、既存の調査結果や論文や影響力のある人物の発言などの資料を持ってきて、それらを組み合わせて主張するものがあるが、これはグレーか流用主義と言っていい。一見すると妥当であり、多くの場合は実際に最適解だが、意思決定が反映されておらず、知識のコレクションまたはそれを自慢するコレクターと大差ないためである。
  • そういう意味では、もう一つの目安として「自分なりの意思決定が組み立てられているかどうか」も使える。組み立てられていないか、流用先の意思決定しか見られない場合は流用主義的である。逆に、流用主義的でないなら、その人自身の意思決定が必ずメインの扱いで主張されているはずだ。
  • 流用主義者は、作業や政治を進めるのは早い傾向にあるが、オープンエンドな仕事には向いていない。オープンエンドでは自身の開示も含めた深い思考を行い、仮説をつくって、それをぶつけて検証していく必要があるためだ。別の言い方をすれば、そういったアプローチが苦手か、意図的にやりたくないと考えているため、流用に逃げているとも言える。そのような受動的な者にオープンエンドは務まらない。

• 3つの壁	three_walls.md

  • *3つの壁（Three Walls）** とは、やりたいことを阻む壁を 3 つ述べたものである。
  • 論理的に網羅的である必要はなく、おおよそ誰が見ても納得できる程度の壁を適当に言語化すれば良い。
  • 壁に順番がある場合は番号をつける。逆に、順不同な場合は番号はつけない。
  • 3つの壁が提示するのは「壁を持続的に越えられるほど優秀でなくてはならない現実」または「根本から変えることの必要性とどこから攻めるかを考えるためのヒント」である。つまり3つの壁は、人員を選ぶ際のフィルターまたは根本から改善または変革する際の足がかりとして使える。
  • 一方、個人レベルの短期的な改善や成長のために使うことはできない。壁を個人レベルで短期的に越えるのは非現実的だし、仮に越えられるならそもそも（その人にとっては）壁とは言えない。3つの壁はむしろ、個人の努力ではどうにもならないものを端的に言語化し、折り合いや割り切りをつけるための道具である。割り切るために言語化するのである。

• トランスフォーマトリー

  transformatory.md

  • see: Casual Innovation

• VUCARD

  vucard.md

  • 現代は VUCA といわれるが、さらに追加すべき要素がある。
  • Remote
  • 現代の生活水準は向上し、出社はもはや前時代的になりつつある
  • 権力者や仕事中毒は引き続き出社させたがるが、いつの時代も不都合な水準を押し付ける動きはありえるので相手にしてはならない
  • リモートを前提にしなければならない。常にフルリモートで良いわけではないが、フルリモートが当たり前でもおかしくはないし、少なくともハイブリッドにはするべきだ。もちろん、必要ならフル出社でも良い。ただ、それでもデフォルトはリモートに寄せるべきだ

This site is open source. Improve this page.