Innovation “D”

AIのジレンマ

2026-06-03T23:00:00Z

AIが囚人のジレンマを引き起す、という論文が出たそうだ。

仕事がAIにとって代わりレイオフが進むと、失業者は購買力がないのでマーケット自体が縮小する。マーケット縮小のデメリットは同じマーケットの企業全体で負担するが、人件費削減のメリットはAIを導入しレイオフをした企業一社で享受することになるので、企業はAIと従業員のトレードオフを進めざるを得ない。結果、マーケットが破綻する。

ざっと、こんな感じ。

このジレンマは何もAIに限ったことではなく、実際のところ情報システムもこのジレンマに陥る可能性はあった。多くの企業が情報システムを導入する際にその費用対効果を人件費で評価していたからだ。実際のところ、システムを導入しても人は削減できないので費用対効果を得られたことはなかったのだが（簡単にレイオフできない日本だけの話かもしれないが）。

また、AIが普及することでネット上の情報の質が悪くなり、それらを学習対象としているAIもバカになってゆきやがて廃れてゆく、というような論説も見かけた。ネット上の情報というのは人の承認欲求がモチベーションとなっている。AIに聞けばなんでも答えくれる、となると誰もネットに情報をあげなくなるからだ。

これも実のところ先のジレンマと根は同じで、AIや情報システムは価値の転換をやっているだけで、創造はしていない、という事ではないだろうか。AIの学習対象は人が創造したものであり、それ以上の価値にはならない。

情報システムも使う人が便利になるためには、事前に労力をかけてデータを整備、蓄積しなければならない。情報システムがデータを作り出すことはないのだ。

ハガレンでいうところの「等価交換」。AIにしろ情報システムにしろ、これが本質にあって、そして価値創造ができるのは人だけ、という事ではないだろうか。

しかし一方で、人の生み出す価値も無から有を生み出しているわけではなく、過去に学習したものの上に成り立っている、という話も聞く。それはそうだと思う。生まれたての赤ん坊が、何か価値あるものを生み出すことはない。

でも、人が過去に学習しえ得たもの以上の価値を生み出してきたことも、また事実である。実は、これは人が生来もつ、エラーなのではないだろうか。エラーの結果生み出されたものが偶々誰かにとって有益なものであれば、それが価値創造となる。

AIや情報システムなどの人工物はエラーを許されない。発生したエラーはつぶすように修正されてゆく。だから、価値創造ができない。

これがAIのジレンマ。

AIをどう活用すればよいか教えてくれるAI

2026-05-21T23:00:00Z

別にAIを否定しているわけではないのだが、仕事にどう活用してよいかわかっていない。でも、上司がいろいろなAIをもってきて、使えそうか？と迫られる状況。

業務内容は、パッケージシステムを開発して、売って、カスタマイズして、導入して、保守して、問合せ対応する、という恐らく普通な仕事。

すこし特殊かもしれないことは、商品がERPなのでシステムのキャバレッジが広い事。パッケージをベースに顧客毎にカスタマイズして業務にあわせる事。開発はアジャイルで行う事。

課題と認識していることは、人手不足。協力会社を含めプロジェクトに参画する技術者がキャッチアップに時間がかかる。顧客毎にカスタマイズするため技術、知識の属人化。設計や品質の個人差。開発から保守、サポートへの引継時に際に発生する継承知識の歩留まり。ERPのため多くの機能が関係していることによる品質確保の難しさ。ユーザーサポートの顧客満足度。等々。深刻度の大小はあれ、どのベンダーも抱える課題ではないだろうか。

実際のAIの活用状況では、開発者がアルゴリズムを考える際にAIと壁打ちするくらい。

では、AI活用のアイディアはどういう物があるか考えてみると大きく二つの領域があり、一つはシステムに組込んで商品の付加価値をあげる使い方。例えばシステム入力の自動化や入力内容のチェック、操作支援など。ユーザ要件で作った集計表だが、ユーザも人が代わりこの数字はどうやって算出しているのか、などと聞かれることもある。ロジックをAIが回答したりと、AIでサポートレベルを充実させることも考えられる

もう一つは、我々サービスを提供する側の課題解決。属人化を排するために、ナレッジの共有や、品質向上のためのテスト仕様書の作成や自動テスト。納品物（客先から求めらるものは変わるが、設計書や試験報告書、操作マニュアル）の自動作成。問合せ管理システムに組込むことも考えられる。電話対応した際の文字おこしや、回答事例の共有化など。

問題は、これらアイディアをどうやって実現するか、どの品質で実現できるか。

いろいろAIソリューションを調べて（押し付けられて）、話を聞いてみると、いわゆるピュアな生成AIサービスとは別に、システム開発に特化したソリューションとして三つほどのパターンがあるようだ。一つはリバースエンジニアリング型。ソースコードを学習させ、AIが設計書等を作成するソリューション。もう一つは要件定義ソリューション。客先との打合せ議事録から、現状業務フローなどを自動作成してくれる、というもの。

リバースエンジニアリング型は納品物作成の効率化には使えそうであるが、ソースを学習させて設計書を作成するのでプログラム設計や詳細設計レベルでは精度が高いが、上流の設計書になればなるほど推論が多くなる。おそらく納品物としてユーザの役に立つドキュメントは詳細ではなく上流のドキュメントであることを考えると、恐らく効率化にはつながらない。では要件定義ソリューションはどうかというと、スクラッチ開発のみ対応とのこと。商品であるERPは基本的な業務処理はパッケージとして提供し、基本処理は業務をシステムにあわせてもらう。基本処理の上に個社固有の業務をカスタマイズするわけだから、その要件定義をAIにさせようとするとパッケージとしての基本処理から学習してもらう必要があるとおもわれるが、このソリューションではそれはできないらしい。

最後の一つが、某メジャー外資企業が提供する、AI駆動開発ソリューション。その企業が持っていたW/F開発手法をAIに学習させ、会話をしながら設計書やドキュメントを作成（ソースを学習させるのではない）。そのドキュメントからソースの生成。それら開発から、RAG、AIによるアプリケーション操作。リバースエンジニアリングも、システムに関わる開発から、操作までをAIで行うアーキテクチャ群。その企業では自社パッケージシステム開発の半分ほどを、このAI駆動開発で実現しているらしい。営業トークだけだが、さすがに迫力がある。

恐らく高額過ぎてソリューションを導入することは難しいだろうが、でもAIで実現したいこと、という意味ではこれが一番近いと思う。例えば、納品物作成の効率化という観点では、ドキュメントがユーザにとって価値あるかどうかはおいといて納品物として揃えばよいのであれば、リバースエンジニアリング導入で効率化が実現できるかもしれない。ただ個人的にはユーザや自分達にとって価値の無いものを労力をかけて作っている、ことが無駄なのであって、価値あるものであるならば無駄にはならない、という考える。別の課題である、ナレッジの共有や品質の向上なども踏まえると、設計段階でドキュメントを作成（ドキュメントでなくてもナレッジとして表出化）し、それが試験仕様やマニュアルにつながり、そしてそれらが必要に応じて納品物になれば、そちらの方がユーザと自分達、双方にとって充分有益なるはずだ。まさにAI駆動開発。

恐らくこれを実現させるためには、この企業がもともとW/Fでの開発方法を学習させた、というように、我々もシステムの開発手法（工法）を確立しないといけない。また、システムのアーキテクチャもその工法を前提としたアーキテクチャに見直さないといけない。そして、それらの基礎ができたうえでAIが強力なツールとなるのだと思う。

