プログラマの思索

「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。

【参考】
akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S"

前任の仕事を引き継ぎしたら、下記の問題があったらしい。
技術的負債込みで引き継いでしまった、という例は、本当によくある。

(引用開始)
１年前の状態
・すべてがメールベース
・ドキュメントはほぼ無い
・最強の属人化。個人のパワーで乗り切る
・技術に関心が無く誰も行動しない
・暫定スクリプトが今も元気に本番稼働中
・ソースには、ほぼコメント無し
・hoge.pl.(日付) 形式のソース管理
・チーム共有ライブラリをrequireして使用
(引用終了)

そこから、インフラ担当者を巻き込んだり、開発ツール(Redmine、Git)を普及させたり、社内で勉強会を開いたり、色んな活動をして、技術的負債を少しずつ減らし、チームの雰囲気も変えていった、と。
まさにプロセス改善の活動そのもの。

この資料で共感した部分は「今後に向けて １年でガラッと変えたけど、（本当は半年でやりたかった） 本当に、メンバは幸せなのか？」「今後に向けて このまま進めていって良いのか？ 押し付けになっていないか？」と自問している所だ。

僕自身、Redmineに愛着があるし、GitやJenkins、TestLinkなどのツールを使って、開発プロセスを自分の理想に当てはめてやりたくなる。
しかし、それが本当に良いことなのか？と自問する時がある。

会社や現場の組織構造や雰囲気、チームの成熟度によっては、自分が理想とするチケット駆動開発が適用できない時があり、すごく歯がゆい気持ちになる。

現代のソフトウェア開発の潮流を見れば、Scrumなどのアジャイルな開発スタイルが当たり前なのに、官僚的組織によるプロセスの標準化に偏っている現場に不満があったりする。
今の時代は、少人数のチームでソフトウェアを開発するのが当たり前なのに、一昔前のような組織構成で工程ごとに分断されたチームでまどろっこしい開発スタイルに不満があったりする。
だからと言って、自分の思いを捨てて、現状になびくのが良いとは思わない。
おかしいものはおかしいから。

問題だらけの環境の中で、小さな糸口を見つけて、そこから少しずつ進めていく。
違和感を持ちながらも、その感触は忘れず、かと言って毎回衝突するのでもなく、ちょっとずつ変えていく。
必ず改善できるチャンスはあると思うから。

違和感はなくさず、その違和感の真因を考えて、自分なりの解決策を何度も練り直して持つ。
それが何となく大事な気がする。