とあるIT屋の独白

ITや経営について主に書きます

ダークなことを許す風潮は危ういと感じる

少し前に令和の虎の林氏が、以下のような投稿をしてました。これについて、思うところなど少し書いてみたいと思います。

この世の中は、善だけで回っているわけではないです。ダークなことも、やはりあるとは思います。ではダークなことがあるからといって、ダークなことをやっていいというのは違うかなと感じます。他の人がやってるから自分もやっていいという論理は、あまり筋がいいとは言えないと私は考えます。

また、法律に触れてないからよいのではという意見もあるかもしれません。しかし、以前の記事にも書きましたがそもそも法律は事細かにルールを定めるという位置付けではなく、法律に書いてなくても人に迷惑や不快に感じさせることはあるわけです。林氏が言うような、いわゆる対立など人が快く思わないことで、インプレッションを集めることが手段として適切なのだろうか。情報発信は有益だったり楽しかったりすることが、基本線であるべきと私は考えてます。とはいえ、投稿内容で人が不快に感じることをゼロにするのは難しいですし、ダークな内容である方が人の注目を集めることが容易ではあるのはその通りと感じます。

ただ、そのような状況だからといって、開き直ってダークな方向を容認するのは個人的には嫌だなぁと思います。それは見ている人も、そういうことをやっていいんだという風潮になるからです。特に経営者層など影響力がそれなりにある人がやることであれば、真似する人は一定数出てくるでしょう。短期的なインプレッションのために社会全体が良くない方向に傾くリスクがあるのは、やはり止めるべきなのではと私は考えます。

モデルとは何かについて考えてみる

システム開発において、データモデルなど「モデル」という単語を見かけることがあると思います。今回はこの「モデル」という単語について少し書いてみます。

まずモデルの意味について考えてみます。モデルという単語が持つ意味合いは複数あると考えていて、以下の資料の通り、理想、典型、規範、近似などが挙げられます。例えばファッションモデルとかは「理想」のカテゴリーに入りますね。

【モデルとは何か？】
http://dse.ssi.ist.hokudai.ac.jp/~onosato/lectures/DSE19/H19-Model.pdf


システム設計におけるデータモデルやドメインモデルは、近似の意味合いに近いと考えています。例えば紙で行っている業務フローをシステム化する場合、人がどのような業務を手動で行っているかに近似するような設計にすると思います。業務をどのようにモデル化してシステム設計するかは、以下の記事にある通り抽象化や解釈を行う作業が必要になります。

made.livesense.co.jp

抽象化を行い、いくつかの正解（様々な解釈）の中から採用するモデルを決定します。改めて、関係する側面を抽象化して、集中するモデルを決定します。


具体例としては、以下の記事にあるようなデータモデリングが挙げられます。システム化の対象に分析をした後に、どのような特徴があるかを見出すことがモデル化には重要と考えられます。

xtech.nikkei.com

「商品名とメーカー名は不変だけど、商品のサイズやカラーは増減するかもしれない」「商品価格や在庫は変動する」という特徴が見えてくると


AIモデルになると、文脈によって意味が少し変わる感じはします。ChatGPTやClaudeなどの汎用AIはプロダクトのシリーズになるので、いわゆる「規範」としての意味合いが強いかもしれません。一方で自分用に開発したAIモデルは、あるタスクの遂行を目的とすることが比較的多いことから、「近似」の意味合いが強くなる気はします。

モデルという用語はそこかしこで使われるので、このモデルはどういう意図で使ってるか考えると、文脈理解の助けになるかもしれません。

AI時代でのプロセスの重要性

2026年6月現在でも、AIが話題になり続けています。AIに指示すれば、すぐに結果が得られるというのはその通りですし、今後も利活用は広がるでしょう。ただ、結果がすぐ得られるからといってプロセスが雑になるのは、本末転倒でしょう。むしろ結果が早く得られるからこそ、プロセスに価値を置くべきと最近は感じます。
以下の記事は戒名の例ですが、AIで戒名をそれっぽく作るのは難しくないでしょう。ただ、果たしてそれっぽいものに対して価値はあるのか。実質的にプロセスの無い成果に意義はあるのか。

shueisha.online

最終的に、ご家族やお寺が一緒になって『あの人らしい漢字はなんだろう』と考え抜き、お寺から手渡しで授与される。その『人と人との繋がり（プロセスの物語）』こそが本質であり、テクノロジーに全てを委ねて自動化・効率化してしまってはならない境界線

作業をAIに行わせるにしても、そのプロセスは大事と考えています。どのようなプロセスでどの工程でAIを活用するのか。AIをとりあえず使うことは全否定はしませんが、業務に適用する以上はプロセスの棚卸しは行うべきと感じます。
このプロセスの設計をスキップしてAIを思考停止で使うことは、無駄な手戻りや成果物の品質に関わると考えます。プロセスの設計イメージとしては、以下のプロセスマイニングに手法が参考になると思います。

www.ey.com


