メディア

開発中、リーダーは何をしている？：初めてのプロジェクトリーダー（4）

» 2005年06月15日 12時00分公開

[岡島幸男，永和システムマネジメント]

　開発が佳境に差し掛かり、メンバーがプログラミングなど開発作業に集中しているとき、リーダーはチーム全体の状況を把握し、チームを正しい方向へ導く必要があります。「チーム全体の状況」にもさまざまなとらえ方がありますが、今回は主に進ちょく管理の実践を中心に説明します。また、プログラマー兼任リーダーと、複数プロジェクトの掛け持ちリーダーについてのポイントも簡単に説明します。

進ちょくの見える化

　進ちょく管理とは、顧客にとって価値あるもの、すなわち成果物の生産状況を把握し、コントロールすることです。前回の記事でも説明しましたが、進ちょくは成果物で測定するのが原則です。つまり、「10個のうち、3つ終わっている」ことを誰の目から見ても明らかになるようにするのが重要となります。

　キーワードは「見える化」です。見える化とは、もともとはトヨタ生産方式の用語ですが、最近はソフトウェア業界でもよく使われるようです。そして、見える化を実現するためのツールとしてよく利用されるのが、「ソフトウェアかんばん」（図1）です。

図1 ソフトウェアかんばん

　まずは、壁やホワイトボードに3つのレーン（TODO・DOING・DONE）を区切ります。次に、大きめの付せん紙をタスクカードとして利用し、タスクの状況に応じたレーンに貼り付けます。なお、タスクのサインアップはメンバー自らが行うのが原則です。

　作業の進み具合に応じて、タスクカードを右側に移動させていくことにより、誰の目から見ても進ちょくが見えるようになります。すべてのタスクカードがDONEのレーンに移動すれば、作業は完了となるわけです。

かんばん運用の注意点

　ただし、ここで説明したソフトウェアかんばんは、どのような状況でも効果があるとは考えないでください。具体的には、以下の状況での利用はお勧めできます。

（1）タスクの粒度がそろっている

　例えばドキュメント作成であるとか、画面モックアップの作成、アプリケーションのプログラミングなど、比較的均質のタスクがある程度まとまった数そろっていて、それぞれのタスク間に優先度の違いが少ない場合。

（2）メンバーに経験者が多い

　自分で見積もって、サインアップが可能な程度の経験を持ったメンバーが多い場合。

（3）期限が比較的長い

　全タスクを完了させるまでの期限が、比較的長く（数週間程度）取れる場合。逆にいうと、これらの条件から外れている場合は、以下に説明するようなカスタマイズが必要になります。

（1）タスクの粒度がバラバラの場合

　タスクの難易度や、完了するまでの時間に差が大きい場合には、かんばんを別々にします。例えば、ドキュメント作成とプログラミングを並行にしている場合には、それらを全く別のかんばんとします。

（2）経験者が少ない場合

　例えば、新人が多く配属されて、かつ納期が厳しいプロジェクトの場合には、リーダー主導でタスクの分配を行っていく方式を採用します。メンバーに、スケジュール重視であることと、タスクの優先度の説明を行った後、あなたがタスクを割り当てます。メンバーによるサインアップの原則を曲げるわけです。ただし、このような場合にも、「管理というよりは演出」の原則を忘れずに、メンバーに作業の進め方の意見を聞くことも大切です。何でもかでも独断的に決めてしまうと、長い目で見た場合にチームワークに影響を与えますし、人を育てる観点からいっても効果が薄くなります。

（3）納期が迫っている場合

　納期が迫ってきたのに、進ちょくが見えず、危機感が伝わってこないことがあります。このような場合は、かんばんをいったん外してしまい、下の表のような、日付をベースとしたかんばんに付け替えます。


	5/9	5/10	5/11	5/12	5/13
タスク1	徳川	徳川		デモ
タスク2		豊臣
タスク3			全員

　1週間単位で、タスクと日付の交差する場所に担当者の名前を書き、完了したタスクには印を付けていきます。また、重要なマイルストーン（イベント）も同時に記入し、いまの作業は何を目的にして行っているのかを明示します。この例ですと、5月12日のデモに向けて各タスクを進めていることがよく見えます。

　納期にかかわらず、開発メンバーは目の前のこと、いま作っているプログラムに意識が集中します。このような場合に、タスクの相互関係、タスクの組み合わせが達成する目的をはっきりと見せて、メンバーに期限優先の意識を持ってもらうことが狙いです。これはよくあるスケジュール表（ガントチャート）ですが、印刷して配布するよりも、このようにかんばん化して掲げることの方がより効果的です。

　どのようなかんばんを使う場合でも、掲げただけで満足しないことが重要です。上手に機能するまで、時と場合に応じてかんばんと、その運用を改善していく必要があります。「最近、かんばんの更新が少なくなってきたなあ、誰も見てないんじゃないの？」と感じたときには、すぐに動いてください。

