パッションは教えられない

　では、今の若手ITエンジニアは、前回説明した三つの要素をどのように獲得していけばよいだろうか。

　三つの要素のうち、パッションについては教育が難しい。パッションの源泉となるのは、主にその人が経験してきた膨大な原体験だ。出会いや別れ、思ったこと、やってみたこと、うまくいったこと、失敗したこと、決して大きな事件でなくとも、その時々に感じたことや考えたことが積み重なって、パッションに変わる。

　原体験がなくとも、同僚や先輩の持つパッションに感染するケースもある。しかし、そうしたパッションでは、感染源からの影響が途切れたときや信頼が揺らいだときに失われ、急に精神的な危機に陥る場合がある。こうした危機に陥った場合に回復できるかどうかも原体験が影響すると考えられる。

　このように、パッションはとても個人的なもので多様性がある。偶発的なものであり、教育によって得られることもあるが、あらかじめ効果を期待できるものではないだろう。

　パッションは教えられないが、スキルは教育によって得られる。必要な知識とテクニックを伝授すれば、一定の習得期間で教育者と同レベルのスキルが身に付く。もちろん、その知識を理解する基礎能力が足りないときや、習熟に足る時間がないときには、そうはいかない。したがって、スキルによっては永遠に他人に伝達できずに終わってしまうものもある。

　スキルの習得には、ある程度決まった順序がある。高度なスキルを得る前に、まずは初歩的なスキルを習得しなければならない。基礎的なスキルを習得してはじめて、応用的なものを習得可能になる。あるスキルを習得しなければ存在すら理解できないようなスキルもある。一連のスキルを習得し、その分野の達人になるまでには長い時間が必要だ。

スモールチームでの仕事のやり方

　スモールチームの仕事のやり方を習得するにはどうするべきか。筆者が教えているスクラムはそのやり方の一つ。スモールチームで仕事を進める方法をひとまとめにしたフレームワーク（枠組み）だ。

　流れを一通り見ておこう。まず、チームが今後提供するもののリストを作る。これをプロダクトバックログと呼ぶ。プロダクトバックログの中の項目は、優先順位の順番に一列に並べる。項目の一つひとつに、必要な労力を見積もっておく。これにより、チームがこの先どのように仕事を進めていくべきか認識を共有しておく。プロダクトバックログに基づいて継続的に仕事を進めていくと、いつまでにどのようなことが実現されるか、予測できるようになっていく。

　また、プロダクトバックログに基づいてチームで協調的に仕事を進めていけば、他のメンバーの持つパッションやスキルについても理解が深まっていく。互いをよく知っていれば、上手にコラボレーションできるようになり、作業効率が上がる。メンバーが不在のときや手一杯のときにも互いにカバーできるようになる。このように、メンバー間の相互の学習を通じて、より効率的で安定したチームを作ろう、というのがスクラムの特徴だ。

　人数が少なすぎると、人が抜けた場合にカバーができないので、チームは安定性にかける。スクラムでは、3人から9人のチームを推奨している。