TRICHORDの背景 - (2) 時間を基軸とするスケジュール管理

Author: Zenji Kanzaki(神崎 善司)
Published:2007-06-07

はじめに

前回は、ガントチャートの背景に流れる前提が、最近の開発では成立しなくなってきたという点と、その問題に対して対応可能なものはどれかということについて論じました。今回は時間を基軸とするスケジュール管理について解説します。

何を実現する必要があるのか

スケジュール管理をどのように行うかを考えるにあたって「とき」「こと」「ひと」の3つに単純化して考えることが有効です。

  • とき:「いつ」に着目した視点
  • こと:「行うこと」に着目した視点(成果物、作業項目...)
  • ひと:「誰が」に着目した視点

スケジュール管理を「いつ何を誰が行うか」を管理するものと定義します。 ガントチャートなどを用いた場合は「こと」と「ひと」に着目し、その結果いつまでに出来あがるかに関心があります。しかし、ここで取り上げる方式は不確定要素が多い場合、つまり「こと」が不確定な場合に適用する方式になりますので、「とき」を中心においた管理方式が有効になります。 まとめると「こと」が定まらないならば「とき」を定めてその中で「こと」を確定していことうとする考える方です。

前回、スケジュール管理に関わるいくつかの問題を見てきましたが、それらを管理するためのポイントを図3にまとめています。各々の管理ポイントを「ひと」、「とき」、「こと」の3つにマッピングし包括的に洗い出しています。

images/bg3.png

[図3 管理ポイント]

WhatとHowの視点

一般的にスケジュールの管理項目としては成果物ベースもしくは作業ベースでタスクを洗い出します。例えば成果物ベースとはタスク名に成果物の名前をつけて、その成果物を作る作業を示します。また、作業ベースとはタスク名に作業名をつけて作業の内容を表すものにします。しかし作業内容の複雑化に伴い管理項目を成果物ベースまたは作業ベースのどちらか一方だけで管理する事は難しくなっています。その場合は実現すべき状態としてタスク名をあげることもできます。例えば「概要を把握できるレベルでユースケースを作成する」などです。これはユースケースを完成させることが目的ではなく、取りあえず各ユースケースの概要を捕らえる作業を行うときなどに使う表現です。

スケジュールを組むときに適切な管理項目が見つからない場合がありますが、多くの場合成果物ベースもしくは作業ベースのどちらかの記述に固執することから、適切な管理項目を見つけにくくしていると考えられます。 ここで成果物ベース、作業ベースをより一般的な言い方に当てはめると、成果物ベースが5W1Hの「What」に相当し作業ベースは「How」に相当します。管理項目をこの「What」と「How」の二つの視点に分けて使い分けることが上記の問題に対処するときに有効です。状態名として管理項目を洗い出すことも「What」を表していることになりますので、状態で管理することは成果物で管理することの代わりとなります。 このように管理項目をWhatとHowの二つの視点で扱うようにすることで、必要に応じて管理項目の出し方を使い分けることが出来るようになります。つまり「こと」を表す時にWhatとして出した方がいい場合とHowとして表した方が適切な場合とに分けて管理することが出来るようになります。

管理項目の共通認識

様々なロールの異なる担当者(開発者、マネジャー、コンサルタント、マーケティング、デザイナー...)がシステムの中で共同作業を行う機会が徐々に増えています。このときスケジュール管理としてどのような配慮が必要でしょうか。まずはスケジュールの管理項目を異なるロール間で共有する必要があります。各々のロールは通常別々の作業を行いますが、その作業間には必ず依存関係が存在し任意のタイミングで同期を取る必要があります。