　また、かんばん方式だけで、すべての管理を行おうと考える必要はありません。課題の管理などは、Excelで一覧を作って管理するのがよいでしょう。

伝家の宝刀の抜きどころ

　次は話題を変えて、リーダーが「刀を抜く」すなわち、実作業を行う場合のポイントをお話しします。特に小規模なプロジェクトの場合は、リーダーは管理だけではなく、プログラミングをはじめ、さまざまな開発作業も行う場合が珍しくないでしょう。その場合、「伝家の宝刀はひっそりと抜く」原則に従ってひっそりとやり遂げるのが理想なのは、以前説明しました。では、具体的にはどのような場面が刀の抜きどころなのでしょう？

　筆者は、以下の個所が刀の抜きどころだと考えています。

・ログ出力、共通例外の設計、プログラミング

　これらは仮組みのまま、最後までおざなりになってしまうことが多いようです。システムの要件としてはっきりと事前に決められることが少ないせいもあるでしょう。ただし、これらの機能を中途半端にしたまま開発を進めると、必ず「ログが出なかったので、再現できない不可解な問題」や、「よく存在意義の分からないあちこちに散らばる例外クラス」などの問題が発生し苦労します。こうなる前に、リーダーであるあなたが、これらを作ってしまいます。

・（根本的な課題部分の）スパイクプログラミング

　スパイクプログラムとは、機能を事前検証するための小さなプログラムです。根本的な課題部分とは、例えば、初めて採用するミドルウェアの動作検証など、動かなければプロジェクト全体に影響を及ぼすような事柄です。リーダーであるあなたが、事前にこれらを作っておくと、開発がスムーズに立ち上がりますし、開発が本格化した後に問題が発生した場合にも慌てず対応できるようになります。

・エラーメッセージの見直し、修正作業

　エラーメッセージは、システムを利用するユーザーが直接目にするインターフェイスです。従ってとても重要なのですが、意外に適当に扱われてしまう場合もあります。開発者の視点からすると、「単に変数であり、いつでも置き換え可能な文字列」だという意識が多少なりともあるからでしょう。開発も終盤に差し掛かり、エラーメッセージの修正やドキュメント化を行う必要が出てきた場合は、リーダーであるあなたが、ユーザーの視点に立ってメッセージを見直し、修正作業も行ってしまいます。

抜かない刀はさびる

　チーム全体のためには、刀はむやみに振り回さず、1つ上の視点でチームをまとめていくことに最も注力する必要があることは、連載初回にもいいました。ただし、刀は抜かないと、鞘（さや）の中でさびてしまいます。ソフトウェア技術の進歩スピードは本当に速く、少しでも気を抜くと世の中から置いてきぼりを食らうのは事実です。また、丸腰や、さびた刀しか持たないリーダーを信頼し、ついて行きたいと思ってくれる技術者がいないのも事実です。どのような技術に人気があり、また、今後の主流となっていくのか。このような情報をつかむためにも、開発中こそ、メンバーと技術談議することをお勧めします（もちろん、自分で勉強をすることも大事ですが）。

複数チーム掛け持ちリーダーの場合

　最後に、複数のチーム（プロジェクト）リーダーを兼任する場合のポイントだけ説明しておきましょう（初めてのリーダーで、いきなり掛け持ちすることはないとは思いますが）。

（1）掛け持ちするな

　できれば掛け持ちは避けたいところです。人間の集中力には限界があり、頭の切り替えには相当なパワーと時間が必要です。それでも掛け持ちする場合は、プロジェクトマネージャや、上司に相談し、以下のような対策を考えてください。

（2）右腕となるサブリーダー

　当たり前の話ですが、それぞれのプロジェクトに、あなたの右腕となるサブリーダーが必要です。しかも、最初から育てている時間はないので、最初からそれを前提にアサインをお願いする必要があります。

（3）リーダーのリーダー

　理想形は、それぞれのプロジェクトのサブリーダーに、管理の実作業をしてもらい、あなたはリーダーのリーダーとして、チームの方向付けと重要な判断に集中することです。そのためには、リーダーとサブリーダーが同じ価値観、原則を持つ必要があります。サブリーダーが自分の判断で動けるようなチームを目標とすることをチーム計画書に宣言し、サブリーダーに、あなたの期待感を正しく伝えます。

　掛け持ちの場合、特にプロジェクトの初期はかなり苦しいはずです、しかし、ここでサブリーダーと一緒に苦しんでおかないと、プロジェクトの後半ではもっと苦しむことになります。

　プロジェクトが無事完了するまでには、実にさまざまな問題が発生します。次回は、主に問題解決方法について話をする予定です。

　なお、来る6月29日（水）に筆者も参加するオブジェクト倶楽部のイベントが開催されます。テーマは「プロジェクトファシリテーション」です。当日、筆者もワークショップを開催します。内容はこの連載にそのままリンクしています。興味のある方はぜひ参加してみてください。

「初めてのプロジェクトリーダー」バックナンバー