アップダウン」の採用アプローチが現実的な選択肢となりそうです。JDに書かれるような要件を自らの個性として体現しているリーダー、そして環境の変化に適応し成長を続けているリーダーが主役となるのです。各々のリーダーがそのチームに必要な人材像を定義し採用に関わっていくのが「ミドルダウン」の方向性です。リーダー同士の協調で解決しない問題や、調停が必要な衝突が生じたときの調整役を探しに行くのが「ミドルアップ」の方向性です。

「トップダウン」のアンチパターン

典型的な失敗は、既成の組織図の空席を埋めにいく「白地図に色を塗る」ようなトップダウンアプローチです。この白地図は他社の成功事例から安直にコピーされたものであったり、落下傘で降りてきた役職者とともに持ち込まれる場合もあるでしょう。社員が辞めない・辞めさせられない「日本の雇用慣行」の下でこの方法は強い副作用を引き起こします。組織図に合わない人が押し出されることがないわけですから、このアプローチは裏表のあるカルチャーを生み出し、面従腹背の社員を増やすだけです。

柔軟な一枚岩の組織

リーダーの個性を軸としたミドルアップダウンが組織を一枚岩にする、このように言うと、「個性」と「一枚岩」という言葉の対比に違和感を持たれるかもしれません。しかしながら、多様な専門性と変化への適応力が必要とされるプロダクト開発の現場においては、画一的な方法で人同士のつながりを維持することは困難です。リーダーたちの個性が「しなやかな関節」として機能し、変化に即応できる一枚岩の組織を編み上げる、これが、ソフトウェア開発の現場における現実解なのです。

2b:Tc28,

「定着しそうにない」というフィードバック

私はこれまでに10回以上の転職を経験してきました。それは裏を返せば、100回を超える「お断り」を受けてきたということでもあります。キャリアの中盤以降では、不採用の理由として「定着しそうにない」というフィードバックをしばしば受け取りました。この文脈で言われる「定着」という言葉について、少し掘り下げてみたいと思います。

「定着」を、あえて「執着」や「居座り」という言葉に置き換えてみるとどうでしょう。組織に執着し居座り続ける、そんな兆しが見えた候補者をあえて採用することはないはずです。ではなぜ「定着」ならポジティブなのでしょうか。

何に「定着」することを期待しているのか

「定着」という特徴に期待するのは、一般的には、長期的な目標や仕事へのコミットメントを示す能力でしょう。安定して貢献してくれる人材を求めるというのは、採用の文脈では自然です。

しかし、「長期的」「安定して」という時間軸のニュアンスばかりが重視されてはいないでしょうか。先決問題は「貢献できるか」だと思います。長期的に安定して「貢献できない」となれば、その状況はまさに居座りだからです。

「定着」の裏側に潜む、双方の甘え

「定着」の両サイドには、採用側と候補者側、双方の「甘え」が潜んでいるように見受けられます。採用側は、年功序列的な評価軸から脱却できず、一方的に人材の成長を期待してはいないでしょうか。候補者側では、自身の市場価値に評価を下すことを避け、会社という場所あるいはポジションに過度な保護を求めていないでしょうか。

私の経験上、プロダクト開発チームは、リーダーがゴールを語り続けることを怠ればわずか2週間で瓦解し始めます。目標を達成するために必要なのは、定着特性の高い人材を揃えることではありません。マネジメントが鮮明なビジョンを示し続けること、同時に個人がプロフェッショナルであり続けること。この両側にある厳しさと、その間に生じる健全な緊張感こそが不可欠なのではないでしょうか。

かつて私に直接フィードバックをくださった企業の方々は、当時の私の「貢献の再現性」を真摯に評価してくださったのだと理解しています。私の経歴を把握した上で対話の機会をいただけたわけですから。改めて感謝いたします。今後もプロフェッショナルとしての研鑽を積みますので、またどこかでご縁がありましたら、その際はよろしくお願いいたします。

2c:T2aa6,

クリーンアーキテクチャの時代

この記事は、Robert C. Martin（Uncle Bob）によって紹介された「Clean Architecture」を題材に、そのようなアーキテクチャが発想された背景や、解決しようとしている課題、そしてプロダクトへの適用可能性について考察するものです。Clean Architectureそのものを解説することを目的とはしていません。

はじめに

アーキテクチャはフレームワークではなく、ましてやプロジェクトのディレクトリ構造を規定するものでもありません。この点は重要で、誤解してしまうと、アーキテクチャを応用したつもりで用途に合わないフレームワークを導入しただけという結果になりかねません。

この記事はなにか具体的なルールを見出そうとするものではありません。ここで触れるアイデアをもとに、プロダクトや私たち自身との相性を考慮しながら、実践的な取り組みを進めていきましょう。

Architectures are not (or should not be) about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.

アーキテクチャはフレームワークのようなものではありません（あるいは、そうあるべきではありません）。アーキテクチャはフレームワークによって提供されるべきではありません。フレームワークは使用すべきツールであり、従うべきアーキテクチャと異なります。もしあなたのアーキテクチャがフレームワークに基づいているなら、それはあなたのユースケースに基づいているとは言えません。

Robert C. Martin, 2017, Clean Architecture: A Craftsman's Guide to Software Structure and Design (以降、注記のない引用はこちらの本から)

時代背景を知る

先に引用した本は2017年に出版されましたが、そのアイデアは著者がそれ以前から展開していたものです。この発想の原点を理解するためには、Web2.0という言葉が生まれた2000年代初頭まで遡る必要があります。

2000年代初頭といえば、XPが認知され、アジャイルソフトウェア開発宣言が出版された時期です。開発と保守との境界が消失し、システムの保守というものが永続的なプロセスになり始めた時代です。

それ以前は、システム開発は設計時点での与件に基づいて行われ、保守は技術的な環境変化への適応し稼働を維持することを目的としていました。しかし、2000年以降は、ダイナミックなビジネス環境へ継続的に適応できるかが重要になりました。

つまり、コンピュータシステムがプロダクトとしての性質を持ち始めたのがこの時代です。システムの保守戦略がプロダクトの成長戦略と言い換えられるようになりました。

引用：総務省・令和元年版情報通信白書

ご存知の通り、アーキテクチャは開発と保守の両方に関わる重要な課題です。このような時代背景を踏まえながら、Clean Architectureについて見ていきましょう。

2000年以前の話

2000年以前の保守戦略は構造の保全を基本としていました。開発時に設計された「正しい構造」を保守プロセスの中で維持しつつシステムの寿命を延ばすことに重点が置かれていました。さらに問題が発生した場合はパッチで対応し、システムが機能しなくなった場合は全面的な再構築を行うというアプローチでした。

本書ではこの種の「設計の正しさ」を「自信過剰」と表現しています。（劣化したシステムを一から作り直すというアイデアに対し）

Their overconfidence will drive the redesign into the same mess as the original project.

再設計したとて、エンジニアの自信過剰が元のプロジェクトと同様の混乱を再びもたらすでしょう。

2000年以降の話

Clean Architectureのアイデアは、プロダクトの発案、開発、リリース、そして成長という時間軸を意識しています。そのため、「アーキテクチャ」という言葉から受ける印象とは異なり、変化に対応するための柔軟性を備えています。より正確には、安定した部分と柔軟な部分が共存する構造となっています。

時間軸の導入

プロダクトの成長を考え、ビジネス観点で物事を整理するには、現在から未来への時間軸を意識する必要があります。当然ながら、私たちは未来を完全に予測することはできません。

技術的観点から物事を整理する場合、与件に基づき「どのように作るか」という点だけを考えれば十分かもしれません。しかし、ビジネスの観点も必要となれば、「いつ作るか」「作り続けるか」という要素も同時に考慮しなければなりません。

これはプロダクトの成長という中長期的な時間軸においても、２週間のスプリントという短期間のなかでさえも同じことです。

The composition of the components will likely jitter and evolve with time as the focus of the project changes from develop-ability to resuability.

プロジェクトの焦点が開発の容易さから再利用性に移行するにつれて、コンポーネントの構成は時間とともに揺らぎ、進化していく可能性が高いでしょう。

クリーンアーキテクチャ

クリーンアーキテクチャの特徴を示すオニオン図を見てみましょう。この図は、コンポーネントをレイヤーに整理する際、技術的な性質ではなくビジネス上の性質を基準としています。ビジネスにとって本質的で変化しにくい要素ほど内側に、変化しやすい要素やビジネスと無関係な技術的要素ほど外側に配置されています。

引用： https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

ビジネス観点からの変更可能性を基準として構造を整理することで、環境変化に強いシステムが実現されています。プロダクトとしての成長可能性も実現されているといえます。構造は一時的なスナップショットをもって評価できるものではありません。

There is false or accidental duplication. If two apparently duplicated sections of code evolve along different paths — if they change at different rates, and for different reasons — then they are not true duplicates.

偽のあるいは偶然の重複があります。一見重複しているように見える2つのコードセクションが、異なる経路で進化する場合 — 異なる速度で、異なる理由で変更される場合 — それらは真の重複ではありません。

Appendix

ユースケースとは

本書の中でいうユースケースとは、以下の引用の中で言われるシステムの意図を可視化するための方法論であって、何かの実装方法やコンポーネントの種類ではありません。

The most important thing a good architecture can do to support behavior is to clarify and expose that behavior so that the intent of the system is visible at the architectural level.

優れたアーキテクチャが振る舞いをサポートするために最も重要なことは、システムの意図がアーキテクチャレベルで可視化できるように、振る舞いを明示し公開することです。

主観の必要性

振る舞いの局在性（Locality of Behavior）について、それが原則論とコンフリクトする際の対応について、htmxの著者が興味深いことを述べています。

There is no hard and fast rule, but rather subjective tradeoffs that must be made as software developers.

確固たるルールはなく、むしろソフトウェア開発者として主観的なトレードオフの判断をする必要があります。

Carson Gross, https://htmx.org/essays/locality-of-behaviour/

「主観的な」とは、工学的な手法による単純な評価ではなく、プロダクトの特性を総合的に考慮した上での判断が必要だと解釈できます。

技術的コストの変遷

技術的な正しさを判断する基準の一つはコストですが、この判断基準は常に更新していく必要があります。例えば、tailwindcssのドキュメントには興味深い記述があります。コードの重複に対する解決策として、エディタのマルチカーソル編集機能が紹介されています。この種の重複は、以前であればCSSクラスの作成の動機となっていました。

https://tailwindcss.com/docs/styling-with-utility-classes#using-multi-cursor-editing

ツールを活用してコードの局在性を実現する方が、結果的に保守性の高いコードを生み出せる可能性が高いと言えます。特に現在では、AIの活用も可能になっており、このようなコストに関する考え方を見直す必要があります。

2d:Tbb5,

こんにちは。『技術選定』の話を書こうと思いますが、大きすぎるテーマに思われますので、今回は前の記事に書いた「いきなりレガシー」問題のみに焦点を絞ります。

いきなりレガシー

新しく作ったのがもうレガシーと呼ばれる、そんな様子を「いきなりレガシー」と表現しました。多くの場合、以下のような特徴を持っています。

過去のコードからのコピー＆ペーストがある
自家製ユーティリティ集に依拠している
環境構築やデプロイについて手作業が多い
プログラミング言語やフレームワークのバージョンを上げられない
前任者が出世している

なぜそうなるの？

考えなく前例踏襲をするからです。より正確に言うと、前例の動機や背景について思いやることなく成果物のみを借用するからです。

まるで同じロジックがあるとは思えないし、あるとすれば共通化なり外部化されるべきではないのか？
そのユーティリティが製作された当時の制約がいまでも存在しているのか？制約が消滅あるいはより信頼性の高い解決法が出現していないか？
喉元過ぎれば熱さを忘れる。
ハッキーなソリューションはいつでも推奨されない！言語やフレームワークの思想を理解しよう。
無用な忖度はやめよう。実際、偉い人はただただ収益性の高いプロダクトを望んでいるだけだ。

受け継ぐべきは「知識」です

受け継ぐべきは知識です。古いコードではありません。

古いコードの動機や背景を思いやり、ノイズを除去して、プログラミング言語やフレームワークなどのツールの思想を理解し、プロダクトの本質を知ることが大事です。

現在進行中のプロジェクトとしては、プロジェクトメンバーが「知識」を最大限に蓄えられるように工夫があるべきです。

将来また同じメンバーで仕事ができれば最高ですが、そうでなくてもそのような「知識」は組織のレイヤーにも透過的にレプリケートされていくものだと私は考えています。

おわりに

最後までお読みいただきありがとうございました。

あと一つ付け足しですが、思想を理解するとは、憶えるとか身につけるということではなくて、一緒に考えるという意味でした。

◇

初出は note です。

2e:Tce6,

組織に関わる話で『カルチャー』という言葉を頻繁に聞きます。それはときに理念のようで、ときにそこそこ強い行動規範のようです。そのカルチャーとは何なのでしょう。

それは招待状だと思います。

それでは、私が疑問やら、この言葉を使うとき耳にするときに留意しておきたいことなどをお話ししたいと思います。

同調圧力なんだろうか？

カルチャーには「自然に形成される」のニュアンスがあると思うのですが、行動規範のような内容を示されたときに違和感を覚えます。

自然・普通に・合意できて当然、このような論理だと、マイルドなニュアンスとは裏腹にけっこうな圧力を感じます。

文明なんだろうか？

カルチャーが「未開の地に文明をもたらす」の勢いでアピールされることがあります。

この場合、暗黙的に何かの否定とセットなので、やはり圧力を感じてしまいます。

カルチャーフィット？

採用面接で評価されるカルチャーフィットとは何なのでしょうか？これ、じつは、カルチャーとは関係がないと思います。

柔軟性とか常識力とか、その種の説明しにくい情緒的な理由の言い換えと推測します。

カルチャーは現実ではない

ところで、カルチャーを説明してくれる人はカルチャーの体現者なのでしょうか？その会社ではカルチャーが生きているのでしょうか？

多くの場合で答えはNOだと思います。そこにはカルチャーと対峙する課題が横たわっているのです、つまり、そこにある現実はカルチャーの逆。

カルチャーを言う理由

カルチャーを言うのは、その反対側にある課題を解決するアイデアが欲しいからです。そのジャーニーに参加してくれる仲間が欲しいわけです。すなわちカルチャーは招待状なのです。

極端な言い方をすれば、カルチャーに描かれた世界はファンタジーです。そこにある果実を収穫できません。収穫できるかはその組織のこれからの頑張り次第なのです。

だからあなたが仕事を探しているなら注意してください。カルチャーにはあなたが現時点で獲得できるものは何も描かれていないのです。

おわりに

採用する側で思いを語るとき、あたかも種々の理想が実現済みであるかのような錯覚に陥ることがあります。そして、錯覚にとらわれながら話をしてしまった不誠実さを反省することがあります。

謙虚さを忘れないようにしたいと思います。頑張ります。

最後までお読みいただきありがとうございました。遅れましたが、2022年もよろしくお願いいたします。

◇

初出は note です。

2f:T8db,

エンジニアにとって、「これできますか？」は最も回答が難しい質問の一つです。なぜなら答えはいつでもYESだからです。

答えはいつでもYES

大概のことは技術的に可能なのです。だから基本的にYES。しかしながら以下のような理由により回答を躊躇してしまいます。

そもそも「これ」の抽象度が高いので具体的なゴールがいくつも見えてきます。本当にやりたいことは何なのだろうと考えてしまいます。

手段についても迷います。ソフトウェア開発においてはいつも、目的を実現するための方法は幾通りもあり、それぞれの方法にそれぞれの利点・欠点があります。

トレードオフの関係性を解きほぐす必要があります。それからどういう基準でリスク評価をすればよいでしょう。

十分な情報のインプットが無い状況では結論を出せそうにありません。たぶん、出てくる回答はそのエンジニアの気分もしくはキャラクター次第になるでしょう。

観点がわからない

さるとガソリンどっちがすき？／さる
引用：Z CHAN 井口真吾 1989

観点がわからないとこのようにすがすがしく空虚な会話になる

おわりに

今回は短い文章の投稿となりました。

エンジニアはひねくれものだということを言いたかったのではありません。共通の背景をいつもメンテナンスしておくと仕事が楽になるということを言いたかったのです。なお、あえて背景を察しようとしないエンジニアは本当のひねくれものですよ。

最後までお読みいただきありがとうございました。

◇

初出は note です。

30:T1ed8,

ＩＴ業界で聞く『レガシーシステム』とはなにかのお話です。今回から「となりのプログラマー」にシリーズ名が変わりました。前回のＣＴＯ１年振り返りからの続編でもあります。

「経営層」という言葉を文中で使いますが、適宜「なにか決める人」くらいに置き換えていただけますと幸いです。さほどエンタープライズな話ではありません。

レガシーシステムとは

「いまだ本番稼働中であるけれども構成要素がだいぶ古いシステム」を指して言います。古いバージョンのプログラミング言語やフレームワークで構成されています。

辞書どおりの意味「遺物」で使われることはまれですが、担当者の退職を起源とするレガシーシステムはそこそこ存在します。

エンジニアはレガシーシステムが嫌いだ

エンジニアは新しいものが好きだからレガシーシステムが嫌いという見立ては短絡的でしょう。実際問題としてレガシーシステムの周辺には様々な困難と危険があるのです。

数々の暫定対応が重ねられてきたため無用に複雑
現在のビジネスを投影した形になっていない
仕様は文書化されていないが、実装から仕様を理解することも難しい
近代的ベストプラクティスは適用できない
変更のコストを見積もることが難しい
変更のリスクを評価することが難しい

例）ジュニアエンジニアの危険
コストを過小評価⇒自己責任論による長時間労働⇒システムを修理した人以上の評価は無し⇒退職

例）ベテランエンジニアの危険
バッファを取って工数を多めに見積もる⇒リスクを声高に叫ぶ⇒会社からうとまれる⇒リストラ