例えば以下の三菱電機の品質不正のように、やらなくてもいい作業がプロセス上に存在することも考えられます。ただ、プロセスを変えたくないという気持ちはわかります。変えるには組織の人と合意を取るなど、労力を使うからです。ERPの導入においても、標準のプロセスに日本の会社は中々合わせるのが難しいという話もあったりしますが、プロセスを変えることの大変さという面はあるかなとは感じます。

monoist.itmedia.co.jp


今の時代は、実作業はAIにシフトしていくことが考えられます。今までは人間のためのプロセスでしたが、AIを活用するためのプロセスに変えていくような動きは出てくるでしょう。なのでAIの活用がさけばれている今こそ、プロセスの再設計を行うチャンスと個人的には思います。
以下の記事に挙げられているAIプロセスマイニングは、アプローチとしては面白いと感じます。プロセスの分析からAIに行わせることで、人間のバイアスをある程度取り除くことは期待できるからです。ただ、もちろんAIの出してくるものは絶対ではないので人間の判断は必要にはなると考えてますが、それでも硬直したプロセスを変えるとっかかりにはなるかなとは感じます。

speakerdeck.com

ポピュリズムの膨張に対する懸念

政治を行う以上は、いわゆるポピュリズムが起きてしまうことは致し方ない面はあります。結局は選挙に勝たなければいけなく、ある程度ポピュリズム的な要素も含めないとウケが悪くなるからです。そもそも、ポピュリズムという概念はどのようなものであるか。以下の記事にある通り、良く言えば一般大衆の意見の代弁になりますが、悪く言えば大衆迎合となります。

www.dlri.co.jp

広辞苑でも「一般大衆の考え方、感情、要求を代弁しているという政治上の主張、運動」と解説されています。他方で、実際には多くの場合、「大衆迎合主義」といった否定的な意味合いで使われています。

ポピュリズムが高まる背景としては、既存政党に対する不信です。不信感が高まっている大衆に対し、ポピュリストは極端な政策を掲げる傾向にあります。大衆としてはこれが銀の弾丸と思ってしまう面はありますが、実際はデメリットもあるかなとは感じます。

research.nira.or.jp

政治への不信が高まったことで、政治局面を一変させる政策を掲げるポピュリズムが台頭したのである。しかし、ポピュリズムが招く極端な政治は、大きく政治を変化させるが、政治的な不安定さを招くことがある。

極端な主張が多くの支持を集めてしまうと、権力の集中や対立の深化につながるリスクがあると考えています。ポピュリストは、対話よりも自身の主張を正当化するような傾向にあるとみられるからです。アメリカのトランプは、まさにその傾向があると感じます。自分に反対する意見の人を要職から外し、対外的には対立を煽るような行動をとります。

blog.smartsenkyo.com

ポピュリズムは、カリスマ性を持つ強い指導者が大衆を率いて成り立っていることがほとんどです。そのため、その指導者に権力が集中し、独裁に陥る危険性があります。

また、国民の不満や不安を煽り、敵をつくる傾向にあるので、社会の分断を生むことがあります。

ポピュリズムでも、選挙で勝てばそれが民意という意見も分かりますが、選挙で勝てば自分達の好き勝手にやっていいというわけではありません。現実世界には、ポピュリストの極端な政策によって不利益を受ける人や、そもそも支持してない人も存在するでしょう。ポピュリズムが膨張しかけている段階において、いわゆる少数意見の尊重は極めて大事になってくると感じます。

globe.asahi.com

投票で決めることは大事ですが、投票だけですべて決めていいわけでもないのです。『民主主義イコール多数決』ではない、というところをしっかり認識する必要があると思います。

冒頭にも書きましたが、私はポピュリズムを全否定するわけではなく、むしろ一定数はこのような人が存在するほうが自然ととらえています。ただ、それが膨張してしまうと良くない方向に行くリスクが高くなり、我々大衆がどこかで歯止めにならないといかんなぁと感じる今日この頃です。

挑戦してない人が挑戦する人を批判するなという主張について

何かに取り組んでいる人に対して批判すると、「挑戦してない人が挑戦している人を批判するな」みたいな反論がSNS等であるかと思います。もちろん挑戦する人はできれば応援したい気持ちはわかるし、それを馬鹿にするという行為はいけてないなとは感じます。

ただ、少し冷静になってみると、批判する人も挑戦すること自体というよりは、その内容について批判してることが多い気はします。特にその挑戦が周囲の人に悪影響をおよぼしそうな場合は、批判がくるのも致し方なしな面はあると思います。具体の批判に対して、挑戦という抽象的な概念を持ち出して反論するというのは、なんかごまかしてるんじゃないかという疑念は生じる気はします。
そもそもですが、何を「挑戦」とするのかはそれぞれの人の考え方によって変わると思います。借金などして大きなリスクを取って起業するだけが、挑戦とは私は考えません。リスクを抑えつつ物事に取り組むことも、人によっては挑戦の範疇に入るのではないでしょうか。なので誰が挑戦しているかしてないかというのは、人それぞれの価値観によって異なると私は考えます。主観的な判断で、人を色分けしたものをベースに主張をしているということになると思います。

