ITエンジニアの仕事の勘所について⑫

全工程共通

設計書、テスト仕様書、はたまた企画書。。。あらゆる成果物を作る途中で『中間報告をする』ことの大切さについて

みなさま。
さてさて、WordPressによるブログ投稿第三十一(さんじゅういち)弾を書いている加賀美(カガミ)です。
どうも、こんばんは。

さて(『さて』ばっか💧)、さっそくなのですが、
WordPressブログ第 三十一弾は『中間報告をする』ことについて投稿したいと思います✨

こんなこと、普通の会社ならどこでも新人研修などで習うわ!(怒)
。。。と、お怒りの声を戴きそうですけど(;´∀`)

けどこれまでかがみがITエンジニアとして働いてきた中で印象深かったコトモノを、
あえて投稿しているのがこの『勘所』シリーズなので、
『踊る大捜査線』の和久さんよろしく、40代のおぢさんエンジニアが
あえて口酸っぱく『中間報告をすること』の大切さをお伝えしたいと思います✨

それでは、本投稿も最後まで何卒宜しくお願い致します!

理想は依頼者との以心伝心!?成果物の作成過程で起こる『コミュニケーション・ギャップ』について

はいそれではさっそく本題に入りたいと思います♪

エンジニアであるなら、誰しも一度はパワポやExcel、あるいはWordなどでドキュメントの作成を
依頼されたことがあるかと思います。

詳細設計書、不具合原因の報告書、現行システムの仕様についての調査資料。。。
そしてそういったお仕事を『依頼された方々』と、作成途中で『中間報告』をされるかと思います。

『中間報告をする』。

このことは、依頼された方が自分より上位の方であると緊張するし、
作成過程の成果物に対して叱責を受けたり、
ドヤ顔で作った部分の問題点を炙り出されたりで、
『作成者』からするとできれば頻度を下げたいと思われるかもしれません。

けれど、『中間報告をする』と『しない』とでは、
最終成果物に対して下記のようなギャップが生み出されやすい傾向がございます。

A)依頼者から依頼を受けてから、完成まで一度も『中間報告』をしなかった場合

はい、ちょっと極端ですけれど(;´∀`)
上図は依頼者と初回にお仕事内容を伺ってから、
『一度も』中間報告をしなかった場合に陥りやすい
パターンを表しております。

依頼者と作業者とでは、
通常「見えている世界」が異なるので言葉などを用いたコミュニケーションを
いくらしても『微妙な』ギャップが存在します。

そして、
その『ほんの些細な』ギャップが、時間経過とともに、すなわち成果物の作成が進めば
進むほど大きなギャップとなってしまいます。


これは、上図のイメージで表しているように、依頼者とのギャップが分度器で
表せばほんの一度くらいの違いだとしても、時間経過とともに理想との開きが大きくなって
しまうためです。


もちろん、これはあくまで『たとえ』であり、実際にドキュメントを作成する場合は
作業はもっと複雑なものであると思います。

例えば、作成途中で自分自身で依頼者の指示との違いに気づき、
過去に作ったページなどを手戻りして修正するなどです。

ですが、
中間報告が無いと、往々にして『作業者独自の見解』による暴走が起こりやすいです。

B)依頼者から依頼を受けてから、<ちょくちょく>『中間報告』をした場合

これまた極端な例なんですけど(;^_^A
これ、何のイメージを表したかと言いますと
適切な頻度で『中間報告(=依頼者とのコミュニケーション)』を取ることで、
依頼者の青写真とのギャップの調整がなされていることを表しております。


そして、まぁあくまで理想的なパターンなんですけど、
適切な中間報告のおかげで、依頼者の青写真通りの最終成果物ができあがり、
結果、『完了報告』以降の『手戻り修正』などが皆無の状態となっております。

ここら辺にご注意!『中間報告をすること』

さて、前節で両極端なご説明をさせて戴きましたが、(;^_^A
『中間報告をする』際のご注意など箇条書きさせて戴きます。

①成果物が単純であればそれほどコミュニケーション・ギャップは生じない。

はい、当たり前ですよね(;^_^A
例えば

『xxxフォルダ配下のファイル、一つ一つ開いて中身コピーしてスケジュールに貼り付けといて』

とかであればまぁ数によっては中間報告が必要でしょうけど、
少なくともコミュニケーション・ギャップによる手戻りとかは起きなさそうですよね(;´∀`)

②『中間報告』の頻度が多すぎると依頼者は困ってしまう

これも当たり前の話ですけど(;´∀`)

そもそも、依頼者の方は司令塔の役割の方であるか、
または他の重要な打ち合わせなどがあるから作業者に依頼をかけているのだと
思います。

また、コミュニケーションの頻度が多すぎると、
コミュニケーションを取ること自体の工数が肥大化して、
結局納期に間に合わなくなることだってあるかと思います。

③『わからない箇所』で作業をストップさせない

どこか別の個所でもお伝えしたかもしれませんが、
作業をしていて『わからない箇所』があれば、
定期的な中間報告以外でも良いので
依頼者または有識者の方に質問をしたほうが良いでしょう。


そこがボトルネックとなって進捗が遅れてしまうのであれば
その影響は大きいと思います。

あくまで経験則ですが、
15分経っても自己解決できなければ、
質問事項として控えておいたほうが良いのではと思います。

また状況によっては質問は五月雨式ではなく、
定期の中間報告の際に
まとめて報告するほうが良いかもしれません。

そしてその場合は、
その問題点以外で進められる個所をどしどし進めるべきです。

結びに

どうでしょう?
今回も退屈でしたかね(;^_^A。

ちなみに今回使った図は、
とある超大手ユー子のプロパーSEの方から口頭で教わった内容
ほぼそのままを図にした(つもりの;)ものとなります。

当時かがみは
エンジニアとしてはまだ駆け出しであり、
わかりやすい説明に本当に関心致しました。

SIerのユー子といえば
ドエンドユーザーとのやり取りも多く、
ためにわかりやすい説明をするというスキルに長けていたのかもしません。

とまぁ巷では高給取りのわりに
敬遠されがちな日本のSIerのSEですが、
なかなか数値化、数量化しにくいですが、
けっこう高度なスキルを保持しているのかなぁと
かがみは思います💧

逆にたまに聴くお話ではこれまで開発中心でやってきた会社が、
直接受注してシステム構築の最上流から手掛けようとしたところ
けっこう苦労しました、みたいなケースも。

理想は技術のキャッチアップに長けたSEですかね💧
赤間信幸さんという方の『業務システム開発モダナイゼーションガイド』という本では、
業務知識の長けたSEがWeb系企業などが利用している最新技術などを学び、
取り入れることが主張されております。

これこそ巷で聴く『リスキリング(Re-skilling)』なのかもしれませんね(;^_^

ところで、
ドキュメントなどの成果物の難易度や複雑度が高い場合、
中間報告をこまめに行うべしという
今回のテーマは、
ある意味システム開発手法におけるアジャイルに通ずるものがあるのかもと、
今回のブログを書いていてかがみはそう思いました。

ようするに、
フィードバックループを回せ、
ということですよね(;^_^A

ここで言う『フィードバック』とは、
アウトプットの内容をこまめに見直すことで、未来を微調整する
ことをかがみはイメージしております。

次回は、『プロ意識を持つ』をテーマに投稿をする予定です。

それでは、今回は以上となります。
最後までお読み戴きありがとうございました。














私たちみんなに、明日も良いことありますように✨

タイトルとURLをコピーしました