「　もう一回　階層について　記事を書くぜ」

「　熱心だな」

「　失敗しただけ、要らん記事が量産されてるのよ」

命令を出す者

Commander

「　まず、コマンダー（Commander）は、別のコマンダーへ、コマンドを出せるぜ」

「　👆　絵にすると　こんな感じだな」

階級は全順序

「　👆　で、コマンダーには　階級というものがあるぜ。
階級が上のコマンダーは、階級が下のコマンダーに　コマンドを出せるぜ。
階級が下のコマンダーは、階級が上のコマンダーには、コマンドを出せないぜ」

「　序列があんの？」

「　上と、下が　ひっくり返ることはないぜ。全順序」

下のコマンダーから上のコマンダーへの向きは、報告を上げるだけ

「　👆　階級が下のコマンダーが、階級の上のコマンダーに投げれるものは
レポート（Report）でも呼ぶとしよう。
ここで、階級が上のコマンダーは、レポートを読んでも、
コマンドを送り返すことは　しないことにしろだぜ」

「　レポートを受け取ったら　すぐにコマンドを出したいような
決まりきった処理だって　あるんじゃないか？」

「　👆　Bという報告を受け取ったらAという命令を出すコマンダーと、
Aという命令を受け取ったらBという報告を返すコマンダーが　コンビを組むと
インフィニティ・ループ（Infinity Loop；無限ループ）に陥る」

「　じゃあ　階級が上のコマンダーは　階級が下のコマンダーに　もっと働いてもらいたいと思っても、
レポートを受け取ることしかできないのかだぜ？」

「　階級が下のコマンダーが　もっと働くというのが　おかしいんだぜ。
階級が下のコマンダーは、階級が下なりの、それなりのことしか　しないぜ」

部下の名前は知ってるが、上長は誰か知らないかのように作れ

「　👆　プログラムでは、
部下の名前は知ってるが、上長は誰か知らないかのように作れだぜ」

「　そんな　マヌケ　な部下でいいのかだぜ？」

「　マヌケなのがいいんだぜ」

「　上長が　すり替わっても　仕事はできますもんね」

末端の部下に、組織全体をひっかき回すぐらい仕事してほしいケースがよくある

「　👆　でも　プログラミングやってると、
一番末端の部下に　組織全体をひっかき回すくらい仕事してほしいケースが　よくあるのよ」

「　設定ファイル　書きかえるボタンとかな。
上長の言うことが変わるような権力を　設定画面が持ってたりするな」

「　設定画面は　上の方の　上長にしないといけないよな」

「　でも　みんな設定したいのだから、末端にいてほしいのよ」

「　インフィニティ・ループが始まってしまう」

「　じゃあ仮に　リバース・ワーカー（Reverse worker；逆転する作業員）とでも造語しよう。
リバース・ワーカーをいないようにするのが　優れた階層だぜ」

「　👆　リバース・ワーカーは　上位に置けだぜ」

判定ラインは？

「　どいつが　リバース・ワーカーで、
どいつは　部下にコマンドを送っているつもりが、リバース・ワーカーに
レポートを上げることになった末端のコマンダーなんだぜ？」

「　考え方が逆だぜ。
末端作業員の　ボトム　から確定していって、
最後の方まで残る　余り　のようなやつが　リバース・ワーカーだぜ。
その　リバース・ワーカー　が、ボトムにいたら　プログラムは崩壊するんだぜ」

データとプログラム

「　👆　コマンダーって、自分の裁量で扱えるデータと、そのデータをどう扱うかのプログラムを持ってると思うけど……」

「　👆　そのデータと　プログラムも　階層構造になってると考えると」

「　👆　上長になるほど　バカデカくなって、　部下は　ちょっとのことしか　できなくない？」

「　それが理想だぜ」

「　優秀な部下が　勝手に動いてくれないと　忙しい上長は　楽できないんじゃないか？
めんどうな仕事は　部下に押し付けるのが　組織なんじゃないか？」

「　デベロップメントでは　逆だぜ」

「　コントロール可能で簡単なことしかしない部下と、コントロールする上長にしろだぜ」

「　造語すると、ビッグ・ボスと　スモール・メンバーだぜ」

上長が持ってるデータをほしい部下

「　👆　部下が仕事するには、上長が持ってるデータが欲しいときがあるでしょ」

「　よくある」

「　命令だけじゃなくて、データも　よこしなさいよ」

「　リバース・ワーカーになるのでは？」

「　上司の持ってるデータを　部下に渡すと　部下が　でかくなるぜ。
上司がデータを部下に渡すのが　階層の序列崩壊の始まりだぜ」

「　部下の仕事が進まないんだけど」

「　部下が、 上司が持っているデータが無いと進められない仕事　を持っていることが　おかしいんだぜ」

「　じゃあ、部下にやってほしい仕事の多くを　上司がやることにならない？」

「　プログラミング　の中の価値観では、そうなるぜ」

「　リバース・データ（Reverse Data）とでも造語しよう」

「　競技プログラミングのようなものは除くが、
大きな組織を作るときは、リバース・データは　しないことが重要だぜ」

横のデータがほしい自分

「　👆　上司のデータは要らないけど、同僚のデータがほしい場合は　どうすんの？」

「　厳密には、横だと思ってるやつが　本当に横かは分からない。
自分のボスが誰かさえ　自分は知らないからな」

「　悪の組織みたいだな。密輸でもしてんのか」

