野狐消暇録

所感を記す

学生症候群対策@ソフトウェア・プロジェクト

概要

ソフトウェア開発プロジェクトにおいて、以下が発生した場合の対策をまとめる。

対策のポイント

対策は以下の2種類ある。

  1. 管理者がタスクを細かく管理する。
  2. 開発者自身がタスクを管理できるようになる。

「1.」は対症療法的、もしくは短期的な対策であり、「2.」が根本的、もしくは長期的な対策である。

学生症候群とは何か

学生症候群は、期限ぎりぎりまでタスクを引き延ばす傾向を指す。

 

en.wikipedia.org

ソフトウェアプロジェクトの管理者が作業の見落とし、仕様変更などによるプロジェクトの遅延に備えてスケジュールにバッファを設けると、そのバッファを学生症候群に陥った開発者は「まだ期限が来てない」と考え、作業を先延ばしにすることで食い尽くしてしまう。

パーキンソンの法則とは何か

パーキンソンの法則とは、不要な仕事を作り出してまで、与えられたリソースを使い切ろうとする傾向のことである。

ja.wikipedia.org

ソフトウェアプロジェクトにおいて、開発者が不要な仕事に時間を割き、用意した時間を浪費することがある。例えば、必要以上に丁寧にドキュメントを作る、もうテストが済んでいるのに、追加のテストケースを無理やり考えてテストを行うなどの行為である。これらはパーキンソンの法則に当てはまるリソースの浪費である。

 

事例

体制

  • 管理者兼開発者(プレイングマネージャ) 1人(管理者Mとする)
  • 開発者 1人(開発者Aとする)

開発内容

社内システムとECサイトに対する中規模の改修作業

事象

管理者Mは、おおよそのスケジュールを3か月と見積もり開発に着手した。

最初の1か月で要求のヒアリング、要件定義をおおよそ固めると、2か月目に構築作業に着手した。ここで、構築作業とは、プログラムの設計、実装、機能単位のテストを行い、検証環境にリリースすることを指す。構築作業を一か月で終えたら、最後の一か月で総合的なテストを実施し、システムの改修を完了する予定であった。

管理者Mは構築作業を始めるにあたり、自身と開発者Aに構築作業を均等に割り振る計画を立てた。

学生症候群の例

予定工数が1人日~2人日の小規模な構築作業aを開発者Aに依頼した。開発者Aは他に2,3の作業を抱えていたが、構築作業aの優先度がそれなりに高いことを知っていたにも関わらず、作業を先延ばしし続けた。そのため、構築作業aはテストフェーズに入る直前まで着手されておらず、テストフェーズに入る前の日に着手され、その日のうちにリリースされた。リリース後、作業漏れが見つかり、テストフェーズの一日目を使って、作業漏れの対応を実施することになった。

パーキンソンの法則の例

開発者Aは、構築作業aを先延ばしにしている間、他の作業bをずっと続けていた。作業bは顧客とやりとりしながら、データを整理していく作業であった、予定工数は1日3時間使うとして5~7日程度の見込みであった。開発者Aは1日5時間前後を使い、3週間以上に渡ってこの作業を続けた。管理者は当初単なる見積もりの誤りと判断して遅延を許容していたが、3週間経つ頃から流石に工数がかかり過ぎていると思い始めた。

プロジェクトはどうなったか

プロジェクトの当初、管理者Mは開発者Aにそれなりの分量の開発作業を依頼する予定であった。しかし、構築作業a以外の構築作業も、開発者Aは常に先送りし続けた。そのため、管理者Mは作業の遅延を防ぐために開発者Aに振った仕事を他の開発者、つまり自分自身にアサインし直さざるを得なかった。結果として、3か月のプロジェクトの終盤に差し掛かってみると、開発者Aは構築作業をほとんど行っていなかった。構築は管理者Mがほとんど担っており、構築作業は予定の1.5倍のスケジュール時間を使っても完了せず、テストフェーズに入れなかった。2人で進める予定の構築作業を管理者Mが一人で進めていたため、構築が終わらなかったのである。

