(最近思うこと。2026年7月)

(最近思うこと。2026年7月)

流行に乗っ取られてはいけない

さんざん言われていることではあるが、SNS時代である。SNS的コミュニケーションに最適化したコミュニケーションが優先されすぎるきらいがある。インプレッションやいいねやフォロワーが多いこと、おどろきがあること、一刀両断、論破、断是か非か。僕なんかは昭和のテレビっ子で流行に弱いので、気をつけたい。

地に足付けて

サッカーのワールドカップが開催され、我らが日本代表は惜しくも決勝トーナメント一回戦の壁をまたしても超えられなかった。残念ではあるが、健闘を讃えたい。最高の景色ではないが、新しい景色は見えた。強豪国に対しても現実的に戦える。格下の国にはしっかりと大勝できる。すばらしい成長を見せてくれたと思う。 ヨーロッパでプレーする選手がとても多くなったが、まだ主要リーグの中心選手は多くない。このギャップ、ジレンマを、日本代表はうまく扱ったと思う。クラブでの活動と代表活動をうまくリンクさせて選手の向上と代表チームの向上を同時に図ったと思う。そのためのいわゆるボトムアップ方式だったと思う。まず土作りからするような代表だった。僕らのような見るだけの素人やYouTuber解説者などは単純に、あるいは観念的に語りがちだけれど、現実とはもっと複雑で、それに対して日本代表というチームは真摯に地に足つけて取り組んでいたと思う。ディテールでうまくいかなかったことあるかもしれないが、すばらしい成果が得られたと思っている。この節目を超えてどう変わっていくのかわからないが、ここまでの学びを活かしさらに伸びていって欲しい。

悪意を読み取らない

人が会話するときには、交わされる言葉がすべてかというとそうではなく、背景というかコンテキスト込みで会話している。交わされる言葉から推測されたコンテキストもリアルタイムに更新しながら行うことなので、なかなかに大変なことだ。会話では解釈プロセッサがフル回転になるわけだが、その際には、相手の発言にできるかぎり悪意を読み取らない方向性が好ましいだろうと思う。なんか皮肉とか含意があるように思える言葉が投げられることがあったとしても、いい方に解釈するとか、聞き漏らした体で受け流すとか、そういう姿勢がまあいいんじゃないかと思う。他者は(ああ、自分に対してもだけど)、全力を尽くして誠意を持って振る舞ってくれているという前提で捉えるのがいい。こういうことは身につくまで練習しないとスマートにはできないので、意識して取り組んでいきたい。

時を超えた組織活動の道

ウォーターフォール開発再考

ウォーターフォールのデメリットや陥りやすい失敗が欠点とか害悪とされることが多い(多かった)。だがソフトウェア開発方法論界隈はポジショントークが多いので注意が必要だ。僕自身もウォーターフォールを悪者に仕立てた上に自分の主張を置いたことがあると思うので言えた義理ではないが、ウォーターフォールの悪口自体は鬱憤晴らし程度の意味しかない。

思うに、ウォーターフォールは要求事項の最大公約数だ。かつてのPMBOKにも通じるものがある。そしてこれが一番の弱点だと今思うのだが、その要求をどう実現するのかの観点が弱い。必要なことだけを強く言い、それが揃った理想世界の話だけをしている。普通の人間による普通の組織がそれができるかという点にはあまり意識が向けられていない。その弱点にしわ寄せが来て、ウォーターフォールの典型的な失敗が発生し得るのだろう、と今の僕は思う。

プロジェクトをどう成功させるのかを考えるなら、人間というものを踏まえる必要がある

ウォーターフォールの代案として登場したアジャイルソフトウェア開発。アジャイルソフトウェア開発宣言を見てみると、こっちの方が価値があると言うばかりでそれはなぜかは言っていないのでわかりにくいのだが、それでも価値観や原則には、プロジェクトを成功させるための考慮や工夫が見てとれる。

それは、プロジェクトは人間(の集団)が行うことなので、人間ができるように、人間の持つ癖や弱みをうまく回避し、強みを発揮して乗り切ろう、という戦略だ。つまり人間中心。これが当時僕にとってアジャイルが魅力的に見えた理由かなと今思う。

で、別にアジャイルソフトウェア開発でないとだめとは今の僕は思わないのだけど、この、主体は人間とその集団であり、その特性に寄り添うことは成功のかなり重要な要因だ、ということを思う。

さりとて人間は難しい

組織やプロジェクトを成功に導きたければ人間というものの理解が必要と言ったが、人間というものは非決定的なものである。単純な論理ではない、ゆらぎ、ぶれ、かたより、ひずみがある。同じ人であっても状況で反応が違うとか。だから扱いが難しい。人間は人間の手に負えないところがある。

