Moo

属人性を仕組みに置き換え、個人の力量に依存しない技術組織をつくる

私がこれまで繰り返してきた仕事は、突き詰めれば一つに収束します。**判断を個人の手元から取り上げ、構造の側へ移す**作業でした。 - 本番で稼働している版の識別を、サーバ上のシンボリックリンクからGitのタグへ - ミドルウェアのバージョン標準を、文書上の取り決めからAnsibleロール内の固定値へ - レビューの規律を、担当者の丁寧さからCIパイプラインの制約へ - UI設計の判断根拠を、個人の感覚から外部の標準とアクセシビリティ要件へ - 非機能要件を、暗黙の期待から経営層と合意した明文へ 対象は変わっても、解き方は同じでした。規律に依存した取り決めは、担当者の交代や繁忙期に必ず形骸化します。だから、守らない選択肢が存在しない状態をつくる。これが私の一貫した設計思想です。 技術選定でも同じ基準を持っています。クラウドは手段であり、目的ではありません。オンプレミスとの比較を経ていない移行は、判断ではなく追随です。採用する技術も、新しさではなく信頼性で選びます。商用サービスを支える以上、枯れた技術の採用は欠点ではなく要件だと考えています。 一方で、仕組みは運用の実態に耐えなければ意味を持ちません。たとえば権限設計を締め上げすぎると、運用側は必ず回避策を編み出します。仕組みで縛るのであれば、不便を吸い上げる経路を同時に用意しなければ機能しません。制約と現場の折り合いをつける段階までが設計だと捉えています。 そして、**私自身の課題もここにあります**。 属人性を排除する仕組みをつくり続けながら、私自身は単一障害点であり続けました。複数領域を横断した成果も、未経験の技術領域を短期間で戦力化した実績も、経歴が示すとおりです。しかしこの特性は、組織に「担当を委ねれば回る」との学習を与えます。直近のプロジェクトでは、その構造をリスクとして経営層が判断できる粒度で文書化し、体制変更の判断を引き出しました。ただ、その構造を成立させていた一人が自分である事実も自覚しています。 次に望むのは、**この能力をヒーローとしてではなく、仕組みとして使える環境**です。技術投資の判断が下りる組織で、同水準の技術者と責任を分割しながら、成果物ではなく判断基準を組織へ残す仕事をしたいと考えています。個人の力量に依存しない設計を、システムに対してだけでなく組織に対しても行う姿勢が、当面の目標です。 ### 余談:個人的な背景 - 新潟の原風景と仕事哲学の源泉 ここまでご覧下さりありがとうございます。さいごに、私の原風景からくる、仕事哲学について触れたいと思います。 私は新潟の漁村、網元(船を持ち、乗組員を率いる漁師家系)に生まれ育ちました。家業と家庭を営むために家族全員が明確な役割を持ち、誰かが倒れれば別の誰かが引き受ける。「役割を放棄する」選択肢が存在しない世界でした。営みを止めれば家族全員の明日がない。他の人ができないなら自分がやる。ここが私の当事者意識の源泉であり、同時に、前述したヒーロー的な働き方を助長してきた要因でもあります。