まさにその共有する管理項目を決めて、同期を取るタイミングを用意する事がスケジュールを組み立てる上で重要になります。その管理項目としてWhat的(成果物、状態)な管理項目を適用する事が有効です。 各ロールの作業は一般に専門性が高く他の分野の人には理解できないことがほとんどです。しかし、その結果作られる何かしらの成果物は他分野の人でも理解出来る場合が多いです。例えば「こっちはXXXのデザインをつくるので、そっちはその要素技術をまとめて、それで内容を合わせましょう」などという会話をしたことがあると思います。各々「XXXデザイン作成」「要素技術資料作成」としてタスクが洗い出され、それらはWhat的な管理項目になります。同じように「4月末までにXXXができる状態にするので、そこで再度検討しよう」という管理は状態としてその時点で実現している状態を「XXXできる状態にする」という管理項目で表すことになります。 このように役割の異なるロール間で認識をあわせるためにはWhat的な管理項目とし、役割の同一なロール内の場合はWhat的もしくはHow的な管理項目で認識をあわせます。Howは作業の内容を共有する必要がある場合だけ使用します。

自立的な作業ユニットの構築

自立して動ける技術者とは、自分に割り当てられた仕事に対して作業の段取りが組めて、実際に作業を行い、結果を出せる技術者のことを指しています。これは昔から使われている言葉ですが、ここに来てその重要性が増しています。それは開発スタイルがライブラリやミドルウェアを多く使うスタイルになったことに起因しています。

例えばある問題を解決するためにはそれを解決出来るライブラリやミドルウェアを探すことから始まる場合が少なくありませんが、そういう作業を行うためにはその周辺の知識が必要です。また概要レベルの説明でそれらのライブラリやミドルウェアの使い方を理解出来るスキルも必要です。それらは経験に裏打ちされた想像力によって初めて可能になります。

同時に今はツールが発達し同じようなプログラムを横展開するような作業はツールに置き換えられています。このように同じ技術を使った横展開可能な開発は少なくなり、どの仕事も新たに技術や手法を調べながら開発する場面が増えています。

しかし、そういう知識や技量のある技術者は限られています。経験豊富でスキルの高い人であれば一人で作業を受け持つ事が出来るかもしれませんが、そういう経験豊富な技術者は多くありませんし、居たとしても先行開発や他の作業者の支援に回る必要があります。

そこで作業に人を割り当てるときは個々の人ではなく自立的に動くける作業ユニットという考え方を導入し、作業に割り当てた人が機能するような考え方が必要です。これは明確なチームを指すものではなく、あくまでも作業に人をアサインするときの考え方として存在するものです。平たく言えば「作業を割り振る時には、その作業を自立的に解決していけることを念頭に人のアサインをしましょう」ということにつきます。一般的には経験豊富な技術者がいくつかのユニットに参加し作業の方向性を出すことなどが考えられます。また、ペアプログラミングのように共同で一つの作業を実行するような、問題解決の方法も考えられます。これらのことはここで繰り返すまでもなく、今までも行われていた普通の考え方です。しかし、よく見受けられるケースとして、ガントチャート上のタスクに人を割り当てることが、スケジュール管理だと考えてしまう傾向があり、その結果優秀な技術者に個別の作業を割り振ってしまうことがあります。一応それでタスクは消化出来るかもしれませんが、それはあくまでも線表上(ガントチャートなど)タスクに人を全て割り振っただけとなることが多くあります。線表上のタスクへの人の割当を優先するあまり、現場の作業のスムーズな展開が阻害されています。ガントチャートを使った場合の問題点はタスクを組み立てるとプロジェクトが円滑に回っていくと錯覚してしまう傾向が強いということです。このため、無理矢理にでも全てのタスクに人を当てはめてしまうことになります。

現在のプロジェクトは画一的な作業は少なくなり、状況に応じて判断をしながら所定の結果を導き出す必要が増えています。このような判断を要求される作業の場合は一人で対応するよりも2,3人のユニットとして対応した方がうまくいく場合があります。

