仕事のモヤモヤをAIに壁打ち（相談）してみたら、ずっと現場で感じていた違和感の正体がびっくりするほどクリアに整理された。

​開発が遅れそうになると、生産技術からは「設備が作れない」とプレッシャーを受け、事業部からは「顧客が待っている」と詰められる。

追いつめられた極限状態のプレッシャー下で良いアウトプットなんて出せるわけがない、とAIに愚痴をこぼしたのがスタートだった。

​対話を進める中で、ハッとさせられる発見がいくつもあった。

​まず、「合意形成ばかりの職場は嫌いだ、良いものが作れない」という私の感覚。

AIと議論する中で、全員が納得する「丸い合意」を追求すると、

尖った価値や熱量が削ぎ落とされた無難な代物しか生まれないのだと確信に変わった。

妥協のないものを作るには、全員の顔色を伺う合意ではなく、強烈な意志と突破力が必要なのだ。

​さらに根深い構造についても意見を交わした。

形だけの「早期巻き込み（コンカレント・エンジニアリング）」は、

外部委託メインの生技が口だけ出して不具合の責任は取らないという地獄を生むこと。

そして何より、うちの現場で一番の害になっている

「定年待ちの年配生技が、年下リーダーのもとで影のボスとして君臨している」

という実態。

​AIに客観的な視点を入れてもらったおかげで、これは現場の人間関係の問題ではなく、

「誰の下で、どんな目標に向かって動いているか」

という組織構造の欠陥なのだと理解できた。

​解決策はシンプルだ。

開発も生技も同じ単一のトップ下に置く「タスクフォース型」に改めること。

そして、変化を拒むベテランは思い切ってラインから外し、

アドバイザー的な位置に隔離すること。

​一人で抱え込んでいた

「現場の理不尽なストレス」が、

AIとの対話を通して

「解決すべき組織の構造問題」

としてスッキリと言語化された。　

この学びと気づき、

実行はまだ先かもしれない。

いつか私がチームを動かすとき、

少しずつ活かしていきたい。

最近、仕事をしながらずっと感じていたことがある。 

私の所属する開発部門では、製品開発以外にもさまざまな業務を担当している。

 •サプライヤ選定 

•試験方法の検討

 •試験手順作成

 •検査手順作成

 •検査治具設計

 •生産設備の組立方法検討

 •組立検証

 •滅菌バリデーションの段取り

これらの実作業をやっているわけではない、インプットとスケジュール管理だ。

つまり、実作業以外、をやっている。

こう考えると

ものの機能や形を決める　

以外のことにずいぶん時間を使っている。気がする。

開発という言葉がどこまでを含むのか、も正直曖昧だ。

 そ
「こんなにいろいろやっていたら、本来の製品の形を決めること（私が認識している開発）に集中できないのではないか」
という疑問を持った。

AIに相談した。

結論としては、

 一番大変なのは調整

という点にしっくりきた。

 設計そのものではない。

 •サンプルは間に合うか

 •試験日程は確保できているか

 •治具は完成するか

 •滅菌業者の予定はどうか

 •次の工程にいつ引き渡せるか 

こうした確認や調整に多くの時間を使っている。 

そして試験で不具合が出れば、
•何が原因か

 •再試験はいつか

 •スケジュールへの影響はどれくらいか 

を考えなければならない。

気が付けば設計者でありながら、プロジェクト全体の交通整理役も担っている。

加えて、思ったことがある。

 責任は誰にあるのか
さらに考えていて難しいと感じたのが「責任」の問題だった。

 例えば試験で不合格になった場合。

 原因解析や対策立案は開発の責任だと思う。

 しかし、

 •サンプル準備

 •試験実施

 •業者との調整

 •スケジュール管理 

まで含めて考えたとき、本当に開発だけの責任なのだろうか。

 現実には複数の部門が関わっている。

 ところが結果として、

 「開発案件が遅れた」
という話になると、責任が開発部門へ集まりやすい。

 そこで気付いた。

 実行責任と結果責任が混ざっているのではないかと。 

さらに難しいのは組織の力学
理想的には部門ごとに役割は決まっている。

しかし実際の職場は単純ではない。

部門間の力関係や担当者の年齢、性格によって、本来の分担が崩れることがあると思う。

本来はプロジェクト全体で対応すべき問題なのに、
いつの間にか特定の部門への追及に変わる。

「開発の精度を上げる」という違和感
こうして考えていくと、問題が起きたときによく聞く
「開発の精度を上げよう」
という言葉に違和感を覚えるようになった。

もちろん設計品質を向上させることは重要である。
しかし本当にそれだけなのだろうか。

例えば、
•スケジュールが過密だった
•情報共有が不十分だった
•サンプル手配の仕組みが弱かった
•リスクの見える化ができていなかった

としたら、

それは開発者個人の問題ではない。
仕組みの問題なのではないか。

AIに相談すると以下の言葉が返ってきた。
人ではなく、仕組みを疑う

今回の気付きはシンプルだった。
問題が起きたとき、
「誰が悪かったのか」
を考えるより、
「この結果を生んだ仕組みは何だったのか」
を考えたい。

開発が忙しいのは、能力不足だからではないかもしれない。
不具合が発生するのも、設計の精度だけの問題ではないかもしれない。
本当の課題は、組織やプロジェクト運営の仕組みの中にあるかもしれない。

最近は、
「開発の精度を上げる」
という視点より、
「システム上の問題点を探す」
という視点の方がしっくりくる。

個人を改善することも大切。
しかしそれ以上に、問題を生み出している仕組みを改善することが、強い組織への近道なのではないだろうか。

自分の正当化なのかもしれない。

しかし、少なくとも自己の反省もしながらこのように考えるは正しい気がする。

そんな毎日を過ごしているうちに、ふと思ったことがある。

「みんな、こんなにいろいろなことを本当に管理できているの？」

仕事だけでも覚えることはたくさんある。それに加えて家庭、将来の計画まで考えていると、頭の中が常に何かで埋まっている感覚になる。

何かをしていても、頭の片隅では別のことを考えている。

「明日の仕事は大丈夫かな」

 「そういえばあの件、まだ終わってなかったな」

そんな感じで、一日中頭の中でいろいろなタスクが行き来している。

単純にやることが多いからなのか。

具体的に何を考えているのか、改めて考えてみた。

「そういえばあのメール返信していなかったな」

 「次の打ち合わせまでに資料を見ておこう」 

こんな感じだろうか。

ここで気づいたことがある。

疲れているのは作業そのものじゃなくて、「覚えておこう」としていることだ。

仕事の予定、やるべきタスク、家庭のこと。

気づけば頭の中だけで管理しようとしていた。

そこで少し調べてみると、人間の記憶やスケジュール管理能力には限界があって、優秀な人ほど全部を覚えようとはしないらしい。

確かに自分も忙しいときほど、

「あとでメモしよう」

「あとでカレンダーに入れよう」

と後回しにしていた。

でも、それが頭の中の負担を増やしていたのかもしれない。

頭は保存する場所じゃなくて、考える場所。

そう考えると、毎日頭がフル回転なのは能力不足ではなく、覚えようとしすぎていたからなのかなと思った。

これからは記憶することより、記録することを意識していこうと思う。

有効かどうかは分からない。続けられるかも分からない。

でも忙しい今の自分には、その方が合っている気がする。