2016年04月14日

経常的な業務に着目する

  更新日:2016年7月13日(水)
初めての方はこちらを「はじめに

きっかけ


理想的な姿をイメージすると、全てが予定通りなので日々計画に沿って粛々と仕事をしていくという落ち着いた姿が思い浮かびます。このイメージからすれば日々計画外の事が発生してバタバタと対応に追いかけられている姿はあまり良くないという事になります。

以前から自分自身がストレスを感じる局面がありました。
それは開発が佳境で忙しい時に人事への提出物等が急に「○○日までに」といって待った無しの状態で降りてくる事でした。そんな事はやっていられない状況なのに提出期限が迫っていてどうにもなりません。
実は大本の人事部に聞くと元々のスケジュールはそんなに急では無かったのに、組織のヒエラルキーの中で色々な所を経由するとそれぞれで中間マージンの様に日程が取りつくされて行き、実作業をする当の本人に降りて来た時にはギリギリの日程になっていたりします。そういう事が起きる度に「もっと事前に降ろせなかったのか!?」という憤りに近いものを感じていました。以前からそういう思いを抱いていた事もあり今回冷静に考えてみると、そもそも人事向けとかの開発業務以外の部分は経常的なものであって年中行事みたいなものなので一年分の計画を事前に全て立てられるんじゃないのかと気が付きました。過去のデータを拾うと予算関係の○○は期初の第○週だとか消防訓練は○月の○日あたりだとか予想が立ち、しかもそういった経常的なものが思いの外色々浮かび上がってきました。経常的なものという観点では特に分析をしなくとも毎月の末には勤怠の処理をしていたりとか日々明確に意識しているものも沢山あります。また、開発業務の中でも定例で行う進捗会議などは経常的と言えます。

経常業務の計画を立てるメリット


年間の経常的な業務(以降経常業務と呼ぶ)を全て洗い出して作業時間を見積もって計画化してみると、全体のおよそ1/6の時間を占めている事が分かりました。非常に多くて驚きました。
1/6の時間が純粋な開発作業から削られていたと考えると半年で予定していた仕事が一月位延びてしまう事になります。これでは幾ら開発内容を正しく見積もれたとしても計画通りに行くはずもありません。いや、むしろ厳密に見積もれば見積もる程計画通りには行きません。1/6程度の揺らぎを吸収出来る位の大雑把な見積りでなければ計画通りには行きません。

全ての項目を抜けなく計画するという観点から考えただけでも経常業務を計画に組み込む必要はあるのですが、全体として主に以下の様なメリットがあります。
・開発作業の計画をより正しいものにできる
・誰でもが立てられて誰でもが確実に達成できる
・計画化するのでその分の割り込みはほぼ無くなる
・休み(有休)が計画的に取得できる

確実に達成できる計画でリスクが少ないので最初に取り組む事としては最適だと思われます。
休み(有休)に関しては「支給するが取らせない」などというブラックな企業なら別ですが本来の意図からすれば一定の期間毎に取得するべきですから、まさしく経常業務として計画をする事になります。取れる時に取るではなく、開発作業と同様まさしく「計画」するのです。

開発の日程の項目として入れるべきなのか?


経常業務の計画を立てるとして、では経常業務の日程は開発業務の日程と組み合わせた一枚の日程表にするべきなのでしょうか?
自分一人の日程表ならば一枚にして何も問題は無いのですが、リーダーとしてグループに対して標準的な運用とする様な場合では少し悩む部分があります。

まず前提として、経常業務における提出日などのマイルストーンは各人で違う訳ではないのでリーダーが一元的に作成してメンバーに配布する形式が良いと思われます。そうすれば立案作業は一人しかしなくて良いのでグループ全体として見れば無駄を省いて効率を上げる事になります。
また良くある様にリーダーが管理者である場合には更に好都合です。
例えば勤怠の締めが20日で26日に人事部に提出する場合を考えた時、流れ的にはメンバーが自身の締めの処理を実施→リーダーが承認→人事部に提出という事になると思いますが、リーダーが経常業務を立てる役ならば、例えばメンバーは22日に提出、承認処理は24日、人事部提出は25日などと、自身のスケジュールと合わせてメンバーに対するスケジュールの制御も自動的にスムーズに行えます。

さて上記の様に一元的に作成された経常業務の日程をメンバーに配布するとして開発業務の日程との関係で以下の二つのパターンが考えられます。
A.開発分と経常業務分と二枚別々のまま利用する
B.開発分と経常業務分を転記等をして一枚にまとめ上げる

Aの場合開発分と経常業務分の関係性が分かりづらくなってしまい、例えば経常業務の作業をしなければならない日に開発業務の作業も割り振ってしまったりとかミスが発生しやすいです。
Bの場合はその点は良いのですが開発分と経常業務分を併せるところでパワーがかかってしまいます。一般に何か新しい仕組みなどを取り入れて集団で運用しようとする場合には、実際に運用する人に新たな負担がかかる事は致命傷となる可能性があるので極力少なくしなければならないですし、慎重に配慮しなければなりません。さもなければたちまち運用されなくなる可能性があります。
従ってBの場合出来上がった結果の機能的にはAよりも優れているのですが運用に難があるという事になります。もし現在の状況からほとんどパワーがかからずに実現できるという事ならば特にBで問題ないと思います。

自分の場合当時の状況は各メンバーはExcelを使って自由なフォーマットで日程の線を引いている状態でした。従って経常業務の日程を配布してもフォーマットが合わないので各人が自分のフォーマットに転記するという作業が発生する事になります。これではパワーがかかってしまい運用はおぼつきません。
実はこのような観点から当初Bでは運用できないと判断してAで運用してみた事があります。しかし運用してみるとやはりミスが出てしまうのと他人が見ても日程が正しいのかどうかをチェックするのが難しくて続けるのは無理だと判断しました。そこでBで行くしかなくなったのですがこれが意外に悩む事になりました。
もし凄く便利で誰もが納得するようなプロジェクト管理のツールでも導入できれば良いのかもしれませんが、そんな予算は貰えないし導入効果を説得できる様なレベルにもありませんでした。自前でできる事と考えると本質的にはDBにして後は各人が今まで通りの好きなフォーマットで出力するという形にすれば良いのですが、そんなシステムを組む余裕もこれまたありません。結局はExcelベースのままフォーマットを統一するしかありません。
自分個人のフォーマットを捨てさせるという事は心理的な抵抗が大きいので新しいフォーマットは簡単な事や見やすさとか使いやすさみたいなところにも拘る必要があります。端的に言えば「新フォーマットに乗り換えて良かった」と思えなければ必ず運用は失敗します。そこでフォントサイズや色など一枚の情報量が多くてかつ見やすいというデザインを目指して色々試してみたり、計算式を駆使して色々埋め込んで線だけではなく数値で色々出して内容の正しさをチェックしやすくしたりしました。またパワーという意味では当時日程の線を引くのに全員図形の矢印で書いていたのですがこれを止めて、「条件付き書式」の機能を利用してセルに何かを入力したらグレーに塗りつぶされるようにして、矢印の代わりに塗りつぶしで表現するようにしました。(図形の操作は専用だし面倒で注意が必要なので、他の部分同様にセルの操作だけでできれば楽になる)
そういう細々とした色々な工夫をした結果無事に統一的なフォーマットで経常業務分を取り込んだ運用が実現できました。逆に言うとそういう工夫をすれば大掛かりな事をしなくとも実現できるという事でもあります。

一覧


メニュー


記事を広める



posted by 善 at 23:04 | Comment(0) | TrackBack(0) | 計画 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック