第７８８回　「仕事遂行の絶対要件・鉄則」

私たちの業界が手がける仕事のパターンは、多種多様です。
パターンの分類方法も多種なのですが、最もシンプルな分類は、目標とするシステムの構築全体を遂行するのか、切り出された部分のみを構築するのか、の範囲の違いがそのひとつです。

システム構築全体を業務遂行するには、それなりの高い技術、テクニックを要します。
一方、部分のみを構築遂行するケースは、現場遂行者にとってより一層の高い技術、テクニックが要求されます。
何故なら、一部だけを遂行して優れた結果を残すためには、算出する成果物の全体との整合性、調和を最低限維持する事が課されるからです。

そのためには、業務遂行課程と遂行組織のそれぞれにおける全体との整合性、一定の調和を維持する事が要求されます。
つまり、自分たちが担当すべき部分の全体における位置づけ、役割、影響性を十分考慮して業務遂行しなければ、業務は終了しません。

昨年の秋から現在も引き続き遂行中の業務案件の例です。
我々は、プロジェクト発足の早々に、機能プログラム間共通部品プログラムの開発をするよう要請を受けました。
ところが、実際に業務遂行に着手してみると、詳細設計が未了であることが判りました。

恐らく工期を短縮する目的で、そのような無謀な業務遂行指示となったのだろうと、推測します。
一方、担当したスタッフはその不足部分を力技で埋めようと、試みたようです。
その熱意は、大変評価するのですが、それでは問題が複雑化してしまい、負の影響を蔓延らせてしまいました。

設計が完了していないため、実装が完成したものの発注側指示者（設計者）との間の齟齬が、いろんな箇所に発覚しました。
その都度プログラムは改訂するのですが、以下のような多くの問題が発生し、未だその対応中です。
改訂仕様指示が口頭の為、「言った。言わない。」の論争が続いています。

周囲と上手く整合しないプログラム箇所に絞ったピンポイント改訂を行なうため、全体としての機能の相関関係が崩れてしまいました。
さらに、共通部品であったため、本流のプログラム開発への影響が大きく、本流の開発遅延や工数増大化を招いています。

ここで言わんとするのは、業務遂行要件が十分整理されない状況で業務遂行に着手すると、品質、コスト、納期の３大業務遂行要件を満たすことが出来ない、と言う指摘です。
一方、仕事を引き受ける場合、条件が十分整備された仕事ばかりを選べるような立場にはない事が、一般的です。

それにも拘らず、仕事の遂行要件である品質、コスト、納期を満たさなければ、成果が認められないのも一般的です。

成果が認められないと、あるいは成果を出す以前に業務遂行環境から受けるプレッシャーに押し潰されそうになると、責任を外部に転嫁し勝ちに成ります。

例えば、運が悪くこういう案件の仕事に従事させられてしまった。上司のフォローが不十分だった、などです。

勿論、上司はフォローすべきですが、スタッフ自らが上司に手を差し伸べさせるよう働きかけが要ります。

上司を自らが動かす工夫をせずに、負の状態に陥っていることに気付かない上司や、任命された業務の質へ不満を漏らすのは、組織人としての自立心の欠如、甘えに過ぎません。
要は、自分の問題として捉え自分で解決しなければならないのです。

そういうことを指摘しますと、次のような反論をよく受けます。
経験の浅い者が、業務遂行条件・環境整備のお願いをしても、建設的な意見を述べても耳を貸してもらえない、と言うような反論です。
確かに、場によっては、意見やお願いをし辛い場合が多くあります。

そういう場合は、意見を述べることの出来る立場にある人にお願いする。

口頭でのお願いではなく、文章（メールなど）でお願いする。

または“行きつ・戻りつ”の業務遂行にならないよう現場の相互承認ルールを整備する。

等々、仕事の現場では、知恵と工夫を働かせ、何とか自分達に与えられたリソースだけで品質、コスト、納期を満たし業務遂行を完了することが、絶対要件です。

非常にシンプルな要件のはずですが、細部から問題を解決しようとすると複雑になってしまいます。問題解決は根源から、と言うのも鉄則です。