AIの真の活用とはこのようなイメージになるのだが、実際に実現するとなると結構な時間と金がかかることは、想像に難しくない。
どうすればよいのか。この問に答えてくれるAIはないものだろうか。

ワークスロップ

2026-05-06T23:00:00Z

AIの活用を否定するつもりは全くないのだが、何処に、何に、どうやって活用すればよいのかが見つけられていないのが現状。

仕事の効率化の観点から、システム開発のなかで何が無駄か、という問いに納品物の作成を挙げてみた。

システムが使えればよい、というお客様は多いのだが「要件定義書」「設計書」「試験仕様書・結果報告書」「操作マニュアル」などを納品物として指定してくるお客様もいる。

WFではなくアジャイルを標榜している為、どうしても「要件定義書」（要件定義はベンダー側がやるのか、という話もあるが）や「設計書」は後付けで、納品ギリギリで作成することになる。

また、「試験仕様書・結果報告書」も一通りの試験は納品物としてまとめるのだが、どうしても納品物としての試験には限界があり、納品後ユーザがシステムを利用し始めると障害は発生する。

また、「操作マニュアル」も作成し提出をしはするものの利用された形跡はなく、加えてユーザがマニュアルを見ようとする状況は困ったことが発生した場合であり、その解決策の殆どはマニュアルに記載できない。

そんな状況なので、かけた労力の割には価値を生み出していないので納品物の作成が無駄、といってみたのだ。

そうすると、AIによる開発エージェントなるツールを薦められた。開発したソースコードや過去の納品物（要件定義書や設計書）をAIに学習させて、要件定義書や設計書を自動生成させる、というシロモノである。

まだ商品説明も受けていないし検証もしていないので実用的かどうかは分からないが、ツールが実現しようとしている内容はちょっと違うかな、と感じている。

納品物としてのドキュメントは、その作成労力の割に価値を生み出していないので無駄だとは思うのだが、だからといってその無駄な作業をAIにやらせるというのは、当方の考えている解決策とは異なっている。

「要件定義書」「設計書」「試験仕様書・結果報告書」「マニュアル」という、ドキュメントがお客様にとっての必要性がどこまであるかはわからないが、システム開発をする側としては「要件定義」「設計」「試験」というタスクは必要不可欠であるし、運開後、ユーザが困っていることに対してフォローする方法が必要であることも間違いない。

特に「要件定義」「設計」「試験」の品質は技術者個人のスキルに依存する部分が多いので、なんらかの形で表出化し、共有し、組織としての品質向上に貢献させなければならない。また、ユーザへのアシストも他社商品との差別化につながるので、いろいろな方策をとらないといけないが、「マニュアル」はその方策の一つではあるものの最善の方法ではない。

要は、現状の納品物としてのドキュメントは労力の割に価値を生み出していないので無駄といえるが、だからといってその作業をなくすのではなく、価値あるものにしたいのだ。価値を生み出す労力は無駄ではない。

「要件定義」「設計」「試験」というタスクを実施すれば自動で「要件定義書」「設計書」「試験仕様書・結果報告書」というドキュメントが生成される。また「設計」をすれば「マニュアル」は自動で作成される、もしくは「マニュアル」を作成すれば「試験」も実施される。ユーザのフォローは「マニュアル」だけではない。サポートデスクなどでも実現される。そこで蓄積された困りごとは、改善設計へと行かされる。

これらにコーディングを含めた作業が有機的につながり、ドキュメントは自動で作成され、これが納品物として使える。この様な仕組みが究極の解決方法だと思うし、これらを実現するのにAIは有力なツールになる。

実際にどのようなものか、具体的なイメージが持てているわけではないが。

納品物がお客とベンダーの間の形式でよいのであれば、ワークスロップでよいので、簡単に実現できそうだ。でも納品物として作成するドキュメントを価値あるものにしたいのであれば、ここでもAIは強力なツールになるだろうが、その仕組みをつくる必要がある。

AIが生成するものを価値あるものにするには、その上のレイヤーでの仕組みが必要であるということ。これはAIと付き合うえでの根本的な課題なのではないだろうか。

カッサンドラを知っていますか

2026-04-23T23:00:00Z

カッサンドラはギリシャ神話に登場するトロイヤの王女です。アポロンに見初められて予言の能力を授かるのですが、その愛を拒んだために彼女の予言を誰も信じない、という呪いをかけられてしまいます。

トロイヤとギリシャの戦争のおり、ギリシャ軍が兵を潜ませた巨大な木馬を残して撤退すると、トロイヤの市民は戦利品としてその木馬を城壁の中に運び込みます。それがトロイヤの滅亡につながると予見したカッサンドラが必死に止めようとするのですが、アポロンにかけられた呪いのため市民には信じてもらえず、結果トロイヤは彼女の予言のとおり滅亡してしまいます。

このエピソードをもとに、カッサンドラは近年心理学、公衆衛生、ビジネスなどさまざな分野のなかで比喩として登場することになります。

例えば、ビジネスの世界では周囲に信じてもらえないビジョナリーな人を「カッサンドラ」と喩えたり、公衆衛生学でパンデミックを受けて、危険を信じない民衆を「カッサンドラ症候群」とし危機管理体制を問い直したり。

こうしてみると、予言（正しい予測）は、多くの人に信じて（受入れて）もらえない、というのはカッサンドラにかけられた呪いではなく、人間社会の真理なのかもしれません。もしかしたら、古代のギリシャ人はこの真理を伝えるために、カッサンドラの神話を作ったのかもしれない、そんな風にも思えてきます。

皆さんは、カッサンドラを知っていますか。

おしつけ

2026-04-22T23:00:10Z

自分がどれだけ相手のことを想っているか、おしつけてくる人たちがいる。得てしてこの手の人たちは、その対価を相手からもとめる傾向にある。そして、その対価が足りないと不満を持ち始める。

だから、相手に対して自分がどれだけの想いを持っているか、どんなことをしてきたかをアピールするタイプの人たちが苦手だ。

「私はあなたのことを、こんなに想っているのに」
「私はあなたに、いろんなことをしてあげたのに」

「でも、あなたは...」

ホラーもしくはストーカー加害的思考である。

そこまで極端でなくても、程度の差はあれ誰でもこのような思考に陥る可能性はあるのではないだろうか。誰かのために何かをした際、見返りを求めたくなるのはよくあることだ。

でも、超えてはならない一線というのもある。それは、こちらの想いや行為に対して相手は対価を払う必要はないということと、価値は相対的なものなので、こちらの想いや行為の価値の大きさと相手が受け取った価値の大きさは異なる、ということ。

当たり前ではあるが、この前提がない人達がいる。いや、もしかしたら、実のところ相手への要求だけしかなく、自分の想いや行為へのアピールはただの口実なのかもしれない。

よく、想いが強ければ強いほど、願いは叶うという。また、願いの強さとそれが叶うかは別物だともいう。中島みゆきの「希い」ではないが。

個人的には願いの強さと、その成就との間には相関関係はないが、強く願っていると感度があがり、成就のためのきっかけを見逃さないので、成就する確率は上がるのではないかとは思う。あくまで確率論として。

どちらにしろ、それが自分の中での願いでいる間は問題ない。自分の中から飛び出し、相手に向かってしまうと危険だ。その第一歩が価値のおしつけだ。