事情が複雑なので図を書いてみます。レガシーシステム由来の技術的な難しさではなく、自己解決が難しい問題について人間関係も絡みつつプレッシャーが掛かってくる、というのが問題のように見えます。

そしてこの問題が認知されるのが、レガシーシステムが壊れるタイミングではなく、開発チームが壊れるときというのが恐いところです。

それでは、新しいシステムへ移行しよう

上の図では開発チームがすでに壊れていますので、開発チームが疲弊しきる前に移行の決断をしたいものです。しかし、その必要性を経営層に理解してもらうためには越えなければならない壁があります。

簡単な図を書きます。要点は①レガシーシステムが生み出し続ける作業を知ってもらうこと②その作業が「非本来的」なものだと認識してもらうこと、になります。非本来的作業とは、その人の職能を無視していて生産性や創造性を奪う性質のもの、という意味です。

さらにもう１つの壁があります。新システムへの移行を決断しそれを完遂したとして、その効果が遅れてやってくるということを事前に共通認識としなければなりません。さもないとプロジェクトが不当な評価を受けるかもしれませんよ。

２つの壁は越えられそうでしょうか？実際問題、根回し段階からかなり困難なプロジェクトとなりそうですよね…。

実際的な戦略

必ずしも正面からぶつかる必要はありません。実際的に考えましょう。いくつかの戦略を紹介します。

①機能開発と同時進行させる

フロントエンドとバックエンドが分離できているのなら、フロントでUIの刷新をしつつバックエンドの移行を進めましょう。BFF層を作ってみるのも良いでしょう。移行期間中も目に見える成果物が生まれ続けるのが良いです。レガシーシステムがフロント・バック・インフラまで一緒になったフルスタック型のフレームワークを使っていると痛いです、この戦略は採用できません。

②自動化テストと監視体制構築のプロジェクトに変える

新システムへの移行には前段階としてE2Eテストや監視を充実させる必要があると思います。それをプロジェクト化してしまうことで、新システムへの移行を成果物が出てくるプロジェクトに変えることができます。実際、自動化テストや監視ダッシュボードなどは見た目にとても説得力があります。

③事業仕分け戦略

そもそもこのシステム要るんですか？の問いかけからスタートして、レガシーシステムを「ただのお荷物」に降格させる戦略です。外部のSaaSを利用するなどそのシステムを代替する方法があるのではないでしょうか。もしすこしでもこれが成功しそうなら、この戦略が第一選択になるでしょう。注意！移行後の成長戦略をあわせてデザインしておかないと開発チームがお荷物になってしまうかもしれません。

余談

誤った戦略

あなたがレガシーシステムのおかけで潰れた会社を10社以上知っているコンサルタントなら別ですが、技術的負債とか技術的流行語でステークホルダーを説得しようとするのはやめましょう。腹落ち無しのうわべの合意でプロジェクトが始まって、中途半端に終わるのが目に見えています。

いきなりレガシー

古い技術をつかってシステムを作りますといきなりレガシーになります。会社の立ち上げメンバーが使い慣れていた技術を使ってアプリケーションを作った場合などです。この辺りの技術選定の話はまた別の機会に。

おわりに

最後までお読みいただきありがとうございました。

あと、ひとつ大事なことを付け足します。

あるシステムがレガシーシステムと呼ばれるようになるまで多くの開発者が関わってきたと思います。この記事は彼らの仕事を批判するものではありません。そのようなことはあってはなりません。

会社を大きくしようとか世の中を楽しくしようとか、そういう当時の開発者たちの思いやりに立ち返りながら、それを現代のコンテクストのなかで再解釈し、再び実装して前に進もうというのがレガシーシステムマイグレーションの目的です。

◇

初出は note です。

31:T12be,

2020年9月からBEAMINGのCTOとして働き始めて、1年が過ぎましたので振り返りをしようと思います。ちょうど大きなイベント「MUSERフェス」も終わりました。

活動ログと成果物

GitHubのスクリーンショットをつなげました（草原の偽造はしておりません・趣味の稼働を含みます）

2020-09 ～ DBがスパイクしてMUSERが止まりました。
2020-10 ～オフィスが五反田に移転しました
2020-11 ～配信画面のUIを一新しました
2021-01 ～サーバーレスのバックエンドが稼働開始しました
2021-02 ～全体のUIを一新しました
2021-03 ～チャンネル機能をリリースしました
2021-04 ～ MUSERフェスの開発が始まりました
2021-06 ～ MUSERフェス会場がオープンしました
2021-09 ～ MUSERフェス本番が開催されました

活動の背景

活動方針を決めていくにあたって、私の中には以下のようなゴールがありました。

目に見える成果物を定期的にリリース
説明できるバックエンド開発
テクノロジーで対話を

MUSERはベンダーに作ってもらったV1から内製のV2への移行期にあります。逐次移行する方法もありますし、一気に作ってビッグバンリリースする方法もありますが、上記の背景から前者を選びました。

テクノロジー的に良かったこと

TypeScript 始めました（バックエンドも）楽しくプログラミングしています。業務委託の開発メンバー集まってくれたのもこれのおかげかもしれません。フロントとバックエンドとを同じ言語で書いていると lint 設定がすごくラクです（もちろんそれだけじゃない）。

DynamoDB + Single Table Design 始めました

DynamoDBは凝ったことができるKVS。KVSだからデータの読み書きで想定外のことは起きません。お客さんがいくら増えても・盛り上がってエールを送りまくっても安心です。

テクノロジー的に悪かったこと

エンジニア採用

プロダクトが弱い、私のプロダクトへの理解も未熟、結果として不誠実な採用活動になったと思います。自分で自分が薄っぺらい人間に見えたので、モノを作ってから出直します。

設計に費やすべきあと数日

MUSERフェスは唐突に始まったのですが、とはいえ設計にあと数日でも多くの時間を費やして、より厳しくなれなかったものだろうかと反省しています。Workaroundが多くなり過ぎました。

そもそも論

CTOの定義

事業系スタートアップの初代CTOに仕事の定義などあるわけがなかったです。そういう環境下で、会社やら社員やらプロダクトとの距離感を無用に頻繁に測っていた気がします。

会社がまだセットアップ中

そして会社はまだ原始時代です。それにも関わらず、変に会社とか組織論みたいなのを意識しすぎてしまったかと思っています。出来上がっていない組織の中での立ち回りを覚えなければいけませんでしたよ。

「私がCTOである」と何度言えていただろうか。そもそも、私は自由すぎることに耐えなければいけません。

おわりに

さて、採点です。

👍 目に見える成果物を定期的にリリース
超大物アーティストの皆さんにご参加いただいたリアルタイム配信・MUSERフェスが無事に成功 ◎。

🙂 説明できるバックエンド開発
Workaroundが多すぎましたが、技術選定は間違っていなかったでしょう〇。

😭 テクノロジーで対話を
そもそも誰と話そうとしていたのか、正直なところお遊びのスクラムチームみたいな目標設定でした △。

及第点とはいきませんでした...精進します。

なおCTO振り返りではありますが、この記事は私個人の意見です。お読みいただきましてありがとうございました。

◇

初出は note です。

32:Te99,

こんにちは。『リファクタリング』についてお話しします。リファクタリングそのものの定義より、『リファクタリング』が聞こえてきたときに感じとるべきことについてお話しします。

リファクタリングとは

『リファクタリング』とはプログラムの動作を変えずに中身を変えることです。こんがらがった配線を、タグ付けしたり色分けしたりして整理するイメージです。なお、必ずしも新しいものや高性能なものに置き換えることを指しません。

コードから怪しいにおいがする

整頓された環境で仕事をするのはとても楽しいことです。新しい要望に積極的に応えたくなります。同僚との信頼関係は深くなり、きっと多くの人と仲良くやっていけることでしょう。

一方で「こんがらがった」配線を触るのは危険な作業です。まちがって重要な配線を変更してしまうかもしれません。危険な作業にはとうぜん時間がかかります。

また、間違いを起こしたら責任を問われるかもしれません。心理的プレッシャーがさらに作業を遅くします。あなたが開発リーダーなら「もう触るな」と叫んで開発をストップさせるかもしれません。

そんな背景から、エンジニアはこの種の 「こんがらがり」を「怪しいにおい」として感じとり 『リファクタリング』が必要だと言うのです。

プロジェクトから怪しいにおいがする

ときに、プロジェクトを進めるなかで『リファクタリング』が聞こえてきたときには、ちょっと注意が必要です。２点あります。

１点目、これは簡単なことなのですが、リファクタリングは目に見える成果物を生み出しませんので、それを実施するタイミングについてよく考える必要があります。政治問題化します。

２点目、「怪しいにおい」の出どころについてです。それは本当に私たちのコードからなのでしょうか？どんな危険や痛みがあるのでしょうか、具体的にそれがなにかを調べなければなりません。

「自分の考えと違う」「他社にくらべてうちの技術は古い」「人間関係がつらい」「プロジェクトの趣旨に共感できない」とか、じつはそういう背景から『リファクタリング』が聞こえてきたのかもしれません。

そのようなことならば、プロジェクトの目的をもう一度話し合ったり、適材適所になるようメンバーの組み換えが必要だったりするでしょう。

おわりに

『リファクタリング』が必要、と聞こえてきたとき、それを技術的問題とのみとらえないほうが良いと私は考えています。プロジェクトや組織にもなにか整頓すべき問題があるのかもしれませんね。

本当に痛みを減らす『リファクタリング』ならやるべきで、関心事を他に向けて（技術的問題のみに夢中になって）痛みを麻痺させるだけの『リファクタリング』ならやらないほうが良いです。

最後までお読みいただきありがとうございました。

◇

初出は note です。

33:T13ea,

はじめに

『ウォーターフォール』は開発手法の一つです。ウォーターフォール型の開発、などのように総称としても使われます。

『ウォーターフォール』というと「川の流れ」のように響くかもしれませんが「水門のある運河」がより正しいイメージです。ウォーターフォールの肝心かなめはゲートの存在です。

「アジャイル」と比較されながら「ウォーターフォールはエンジニアを不幸にする」ようにしばしば言われていますので、その背景について私なりの考えをお話しします。

儀式的な分断

必要なことを調べる → 仕様を決める → 実装する → テストする → リリースする、ウォーターフォールではこのように工程が分けられます。そして各工程の間にゲートレビューがあります。

ゲートレビューでは作業が完全に終わったかをチェックします。ウォーターフォールは原則として逆流しませんから、仕事は完全な状態で次の工程に引き渡される必要があります。

ただ誰でも「おまえの仕事は完全か」と問われれば多少は不安になるでしょう。そこでゲートレビューは報告書なり仕様書に権威を与える荘厳な儀式になります。

権威の盾により当該工程の担当者としては「仕事が終わった」の安堵感を得られる一方、工程ごとに人々は心は分断されてしまいます。

重ならない関心、そして孤立

もうひとつ難しいことがあります。プロジェクトにかかわる人々の関心が重なる時間が短いのです。基本的に自分の工程にカーソルがあるときしか関心が高まりませんから。

プロジェクトの中途でなにかに気づいて手を挙げたとしても、自分の担当領域外のトピックであるとすると、その時間において関心を持って聞いてくれる人が周りにいないのです。

折角のアイデアが誰にも聞いてもらえないとしたら、それはとても寂しいことです。会社にとってもきっと損失でしょう。

そうして時間的距離にによっても人々の心は分断されてしまいます。

アジャイルという解決方法

アジャイルの特徴は「反復（イテレーション）」です。反復はまず仰々しい儀式を廃してときどき間違いながら徐々に進むことを許します。とうとう私たちは権威の盾を解除することができます。

そして短い間隔での反復により、プロジェクト関係者の関心の高く保たれるようになります。結果として、だれもが手を挙げやすくなり、プロジェクトがより良いアイデアを採用しやすくなりました。

アジャイルは万能のようです。ただこれらはアジャイルでしかできないことなのでしょうか？ウォーターフォールに構造上の欠陥があって、アジャイルがそれを修正したということなのでしょうか？

ウォーターフォールの問題じゃない

権威の盾の問題は、開発手法上のプロセスが政治化したことが問題なのであって手法の欠陥ではありません。利用の仕方の問題です。

関心が重ならない問題は、もとから関心の無い人が無理に関心を高めて無理にウェーイしていることが問題なのです。関係者全員がプロダクトについて当初からどれほどの関心を持っていたでしょうか？

つまるところウォーターフォールかアジャイルかというより、関係者の心構えの問題だと思えてきました。

おわりに

「ウォーターフォールでエンジニアが不幸になる」という話は、「部内部長がいる会社に入ると不幸になる」みたいな「あるある」話かな、と私は思いました。

弊社では、様々なタイプの関係者（社員・準委任の業務委託の方々、請負で仕事をされるベンダーの方々）がいることからも、全方向を探索しながらプロジェクトを進めており、いつも悩んでいます。

いつか「弊社のベストプラクティス」みたいな記事を書いてみたいです。

最後までお読みいただきありがとうございました。

◇

初出は note です。

34:T130e,

はじめに

『バグ』はすでにじゅうぶんに一般化している用語ですね。「不具合」のことです。「不具合という現象」を指して用いられることが多いと思いますが、それの「原因」を指しているときもあります。

取り扱い注意！

プログラミング業界では『バグ』はしばしば「攻撃的」に響きますのでご利用の際はご注意ください。 「バグを見つけたよ」＝「おまえの不完全な仕事の証拠を見つけたぞ」 と聞こえてしまうわけです。

バグ報告の仕方

ちょっと横道にそれますが、バグ指摘のコツを書きます。

① 発生している事実を伝える
② 報告に至った背景を伝える
③ 原因についての推測を伝えない

バグ報告のフォーマットを決める

①についてはチームでフォーマットを決めることをお勧めします。自身にとって自明なことを誰かに伝えるのはいつでも難しいです。

そもそも認識相違が無いかを確認

ある人には不具合である人には仕様通り、そういう認識相違のケースがあるので②のように背景を知らせることはとても重要です。

推測しない

③ですが、初報で推測を伝えると混乱が起きがちです。調査が始まり状況が分かってきたうえで、もしまだあなたの推測が助けになると思うなら伝えましょう。

特に②と③とがちゃんとしていないと、バグ報告はただの「揚げ足取り」になりがちです。

バグの実際

バグ＝虫なので、なにか有機的なもの、不思議な生命体が突然変異でコードの中に生まれてしまった？ そんな印象を受けるかもしません。しかしながら実際のバグはしばしば「うっかりミス」程度のものだったりします。

if (good) doOne(); doTwo();

例えば上のような単純な書き間違いです。「"good"だったらoneとtwoを実行」のように見えますが、実際の動作は「"good"だったらoneを実行。その後無条件にtwoを実行」になります。

仕様バグ

『仕様バグ』という用語もあります。これは、そもそも仕様に間違いや矛盾があったのだが、それがプログラムの動作テストの段階になってようやく発見された、そのような場合に使用されます。

『仕様バグ』は政治問題化しやすく扱いが難しいです。ウォーターフォール的な現場だと「バグを含む仕様がなぜ承認され下流工程へ渡されたのか」の責任追及が起こったりします。

「仕様策定にエンジニアが参加」と言うとき、それは情緒的な表現（全員野球のような）として言われることが多いですが、エンジニアには漏れなく抜け目なく考えるのが得意な人が多いので、これは実務的に有効な方法だと私は思います。

バグを防ぐ方法

チームにあった方法論を採用し磨き上げてゆくことが大事だと思います。方法論は各メンバーが「正しさの確信」にたどり着くための助けにならなくてはなりません。

たとえばプロダクトオーナーが一貫した考えを語ることは大事だと思います。考えがブレれば仕様バグを生むでしょう。

エンジニアはプログラミング言語を要求分析の方法としても使いこなすべきです。そして美しく仕上がったコードは仕様そのものです。醜いコードには誤解があり、きっとバグが潜んでいるでしょう。

おわりに

『バグ』の話より、バグをめぐるコミュニケーションとチームワークの話になりました。

『バグ』が攻撃的に響くのを回避するために『イシュー』という言葉を代わりに使用することもおすすめです。「なにかしらの理由で起きた不可解な出来事」のニュアンスなので誰かを責めたりしません。

ウォーターフォールについては別に書きたいと思います。ウォーターフォールの問題点は「政治問題」が起きやすい点です。古めかしい点ではありません。

最後までお読みいただきありがとうございました。

◇

初出は note です。

35:Ta7a,

はじめに

Webサイトを作っていて、ここは『静的』な部分・ここは『動的』な部分、のよう使われます。『静的』は "Static" の訳語・『動的』は "Dynamic" の訳語と思います。

『静的』は性的と同音なので、この用語にまるで馴染みのないグループで使う場合には『スタティック』を使ったほうが良いかもしれません。

静的・動的の使い方

『動的』を先に説明しましょう。『動的』な部分とは、ユーザーの操作やアプリケーション内部の計算など、諸条件の影響を受けて自動的に変更される部分です。

『静的』な部分はその逆で、それらの影響を受けることなくいつも同じ姿をしている部分です。

なぜその区別が意識されるか

制作コストが違うので区別が意識されます。『動的』な部分は『静的』な部分よりコストが高いです。

『動的』な部分の制作にあたっては、諸条件が正しく反映されるようプログラムが必要になりますしテストも必要になります。条件の組み合わせが複雑になるにつれコストはより高くなるでしょう。

もめごとになるケース

「ここちょっと直してよ」とエンジニアに依頼したら拒否されたので、口論になりました。

そのようなとき、おそらくその箇所は『動的』な部分だったのだと思います。「ちょっと＝簡単でしょ」がコストを度外視していると聞こえたのだと思います。

機能として作りましょう

先のもめごとについて解決策を提案しておきます。そのようなときは「機能」の制作を提案すると良いです。

「大得意先である〇〇商店さんのあの商品にちょっと星印をつけてくれる？」を「特定の商品にバッジ表示する機能を開発してくれる？」にしてみましょう。

おわりに