得てして複数の人間で同時にものを考えるよりも、個々に別々のことを並行的に行う方が結果として成果が多くなるように思えます。しかし、現在のように作業や成果物に依存関係が多い場合は並行的に作業をしていても、有効な成果を上げられないことが多くなっています。それは一人で作業している中で決めたことが、ユニット内で合意されるまではあくまでも個人的な決定事項になってしまい、その事項に依存する他の項目の決定事項も仮のものになってしまうからです。それがユニット中で検討され合意されたことはユニットとしての合意となり、それを土台として合意事項を積み重ねていくことが出来るからです。 例えば何度打ち合わせしても毎回参加者が”私の考えではXXXXXXです”と話の最初に”私の考え~”とまだ私見であることを告げて意見することがあります。初めて出す意見の場合は問題無いのですが、これが何度も繰り返されているようだと、やはり合意の積み重ねが出来ていない証拠です。 このようにユニットとして生産的なディスカッションが行えるようになってくると、一人で考えるよりも数段早く物事が決まっていきます。

作業の軌道修正

不確定要素が沢山ある中で「システムをいかに開発すべきか」という課題に取り組まなくてはいけないのが、現在のシステム開発の根本的な難しさを表しています。 そのためには不確定要素を少なくしていく努力と平行して、多少の手戻りはあってもその時点で確かな情報の範囲でプロジェクトを強引にでも前進させ、不確定要素を明確にするように軌道修正しながら進めていくプロジェクト運営が必要になります。

不確定要素を減らすための一つの方策として結果を見せながら、要件を固めていく方法が昔からイテレーション(反復型)開発の中で提案されています。結果を共有することでどこを目指しているかを具体的にイメージすることが出来ます。

そもそも未経験な領域のシステムや新しい価値が求められるシステム開発においてはプロジェクトの進行に伴ってゴールそのものが変ることがよくあります。これはプロジェクトを始めた最初のうちはゴールそのものが漠然としたものであったとしても、検討を重ねる中でより具体的にゴールの姿が見えてくるということが、ゴールが変わったように見える理由です。

そのような漠然としたゴールであっても、決められた時間内に確実に結果を出していくためには、プロジェクトを強引に前に進める必要があります。そのためには「多少の問題があっても走りながら考える」という勇気と、そのための軌道修正の仕組みをプロジェクトとして持つ必要があります。

今までもフェーズ毎に軌道修正を行う考え方がありましたが、なかなか実現されていませんでした。それは軌道修正するためにはスケジュール上のタイミングだけではなく、作業の習慣として軌道修正を受け入れられる文化が身に付いている必要があります。その鍵がPDCAサイクルにあります。

先ほどもあげましたが、ドキュメントが全て揃うまで次のステップに進まない、というドキュメントベースの進捗管理を前提にしている場合は、上流工程に非常に時間がかかるケースがあります。これなどは「全てが分かるまでは次の作業に進まない」という暗黙の考え方に支配された考え方です。この考え方が通用するのは全ての項目がその段階で明らかになるようなケースだけです。それは既に似たようなプロジェクトの経験がある場合か、開発対象が明確でその手順もはっきりしている場合だけです。

それ以外の場合は少なからず手戻りが発生することを前提に、軌道修正を習慣化する努力が必要です。そのポイントは先の先まで厳密に決めないことです。直近のことを明確化し、マイルストーンを明らかにしても道筋は漠然とした状態においておきます。そして直近のことを確実にこなしながら、次の作業を明確化していくことです。

PDCAサイクルの導入

プロジェクトの軌道修正がなかなか実現出来なかった背景には、進め方やゴールを変えることへの準備がなかったことも一因と考えられます。準備とは軌道修正に伴うスケジュールの再調整や作業の見直しが要求されることを指します。それらの見直しに伴う作業が通常の作業とは全く別物として扱われた場合には、軌道修正を行う事はイレギュラーな作業を行う事になってしまい、スケジュールの変更を伴うからです。

やはり軌道修正にともなう変更も通常の作業の一貫として見なせるように習慣化する必要があります。そのためにPDCAで計画(Plan)・実行(Do)・チェック(Check)・アクション(Act)をサイクルとして実現し、それをスケジュールに盛り込み、習慣化することが必要です。

このとき重要なのが検証可能な管理項目を挙げる事です。ここに「What」としての管理項目を使います。つまり、検証可能な成果物をそのサイクルでの管理項目としてスケジューリングします。

