技術的負債を放置した組織で何が起きるか
正直に書いておきたいことがある。
誰かが読んで「あ、うちだけじゃないんだ」と少し気が楽になるなら、それだけで十分だと思っている。
「いつか直す」の行き先
技術的負債という言葉がある。コードの問題として語られることが多いけど、自分が経験してきた中で感じたのは、放置された負債が最終的に壊すのはコードじゃなくて、人と組織のほうだった。
「今は優先度が低い」「次のフェーズで対応する」「来期に向けて検討する」。
こういう言葉が積み重なると、やがてエンジニアの中に"どうせ"という感覚が生まれてくる。自分もそうだったし、周りもそうだった。
改善提案が通らない、を繰り返すと何が起きるか
提案する。理由を説明する。資料を作る。
それでも「今は難しい」で終わる。
最初は「もう少し説得力のある資料にすれば通るかもしれない」と思う。次は「タイミングが悪かっただけかも」と思う。さらに次は「伝え方が悪いのかも」と思う。
でもある時点で気づく。問題は説明の質でも、タイミングでも、伝え方でもなかった、と。
構造的に、改善に対してGoが出ない仕組みになっていたんだ、と。
善意と努力が「安さ」に変換される話
ここが一番書きたかった部分かもしれない。
エンジニアや現場のメンバーは、それぞれ誠実に働いている。バグがあれば残業してでも直す。属人化していても、なんとか引き継げるように資料を作ろうとする。品質に不安を感じながらも、自分なりに確認を増やす。
ところがこの善意と努力が、ある種の**「取引コストの安さ」**として機能し始めてしまう。
「あの人が頑張ってくれているから、今の体制でもなんとかなる」という状態が生まれる。改善投資をしなくても回っているように見える。問題が表面化しにくくなる。その結果、構造的な改善をするインセンティブが、意思決定する側に生まれない。
個人の努力が、改善を先送りにする根拠として静かに使われていく。
本人はそんなつもりはないし、使っている側も意図していない場合が多い。でも構造的にそうなる。
現場で感じる感覚としては、**「頑張っているのに、頑張ることで状況が変わらなくなっている」**という閉塞感に近い。
誰が辞めるか
優秀な人から辞めていく、とよく言われる。
自分が見てきた感じでは少し違って、「このままでは良くならないと早めに気づいた人」から辞めていく、という方が正確な気がする。
その人たちが辞めると、残ったメンバーへの負荷が上がる。負荷が上がると、改善のための時間がさらになくなる。改善の時間がないので、技術的負債は積み上がる。積み上がると、また誰かが「もう限界だ」と感じる。
この繰り返しを、傍で見ながら何ができるかを考え続けてきた2年間だった。
構造に名前をつけると少し楽になる
モヤモヤしているうちは「自分がうまくやれていないからか」と感じることもある。
そういうときに助けになったのが、『エンジニアリング組織論への招待』（技術評論社）だった。
この本が一貫して問うのは、「どうすれば不確実性を効率よく減らせるか」という視点だ。技術的負債も、経営とエンジニア間のすれ違いも、突き詰めると情報の非対称性と、不確実性への向き合い方の失敗として整理されている。
読んでいて腑に落ちたのは、「問題はコードじゃなくて、思考・組織・ビジネスの構造にある」というメッセージだった。自分が感じていたモヤモヤに、ちゃんと言葉が与えられた感覚があった。
「これは個人の問題じゃなくて、インセンティブ設計と組織構造の問題だ」と言語化できると、少し楽になる。誰かを責める話じゃなくて、仕組みがそうなっている、という話として見られるようになる。
おわりに
この記事を書いたのは、反省でも批判でもない。
同じ状況で「自分の力不足なのかな」とか「自分がもっとうまくやれば変わるのかな」と思っている人が、「あ、そういう構造の話だったんだ」と少しでも思えたら、それだけで十分だ。
少しでも前向きな感情に変わることを願います。
48歳になって思うこと
現職について
お金を稼ぐ手段であって、人生の大半を過ごすことになる働く時間。
ワクワクしていたいし、悔しいと思うことがあっても、次に頑張ろうと思えるようになりたい。
2023年の年末からは色々周囲に起きすぎて、思い通りにならないし、嫌な方向に流れているような気がしたとしても、方向転換させる事が出来ない自分がいてて、不満が溜まってしまってたと感じている。それを周囲にあたってしまっている自分も嫌いになりそうな感じもする。
- 人事面で予想外の異動があって、社内に不満が溜まったが、個人的には正直新しい事ができる事もあったし、余裕ができる部分があって、ほっとした
- 移転に関しては、悪いイメージしかないが、それに関しても会社にとっては費用がかからない形で、あの人数が出社可能な場所を確保するための決断である
- 出社の見直しに関しても、管理する側にとっては、会話するタイミングが取りやすいことは仕事を進めやすくなりストレスは減る
こう書き出してみると、良いことばかりに思えるが、何故か不満が増えてしまっている。やはり離職が大量に出てしまった事が、自分にとっては、ショックだったんだと感じている。これからも何人か出てくるであろう。そして、経営者もこういった事を何度か繰り返して、会社を成長させており、それが成功体験になっていると思われる。そこが悲しいし、不満になってる部分である。
過去の社会人経験を振り返っていると、ますます「新卒で入社した時の会社の雰囲気」に似てきている。その時は、「部署の責任者」がいたのだが、その方は、なんでこんなに簡単に退職するのだ？って思ったけど、自分の人生であり、自分で決めていく権利があると思う。経営陣と方向性が合わなかったのだろう。
転職して、最初の年は製品を理解する事、その時も大量に転職者がいたので、キャッチアップを進めてもらうために、資料を作成して、転職して半年で教育も担当した。その後は、顧客との関係性構築の改善のための業務も任せてもらった（この時から手のひらで踊らされていたように感じてしまう）。その後は、顧客担当部署の責任者になったが、トラブル・トラブルの連続だったが、若い方達に支えられたのと、これまでのそれなりの経験で乗り越える事が出来た。ただ、製品自体の質であったり、開発の体制であったりに対しては、常に不満を感じてしまっていた。開発部署にとっても「過去にこん形で開発してきたから、自分たちにはわからない。これから新しい製品を開発する。」みたいな感じの論調だったと思う。ただ、今の時点でも新製品は良い形になっておらず、何かリリースする度に問題は起きている。何故、こんな事が繰り返されるのか？
- 製品の目的ははっきりしているか？
- 製品の最低限の品質を高めるための最低限の試験を実施しているか？
- ある程度枯れた技術を使って、開発を実施しているか？
これから会社を「立て直す」のではなく、「崩壊しない」事に、再度3年使う事になることを想像すると、時間を無駄にするような感覚におちいる。
ただ、諦めずに何を優先的に取り組めば良いかをしっかり考えることは自分にもできる。（今年は疲れてて、やる気がそがれていたけど、前向きにはなってきたかも）
- 受注分を問題なくこなす
- 各作業の目的をはっきりして、優先度づけをメンバーにも示す
- 他部署でボトルネックになってる部分を上長と相談して、3ヶ月先の対策をたてる
１つ目はメンバーに徹底してもらうことなので、口をすっぱくして日々の行動の認識・優先度をあわせていきたい（プロジェクト管理しているメンバーとスケジュールだてはきっちり出来ているかのこと）
2番目に関しては、かなり会社は危機的な状況な事を伝えて、年配のメンバー・発散しがちなメンバーに集中してもらう。１つでも炎上すると被害が広がりまくる。
３つ目は退職者が続いている部署の立て直しをどうするかを正直に話していかないと、結局はストレスが溜まる状況が続く事になる。
claudeに業務の相談したら、一番優先して取り組むべきは、「過去の所属部署の業務」をどうにかすべきとの結論でした。それが一番ストレスになるとの事で、回答があった時に、しっかり壁打ち相手になってくれると感じた。もう2年ぐらい過去の部署の仕事を実施している事をどうにかしないといけない。
年末から年明けに向けて、解消していこうと思う。
力を抜いた年始の誓い
あまり、これ！って言う目標を立てて生活する事をしたくないです。結局人生ってなにが起きるか分からないしね。だから日々淡々と過ごす事を大切にしてきたよーに思います。
ですが、こうなりたい！って言うのはあるかも。
『部長になりたい』は無いけど、
『こういうチームのリーダーにはなりたい』とか。
『年収を○○もらいたい！』は無いけど、
『せめてこれぐらいは年収欲しい』とか。
書いていて考えると好き嫌いがはっきりしてなくて、なんとなく生きてきた感じがします。『それなりに』は満足できてなかったし、それを変えようと思うと、思いが強くないと変わらないよなぁ。
新しい環境で、それなりに出来てきてる感じがするけど、何を実現したいかをもっと具体的にしないといけない。やりたいことの方針は立てれてるので、具体的に深く考えて、日々の行動に落としこめることを目指す。
年末年始に色々あって、書けてなかったけど年始に思ってた事を公開しよう。
何かを人に依頼するときは、本当に気をつけて依頼しないといけないな。大事な時間を使ってもらう事だし、相手のこれまでの大事な経験を使うことになるので。そういう考え方を持ってる人と一緒に仕事をしたい。部下だからとかで、自分優先で考える人間とは一緒に仕事して、結果を出せても喜べない。それに今回は、その人にそう感じてたいたのに、進めようとしてしまってた。最初にそう感じた時点でやめるべきだったし、そのおかげで大事な方の時間も気持ちも無駄にしてしもたしなぁ。
無駄に年齢だけ重ねてきたと感じてモヤッと感が多すぎる年始やわ。なんとか仲間を増やしていきたい。半年後には幸せな気分でいたいな。
この一年の終わりに
気がついたら新しい環境で２ヶ月経ってます。なんやかんやと激動の２ヶ月だったと感じております。何が激動って、新しい仕事を覚える事よりも、新しい人との出会いが激動です。学生の時はクラス替えがあったりで新しい人と出会うことがあるけれど、社会人でIT関係の場合に、転職以上の人間関係の変化って無いです。プロジェクトが変わってとかもあるかもしれないけど、上司やメンバーが総入れ替えって！しかもお客様も！
前職ではラッキーな事に色々な方達と過ごす機会に恵まれたので、本当に良かったです。凄くコミュニケーションが取りにくい方や、天然の人や、明らかに悪意があってさぼる人、逆に本当に優秀過ぎる若手とか。友達が多い方では無いけれど、色んな人に仕事で出会えて良かったなあ。
これまで色々な縁に恵まれてきたと感じています。
・家族
・学生時代の友達
・結婚
・就職
・とんでもなく著名な方（の会社の方達も！）
・優秀な同僚
・イラっとさせられる同僚
・先輩、後輩
・反感、批判をしてくれる人
思い出すと色々出てくるなぁ。
今回、転職して新しい出会いが一杯ありました。
今、感じている事は、
・誠意を持って接する事
・感情的にならずにこちらの要望を伝える事
・感謝する事
がむちゃくちゃ大事だと言うことです。
前職のメンバーと先月末に飲みに行ったときにつくづく感じました。家に帰ってから奥さんに、「そらぁー、腹割って話できるし、楽しかったやろー」って言われました。やっぱり優位な立場にあった分、相手に気を使われてる事を意識して接する必要があるなと感じました。また来年メンバー増やして飲みにいくのが楽しみ。
そして今年できた新しい縁も大事にして行きたい！
ハロウィンなんか関係ない
これまでハロウィンとか体験する事も無かったし、今年も何も体験する事がなかった。仮装にはまったく興味は湧かないなぁ～。USJで流行りだしてからでも、行くような感じじゃなかったしなぁー。もう2年ぐらいして、子供ももう少し大きくなったら、一緒に行ったりするのかなー。
急に寒くなってきたけど体調を壊さずに過ごす事が出来てる。新しい環境で、手探りなところがあるけど、年の功と言うか、経験年数のおかけで、なんとか過ごせてる感じがする。入社前後であまりイメージが変わらなかったのも良かった。良いところと悪いところのイメージが両方あったけど、大体イメージ通り。ただ、課題をどう改善していくかは、人間力と技術力が必要に感じている。
まだまだ足りてないと感じることが多かった人間力。『軽い感じで声をかける』、『相手が嫌がることを嫌み無く伝える』、『イラっとしてるところを見せずに、うまく伝える』って言うあたりがやっぱり出来ないと感じた。相手に勢い良く、思い込みで喋られると駄目なんやなー。なるべくそう言う相手とは会話を避けるべきやなー。そうじゃないと関係性が悪くなる。。。そう言う形にはしたくない。
技術力に関しては、要件聞いて、カスタマイズして、導入して、運用して、保守して、バージョンアップしての一通りのライフサイクルを回す事に関する技術が試されてるよなー。前段の開発・導入は力になれそうな気がしてるけど、運用・バージョンアップのところがイメージがわかへん。そのあたりのサイクルを回せるようにサービス設計に貢献できたらええな。ほんまにソフトウェアは面白い、組織のコミュニケーションも考えるし、使うソフトの目利き力も必要やし、突破していく力がものすごく大事やし、やりがいがあるなぁ。
先月は、一旦慣れるのに精一杯になってしまったし、少し立ち止まって考えよう。おかげさまで、そう言う事を考える事を許して貰えるポジションだし。
まずは、年内のイメージから。
チームに資料作成・共有の流れを作りたいのと、主要アラートを減らして、前向きになれるチームの雰囲気にしたいな。ほんまに減らせられたやん！的な。
来年の上期はチームのバランスを考える事かな～。そこは全社的な能力バランスとか、後は下期に導入を目指す技術をチームで習得とか。コミュニケーションが向上できたところで、継続的デリバリーに持っていけるなら行きたいなぁ～。
次に三年後。やっぱり前職で出来てなかった、ソフトウェアの技術を使ってお客さんに、本当にインパクトがある製品を継続して提供出来るチームにしていたいなー。ヒヤヒヤはするけど、ほぼ安定運用していて、そこから2年後ぐらいのロードマップもあって、そしてたまに発生する障害も頻度が凄く低いとか。そして余裕もあるから、継続して学習時間がとれてる事。そんな組織にしたいなー。
そして10年後は？
技術を楽しんで、基礎学力である数学的な知識や、情報系の知識を身につけて、それを伝える仕事をしていたいな。それが今の会社のお客さん相手でもいいやろうし、現職で新しく知り合った関係の人でも良いし。そう言う下地がある人が多そうで良かった。やっぱり学習する組織で、学習する仲間と関係を続けたい。
もやっとしてるけど、昔よりははっきりしてきたかも。日々少しでも達成感を持って過ごそう。
台風とともに
今年も印象に残る災害がいくつか起きた。特に台風の被害が大きく、また事前にJRが止まると言うイメージが出来上がった年でもあったと思う。何をするにしても余裕を持ってやる事は良い事だと思う。起きてからだと遅いのだ。
9月末で（一応）約18年間近く勤めた会社を退職した。退職するまでに社名が4つ変わった。新卒で入った時にはこんな事になるとは想像してなかったし、『どうしたい』って事も無かったように思う。それなりに一生懸命働いて来たけれど、どう言う事がしたいって事は無かったように思う。ただ、場面ごとにはやりたい事を選択できてきたので、あまり後悔は無い（こうすれば良かったなぁ〜と言う気持ちはあるが）。
今はScalaをやり始めて、更にそれとは別に小学校の算数から数学を再勉強してて、遂には大学レベルの数学に入門し始める事が出来ている。昔は個人的にアプリ作って、Webシステム作って（Google App Engine）とかやってみたけど、どれも中途半端だと感じていた。そんな中、昔やりかけで終わったアセンブリ言語を勉強し直した。この『再勉強』が転機だったのかもしれない。『なんとなく分かった』レベルをなんとかしたくて、実際に環境を作って、手で入力して、学んだ事を簡単にまとめてって言うのを繰り返すようになった気がする。アセンブリを個人的に再勉強する事が出来て、仕事では死ぬほどSQL（Oracleだけど）とExcelを見て、データも一杯見て、Javaを少しだけ見てた状態から、あるWebのブログでScalaに出会い、勉強をしようと言う意欲を持つ事ができた。きっかけとなったブログに本当に感謝したい。Scalaを始めて3年以上経ったけど、本当にまだまだ未熟だ。。。と言うよりもそもそもデータ構造とアルゴリズムにも詳しく無くて、その辺りも学んでいたのだけど、ようやくAtCoderのABCのABは簡単に解けるようになってきた。これからC問題に取り組んでいきたい。『しっかり身についた知識』が無いと解けない問題があるので、ここもしっかり体に染み込ませて行きたい。
今日から新しい職場に出勤した。直近の約9年間とは異なり、10年近く前の状態の職場の雰囲気を感じた。『”課題”が組織をどのような形で維持するか？』ではなく、今日出勤して聞いた状況では、『ソフトウェアで解決可能な課題を、自分たちはどう会社として取り組むか？』であった。世の中に受け入れられている企業なので、お互いに学び、日々充実した生活を継続できるような組織になるように貢献できればと思う。
10年後どうしたいかを聞かれたのは唐突だったけど、技術を突き詰めたいか、管理職かと聞かれて、少し返答に困ったけど、管理職と答えた。前職では技術と答えていたのだが、前職の管理職の意味合いは『経営者（営業サイド）』的な意味合いが強かったので苦手意識があったのかもしれない。良い事業内容があって、企業としてもスケールする段階で、それなりの経験を重ねて来た自分にとって、メンバー間の調整と言う役割が役に立ちそうに感じているので、真摯に取り組みたいと思う。残り30年の人生の3分の1ぐらいはかける事になるだろう。
60歳の方の定年退職エントリーがあったけど、心からカッコいいと思った。自分には到底及ばないキャリアだけれども、60歳になっても学ぶ姿勢だけは真似したい。その年齢になるまで、新しい会社でも技術的に尖ったメンバーと長く働く事が出来ればと思う。
これだけ前向きになれる機会を貰えて自分はラッキーだ。
夏休みの宿題の残り
今年のお盆もなんだかんだとゆっくり休めました。休み中には子供とプールに行ったり、ゲームしたり、ポケモンGOしたりと普段の生活を楽しんだ感じです。今年は先々月に旅行も行けたので満足できた夏を過ごせました。
旅行前に割と大きな決断をしたのですが、その事が頭から離れない状態がしばらく続きました。悩んでも結局は答えを出していたので、結論は変わらないのですが、やっぱり切り替えはムズカシイと感じたものです。来月はこの事を振り返って買い手みよう。
そんなこんなで悩んでた答えを求めてお盆前に書籍を買って、子供と遊ぶ合間に読んでました。
Effective DevOps ―4本柱による持続可能な組織文化の育て方
1. 読もうと考えた動機
今の会社にいて、今の案件に携わっていて、なんとか解決策が無いか模索しているような感じ。『保守』として案件に携わっていて、業務内容の曖昧さにいつも迷っていたように思う。完全にバッチ処理なので、『使いやすさ』、『見た目』とか『広く一般的に受け入れらる』とか『モダンな』とかの要素が全く無かった。ただ単に速さ・正確性が求められていたように思う。ただし、『数字』を扱うシステムなので、その数値をどんな軸で見せるかと言うのは大事だったと思う。『窓口・営業・企画』や『基盤・運用』は別”組織”がやっていた。自分達は”上流工程”から流れてくる仕事を、うまくこなして、流れに乗せていたような感覚である。そんな中、たまたま本書の紹介を見かけたので、まとまった時間が取れそうだったので読んだ。あとで書くけど、”組織”や”上流工程”に対する課題に関して、解決可能な範囲は決まっていると感じた。読んでみて、凄く納得できる部分もあったし、参考になる部分もあった。但し、但し書きがあるような感じ。
2. DevOpsって
海外で始まった文化的な運動。まとめてくれてる資料はこちらです！これを読んで読んで見よって背中を押されたかも。
私は誤解なく書籍を購入したのだけど、DevOpsって言う単語だけで捉えると、”開発チームと運用チームの協力で色々自動化する事”や”ツールで自動化”みたいなイメージが先行してしまうと思う。（どう効率化するかを考えていて、DevOpsに興味を持ったのが元々の動機ですし）
この書籍に書いてある内容は、人間関係の大事な部分や、組織をどう作っていくかのところに力点が置かれており、ケーススタディ的な書き方がされている。特にIT系で花形と思われている開発側からの視点ではなく、運用やサポートチームからの視点が多い。
最初に説かれているのは、コラボレーションである。同じ目標に向かって、チーム内で協力しあって仕事を進める姿勢である。固定思考と成長思考の違いや、どう言った仕事の進め方がチームに影響を与えられるかが記述されている。特に自分に響いたのは、『感謝の表明』である。いつだったか忘れたけど、妻の母が私の事に対して、『あまりありがとうって言わへんよね』って言ってた事を聞いた。とりあえず感謝の気持ちがあったので、それ以来普通に言葉に出して、感謝の気持ちを普段から伝えるようになった。周囲にちゃんと伝わってるかどうかは自信は無いが、心がけているつもりだ。
次にアフィニティ（好み、相性とかの事？コラボレーションとの違いがイマイチピント来てません）。どちらかと言うと個人より、チーム間の関係に関して述べられている。このあたりは、昔父親と仕事について会話していた時に、「営業が仕事取って来なかったら、仕事無くなるやろ」って言われた言葉が重い。めったに父親とは仕事の話とかしなかったけど、これだけは強烈に覚えている。それ以来、”営業”と言う言葉に対する偏見は無くなったように思う。お互い一生懸命仕事してるよね。ちゃんとこっちから伝えれば、わかってくれる部分もあるよね。両輪やよねって思いが強い。それの開発と運用チーム版みたいな感じの事が書かれている。
あと、ツールとスケーリングについても書かれているけど、良かったら書籍を読んでください。
3. 感想文
書かれている事はもっともだし、解決できる課題も多いだろう。でも今自分が直面している課題に対しては、以下の部分が一番しっくり来た感じがした。
~ 黄金の手錠 ~
『すべてのチームや組織がすべての人に合うとは限らない。devopsやあなたが大切に思うその他のことを誰もが大切にしてくれるわけでもない。自分に合った新しい場所を見つけることがベストだという場合もあるのだ。』
ある程度経験を積んで、ある程度仕事をこなせるようになって、更に求められるようになっているけど、仕事って何か課題を解決した事に対する対価だったりと考えている。これまでしてきた開発だったり、調査だったり、Excelでのデータ整形も出し、進捗管理も、『誰かができない事』を助けてきていたように思う。現状は、既に自分じゃ無い誰かが出来るようになりかけているのに、”会社”の維持のために自分が居るような状況になっていたし、ビジネスモデルがそんなモデルだったんだよね昔から。そう言う文化が好きになれなくて、我慢もできなくて、違う”組織”で喜んで出来る事があるなら、そっちを取るべきだ。もちろん責任も伴うだろうけど、その緊張感も愉しめるなら本当に良い選択だと思う。
あとやっぱり契約関係については曖昧にするんじゃなくて、そこはきっちり周知していく必要があるんやな。っと思ったし、世の中そう言う流れも出て来ていると思う。
そういえば高校数学の学び直しがもう少しで終わりそうだ。これが終わったら更に深みにはまりたい。