古典的な組織管理手法は単純な人間モデルを強引に当てはめて、あたかも管理は難しくないように見せかけていた。さすがにそれは単純に考え過ぎということになるが、じゃあそういう複雑で非決定的な人間性というものをどう理解しその知見を扱っていけばいいのか、これは難しい。

人間は組織管理手法を待つまでもなくもともと社会的生物であり、帰属集団の成功を意識して振る舞う。人間というものを肌感覚で理解しており、それを空気と呼ぶほどだ。ただそれがかならずしもうまくできない。空気を読むことで疲れ果ててしまうこともしばしばなのだ。

単純な管理を選んでしまうのにも道理があって、難しすぎることははなからできないからなのだろう。

人間というものをどう知識化するか

このようなコンテキスト依存で非決定的なものに関する知識を扱う方法として思い起こされるのがパターン、パタン・ランゲージである。パターンとして人間や組織の特徴や特性を記述し、それを語彙として組織やプロジェクトの運営を行う(そのための会話を行う)といいじゃないか。

このような取り組みはすでに行われているとは思う。組織パターンや、Fearless Changeのような知識体系化の取り組みはなされてきた。ただ、人間や集団を理解する「サブテキスト(副読本)」に留まってしまっていたのかなと思う。パターンスノッブのような。しかし改めて、今の時代、組織でなにかをなしたいのなら人間についての理解、それを踏まえたアクションは絶対に必要で、そのために改めてパタン・ランゲージの出番がきているのではないかと思う。

LLM Wiki で組織パターンを収集する

AIと協働してWikiにナレッジを蓄積形成していく「LLM Wiki」という取り組みが紹介され、とても興味深いものと思った。このアプローチで、前述の人間に対する理解のパターンを収集し、組織運営、業務プロセスの知識ベースを作ったらどうだろうか。

心理学や行動経済学などの知見も知識項目になると思うし、会社とか部門とかの組織単位の特性も含まれていいと思う。パターン名なんかは組織独自の呼び名がまさにふさわしい。なんなら最近の職場ではコミュニケーションやドキュメントなどをAIも見ているので、AIのほうが人間の振る舞いについて詳しいかもしれない。AIと共同で組織パターンを記述するというのは目があると思う。

Wikiは元々ウォード・カニンガムがパターンを記述するために作ったシステムから出発している。LLM Wikiで組織パタン・ランゲージを作るというのは、まさに原点回帰である。

AIを用いた組織パターンの活用

先ほどかつてのパターンはサブテキストでしかなかったのが残念だったという話をしたが、このAI時代、AIは個人に寄り添う秘書のような存在にもなってきていると思う。チャットやメールになにかを書こうとするとき、AIはそのコンテキストに沿って助言をくれる。そのAIに、先ほどの組織パターンが参照されていたらどうだろう。 人間的な認知の偏りやコミニュケーションエラーを上手に回避するとか、円滑にエンパワーする方向にナッジするとか、そういうことが可能だろう。AIが個人の耳元でこっそり耳打ちしてくれる形なら、パターンの使いこなしにおける格差やマウンティングもうまれず、本来の意味での高い心理的安全性が得られるのではないか。

こうして人間理解を踏まえた組織運営のパターンは単なるサブテキストの域を超えて、真に有効な生きたナレッジ、組織のランゲージとなる。

ということで、人間を理解することが重要だが、それは簡単ではない。が、AIといっしょにパタン・ランゲージを作って活用すればいいんじゃないだろうか、という話でした。

(最近思うこと、2026年5月)

最近思うことの備忘録です。ちゃんとした文章にしておきたいけどすぐできないので、とりあえず概要だけ。

アジャイル関連

アジャイルソフトウェア開発宣言やその背後にある原則はHowを言っていてWhyを言っていない。あれだけWhyを書けと言っておきながら。。。

アジャイルソフトウェア開発とは、「不完全で偏りのある存在としての人間」の弱みを避けるか補い、強みを活かし、それらによって開発を成功させようという試みである、という見方で読み直してみたらどうか。

アジャイルソフトウェア開発を人間のためのものとしていま見直す意義は、システムやソフトウェアの開発の一部がAIによって行われるようになってきており、人間がボトルネックであると思われてしまう状況になってきているから。人間が関与しなくていいなら別にどうでもいいけど何らかの理由で関与するのであれば、その弱みを避けるか補い、強みを活かすやり方が必要だろう、ということです。これは効率のことを言っているのではなく、人は幸せになってほしい、という話。

