スクラムでプロダクト開発をするようになって、約1年が経過した。

スクラムは実によくできたフレームワークであり、スクラムから得られたものはたくさんある。 例えば..

• 今自分がやっていることに対して納得感を持って取り組むことができるようになった
• 発生した問題に対して、その場しのぎではなく仕組みで解決することができるようになった
• 同じゴールを共有するようになったことで、"チームでやっている"という感覚が強くなった。そのおかげで心理的負担が減り、同時にメンバー間も仲良くなった（と思う）
• 優先順位に基いて業務を進めるようになったことで、属人化が減った

などである。

その一方で、デメリットとして最近感じているのは属人化を排除することで同時に個々人の責任感も削り落としてしてしまったのではないかという点である。

スクラム導入以前は、AさんはサービスAを担当し、BさんはサービスBを担当、というように個人が持つ領域が明確に分けて開発・運用をやっていた。今考えても、限られた人数でそこそこの規模のプロダクトを効率良く運営するにはこれ以外に良い方法が思い浮かばない。

当然この運営スタイルは属人化を強めてしまい、AさんはサービスAしか見れないし、また担当外のサービスBについてはほとんど関心が無いという状態になってしまった（少なくとも自分はそうなった）。 一方でメリットもあった。それは担当しているサービスに対する責任感が人一倍強くなるという点だ。障害が起きれば真っ先に対応するし、ユーザや関係者からの問い合わせがあればそれについても真っ先に対応する。サービスの短期的な面だけでなく、将来的な面についても検討することができていた。

スクラム開発では、スプリントバックログという形で1スプリントで取り組むタスクを優先順位で並べて可視化すると思う。優先順位でタスクを消化していくため、誰がどのタスクを取ることになるかはわからない。言い方を変えれば、どのタスクを取っても大丈夫という状態になっていなければならない（と理解している）。 このようなスタイルで開発を進めていくため、属人化された業務が減っていくわけだ。 そして、みんながサービスに対してある程度の知識を持つようになったことで、"ここは自分がやるんだ"という責任感も弱くなった。

心理学的に言えば 社会的怠惰 という現象に当てはまると思っている。「誰かがやってくれる」「自分が前に出なくても誰かが..」といった意識が無意識に働いているような気がする。 また「自分は1人ではなくチームでいる」という安心感が、危機感すらも鈍らせてしまったように思う。これまでは「何が何でも解決しなければならない」という気持ちだったものが、「今やれることをやっていこう。無理をしても仕方がない。」という方向になりやすくなった。

エンジニアの中で 属人化は悪 というのは常識のように語られ、自分もそれを信じていた。 しかし、もちろん自分の弱さもあるが、実際にそのデメリットを肌で感じることでこの通説に疑問を抱くようになった。今でも属人化が良いとは思っていないが。

何か、良い感じにバランスをとっていけるやり方は無いかなぁ。

...といったことを考えつつ、初心に帰ってスクラムの書籍でも読んでみようと思った2017年の秋だった。

SCRUM BOOT CAMP THE BOOK amazon.co.jp

とりあえずこれ買ってみた