「　👆　とにかく　他の人のデータがほしいとき　どうすんの？」

「　部下以外から　データを引っ張り出してくると、リバース・ワーカーのできあがりだぜ」

「　👆　仕方がないので、解決方法としては、まるで　共通の部下がいるような　下位の部下を置いて、
隣と共有したいようなものは　下位の部下に置き、見知らぬ上長同士で　共有することだぜ」

「　ツリー構造が　破れるな」

「　全順序の方が重要だぜ」

「　その　Common　のデータは、本来　上長が持っておくべきものを　部下に渡しただけじゃないの？
なんでもかんでも　Common　にデータが置かれて、
Common にアクセスできるコマンダーは結局、リバース・ワーカーになるんじゃないの？」

「　Common に置くのは　あくまで　同僚間で共有するであろうデータだぜ。用法を間違えば　階層の序列は崩壊する」

「　このトピックに名前を付けておくと、　コモン・オブ・ヒエラルキー　とかどうだぜ？」

コモンが　めちゃくちゃ　でかくなる

「　お父ん。ほとんどのコマンダーが　自分の持っているデータを　Common　に下げてしまい、
Common　が　リバース・ワーカーになったぜ」

「　横　とは　密　になるわよねえ」

「　ネットワーク状になるんだろ。ヒエラルキーを侵食していくぜ」

「　あるところは　密なネットワーク　で、
あるところを部分的に見ると　全順序　で、
全体としては　半順序　な、
そのような　機械的には収束しない、　振動する不定形なモデル　を想像しないと　いけなくない？」

「　現実的にはそうなるか。　しかし　なんらかのあるべき状態へ戻ろうとするちから　が働かないと　序列は崩壊するぜ」

メンバー・ネットワーク

「　👆　ぐちゃぐちゃの　密結合を認める空間、 メンバー・ネットワーク （Member Network） を認めることにするぜ」

「　Member Network って文字数が １３文字もあって長いので、短くならないの？」

「　同僚なら Colleagues、部下なら Subordinates でどうだぜ？」

「　長い」

「　同僚なら Co、部下なら Sub でどうだぜ？」

「　今度は短すぎる……」

「　文字数は Member Network よりマシだから、変数名に困ったら Colleagues と Subordinates を使うことにしましょう」

「　Member Network　は単に　Members　で十分よね」

「　分かった、分かった」

メンバー・ネットワークを認めるのなら、Common は要らんのでは？

「　メンバー・ネットワークを認めるのなら、Common は要らんのでは？」

「　まったくだぜ」

話しを覆すが

「　👆　上長と　部下の間に　Members という名前の　メディエーター（Mediator；仲介者）を置くことにするぜ」

「　なんでまた」

「　ネットワーク構造は　すぐ　スパゲッティー・コードと化す。
ネットワーク構造を不可とし、ヒエラルキー構造を　強制させることにするぜ」

「　今度は　Members　メディエーターに　コードが集中してくるんだけど」

「　上長と　部下を　シンプルにして、　Members メディエーターに　密結合を　押し付けろだぜ。
押し入れみたいなもんだぜ」

「　部下のコードが　Members メディエーターに取り上げられて、
部下は　なんにも隣と連携しない　木偶の棒　みたいになってしまうぜ？」

「　それでいい。それが理想。疎結合。あるべき姿」

ソース・フォルダーの使い方

　　📂 Ramen Project
　　└── 📂 Models
　　　　└── 📂 Book
　　　　　　└── 📄 MemoModel

「　👆　ヒエラルキーを作ると、フォルダー階層が深くなるのよねえ」

「　ファイルパスは　文字数上限　２５６文字の壁がある。
　　フォルダー階層を作る方法は　いずれ　行き詰る」

「　じゃあ　ソースはどう配置したらいいの？」

「　例えば、悪い方法から見てみよう」

悪い方法：テレスドン

「　👆　例えば　上図のような画面遷移があるとしよう」

悪い例：

　　📂 SiteMap
　　├── 📄 Portal
　　└── 📂 Portal
　　　　├── 📄 Introduction
　　　　├── 📄 Downloads
　　　　├── 📂 Downloads
　　　　│　 ├── 📄 Windows
　　　　│　 └── 📄 Linux
　　　　└── 📄 FAQ

「　👆　例えば　サイトマップの階層を　そのままフォルダーを使って表すのは　悪い例だぜ。
わたしは　こんなことをする人を　テレスドン　と呼んでいる」

「　テレスドンには　風評被害だぜ」

「　ファイルパスの　２５６文字制限は　わりとよく　ぶつかって
深い階層のフォルダーで　圧縮ファイルを解凍したとき、ファイルを破損したりするぜ」

「　じゃあ　どうすんのが　ベスト・プラクティスなの？」

「　👆　ひとまず、流し込むコンテンツが違うだけで　同じテンプレートでいけるだろ、という画面は
１つにまとめるぜ。
わたしは　これを　タイピング　と呼んでいる」

良い例：

　　📂 Pages
　　├── 📄 ByOS
　　├── 📄 Downloads
　　├── 📄 FAQ
　　├── 📄 Introduction
　　└── 📄 Portal

「　👆　あとは Pages フォルダ―を作って、その下に　ABC順で　フラットに並べるだけだぜ」

「　階層構造が　分かんなくない？」

「　そんなものは　設計書か何かに書いておけだぜ」