まとめると「挑戦してない人が挑戦している人を批判するな」のような反論は、主観的な観点で具体性も欠けており、この反論に何か意味があるようには個人的には感じません。

ペアプログラミングについて思うところ

ITの現場にいると、ちょくちょくペアプログラミングの取り組みを行う機会があるかもしれません。私も何度か行う機会はあったのですが、自分が教育係みたいになってしまって、果たしてこれはペアプロなのかと感じてしまいました。。

以下の記事で触れられている通り、ペアプロの相手をどうするかはけっこう大事と思います。私の場合はピンポイントでやるというケースが多かったので、そこまで強いストレスにはなりませんでしたが、毎日ペアプロやれと言われたら、たぶんしんどいなぁと感じるところではあります。

qiita.com

あなたが運転する車に、あまり仲良くない人間を乗せて、ふたりきりで8時間ドライブをしてください。最初は世間話や当たり障りのない会話でごまかすことができるでしょう。しかし、人生の価値観や趣味などの深い話では価値観が合わないため、会話が続かず、次第に沈黙が多くなっていくでしょう。

そもそもペアプロの目的は何なのか。知識の共有やレビューコストを削減する、といったものはとりあえず挙げられるでしょう。もちろんそれを否定することは全然しませんが、個人的には本来的なものは少し別なところにあると考えています。
それは、以下の記事で野中郁次郎先生が触れられている「知的コンバット」です。最終的には、組織で「知」を生み出すことにあると考えています。

hello.coacha.com

双方が感じた異なる直観を、真剣勝負で何度もぶつけ合いながら、ようやく「こうとしかいえないよね」というコンセプトにつながっていくという感じです。この「共同化」のプロセスがない限り、組織で「知」を生み出す、イノベーションが起こるということはあり得ません。


組織で知を生み出すために、どのようなペアプロがよいか。個人的には以下の記事にあるような、突発的なペアプロが良いと感じます。ペアプロにおいても直観的なものが大事で、率直な意見が言える雰囲気だと目的にも近づけそうな気はします。

japanrock-pg.hatenablog.com

どういうときに成果がでるのでしょう。それは、「突発的ペアプログラミング」でした。以前は「計画的ペアプログラミング」でした。

とは言いつつ、そのような関係をすぐに築くのは難しいでしょう。チームビルディングの最中はどうしても、計画的ペアプログラミングっぽくなると思います。このチームビルディングの手助けを行うのが、スクラムの手法と私はとらえています。
ただ、スクラムはどうしても手法論によりがちで、本来的にあるべき姿を見失うこともあるように感じます。ペアプロも義務的にやるのではなくいわゆる自然発生的に、必要だからやるという雰囲気作りが大事とは思っています。手法だけやればチームが良くなるということはなく、どう良くしていきたいかという意識がまずは重要なのではないでしょうか。

要件や計画をころころ変えるのはアジャイルではないと思う

以前に、考えなしにとりあえずやってみるという行動について、否定的な記事を書きました。
toaruit.hatenablog.com

その時は、例えばアジャイル開発であれば探究心的なマインドが必要と書きました。今回もほぼ同じテーマなのですが、もう少しアジャイル開発にフォーカスして思うところなど書いてみます。
変化への対応は、アジャイル開発を導入する主目的の一つと思います。ただ、この「変化」というのが人によって捉え方が異なると私は感じていて、認識が合わないままに開発がダラダラ進むことはあるかなと感じるところではあります。
では、アジャイルにおける変化とはどのようなものか。個人的には以下の記事にある「ユーザーのニーズの変化」、「競合環境の変化」、「最適解が不明」といったものが挙げられるかなと感じます。

globis.jp


一番厄介なのは、最適解が不明というケースと考えています。最適解が分からないからたいして深掘りせず走り出す、というのはかなりのアンチパターンなように個人的には思います。以下の記事のように、作りながら考えるような姿勢に偏るのは、無駄が多くなるというのはその通りと感じます。

www.intra-mart.jp

発注側と開発側で期待している成果物が異なっている場合、後工程で大きな修正が必要になるケースも少なくありません。アジャイルだからといって「作りながら考えればよい」という姿勢に偏りすぎると、無駄な試行錯誤が増えてしまいます。


そうなると計画なんてあって無いようなものになり、以下の記事にあるようにプロジェクト全体もグダグダになります。要件や計画を変更するなというわけではなく、メリハリをつけることが大事と考えています。スクラムには「リファインメント」や「プランニング」というプラクティスが用意されてますし、秩序なく思いつきのような感じで進めるのはアジャイルではありません。
メリハリなくダラダラ進めていく開発はメンバーの士気も下がりますし、本来のアジャイルの姿から程遠いものになると感じます。作りながら考える感じで進めて、成果物の深堀りが本当にできるのかはあらためて考えるべきことと思います。

zenn.dev

誰にもプロジェクト計画書は承認されないまま、なし崩し的にプロジェクトは始まり、バックログはプロダクトオーナーによって、頻繁にリファインされ初期のプロジェクト計画から大きく変更