開発者Aの背景

管理者Mは、上記プロジェクトの中盤あたりで、開発者Aが色々な理由を述べ立てて構築作業を行わないのを見て、開発技術が未熟であるために、面倒臭がっているのではないかと考えた。そのため、スキル不足の要員であるとの見立てを元に、開発技術の勉強を勧めたり、成果物のレビューを引き受ける旨伝えたりして、開発者Aを励ました。しかし、あまりにも開発者Aが構築作業を忌避しているように見えることから、「開発者Aのスキルが不足している問題」を上司に報告した。すると、上司からは

「開発者Aは適当な仕事をして誤魔化しているように見えている」

「開発者Aはいつもドキュメントを作っているが、全く忙しそうに見えない。管理者M君はいつも忙しそうに見える」

という指摘があった。そこで初めて、管理者Mはそもそもの問題が技術力ではなく、開発者Aの仕事の進め方にあるのではないかという事に気が付いた。

開発者Aと面談してみると、果たして

「作業bはもっと短い期間で出来た。おそらく実際に必要な時間の2,3割増しで時間を多く使っている」

「簡単な作業については、後でやればいいやと思って先に送ってしまう癖がある」

などの証言が得られた。

事ここに至って、管理者Mは自分が感じていたことの原因を見い出した。管理者Mは開発者Aと仕事をしながら、次の事を感じていた。

「こちらがお願いした仕事はやってくれないが、開発者A自身が見つけてきた仕事は嬉々としてやる。提案してきた仕事が要らないことがあるのだが、仕事を自分からやってくれるのは歓迎すべきことであるから、敢えて止めるには及ぶまい」

しかし、問題の原因が学生症候群とパーキンソンの法則である事が分かってみれば、この対応は間違いだったわけである。開発者Aは、上司の指摘した通り、プロジェクト上の要否ではなく、自分の仕事の好みに従って作業を選んでいたのである。そうなると、開発者Aの裁量に任せた箇所については、裁量によって効率が上がるどころか、むしろ、プロジェクトのコントロールが失われていたわけである。管理者Mは、スケジュール上のリスクを吸収するためのバッファが開発者Aの恣意的なタスク管理によって食い潰されていた事にショックを受けたが、同時に思い当たる節がひとつあった。

それは開発者Aが非常に強いプレッシャーのかかるプロジェクトに長年携わっていたという事実である。開発者Aはかつて大手都市銀行のシステム更改に携わっており、徹夜したり、開発メンバーが会議で怒鳴られたり、一年のうちに何度も開発メンバーが辞めたりする職場にいた。銀行のシステム更改のような大規模なプロジェクトは大抵スケジュールが遅延しているため、定常的にスケジュールのプレッシャーが開発者にかかっていたであろうことは想像に難くない。しかも、上記に述べたような強権的なプロジェクト管理下にあったとすると、開発者にとって「外からの圧力によって強制的に作業をやらせられる」事は当たり前になっていたに違いない。こうなると、開発者は息抜きできる場所を探してなるべく楽をするように努めることになるだろう。結果として、こうした職場の開発者は、裁量を与えられると、それを自分の息抜きのために使ってしまうのではないだろうか。つまり、開発者Aの受動的、非協力的なタスク管理は、こうした環境で養われたものではないかと推測したのである。大規模な開発プロジェクトでは、プロジェクト管理は開発者から全く切り離されているため、開発者の非協力的なタスク管理によってプロジェクトそのものが破壊されることはないであろうが、今回のような二人体制の小規模なプロジェクトでは、破壊的な影響をもたらすことになる。

その点を開発者Aに聞いてみると、

「急かされないとやらないところはある」

「大手都市銀行のシステム更改では、徹夜もあったが、何もない日が2,3日と続く事もあった。何もない時は、上司に聞いても『作業はない。待っててくれ』と言われ、やる必要がない仕事をやむを得ず、何日にも渡って時間を潰すためだけにやっていたことがあった」

