今日は神保町から秋葉原を目指して歩いています。
途中のビルでイベントの準備が行われていました。
フツーに音楽イベントなども出来るようになってうれしい限りです。
右に行くか、左に行くか？
今日は八王子に来ています。
ここは中央線と横浜線の乗換駅で、普段この駅で降りることはほとんど無いのですが、駅の周りを散歩してみようかと思い、改札を出ました。
改札を出て「右に行くか？」「左に行くか？」迷うところ。
まずは「ビックカメラ」もある左側へ。
ちょっと歩くと「スタバ」があって、散歩の前に入ってみます。
何を食べるかはいつも迷いますが、今日はドーナツで。
「アールグレイミルククリームドーナツ」は生地の中にクリームが入っていて、クリームも一緒にたべるとちょっと味に変化が出ておもしろい。
本を読みながら過ごしていると、雨が降ってきました。
スタバに入っていなければ、歩いている途中で雨に降られたのかな。
結局、散歩は諦めて改札口に向かいます。
あとで調べてみると、駅を挟んで両側にスタバはあったみたい。
改札出てからどちらに行っても、結局は同じだったかも。
技術的負債がもたらすもの
離職者が減らない？
先日とある会社で開発部門の年度目標を聞く機会があったのだが、その話の中で前年度の課題についても聞くことができた。
いくつか挙げられていたが、その中のひとつに「離職者が減らない」という項目があって目を引きました。
会社の業績が悪いというのも理由のひとつだとは思うのだが、もっと大きな理由として、「技術的負債」とその管理のまずさからくる「閉塞感」が原因なのではないかと感じることがある。
技術的負債
技術的負債というのはソフトウェア開発の文脈で良く使われ、「効果的なソリューションではなく簡単なソリューションを選ぶことで後々発生する追加のコスト」なんて説明されることが多いけど、簡単に言えば「変なやり方してるよな」とか、「何でこうしたんだっけ？」みたいな理由が判らず解析しづらくなってしまったソースコードなどは技術的負債を生じていて、不具合対策時の調査や修正のための分析時に多くのコストを生じさせている。
ソフトウェア開発でよく使われるけど、ハードウェアにも当てはまることは多くて、部品の定数を決めた根拠が判らなくなっていたり、そもそも何でこの回路が必要なのか？といったこともあったりする。
技術的な面だけで考えれば少しづつでも解消してゆけば良いのだけれど、解消できるかどうかは技術だけで解決しないことがあって物事を複雑にする。
技術的負債は返済困難？
その会社の製品は満たすべき規格が比較的頻繁に変更されるため、ソフトウェアの定期的な更新が必須なのだが、ソースコードを健全な状態に保つ努力をしないまま改造を繰り返したために、改造するにも効率が悪い。
「修正した方がいいよな。。」と感じている技術者も居るのだが、何か問題が出ればコードを修正した人が責められるという雰囲気があって手を付けるのはためらいがち。
修正の提案が出されても、市場で不具合になっていなければ修正は行わないというのが基本スタンス。
技術的な解決方法があったとしても、職場の雰囲気を含めた開発環境が技術的負債の解消を阻んでいることが多いみたい。
何に人は傷つくのか？
技術的負債に対する解決策を持っていても、断念せざるをえない状況の繰り返しが閉塞感につながっているみたい。
「自分が大切にしていることが大切にされなかったとき、人は傷つく」という話をある学者の先生の講演会で聞いたのだが、「良い製品を送り出したい」と考えている技術者にとって、それを諦めて製品のリリースを繰り返すのは、本人の自尊心を傷つけているかもしれない。
技術的負債を適切に管理できずに先送りしていることが離職者が減らない状況につながっているように感じているけれど、飛躍しすぎかな？