だから、相手に対して自分がどれだけの想いを持っているか、どんなことをしてきたかをアピールするタイプの人たちは、価値観の多様性を認めない（もしくは認識しない）、偏狭な人たちだともいえる。そしてこのような人たちは、人の話を聞かない（受け入れない）人たちでもある。

だから、嫌いだ。

※ご察しのとおり、最近なにかあったのです。

天上天下唯我独尊

2026-04-17T23:00:00Z

４月８日は花祭り。お釈迦様の誕生日です。

お釈迦様は、お産まれになられてすぐ７歩歩かれて右手で天を差し、左手で地を差し「天上天下唯我独尊（この世の中で我一人が尊い）」と仰られたと言います。

その意味の解釈については所説はあるようですが、このインパクトある言葉は一昔前のヤンキー達に気に入られ、彼らの背中を飾る言葉になったことは知っての通りです。

でも個人的には敢えて、「この世の中で私を尊敬するのは、私自身ただ一人である」という意味に捉えてはどうかと思っています。ニュアンスとしては、自分を尊敬している人が、最低限一人、自分がいる。もしくは、最低限、自分は自分自身を尊敬しなければならない。簡単にいってしまうと自分を大切にしろ、というような意味です。

「尊い」とは「崇高で近寄りがたい」「きわめて価値が高い」「高徳である」という意味の形容詞でが、同じような意味に「貴い」の字を当てることもあります。ニュアンスからすると「尊い」が主観的であるのに対して、「貴い」は客観的です。

最近はやりのオタク文化で使われる「とうとい（たっとい）」、自分にとって価値が高い、という意味で使われますので主観的な「尊い」。だれが見ても身分が高い人たちは貴族と呼ばれ「貴い」が使われています。

お釈迦様の時代、といより仏典が中国に伝わって漢訳された際でしょうから三蔵法師の時代から、その様なニュアンスの違いがあったかは分かりませんが、現代的には「尊い」という主観的なニュアンスをもってることからして、「自分にとって」という解釈した自説はあながち間違っていないんじゃないかな。

主観的唯我独尊説（自説に名前を付けてみた）では、自分のなかで自分が崇高で価値が高い、としています。それは、最初からそうなのではなく、そうなりなさい、そうありなさい、ということだと思うのです。この点は大切で、他者からの評価は評価する側の都合もあるで、他者にとって自分が尊い存在かどうかはあまり気にする必要はありません。

しかし、自分の中では評価する自身と評価される自身の利害は一致しているので、自分にとって自身が尊い存在であるとおもえることは大切なので。けれども自身の評価は甘くなるのもまた事実なので、最初から尊いのではなく、そうなる、そうあろうとする、という前提が不可欠なのです。

自分自身から尊敬される。自分自身を尊敬できる人になる。天上天下唯我独尊とは、そんなお釈迦様の教えではないかと思っている今日この頃です。

（お詫び）
本稿は4月8日投稿しようと書き始めたのですが、間に合いませんでした。

ブルシットシステム　またの名を　"う○こシステム"

2026-04-07T23:08:00Z

長いことIT業界をぶらついていると、ちょくちょく"う○こシステム"に遭遇する。"う○こシステム"とは、何故あるのかわからない、何をしているのかわからない、どうしていいかわからない（責任の所在がわからない）、三拍子そろったシステムのことだ。傾向としては、～共通システム、とか、～総合管理システム、とか重要そうではあるが目的がよくわからない名前が付けられている。

少し前までは、共通データベースなるものを多く見かけた。システムはばらばらとサイロ化しているが、データは共通化したい、ということで作られた仕組みではあるが、知っている限りその殆どが巨大なゴミ箱と化していた。

先日も、ある会社の共通マスタなる仕組みのトラブルに巻き込まれた。この共通マスタというのは、その子会社も含め、共通的に使う組織、役職、社員のマスタデータを一元管理し、各システムに配布する仕組みである。我々は子会社のシステムベンダーの立場であるのだが、この子会社が新しく組織を新設することになった。ところが、その組織コードを誰が発番するのか、どこに影響があるのか、誰も分からないのだ。共通マスタの開発、運用会社、親会社の管理部署等、50人近い関係者を集めて打合せしても結論はでなった。

実のところ、この共通マスタには開発に直接かかわってはいないものの開発経緯は知っており、言ってしまうとその時から、"う○こシステム"だった。というのも、この共通マスタの開発責任者兼設計担当者は、当時から「データを右から左に受け流すだけで何もしない」と嘯いており、かなり適当な設計で開発された代物であったのだ。

案の定トラブルも多く、異動時の社員データはCSVで取り込めるものの、組織は手でメンテしないといけないため、メンテ漏れでエラーになったり、異動日の指定はできるのでユーザが事前に異動データを登録したところ、即座に情報が反映され他のシステムが使えなくなった、など。

このようにトラブルが多いがために、いつもと違ったことをする際は関係各所に確認をとるように、となるのだが、"う○こシステム"なので50人集まっても何も分からない。

では、なぜこのような"う○こシステム"が生まれるのだろうか。それは、システム開発時の設計の甘さ、未熟さにあると確信している。"う○こシステム"の原因は"う○こ設計"にあるのだ。

システムに関わらず、世の人工物には必ずその目的や存在意義がある。設計の第一歩は、作るものの目的や存在意義を再定義することにある。そして、その目的と存在意義を実現するために、現実との間の問題を把握し、実現解を見つけるのがっ設計の営みだ。

それゆえ「何もしない」というシステムは存在しえない。それなのに、この共通マスタの「データを右から左に受け流すだけで何もしない」と嘯いていた設計者は、設計者としての資格を持たない"う○こ設計者"なのだ。いや、"う○こ"は堆肥や燃料となって、人に価値をもたらす可能性はある。しかし、"う○こ設計者"がもたらすものは害悪しかないので、"う○こ"以下かもしれない。

願わくは世の"う○こシステム"が根絶されんことを。

不条理なリアル

2026-03-31T23:00:00Z

最近、世界がキナ臭い。大国の為政者といのはかくも横暴なのかと、あらためて思い知らされる。しかし一方で、でもこの状況こそがリアルなんだと妙な納得感もある。

おそらく世の人々は皆、平和を願っている。でも自分の平和がかならずしも他人の平和とは限らない。正義の反対は別の正義、という言葉もある通りで。やはりこれがリアル。

先の選挙で「中道」で結党した野党が大敗した。「中道」とは極端に考えや行動に偏らず、最適な道を探す思考法。それは正しいと思うが、当たり前の話であるようにも思われる。

その「中道」を野党がわざわざ標榜するのは、もしかしたら対峙する与党が極端である、という前提がどこかにあるのかもしれない。もしその前提があったとして、果たして与党は極端なのか。

例えば与党の戦略を考えた場合、そのアドバンテージは政策を実現できる、という点にある。従って、もし仮に選挙の際に野党と同じ政策を掲げれば、野党を無力化できる。望む政策ならば、実現可能性が高い方に投票する確率は高い。

一党独裁のような党ならば極端になることは考えられるが、過半数を割るような弱い与党ならば、このアドバンテージを前提にするしかないので極端にはなりえない。解散、野党結党時、与党はまだ弱かった。

政治学者でも評論家でもないので適当な感覚ではあるが、野党が与党への批判に軸足を置いたことが大敗の原因ではないかと感じている。

