2026年アジア大会サッカー男子決勝戦をトヨタスタジアムまで観戦に行きました。惜しくも0-1での敗戦。選手は全力で戦ってくれたと思うのでまずは健闘を讃えたいと思います。おつかれさまでした。 日本がポジション取りや攻撃のパターンが割と固定的で平板だったのに対し、韓国の方が圧縮してメリハリを付けたプレーをしているように見えました。これ自体はどちらがいいということではないですが、失点後も同じアプローチを続けて結局無得点で破れたことに課題を感じました。自分の持ち味や強みを出していくのはいいですが、引き出しの数、駆け引き、変化をつけることでそれらが活きる、活かすものということを選手たちが分からないはずもなく、どういうチーム作りだったのだろうかと疑問です。監督は自分たちのスタイルは出せたと言っているそうですが、サッカーはスタイルを出すのが目的ではないので、5年以上この世代の監督を努めてきて次期フル代表監督になる人にそういうこと言われると心配です。 3万人の入場者で、世代別でも男子サッカーは人気だな、と思いました。自由席を取って遅めに行ったら空き席がなくてトヨスタ登山を強いられました。 松丈コロッケは美味しかったです。
今や昔、UMLといふものありけり
UMLというものがあります。もしかしたらもう「ありました」なんでしょうか。プログラマーの必須科目だった時代がありました。
UMLを知ったときにおもしろいなと思ったのは、プログラムの様々な側面を、様々な視点からモデル化している点です。情報がどのように構成されるか、どのようなインタラクションがあるのか、どのように状態が変化するのか、等々。そのためのダイアグラムがそれぞれあります。あの頃の考えとしては、UMLに規定されているようなダイアグラムを描いてモデリングし、それぞれの切り口で十分に検討すれば、そこそこのソフトウェアが作れ運用できる、ということだったように思います。設計の構造化を促し、検討すべき観点が明示されました。ソフトウェアそのものをまるごと理解すること、話題とすることは難しいので、モデル化するというアプローチはよかったと思います。
実際のところは、そのような多量のモデル/ダイアグラムを維持する負荷とコストが高すぎて、徐々に敬遠されるようになってしまったのかなと思いますが…
ただその理念そのものは悪くないと思います。もっといろいろな切り口のダイアグラムが追加されていった別の世界線もあったかもしれませんね。セキュリティダイアグラム、パフォーマンスダイアグラム、リソース消費ダイアグラム、ログと計測ダイアグラム、ビルドラインダイアグラム、テスティングダイアグラム、コンプライアンスダイアグラム、なんてものを夢想しました。
ソフトウェアを作るときに考慮すべき観点は多岐に渡りますし、見落としは事故につながります。これをよりよく行うために、モデル化し切り口で見る、というアプローチは王道でしょう。AIが大量のコードを生成してくる今、人間はなにをどのように見ることができるのか、と考えたとき、このUML的モデル化はいいかもしれません。モデル化、ダイアグラム化をすべて人間がやると大変ですが、AIありきならありかも？という話でした。
還暦にして惑う（職場編）
私は再雇用2年目で、あと3年半で多分今の会社は卒業です。残り少ない会社生活ですし、できる限り有意義に過ごしたいと思っています。しかし、どうも具合がよくない（点がある）、という話をします。
会社はビジョンだの価値観だのパーパスだのといろいろよいことを言います。そして、もっと積極的に自分ごととして行動しろ、それが会社生活を意義あるものにし、会社にも社員にもよいことだ、と言います。間違っているとは思いません。むしろいいこと言っていると思います。しかし周囲の同僚たちはそのように行動しているようにはまったく思えないのです。
同僚たちは真面目でおだやかで、同時に極めて現実主義であり、したたかです。彼らは職場の空気とあたりまえを的確に捉えそれに従っています。それについて公の場で言葉にして議論することはありません（少なくとも僕に見えるところでは）。この職場でどう振る舞うのがよいのかを瞬時に無言で判断して振る舞っているように見えます。それが時間をかけて彼らが身につけた生存戦略なのです。会社がどんなにビジョンやパーパスや行動規範やネクストチャレンジプランを示したところで、職場の空気のなかの暗黙の価値観に照らして取捨選択されるだけなのです。
そのような職場の人たちのありようも、会社の姿勢も、どちらも私は嫌いではないし、それぞれ理があると思っています。それはいいのです。でも、結局私はどう振る舞ったらいいのか、それは分からないのです。少なくとも、同僚たちとの関係性において、私は集団的アイデンティティを持っていません。そのような状況で、会社の示すビジョンだけを信じて一人で行動する気にもなれません。かといって今いる場所を離れて、居心地のよい場所に行く、という勇気も目処もない。結局、この孤立感を慰撫しつつ、まあ、こういう人がいても悪くないだろうと自分で思えるような振る舞いで、自分がやりたいこと、やってもいいと思えることをする。これが精一杯です。これで残り少ない会社員生活を終えてよいのか（後悔しないか）は分からない（これがまた不安）なのです。
（最近思うこと。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にとっては無意味でも、ある特定の条件で意味があり、それに私たちが気づいていないだけかもしれない。その条件が成立したのは昔だけの話で今はないのかもしれないけれど、そのような遺構が残っていたとして、そこから学べることはなにもないと言うのは傲慢です。
書いてあること、ないこと、誤っているようにみえること。それらを正しさで評価して切って捨てるのではなく、それが書かれたときの状況を想像し意味を探る。もしかしたら当時から単なる誤りだったかもしれないけれど、それを書いた当時の開発者の状況や心理を想像し寄り添うことは、そのコードやドキュメントを利用する者に取って必要な態度ではないでしょうか。常に探索の視点を持つことが、優れた探索者を育むでしょう。そして私たちが書くコードが未来に残ることが許されるとしたら、そのように受け入れられるということなのでは？ということも言い添えておきましょう。そんなマインドセットをこれからは持ちたいね、というお話でした。
