等などで愚痴を披露しているようにいわゆる「レガシーコード」と対峙するに下のような問題があると思っている。
- 暗黙知が多すぎる問題
- 自分でやったほうが早い病を誘発する問題
- 自走を全く促せない問題
結果、レガシーコードに関して後世に何も引き継がれず問題に取り組んでも手応えを感じられず誰も得しないかなしみ。結論として以下が処方箋だよ、というお話。
- 形式知化
- ペアプログラミング/モブプログラミング
レガシーコードへ、「人的アプローチとしてどう立ち向かうか」の考察を軽めにまとめたもの。
1. レガシーコード、暗黙知が多すぎる問題
「担当になった者がソースコードを読んで気合と根性でなんとかする」で引き継がれてきたから。
それができたのはまだその「レガシーコード」が本流だった頃の話。
時が進んで複数バージョンと合わせて見るなどという状況ではかけられる時間も異なる。よってドキュメントももう一度、形式知として改善していく必要がある。そして読んでもらえるようにする。
2. レガシーコード、自分でやったほうが早い病を誘発する問題
1 に伴って、「自分がやったほうが早い」状況がしばしば発生する。
「自分でやった方が早い病」を克服したい。
「自分が介入し過ぎることでメンバーの思考力を奪ってしまっていたのだな」
自走するチームを作り大きな成果を達成することを阻害する因子
チームとして大きな成果を生み出せなければ、自分はさらなる高みにいけない
自分でやった方が早い病
その弊害は以下とまとめられている。
中長期的な視点で物事を考えるのが苦手
長時間労働が苦ではない
ムダな完璧主義者になる
3. レガシーコード、自走を全く促せない問題
また2 に伴って「自走」という言葉が流行り言葉として語られる。
「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話
- issue
- Design Doc
- times channel
- ペア/モブプログラミング
- draft pull request
どうやったら「自走できる人」になれるのか
自走できるエンジニアとは
「自走」できないほうに責任があるわけではないんだよなあと思う。
まとめ
結論、上に書いたような問題に対して
- 形式知化
- ペアプログラミング/モブプログラミング
が有効に考えられるという現時点でのメモ。ともかく同じ方向を向いて目線を合わせる点でこれらがツールとなりそうだぞ、と取り組み始めているところ。
これらっておよそ「孤独」をどうやって避けるかのアプローチなのだなとおもう。
より具体的なペアプログラミング技法等などは研究しながらまたまとめたいと思うが、まずはスタート地点での考察の意味で、以上参考になればさいわいです。