超メモ帳(Web式)@復活

小説書いたり、絵を描いたり、プログラムやったりするブログ。統失プログラマ。


SPONSORED LINK

弊社の技術的負債をどうするか考えている。

f:id:yuki_2021:20200908223920j:plain


今日は会社でミーティングがあったのだけど、こんな事を考えていた。



なんというか、中小企業の開発部なんかにはありがちなんだけど、目の前のタスクに追われていてシステム全体の技術的負債が大きくなってしまっていて、結局、開発コストが大きくなっている。技術的負債ってのはこういう言葉。


ja.wikipedia.org

技術的負債(英: Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。

1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。

最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる[2]。


僕は今、アプリ開発をやってるんだけど、なんせ今までWeb開発しかやってきてない人間が気合いと根性とググり力だけでアプリ開発しているので、ViewControllerなどが肥大化してきており、リファクタリングの必要性を感じている。これも会議で報告したら、直接会社の売り上げにつながらない事に納期はさけない。どうしても直したいなら、自分で時間を作ってなんとかしろとの事でした。


最近入ってきた新人君がこの現場は技術的負債が酷いことを指摘していて、僕も実際現場を見ていてその通りだなと思っている。弊社は中小企業にありがちなレガシーな開発を行っており、コーディングルールも決まっておらずそれぞれの裁量で言われたタスクだけを潰してる。当然のごとく納期が近づくと深夜まで残業になる。最初に開発されたシステムを行き当たりばったりでつぎはぎして増築を行っている状態である。しかも、各システムはそれぞれ一人の担当者にまかせっきりになってる状態で、誰かが辞めれば一発でシステムが止まりかねない「トラックナンバー1」で運用されている。


現代的なチーム開発をかじった人間ならばそういう事をやってるといずれにっちもさっちも行かなくなる破滅的なトラブルが来るとすぐ分かるんだけど、直属の管理職ですらIT知識に乏しく、しかも自分の仕事を変えたくない人間がマネジメントをやっているので、何か新しい管理ツールを提案される事すら嫌がる。以前も、コミュニケーションツールにslackを導入する様に上申したんだけど、現在使ってるIPメッセンジャーで現場が動いているからと却下された。


以前、増田でこのような退職エントリーがあったけど、まさしくこういう中小企業にありがちなレガシーな現場を細かに描き出している。


anond.hatelabo.jp

これは地方の、それもIT気質のあるわけではない、ワンマン経営の中小製造業ならばどこにでもあることかと思われますが、随所に感じるレガシーさに疲れてしまいました。一例を挙げると、毎朝30分に亘り行われる全社清掃(もちろん業務時間外)、社是の復唱、『感謝の言葉をみんなで味わうポエム』の輪読、その感想大会、頻繁に行われる中身のない会議、日報をエクセルで書いてメールで送ったり、出退勤表を毎日エクセルに書いて印刷して事務方に持っていくなどのルーティンがけっこう苦痛でした。

社内のコミュニケーションツールはLINEだったので使い勝手も悪く、会議でchatworkかslackを使いましょうと提案しても誰一人としてそれらの存在を知らず、「勝手にやってくれ」と言われてしまったり。LINE WARKすら知らんやんけ。説明しても「skypeじゃ駄目なの?」と言われたので諦めました。

えらい人の思いつきのたびに方向性が変わり、当人は発言したらそれで全て完了した気になってしまったのか、会議終了後の10分後に「さっき言ったやつまだ出来てないの?」などと言われた時はギャグかと思いました。会議の議事録も誰も見返さないので果たして意味があったのか疑問です。誰かひとりでもmarkdownが書けたり、少なくとも書く気があれば勉強会を開催してHackMDなどを推せたのですが。議事録が機能していないエピソードとしてひとつ思い出しました。開発中に機能追加を下された際に、その挙動は完全にプラットフォームネイティブであり今の技術選定だと作り直しになり、結果納期に間に合わない(し、自分の技術スタックからも遠く外れていたので学習コストも加算)と発言したらその場は収まったのですが、会議終了後に個人メールで「やはり機能はマストだ」と伝えられました。当然それは議事録に反映されることなく、なんかしらんけどそういうことになっているという感じになりました。


まぁ、中小企業の開発部ってどこもこんな感じ。


というか、僕は新卒の時からこの手の中小企業で社内SE兼業のプログラマをずっと続けてきたので、こういう光景を見るのがいつも普通で見慣れている。今回の職場は人間関係が良好な方なので比較的ホワイトである。


まぁ、僕も前職では中間管理職をやってたんだけど、結局、プレイングマネージャーをやって仕事を全部一人で抱え込むとかそういう行動をやってメンタルを壊してしまい、今は障がい者雇用で働いている。こういうレガシーな現場を、カイゼンジャーニーみたいなやり方で変えるってのは死ぬほどエネルギーを使うのであり、よっぽどその会社が好きな愛社精神あふれる人でもないとできないだろう。


自分はこういう現場でどういう立ち回りをするのか考えているんだけど、開発部は若い社員が多いので、現在の状況に問題意識を持ってる子が結構多い。僕がこの開発部では一番年上ぐらいなんだけど、情報共有おじさんになっていままで見てきた現場でのやり方とかを教えてあげる程度に抑えておいた方が良いかな?と思ってるところだ。なんせ、障がい者雇用で非正規で一番下っ端だし、社内政治からはすでにドロップアウトしているし目立ちたくない。まぁ、自分は社内改革を主導しようとしないで岡目八目で状況を見つつ、誰がキーマンになるか見定めて、今までの経験で知ってるやり方をこっそり教えてあげるぐらいにしとくか。


一応、今の会社で正社員登用は狙っているけど、この会社でずっと長居をするつもりもあんまりないのである。以前もちらっと書いたけど障がい者雇用ってのは基本的に最低賃金だし、昇給も昇進も望めそうにない。どうせこんな安月給では安定した生活は望めないので、いずれ独立してフリーランスプログラマでも目指そうと思ってこういう情報も集めてる。


blog.tai2.net


アプリ開発とかやってるのは自分で望んでそこに配属されるようにお願いしたんだけど、今までのキャリアではWeb開発しかやってなかったんだけど、この現場でアプリ開発の技術を2~3年ばかりやっとけば技術も身についてスキルアップにもなるし、もし転職するにしても履歴書に書ける職歴になる。フリーランスになるにしてもアプリ開発も出来るのは業務の幅が広がる。


しっかしまぁ、どうせ仕事をやるのであれば気持ちよくやりたいし、障がい者になってしまって働き口が無い所を拾ってもらった恩義もあるし、なるべく改善しようと頑張ってる新人君の味方などをして業務改善が出来るようには行動していきたいものだ。

プライバシーポリシー免責事項