という資料を捏造したい気分だったので書いてみた。特に意味はないしオチもない。
フリーマンを置く目的は、以下である。
・システムの品質向上
・プロジェクトに潜伏している問題の早期発見
・メンバーの技術レベルの把握と向上
フリーマンは明確なタスクを持たず、名前の通り、手の空いた状態でプロジェクトに携わるエンジニアである。
システム開発におけるフリーマンが行うべき主な作業は以下である。
・ソースコードレベルでの問題の発見と指摘
・テストコードの不足分の拡充
・仕様が曖昧且つ後日問題となりそうな点の明確化
・メンバーの技術レベルの把握と作業分担の適正化
フリーマンは直接コードは書かない。その代わり、製造されているすべてのソースコードを把握し、問題があれば指摘を行う。
また、技術レベルに問題があるメンバーがいる場合は、指導もしくは適切な作業の割り当てを提案する。
フリーマンの存在が効果を発揮するのはプロジェクト中期以降である。そのため初期の段階では参画せず、中途でアサインされることが多い。これはシステム開発当初から居たメンバーとは別の視点をもたらす効果もある。
規模の小さなプロジェクトの場合は、フリーマンが複数のプロジェクトを掛け持ちする場合もある。
フリーマンには以下のスキルが求められる。
・メンバーを指導ができるだけの技術力
・指導をスムーズに行えるコミュニケーション能力
・大量のコードを素早く読むことができるコード読解力
・能動的にプロジェクトの品質を高めようとするモチベーション
・品質を第一とし技術的な嗜好に走り過ぎない自制心
フリーマンは技術指導を行う立場である。そのため、通常は最も技術スキルが高いメンバーが選ばれる。但し性格的にフリーマンに向かない技術者もいる。その点は考慮する必要がある。
指導やメンバー間の調整など、コミュニケーションが発生する役割を多く担う。そのため、メンバーとの不和を起こさないだけのコミュニケーション能力が必須であり、これがないと逆にプロジェクトを混乱させてしまうこともある。
フリーマンは明確な成果物を持たないため、モチベーションの維持が難しいとされている。リーダーは成果の報告を義務付けたりそれに対する評価を行うなど、適度な頻度で干渉すると良いとされている。
ここからフリーマンを置いた場合に得られる効果について紹介しよう。
新しくメンバーが加わった。彼の能力は未知数だが、経歴から判断して作業を割り振った。週に2度の進捗報告では彼の進捗に問題はなく、スケジュール通りに作業が完了するはずだった。
ところが、当該作業が終わる予定の当日に、「もう1日待ってくれ」と言い出した。リスケしてもう1日待ってみたところ、さらに「もう1日待って欲しい」と言われた。不振に思いソースを確認したところ、まだまともに動作する状況ではなくあと1週間は必要だということが分かった。
↓
一緒に仕事をしたことがない相手と仕事をする場合、力量もわからなければ、正確な報告が期待できるかも分からない。
少し規模の大きい開発現場では、ほとんどのメンバーの力量を認識できていない状態でプロジェクトが進行することも多い。酷い時はその人を雇ってから半年以上経過して、ようやくスキルに問題があることに気づくというケースもある。
これは作業者の能力や進捗を正しく把握することができていないためである。多くの開発現場で、作業者の能力を把握し適切なタスクを割り振ることに対して、十分なコストが支払われていない。
フリーマンが毎晩コミットされるコードを確認していれば、もっと前の段階で異常を感知し、作業の割り当てを変更することができる。また、雇った人間のスキルが十分でないと判断した場合は早い段階で契約解除などの対応を行うこともできる。
メンバーの1人が高い能力を持っており、他のメンバーが3日で行う作業を1日で終わらせてしまうことができた。しかしそのメンバーは周囲より突出した成果をあげることを嫌い、1日で仕事を終わらせた後、残り2日はプロジェクトの進捗と直結しない作業をしていた。
↓
フリーマンはコードの質や日頃の仕事ぶりを確認することで、そのメンバーの能力の高さに気づくことができる。能力のあるメンバーにより高いモチベーションで作業してもらうことができれば、プロジェクトの成功率は大きく向上する。
同じ給料で人の3倍の仕事を課すのは無理がある話であるが、成果に応じた報酬の見直しを言及したり、そのメンバーが望む作業を割り振るなどの対応によって、大きな戦力を得られる可能性がある。
同じような機能が複数の実装者によって重複して作られていた。どちらの機能も仕様は満たしているものの、後々、お客様から動作の微妙な違いが気持ち悪いとクレームが入った。
↓
大枠の共通機能は設計段階で共通化できるが、いざ実装を始めると細かい類似コードがいくつも発生してしまうのはよくあること。多くの場合は問題にはならないが、僅かな挙動の違いが深刻な問題を引き起こすケースもある。
フリーマンは横断的にソースを把握しているため、それらの問題を早期に発見し、共通化した機能を提供するなどの対処を行うことができる。
また、それらの中には適切なライブラリを用いた方が、より少ないテスト工数で安全な動作が期待できる場合がある。そうしたライブラリの導入提案もフリーマンの大切な役割の1つである。
将来的に育って欲しい若手の社員をメンバーに入れた。まだ経験が浅くミスがあることが予想されるので、リーダーである自分が面倒を見ようと思っていたが、途中から自身の作業で手一杯になりほとんど放置する状態になってしまった。
↓
フリーマンは全メンバーのコードを把握し、必要に応じて教育を行う。但し、通常はメンバーのスキルアップよりも品質向上を優先課題としているため、品質に問題が出ない程度の記述の重複やパフォーマンスの良くない書き方については、あえて指摘しないケースが多い。
しかし重点的な教育が必要なメンバーに対しては、他のメンバーよりも細かいところまで指摘し、より良いコードの在り方を教育することで、ペアプログラミングを行なった場合に近い教育効果をもたらすことができる。
まとめ
システム開発において、十分な品質を維持するのにもっとも効果的な方法は、品質の高いコードを書ける人間でプロジェクトを固めることである。
しかしそうした恵まれた環境を整えられるケースは少なく、水準を満たしたコードを書けるメンバーが1〜2人しかいない状態で作業を強いられるケースも少なくない。
フリーマンの基本的な考え方は、そうした高い能力があるエンジニアに多くの作業を受け持たせるのではなく、最低限の品質を確保することに注力してもらおうというものである。
最も能力の高い戦力をどこに割り振るべきかは、メンバーの質やプロジェクトの内容によって変わってくる。品質面の不安を最も強く感じる場合は、フリーマンを採用することも検討したいところである。