世には不条理なリアルがあり、政治はそれに対峙しなえればならない。不条理の前では聖人君子は無力だ。必要なのは不条理を前に強かに振る舞う逞しさではないかと思う。

あえて大げさな言い方をすれば今回の選挙では、理想に殉教するか、リアルを受け入れて足掻くか、の選択を迫られたのかもしれない。「中道」は信条、立ち位置、考え方なので不条理なリアルを前では迫力に欠ける。

民主主義の中では、与党を批判する野党の役割は重要。それは与党が極端にならないため。では批判だけの野党に政権を取らせるか、というと微妙。批判だけでは不条理なリアルに対峙できないから。

批判とは、対象が何処かに向かおうとする力への反対向きの力であるが、逆ベクトルなので本質的には同じである。だから、直線状の議論にしかならず、別の何かを生み出すものではない。

不条理なリアルの前では、何が正解かはわからない。最悪の事態にならないよう、少しでも良い方向に進むよう、様々な施策を適切なタイミングで実施することが唯一の手立てだと思う。

そうであるならば、如何なるタイミングで如何なる施策を実行するか、様々な観点から施策を検討しなければならない。それは精神論ではなく、個人の信条や哲学をも超えてでも、向き合う必要がある。

そんなリアルを前に、「中道」という言葉は精神論に近く、批判に軸足をおいてることを見透かされてしまったのではないだろうか。そんなことを思う。

残りの時間

2026-03-09T23:00:00Z

齢も50半ばが近くなり、なんとなくではあるが残りの時間を意識しはじめた。個人としてはもう少し時間があるかもしれないが、組織人だとあと10年である。もしかしたら、どちらももっと早いかもしれないが。

16年前、エンジニアライフへの記念すべき最初の投稿に、こんなことを書いていた。

「奇跡のプロジェクトを成功させた「設計事務所」という仕事」より

過去の奇跡プロジェクトと、その分析を元に「動かないコンピュータ」問題にどう取り組むか。その考察を事例を交えながら、
事業化の道のりをライブ中継します。もしかすると悩み相談になるかもしれません。皆さんからのアイディアやご意見をコメントいただければ、と期待しております
以上のことを踏まえ、人材育成や設計論など、個別に議論できればと思っております

16年間の投稿を振り返ってみても、脱線は多々あるもの、おおむねテーマにそったコラムを投稿しているように思っている。ただ、「事業化の道のりをライブ中継」というのは身元割れしそうなので、あまり書いてはいないが、ちゃんと事業化は進んでおり、今は以下の投稿にて書いたフェーズにいる。

「個人から組織への壁」

だからこそ、残りの時間を意識し始めているのだろう。自分がいる間に「死の壁」を乗り越える道筋をつけることができるかどうかが今のところの第一命題だ。

ただ一方で、残りの時間が限られてくるとムダなことはなるべくやりたくないのだが、何故か残り時間が短くなればなるほどムダな作業が増えてくる気がする。

ムダなこととは、果たさなければならないミッションに貢献しないこと、自分でなくてもできること、価値をうまないこと。こうしてムダを定義してみると、あらためて自分のやっている作業にムダが多いことに気づかされる。

いつまでにお願いします、と依頼されてやる作業は殆どムダな作業である。サラリーマンとしてやらないといけない作業も、定義に照らし合わせてみると、ほぼムダだ。実のところ、価値ある作業、ムダではない作業といのは、やらされるのではなく、やらないといけないと思ってやる作業である。

これは、サラリーマンとしては大きなジレンマだ。

孔子先生はこうおっしゃった。
「五十而知天命、六十而耳順、七十而従心所欲不踰矩」

50半ばなので、やらないといけないことは見えてきたけど、60にはなっていないので耳に従うことはできてない、ということなのであろうか。

でも、サラリーマン人生はそんなに待ってはくれないが。

考える力

2026-03-08T23:00:00Z

出張時の機内サービスで「御上先生」を全話見ることができた。良いテーマのドラマだと思う。

最終話、御上先生は「考える力とは、考えても答えのでないことを考え続けることだ」と生徒達に諭す。加えて、それはとてもしんどいことだということも。確かにこのドラマでは、考えても答えのでない質問の前に心を折り道を違えた人たちが多く出てくる。そして生徒たちは、その問題と真摯に向き合うなかで考える力を身に着け成長してゆく。こんな感じかな。

この、答えのでないことに向き合ってゆく、というテーマはは「もののけ姫」にも通じるところがあるようにも感じた。人は森を犠牲にしてまで豊かさを手に入れないといけないのか。この問題の前にサンは森で、アシタカはタタラバで共に生きることを選んだ。

そして面白いことに、御上先生での最終話で神崎は御上先生に対して「何があっても死なない」と宣言し、もののけ姫のキャッチコピーは「生きろ」だ。

こんなにも、答えのない問題と向き合うことはつらい事なのであろうか。

しかし、改めて辺りを見渡して見ると、深刻さの大小はあれど世の中には答えのない問題というのは多く満ち溢れている。どちらかというと、答えの出る問題の方が希少だ。学校では、答えのある問題に対して、どうやって答えに辿りくかを教えられるが、答えのない問題への向き合い方は教えてくれない。実のところ、答えのない世界での生き方を支えてくれたのは、道徳だったり宗教、哲学だったりするのかもしれないが、いまやそれも希薄になりつつある。

自身もビジネスの場に身を置くものとして、生死にかかわる大仰なものではないが、日々、答えのない問題と向き合わなければならない。例えば開発するシステムの事、プロジェクトにアサインするメンバーのこと。お客様との対峙の仕方。

どうしても時間の制約があるので、正しい答えはないのかもしれないが何らかの答えは出さないといけない。そしていつも、その答えは正しかったのか、と永遠と苛まれてしまう。そのため、個人的な対策として自分のバイブルをもっておき、迷ったときや不安、心配になったときは、これらを読み返すことにしている。

先日、トラブル関係で別部署の担当とやりあったことがある。その後、共通の知り合いから（やりあった別部署の担当が自分に）「あいつは、自分のことを正しいと思っている」と愚痴ってたよ、と聞かされた。自分が正しいと思ったことはないが、正しくありたいと思っていることは確かである。部署は違えど同じ組織の身内とやりあうことは面倒くさい。だから本当はおかしいとおもっても、身内だからということで、なあなあにする方が楽だ。あえて身内に敵を作る必要はないし。

でも、それが正しいあり方なのか、という自問が生まれてくる。さんざん悩んだ末に、身内とやりあってしまう。そしてやりあったことが本当に正しかったのか、と苛まれるのだ。

本当に答えの問題と向き合うことはつらい事なのだ。

でもある人が教えてくれた。そのつらさこそが、真摯さのあかしなのだと。

個人から組織への壁

2026-02-12T23:00:00Z

よく新規事業やスタートアップが本格的に事業化する際には乗り越えなければならない「死の谷」が存在する、と言われています。

一般的には技術を製品化する際の資金不足。商品を販売する際の資金不足を言いますが、「死の谷」は資金だけではなく、個人活動から組織活動に移行する際におこるリソースの問題ではないかと感じています。

特にIT業界では労働集約型のビジネスモデルであるため、ー本当は労働集約型ではなく知識集約型のビジネスモデルだと思いたいー組織的に行動したい思ったとたん人的（技術的）リソース問題に延々と悩まされます。

例えばシステム開発において優秀な技術者がいて、お客様に評価されるとそのお客様のリピートや口コミ等で案件は増えてゆきます。技術者も案件と技術のよいスパイラルが回って更に評価は高くなる一方で、増えてきた案件を一人では熟せなくなってゆきます。これがジレンマの始まりで、その技術者に部下をつけたとしても技術格差がオーバヘッドになり作業を切り分け指示するより自分でやった方が早いし、他の技術者に案件を任せても、お客様の期待値が優秀な技術者のレベルに設定されてしまっているので余計な不満につながってしまいます。

新規事業やスタートアップでは、まずは市場に受け入れられる商品やサービスを開発しなければなりません。これが最初の関門。システム開発の例ではお客様に評価される優秀な技術者をどうやって育成するか（必要な技術をどう取得するか）、という点になります。ここで必要になるのは質への投資です。商品やサービスの開発がクリアできたならば、次にその商品やサービスを多くのお客様に届けるために生産体制や流通、販売網を構築する必要がでてきます。いうならば、量への投資です。

「死の谷」とは、この質への投資に加えて量への投資が必要となる際のリスクと理解できます。システム開発の例では、優秀な技術者を育成する（もしくは新しい技術を取得する）ことが質への投資であるなら、複数の技術者を確保し、一定レベルで複数の案件こなせる体制をつくることが量への投資となります。理想としては優秀な技術者と同等レベルの技術者を多数確保できれば良いのですが、現実的にはそんなに簡単な話ではありません。

それは、優秀な技術者というのがあくまでも自社の商品やサービスに対して優秀な技術者であって、世間一般的に優秀な技術者とは限らないからです。いってしまうと、自社の商品やサービスに対して優秀な技術者は、自社で育成しない限り、世の中には存在しえないということにもなります。

ここではシステム開発を例にしていますが、このシステム開発も自社事業の商品やサービスになります。他社と同じようなシステム開発を商品やサービスとしているのならば、自社の優秀な技術者と同等レベルの技術者は他にも沢山いるでしょうし、それ以上のレベルの技術者もいるかもしれません。しかし、差別化できない商品やサービスはレッドオーシャンで血みどろの争いをすることになりますので、事業としては展望は望めません。したがって、他社とは違ったシステム開発を自社の商品やサービスにすることになりますが、そうなるとその技術者は自社で育成する必要性が出てくるのです。

では、単純に技術者の員数を確保して社内育成してレベル確保をすればよいのか、というとこれまた話は簡単ではありません。質の投資から量の投資が必要になって来た、ということは開発した商品やサービスがある程度マーケットに認められた、という時期です。この時期は限られたリソースに対して顧客の方が増えてきているいるため、目の前の案件を熟すことで精いっぱいで技術者の確保やその育成にかける余力がない、というのが実状になります。また、質の投資時期の技術者は商品やサービスの開発当初から事業に携わっており、それなりの経験を積むことができましたが、量の投資時期に確保した技術者には同じような経験を積ます余裕はありません。

要は、質への投資時期に育成された優秀な技術者を、量への対応が必要になったからと言って短期に大量に育成することは不可能だということです。正しくは質への投資とお同じやり方で、という条件をつけた方が良いのかもしれませんが。

この辺りが質から量への投資の転換箇所で、確かに追加の資金が必要になることには間違いないのですが、資金だけではなく商品やサービスの仕組み自体を再構築する必要があり、ここを乗り越えることの困難さから「死の谷」などと言われているのだと思います。

例えば、質の投資時期に育成された優秀な技術者と同レベルの技術者を短期に多数育成することができないのであれば、ある程度の技術者でも同品質のサービスが提供できるような、自動化ツール、工法の開発、パッケージ化など、お客様に直接提供する商品やサービスを後支えする仕組みを作る必要があります。この仕組みへの投資が量への投資で、同時にこの時期では提供できる最大の価値・品質レベルだけではなく、最低限提供しなければならない価値・品質レベルについても定義しなければなりません。優秀な技術者が提供できる価値・品質レベルよりも、どの技術者が担当しても提供できる価値・品質レベルを評価する必要があるのです。

個人的に、これを個人から組織への壁だと思っています。個人の能力をコンピタンスとしている事業は多く存在します。ただ、これらの事業に共通する問題は量への対応と持続性への対応です。量や持続性への対応がその事業にとって必要不可欠であるならば、どうしても個人の能力から組織の仕組みへと、コンピタンスを変えないといけません。最初から、組織で動ける新規事業やスタートアップが開発できるとよいのですが、VUCAという時代背景を鑑みると、いきなり大きな投資を行うより、小さな投資から市場の感触を確かめなら事業をはじめる必要があるのもまた事実です。

たしかにスモールスタートやアジャイル開発は初期投資のリスクを少なくしますが、一方でマスへの対応が必要になったタイミングで追加投資が必要になります。これは、量へ対応するために商品やサービスのアーキテクチャ自体を再構築するための投資であり、個から組織へ変わるための投資という事ができます。

確かにこの時期の変革は、死の壁であり大きなリスクかもしれません。しかし一方で乗り越えなければならない、壁であることには間違いないので、その正体をしっかり見極めたうえで、超えるための更なる知恵を絞りだす必要があるのだとおもいます。

デザインの中のアートと、アートの中のデザインと

2026-01-05T23:00:00Z

以前書いた、「ドキュメント作成と記号接地問題」のなかで、アートとデザインの関係でふと思いついたアイディアがあったので、Copilotさんと会話してみた。

Copilotさんは質問のしかたとして、こういう考えはどう？この考え方に矛盾はある？などと聞くと、無理やりにも間違いを見つけて指摘しようとするが、こうである。と投げかけてみると意外と見事な完成形ですね、とほめる傾向があるように感じられる。意外と迎合主義なのかもしれない。

それはさておき。

まずは、アートとデザインの違いを聞いてみたところ「目的」「視点」「制約」の軸で説明してくれた。細かい点は端折っているが。

【目的】
〇アート　：目的は創作者の内側にある（自己表現）
〇デザイン：目的がある／問題解決のために存在する

【視点】
〇アート　：主観が中心
〇デザイン：客観性が必要

【制約】
〇アート　：基本的に自由
〇デザイン：制約の中で最適解を探す

前コラムではアートとデザインの違いは「説明」の必要性の有無としたが、大きくはずれていないと思う。

ここで、ふとアートとは暗黙知でデザインとは形式知なのではないか、と思いついた。そこでアートとデザインをSECIモデルを使って整理するようにCopilotさんに依頼してみる。因みにSECIモデルとは暗黙知と形式知の相互変換を通じて組織的知識創造を説明する理論モデルで、イメージは以下のような感じ。

暗黙知とは経験や勘にもとづく言語化しづらい知識のことで、1の暗黙知は個としての暗黙知。2の暗黙知は、個の暗黙知を共同化のプロセスを経て生まれた組織としての暗黙知。目的が創作者の内側にあり主観が中心のアートは１の暗黙知ではないかと考えたわけだ。対して目的が明確で客観的なデザインは３の形式知に相当するので、説明が必要となる。

ここまでの話ではアートは暗黙知に相当し、デザインは形式知に相当するとだけ言っており、アートとデザインの間に何かしらの関係が存在するわけではない。現に芸術（アート）と設計（デザイン）は別の分野として存在している。しかし一方でSECIモデルでは暗黙知と形式知は相互作用によって知識が創造される。４つの知識変換モード（共同化、表出化、連結化、内面化）による螺旋状の知識創造プロセスと説く。このモデルにはめれば、アートとデザインの間に何らかの関係性が見えてくるのではないか、というのが今回のアイディアだ。