最後までお読みいただきありがとうございました。

コストについてはソフトウェア開発の視点からなので、クリエイティブの視点からはまた別の話があると思います。

エンジニア側からのみ書きましたが、もめごとの解決にはお互いをリスペクトすることがいつも大事ですね。

◇

初出は note です。

36:Td95,

はじめに

YAGNI はヤグニで You aren't gonna need it で『たぶんそれ要らなくね？』です。

必要なのか？不要なのか？

不要なことをするのは無駄、それは明らかなことです。ただ最初から物事に「不要」のラベルがついていることは稀でしょう。それなので、私たちはそれが必要なのか不要なのかの判断をしなければいけません。ときにはその結論をもって誰かを説得する必要があるかもしれません。

洞察なのか？憶測なのか？

いっけん不要に見えてじつは必要、そのようなこともあるでしょう。判断が必要な場面ではその 発端が「洞察なのか」「憶測なのか」 を見極めなければなりません。そのときに使える問いかけが『たぶんそれ要らなくね？』なのです。耐えられれば洞察、耐えられなければ憶測です。

最初が肝心

不要なものに手を出すと、そのときの時間を無駄にするだけではありません。未来に渡って無駄は無駄を生み出し続けるのです。ソフトウェア開発の現場における典型を紹介します。

共通レイヤー

共通レイヤーを作りました。モチベーションは以下の通りです。

いくつかのモジュールに共通点が見えたので共通化しよう
将来の機能拡張を先取りしておこう

もしそれらが憶測であったらどうでしょう。

同じに見えたが、各々のモジュールには差異があった
予想が外れた、そのような機能は結局必要とされなかった

憶測にもとづく共通レイヤーは無駄でした、しかしそれだけではすみません。これからずっとあらゆる新規開発の前に立ちはだかり、要件に対応するための改造が加えられ続けます。そしてアプリケーションの複雑度は増大を続け、最後には、もうだれも触れないコードができあがります。

それ要らなくね？

『たぶんそれ要らなくね？』と問いかけることがきっと大事です。私たちは自信過剰になるべきではありません。事前でも事後でも良いので問いかけましょう。さらには、その問いかけを通じて、良かれと思って何かを始めた当初の「善意」に立ち返りましょう。

おわりに

組織においても、『たぶんそれ要らなくね？』の問いかけができない組織は、無駄なポジションや無駄な人間を生んでしまう非人間的な組織です。勘や憶測らしきものが問いかけに封をしてしまっていないか点検が必要です。

最後までお読みいただきありがとうございました。

備考

不要なプロセスとか、儀式のような会議とか、会社の中にもいろいろあると思うのですが、多くのことの発端は「善意」だったと思うのです。先人の善意に立ち返りたいです。

◇

初出は note です。

37:T1645,

はじめに・フラグを立てる

『フラグを立てる』はもともとプログラミングで使われる用語です。ご存じのとおりです。「フラグの回収」は違って、これは「伏線の回収」とどこかで混じったものでしょう。

一般化した『フラグを立てる』がプログラミング業界に逆輸入され、いまでは「変数に真と評価できる値を代入する」という意味で使われることがありますが、古来の意味はビット演算のことです。

例外を投げる

さて、次に、これから流行る技術用語『例外を投げる』を紹介します。

『例外を投げる』の背景
『例外を投げる』の実際
『例外を投げる』の一般化

この順でお話ししていきたいと思います。

例外を投げる、の背景

ソフトウェアの開発においては、処理中に発生しうる状態を抜け目なく考えてゆくわけですが、規模が大きくなればより複雑になります。手に負えなくなって抜け漏れが出ます。

そこでソフトウェアの内部を小さな部品に分割することにします。それぞれに「小さくてわかりやすい責任」を負わせることにします。これで設計が明確になりそうです。

小さな部品たちは互いに、何かを頼んだり頼まれたりの依存関係を持ちますが、ここでちょっと問題があります。頼んだことをやってくれない部品にどう配慮すればよいでしょう？

ある部品が頼んだことをやってくれない場合、それを想定して他の部品を設計してゆくべきでしょうか。待ってください、それでは大きくて複雑で手に負えない設計に逆戻りです。

これの解決法が『例外を投げる』になります。例外に対応するから文字どおり「例外」で、部品どうしの依存関係とは「別ライン」で対応されるから「投げる」となります。

例外を投げる、の実際

ソフトウェアの内部を擬人化しました。緑が通常の頼みごとのライン、オレンジは例外による「別のライン」です。

倉庫係の責任は、倉庫の状況を調べて報告することです。しかし、倉庫の鍵が折れるという想定外の事象が発生したため責任を果たすことができませんでした。そこで例外を投げました。

庶務係は、そもそも倉庫係が「はい」か「いいえ」以外の返答をすることを想定していません。そうして庶務係の業務は小さくわかりやすく設計されているのです。

さて、投げられた例外は、どこへ飛んでゆくのでしょうか？

ベテラン受付係が例外をキャッチしました。ウェブサービスを利用していて「システムエラー」という画面をご覧になったことが一度はあると思いますが、あれがまさにベテラン受付係の仕事です。

例外を投げる、の一般化

なんでも私に報告しなさい、私がなんとかする
なにかあったら例外を投げなさい、あとは誰かが何とかする

唐突ですが、リーダーのセリフです、どちらのリーダーが好きですか？

前者のリーダーは頼りになりそうです。突破力がありそうです。ただ、心配なことに「コンプライアンス違反」をやらかしそうなんです。大事なことを握りつぶしそうなんです。

後者のリーダーは、大事なことを他人に丸投げする頼りにならない人物なのでしょうか。じつは、組織対応すべき問題を正しく心得ている正しい組織人なのかもしれません。

ソフトウェアの仕組み『例外を投げる』は、より安全な組織をつくるために活用できそうです。一本道のレポートラインですべて処理するのではなく「別のライン」を設けておくと良いことがありそうですね。

おわりに

そんなわけで、きっとこれから『例外を投げる』が流行ると信じています。ぜひ使いこなしてください。

最後までお読みいただきありがとうございました。

備考

多くのプログラミング言語で実際に『例外を投げる』と書きます。
例） throw new Exception("message");

同様に例外は「キャッチ」されますが、プログラミング言語Rubyでは「レスキュー」されます。どちらも素敵です。

例外を握りつぶすのはソフトウェアの実装において悪手とされています。プログラマー的にコンプライアンス違反です。

例外にはその要旨とともに、発生時刻や発生場所が記録されています。この情報が事後の調査を容易にします。

◇

初出は note です。