アジャイルがウォーターフォールの否定であり置き換えであるかのような言い方を、皆がいつもしていたわけではないと思うけれど、そんなふうに聞こえるように言ってしまったり、そんなふうに聞き取ってしまった部分もあると思う。自分も含め。いろいろ背景はあると思うのでそれはそれでいい。けれど、ウォーターフォールだって開発の成功を願って始められたものだし、現場は成功に向けて努力していたのだから、あまり悪くだけ言うのは不要な対立のもとになるし、せっかくの学びに背を向けることにもなってしまうと思う。人間は不完全でやることは完璧ではない、ということで、公平かつ客観的に見て学び改善を考えればいいと思います。

問題のあるコードやドキュメントを受け入れてみる

私は職業プログラマーです。私たちはよいプログラムコード、よいドキュメントが大好きです。よいコードやドキュメントが好き過ぎるあまり、よくないプログラムやよくないドキュメントの批判をします。まあ、よいもの志向の真面目さの現れなので悪いことではないかもしれません。しかし少々度が過ぎるのではと最近と感じています。

よいも悪いも程度問題でグラーデーションです。悪いものをあまり強く非難すると、それらを作ることそのものの敷居を上げ、学んだり相談したりすることを躊躇させ、最終的に悪いものを増やすことになってしまう気がします。

よくても悪くても、そこにソースコードやドキュメントがあるなら、それはそのまま受け入れ、読み取れることを読み取り、書いてないことは想像で補う。補うためのヒントや材料としてそれらを見る。そうやってそれらを利用し、今自分たちがソフトウェアで実現したいことをする。そういうマインドセットはどうでしょうか。

例えば、意味不明のコードを私たちは忌み嫌います。そういう文言を大量にネットに放ったため、それを学んで育った開発AIはそういうコードを見つけると問答無用で削除してしまいます。しかしそれは違うと私は言いたい。一見不要で意味不明なコードでも、何らかの意味があるのです。今そのコードを読んでいる私たちやAIにとっては無意味でも、ある特定の条件で意味があり、それに私たちが気づいていないだけかもしれない。その条件が成立したのは昔だけの話で今はないのかもしれないけれど、そのような遺構が残っていたとして、そこから学べることはなにもないと言うのは傲慢です。

書いてあること、ないこと、誤っているようにみえること。それらを正しさで評価して切って捨てるのではなく、それが書かれたときの状況を想像し意味を探る。もしかしたら当時から単なる誤りだったかもしれないけれど、それを書いた当時の開発者の状況や心理を想像し寄り添うことは、そのコードやドキュメントを利用する者に取って必要な態度ではないでしょうか。常に探索の視点を持つことが、優れた探索者を育むでしょう。そして私たちが書くコードが未来に残ることが許されるとしたら、そのように受け入れられるということなのでは?ということも言い添えておきましょう。そんなマインドセットをこれからは持ちたいね、というお話でした。

コードを書くとは、「正解」の居合切りではなく、「関係」を育む旅

プログラミングと聞くと、「論理的に正しいコードを書くこと」「仕様通りに正確に記述すること」といったイメージを持つ方が多いのではないでしょうか。もちろん、コードは正しく動作すべきですし、そのための努力は惜しむべきではありません。しかし、現実のプログラミングは、そのような直感よりもずっと複雑で、一筋縄ではいかない側面を持っています。

プログラムのソースコードは、たしかにその構造や処理の手順を記しています。しかし、その「手続き」の記述の中に、しばしば深く潜むのが「コラボレータとの連携」という要素です。例えば、データベース、外部API、OSの機能など、現代のプログラムは単独で完結することはまれで、常に何らかの外部要素と協調しながら動作します。このコラボレータとの連携が、プログラミングを「ただ正しく書けば良い」だけの行為でなくするのです。もう少し詳しく見ていきましょう。

私たちはコラボレータが提供する「インタフェース」を通じてやり取りしますが、このインタフェースが、コラボレータの振る舞いのすべてを網羅的に説明しているかというと、往々にしてそうではありません。例えば、あるメソッドを呼び出したときに、それがすぐに結果を返すのか、必要なだけ待たせて戻るのか。どのような状況でエラーになり、そのエラーはどういった特性を持つのか。内部でどのようなリソースをどのくらい消費するのか。副作用が発生するのかしないのか。インタフェースだけでは判別できない、いわば「説明不足の領域」が存在します。

そのため、私たちは何らかの「想定」を行い、そのインタフェースとコラボレータの振る舞いを「解釈」し、プログラミングを進めます。しかし、この想定が外れたり、解釈が誤っていたりすると、プログラムは期待通りに動かず、障害を引き起こします。このことを結果論で「正しくなかった」「正しくするべきだった」とだけ見るのは、一面的に過ぎるでしょう。コラボレーターとの連携は本質的に想像と探索であり、そして「完璧に探索し尽くす」ということもないのです。