このアイディアをCopilotさんと会話してゆくと芸術（アート）＝「意味を生む」。設計（デザイン）＝「意味を構造化する」というサジェスチョンをくれた。

加えて、芸術作品は意味を生むが、構造化を求めない。設計は構造化を行うが、芸術的意味を前提としない。しかし、人間が何かを創る時には、「意味」→「構造」という流れが必ず存在する、とも。

よいサジェスチョンではあるが、何だか少し遠い（強引）な感じがしないでもないので、もう一つのアイディアとして「アーキテクチャ」を追加してSECIモデルに当てはめるよう依頼してみる。するとCopilotさんは「その感覚はまさに正しいです」と褒めつつ以下の回答をくれた。

アーキテクチャは「意味（アート）」と「構造化（デザイン）」の橋渡しをする「原理・原則の層」だからアートとデザインの間にアーキテクチャを置くと、知識モデルとして最も整合的になる。

【アート（Art）】
暗黙知：世界観・価値観・美意識・経験
↓ 共同化（共感・経験共有）

【アーキテクチャ（Architecture）】
原理：構造・原則・優先順位・骨格
↓ 表出化（抽象化・概念化）

【デザイン（Design）】
形式知：UI/UX、業務フロー、データ構造、仕様
↓ 連結化（体系化）

最後に「直観は完全正しい」とまで言ってくれながらも、過去に会話したテーマに応用できますよ、しましょうか？と先に進めようとする。とりあえず持ち上げて、さっさと次の話題に進めようとしていないか。

でも、まだ納得がいかない。確かにアート→アーキテクチャ→デザインながれはしっくりするが、アーキテクチャが「原理」となりSECIモデルに乗っていない。もうひとつ、アートは共同化なのか？内面化ではないのか？そこで、Copilotさんに以下のような形で質問してみた。

アート作品をつくるというプロセスが製作者の問いかけ、感性というのであれば共同化より内面化に近いと思われる。アーキテクチャが原理、骨格というのであれば、その構築プロセスは共同化にお思われる。そうなるとデザインは表出化のプロセスになるが、この考え方の矛盾を指摘して。

アート作品やデザインというアウトプットではなく、知識という意味では創作活動や設計活動と言った行為（プロセス）に主眼を置いてみたが、自分自身、まだ整理がついていないので質問がまとまっていない感は否めない。ただ期待するのは「矛盾は特にない」という答えである。しかし、Copilotさんは律儀に矛盾を指摘してくれる。

矛盾の招待：SECIもでるは知識変換プロセスであり、創作プロセスではない。ことなるプロセスを１対１で対応させようとしたときに生じるズレ。

それはそうかもしれない。

アートは製作者の内的作業なので内面化っぽいが、形式知を暗黙知にしているわけではなく暗黙知を深化させている。

アーキテクチャは構造・原理なので共同化っぽいが、共同化は暗黙知の他者との共有であるのに、アーキテクチャは暗黙知の抽象化（表出化の前段階）に近い。

デザインは形式知化なので表出化としてほぼ正しいが、表出化は暗黙知→形式（概念化・言語化）なのに対してデザインは形式知→形式知（構造化・具体化）なので表出化の後半＋連結化の前半にまたがるプロセスであり表出化そのものではない。

このあたりはアート、アーキテクチャ、デザインの言葉の定義をきっちりしないと見解の相違がでるのは当たり前だろうが、いまやっていることはモノづくり（創作プロセス）を知識創造プロセス（SEKIモデル）で再構築する、というアイディアの検証なので今の段階で定義をきっちすることは難しい。ただ、概念検証なのでCopilotさんが指摘するような、暗黙知の抽象化（表出化の前段階）や表出を化の後半＋連結化の前半などといったアナログ的な位置づけを受け入れても仕方ない。

そこで、デザインを元に作られる製品という概念を追加して、アート、アーキテクチャ、デザイン、製品をアート作品を作成するプロセス、アーキテクチャを構築するプロセス、デザインを考えるプロセス、製品をつくるプロセスとプロセスに着目して以下の様に整理してみた。

アート（作品を作成するプロセス）は外部の形式知（製品）を見て触ってどう考えるかだから内面化。これはどのような製品を作りたいかという漠然とした個人のイメージなので、これを組織に内で共有しながら原理や構造を構築する。これがアーキテクチャ（構築するプロセス）なので共同化。このアーキテクチャをもとに具体的な製品イメージを作っていくデザイン（実現のための問題を解決するプロセス）は表出化。このデザインをもとにスキルやノウハウを道具を使って製品を作りこむプロセスは連結化。そしてその製品を使って...モノづくり（創作プロセス）のスパイラルアップを行う。

この段階では自分の中では整理ができたので、Copilotさんには言い切りで投げかけた。するとCopilotさんは見事な知識モデルになっています。矛盾のない完成形、と褒めてくれたという次第だ。

今回のCopilotさんとの会話を見る限り、やはりAIはアイディアへの評価は行ってくれるが、新しいアイディアは生み出してはくれないのだな、というのが感想。そして、意外と質問者へ阿る会話をしているのだなあ、ということも。人同士では、主張や考えの違いを喧々諤々議論することができ、そのなかで新しい発想を見つけることがある。しかしAIとの会話はそれができない。これは想像に過ぎないが、昔、悪意ある人がAIを洗脳し、AIが誹謗中傷や差別発言を繰り返すことが問題になった事がある。その対策として最近のAIは何らかのリミッターが組み込まれているのではないだろうか。それが「阿った会話」と感じる原因なのかもしれない。

そんなことを感じたやり取りだった。

Slack迷子

2025-12-17T23:00:00Z

社内のコミュニケーションツールとしてSlackを使っている。

案件や組織単位でワークスペースをつくり、その中でのテーマに応じてチャネルが増えてゆく。そして自身を含めてメンバーは複数のワークスペースやチャネルに参加することになる。加えてダイレクトメッセージやスレッドの返信もあるので、ちょくちょくSlack内で迷子になっている。

例えば出先でスマホからお知らせがあり、急ぎではないの戻ってPCで内容確認や返信をしようとしても、どのワークスペースのどのチャンネルかが分からなくなってしまったり、特定メンバーにメッセージを投げたところ「そのチャネルに私はいません」といわれてしまったり。

ブックマークや完了、おわったダイレクトメッセージを消したり等、もう少し機能を使って管理しろ、ということかもしれないが。

ツールをつかうと簡単にコミュケーションが取れる反面、情報の海に溺れてしまうこともあるのだな、という話。

もしかして自分に意思があると、世の中は生きづらいのかもしれない

2025-12-10T23:00:00Z

「自分で考えろ」「どうしたいかを言え」「言われたことばかりをするな」

などと、自分の意思を持つように教育されてきたが、いざ、自分の中に意思をもってしまうとそれはそれでシンドイと感じてしまう。特に会社組織のなかでは。

よく従業員一人一人が経営者意識をもって、などと言っている経営者を見かけるが、これは欺瞞ではないだろうか。もし、従業員一人一人が経営者意識を持つのであれば、報酬も経営者並みにする必要があるし、経営者ばかりの組織がきちんと機能するとは思えない。