5:["$","html",null,{"lang":"ja","children":["$","body",null,{"className":"_72QFoa_className","children":[["$","$L1a",null,{"data":[{"name":"2026-11-08-support","content":"$1b","description":"カスタマーサポートと話そう / AI を活用することで、開発者は顧客により近いところで仕事をするようになるかもしれません。顧客と直接話し、その場で課題を理解して、解決策を形にする。FDE（Forward Deployed Engineer）という働き方にも、そうした方向性を感じます。…","prevId":null,"nextId":"2026-11-08-skills","title":"カスタマーサポートと話そう","date":"2026-11-08 21:00:04 +0900","categories":[]},{"name":"2026-11-08-skills","content":"

便利なスキルを探してインストールする。その使い方はもう終わりました。いまの関心は、AI エージェントの仕事の流れをどうデザインするかに移っています。

ただ、ここでハッとさせられるのは、人間の組織のほうはまだ「スキルをインストール」の段階ではないかということです。

組織の話になると、結局「優秀な人材を採用したい」しか出てきません。人を集めることと、その人たちが相互作用する仕組みを作ることが、同じ仕事のように扱われています。

異なる専門性や視点が相互作用し、単独では生み出せなかった価値をつくりる—人間の組織の本題はそこにあるのではないでしょうか。それになぜか、AI 活用の文脈で気づかされます。

楽器のシンセサイザーは、波形を組み合わせてピアノや弦楽器のような音を再現しました。同時に、それまで存在しなかった音を生み出し、新しい表現を創り出しました。

人材を集めることは、波形を重ねることです。チームの能力は、スキルの足し算とは次元の違う表現としてあらわれるのだと思います。

何が最適なのかは、これからの試行の中で見出すほかありません。ただ、一段上のレベルに上がったチームと、そうでないチーム。その差が、もう見え始めているように感じています。

あなたのチームから、新しい音が聞こえていますか？

まとめ

スキルをインストールするだけの AI の使い方は終わり
優秀な人材をインストールするだけの組織づくりも終わり
組織はシンセサイザーを目指す

最後までお読みいただきありがとうございました。

","description":"スキルをインストールする時代の終わり / 便利なスキルを探してインストールする。その使い方はもう終わりました。いまの関心は、AI エージェントの仕事の流れをどうデザインするかに移っています。…","prevId":"2026-11-08-support","nextId":"2026-11-08-organizations","title":"スキルをインストールする時代の終わり","date":"2026-11-08 21:00:05 +0900","categories":[]},{"name":"2026-11-08-organizations","content":"$1c","description":"開発組織は思うほど進化していない / 今年は幅広く複数のプロジェクトに参加することができました。そして、改めて気づいたことがあります。ソフトウェア開発組織は、思っていた以上に「多様」です。…","prevId":"2026-11-08-skills","nextId":"2026-11-08-goodwill","title":"開発組織は思うほど進化していない","date":"2026-11-08 21:00:03 +0900","categories":[]},{"name":"2026-11-08-goodwill","content":"

セキュリティ事故のニュースを見ると、気持ちが沈みます。チームの日々の努力が、強い見出しの向こうにかすんでしまうように感じるからです。

見えないところで続く仕事

強い見出しに注目が集まるとき、それまでの経過が見えにくくなります。努力の積み重ねや、現場が抱えていた困難がそうです。

いま、チームが同じ方角を向いているように見えるかもしれません。一方で、持続的に、善意を生かす仕組みを育てる必要があります。

足りなかった何かではなく、日々を支えていた何かにも目を向けたいと思います。

普段からチームメンバーを信じ、その声を尊重することが大切です。

結果として、一人ひとりの倫理観やプロフェッショナリズムが、チームの力になるでしょう。

なお、攻撃への恨み節ではありません。雰囲気に押しつぶされないようにしたいという話でした。

最後までお読みいただきありがとうございました。

","description":"かすまない善意 / セキュリティ事故のニュースを見ると、気持ちが沈みます。チームの日々の努力が、強い見出しの向こうにかすんでしまうように感じるからです。…","prevId":"2026-11-08-organizations","nextId":"2026-11-08-diligence","title":"かすまない善意","date":"2026-11-08 21:00:01 +0900","categories":[]},{"name":"2026-11-08-diligence","content":"

「会員登録をやめます」「個人情報は持ちません」—企業がそうした戦略を選ぶようになったことを、よい変化だと思います。守るための対策を増やす前に、そもそも守る対象を持たない。無用なリスクを取る必要はないのです。

私たちの開発現場はどうでしょうか。必要性が曖昧なままリスクを引き受け、そこに仕事を積み上げ、愚直にやり遂げたことを称賛していないでしょうか。

愚直さがリスクを育てる

戦略的にリスクを引き受けることはあり得ます。問題なのは、どんな価値を生むのか、何を引き受けるのかを十分に精査しないまま、「いつか横展開するときに」のように、漠然とした可能性が実装の前提になることです。

そして、その漠然とした前提をもとに、やたらと仕事を増やしてしまう。背景にあるのは、手間のかかる仕事を最後までやり遂げた、そういう愚直さを称賛するカルチャーです。

そんなカルチャーの下では、疑問を持つことや立ち止まることに批判が向けられます。そうして、早い段階でリスクを回避することに失敗し、そして次々とリスクを抱え込んでいくのです。

価値の薄い仕事を積み上げ、愚直にそれを消化する。やめればいいのにやめられない。

もしそんな状況なら、チームとして大事にしたいのは、疑問を歓迎すること。そして、立ち止まり、振り返ることへの評価です。

最後までお読みいただきありがとうございました。

","description":"愚直さを評価する罪 / 「会員登録をやめます」「個人情報は持ちません」—企業がそうした戦略を選ぶようになったことを、よい変化だと思います。守るための対策を増やす前に、そもそも守る対象を持たない。無用なリスクを取る必要はないのです。…","prevId":"2026-11-08-goodwill","nextId":"2026-08-16-time-investment","title":"愚直さを評価する罪","date":"2026-11-08 21:00:02 +0900","categories":[]},{"name":"2026-08-16-time-investment","content":"

AI エージェントを使った開発の敵は「惰性」です。

エージェントが動いていると、開発が進んでいるように見えます。その様子を眺めていると、止めるよりも動かし続けるほうがよいと感じてしまいます。その「惰性」が問題です。

自由時間はリターンとして

AI 活用で作業を自動化したぶん、人間の時間がそのまま余る。想像としては自然なのですが、これは少し乱暴です。

実際には、まず「別の時間」が必要になります。動かし方や検証の基準を決めるための事前準備の時間です。

さらに、その準備がうまく働くかを確かめるために、「トライ・アンド・エラー」の時間も必要になります。

一定の時間を投資すると、自由時間が「リターン」として得られる――ソフトウェア開発の現場の感覚と一致するのはこの考え方です。

雰囲気に負ける

それでも、「惰性」で仕事を進めてしまうことがあります。

おそらく、トライ・アンド・エラーのような「愚直」な部分は、速く・楽に・自動で、という世の中の AI 活用の「雰囲気」に合わないのです。

一方で、AI エージェントが動き続けている様子はその雰囲気に合います。だから、惰性でエージェントを動かし続けてしまうのです。

相変わらずのエンジニアリング

惰性や雰囲気に負けず、リターンを最大化するために、動かし方を決めること・確かめることに正しく時間を使っていく必要があります。

私たちは相変わらずエンジニアリングをしているようです。ソフトウェア開発の現場は意外に変わっていないのかもしれません。

最後までお読みいただきありがとうございました。

","description":"開発の敵は惰性 / AI エージェントを使った開発の敵は「惰性」です。…","prevId":"2026-11-08-diligence","nextId":"2026-08-16-opinions","title":"開発の敵は惰性","date":"2026-08-16 09:00:00 +0900","categories":[]},{"name":"2026-08-16-opinions","content":"

「自分の意見を言おう」「受け身になってはいけない」——この種のアドバイスが聞こえてくる組織は、裏を返せば、意見を言わなくても受け身であっても基本 OK な組織なのだと思います。

主体性は加点要素？

基本的に受け身でよい組織においては、主体性は加点要素であり、「自分の意見を言おう」「受け身になってはいけない」——これらは成長を促すアドバイスというより、性格矯正に近いものになります。

つまり、それらは個人のスキルアップを促しているのではなく、組織内でのふるまいでどう点数を稼ぐかという処世術を教えているのです。

もし、その点数だけで評価や出世が決まるなら、まるで「性格診断の結果で組織図ができあがっている」ような状態ですね。

意見に応答する仕組み

文字通りの意味で「自分の」意見を言ってもらいたいなら、「意見に応答する」仕組みが聴く側に実装済みかどうか、前もってその点検が必要です。

ガス抜きの時間を設ける、そのような「聴取」だけの仕組みは見透かされます。そこでは、本当に必要な意見が沈黙の中に消えていきます。

また、傾聴という名の「吸収」も違います。リーダーは 1 on 1 で、組織側の人間として意見をただ吸い込むだけの緩衝材にならないようにします。

意見を受け取り、対話を経て、その意見を評価するための共通の土台を、言う側・聴く側の双方に築くことが大切です。

チームとして成果を残せたとき、チームワークをたたえると同時に、意見を表した個人の貢献もたたえるようにします。

そのような応答ができてこそ、組織が個人に「自分の」意見を求めることができるようになります。主体性を求める前に、組織には、応答する責任を引き受ける必要があるのです。

","description":"意見に応答する / 「自分の意見を言おう」「受け身になってはいけない」——この種のアドバイスが聞こえてくる組織は、裏を返せば、意見を言わなくても受け身であっても基本 OK な組織なのだと思います。…","prevId":"2026-08-16-time-investment","nextId":"2026-07-28-world-line","title":"意見に応答する","date":"2026-08-16 06:00:00 +0900","categories":[]},{"name":"2026-07-28-world-line","content":"

会社はそういう世界線だから―そうして距離を置いてしまうのは、もったいないことだと感じます。

たてつけが変更不可になる

例えば、「お客様は神様です」という「たてつけ」から始まったサービス改善活動が、いつしか疑ってはいけない与件となり、カスハラの根拠となってしまうような場合を考えてください。

ときに、組織では前提が行方不明になります。漠然として見えなくなり、届かなくなり、やがて不可侵となる―これは組織の中で「思考停止の追認」が積み重ねられる結果です。

その「たてつけ」は、目的にあわせて作られただけのものなのですが。

世界線の誕生

影のボスのように不可侵、そのような前提に支配されて、会社は「そういう世界線」というパラレルワールドになります。

経営層がパーパスの声を大きくすると、現場に冷ややかな雰囲気が広がる、そんな光景もまた会社のフィクション化を象徴しています。

ただ、それは楽しい物語ではありませんね。会社は現実で、その結末を受け止めるのも現実の人間なのですから。

世界観を接続する

個人の「世界観」が、組織に欠けてしまっているのだと思います。「世界線」ではなくて「世界観」です。

実際のところ、辞めていく人はたいてい会社との断絶を言います。つまり、結局は会社を別世界としてあきらめたりはしないのです。

個人も、会社も、社会を動かしたいと思っている。現場のリーダーは、個人の「世界観」が会社に接する最もリアルな場所で、手助けをする必要があるのだと思っています。

","description":"会社という世界線 / 会社はそういう世界線だから―そうして距離を置いてしまうのは、もったいないことだと感じます。…","prevId":"2026-08-16-opinions","nextId":"2026-06-28-vpoe","title":"会社という世界線","date":"2026-07-28 09:00:00 +0900","categories":[]},{"name":"2026-06-28-vpoe","content":"$1d","description":"VPoE 不要論 / VPoE はまだ必要でしょうか。エンジニアだけは特別に難しい人たちだから、専用のマネジメント構造が必要だ、という前提がまだあるでしょうか。…","prevId":"2026-07-28-world-line","nextId":"2026-06-24-adventurism","title":"VPoE 不要論","date":"2026-06-28 09:00:00 +0900","categories":[]},{"name":"2026-06-24-adventurism","content":"$1e","description":"リゾート冒険主義 / スタートアップは挑戦者を求めています。つねに新しい可能性を試す、そういったエンジニアの「挑戦的」な姿勢は歓迎されるでしょう。しかし、「挑戦しているように見えること」と「本当の挑戦」は違います。…","prevId":"2026-06-28-vpoe","nextId":"2026-06-01-disruption","title":"リゾート冒険主義","date":"2026-06-24 09:00:00 +0900","categories":[]},{"name":"2026-06-01-disruption","content":"

私は以前、仕事とそれ以外の境界線が曖昧であることを、むしろ誇らしく思っていたところがあり、私にとって「邪魔」なものなど何もありませんでした。仕事と遊びとか、集中とリラックスとかそういう線引き、あるいはポモドーロのような生産性向上メソッドが、すべて野暮ったく見えていました。

さいきん「邪魔」を感じる

ところが、さいきん「邪魔」を感じます。いわゆるディスラプションです。環境が大きく変わったわけでもないですし、新しい趣味を見つけたわけでもありません。加齢による集中力の低下——それは確かにあるかもしれませんが、それほどではないつもりです。

そして、野暮ったいと思っていたメソッドに感心したりしているわけです。ついには、この私がセルフマネジメントの必要性を説明していたり。

守るべきものの変化

明らかに、かつての私は、独りよがりを熱意とかプロフェッショナリズムと美化していたでしょう。仕事のモジュール化がよくできていたのかもしれません。いいえ、実際のところ「自分が頑張ればなんとかなる仕事」を好んで引き受けていただけなのでしょう。

自分以外が邪魔されるようになった。これはたしかに思い当たることで、ディスラプションを感じる時に、チームのワークフローへの悪影響を最初に考えているかもしれません。集中力不足の結果も、手戻りとして私よりチームに返ってくるようになりました。

臆病になるという別の問題

立場が変わったので、考え方も変わりました。でも、それもまた野暮ったいなと思うのです。今度は妥協をプロフェッショナリズムとして美化し始めたのではないだろうか。ノイズを含めて自分が自分だったころのほうがカッコよかったし、人に優しかったような気がします。

臆病になって、邪魔が怖くなっているだけなのかもしれませんね。ディスラプション上等、で仕事していきたいと思います。もちろん最高の生産性を目指しながら。

とりとめのない話でしたが、最後までお読みいただきありがとうございました。

","description":"ディスラプションと私 / 私は以前、仕事とそれ以外の境界線が曖昧であることを、むしろ誇らしく思っていたところがあり、私にとって「邪魔」なものなど何もありませんでした。仕事と遊びとか、集中とリラックスとかそういう線引き、あるいはポモドーロのような生産性向上メソッドが、すべて野暮ったく見えていました。…","prevId":"2026-06-24-adventurism","nextId":"2026-05-18-unverified-as-dream","title":"ディスラプションと私","date":"2026-06-03 08:10:00 +0900","categories":[]},{"name":"2026-05-18-unverified-as-dream","content":"$1f","description":"「未検証」を「夢」と言い換える / 新しいことを始めるとき、プロジェクトの初期フェーズは「未検証」そのものです。だからこそ私たちは動き始めるのですが、組織の中では、「未検証」だからといきなり批判の対象になったりします。ただの言いがかりのようでいて、私はそこに構造的な問題があると思っています。…","prevId":"2026-06-01-disruption","nextId":"2026-05-11-ai-suspension","title":"「未検証」を「夢」と言い換える","date":"2026-05-18 19:47:00 +0900","categories":[]},{"name":"2026-05-11-ai-suspension","content":"$20","description":"「それ AI で」で会議を終わらせない / プロダクトづくりに AI を利用できるようになってから、「プロダクトをどう良くするか」という議論が、以前よりも早く打ち切られるようになったと感じます。Why を問わずに How に飛びついてしまう傾向は前々からありましたが、最近はそれが目立って悪化しています。…","prevId":"2026-05-18-unverified-as-dream","nextId":"2026-04-30-run-through","title":"「それ AI で」で会議を終わらせない","date":"2026-05-11 09:50:00 +0900","categories":[]},{"name":"2026-04-30-run-through","content":"

昨日、ETCカードの期限切れに気づかず料金所を突破してしまいました。本日、首都高速のお客様センターに問い合わせ、丁寧に対応していただきました。車両の情報や、新旧のETCカードの情報をお伝えしたら、新しいカードに請求されるとのことでした。

コネクティッドの価値

今年の1月で期限切れを迎えていたので、もっと早くにアラートが出てしかるべき、と思いましたが、考えてみるとETC車載機は現在日時を知らないのですね。こうした日常の小さな不便の解消が感じられれば、コネクティッドカーの価値が認識されると思いました。

おわりに

アラートは出ないものの、期限を毎回唱えてくれていたので、機械の話もしっかり聞くべきと反省
1月から旅行に行ってなかったのか、という、忙しさについての振り返り
子供の春休みに出かけられなかったなという哀しみ

新しいETCカードを挿入して、今年度を安全に駆け抜けていきたいと思います。

","description":"機械の話もしっかり聞こう / 昨日、ETCカードの期限切れに気づかず料金所を突破してしまいました。本日、首都高速のお客様センターに問い合わせ、丁寧に対応していただきました。車両の情報や、新旧のETCカードの情報をお伝えしたら、新しいカードに請求されるとのことでした。…","prevId":"2026-05-11-ai-suspension","nextId":"2026-04-27-real-spec","title":"機械の話もしっかり聞こう","date":"2026-04-30 21:00:00 +0900","categories":[]},{"name":"2026-04-27-real-spec","content":"$21","description":"後付け仕様書のような / 確かに時系列としては、先に指示を出しています。そして AI を動かしています。しかしながら――その指示は、成果物にどれだけの影響を与えたのでしょうか。AI 活用まわりの話を聞いていると、それが後付けの仕様書のように感じられる時があります。…","prevId":"2026-04-30-run-through","nextId":"2026-04-23-ls","title":"後付け仕様書のような","date":"2026-04-27 05:00:00 +0900","categories":[]},{"name":"2026-04-23-ls","content":"

平穏でいるためには、ある意味でひたすら自分勝手である必要があるのだと思います。

多くのコンフリクトは、相手との対立そのものよりも、まず自分の内側で起きている葛藤から始まっているように見えます。内面で始まった争いの出演者を、外の世界に探しにいってしまうのです。

自分の中の争い

自分の内側の争いは、もっと単純に扱ってよいのかもしれません。好きなら好き、嫌なら嫌で、いったん受け止める。整った理由を与えなくてもよいのだと思います。子どもだったころの感覚を思い出してみればよいのかもしれません。

チームの中の争い

チームの中の争いも、表面上は意見の衝突に見えて、実はとても不鮮明な問題であることが少なくないように思います。本当に意見の対立なら、それはとても健全です。

一度片づけてもまたぶり返す論点は、そもそもそう扱うべきものではなかったのでしょう。チームの問題でも、いったん好き嫌いの感覚に立ち返ってみてもよいのかもしれません。

組織の平穏のため

表層に現れてこない内面の問題を探るために、個人としてもチームとしても感情を手掛かりにしてみるのは一つの方法だと思います。4Lsという振り返りのフレームワークが役に立つかもしれません。

自分勝手になってみる。そうするとコンフリクトが解消し、合意形成がしやすくなる。逆説的ですが、そうして良い結果が得られると思います。

","description":"自分勝手である必要 / 平穏でいるためには、ある意味でひたすら自分勝手である必要があるのだと思います。…","prevId":"2026-04-27-real-spec","nextId":"2026-04-16-cool-stuff","title":"自分勝手である必要","date":"2026-04-23 18:22:00 +0900","categories":["short"]},{"name":"2026-04-16-cool-stuff","content":"

自分にとっての「ごほうび」は何だったでしょう——

ごほうびを思い出す

自分にとっての「ごほうび」は何だったでしょう。新しい技術を使いこなせたうれしさとか、誰かの困りごとを解決できた実感とか、普通に褒められたこととか。

また、六本木でおいしいお肉をご馳走になったこととか。そういうことも含めて、何が嬉しかったのかを一つひとつ思い出したいと思います。

かっこ良さに戻る

というのも、欲しいものがないのにそれをよこせと主張だけしている、自分の態度がそのように見えることがあったからです。

こだわりすぎのアーキテクチャより、昼休みのチョコジャンボモナカだったかもしれない。

ごほうびください！そういう、かっこ悪さの反対側にかっこ良さがあって、プライドもまたいつも反対側にあったように感じます。

原点に返る

自分の前にしっかりと、心躍るようなごほうびを並べてみたいと思います。習慣とかイデオロギーには流されないで。そうして、エンジニアとしての原点に返りたいと思います。

","description":"心躍るごほうびを求めて / 自分にとっての「ごほうび」は何だったでしょう——…","prevId":"2026-04-23-ls","nextId":"2026-04-05-natural-language","title":"心躍るごほうびを求めて","date":"2026-04-16 09:00:00 +0900","categories":["note"]},{"name":"2026-04-05-natural-language","content":"

自然言語がソフトウェア開発現場をスパムしています。たとえばライフハックの押し付けのようなプロンプト——AIエージェントを利用するようになってから増えたこうした自然言語による指令が、実は開発者の心を暗くしている、そのように感じています。

看板だらけの街

「駐輪禁止」「ポイ捨て禁止」「カメラ監視中！」——仰々しい書体で作られたそういう看板を街角で見ると、私は不穏な気持ちになります。むしろ傲慢さと無秩序を感じるからです。

いま、ソフトウェアのコードベースについて、同じことを感じています。AIエージェントに向けてのその種の文言が続々とコミットされてくるからです。中には、それはあなた用のライフハックでは？と思えるようなものまで。

量に説得されようとしている

これまで私たちは、分厚い仕様書とか無限スクロールの質疑応答書とか、その類の「量で圧倒してくる」ものに振り回されてきました。

ですがいまは、AIを活用して、開発者はその苦い経験の「逆側の当事者」になろうとしているわけです。つまり、逆側にあった「量で圧倒しよう」のモチベーションに突き動かされているのです。

美しい街

看板ばかりが目につく街でアイデアが降りてくるでしょうか。人々がそこに集うでしょうか。美しさの定義は人それぞれだとしても、少なくとも、無粋な看板がそれでないことは確かです。

構造を整えること、それが第一であると私は考えています。なぜなら、ソフトウェアはビジネスをスケールさせるための「場」であり、人々が集う美しい街であるべきだからです。

やはり、構造が大事です。私は美しい街を作りたい。

おわりに

ソフトウェア開発手法の激しい変化の中、このような考えは感傷に過ぎないかもしれません。しかしながら、単なるノスタルジアとも言い切れない、そんな面もあるように思っています。

自然言語スパムがコードベースを圧倒している
無粋な看板だらけの街のようだ
ビジネスがスケールする「場」としてどうか？
そうではない、美しい街を作りたい

","description":"自然言語スパム / 自然言語がソフトウェア開発現場をスパムしています。たとえばライフハックの押し付けのようなプロンプト——AIエージェントを利用するようになってから増えたこうした自然言語による指令が、実は開発者の心を暗くしている、そのように感じています。…","prevId":"2026-04-16-cool-stuff","nextId":"2026-03-30-timebox","title":"自然言語スパム","date":"2026-04-05 10:00:00 +0900","categories":["note"]},{"name":"2026-03-30-timebox","content":"

時間を無駄にしたという感覚

「時間を無駄にした」という感覚は、単純に「見積りより長くかかった」とか、「期待した成果が出なかった」といった話ではないように思います。むしろ、使った時間と得られた成果の釣り合いに「あとになって」納得できず、事後的に自分へクレームを入れている感じです。

使える時間の制約が無い
成果物のイメージも無い

そうして手探りで進んだ「ラッキー探索」の結果です。

時間枠（タイムボックス）は必要

成果物のイメージはどこまででも膨らみます。ですから、時間の制約のほうを先に扱うのが良いでしょう。ポモドーロテクニックやスクラムのスプリントのように、「まず時間枠を決める」という方式です。

それによって、漠然とした理想像ではなく、制約の内で十分な、そして具体的なイメージを描けるようになります。

クリエイティブな作業

その種のアプローチが当てはまりにくい性質の仕事もあります。探索や試行錯誤、寄り道も必要な種類の仕事です。

ただし、ここには落とし穴があります。あなたが対峙している仕事は、本当にそのような性質のものなのでしょうか？まだ決めたくないことを先送りするために、「創造性」を持ち出していないでしょうか。

そうしてしばしば逃げてしまうのは私です。大変お恥ずかしい限りです。

プロフェッショナルとして

「ラッキー探索」は、健全な仕事の仕方ではありません。クリエイティブな仕事と混同してもいけません。必要なのは、評価基準を「自主的に」設けて、途中で振り返りをしながら進むことです。

その基準に照らして「時間を無駄にした」と判断する場合なら、それは同時に学びでもあったと思うので、クレーマー的なものとは別のものでしょう。

まとめ

ラッキー探索は効率が良くありません。
時間を無駄にしたと言うのは大体クレーマーです。
時間枠をうまく使うことが大事です。

","description":"時間を無駄にしたという感覚は、事後的に自分にクレームを入れている状態——手探りで進んだ「ラッキー探索」の結果です。 / 「時間を無駄にした」という感覚は、単純に「見積りより長くかかった」とか、「期待した成果が出なかった」といった話ではないように思います。むしろ、使った時間と得られた成果の釣り合いに「あとになって」納得できず、事後的に自分へクレームを入れている感じです。…","prevId":"2026-04-05-natural-language","nextId":"2026-03-26-magic","title":"時間を無駄にしたという感覚","date":"2026-03-30 13:28:00 +0900","categories":["note"],"headline":"時間を無駄にしたという感覚は、事後的に自分にクレームを入れている状態——手探りで進んだ「ラッキー探索」の結果です。"},{"name":"2026-03-26-magic","content":"

やっと買ってもらえた手品の道具、そのローテクさに落胆してしまった——そんな記憶があります。小学校３年生くらいのときだったでしょうか。

種明かし

当時の私は、手品の道具に「憧れ」を抱いていました。なぜなら、そこには精巧な、高度な、ハイテクな仕組みが隠されているものだと信じていたからです。

しかし、買ってもらえた道具は驚くほど素朴でした。仕組みというよりは「扱い方」がすべてでした。「虫ほどの大きさのロボット」でも仕込まれていると期待していたわけですから、すっかり落胆してしまいました。

本当の種明かし

それで、その扱い方をよく練習したのかというと、しなかったと思います。なぜ手品がエンターテインメントとして支持されているのか、それを普通に考えられていなかったわけです。

そこでやめずに続けていれば（元来手先が不器用なので、初級すら到達できるか怪しいですが…）、その先にある心理戦のような高度な技術に気づけたと思うのですが。

突き詰めることで見えるもの

入り口で何かを「大したことがない」と判断してしまう、これは私の悪い癖です。表面的には単純に見える仕組みでも、一定の深さまで関わってみないと、難しさも面白さも見えてきません。

そんなことを手品の道具の記憶から思い出しました。

","description":"手品の技術 / やっと買ってもらえた手品の道具、そのローテクさに落胆してしまった——そんな記憶があります。小学校３年生くらいのときだったでしょうか。…","prevId":"2026-03-30-timebox","nextId":"2026-03-23-recording","title":"手品の技術","date":"2026-03-26 13:15:00 +0900","categories":["short"]},{"name":"2026-03-23-recording","content":"

AI議事録の普及により、なし崩し的に「すべての会議を録画する」になっていませんか？録画が生産的かどうか以前に、摩擦を生みかねないこの行為が、なぜ、自然に受け入れられたのかを考えてみました。

聴取と通達

理由は単純で、ほとんどの会議が「聴取」か「通達」を目的としていて、録画に分かりやすい合理性があるからです。

「聴取」のための会議では、録画を記録として残したくなるのは自然です。たとえば、ユーザーインタビューは後から見返したい。あるいは、少々いやらしい例ですが、言質を取るための聴取ならしっかり証拠を残したい。

「通達」のための会議にいたっては、もはや先に録画しておきたいものです。そして、それを配信すれば事足りる。会議の形式が選ばれるのは、役職者が「登壇」するための舞台が必要…ただそういうことかもしれません。

そうじゃない会議

一方で、それらに当てはまらない会議については、録画の要否を、場の性質を踏まえて複数の観点から慎重に考えたほうがよいと思います。

たとえば、1-on-1を録画するのは基本的にナシだと感じます。しかし、組織全体に「録画するのが普通」という空気が広がると、違和感を覚えたときに、そこで手を挙げにくくなるかもしれません。

会議を録画する行為は自然に受け入れられている
実際のところ、多くの会議は録画に適している（良し悪しは別として）
しかし、とりあえず全部録画、が慣習化すると危険

","description":"会議はとりあえず録画？ / AI議事録の普及により、なし崩し的に「すべての会議を録画する」になっていませんか？録画が生産的かどうか以前に、摩擦を生みかねないこの行為が、なぜ、自然に受け入れられたのかを考えてみました。…","prevId":"2026-03-26-magic","nextId":"2026-03-19-than-output","title":"会議はとりあえず録画？","date":"2026-03-23 09:00:00 +0900","categories":["short"]},{"name":"2026-03-19-than-output","content":"

AI活用において、数字で測れる量ばかりに目が行きがちですが、押し売りの指標に振り回されることなく、楽しいことをやりましょう。

できたらうれしい

私たちは出力の「量」ばかりに気を取られてはいないでしょうか。エンジニアであれば、AIエージェントに任せておくだけで、数十倍のスピードでコードが書けるとか。比較の基準はかつての自分の仕事量、ですが、そもそも量をこなす仕事を喜んでいたのでしたっけ？

「やったぜ」と、純粋な喜びを叫ぶ瞬間を忘れたくないと思っています。

やりたいことをやろう

あなた自身やあなたのチームの楽しみは、おそらく量に比例するものではありませんでした。仕様書を書くにしてもコードを書くにしても、それらは感性を働かせるための手段だったはず。かつて大事だと思ったことがないような押し売りの指標に振り回されることなく、やりたいことをやる、それが、この時代のこのタイミングで一番大切だと考えています。

","description":"押し売りの指標に振り回されることなく、やりたいことをやる。 / AI活用において、数字で測れる量ばかりに目が行きがちですが、押し売りの指標に振り回されることなく、楽しいことをやりましょう。…","prevId":"2026-03-23-recording","nextId":"2026-03-16-career-characteristics","title":"出力量より楽しいことを","date":"2026-03-19 07:00:00 +0900","categories":["short"],"headline":"押し売りの指標に振り回されることなく、やりたいことをやる。"},{"name":"2026-03-16-career-characteristics","content":"$22","description":"性格とポジションの相性より、立ち回りスキルを優先してしまう問題。 / ソフトウェアエンジニアの「人の性格」と「ポジション」との相性について、あまり話題になりませんでした。「Builder vs Maintainer」のように英語で検索すると、性格分析とポジションとをマッピングしてみる考察がそこそこ見つかるのですが、日本語だとあまり見つかりません。…","prevId":"2026-03-19-than-output","nextId":"2026-03-12-skillmap","title":"性格とポジション","date":"2026-03-16 04:20:00 +0900","categories":["note"],"headline":"性格とポジションの相性より、立ち回りスキルを優先してしまう問題。"},{"name":"2026-03-12-skillmap","content":"$23","description":"スキルマップはエンジニアの番付ではなく、チームのボトルネックを見つけるための道具です。 / スキルマップ（星取表）が、なぜか「チームの雰囲気を悪くするツール」になってしまった。そんな経験はないでしょうか。今回は、スキルマップのあるべき姿を、ソフトウェア開発の現場目線で考えてみます。…","prevId":"2026-03-16-career-characteristics","nextId":"2026-03-09-ai-and-org","title":"スキルマップを番付にしない","date":"2026-03-12 15:43:00 +0900","categories":["note"],"headline":"スキルマップはエンジニアの番付ではなく、チームのボトルネックを見つけるための道具です。"},{"name":"2026-03-09-ai-and-org","content":"

そもそも、人の力を引き出せていない組織がAIを導入しても、その効果は限定的ではないでしょうか。AIで人を代替できるかという議論の前に、採用や育成、組織構造、プロセス整備といった組織づくりに向き合う必要があります。AIの話がそれを先送りする口実になってしまっては本末転倒です。

人間組織のメタファー

これまで人間に何を期待し、人間組織の理想像をどう描いていたか―その過程で手に入れた人間組織のメタファーが、AI活用を設計するために必要だと考えています。未来に向けても、人間への期待をやめない組織だけが、AIとともに働き、発展できるのだと思っています。

","description":"人間への期待をやめない組織こそAI活用に成功する。 / そもそも、人の力を引き出せていない組織がAIを導入しても、その効果は限定的ではないでしょうか。AIで人を代替できるかという議論の前に、採用や育成、組織構造、プロセス整備といった組織づくりに向き合う必要があります。AIの話がそれを先送りする口実になってしまっては本末転倒です。…","prevId":"2026-03-12-skillmap","nextId":"2026-03-05-persona","title":"人間組織のメタファー","date":"2026-03-09 11:50:00 +0900","categories":["note"],"headline":"人間への期待をやめない組織こそAI活用に成功する。"},{"name":"2026-03-05-persona","content":"$24","description":"ペルソナがプロダクトのポテンシャルを奪う危険について考察しました。 / プロダクト開発では、「プロダクトを待ち望んでいる誰か」、つまりペルソナを描くことは一般的な手法です。ペルソナはプロダクトへの共感を容易にし、要件の理解を助けるためにとても有効な手法だからです。…","prevId":"2026-03-09-ai-and-org","nextId":"2026-03-03-teamwork","title":"楽に共感できたら立ち止まろう","date":"2026-03-05 10:20:00 +0900","categories":["note"],"headline":"ペルソナがプロダクトのポテンシャルを奪う危険について考察しました。"},{"name":"2026-03-03-teamwork","content":"

だいたい何とかなるという楽観主義で、思い込みに基づく完璧主義をやっつけていく、直近はそんなチーム運営です。もちろん、慎重さは第一原則だと心得ています。

何かが足りないと気づく瞬間

チームで仕事をしていて一番うれしい瞬間は、私たちには「何かが足りない」と気づけたときです。それは、準備不足の発見やバグのことではありません。一緒に仕事をして学習が進んだ結果、見える景色が変わったというサインです。個別の課題に深く潜り、プロダクトやコードベース特有の事情を理解するうちに、チームを状況に適応させる必要性に気づいた、そういうことでもあります。

最初からそうはならない

「最初からそうしておくべきだった」というのは、レトロスペクティブにおいてよくある残念なコメントです。外野の人が表層的な理解でそのような発言をするならなおさらです。ただ、共に時間を過ごしたチームメンバーからの、「最初から見えていたならな」という仮定法の発言なら、それは次のプロジェクトがもっとうまくいくという兆候でしょう。

","description":"「何かが足りない」と気づいた瞬間には新しい景色が見えている。 / だいたい何とかなるという楽観主義で、思い込みに基づく完璧主義をやっつけていく、直近はそんなチーム運営です。もちろん、慎重さは第一原則だと心得ています。…","prevId":"2026-03-05-persona","nextId":"2026-02-27-characters","title":"新しい景色が見えている","date":"2026-03-03 15:32:00 +0900","categories":["note"],"headline":"「何かが足りない」と気づいた瞬間には新しい景色が見えている。"},{"name":"2026-02-27-characters","content":"

AI時代に「擬人化」がシステム設計技法として活きる―そして擬人化力にたけた日本の会社が設計力を倍増させるかもしれません？

AI時代に試される「擬人化力」

AIエージェントを組織やワークフローにどう組み込むかという課題について議論するとき、AIを一人の社員に例えて考えてみる、このような取り組みはすでに行われていると思います。

さらに一歩踏み込んで、AIエージェントをキャラ化していくとどうでしょうか。

「レイテンシが上昇中」
「なんかいつもと違う、もっさり！」
「問い合わせきてまーす」
「優先順位を整理せよ」

セリフを並べるだけでマルチエージェントを活用した監視システムの設計が完了しました。ストーリーやキャラというメタファーが、システム設計の土台となる時代が来たようです。

※この記事は、ちょっとした遊び心によるものです。

","description":"キャラの会話から役割、責任境界、協調のイメージをつかむ。 / AI時代に「擬人化」がシステム設計技法として活きる―そして擬人化力にたけた日本の会社が設計力を倍増させるかもしれません？…","prevId":"2026-03-03-teamwork","nextId":"2026-02-26-why-why","title":"AI時代に試される「擬人化力」","date":"2026-02-27 15:00:00 +0900","categories":["short"],"headline":"キャラの会話から役割、責任境界、協調のイメージをつかむ。"},{"name":"2026-02-26-why-why","content":"

なぜ「なぜ」で開発が止まるのでしょうか？この「なぜ」は、要件についての質問や仕様確認ではありません。この種の「なぜ」は、整合性の問題であることを知る必要があります。

コミュニケーションの問題ではない

「テックリードが忙しすぎる」とか「質問しにくい雰囲気がある」とか、そのようなコミュニケーションの問題で、知りたいことをすぐに知れない状況は起こりえます。確かに、そのようなコミュニケーションの問題が出力を低下させることはあります。しかしながら、開発を立ち止まらせる「なぜ」は、多くの場合で別種の「なぜ」です。

内面との不整合

この「なぜ」は、暗黙知に基づく期待との不整合です。趣味の問題と誤解されるかもしれませんが、あえて「違和感」とも言い換えることができそうです。ですから、生産性ツールを導入して、コミュニケーションの効率を改善したとしても、この「なぜ」が解消することはないのです。

なぜ「なぜ」を問うのか

エンジニアは、「違和感の強さ」と「コードの将来」を掛け算して「暗黙のリスク計算」を行っています。よって、計算結果として大きな数字が表れてくれば、速度を落とすか立ち止まることになります。つまり、「なぜ」を問うのはリスクの表明なのです。端的に答えが求められているのではありません。

おわりに

エンジニアが将来を掛け算していても、組織の期待が非常に短期的で、噛み合わない場面に出会うこともありました。チーム全体がプロダクトの将来を語り合える組織が最高だと思います。そういう意味のコミュニケーションの改善は、非常に大切だと考えています。

","description":"開発を止める「なぜ」は仕様確認ではありません。 / なぜ「なぜ」で開発が止まるのでしょうか？この「なぜ」は、要件についての質問や仕様確認ではありません。この種の「なぜ」は、整合性の問題であることを知る必要があります。…","prevId":"2026-02-27-characters","nextId":"2026-02-24-salary","title":"なぜ「なぜ」で開発が止まるのか","date":"2026-02-26 18:14:00 +0900","categories":["note"],"headline":"開発を止める「なぜ」は仕様確認ではありません。"},{"name":"2026-02-24-salary","content":"$25","description":"転職で給料アップは「定石」だが、2026年には特殊事情がありそうです。 / エンジニアの転職において「給料を下げてはいけない」というのは定石です。私自身も概ね同意なのですが、2026年には年収の大小以上に考慮すべき「特殊事情」が多すぎます。事業会社で働くエンジニアをペルソナとして、この特殊なタイミングにおけるキャリアの選択について考えてみました。…","prevId":"2026-02-26-why-why","nextId":"2026-02-19-understaffed","title":"給料を下げてでも転職すべきか・2026","date":"2026-02-24 09:00:00 +0900","categories":["note"],"headline":"転職で給料アップは「定石」だが、2026年には特殊事情がありそうです。"},{"name":"2026-02-19-understaffed","content":"$26","description":"ご存じの通り、それが真の問題ではありません。 / 人さえ増やせば問題が解決する、そんなプロジェクトの「黄金時代」を迎えたことがありますか？「メンバーが足りない」「採用が追いつかないから開発が進まない」そのような声を聞くと、本当に人数不足が問題なのか、そもそも人数の問題にするのが適切なのか、という疑問が浮かびます。…","prevId":"2026-02-24-salary","nextId":"2026-02-16-project-management","title":"「人が足りない」という話","date":"2026-02-19 09:00:00 +0900","categories":["note"],"headline":"ご存じの通り、それが真の問題ではありません。"},{"name":"2026-02-16-project-management","content":"$27","description":"事業会社において、プロジェクトをどう「やりくり」するかという、現場観点の考えを言語化してみました。 / **2026年初頭に感じていること：**…","prevId":"2026-02-19-understaffed","nextId":"2026-02-13-work-with-ai","title":"事業会社におけるプロジェクトやりくり","date":"2026-02-16 10:30:00 +0900","categories":["note"],"headline":"事業会社において、プロジェクトをどう「やりくり」するかという、現場観点の考えを言語化してみました。"},{"name":"2026-02-13-work-with-ai","content":"

AIが決めたという逃げ道

スクラムイベントとして「瞑想」を設けてはどうかという私の提案に、プロジェクトマネージャーが賛同してくれました。半ば冗談だったのですが、AIにより仕事の進め方が急激に変化するなか、私たちが「AIが決めた」という逃げ道をどう塞ごうか迷っている、その共通の悩みを確認できたように思いました。

AI時代の「社員稼業」

その悩みは言い換えると、AIエージェントを束ねる事業主はどうあるべきか、という問いです。そこで私は松下幸之助の「社員稼業」を思い出します。AI時代においては、社員稼業が極めて「現実的な」スタイルに思われますし、さらにはプロフェッショナルとしての「スタンダード」とさえ感じられました。

経営資源の管理

社員稼業を営む経営者としての難しさは、自分自身を含む経営資源の管理です。持続的に成果を出し続けるためには、自分自身の「ウェルネス」のメンテナンス、これが大切と思います。瞑想も一つの手段ですが、AI抜きの経営会議で実りある議論ができるよう、自分自身としっかりと向き合うこと、これを続けていきたいと思います。

","description":"AIエージェントを束ねる時代の現実的なプロフェッショナル像 / スクラムイベントとして「瞑想」を設けてはどうかという私の提案に、プロジェクトマネージャーが賛同してくれました。半ば冗談だったのですが、AIにより仕事の進め方が急激に変化するなか、私たちが「AIが決めた」という逃げ道をどう塞ごうか迷っている、その共通の悩みを確認できたように思いました。…","prevId":"2026-02-16-project-management","nextId":"2026-02-10-saas-is","title":"AI時代の「社員稼業」","date":"2026-02-13 12:40:00 +0900","categories":["short"],"headline":"AIエージェントを束ねる時代の現実的なプロフェッショナル像"},{"name":"2026-02-10-saas-is","content":"

ただ言葉にしなかっただけ

「SaaSは死んだ」という言葉が繰り返されるようになったのは、エージェント型AIの台頭という文脈ですが、SaaSに関わるエンジニアとしてこの言葉に唐突感はありません。むしろ、多くのエンジニアが心のどこかで感じていながら、ただ言葉にしなかっただけのことではないでしょうか。

実際、AIブームよりも前からそのような空気を感じ取っていました。ビジネスの成長が華やかに語られる一方で、開発現場には何か重要なことが隠されている、そのような感覚でした。

感じていた違和感

開発組織は「扱いの難しい子供」のように大事され、しかしどこか距離を置かれて扱われてきたように思います。CRUDを実装しUIを整えること、それが仕事のすべてであっても、プロダクトマネージャーはそれを優しく「開発」と呼びます。

そんな距離感の背景は、時間軸のズレです。セールスが駆ければ駆けるほど開発が遅くなるというSaaSの宿命的な性質は、「大人の世界」と「子供の世界」を生み出します。２つの世界と２つの時間軸、これが違和感の正体です。

AIが教えてくれたこと

エージェント型AIの可能性は、SaaSのかつての功績をはぎとりつつ、結果としてSaaSを古びたテンプレートに見せます。開発現場においても、「優しくない」疑問を発することを助長しながら、距離を保っていた２つの世界の関係性を揺るがします。

SaaSは死んだというのは、違和感を解消すべき時が来たということです。SaaSという「モデル」を離れるには良いタイミングだということをAIが教えてくれました。私たちは唯一の世界に戻り、同じ現実を見て、同じ時間軸で動く。さあ、町に出ましょう。一緒に仕事をしましょう！

","description":"SaaSの生死はともかく、町に出て一緒に仕事をしましょう。 / 「SaaSは死んだ」という言葉が繰り返されるようになったのは、エージェント型AIの台頭という文脈ですが、SaaSに関わるエンジニアとしてこの言葉に唐突感はありません。むしろ、多くのエンジニアが心のどこかで感じていながら、ただ言葉にしなかっただけのことではないでしょうか。…","prevId":"2026-02-13-work-with-ai","nextId":"2026-02-05-constraints","title":"「SaaSの死」に応答する","date":"2026-02-10 15:00:00 +0900","categories":["note"],"headline":"SaaSの生死はともかく、町に出て一緒に仕事をしましょう。"},{"name":"2026-02-05-constraints","content":"

制約に従属することが目的化する

制約条件とは、本来の目的から相対的に見出されるものですが、目的があいまいになる一方で制約への従属が目的化する、そのような状況をしばしば目にしています。その状況下では、仕事はただ隙間を埋める、まるで白紙のジグソーパズルを解くような作業となってしまいます。

本筋が無いのに代替案の議論が始まる

従属が目的化している状況では、本来の目的が表層的な言葉のみの抜け殻になる一方で、本筋を欠いた「代替案」のみが活発に議論されるようになります。顧客価値は思考の外に追いやられ、自分たちだけの問題にエネルギーが費やされてしまうのです。

自然法則を回復させる

制約のバランス調整が作用しなくなり、従属が目的化する背景には、官僚的になりがちな組織文化や、責任回避の心理、共依存に近い関係性があるかもしれません。いずれにしても、プロジェクト推進においては、「成功したい」と願う自然法則が働いているかどうかを、繰り返し点検する必要があります。

","description":"プロジェクトを成功させたいと自然に思えていますか？ / 制約条件とは、本来の目的から相対的に見出されるものですが、目的があいまいになる一方で制約への従属が目的化する、そのような状況をしばしば目にしています。その状況下では、仕事はただ隙間を埋める、まるで白紙のジグソーパズルを解くような作業となってしまいます。…","prevId":"2026-02-10-saas-is","nextId":"2026-02-02-emotional-tidy-up","title":"制約への従属","date":"2026-02-05 06:00:00 +0900","categories":["short"],"headline":"プロジェクトを成功させたいと自然に思えていますか？"},{"name":"2026-02-02-emotional-tidy-up","content":"

振り返って言葉にしてみると

現場で起こった悩みを言葉にしてみると、それがあまりに単純で、実は陳腐な悩みではなかったかと恥ずかしくなるようなことが時々あります。しかし多くの場合、それはその時の感情をなぞった表現に過ぎません。つまり、それは悩みの「構造」の単純さを表したものではありません。

スパッと切れても

意思決定の局面ではその単純化は役に立ちます。自分自身の経験に基づく、あるいは信頼できる人物の「スパッと切る」判断には合理性が感じられます。しかしながら、プロジェクトを振り返り、再現可能あるいは回避可能な要素を取り出そうとするときには、さかのぼって複雑な構造に立ち入っていくことも必要です。

より安全な仕組みのために

感情的な整理が同一になったとしても、問題の構造が同じとは限らないのです。私たちにはこの先も無数の意思決定の場面がありますから、振り返りを通じて問題の構造を言語化し（自然言語以外も活用できます。例えば、プログラミング言語）、チームがより安全に働ける仕組みとしてそれを再構成する必要があります。

","description":"陳腐な悩みは本当に陳腐な悩みなのでしょうか？その背景を振り返る必要があるでしょうか？ / 現場で起こった悩みを言葉にしてみると、それがあまりに単純で、実は陳腐な悩みではなかったかと恥ずかしくなるようなことが時々あります。しかし多くの場合、それはその時の感情をなぞった表現に過ぎません。つまり、それは悩みの「構造」の単純さを表したものではありません。…","prevId":"2026-02-05-constraints","nextId":"2026-01-29-tech-interview","title":"感情的な整理と振り返りの違い","date":"2026-02-02 08:00:00 +0900","categories":["short"],"headline":"陳腐な悩みは本当に陳腐な悩みなのでしょうか？その背景を振り返る必要があるでしょうか？"},{"name":"2026-01-29-tech-interview","content":"$28","description":"成果物（コード）を中心に据えて議論し「仕事観」を共有するような面接について説明します。 / プロダクトエンジニアの採用活動において、私は「技術試験」を設計し、面接官の一人としてそれに参加しています。一般的にイメージされる「コーディング試験」とは少し違うため、私はこれを「コード中心面接」と呼んでいます。…","prevId":"2026-02-02-emotional-tidy-up","nextId":"2026-01-27-system-update","title":"コード中心面接のすすめ","date":"2026-01-29 06:00:00 +0900","categories":["note","column"],"headline":"成果物（コード）を中心に据えて議論し「仕事観」を共有するような面接について説明します。"},{"name":"2026-01-27-system-update","content":"$29","description":"組織を支えるシステム（制度やルール）も、コンピューターシステム同様にメンテナンスが必要です。 / 制度やルールの見直しが話題になると、それがあたかも「何かへの攻撃」であるかのような前提で議論が始まることがありますが、最初にそれらがそもそも何を守るためのものだったかを思い出す必要があります。そして、攻撃という印象（バイアス）を排したうえで、その制度やルールがいまでも正しく働いているのかを検証し、その結果を客観的事実として参加者全員が受け入れる必要があります。そうすれば、環境変化に応じてシステムをアップデートする、というシンプルなモチベーションで議論を続けることができるでしょう。…","prevId":"2026-01-29-tech-interview","nextId":"2026-01-22-repeat","title":"システム化された怠惰","date":"2026-01-27 06:00:00 +0900","categories":["note"],"headline":"組織を支えるシステム（制度やルール）も、コンピューターシステム同様にメンテナンスが必要です。"},{"name":"2026-01-22-repeat","content":"

恥を忍んで繰り返す

同じことを何度も言うのは、くどく感じて正直少し恥ずかしいものです。しかし、リーダーには意図してこれをやらねばならない時があります。チームの前進には「一度の名言」や「一瞬のひらめき」ではなく時間が必要だからです。

言葉は刺さらない

天才同士の師弟関係のように、言葉が刺さった瞬間に人が変わり景色が一気に変わる、そのような瞬間は期待できないのです。繰り返し言っていたことが「しばらくして」実現するというのが普通です。チームメンバーはそれぞれが違う背景、そして違う認識の方法を持っているのですから。

自信をもって時間を過ごす

私は、最初の期待を「超える」成果が時間差で返ってくる、そんな経験を何度もしました。待った甲斐があったというものです。期待を手放さず言葉の熱量を維持して、自信をもって時間を過ごすこと、これがチーム運営においては大事だと思います。

―余談ですが、加齢で現れやすい特性とリーダーシップの要件とに偶然の重なりはありそうです。しかしこれで思い上がると、独りよがりの人物と思われかねないので注意が必要です。この件はまた別の機会に。

","description":"刺さらない言葉の先に期待を超える成果があるかもしれない / 同じことを何度も言うのは、くどく感じて正直少し恥ずかしいものです。しかし、リーダーには意図してこれをやらねばならない時があります。チームの前進には「一度の名言」や「一瞬のひらめき」ではなく時間が必要だからです。…","prevId":"2026-01-27-system-update","nextId":"2026-01-09-middle-up-down","title":"同じことを言い続ける","date":"2026-01-22 08:00:00 +0900","categories":["short"],"headline":"刺さらない言葉の先に期待を超える成果があるかもしれない"},{"name":"2026-01-09-middle-up-down","content":"$2a","description":"エンジニアひとくくりをやめて、現場のリーダーを軸としたミドルアップダウンのアプローチで、柔軟な一枚岩の組織を構築する方法の考察。 / プロダクトの性質や、事業のフェーズによっても、エンジニアに求められる「専門性」や組織に求められる「厚み」は刻々と変化します。しかし多くの組織でエンジニアを「ひとくくり」にする曖昧な採用方針をとりがちです。少しでも具体性を与えようと「フルスタックエンジニア」や「プレイングマネージャー」、あるいはトレンディな用語でそれを修飾するわけですが、「現場のリアリティ」との乖離は埋まりません。本来なら状況を精緻に分析し、クリアなおそらく複数のジョブディスクリプション（JD）に落とし込むべきですが、事業と採用との両面の環境が高速に移り変わる中で採用方針を機動的に変更することは困難です。…","prevId":"2026-01-22-repeat","nextId":"2026-01-07-prompt-dream","title":"ミドルアップダウンのエンジニア採用","date":"2026-01-15 08:00:00 +0900","categories":["note"],"headline":"エンジニアひとくくりをやめて、現場のリーダーを軸としたミドルアップダウンのアプローチで、柔軟な一枚岩の組織を構築する方法の考察。"},{"name":"2026-01-07-prompt-dream","content":"

技術が解消してきた「やっかいごと」

新しい技術はいつも、私たちの「やっかいごと」を消し去ってくれました。食洗機からクラウドまで、私たちはその恩恵を享受してきたはずです。それなのに、最新のツールを前にすると、未知の恐怖や抵抗感に襲われることがあります。

自分自身も「やっかいごと」の一部

その種の不安の正体は、自分自身が「やっかいごと」の一部であるという暗い自覚かもしれません。不毛な活動を「仕事」と偽っている無意識の罪悪感が、変化から自分を遠ざけようとするのです。後ろ向きな自分と戦い、誠実に前向きでいれば、新しい技術は脅威ではなく、自分が自分でいるための道具になるはずです。

夢をかなえるため

夢を見ることが大事です。かなえたいことを言葉にするようAIが促しています。「夢をかなえるため」という当初の気持ちで自身を振り返ってみて、そして前を向けば、不安はきっと創造の火花に変化するでしょう。

","description":"新しい技術は人を不安にさせる、人はその不安を創造力に変える。 / 新しい技術はいつも、私たちの「やっかいごと」を消し去ってくれました。食洗機からクラウドまで、私たちはその恩恵を享受してきたはずです。それなのに、最新のツールを前にすると、未知の恐怖や抵抗感に襲われることがあります。…","prevId":"2026-01-09-middle-up-down","nextId":"2025-12-18-stay-long","title":"新しい技術が素敵な理由","date":"2026-01-07 08:00:00 +0900","categories":["short"],"headline":"新しい技術は人を不安にさせる、人はその不安を創造力に変える。"},{"name":"2025-12-18-stay-long","content":"$2b","description":"採用活動において、候補者に求める・求められる「定着」という要件は何なのだろうか。 / 私はこれまでに10回以上の転職を経験してきました。それは裏を返せば、100回を超える「お断り」を受けてきたということでもあります。キャリアの中盤以降では、不採用の理由として「定着しそうにない」というフィードバックをしばしば受け取りました。この文脈で言われる「定着」という言葉について、少し掘り下げてみたいと思います。…","prevId":"2026-01-07-prompt-dream","nextId":"2025-10-20-framework","title":"期待値としての「定着」について考える","date":"2025-12-18 06:00:00 +0900","categories":["note"],"headline":"採用活動において、候補者に求める・求められる「定着」という要件は何なのだろうか。"},{"name":"2025-10-20-framework","content":"

フレームワークとは

フレームワークは「物事をとらえるための手段」です。ビジネス分析では「状況を整理するレンズ」として意図的に使い分けます。ところが、ソフトウェア開発ではフレームワーク自体を実践だと捉えてしまいがちです。手段が目的化するのです。実際に、作業の大部分がフレームワークに規定されるため、開発ではその現象がしばしば起こります。

手段の目的化という落とし穴

この手段の目的化が深刻な問題を引き起こすのは、フレームワークと本来の目的との適合性に疑義が生じたとき、あるいは環境変化によって不適合が生じたときです。普通なら「レンズを掛け替えれば」良いのですが、現実を無理にフレームワークに当てはめる結果、フレームワークの思想からも逸脱した複雑な依存関係をこしらえたり、あるいは空虚なモジュールを量産したりする――これは技術的負債が膨らむ瞬間です。

さらに手段の権威化も生じます。時間を経るごとに、本来の目的を意識し、その目的達成に資するかという観点から実装を評価する姿勢が鈍っていきがちです。開発者自身が責任を持つべき評価のプロセスをフレームワークという「権威」に委ねてしまうのです。

なぜ囚われてしまうのか

フレームワークに囚われてしまう理由は二つあります。ひとつは思考の抽象度が固定化されてしまうことです。手段あるいは権威と化したフレームワークのもとで、そもそも「顧客にどんな価値を届けるのか」という本来の目的に立ち戻る思考が難しくなるのです。

ふたつ目はサンクコストの誤謬です。フレームワークの枠内で費やした時間が権威性を補強し、逸脱をためらわせます――ただ、この点に関しては昨今のAIの発展が解決の糸口を与えつつあるでしょう。さいきん、私たちは新しく何かを始めることに物怖じしません。

囚われず、あえて利用していく

単一のフレームワークに囚われないよう留意し、本来の目的の達成に資するかという観点から継続的に評価を行い、あえて使い倒していくのが良い姿勢でしょう。加えて、組織づくり（採用や育成）の観点からは、複数のフレームワークを使いこなせるスキルと、それらのフレームワークが「実際に何を解決しているのか」を理解できているかどうか。これらがますます重要になっているように思われます。

","description":"ソフトウェアエンジニアだけがフレームワークを誤解しているかもしれない。 / フレームワークは「物事をとらえるための手段」です。ビジネス分析では「状況を整理するレンズ」として意図的に使い分けます。ところが、ソフトウェア開発ではフレームワーク自体を実践だと捉えてしまいがちです。手段が目的化するのです。実際に、作業の大部分がフレームワークに規定されるため、開発ではその現象がしばしば起こります。…","prevId":"2025-12-18-stay-long","nextId":"2025-10-09-planning-poker","title":"フレームワークは利用するもの","date":"2025-10-19 09:00:00 +0900","categories":["note"],"headline":"ソフトウェアエンジニアだけがフレームワークを誤解しているかもしれない。"},{"name":"2025-10-09-planning-poker","content":"

プランニングポーカーの思い出

プランニングポーカーに初めて出会ったとき、リスクに対して手を挙げるとか、合意形成の努力をするとか、そういうことが仕組化されて期待されていることに感動した。

当時の私は、処世術としてそうした振る舞いを脇に置く習慣が強かったのだと思う。惰性を超える良い機会になった。

組織はときどき組織をあきらめる

いま身近にプランニングポーカーを行っているチームはないが、その趣旨は自然と実践されているようだ。だから形式は不要だということだろう。それはとても頼もしい。

気を付けたいのは、あるとき組織は組織づくりをあっさりあきらめ人に期待しなくなる、そういう退行が起こるということだ。

だから、人に期待する仕組みは、何かしら組織にインストールしておいたほうがよい。形式は何でもよいので。

\nおまけ：こちらのツールは、自分のチーム向けに作ったオンラインで行うプランニングポーカーのツールです。無料ですのでご自由にお使いください。\n

","description":"人に期待する仕組みを組織にインストールしておいたほうが良い。 / [プランニングポーカー](https://en.wikipedia.org/wiki/Planning_poker)に初めて出会ったとき、リスクに対して手を挙げるとか、合意形成の努力をするとか、そういうことが仕組化されて期待されていることに感動した。…","prevId":"2025-10-20-framework","nextId":"2025-10-06-failure","title":"プランニングポーカーの思い出","date":"2025-10-09 06:00:00 +0900","categories":["short"],"headline":"人に期待する仕組みを組織にインストールしておいたほうが良い。"},{"name":"2025-10-06-failure","content":"

成功者の特権として

知人と某ＣＥＯの著書「失敗を語ろう」の話をしていたとき、自分らはまだ成功していないから語るべき失敗もないな…と笑った憶えがある。

失敗を語れるのは成功者の特権というのは確かにそうだ。例えば、採用面接で口外すべきでない類の逸話が多く語られている。

目標のスケールを維持するために

それでも、本にして売れるかどうかは別として、一定規模の組織を預かるリーダーならば失敗は語るべきである。

語らないことは組織の目標を「自分一人で尻拭いできる範囲」に矮小化する。失敗を語ることは、目標のスケールを維持するために必要なのだ。

ただし、自虐ではなく失敗を語ろう。

","description":"語れないリーダーは組織の目標を「自分一人で尻拭いできる範囲」に矮小化してしまう。 / 知人と某ＣＥＯの著書「失敗を語ろう」の話をしていたとき、自分らはまだ成功していないから語るべき失敗もないな…と笑った憶えがある。…","prevId":"2025-10-09-planning-poker","nextId":"2025-09-28-safety","title":"失敗は語ろう","date":"2025-10-06 06:00:00 +0900","categories":["short"],"headline":"語れないリーダーは組織の目標を「自分一人で尻拭いできる範囲」に矮小化してしまう。"},{"name":"2025-09-28-safety","content":"

ここだけは安全である、と言う意味

心理的安全性を言うのは「この場では率直に語ってよい」という限定的な安全圏を設けるためであり、基本的に競争の激しい環境下にいることを前提とした条件設定です。

雇用安定性が高いメンバーシップ型雇用のもとでは、すでに基礎的な安全は確保されていることから、「この場は安全」だとあえて言う心理的安全性の差分価値が見えにくくなり、かえって利己的で好ましくない行動の口実にすらなります。

まず危険を共有する必要がある

勝敗が問われているというのは、文化の違いにかかわらず事業組織の本質です。しかしながら、レイオフ等が危険を現実に可視化する環境では緊張感が自動的に生成されるかもしれませんが、メンバーシップ型雇用のもとでは、そのような危険を日々の生活の中で感じ取ることがありません。

この環境下においてもなお、心理的安全性の果実を得たいならば、リーダーは組織に迫る「危険」を明確に言語化し、組織全体に説き続ける必要があります。議論し、学習し、合理的な意思決定がなければ組織は負けるのだ、この純粋な危険を継続的に共有しなければなりません。

異論を手に入れるための仕組み

心理的という用語が情緒的と誤解され、文字通り甘えの理由付けとなるのは典型的な間違いでしょう。当然ながら心理的安全性は免責の仕組みではありません。心理的安全性は責任ある行動を促す一種の「規律」であり、同時に競争に勝つための「合理的な方法」です。例えば、それは「異論の調達コスト」を押し下げ、プロダクト品質の多面的な検証を可能にします。

リーダーが組織に迫る危険（そしてもちろんそれを克服した姿）を説明し全体がそれを共有する中で、規律としての心理的安全性が実現されいれば、組織はより学習を加速させ、最善の意思決定と勝利、そしてイノベーションへの道を開くことができるでしょう。

","description":"心理的安全性と甘えとはやはり区別しなければいけません。 / 心理的安全性を言うのは「この場では率直に語ってよい」という限定的な安全圏を設けるためであり、基本的に競争の激しい環境下にいることを前提とした条件設定です。…","prevId":"2025-10-06-failure","nextId":"2025-09-26-cowboys","title":"心理的安全性とは規律である","date":"2025-09-28 09:00:00 +0900","categories":["note"],"headline":"心理的安全性と甘えとはやはり区別しなければいけません。"},{"name":"2025-09-26-cowboys","content":"

勇気が必要だ

やさしいカウボーイ集団、ポテンシャルはありそうだがどうも実行力に欠けるように聞こえる。これが私にはありがちな開発組織の姿を現しているように思える。

もっと曖昧な目的が必要な時期に、既製品のマインドが横滑りで導入され、過度な細分化・純粋化が起きた結果、エンジニアの気持ちがプロダクトの現実と乖離する。そんなところが一つの原因だと想像している。

抽象度の高い目的を掲げ続けるには勇気がいるので、リーダーはいつも困難と向かい合う。臆病になれば失敗する、実際に私は何度も失敗した。

もう少し自分の失敗例を集めてから、長い文章を書こうと思う。

","description":"強い開発組織とはポテンシャルありそうな集団のことではないと思う。 / やさしいカウボーイ集団、ポテンシャルはありそうだがどうも実行力に欠けるように聞こえる。これが私にはありがちな開発組織の姿を現しているように思える。…","prevId":"2025-09-28-safety","nextId":"2025-09-24-meeting-online","title":"やさしいカウボーイたち","date":"2025-09-26 09:00:00 +0900","categories":["short"],"headline":"強い開発組織とはポテンシャルありそうな集団のことではないと思う。"},{"name":"2025-09-24-meeting-online","content":"

そもそも集まっていない

オンライン会議で「演説をぶった」ようになり、終了後に自分で自分にがっかりすることがある。これは私にとって明確なオンライン会議のダウンサイドだ。話を聞いてもらいやすい立場（お年寄り）になったからなのか、何にせよ、私のファシリテーション能力不足が露呈している。

同時に、道具やら環境を整えることに傾く自分にも気づく。リモート会議がコンテンツ化する。会議が「場」ではなく消費者のための「番組」となり、Googleカレンダーがテレビの番組表に変わる。

何のために集まって話すのだっけ？という問いに立ち返るわけだが、そこまで考えて、けっきょく結論は広い意味でのファシリテーション能力不足ということなる。参加者一人ひとりへの期待が曖昧なのだ。会議の目的やアジェンダよりそちらのほうが重要だと思われた。

","description":"オンライン会議がコンテンツ化してテレビ番組のように消費される。 / オンライン会議で「演説をぶった」ようになり、終了後に自分で自分にがっかりすることがある。これは私にとって明確なオンライン会議のダウンサイドだ。話を聞いてもらいやすい立場（お年寄り）になったからなのか、何にせよ、私のファシリテーション能力不足が露呈している。…","prevId":"2025-09-26-cowboys","nextId":"2025-09-21-architecture","title":"コンテンツ化するオンライン会議","date":"2025-09-24 09:00:00 +0900","categories":["short"],"headline":"オンライン会議がコンテンツ化してテレビ番組のように消費される。"},{"name":"2025-09-21-architecture","content":"$2c","description":"アーキテクチャはフレームワークではなく、ましてやプロジェクトのディレクトリ構造のことではない。 / この記事は、Robert C. Martin（Uncle Bob）によって紹介された「Clean Architecture」を題材に、そのようなアーキテクチャが発想された背景や、解決しようとしている課題、そしてプロダクトへの適用可能性について考察するものです。Clean Architectureそのものを解説することを目的とはしていません。…","prevId":"2025-09-24-meeting-online","nextId":"2025-09-20-probation","title":"クリーンアーキテクチャの時代","date":"2025-09-21 08:00:00 +0900","categories":["note"],"headline":"アーキテクチャはフレームワークではなく、ましてやプロジェクトのディレクトリ構造のことではない。"},{"name":"2025-09-20-probation","content":"

例えば試用期間

３か月の試用期間で何か見極めようとしていますか？環境に適応するには時間がかかる、最初の数か月は生産性が出なくて当然、そのような前提に寄りかかっていないでしょうか。この期間には双方にとって濃い学びがあるはずで、なんとなく通り過ぎてはもったいないように思います。

適応に重きを置きすぎている

終身雇用の記憶や、期限切れの慣習に無意識に従いながら、適応すること・させることに採算度外視の投資をしていることに気が付かない、採用する側・される側の双方にそんな背景がありそうです。結果として、適応に長い時間を要する高コストな環境が維持されてしまう。

そのような環境下で会社は、環境の改善に取り組む代わりに「適応力が高い人」を探し始めがちですが、そもそも優秀さを消耗させる前提の仕組みはとても効率が悪いものです。

慣れより学び

長すぎるの適応プロセスは、惰性で働くような姿勢を奨励するものになりかねません。節目節目を振り返りながら、相互的な学びを組織と個人とが享受できる環境を作るべきだと思います。そうして、組織も個人も未来のマーケットに適応することを目指しましょう。

","description":"適応すること・させることに採算度外視で時間をかけすぎてはいませんか？ / ３か月の試用期間で何か見極めようとしていますか？環境に適応するには時間がかかる、最初の数か月は生産性が出なくて当然、そのような前提に寄りかかっていないでしょうか。この期間には双方にとって濃い学びがあるはずで、なんとなく通り過ぎてはもったいないように思います。…","prevId":"2025-09-21-architecture","nextId":"2024-11-28-time-to-be-alone","title":"適応に時間をかけすぎている","date":"2025-09-20 08:00:00 +0900","categories":["note"],"headline":"適応すること・させることに採算度外視で時間をかけすぎてはいませんか？"},{"name":"2024-11-28-time-to-be-alone","content":"

時間の湧く場所

時間が無いと感じたときは一人になるべきで、終わらない会話をまず終わらせる必要があるようだ。それが終わらない独り言だったならば、場所を変え、違う景色を見に行くべきだ。そうしたら、時間が贅沢に湧き出ている場所が見つかる。

","description":"時間が無いと感じたときには時間が湧く場所を探しに行かねばならない。 / 時間が無いと感じたときは一人になるべきで、終わらない会話をまず終わらせる必要があるようだ。それが終わらない独り言だったならば、場所を変え、違う景色を見に行くべきだ。そうしたら、時間が贅沢に湧き出ている場所が見つかる。…","prevId":"2025-09-20-probation","nextId":"2024-08-26-seriousness","title":"時間を探しに行く","date":"2024-11-28 08:00:00 +0900","categories":["short"],"headline":"時間が無いと感じたときには時間が湧く場所を探しに行かねばならない。"},{"name":"2024-08-26-seriousness","content":"

真剣さというものは

真剣さとは、子供用の鈴の入ったゴムボールの鈴であり、ときには公園の忘れもので、理由なく蹴飛ばされたり、しゃんしゃん鳴ったりするものだ。

","description":"真剣さはときに理由なく蹴飛ばされたりする。 / 真剣さとは、子供用の鈴の入ったゴムボールの鈴であり、ときには公園の忘れもので、理由なく蹴飛ばされたり、しゃんしゃん鳴ったりするものだ。…","prevId":"2024-11-28-time-to-be-alone","nextId":"2024-04-14-museum","title":"真剣さとゴムボール","date":"2024-08-26 07:00:00 +0900","categories":["short"],"headline":"真剣さはときに理由なく蹴飛ばされたりする。"},{"name":"2024-04-14-museum","content":"

仕事とか自分とかという道具

世界を都合よくとらえるために利用していた道具（仕事とか自分とか）を一時忘れるということは大事だ。絵画の前でそれを自覚して、鳥肌が立ったり、世界の端に居る気がしたりした。

","description":"絵画のまえでは自分のことを考えないで済んだ。 / 世界を都合よくとらえるために利用していた道具（仕事とか自分とか）を一時忘れるということは大事だ。絵画の前でそれを自覚して、鳥肌が立ったり、世界の端に居る気がしたりした。…","prevId":"2024-08-26-seriousness","nextId":"2024-03-23-clock-settings","title":"美術館を訪問した","date":"2024-04-14 08:00:00 +0900","categories":["short"],"headline":"絵画のまえでは自分のことを考えないで済んだ。"},{"name":"2024-03-23-clock-settings","content":"

分かるはずなのに

私のアナログ式のGショックは棚の上で毎朝7時2分にアラームを鳴らしている。解除方法は、ちょっと考えれば分かるはずなのだが、分からないかもしれないという不安があって、考えないことにしてる。だから毎朝アラームが鳴る。

臆病になってはいけない、4つのボタンの組み合わせや、長押しも併用して、解除手順を正確に再現する。なんでも良いから、日々そういうハードルを超える訓練が必要だ。

","description":"ちょっと考えれば分かるはずなのに臆病さから考えるのをやめる。 / 私のアナログ式のGショックは棚の上で毎朝7時2分にアラームを鳴らしている。解除方法は、ちょっと考えれば分かるはずなのだが、分からないかもしれないという不安があって、考えないことにしてる。だから毎朝アラームが鳴る。…","prevId":"2024-04-14-museum","nextId":"2024-03-18-too-much-first-person","title":"アラームの解除方法","date":"2024-03-23 08:00:00 +0900","categories":["short"],"headline":"ちょっと考えれば分かるはずなのに臆病さから考えるのをやめる。"},{"name":"2024-03-18-too-much-first-person","content":"

自分を通して世界を見すぎている

一定の経験を積んで物事の理解が容易にできるようになったからなのか、権利の主張が許されるような地位を得たからなのか、最近は自分を通して世界を見る時間が長くなりがちだ。

自分を俯瞰しながら、以前はもっと自分を雑にコントールしていたように思う。ときどき溝に落ちて死んだり、でも、復活して、無敵のスターを拾ったり。そうして諸々クリアできていた。

","description":"一人称視点で世界を見すぎている。ひどく臆病になり、ただ疲弊している。 / 一定の経験を積んで物事の理解が容易にできるようになったからなのか、権利の主張が許されるような地位を得たからなのか、最近は自分を通して世界を見る時間が長くなりがちだ。…","prevId":"2024-03-23-clock-settings","nextId":"2023-12-09-what-i-said","title":"脆弱な一人称","date":"2024-03-18 08:00:00 +0900","categories":["short"],"headline":"一人称視点で世界を見すぎている。ひどく臆病になり、ただ疲弊している。"},{"name":"2023-12-09-what-i-said","content":"

言葉に生活の術を教える

言葉が殺虫灯に撃たれて虫のようにパチンと死んでしまう。この世界で生き延びられるよう、自分の言葉に生活の術を教えてあげなければいけない。

","description":"まず言葉に生命力を与えねばならない。 / 言葉が殺虫灯に撃たれて虫のようにパチンと死んでしまう。この世界で生き延びられるよう、自分の言葉に生活の術を教えてあげなければいけない。…","prevId":"2024-03-18-too-much-first-person","nextId":"2023-08-20-cheap-fact","title":"いいたいこと","date":"2023-12-09 07:00:00 +0900","categories":["short"],"headline":"まず言葉に生命力を与えねばならない。"},{"name":"2023-08-20-cheap-fact","content":"

ある事実

日射しの強い日に短パンで外を歩き、ふくらはぎに刺すような痛み、ほんとうに針で刺されたように痛い。そんな陳腐な出来事でも機会があったら他人に話したいなと思うのは、嘘をつくよりましで、すこしでも誠実な時間を過ごせる期待があるからだ。

","description":"事実を見つけては、嘘よりましだと思っている。 / 日射しの強い日に短パンで外を歩き、ふくらはぎに刺すような痛み、ほんとうに針で刺されたように痛い。そんな陳腐な出来事でも機会があったら他人に話したいなと思うのは、嘘をつくよりましで、すこしでも誠実な時間を過ごせる期待があるからだ。…","prevId":"2023-12-09-what-i-said","nextId":"2023-08-16-word-weight","title":"嘘よりましな","date":"2023-08-20 17:00:00 +0900","categories":["short"],"headline":"事実を見つけては、嘘よりましだと思っている。"},{"name":"2023-08-16-word-weight","content":"

安全に言葉を使いたかったら

優位な立場の人が言ったら、強い口調でも弱い口調でも、提案でも指示でも、けっきょく命令として響くと思うが、しかしながら後から「そうは言ってはいない」と言葉の重みの変更ができてしまうのがズルいところ。

受け手でもまた、受けとった言葉の印象を事後的に更新しているもので、例えば、受けた言葉に「悪意があった」「攻撃された」と記憶の中でそれに肉付けしている。

安全に言葉を使いたかったら―どうすればいいんだ？

","description":"言葉の重みは事後的に変更される。発した側でも受け取る側でも。 / 優位な立場の人が言ったら、強い口調でも弱い口調でも、提案でも指示でも、けっきょく命令として響くと思うが、しかしながら後から「そうは言ってはいない」と言葉の重みの変更ができてしまうのがズルいところ。…","prevId":"2023-08-20-cheap-fact","nextId":"2023-08-14-new-watch","title":"言葉の重み","date":"2023-08-16 08:00:00 +0900","categories":["short"],"headline":"言葉の重みは事後的に変更される。発した側でも受け取る側でも。"},{"name":"2023-08-14-new-watch","content":"

腕時計を買う

ショーケースの中の腕時計を見ていたら、めずらしいよと言われて、見てるだけだと返したものの、見てるだけでいいよ見てみなと言われて、つけてみて、その腕時計を買った。時計を買う時間だったということだ。

","description":"時計を買った、時間を過ごした。 / ショーケースの中の腕時計を見ていたら、めずらしいよと言われて、見てるだけだと返したものの、見てるだけでいいよ見てみなと言われて、つけてみて、その腕時計を買った。時計を買う時間だったということだ。…","prevId":"2023-08-16-word-weight","nextId":"2023-08-12-bou","title":"新しい時計","date":"2023-08-14 20:00:00 +0900","categories":["short"],"headline":"時計を買った、時間を過ごした。"},{"name":"2023-08-12-bou","content":"

ぼう

棒のような足の友達は
\nそれが棒のようだなんて言わない
\nいいやつだ

ブランドのコートの種類だったり
\n値段だったり
\n生地の厚みだったりを話した

そして筋肉の厚みだったりするのは
\nうまく行った駅と　お城と
\nそのあと５日なんだ

...

Tumblr\nから再掲・加筆。

","description":"ぼう / 棒のような足の友達は …","prevId":"2023-08-14-new-watch","nextId":"2023-03-25-future-year","title":"ぼう","date":"2023-08-12 06:00:00 +0900","categories":["short"],"headline":""},{"name":"2023-03-25-future-year","content":"

3032

3032年と私の作業ノートの書かれていて、しばしば開かれたはずのノートにも関わらず違和感なくそこにありつづけていた。

","description":"過去も未来もカードのように散らばっている。 / 3032年と私の作業ノートの書かれていて、しばしば開かれたはずのノートにも関わらず違和感なくそこにありつづけていた。…","prevId":"2023-08-12-bou","nextId":"2023-03-23-mentality","layout":"post","title":3032,"author":"Keisuke Yamamoto","date":"2023-03-25 08:00:00 +0900","categories":["short"],"headline":"過去も未来もカードのように散らばっている。"},{"name":"2023-03-23-mentality","content":"

ただの余計なこと

心の内と外の境界の位置は人それぞれで違う。一個人においても、その境界がときどき動いている。必要に応じて調整されている、がより正しい表現かもしれない。

余計なことを言いがちな人というのは、外側を広くとるような境界の引き方をするだろう。多くの人が内側で処理している思考の過程が漏れ出て外に聞こえてしまう。未熟な思考が漏れ出るものだから、ときに攻撃的に響いて余計な問題を起こす。

それはただの思考の断片であり曝露された深層心理とかではない。時を経れば、内側で処理されたときと同様に、結論に吸収されてしまうものだ。

","description":"その人の漏れ出た思考がときに攻撃的に響く。 / 心の内と外の境界の位置は人それぞれで違う。一個人においても、その境界がときどき動いている。必要に応じて調整されている、がより正しい表現かもしれない。…","prevId":"2023-03-25-future-year","nextId":"2023-03-13-return-to-office","layout":"post","title":"余計なことを言いがちな人","author":"Keisuke Yamamoto","date":"2023-03-23 05:00:00 +0900","categories":["short"],"headline":"その人の漏れ出た思考がときに攻撃的に響く。"},{"name":"2023-03-13-return-to-office","content":"

オフィスへ返る？帰る？

オフィスでマスクをしなくても良くなった。その日、私はマスクを付けずにオフィスを歩き回り、ちょっと小走りしもした。私にとっては物理的な「返る」ではなくて、気持ち的な「帰る」であり、うれしい出来事だった。

仕事で議論をして厳しく批判されたりがあったとしても、そこに戻れば誇りを取り戻せる場所。マスク期間にはそういう場所が消えてしまったように思う。ひたすら時間と文脈とへの服従を強いられていた時代、大げさに言えばそんな期間だった。

オフィスそのもの、オフィスのある街、通勤経路、ぜんぶが必要な空間だった。こう言うと、リモートワークが問題だったということになるが、しかしながら問題はマスクだった。なぜならいま本当に気持ちが楽になったから。

さあ、空間が戻ってくる！

","description":"マスク生活とは時間と文脈への服従を強いられた時代だった。 / オフィスでマスクをしなくても良くなった。その日、私はマスクを付けずにオフィスを歩き回り、ちょっと小走りしもした。私にとっては物理的な「返る」ではなくて、気持ち的な「帰る」であり、うれしい出来事だった。…","prevId":"2023-03-23-mentality","nextId":"2023-03-05-premature-prerequisites","layout":"post","title":"オフィスへ帰る","author":"Keisuke Yamamoto","date":"2023-03-13 08:00:00 +0900","categories":["short"],"headline":"マスク生活とは時間と文脈への服従を強いられた時代だった。"},{"name":"2023-03-05-premature-prerequisites","content":"

前提は正しいとの思い込み

ぼんやりしていた事柄が、あることの前提事項となった途端、とても正しいこととして信奉されてしまう、これはプロジェクトのなかでしばしば見られる現象だ。信奉の背景には政治やあきらめや怠惰など種々のことがある。

振り返られることのない始まりは不幸だ。そこには、凝縮されたエネルギーがあって、疑われることがあればそれが弾けたというのに。

","description":"前提が未熟のまま孤独に終わりを迎える。 / ぼんやりしていた事柄が、あることの前提事項となった途端、とても正しいこととして信奉されてしまう、これはプロジェクトのなかでしばしば見られる現象だ。信奉の背景には政治やあきらめや怠惰など種々のことがある。…","prevId":"2023-03-13-return-to-office","nextId":"2023-03-04-reset-button","layout":"post","title":"未熟なままの前提","author":"Keisuke Yamamoto","date":"2023-03-05 18:00:00 +0900","categories":["short"],"headline":"前提が未熟のまま孤独に終わりを迎える。"},{"name":"2023-03-04-reset-button","content":"

リセットボタンを押したい

ソフトウェア開発のプロジェクトでリセットボタンを押したくなる時がある。自分の初動が悪かった時、よく分からなかった前提がさらに不明になってきた時など。

マネジメントの工夫によっては、リセットボタンの実装が可能にならないかと思ったりする。前提リセットの振り返りミーティングをしてみるとか。

ゲームと現実とは違うとか、容易にリセットできるものではないとか、もっともらしく聞こえるがそうだろうか。現実が困難に見えるのは、ただリセット機能の実装を怠っているからかもしれない。

","description":"ボールがリセットボタンにぶち当たって世界が台無しになった。 / ソフトウェア開発のプロジェクトでリセットボタンを押したくなる時がある。自分の初動が悪かった時、よく分からなかった前提がさらに不明になってきた時など。…","prevId":"2023-03-05-premature-prerequisites","nextId":"2023-03-03-simple-is-not-simple","layout":"post","title":"リセットボタン","author":"Keisuke Yamamoto","date":"2023-03-04 08:00:00 +0900","categories":["short"],"headline":"ボールがリセットボタンにぶち当たって世界が台無しになった。"},{"name":"2023-03-03-simple-is-not-simple","content":"

シンプルに思い込む

シンプルに考えたら物事が好転したりするだろうか。心の健康を保つためにはそのような考え方は役に立つかもしれない、しかしながら、その状況に多くに人が巻き込まれているならば、他の誰かの心はかえって複雑になっているかもしれない。

シンプルな理解で転ばないように歩くことは大事だ、ただ、地図の複雑さはいつも併せて知っておかなければならない。

","description":"思い込みで世の中をシンプルにしても、生きやすくはならない。 / シンプルに考えたら物事が好転したりするだろうか。心の健康を保つためにはそのような考え方は役に立つかもしれない、しかしながら、その状況に多くに人が巻き込まれているならば、他の誰かの心はかえって複雑になっているかもしれない。…","prevId":"2023-03-04-reset-button","nextId":"2023-02-23-see-something-on-people","layout":"post","title":"シンプルな思い込み","author":"Keisuke Yamamoto","date":"2023-03-03 07:30:00 +0900","categories":["short"],"headline":"思い込みで世の中をシンプルにしても、生きやすくはならない。"},{"name":"2023-02-23-see-something-on-people","content":"

人をみる

私には人を見る目が無いと思うが、人を見る目とは何なのだろうか？真意を知る能力、隠れた才能に気がつく能力、人を類型に整理して理解する能力だろうか。

多少の進歩はあったかもしれないが、悲しいかな、私は人を見るほど誤解を深めているように思える。

","description":"人を見るほど誤解が深まっていく。 / 私には人を見る目が無いと思うが、人を見る目とは何なのだろうか？真意を知る能力、隠れた才能に気がつく能力、人を類型に整理して理解する能力だろうか。…","prevId":"2023-03-03-simple-is-not-simple","nextId":"2023-02-13-consensus","layout":"post","title":"人を見る目","author":"Keisuke Yamamoto","date":"2023-02-23 07:30:00 +0900","categories":["short"],"headline":"人を見るほど誤解が深まっていく。"},{"name":"2023-02-13-consensus","content":"

言った・言わない

なぜ言った・言わないでもめてしまうのだろうか。なぜそんな過去にこだわるのだろう。合意があって物事を先に進めた結果、現在があるのでは？なぜ、言った・言わないのような「大昔」のことに関心が向くのだろう。

きっとそれは、合意を作る努力をしなかったからだ。合意を作るために大きな投資をしなかったから、それを大事にしようという気持ちにならない。それともう１つ、失敗を責める文化と、失敗を引き受ける勇気の無さ。

いつまでも揉めていたい

人々にいつまでも判断を留保したいと思っている、だから、言った・言わないは個人間の出来事ではない。それは臆病な集団の病気だ。

","description":"ひとたび合意できたなら、言った言わないなど大昔の話。 / なぜ言った・言わないでもめてしまうのだろうか。なぜそんな過去にこだわるのだろう。合意があって物事を先に進めた結果、現在があるのでは？なぜ、言った・言わないのような「大昔」のことに関心が向くのだろう。…","prevId":"2023-02-23-see-something-on-people","nextId":"2023-02-06-qr-code-payment","layout":"post","title":"言った言わない","author":"Keisuke Yamamoto","date":"2023-02-13 08:00:00 +0900","categories":["short"],"headline":"ひとたび合意できたなら、言った言わないなど大昔の話。"},{"name":"2023-02-06-qr-code-payment","content":"

手続きの手触り

自分のスマホのQRコードを見せて、お店の人にスキャンしてもらう、という手続き。これが、これまでを代替するにちょうどいい手触りだったのかもしれない。

","description":"コスパ・タイパより手触りがしっくりかどうか。 / 自分のスマホのQRコードを見せて、お店の人にスキャンしてもらう、という手続き。これが、これまでを代替するにちょうどいい手触りだったのかもしれない。…","prevId":"2023-02-13-consensus","nextId":"2023-01-22-invisible-switch","layout":"post","title":"QRコードの手触り","author":"Keisuke Yamamoto","date":"2023-02-06 08:00:00 +0900","categories":["short"],"headline":"コスパ・タイパより手触りがしっくりかどうか。"},{"name":"2023-01-22-invisible-switch","content":"

幸運のスイッチ探し

部屋の電気をつけようとして壁を触ることがある。そこにスイッチは無い。別にがっかりはしていないし、そもそも期待していないのかもしれない。なんとなく触ってみている気がする、そこにスイッチがあったらラッキー、のように。

","description":"手を伸ばしてそこに何かあったらラッキーじゃないか。 / 部屋の電気をつけようとして壁を触ることがある。そこにスイッチは無い。別にがっかりはしていないし、そもそも期待していないのかもしれない。なんとなく触ってみている気がする、そこにスイッチがあったらラッキー、のように。…","prevId":"2023-02-06-qr-code-payment","nextId":"2023-01-15-nel-drip-coffee","layout":"post","title":"見えないスイッチ","author":"Keisuke Yamamoto","date":"2023-01-22 12:00:00 +0900","categories":["short"],"headline":"手を伸ばしてそこに何かあったらラッキーじゃないか。"},{"name":"2023-01-15-nel-drip-coffee","content":"

コーヒー飲みますか？

バーテンが私に「ネルドリップのコーヒー飲みますか？」と聞いた。もうだいぶ前のことだ。そのとき \"唐突だな\" と思った、そしていまもなぜ彼がそう聞いたのか理由が分からない。

何度か行っていた店だったので、彼は私の習慣を知っていただろう、そこでコーヒーを飲んだことはない。だから、彼は新しいチャレンジを提案してくれたのかもしれない。私はひどく酔っていたのだろうか？それなら彼の親切心だったのかもしれない。

彼はわざわざ「ネルドリップ」と言った。新しい手法を試してみてうまく行ったので、どうしても飲んでほしかったのか。どう断ったか忘れてしまったが、おそらく無粋な断り方をした。

もう十年以上前のことなのだがときどき思い出しては理由を考える、そして、試してみればよかったなと。パッと霧の晴れる日がいつか来る、と、なぜかそう信じている。

","description":"コーヒーの淹れ方には色々あって、難しい話になりがちだ。 / バーテンが私に「ネルドリップのコーヒー飲みますか？」と聞いた。もうだいぶ前のことだ。そのとき \"唐突だな\" と思った、そしていまもなぜ彼がそう聞いたのか理由が分からない。…","prevId":"2023-01-22-invisible-switch","nextId":"2023-01-08-incident-for-example","layout":"post","title":"ネルドリップのコーヒー","author":"Keisuke Yamamoto","date":"2023-01-15 15:00:00 +0900","categories":["short"],"headline":"コーヒーの淹れ方には色々あって、難しい話になりがちだ。"},{"name":"2023-01-08-incident-for-example","content":"

やっておくべきだったという思い

インシデントのあと、やはりあの時ああしておくべきだったという思いが生まれる。その当時は、その対策を採用しにくい事情があって、リスクを許容して前に進む決断をしたのにもかかわらずだ。

そもそも論を振りかざすのは乱暴だ。なぜなら、私たちは進まなければいけなかったし、進まねばならないからだ。そもそも論は断片にしか関心をもっていないが、私たちは広い場所で過去にも未来にも関心をもっている。

そもそも論を乗り越えるにはチームワークが必要で、チームの中で起こる広がりのある議論は有意義だ。逆に、一人でその種の問題に立ち向かうのは大変困難だ。

","description":"そもそも論を乗り越えていくにはチームワークが大切だ。 / インシデントのあと、やはりあの時ああしておくべきだったという思いが生まれる。その当時は、その対策を採用しにくい事情があって、リスクを許容して前に進む決断をしたのにもかかわらずだ。…","prevId":"2023-01-15-nel-drip-coffee","nextId":"2023-01-05-no-dislikes","layout":"post","title":"それでも仕事する","author":"Keisuke Yamamoto","date":"2023-01-08 08:00:00 +0900","categories":["short"],"headline":"そもそも論を乗り越えていくにはチームワークが大切だ。"},{"name":"2023-01-05-no-dislikes","content":"

計画どおりに満足する

計画どおりを好むようになっている気がする。経験の積み重ねによれば、臨機応変な行動こそより得意になっているはずで、計画にさして重きを置かないようになりそうなものだが。目的がより大きくなって、これまでとは別種の慎重さが必要とされているのだろうか。いや、むしろスピードこそ求められているように思うが。

じつは、ただただ嫌いなものが増えただけだと思っている。慎重さとか計画性とか言って、できることだけを選り好みして、自身の劣化を隠蔽しているのだろう。嫌いなものが増えていく老い、そんなものに嫌悪しかない。

\n
とりあえずは夜にランダムに歩くもういちどキミをさがしに行くため
\n
Solid Air / 平沢進
\n

","description":"それは慎重さでも計画性でもなく、ただ好き嫌い増えただけのこと。 / 計画どおりを好むようになっている気がする。経験の積み重ねによれば、臨機応変な行動こそより得意になっているはずで、計画にさして重きを置かないようになりそうなものだが。目的がより大きくなって、これまでとは別種の慎重さが必要とされているのだろうか。いや、むしろスピードこそ求められているように思うが。…","prevId":"2023-01-08-incident-for-example","nextId":"2022-12-21-recovery-than-progress","layout":"post","title":"嫌いなものが増えただけ","author":"Keisuke Yamamoto","date":"2023-01-05 17:00:00 +0900","categories":["short"],"headline":"それは慎重さでも計画性でもなく、ただ好き嫌い増えただけのこと。"},{"name":"2022-12-21-recovery-than-progress","content":"

退化したところからの回復

きらびやかな報告をしたいし成果を宣伝したい、日常生活でも仕事のなかでもよくあることだ。進歩している、そう信じろ、そういう態度でいろ、と訓練される場合もある。ときに擬態をしつつ、嫌な気分になりながら、それを隠しながら。

実際のところ人はときどき退化してしまう、自然に何かを失っていく。それゆえにときどき失ったものの回復に時間を費やすのも自然だ。欠けたところを見つけ修復していく作業を、気負って進化と呼ぶ必要はない。

","description":"人は退化する。気負って進化と言い張る必要はない。 / きらびやかな報告をしたいし成果を宣伝したい、日常生活でも仕事のなかでもよくあることだ。進歩している、そう信じろ、そういう態度でいろ、と訓練される場合もある。ときに擬態をしつつ、嫌な気分になりながら、それを隠しながら。…","prevId":"2023-01-05-no-dislikes","nextId":"2022-03-22-tech-stack","layout":"post","title":"退化したところからの","author":"Keisuke Yamamoto","date":"2022-12-21 08:00:00 +0900","categories":["short"],"headline":"人は退化する。気負って進化と言い張る必要はない。"},{"name":"2022-03-22-tech-stack","content":"$2d","description":"プロジェクトチームが得た知識は組織全体に透過的にレプリケートされていく、はず。 / こんにちは。『技術選定』の話を書こうと思いますが、大きすぎるテーマに思われますので、今回は前の記事に書いた「いきなりレガシー」問題のみに焦点を絞ります。…","prevId":"2022-12-21-recovery-than-progress","nextId":"2022-01-14-company-culture","layout":"post","title":"技術選定","author":"Keisuke Yamamoto","date":"2022-03-22 09:00:00 +0900","categories":["note"],"headline":"プロジェクトチームが得た知識は組織全体に透過的にレプリケートされていく、はず。"},{"name":"2022-01-14-company-culture","content":"$2e","description":"カルチャーとは招待状なんでしょう。 / 組織に関わる話で『カルチャー』という言葉を頻繁に聞きます。それはときに理念のようで、ときにそこそこ強い行動規範のようです。そのカルチャーとは何なのでしょう。…","prevId":"2022-03-22-tech-stack","nextId":"2021-11-18-ask-possibility","layout":"post","title":"カルチャーとは何ですか","author":"Keisuke Yamamoto","date":"2022-01-14 09:00:00 +0900","categories":["note"],"headline":"カルチャーとは招待状なんでしょう。"},{"name":"2021-11-18-ask-possibility","content":"$2f","description":"前向きな性格それ自体には価値はないと思う。そもそも、それはとても一方的な評価だから。 / エンジニアにとって、「これできますか？」は最も回答が難しい質問の一つです。なぜなら答えはいつでもYESだからです。…","prevId":"2022-01-14-company-culture","nextId":"2021-10-29-legacy-system","layout":"post","title":"これできますか？と聞かれても","author":"Keisuke Yamamoto","date":"2021-11-18 09:00:00 +0900","categories":["note"],"headline":"前向きな性格それ自体には価値はないと思う。そもそも、それはとても一方的な評価だから。"},{"name":"2021-10-29-legacy-system","content":"$30","description":"システムの悪さが認識されるのは、いつも人あるいは人々が壊れた後である。 / ＩＴ業界で聞く『レガシーシステム』とはなにかのお話です。今回から「となりのプログラマー」にシリーズ名が変わりました。前回のＣＴＯ１年振り返りからの続編でもあります。…","prevId":"2021-11-18-ask-possibility","nextId":"2021-10-05-startup-cto-retro","layout":"post","title":"レガシーシステム","author":"Keisuke Yamamoto","date":"2021-10-29 09:00:00 +0900","categories":["note"],"headline":"システムの悪さが認識されるのは、いつも人あるいは人々が壊れた後である。"},{"name":"2021-10-05-startup-cto-retro","content":"$31","description":"何を話すかよりも、誰に話すかをまちがえてはいけない。独り言をいうにしてもだ。 / 2020年9月からBEAMINGのCTOとして働き始めて、1年が過ぎましたので振り返りをしようと思います。ちょうど大きなイベント「MUSERフェス」も終わりました。…","prevId":"2021-10-29-legacy-system","nextId":"2021-08-29-refactoring","layout":"post","title":"CTO１年振り返り","author":"Keisuke Yamamoto","date":"2021-10-05 09:00:00 +0900","categories":["note"],"headline":"何を話すかよりも、誰に話すかをまちがえてはいけない。独り言をいうにしてもだ。"},{"name":"2021-08-29-refactoring","content":"$32","description":"においの出どころを探し当てるのが困難なことは承知しているはずだ。 / こんにちは。『リファクタリング』についてお話しします。リファクタリングそのものの定義より、『リファクタリング』が聞こえてきたときに感じとるべきことについてお話しします。…","prevId":"2021-10-05-startup-cto-retro","nextId":"2021-08-09-waterfall","layout":"post","title":"リファクタリング","author":"Keisuke Yamamoto","date":"2021-08-29 09:00:00 +0900","categories":["note"],"headline":"においの出どころを探し当てるのが困難なことは承知しているはずだ。"},{"name":"2021-08-09-waterfall","content":"$33","description":"心構えの問題を仰々しく言う必要はないかもしれない、反面でときに仰々しさも必要かもしれない。 / 『ウォーターフォール』は開発手法の一つです。ウォーターフォール型の開発、などのように総称としても使われます。…","prevId":"2021-08-29-refactoring","nextId":"2021-07-26-the-bugs","layout":"post","title":"ウォーターフォール","author":"Keisuke Yamamoto","date":"2021-08-09 09:00:00 +0900","categories":["note"],"headline":"心構えの問題を仰々しく言う必要はないかもしれない、反面でときに仰々しさも必要かもしれない。"},{"name":"2021-07-26-the-bugs","content":"$34","description":"賭けを楽しむように推測を言い放つのは行儀が悪い。 / 『バグ』はすでにじゅうぶんに一般化している用語ですね。「不具合」のことです。「不具合という現象」を指して用いられることが多いと思いますが、それの「原因」を指しているときもあります。…","prevId":"2021-08-09-waterfall","nextId":"2021-07-03-static-vs-dynamic","layout":"post","title":"バグ","author":"Keisuke Yamamoto","date":"2021-07-26 09:00:00 +0900","categories":["note"],"headline":"賭けを楽しむように推測を言い放つのは行儀が悪い。"},{"name":"2021-07-03-static-vs-dynamic","content":"$35","description":"「ちょっと」とか「簡単に」とか、なぜ付け足して言ってしまうのだろうか。 / Webサイトを作っていて、ここは『静的』な部分・ここは『動的』な部分、のよう使われます。『静的』は \"Static\" の訳語・『動的』は \"Dynamic\" の訳語と思います。…","prevId":"2021-07-26-the-bugs","nextId":"2021-06-18-yagni","layout":"post","title":"静的と動的","author":"Keisuke Yamamoto","date":"2021-07-03 09:00:00 +0900","categories":["note"],"headline":"「ちょっと」とか「簡単に」とか、なぜ付け足して言ってしまうのだろうか。"},{"name":"2021-06-18-yagni","content":"$36","description":"発端が善意なのは分かっているが、残念ながらいまそれは余計な事だと思う。 / YAGNI はヤグニで You aren't gonna need it で『**たぶんそれ要らなくね？**』です。…","prevId":"2021-07-03-static-vs-dynamic","nextId":"2021-05-09-throw-exception","layout":"post","title":"YAGNI―それ要らなくね？","author":"Keisuke Yamamoto","date":"2021-06-18 09:00:00 +0900","categories":["note"],"headline":"発端が善意なのは分かっているが、残念ながらいまそれは余計な事だと思う。"},{"name":"2021-05-09-throw-exception","content":"$37","description":"「何でも相談して」と言ってくる人は何でも相談できる人と違う / 『フラグを立てる』はもともとプログラミングで使われる用語です。ご存じのとおりです。「フラグの回収」は違って、これは「伏線の回収」とどこかで混じったものでしょう。…","prevId":"2021-06-18-yagni","nextId":null,"layout":"post","title":"例外を投げる","author":"Keisuke Yamamoto","date":"2021-05-09 09:00:00 +0900","categories":["note"],"headline":"「何でも相談して」と言ってくる人は何でも相談できる人と違う"}],"children":"$L38"}],"$L39"]}]}]

魔法のチョークで描いた窓