■

(2)『情報整理を行うことによる政治利用目的』のこと。

自分ひとりで全てを抱えること。
組織活動においてこのことはしばしば問題として扱われる。

おいらも問題視する。
そいつが仕事ができない！というのであれば分担を考えるし、
そいつしか問題解決ができない！というのであれば、
その状況そのものを考える。

本人としては「周りに任せたら終わるもんも終わらねぇ！」と思いも実感もしていても、
その本人が明日トラックにはねられないとは限らないのです。
万が一助かっても、病院のベットの上で後処理に追われたくはありません。

っというありきたりなところから入り。

平常時は自身のためだけに行っておけばよいこの行為も、
ヤバイ雰囲気漂うプロジェクトや、
書類しか信じないプロジェクトマネージャがいるプロジェクトや、
精神論しかはかない知識不足の上司がいるチームなどにいる場合には
もうちょい手を加えることで立派な武器になる。
大きく分けて2種類。
　・自衛のため
　・作業分割のため
いずれにしろ、マネージャクラスを巻き込まなきゃいけないので、
見せる時の体裁は多少気にする必要はでてくる。

＜自衛の章＞
自身の作業を細分化し、項目分けを行い、今までの作業をそれに当てはめる。
そうすれば現状の作業に対する実績値をだせる。
どこかの誰かが想像で語る希望的観測値ではなく、
紛れも無い現実の数字である。
これが目に見える形で出来るのである。

いかに楽してるかとか
いかに苦労しているかとか
想像していたことが目にみえるようになるのはなかなか新鮮に映る。

これからくる作業予定をこの数値をもとに判定すると、
無理無茶無謀な要求も実績ベースで時間がないと言える材料になる。
なにしろ目に見えるのだから、想像と希望だけで無茶は言えなくなる。
どんなアホでも数値を目の前に出されると、その数値から大きくそれることを言わなくなる。
昨日は9、今日はがんばって10、明日も9、こんな表を可視化してある中で、
明後日いきなり100やれと臆面もなく言えるヤツはよっぽどなやつだ。ってくらいいない。

プロジェクトの規模があれば、
自身の実績を算出した過程を他のメンバーにも適用することが出来る。
1人のデータで納得されなければ複数集めたらよい。
算出労力が少なければ少ないほど他人は協力してくれる傾向にある。
これを利用しない手は無い。

信頼性の高いデータは信じるより他になく、
信じないと突っぱねるにはそれなりのパワーが要る。
そんな計算をさせてみるのも、何もしないよりは効果は上がるもんだ。

＜作業分割の章＞
自分がプログラムを作るときに。
必ずやることになるめんどい事がある。
仕様書という名の要望定義書を受け取ったら解析しなきゃいかんとか、
テスト仕様書始め、書類をあげなきゃいかんとか、
HTMLを解析せにゃいかんとか、
デザイン画を元に画面仕上げないかんとか、
DBの項目一覧を探すとか作るとか多岐に渡るいろいろ。

1人であれば全部せなあかん。
しかして複数人いたらどうなの？っと。
1人1人が1つずつやらなきゃいけない理由があるのかと。*1
複数人いたらその複数人で全員分を期間内に仕上げたらいいんちゃうんと。
そう思うのだ。

そうするために。
作業を細分化する。
ドキュメント整理や、要望定義書の解析などの準備から、
ソースコード構築や、クラス単位でのテストを行うプログラミングから、
最後に一連の動作を行う仕上げのテストまで。

その時のプロジェクトに合せて分割する。
分割した作業種別を、プログラムを作らなあかん各機能に対して割り振る。
割り振ったらあとは誰がどこ受け持つか、
いつまでにどれやるかなど決めることができる。
行き詰っていても、誰しもが誰がどこで詰まったかを説明するのに
「ここで今詰まってます」を言う以上の時間を必要としない。
チーム内で、チーム外へ、情報の共有化を行いやすくするための手法となる。

ゆえに。
単純なことであれば、どこかのだれかに手伝ってもらいやすくなる。
作業の範囲が詳細化される事で明確になっているからだ。
(,,ﾟДﾟ)＜ごめんやけど、ここのこんだけやっといて〜

これがやってない場合には状況説明も必要とされるため、
(,,ﾟДﾟ)＜ごめんやけど、ここのこれのこんなことやねんけど、手伝ってもらわれへんかな〜

ってな具合になるだろう。
後者のは絶対何かのイワク付きの勧誘だと勘ぐってしまう。おいらは。

まとめ

自分の手順を細分化できるかどうか。
まず聞くことで、力量を知るための大まかな目安として利用できる。
そして実践することで、自身の作業効率化が図れる様になる。
さらに応用活用することで、周囲を巻き込んだ更なる効率化が図れるようになる。

ってことかな〜。

*1:経験上まず必要が無いのだが。