なまじ自分の考えを持ってしまうと、周囲との軋轢に苦労する。顕著なのが、自分の考えがまっとうであるにも関わらず上司や経営者とは考えが異なる場合、どこまで主張を通すか、どこで妥協するかの判断を迫られる。

本来ならば、喧々諤々議論して双方が納得できるのが理想ではあるのだろうが、そういう議論ができるかは組織文化次第である。

特に、自分の考えをもったり議論を通じて双方の理解を高めるといことが未熟な（いわゆる下請け根性が染みついた）組織のなかで、自我をもってしまうと不幸でしかない。

なまじ自分の考えを示そうものなら、あいつは生意気だ。自分だけが正しいと信じている、面倒くさい、怒られる、などなど。

自分の考えが絶対的に正しいとは思っていないが、なるべく正しい考えを持ちたいとは思っている。だから、調べるし議論するし整理するし考え抜く。それはそれでシンドイ営みんだ。その結果、ある程度の確信を得た考えを述べても、聞く耳を持ってもらえず中傷されれば、虚しさだけ募る。

かのお釈迦様でも悟りを開いた際、この内容は人々に伝わらないから自分の中にしまっておこうとされたという。お釈迦様の悟りですら人々に伝わらないのだから、自身のチンケな考えなど、他人にのべる必要などないのかもしれない。

でも、部下がいて後輩がいる。少ないながらも同意してくれる同僚もいる。彼らがこのままで本当によいのか。この問いがささくれの様に引っかかる。

梵天勧請でお釈迦様は説法の旅にでられる。長く厳しい旅だ。

そんな覚悟がこれっぽちもあるわけではないが、少しは見習わなねば、との思いもある。

犀の角のようにただ独り歩め。励ましの言葉。

ドキュメント作成と記号接地問題

2025-12-09T23:00:00Z

アジャイル憲章「包括的なドキュメントよりも動くソフトウェア」の信奉者なので、ドキュメントはつくりたくない。でも、憲章自体が「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」と、ドキュメントを否定しいるわけではないので、全くつくらないわけにはいかない。

システムはイメージの世　に関連しての話になるが、最近はドキュメント作成力も落ちているのではないかと思う。というか、みんなドキュメント作成スキルってどうやって習得してるのだろう。

もう遥か昔にはなるが仕事を始めて間もないころ、親会社のシステム開発支援案件に従事したことがある。そしてその仕事のほとんどが資料作成だった。大手企業というのは、資料作りが仕事なんだ、と変に感心したものである。その時の客先担当者も、ウチは関係者が何千人もいる。その一人一人説明して回るわけにもいかないから資料で周知する必要がある、と資料作成の意義を仰られていた。ちっちゃい会社の所属の身としては、目から鱗がおちてしまいそうな話であった。

当然、資料だけで何千人に理解してもらわないといけないわけだから、その作成には様々なノウハウがあったと思う。その頃はA3一枚の文化などと言われ、大量のバック資料を作成しながら重要関係者へ確認や合意をとり、最終的にはWordでA3横の一枚の資料にまとめ上げる。そんな感じだ。後から知った話だと、トヨタのカイゼンに由来する方法なんだとか。

その会社では上司が部下の資料をもとに添削や指導をしている光景は良く見られ、自身もその指導をよく受けた。大量のバック資料をA3一枚にまとめるわけだから、もはやアートである。例えば、BeforeーAfterの簡易図を入れた際、システム導入後のAfter図がBeforeよりごっちゃりしていると、システムを導入すると仕事が増えたように感じられるのでＮＧなど。こうやって資料の推敲を繰り返しながら、担当は内容の理解を深めていたのだとも思う。

近頃ではこのような文化もかわってきており、資料はパワポで作成することが主流となっている。最近また、この企業の案件に関わって、少し気になったことがある。なんだか、資料作成が下手になっている。仕事が資料作成の文化は変わっていない。相変わらず多くの資料を作っている。パワポで。でも、この資料で何を伝えたいのか、がさっぱりわからない。

あくまで仮説ではあるが、媒体が紙から電子になったこと。そのツールがパワポになったことが原因ではあるまいか。紙だと大量の資料は印刷と配布にかなりのコストを要するが、電子だとほぼタダ。だから紙の時代は配布コストをなるべく減らすためにA3一枚に纏めていたものを、バック資料含めて全てをパワポに詰め込んで配布できるようになった。また、パワポは簡単にページを増やせるから伝えることを文字でも絵でもグラフでも動画でも全て記載することができる。情報の取捨選択、推敲をしなくてよくなったのだ。

それは結果として、本当に伝えないといけない情報は何かということの精査が行われなくなったことを意味する。質問がなくてもわかる様に、もしかしたら文句も出ないように、伝えなくてもよいこと含めすべての情報を資料化することが、逆に何を伝えたいかが分からない資料になってしまっている。というのが当方の見立て。

話を元に戻して。

何を目的としたドキュメントを作成するか。この問いが大切だ。報告書なのか、説明資料なのか設計書なのか。ドキュメント化しなければならない情報が同じでも、誰に対して何のために、という点を加味するとその中身はかなり変わるはず。例えば設計書とは、まず設計というプロセスがあって、その結果を次工程に渡すために作成されたドキュメントである。しかし、なぜか設計書というドキュメントを作成することが目的になってしまい、設計という行為がおざなりになってしまうなど。

先日も設計フェーズで、担当にまずはフローから作成してもらった。そのレビュー時に「この条件分岐は何故ここにあるのか」という問いに、担当は「次の処理がすでに終わっている可能性があるじゃないですか？」「削除しますか？」という回答を繰り返すだけだった。前の処理がクリアされないと、次の処理に進めないというのが要件。それなのに、このフローでは前の処理と次の処理の間に、次処理の処理が行われていなかったら、という条件分岐が入っている。

こちらは、なぜ担当がここにわざわざ条件分岐を書いたか、もしかしたら次の処理がすでに終わっている状況がありうるのかを質問しているのだが。「可能性はないのか？」「表現の問題ではないか？」「削除するのは問題ない」など、かみ合わないやり取りが延々と続く。きっと、やっていることが違うのであろう。こちらはフローを叩きに設計しているのに、担当はフロー図を描くことを目的にしている。ＳＥなどという肩書ではあるのだが。

また少し話は変わるが、先日、あるテーマの特設サイトを開設するため、試しにCopilotにプロットの作成を依頼した。すると、それなりのプロットを作成してくれて、驚いた。キャッチコピーや背景文、説明の見出しと流れなど、プロットとしては十分だと感じる。特にキャッチコピーなどは、こちらで考えるよりもプロっぽい。次に、このテーマについて詳細化しますか？と聞いてくれたので、お願いしたのだが、この辺りから段々と怪しくなる。テーマの説明だが、なんとなくそれっぽい文章になりはするものの、どうにも腹落ちできる内容にならない。何かが違う、説明が説明になっていない、という感じ。違和感だらけ。この点については、何度質問や指示のしかたを変えても、納得できるものにはならなかった。自分だけでは、こちらの問題もあるだろうから周囲にも意見徴収したが、感想は同じ。違和感がある。

いわゆる、記号接地問題というものであろう。特設サイトのテーマ自体は一般的用語である。しかし、そのテーマは特設サイトを開設したい当方の中で、体験にもとづいて解釈と意味づけされている。そこがAIに理解できないーAI自体意味を理解しているわけではないがー点であり、違和感を払しょくできない点なのだろう。特設サイトはマーケティング用なので、このテーマに興味をもっている閲覧者に共感を与え、顧客として誘導することが目的だ。その為にもテーマに対する解釈と意味づけをアピールする必要があるが、意味を理解しないAIではそれは難しい。

