Mogicはかんがえる

組織を情報として書きなおす

ふと、IT企業らしい思考実験をしようと思いつきました。

まず組織のあらゆるものを「情報の流れ」に変換できると仮定します。

要はメールや打ち合わせの内容、たわいもない日常会話、教えたり学んだりすること、新しく人を採用すること、見知らぬ誰かに知ってもらうこと、見積書や契約書を作ること、請求書を発行し入金を確認すること、資金繰りをすること、オフィスの設備や就業規則を整えること、勤怠時間をチェックすること、セキュリティを強化することとか、あらゆることを「情報の流れ」とみなします。

その上で、もしすべての情報を俯瞰できる立場ならどうルーティング（経路設計）するのが最適かという問題になります。

これは組織のトップだからすべての情報を閲覧できる権限があるという意味ではなく、本当にすべての情報に接しているという仮想の状態です。

普通の仕事現場なら1人の視点でやってくる情報を逐次処理するだけでいいのですが、このケースだと全員の情報を同時に把握しているのが難しいところです。

仮に10人の組織で1日分だとしても、すべての情報量を単純に加算すると膨大な量になるでしょう。

さらに時間の経過とともに今の情報が新しい情報を連鎖として生み出すため、放っておくと（直線か曲線かは別として）線形に累積されていきます。

何もしなければ、たくさんの未読メールが溜まってしまうイメージです。

はてさて、どうするのがいいのか。

1つ目に、取捨選択＆優先順位の手法を考えます。

あらかじめ情報の粒度を決め、適切なサイズに分割します。

分割したものを組織全体への影響度というモノサシで優先順位をつけます。

1部門より複数部門に影響があるものを上位とみなします。

優先順位の上位から選び出し、下位の範囲は捨象する。

そうすれば、上位の優先順位だけに注意というリソースを充てればいいので情報量を減らすことができます。

ただし、リスクが残ります。

組織全体という一つの視点からは影響度が小さいと思えても組織外の社会からみれば影響度が大きいものを見逃す可能性があります。

これをトップダウンな「単一視点の罠」と呼ぶことにします。

2つ目に、ノード＆フィルタリングの手法を考えます。

ハブ・アンド・スポークとなる重要なノード（結節点）を決めて、そこにフィルタリング（選別）の機能を設けます。

平たくいえば、メンバから部門長に情報が集まり、部門長が総合的に判断してさらに上位のノードに情報をあげていくということです。

ノードが階層構造をとるなら、ステップを経るほど情報が減衰します。

これもリスクがあります。

重要なノード周辺だけで部分最適した判断をしやすく、階層があったりノード同士の距離が離れている場合に情報が遅延しやすい課題です。

部分最適されたノードごとの情報が時間差で届いて、結果として全体としての方針を決めるのに時間がかかり、悪い影響が拡大する可能性があります。

これをボトムアップな「多重ノードの罠」と呼ぶことにします。

3つ目に、冗長性＆圧縮の手法を考えます。

送信するパケットを最少化するために情報理論で使われているものを応用します。

すべての情報のうち、類似する部分を同一とみなしてデータを圧縮します。

X＝｛A，A'，A''，A'''，B，B'｝という情報があるなら、{A*4，B*2｝みたいにした方が短くなります。

ですから、すべての情報のうち似ているものを冗長とみなし同一とすれば圧縮できますから、全体の構造を維持しながら情報量を減らすことができます。

これにもリスクがあります。

あまりに多くの部分を類似とすれば圧縮率が高くなりすぎて、到達した先で情報を理解できなくなる恐れがあります。

かといって、解像度を上げて分解能を高めすぎると圧縮するところがない。

つまり、何をもって類似とするかしないかの基準が難しいということです。

これを解像度による「冗長性レベルの罠」と呼ぶことにします。

紙面の都合上、これ以上展開できないので強引にまとめに入りますと

10年前、20年前と比較して組織内の情報は圧倒的に増えているわけですから、新たな問題が起きたらいろんな罠に怯えることなく、幾何学や分類学としての組織図より情報学としての組織網に取り組むべきなんじゃないかという提案です。

