退職駆動開発 (Retirement-Driven Development = RDD) について考えてみたことをご紹介します。

前提

退職者がでると大変なことが多いですが、デメリットばかりをあげても仕方がないので今回はメリットの部分を取り上げたいと思います。

「退職駆動開発」とタイトルに付けているように、退職をきっかけに開発を推し進めるということについても触れます。

業務引き継ぎのメリット

暗黙知を形式知化できる

引き継ぎのタイミングで、退職者しか把握していなかった暗黙知を形式知にするチャンスが発生します。

具体的には、

• 引き継ぎ資料でドキュメント化される
• 引き継ぎのタイミングでシステムへ実装される

などの過程を経て暗黙知が形式知になります。

引き継ぎ自体は大変ですが、暗黙知から仕様を起こして、システム実装までできるのはメリットと考えられます。

属人化されている業務が洗い出される

暗黙知の内容とかぶりますが、暗黙知が存在する業務はほぼ属人化されていることが多く、そういう業務が存在すること自体、他の人が知らないケースはよくあります。

無駄な業務が無くなる

退職者がおこなっていた無駄な業務が、引き継ぎのタイミングで消失するというのもメリットです。

引き継ぎ先の担当者に充分なリソースがあれば話は別ですが、大抵の場合は今の業務＋αなので、全て引き継ぐことは難しいです。そういう状況だと、重要度の低い仕事は引き継ぎの過程で自然と無くなるケースをよく見てきました。

退職者が◯◯ケース別対応

非エンジニアの場合

引き継ぎのタイミングで適度に業務改善が入ります。

また、業務フローによってはシステム実装されることもあります。

エンジニアの場合

スクラム開発をしているので、引き継ぎ業務自体が不要なケースがほとんどです。暗黙知ができにくく、属人化しにくいというのもスクラム開発を採用している理由の一つです。

以上、本当はタイトルに TDD (Taishoku-Driven Development) って書きたかったけど、別の意味になるので控えた、現場からお送りしました。