編集と真贋
情報は自分自身が直接体験する以外だと、他人による編集を介したものしか受け取ることができない。
編集とは全体から一部を切り取ることであり、かつ、加工することである。
人間は森羅万象をすべて把握することも表現することもできないし、人から人に伝える時点で何かしらは抜け落ち変質する。
人を経由すると、ただそれだけで「編集」された情報となる。
よって我々がメディアを通して受け取る情報はすべて「編集」されたものになる。
そして、「編集」フィルターで情報を濾過すると物事は捉えやすくなる分、情報の鮮度、質、正確性は落ちる。
以前言及したデータサイエンティストは情報の編集者とも言える。
対象のエントリで述べたように、利用する情報の取捨選択と加工のさじ加減でいかようにも表現を演出することができる。
先月の割合が30%で今月の割合が50%になっている事実を提示して「先月より増えている」と言われれば「ああ、たしかに」と勢いで頷いてしまうかもしれない。
しかし割合ではなく実数値だと先月が60で今月も60であり、全体の中の割合が変わっただけの可能性もある。
実際には変動していないのに提示する情報を操作すれば「増えている」という印象を植え付けることができてしまう。
全体の中の一部分だけであっても、それがそのまま事実として伝えられているならまだマシなほうだ。
子供の頃にした伝言ゲームを思い出してみてほしい。
最初に決めた文章から人を仲介すればするほど、どんどん元の文章から内容が変わっていってしまう。
最後の人の文章と元の文章が全然別物になっていて「ぜんぜん違うやん」などといって盛り上がっていたと思う。(優秀なチームは一字一句違わず正確に伝えきっていたけど)
人を経由すると意図をしていなくても情報の精度は落ちてしまう。
さらに意図を持った編集を経由した情報は往々にして形が歪められ、素材となる情報とは違った解釈を生むようになる。
むしろ編集を利用して自分に都合のいいような解釈を意図的に付加しようとする。
先日「ソニー、プレイステーション5予約の事前登録を開始。徳の高い順に招待、米国内のみ」というタイトルの記事がバズった。
ソニー公式のFAQを読むと「PS5予約の事前登録を開始」と「米国内のみ」はちゃんとその通りの文章が書いてある。
しかし「徳の高い順に招待」とは書いていない。
実際に書いてある文章は
Our selection is based on previous interests and PlayStation activities.
で、この文章を拡大解釈して「徳の高い順に招待」と言い切っている。
公式文章から読み取れるのは「招待する人はPSユーザーの過去の行動と関心をもとに判断する」までだ。
記事内の文章には
過去に実在のプレーヤーとして登録や購入などの行動が確認できたかでフィルターする趣旨と思われます。要するにPSに功徳を積んできたかどうか。
と書いてあり、過去に実際に購入したかどうかでフィルタリングするんじゃないか、という真っ当な予測をちゃんとしている。
しかしそれがなぜ「功徳を積んできたかどうか」に飛躍するのか。
タイトルを見ただけの人は「これまでのソニーに対する課金額が多い人からPS5予約できるのか」や「徳の高い順とはなんぞや？」といった好奇の目を持つことになる。
人からの関心を引くためにあえて「徳」という単語を使い、公式が全く言っていない「徳の高い順に招待」とまで言い切ってしまうと、もはや編集を通り越して虚偽だ。
編集された情報は意図の有無に関わらず、その情報だけを元に事実がそうであると早合点してはいけない。
自分 ↑←─[編集(個人ごとの解釈)] タイトル ↑←─[編集] 内容(2次情報) ↑←─[編集] 出典元(1次情報) ↑←─[編集] 現実
情報は実際の現実から自分に届くまでにこれだけ編集の洗礼を受けることになる。
真実に迫るためにはタイトルだけでなく内容をよく読まなければいけないし、出典(ソース)を当たらなければいけないし、最終的には自分自身の手で確認しなければいけない。
間に編集が挟まれるたびにコンテキストが消費され伝言ゲームのごとく情報が歪んでいってしまう。
自分が受け取る時点の情報は真贋すら危ういと認識しておく必要がある。
Tag: コミュニケーション
マイクロサービスの神話
今回は『人月の神話』の「第2章 人月の神話」のパロディです。原文を比較しながら読むとより楽しめます
システムのリプレイス案件があった場合、自然(特に最近では)な対応としてマイクロサービスを採用することがある。
火に油を注ぐがごとく、この対応は事態を悪化、それもかなりひどくする。
火が大きくなればガソリンをもっと欲するように、悪循環はこうして始まり、結局大失敗に終わる。
マイクロサービスはアイデアとして、時間と人の制約を受けずに、設計者の頭の中で完成した形で生まれる。実現されるとき、時間と人の制約を受ける。
私たちのアイデアの不完全さや不整合性は、実現段階になって初めて明白になる。
多くのシステムにおいて運用は扱いにくいものだ。
運用の物理的制約(や法的制約)が、表現できるアイデアを束縛し、実現段階での予期せぬ困難を作り出す。
プログラマは純粋な思考から、マイクロサービスとそれについての非常に柔軟な表現を組み立てていく。
実現も難しいことはほとんどないと考えるようになって、そこから楽観主義が広まる。
しかし、私たちのアイデアに考慮漏れはつきものであり、思ってもいなかったコストが生じる。
単一のサービスにおいては、まさに計画どおり事が運ぶかもしれない。
しかし、マイクロサービスは複数のサービスから構成されており、そのほとんどが複雑に絡み合っている。
この場合、すべてのサービスがスムーズに連携できる確率となると、限りなくゼロに近くなるほど小さい。
システムの運用においてマイクロサービスは、疑うべき危険な神話なのだ。
サービスの数と可用性が交換可能になるのは各サービス間でコミュニケーション(意思疎通)を図らなくても、仕事が分担できる場合だけである。
人が少なくてサービス担当を分担できない場合、サービスを増やすという対策は運用上、何の効果も生まない。
分担はできるがサービス間でのコミュニケーションが必要な仕事においては、コミュニケーションに図る労力を、こなすべき仕事量に追加しなければならない。
したがって、サービスを分割してもお粗末な結果しか得られないだろう。
サービスを分割することで増える負担は、純粋な作業量増加および相互コミュニケーションの2つの部分からなる。
各サービスは、技術スタック、インフラ、運用手順、ドメイン知識それぞれについて絶えず一つのシステムとしての独立性が求められる。
これらの実態は分断されてしまうから、負担の増加分はサービス数に合わせて線形に変化する。
相互連携となるとさらにひどい。
仕様の各部分がサービス間ごとに調整されなければならないから、そのための労力は、サービスがn個あれば、n(n - 1)/2に比例する。サービスが3つなら、それぞれの相互連携が2つのときの3倍、4つなら6倍必要になる。
さらに、もしその分割された各サービスが共同で問題解決にあたるための仕様策定が必要になると、自体は一層ひどくなる。
連携を図るために追加される労力は、一つのサービスの場合と違い、より困難な状況をもたらす。
ソフトウェア構築は、本来システム的な作業──複雑な相互関係における作業の遂行──であり、コミュニケーションを図るための労力は大きく、分担によってもたらされた各サービスの疎結合性はすぐエントロピーの餌食となってしまう。
だから、サービスを分割することが、システムのレガシー化を加速させることはあっても、減速させることはないのである。
コンウェイの法則とマイクロサービス
システム開発においてはコンウェイの法則が稀によく観測されます。
コンウェイの法則とは「システム設計は、組織構造を反映したものになる」法則のことです。
社内の開発体制とシステムアーキテクチャは密接な関係になり、社内のコミュニケーションパターンがDevOpsに影響を与えます。
ところで昨今、開発プロジェクトに関わるごとにマイクロサービスを採用したい人をよく見かけるようになりました。
Wikiの内容をそのまま引用しますが、マイクロサービスは
1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ
です。
一つの膨大なシステムを開発運用するより、システム全体を小さく分割された複数のサービスにしておけば、各担当者はそれぞれ単体のサービスにフォーカスを絞って開発運用ができるようになります。
全体をまとめて管理するより運用コストを下げることができます。
また、サービスがモジュール化(疎結合化)しているのでシステムが冗長化しやすかったり、改修にかかるスコープが限定的で済んだり、継続的デリバリーとも相性がいいです。
すごくいい事だらけなような気がします。
しかし、この世に銀の弾丸はありません。
マイクロサービスを採用しようとしている現場のほとんどはベンチャー企業やスタートアップだったりします。
全員集まっても数人、多くても数十人ぐらいの規模感です。
そもそもチームを分割できるほど頭数がいません。
マイクロサービスは基本1チーム1サービスです。
しかし現実は1チーム複数サービスになっており、結局は全体をまとめて管理運用することになっています。
一つのシステムだと一つのサービスの運用管理で済みますが、複数のサービスに分割されていると、サービスの数だけ運用管理の手間がかかります。
分割した分、一つの状態のときより分量は増えますし、各サービス間のI/Fや連携に携わる手間も追加で発生します。
また、開発時にそれぞれのサービスを別々の開発チームにお願いしていたりすると、DDDにおけるドメインモデルの振れやユビキタス言語の差異が発生し、システム全体の統一性を保つことができなくなり、仕様の面から技術的負債が膨れ上がることになります。
ここで最初に話したコンウェイの法則が牙を向きます。
多チーム多サービスはコンウェイの法則を満たします。
しかし、1チーム多サービスはコンウェイの法則により1チーム1サービスに収斂していきます。
いくら口でマイクロサービスと喚いたところで、最後に蓋を開けてみれば、そこに存在するのはキレイに疎結合化されたサービス群ではなく、なんだかよく分からない十把一絡げになったシステム的なサムシングになるのがオチです。
そもそもベンチャーやスタートアップはビジネスモデルも確立できていないし、人の入れ替わりも激しい業界です。
朝令暮改やピボットが当たり前の世界です。
システムに期待される要件はカオスにさらされ、少人数でPDCAを高速で回す分、システムの実態は密結合にならざるを得ないでしょう。
ビジネスが不安定であり、組織が密結合なのですから疎結合のアーキテクチャであるマイクロサービスを採用すること自体、コンウェイの法則的に無理があるのです。
組織が密結合であるにも関わらずマイクロサービスを採用するものの、コンウェイの法則によりシステムは密結合に収斂していく、これがマイクロサービスがうまく機能しない理由です。
システムの所有者が大手大企業であり、その子会社がサブシステムを持っている、ぐらいの規模感がないとマイクロサービスは実現できないのです。
Tag: プログラミング