再帰（リカージョン）する物語

エンジニアと話していると「再帰（リカージョン）は、構造を見極めることが大事です」となります。

ということで、今回は再帰を使ってちょっと遠出してみようと思います。

まずは前提条件の再帰の定義より

ーーーーーー
再帰（リカージョン）
https://w.wiki/3TjR

再帰（さいき、英: Recursion, Recursive）とは、ある物事について記述する際に、記述しているもの自体への参照が、その記述中にあらわれることをいう。

略

平行な合わせ鏡の間に物体を置くと、その像が鏡の中に無限に映し出される。このように、あるものが部分的にそれ自身で構成されていたり、それ自身によって定義されている時に、それを「再帰的(Recursive)」だという。

略

言語学者ノーム・チョムスキーらは、言語において適格文の数に上限がなく、適格文の長さにも上限がないことは、自然言語での再帰の結果として説明可能だと論じている。

略

手続きや関数といった概念をもつプログラミング言語では、ある手続き中で再びその手続き自身を呼び出すことを認める場合が多い。これを再帰呼出しといい、階乗計算やフィボナッチ数列のように、本来再帰的な構造をもつアルゴリズム（再帰的アルゴリズム）を記述するのに適している。

略

ある大きな部位が複数の小さな自己相似に分岐する構造（フラクタル）など、再帰的な過程によって生じたと思われる形状が、植物や動物で時々見られる。野菜のロマネスコがその一例である。

略

ロシアで生まれたマトリョーシカ人形は、再帰という概念の物理的造形例で、日本ではこうした形式を「入れ子細工」とも呼んでいる。

略

マウリッツ・エッシャーによる1956年の作品 (Print Gallery (M. C. Escher)) は、再帰的な絵を飾った画廊を含む歪んだ都市を描いた版画で、無限に堂々巡りする構図となっている。
ーーーーーー

踏まえると会社の経営は、極めて再帰的だなと感じます。

似たような単語に「回帰」があり、それは「もとの位置または状態に戻ること、あるいはそれを繰り返すこと」であることから、やはり経営は再帰だろうと。

分かりやすく例えてみます。

今日は財務について考えようと思い、本を読んだり、話を聞いたりします。

ひとしきり悩んで、この方法が最善だと思って行動に移します。

3ヶ月後に、いま一度財務について考えます。

すでに前回考え尽くしていますが、もう一度見渡します。

違う角度から思わぬ課題が見つかり、取り組むことにします。

そうして3ヶ月後に、さらにもう一度財務について掘り下げます。

もうないだろうと思っていたら、また新しい課題を見つかります。

ただの同じ状況じゃなくて、これまでの構造を使ってクルッと戻ってくる。

飽きることなく、テーマからテーマへと放浪しながら、帰ってくる。

だから自分にとって、経営は“続けられる物語”なんだろうと思っています。

あらゆる「成長」を聞かれる

数ヶ月に1回の代表インタビューがやってきました。

今回は早いもので最終回。

あらゆる角度から「成長」について聞かれました。

意外と成長って言葉にするのが難しいですね。

ーーーーーー
- 最終回、ちょっと緊張しますね。それではまずMogicのこれまでの成長をお聞きします。最初は1人でコンサルティングされていたと聞いています。そのままでも良かったのに、なぜ人を増やしていこうと判断されたのでしょうか？

山根：株式会社として登記したので、どこかで他の人と一緒にやっていくと決めてました。

ですけど、数人で会社をスタートさせたら固定費が重くなるんです。

人件費や家賃といったものです。

それを賄いながら軌道にのせるにはたくさんの資金を最初にがんばって準備しないといけなくて。

もう少しゆるっと考えながらやりたかったので一人で始めたんです。

幸いなことに友人や知人から仕事をもらい、数ヶ月でうまくいけそうだったのでチームを組んでいきました。

成長していこう！というより、やれることをもっと増やしたいというぐらいの感覚でした。

