久しぶりに計画関連の話です。
これまでは考え方の話がメインでしたが今回は実践的な話です。
「複数のスケールを用いる」でどの様なスケールで運用するのが良いのかは一概には決められないという話をしました。それは確かにそうなのですが一番小さいスケールにはおススメがあります。それが今回の内容です。
最小はいくつが良いか
スケールという概念が無い状態でスケジュールを管理していると、会議の開始時刻などで「１６：１５」などの様に１０分、５分もしかしたら１分単位でスケジューリングしているかもしれません。もしそれをそのままスケールとして採用したとしたら、一分などという単位では運用しようとしても到底できません。スケールが小さくなって細かくなればなるほど運用は大変になります。かといって粗くすると今度は精度が落ちてしまいます。そこのバランスをどのあたりに取るのが良いのかというのが最小値の検討という事になります。
値の検討
まず最初に明らかだったのは「経常的な業務に着目する」で書いた様に経常的な業務は単独で計画できる必要があったので目安としては数時間程度にする必要があるという事でした。つまり勤怠処理や定例の進捗会議などの経常的な業務は、日程の大体一目盛り分になるようにしたいという事です。もしスケールを一日単位などにしてまうとその日はそういった経常的な業務を一つこなして終わりという事になってしまい、その日は本来の開発業務はできない事になってしまいます。これではいくら何でも粗すぎるので少なくとも数時間程度に細かくする必要はあるだろうという判断です。
それでは何時間にすれば良いのでしょうか。
この検討をしていた当時はグループ全員がまだ全然物事を計画的に進める事が出来ず、日程はいつも遅れていました。そこで考えたのは仮に一つの作業（日程の一目盛り分）が丸々失敗したような場合でもその日のうちにリカバリーできるようにすれば良いのではないかという事でした。つまり一目盛り分をその日のうちにもう一度やり直せるようにするという事です。その日のうちにリカバリーできれば一日単位で見た時には特に問題は無いという事になります。こう考えるとリカバリー作業（やり直し）ができる時間的余裕がまさしく最小のスケールの単位になると考えられます。
リカバリー作業かできる時間がどこにあるのかと言えば、それは単純に残業時間という事になります。残業時間といっても「メンタルヘルスについて」で少し述べた様に通常の業務では疲労が溜まらないようにしならければならないので深夜残業になるべきではありません。従って２２時までの４時間程度という事になります。
この様に考えた結果、４時間がスケールの最小単位になるという結論になりましたが、当時は実情として残業をするのが当たり前の状態だったので運用するとしたらリカバリーに残業時間を丸々使うというのは難しいだろうと思いました。そこでとりあえずは半分の２時間として実際の運用の中で値を探る事にしました。
運用を考慮した値
一旦、値としては２時間と確定したのですが、実際の運用を検討し始めると少し困った問題が発生しました。一つには定時までの一日の就労時間は８時間弱だったので２時間の目盛りで分割しようとしても割り切れなかったのです。もう一つは朝の就業開始から２時間ずつ目盛りを区切って行くと昼休みが２時間の境界に来ないのです。つまり昼休みを挟んで一目盛りとなってしまってなんとも運用しずらそうになってしまったのです。
色々考えた結果、結局２時間というのはやめました。というよりそもそも時間という単位自体をやめました。新たに「コマ」という単位で呼ぶようにして一日を次の様にコマ割しました。
| コマ | 区分 | 時間 |
| １コマ | 午前 | １０時 ～ 昼 |
| ２コマ | 午後一 | ～ １５時 |
| ３コマ | 午後二 | ～ 定時 |
| ４コマ | 残業一 | ～ ２０時 |
| ５コマ | 残業二 | ～ ２２時 |
勿論休み時間は除きます。一コマは大体２時間位で、時間で表現すると各コマの長さはバラバラになります。カレンダーの「月」の様なものです。一ヶ月は３０日だったり３１日だったりしますが一ヶ月は一ヶ月です。
１コマ目が１０時からなので朝が少し時間が空き過ぎるような気はしましたが、実際に運用してみると、前日の諸々の雑用なんかを朝一で処理出来て１コマから本業に集中して取り掛かれるので寧ろ好都合でした。逆にもしこの部分の余裕が無かったらうまく運用を続けられなかったかもしれません。
実際に運用する為の工夫
最小のスケールの単位は以上の様に決まりましが、これを実際に運用する為にはかなり細かい単位なので工夫しなければ難しいと考えました。その工夫が「時間割」という訳です。
概要を説明します。
前提として運用は自分のグループで全員に行いました。
立案は他のスケールと同様にガントチャート的な線表で立案します。それを形式を変換して時間割の形式で紙に出せる形にしました。
なぜ線表ではなくわざわざ時間割の形式にしたかというと、自分自身が今何をしなければならないかを頭に従ってやるのではなく、いつも紙を確認する事で計画に従って行動するという形にしたかったからです。計画書や日程表ではその他諸々の文書と一緒にしまわれて、どうしても見なければならない時だけ見るという形になってしまいます。そうではなく普段の仕事の中でもっと密着したものとして、まさしく学校の時間割の様に「えっと次は何だったっけな？」と確認するような存在にしたかったのです。
運用を始めると実際にメンバーの中には毎週机の前のパーティションにこの時間割を貼っている者もいました。
そして更に重要な事は変更に関してです。
このレベルのスケールになると普通に計画（予定）が狂います。それは遅れや割り込みなどによって起きますが、この時にやはり頭の中で修正するのではなくちゃんと計画を変更するという事、大袈裟に言えば計画を今一度立て直すというプロセスが必要です。このプロセスをやらない限りは計画的に進める事はできないと考えていました。ところが先程と同様にその他諸々の文書と同じ様に管理されているようでは容易に変更できません。それが時間割の形で紙で持っていれば変更が発生したその場で書き込んで修正ができます。スケジュール帳を修正する様な感覚です。
勿論紙ではなくともタブレットなどで上記の要件が満たせる様ならばそれで構わないと思います。
以降詳細を説明します。
形式
以下が実際の形式の例です。
一週間分でＡ４一枚になります。
先頭の「版数」は元となった日程表の版数です。
横方向に月曜日から曜日が並びます。
色のついた列のタイトル内は日付です。日付で「()」が付いている日は休日です。
縦方向は１コマから５コマ＋備考欄です。
深夜残業は計画するものでは無く、あくまで突発的な緊急事態の時に行うものという前提です。
朝一に処理する雑用だとか諸々のメモだとかを記入するスペースとして備考欄を設けているので、深夜残業も含め計画外の諸々の事はそのスペースで適宜管理できるようにしています。
べき論ではなく、あくまでこの紙が日常の中で使う人にとって有用なものになる必要があります。そうでないと「常に確認する」といった行為は難しくなってしまいます。
上の月曜日部分の内容を拡大してコマの中の記述の説明をします。
中の記述に関してはあくまで参考ですが、以下の様な内容で運用していました。
□：作業終了を記入するチェックボックス。
コード：元の日程表上のコード。対応付けの為。
項目：二つ上位のスケールから"/"で階層的に表現しています。
例えばこの場合はスケールの単位は"月/週/コマ"のようになっています。
(終了日)：該当する作業項目の一つ上位のスケールの終了日です。
例えば３コマ目だと"下期・実績申告"の終了日（期限）になります。
立案
立案の運用については組織の状態に応じて変わると思いますので、あくまで一例としてご紹介します。
プロジェクトの計画は勿論スタートの時点で立案します。この時のスケールは普通は週単位まで立案していました。そして週の下位が今回の時間割に相当するコマとしていたのですが、流石に半年とか一年の期間をコマで計画するのは無理です。そこでコマのレベルは一ヶ月に一度、月末に「再来月」の一月分を立案するようにしました。つまり来月の分は既に先月立案済という事になります。
なぜ再来月にしたかというと、月末にとって来月というのは極端な場合は明日かもしれないので余裕がなく危険だからです。それに来月分を立案してみたら本当は今月に何か取り組んでおきたかった事などがあるかもしれません。その場合は手遅れになってしまいます。なので再来月分の立案という形をとり、場合によってはその時に来月分の修正も行う形にしました。
このやり方で可能性として問題が考えられるのは、プロジェクト全体の計画はスタート時に出来上がっていてそれに対して最も詳細なコマの単位の日程は毎月その都度立てられるので立ててみた結果最初の全体の日程に収まらないという場合があり得ます。論理的にはこういった可能性はありますが実際は何年も運用してみても一度も発生しませんでした。勿論実績として遅れが発生した事はいくらでもありますが、立案時にそのような問題が発生した事はありませんでした。
変更
次に変更について説明します。
まず、予定通りにいかなかった場合に実際にどのように時間割を修正するかという事を説明します。
例えば月曜２コマの作業が遅れてしまって終わらなかったとします。この場合どこかの空きコマに続きの作業を予定として入れる形になります。終わらなかったからといってそのまま続けてはいけません。各コマの終了時刻でその一コマは終了であって、そこで終わっていなければ実績としては「未達」という事になります。
説明の為に矢印を記入しているのではなく、実際に赤ペンでこの様に書き込んで、自分なりに「２コマの続きを４コマに入れた」という事を表していました。
遅れた続きの作業を時間的に連続して行いたいという事もあると思います。
例えば同じく月曜２コマの作業が終わらなかった場合に、残りの作業をそのまま３コマに続けたいとします。そういう場合はまず３コマを空ける必要がありますから、３コマをどこかの空きコマに移して２コマの続きの作業を３コマに入れます。
割り込みも同様で新たにコマを割り振る作業をする事になります。
「なぜ割り込みを断れないのか」で少し述べましたが、この時にもう割り振るコマが無い様な状態ならば、その割り込みはこのタイミングでは受けられないという事です。来週まで含めて作業項目を玉突きしていけば空ける事が出来るかもしれませんが、そんなに作業が詰まった状態で来週に回して大丈夫な作業項目はあまり無いと思われます。
ただし、五分、十分程度の割り込みは吸収できるような立案の仕方をする必要があります。その程度で計画を変更しなければならないようでは、例え割り込みが無くとも、このスケールでの運用は難しいです。
コマを移動するなどの記法は特に定義は無く、各人好きな様に運用していました。
別に矢印を引かなくとも「月曜２コマの続き」と書き込むのでも勿論問題ありません。
重要な事は必ず時間割を見て紙面上でコマのやりくりをするという事です。それが計画の変更というプロセスに他ならないという事です。
注意点
いくつか注意点があります。
空きコマの確保について
まず、変更といっても無限に空きコマを食いつぶして行ける訳ではありません。
コマというのはあくまで一つ上位のスケールをブレイクダウンしたものなので、その日程を無視して後ろに延ばす事はできません。以下の図でスケール間の関係を説明します。
この図では月、週、コマのスケールの日程表（時間割）が表現されています。
各スケールはそれぞれ上位のスケールのブレイクダウンになっています。それを赤線で表しました。
具体的な内容で説明すると、まず月のレベルでは４月は「仕様」という事になっています。
それを週のレベルで見ると四つの作業項目に落とし込まれて、それぞれに一週ずつ費やす日程になっています。
その一週ずつが更にコマのレベルの作業項目に落とし込まれて時間割になります。
この例では三週目の「ＵＩ」が今週という想定になっていますが、ここで、もし今週の時間割をこなしている中で遅れが発生して、かつ今週はもう空きコマが無い場合を考えてみるとします。
その場合、時間割だけを見ていると来週のどこかの空きコマに入れれば良い様に思えます。しかし週のレベルで見てみればこの図の例では三週目の「ＵＩ」が終わらなかった事を意味しています。そうなると時間割の時に一コマが終わって予定した内容が終わっていなかった場合と全く同様に、計画を「変更」しなければなりません。
こうなると大ごとです。
なぜなら週レベルの計画はスタート時にプロジェクト全体の計画として立案していますし、コマの様にリカバリーの為のバッファーなどは設けていません。なので、もし時間割の時と同じように「ＵＩの続き」を単純に次の週に入れてしまうと、元々の四週目の「調整・ＦＩＸ」は玉突きで次週に押し出されることになります。これが意味しているところは今説明している時間割の話と全く同じで、上位のスケールである月のレベルで見れば４月の「仕様」が終わらなかった事を意味しています。そこで「仕様の続き」を５月に入れてしまうと、元々の５月の「設計」が押し出されて、結局玉突きでリリースが一ヶ月遅れる事になります。
見積もりについて
「小数値の見積もり」で少し触れましたが、最小の単位はコマであってそれより小さい一時間とか三十分などの単位で見積もってはいけません。例えば全然関係ない二つの作業項目をそれぞれ一時間だからといって無理やり抱き合わせにして一コマに入れる様な事はダメです。それぞれ一コマずつ確保する必要があります。
逆に一つの作業項目が複数コマになるような立て方もダメです。つまり製造１、製造２、製造３みたいな作業項目の立案はだめだという事です。それぞれが○○関数作成、△△関数作成、□□関数作成の様に一コマ単位の作業にまで検討して落とし込む必要があります。なぜなら製造１、製造２、製造３では要は製造という作業を一日（三コマ）やるという計画にしかなっていないからです。つまり有効数字の様なもので精度がコマという桁まで求められているという事になります。
時間割のメリット
スケールという考えで時間割のレベルまで適切に運用されると、以下の様な色々なメリットがあります。
全体的な感覚
まず総括として全体的な感覚について述べたいと思います。
時間割で運用する前は一日単位で立案していましたが、その時と比較すると、一日単位の時は実際に作業をする具体的なイメージがまだ何かぼんやりしていて「何となく」という感じでした。それがコマ単位の時間割で運用を始めると、なんとなくではなく全てを意識出来て自分がコントロールしている感覚になりました。日程が目標ではなく初めて自分で制御可能なものになった感じでした。
全てが管理され制御可能になる
一日単位だと会議とかの一日未満の事については別途管理する必要がありました。皆スケジュール帳的なもので管理していました。これがコマ単位になる事で会議など全ての事が計画出来るようになり、全て計画に一本化されて、スケジュール帳などとの二重管理はなくなりました。これによりまさしく就業中の全ての活動が管理され計画できるようになりました。
個人的には特に「経常的な業務に着目する」で書いた様に経常的な業務は全体の１／６を占めていたので、その分を計画出来る様になったのは大きかったです。
デジタル的な効率の良さ
スケジュール帳では時間の管理がアナログ的だったものが時間割だと量子化されたデジタルになるので扱いやすくなりスムーズになります。例えばグループで集まる為に全員の空いてる時間を調整する姿を想像してください。「○時からなら」とか「△時半からなら」とかに対して「３コマなら」「２コマからなら」といった具合になる訳です。根本的には「時間という資源」が一週間で高々２０個前後をコントロールするだけで良くなるという事を意味しています。
リリース（納期）に対する明確な意識が身に付く
全てのスケールの日程が繋がる事で、一番大きなスケールから順番にブレイクダウンして行き、直接今行う作業にまで繋がります。そして先程の「注意点」で説明した通り今行っている作業が場合によっては直接リリースを遅れさせるという事が分かります。これは運用を通して誰もが意識せざるを得ません。全ての人が日々の自分の数時間程度の作業が半年後、一年後の製品のリリースにどう影響するかを意識した状態になるという事です。もしかしたら少しシビアな状態に思えるかもしれませんが、逆なのです。これが普通の状態なのです。本来はプロジェクトの初期だろうと終盤だろうと、今の自分の作業がリリース（納期）にどう影響するのかを分からなければおかしいのです。それが繋がりが良く見えないので最初の方では遅れてもなんとなくリカバリーできる様な「気分」になってしまうだけなのです。
「計画＝主」という意識が身に付く
最も重要な事は「計画＝主」だという感覚が身に付いて行くという事です。いかなる時でも計画的に進められる為には、自分の行動の主は自分ではなく計画だという価値観の転換がどこかで必要です。それは法律に似ていて法律は人間が立てるものですが、立てた法律にはいかなる人でも従わなければなりません。もしその法律を守るのが難しいならば勝手に破るのではなく法律を改正しなければなりません。計画も全く同じです。一たび立案したら何人もそれに従わなければなりません。もし従えない場合は先に計画の変更をしなければなりません。あくまで人間は計画に「従う」存在です。
運用をしていく中で次第にこういう感覚が身に付いていきます。
最後に
勿論この様な事を実施するのはハードルが高くて難しいと感じる人もいると思います。
ですから法律と同様に「普通の人」が運用できそうなレベルに無いならば無理しない方が良いかもしれません。
勿論仕組みを作ったり、教育したり、色々とハードルを下げる工夫は必要です。
しかしその様に色々とハードルを下げる作戦を練ってみても、それでも運用が難しそうに思えるならば、無理をするのではなく、腰を据えてじっくり準備をする必要があるという事だと思います。