完璧な連携が崩れる例を挙げましょう。コラボレータ自体が時間とともに変化します。バージョンアップによってインタフェースの仕様が変わったり、内部の振る舞いが修正されたりすることはしばしばあります。その変化が、当初の私たちの想定を覆します。自身が変わらなくても相手や周りが変わるために結局障害となる、というケースです。

もちろん、コラボレータを持たず、引数で与えられた情報だけを決定的に加工するような純粋なプログラム(関数)も存在します。そのようなプログラムは冪等性があり、テストもしやすい。なるべくそのような関数でプログラムを構成すべきだという考え方があるしそれは意味があります。しかし、現実世界の多くのプログラムは、望むと望まざるとにかかわらず、外部との連携を避けて通ることができません。

だとすれば、プログラムというものは、一度「正しく」書けば終わり、という性質のものではない、という結論に至ります。そこには常に、未記述の情報に対する「解釈」、不確実な振る舞いへの「判断」が伴います。そして、それらの解釈や判断は、時間が経つにつれて古くなってしまったり、不十分なものになってしまうことがあるのです。

そうすると、プログラムというもの(そしてそれに対する理解というもの)は、一度作り上げて終わりではなく、常に見直し、手入れをし、探索し、環境の変化に合わせて育てていくもの、ということになります。私たちのプログラムは、常に生き物のように移ろう。私たち自身もまた、その変化を受け入れ、向き合い続ける。共に旅をし続ける。このことこそが、真のプログラミングの営みであると言えるでしょう。

(雑感、2025-12-29)

職場などの組織における人の行動原理

人は周囲を観察して行動の相場を学びそれに倣う。環境に対する個人の模倣的同形化。これはヒトの生存戦略に基づく本能。品質の高さ、暗黙知の充実、トップからの指示や外部からの声に対しての行動や変容に対する消極性のメカニズム。

AIとチャットする

質問するにせよ相談するにせよ、背景とか動機とか現時点での自分の理解とかを積極的に語ると吉。AIは基本連想しているので、いろんなワードが与えられると考えやすいのだろう。 あと対話。AIの回答に対して思ったことをまた入力する。トンチンカン上等。発想が広がるのでかえって喜ばれる。 思ったことを文章にするのが得意でない人には難しいかもしれない。音声入力で挑戦してみるのはどうだろうか。

読み解きにAIを使う

文書や動画を自分で読んだり見たりせず、まずAI に見てもらう。要点を短くまとめてもらい、細かく聞きたいところについては質問する。また自分の理解を言葉にして入力して意見や補足を求める。タイパがいい。有名な本は(特に英語圏で出版されているものは)AI読んでるのでそれについて語ってもらうことができる。

スマホに物理キーボード

Bluetoothで接続できるキーボード、具合がいい。AIとチャットするとか投稿する文章書くとか、もうPCを持ってきて立ち上げる必要がなくなった。

トレパク騒動から考える、みんなイラストになにを見てるの?

江口寿史のトレパク騒動についてずっと考えています。ぶっちゃけた話、トレス自体は悪いことと僕には思えないんです。ちょっと言葉にしてみます。

音楽だとコード進行だとか構成だとかはよほど独自なものでなければ共有財産扱いだし、なんならサンプリングという技法もあります。絵画の方だってフェルメールの昔からトレスは行われていたわけだし、作画ツールの3Dモデルとか多くの人が使っています。なので、一般論として絵画でモチーフと構図を借用することが許され得ない最低の行為とは僕には思えません。肖像権とかパブリシティ権の点で問題がある可能性があるのは理解しますが、江口寿史が描くようなイラストのモチーフや構図ってありふれているじゃないですか。江口寿史はタッチに確立された優れた個性があっての江口寿史であり、ありふれたモチーフや構図の部分で借用があってもそれほど価値を毀損しない気が僕はします。

まあ、手描きの絵だと思っていたものがAIが生成したものだと分かったときに「なーんだ」「騙された」と思う気持ちは僕にもないわけではなく、トレパクに裏切られたと感じ怒りを覚え批難したくなる人の気持ちも想像できないわけではないです。でも、ちょっと怒りすぎという気がします。絵を見て怒ってるわけではなく、トレパクだと聞いて怒ってる、そりゃ作品に関する話じゃないのではないですか。

ネット時代SNS社会では作品は単なる作品ではなくナラティブとして消費されるもの。よくも悪くも。トレスにやたらと過敏で厳格になるとどういうナラティブを楽しめるのか僕にはちょっと分からないです。