- 起業されてから自分たちのブランドサービスを始めるのに1年ほどかかっています。自社でサービスを始めるにあたり、何が必要だったのでしょうか？

山根：結局、何もかも自分たちだけでサービスを作って、広げるって大変なんですよ（笑）。

当たり前ですね。

ビジネスになりそうな分野を選んで、企画を練って、人を集めて、資金をやりくりして、スケジュールを管理してから、ようやくリリース。

さらにそこからが本当の勝負です。サーバのランニングコストはかかるし、開発もプロモーションもマーケティングもしないといけないけど、時間もリソースもそこまで割けない。

なので、いつもどうすれば最少の工数で軌道に乗せられるかなと模索してたんですね。

会社に所属してサービスを作るのとはぜんぜん違うので、自分たちのリソースを注意深くやりくりして次第にうまくなっていった気がします。

ーーーーーー

そんな感じでロングインタビューはただいま絶賛編集中です。

【後日追加】インタビュー記事の続きはこちら
https://www.mogic.jp/category/interview/14033

フェイルセーフ、スルーセーフ

機械をいじっていると、よくフェイルセーフという単語に当たります。

いうなれば、故障しても怪我しない仕組み、ということでしょうか。

膨らませるために、Wikiより引用します。

ーーーーー
フェイルセーフ
https://w.wiki/3VNK

フェイルセーフ（フェールセーフ、フェイルセイフ、英語: fail safe）とは、なんらかの装置・システムにおいて、構成部品の破損や誤操作・誤動作による障害が発生した場合、常に安全側に動作するようにすること、またはそう仕向けるような設計手法で信頼性設計のひとつ。

これは装置やシステムが『必ず故障する』ということを前提にしたものである。

略

飛行機の場合は、エンジン故障で全推力を失っても滑空して無事着陸できる設計であればフェイルセーフである。

ヘリコプターのエンジン停止においては、オートローテーションという飛行方法により飛行機同様滑空して着陸することができる。

略

ヒューズは、過電流が流れた場合にヒューズ自身が溶けて壊れることにより、それ以上の過電流を止めて基板等の焼損や出火を防止する。

この点で、電気回路にヒューズを挿入することやヒューズそのものも一種のフェイルセーフであるといえる。
ーーーーー

『必ず故障する（間違う）』ということを前提に置いておく。

この考えは会社の運営やマネジメントでとても重要だと感じています。

いうまでもなく、組織や人はしょっちゅう間違いますから。

意図するしないに関わらず、間違っちゃうんですね。

そんなそばから、さっき2つ間違えましたし。

と、そんなことなら

間違いなく、間違いありきで組み立てるしかない。

たとえミスがあったとしてもうまくやれる制度や雰囲気を作る。

それが自分の考える経営なのかなと。

だったらと口に出してみれば

誰かが間違えたらほかの誰かが指摘できるような環境を目指しつつ、それでも気まぐれな人間という存在が指摘するという行為を忘れてしまわないよう、システムで自動的に検知する仕掛けを入れながら、そもそもそのシステムを設計する段階で間違いの可能性を見落とさないために、普段から月1時間ほど「みんなで間違い探し」する時間を設けてみるものの、もちろん万全ではないし、むしろ起きてしまった間違いを別の意味で正解と捉え直すようなゆとりを保つこと

となってきてしまい

そんなことになれば

「はじめから失敗を口にするなんて縁起でもない」
「ダメなことを思い浮かべれば悪い流れを引き寄せてしまう」
「今まで大丈夫なんだから、あえて粗探ししなくていいんじゃない」
「複雑に考えずにさ、出たとこ勝負だよ」

なんて言われたりすれば、俄然、馬の耳に念仏なフリ。

じゃないと、ずっと後になって

「流されずにもっと考えておけば良かった」
「やれるって、みんなで盛り上がったし」
「勢いが一番大事だと思ったんだけど」
「まさかそうなるとは思わなかった」

と、言いたくないですから。

一見、正しそうな意見でもピンとこなかったらスルーしてもセーフなんじゃないでしょうか。