とのことであった。おそらく、開発者Aは今まで自主的に仕事を進めるような働き方をしておらず、自主的な働き方をすぐに身に付けることができなかったと思われる。

対策

学生症候群にしても、パーキンソンの法則にしても、プロジェクトの適切な時期に、適切な品質の仕事をできないことが問題の根幹である。そのため、対策はタスクの管理を適切に行うということになる。

学生症候群を防ぐ

管理者側の対策

何をいつまでにやってほしいのかを伝える。期限を明確に伝えるようにし、個々のタスクの優先順位、タスクの着手順、時間の使い方について、開発者の裁量を少なくし、なるべく細かく仕事を管理するようにする。これはすぐにできる、対症療法的な対策である。

開発者側の対策

自分の抱えている作業について、セルフ・マネジメントをできるようになってもらう。タスクの優先順位や着手順に自覚的になってもらい、プロジェクトの進行状況の中で、今自分がどのタスクをやるべきか、判断できるようになってもらう。これは時間がかかる可能性があるが、根本的な対策である。

パーキンソンの法則を防ぐ

管理者側の対策

どんな仕事を、どのぐらいの品質でやってほしいのか開発者に伝える。不要な仕事、過剰な品質に対して、その仕事は要らない旨開発者に伝え、別の仕事をアサインするようにする。また、開発者の手が空かないように、次の仕事を予め伝えておく。

開発者側の対策

自分のしている仕事が本当に要求されている仕事なのか、意識的になってもらう。要求以上の仕事をすることは「丁寧な仕事」「サービス」であるのではなく、「無駄なこと」であると考えてもらう。することがない場合は、自分で仕事を決めるのではなく、管理者に指示を仰ぐようにしてもらう。

なぜ、開発者側の対策が根本的なのか

管理者側の対策は、学生症候群、パーキンソンの法則を防ぐ意味で有用であるが、管理者側の負担が増すという難点がある。他方、開発者自身が上記の傾向を克服できれば、管理者は今まで通りの管理コストで済むことになる。また、セルフマネジメントができない開発者が管理者になるのは難しいと考えられるが、もし、上記傾向のある開発者がセルフマネジメントをできるようになれば、リーダーや管理者のポジションを割り当てることが可能になる。

学生症候群、パーキンソンの法則を見つけるには?

これはWBS、スケジュール表など、プロジェクトの状態を把握できるツールを使い、予定と実績を比較することで気付くことができる。以下は兆候の例である。

  • 予定工数よりも実績工数が多過ぎるが、開発者に聞いてもはっきりとした理由が返ってこない。
  • 当初の予定に比べて、成果物が上がってくるのが遅過ぎる。
  • 依頼していない成果物が上がってくる。
  • 成果物が丁寧過ぎる。

注意点

学生症候群やパーキンソンの法則は、開発者自身のスケジュールに対する無理解によって発生するわけではない。経験がある方は分かると思うが、何かの仕事を期限ぎりぎりになってやっているときに、「次は計画的にやろう」と言われれば「そうしよう」と誰でも応じる。今回の事例でも、「この作業aは早めにやろう」という管理者Mの話に、開発者Aは「そうですね、やりましょう」と応じていた。更に言うと、「なぜ作業aを早めにやる必要があるのか」についてまで、開発者Aは理解していた。管理者Mは開発者Aがスケジュールについて良く理解していることを理由に、「開発者Aは通常通りに作業を進めており、スケジュール遅延は作業量の見積もりの誤りによるもの」と速断してしまった。

学生症候群やパーキンソンの法則を見つけるには、飽くまでも成果物に着目しなければならない。開発者の理解は直接関係しないとみるべきである。

まとめ

学生症候群、パーキンソンの法則は、いずれも開発リソースの適切な配分の失敗である。管理者及び開発者は、自分達の使っている時間が本当に有効に使われているのか、常に自覚的である必要がある。