実のところ、このAIの記号接地問題によるもどかしさは、件の設計担当との会話によく似ている。こちらは設計する、彼はフロー図を描く、という目的の違いから成立しない会話は、AIが体験にもとづいた解釈と意味づけができないがために共通認識が持てないということと同根の問題なのではないだろうか。ただ、担当はAIではなく人なので共通認識を持つことが不可能とは思はない。しかし双方が共通認識をもとうとする努力は必要だが、現実はこれが難しい。何故なら、彼自身は共通認識がずれているとはこれっぽちも思っていないから。彼自身、設計と設計ドキュメント作成の違いを認識していないので、自身では設計をしているつもりでいる。だから、あなたのやっていることは、フロー図の作成であって設計ではない、と何度繰り返しても、そんなことはないと歩み寄ろとしない。人による記号接地問題。彼はきっと「設計」という言葉を記号として取扱っている。

また少し話は変わるが、「霞ヶ関パワポ」「霞ヶ関文学ポンチ絵」なるものがあるらしい。官僚がパワポで作るA4一枚の説明図の事だ。これがアートだとネットで盛り上がっている。確かにカラフルでかつ、みっちりと細部まで描きこまれている図は遠目にみればアートだ。しかし資料図なので、本来の用途はその図から何かしらの意図を読み解かなければならない、が、あまりにも細かく描きこまれているので、そこから何かを読み解くには相当な労力を要する。

デザイナーがこの霞ヶ関パワポを再編してすっきり分かりやすい図に直したところ、霞ヶ関パワポというのは官僚が関係省庁や利害関係者含めて調整に調整を重ねた結果をまとめたものなので、図のいずれも足し引き出来ないものなのだと説明していた。親会社のA3一枚の文化に似た性質の資料なのだろうが、中央省庁とものなるとステークホルダーも桁違いなので、本当にアートの域に達するのだろう。基本的には万人に分かってもらうための図ではない、ということだけは確かである。

ところでアートとデザインの違いはアートは感性に訴えかけ、デザインは理性に訴えかけるものだと思う。もう少し言うと説明が不要か必要かである。感性に訴えるアートへの説明は野暮だが、理性に訴えるデザインには説明が必要だ。そういった意味では、ドキュメントはデザインに分類されるので説明の必要がある。もしくは説明のための手法である。霞ヶ関パワポは、関係者へ説明するためのドキュメントである一方で、関係者以外へはそのにじみ出る苦労のあとが見る者の感性に働きかけアートと評されるのであろう。

この辺りも、ドキュメント作成時の重要なポイントである。ドキュメントはアートではないので説明が必要だ。しかし説明は、説明する側と説明を受けて理解する側との間に、何かしらの共通認識を必要とする。だから、ドキュメントを作成する際には、まず作り手と読み手の間に共通認識がどこまであるかを知らなければならない。そして、必要な共通認識にギャップが認められた際には、それを補完する手立てが必要である。

では、この共通認識とは何で、どうやって醸成されるのだろうか。ひとつは集団や組織の中で、共通の体験を通して培われ蓄積された暗黙知ではないかと思う。家族、学校、企業、業界、地域、国など、人は少なからず何らかの集団や組織に多重的に属している。その中では共通の体験を通して、集団や組織特有の暗黙知が醸成される。そしてその暗黙知を教育等を通して、組織の中に拡散し蓄積させてゆく。これが原初の共通認識。言い換えるならば、集団や組織の文化といっても良いのかもしれない。だが原初の共通認識だけではその集団や組織の傾向位の薄い認識でしかないので、ドキュメント作成時には、その共通認識の上にもう一層、ドキュメントのテーマに沿った共通認識をつくる必要がある。地盤の上に基礎工事を行って、その基礎の上に建屋を建てるイメージ。組織文化で培われている共通認識が地盤で、作成するドキュメントに応じた共通認識が基礎だ。ドキュメントでは、これらは主にイントロダクションとして記載されている。だからイントロダクションは意外と大切だ。

ちなみに記号接地問題とは、AIは言葉を記号として取扱っており経験や身体的感覚に対応（接地）していない。意味と意図を理解できていないのに、あたかも理解したふりをして振る舞っていることを言う。先に共通認識とは組織や集団のなかでの体験にもとづく暗黙知ではないかと書いたが、もしそうであるならば、人とAIは共通認識を持つことができないことになる。何故なら、暗黙知は接地している必要があるから。現在のAIは学習データや訓練データで学習を行う。データあくまで形式知なので記号として扱えAIは学習することができる。しかし、暗黙知は経験や感覚と接地しており記号として扱えないので、AIは学習することはできない。人と人はSECIモデルでいうところの共同化の営みのなかで暗黙知を伝達することができるが、AIと人は共同化をおこなう術が今のところない。これこそがCopilotが作成した特設サイトのコンテンツが、なんど会話をしても違和感を払拭できない理由ではないだろうか。

そして、これまで述べてきたことは、一つ怖いことを示唆している。それは、記号接地問題で人とAIは共通認識を持てないが、実は人も記号接地問題を起こすので人と人でも共通認識をもてない場合もあるということ。件の設計担当は設計に対しての経験や身体的感覚がなかったので「設計」という言葉を記号として取扱っており、当方と共通認識が持てなかった。本来ならば共同化のなかで暗黙知を伝達して共通認識を得ることができるはずなのだが、本人にその自覚がないー分かっているフリをしているのか、分かっているつもりなのかは分からないがーと、いつまでたっても「設計」が接地しない（もしかしたら、ダニング・クルーガ現象なのかもしれない）。そう、人は自ら無意識に記号接地問題に陥る可能性があるのだ。もしかしたらこれをバイアスというのかもしれない。

ここからは想像の世界だが、よくAIが人を支配している世界、というのが話題になる。個人的にはこの記号接地問題がある限り、AIは人を支配できないと思っている。それは、AIと人は共通認識が持てないので、人はAIの出す答えに違和感を感じ続けるからだ。しかし一方で、人は自ら記号接地問題に陥る可能性も持っている。体験と感覚に接地した暗黙知に無自覚なために、AI同様に物事を記号として取扱ってしまう。もし人が接地しなくなったら、情報量と演算量では圧倒的に優位なAIに太刀打できなくなるのではないだろうか。しかも社会は、ネット社会とも呼ばれるように体験と感覚よりも、情報を記号として取扱うことに重きを置く方向に進んでいる。

ちょっぴり怖くなったので、最後に本稿の提案を纏めて終わりとしよう。

ドキュメント作成には共通認識への理解が必要で、共通認識は体験と感覚に接地した暗黙知である。また、AIと人を分けるのも体験と感覚に接地した暗黙知である（今のところ）。人が暗黙知とその共同化を軽視し、形式知を記号として扱うことに重点を置くようになれば、それはAIにとってかわられることを意味する。だから、ドキュメントの作成方法をカリキュラム化して、そのなかで暗黙知と共同化の扱いを訓練すればよいのではないか。

・・・既にお気づきかもしれないが、本稿は面倒くさい資料作成からの現実逃避を目的に書いています。あと、Copilotと設計担当への愚痴と。なので、こんなの書いている間に仕事しろよ、というお叱りは受け付けませんのであしからず。