What的な管理項目は従来のドキュメントベースでのスケジュール管理でも行われたことですが、その時に陥りやすい問題点として、検証可能な成果物という視点が抜けていることです。成果物としてのドキュメントが出来たか否かに関心があり、その中身を検証することがなおざりになりがちです。これはガントチャートが「タスクを実現すれば想定している成果物を作成出来る」という暗黙の考え方から来ています。

この問題は昔から品質保証の問題として取り上げられ、レビューやインスペクションなどにより品質を保証することが考えられています。しかし、多くの場合、担当者は品質保証よりも納期までに成果物を作成することを優先し、同時にスケジュールを立てている担当者は納期までに成果物ができることに主に関心があります。この問題はスケジュールを立てる人とそのスケジュールを実行する人が分離されており、かつ、両者にとって作業を完了させることが品質を保証することより重視されているためです。それはスケジュールが成果物が出来たか否かを表現できても、成果物の品質についてはうまく表現できていないことも要因の1つと考えられます。

そこで成果物を検証するためにPDCAサイクルを利用します。このサイクルをスケジュールの中に組み込み、作業の結果を評価するタイミングをその中に置きます。

アジャイル開発などで実際に動くソフトウェアを早期に開発するのは、この検証を動くもので実施するという意図があり、作業検証と品質保証に対する1つのやり方を示しています。

しかし、「検証」と言うとイメージとしてプログラムが完全に機能することを想像しがちですが、成果物はプログラムに限りませんので、ここでの検証とは、その作業の結果が次の作業につながるか否かを評価出来ることを指します。つまり、結果を評価することがPDCAのチェックであり、その結果何かしらの対応を取ることがアクションになります。そのチェックとアクションが行える結果を残すことが、作業(Do)を行う上で重要になります。そして先の品質の問題もこのチェックの中で行い、もし品質に問題があれば作業の方法の見直しとしてアクションを取ります。

このようにサイクルとして期間を捕らえ、その進め方を工夫することを習慣化する事で変化に柔軟に対応出来るスケジュールを組み立てる事ができます。

階層化

スケジュール管理は大きく分けると「とき」「こと」「ひと」の3つの側面があります。そして先に挙げたWhatとHowの二つの視点をこの「こと」に当てはめ、それを階層化して視点を切り替えられるようにする事が有効です。そしてWhatを大分類、中分類にHowを小分類に当てはめます。つまり何を行うかを大分類として示し、それをブレークダウンしたものを中分類とします。そしてその中分類をどのように行うかを小分類として扱います。そして大分類を大きな時間間隔で、中分類と小分類を小さな時間間隔で扱います。図4にその構造を示します。

また、階層化の活用方法として役割の異なるロール間では大分類で意識を合わせ、同一ロール内では小分類で意識を合わせます。またスケジュールのサイクルも各々の専門領域によって違うサイクルが存在します。開発部隊とマーケティングでは違うサイクルで各々の仕事を進めるでしょうし、デザイナーと開発者も異なるサイクルを持つと考えられます。しかし、一方で作業の同期を取る必要もあります。このようなときに「とき」の大分類で同期をとり、その中の小分類は各々の部隊で別々のサイクルを回すことが考えられます。つまり、別々のスケジュールで合っても「とき」の大分類のタイミングを合わすことで情報共有のタイミングを計ります。

このように階層を利用して独自の情報と共有する情報を使い分けることで適切な管理項目(ロールに合わせた項目)を導き出し、コミュニケーションロスを減らすようにします。

具体的には「とき」の大分類はマイルストーンのようなものを当てはめ、小分類は週単位などのようなタイムボックスを当てはめます。また「こと」の大分類は検証可能なWhat視点の項目を当てはめます。そして、小分類は作業をイメージできる作業名もしくは成果物を当てはめます。このとき検証可能な項目としてエンドユーザが確認できるユースケースなどを用いることがあります。

images/bg4.png

[図4 階層化]

まとめ

時を基軸にしたスケジュール管理と、その中での管理ポイントについて解説しました。最後に時を基軸にしたスケジュール管理に更に人のモチベーションを考慮する点について解説します。

連載一覧