自分のところではプロジェクト管理としてRedmineを使って、各自担当するタスクや不具合、課題、要望などを管理するようにしているのですが、こうした開発スタイルをとっていく中で当然よい側面と悪い側面が出てきたりします。
簡単に言ってしまえば、タスクが明確化される一方で、与えられたタスクだけをやればよいという風に受け取られてしまうということがあるといった点です。
当然、それぞれのエンジニアの働き方にも大きく依存する問題なのでこうしたツールや開発スタイルというのは良いようにも悪いようにも受け取られたりします。
機械的な形式と機械的な仕事
自分のところではチケット駆動開発と呼ばれるほど厳密なルールを作ってやっているわけではありませんが、タスクや課題、バグからユーザーからの要望などなど雑多なものを拾い上げて適当な開発・改修の粒度に分けてチケットを管理していたりします。
別にこれはRedmineというBTSツールに頼らずとも、規模が小さなチームやプロジェクトであればExcelなんかで管理するというものでも全然かまわないんでしょうけど、要するに何らかのやらないといけない仕事がデータ化され保存されているというわけです。
これにより仕事の見える化が進むわけですけど、それにより最初に書いたような弊害が生まれたりもします。
担当者が決められ割り当てられるというのは、自分がやらないといけないタスクというものがはっきりしますので、いってしまえばそれをこなしていけばよいという機械的な仕事の形式にもなります。
これが、そのタスクだけを自分が担当すればよいという思い込みにもつながったりすると最悪で、そっちは担当ではないから関係ないという思い込みとか、関連するタスクの状況を確認していかなかったために後々トラブルが起きたりとかします。
ここで積極的なエンジニアは他のチケットの状況を確認してコメントしたり、担当者が付いていないチケットでも進んで担当者になっていくというようなことが期待できるのですが、まぁこういう自主的に動いてくれるエンジニアは稀ではないでしょうか（仕事が増えるわけですから心理的には当たり前かもしれませんけど）。
エンジニアの中には自分の力量とタスクの難易度を鑑みて打算的に動く人もいますから、このチケットの難易度は高いから止めておこうとか、このモジュールはAさんが過去に対応していたから自分が受け取るのはやめておこう見たいな事にもなって特定のチケットが放置されたり、システムの分野やカテゴリによっては担当者が偏って負担が大きくなったりもします。
これは、その一部のエンジニアしか積極的にチケット管理ツールを使わないということにもなってきて、本来タスクの見える化や権限のフラット化やチームの活性化というものに結びつかなかったりもします。
個人的には、チケットの総量や担当者の動きというものが全て把握できたりもするので、誰が仕事をしていて誰がしていないか（または積極的ではないのか）ということがわかったりするので、結構残酷なツールだなと思ったりもします。
組織における向き不向き
チーム内でやらないといけないタスクというのは、誰がと言うわけではなく各々が見つけて提言していくのが理想的です。
バグにしろ、ユーザーから言われた改修の要望にしろ、それが特定のマネージャーを通らないとあがってこないという状況ではそこがボトルネックになりかねません。
先ほど書いたように積極的なエンジニアがどれだけチーム内にいるかという話にもなりますが、Wikipediaの記事を書く人と読む人のどちらが多いのかを比較すれば明らかですけど、かなり多く見積もって1割のエンジニアが積極的に動いてくれたとしても、100名のチームならそれなりのタスクの流動性を持たせられるでしょうが10名以下の小規模なチームとかになると1名とかになるのでタスクが自主的に動いていく数がかなり低くなってきます。
タスクが活発に動いている状況はチームが活発に動いている状況でもあるので、そのような状況に無い場合はそもそもその開発スタイルがチームにあっていないということにもなります。
別にこれはコミュニケーションスキルに優れたエンジニアがいるかいないかという話ではなく、BTSを使った場合のコミュニケーション手段は基本テキストになるので、バグの報告とかシステムの仕様をWikiにまとめるといったことは、話すのが苦手といったエンジニアの方が返って向いてたりもします。
逆に話し好きなエンジニアの方が打ち合わせで問題点や方針を決めたりして、それがチケットにあがってこないという状況にもなったりするのでこのスタイルに向いてないかもしれません。
また、チケット（タスク）の総量が減ってきたりするとエンジニアが仕事を持て余すようにもなってきたりします。
つまりは、受身なエンジニアが多い状況ではそのチームやプロジェクトのマネージャーがチケット（タスク）を作り出して割り当てていくということをしていかないと全然仕事が進んでいかないという状況に陥ります。
このスタイルを割り切ってしまえば、マネージャーの負担が大きくなるにしろ機械的にタスクをこなすことでチームを回す事はできるかもしれませんが、それに慣れてしまった場合に何も考えが及ばないようなエンジニアが育ってしまったりして怖いなとも思うわけです。
何れにせよ、数多ある開発スタイルというものは、マネジメントの観点だけで良し悪しが決まるものでもなく、そもそも組織やチームの文化やそこにいるエンジニアの能力や人柄なんかにも左右されるので、無理に当てはめてもすぐに効果が出るものでもなく、長い時間をかけて特性に合うエンジニアを育てていくということも大事なんだと思います。
[PR]
[PR]
関連記事