プロジェクト型技術業務を自社の技術的知見として蓄積するには

一般的になりつつある「プロジェクト型業務」。

これは、技術的な業務でも同じことです。

 

技術的なプロジェクト業務の大まかな流れは以下の通りです。

 

1. 技術的な課題解決といったターゲットを決める。

 

2. ターゲットに向かってどのように進んでいくのかという手順概要を示した、技術評価計画書を作成する。

 

3. プロジェクトに参画する技術者とその役割を明文化の上、共有する。

 

4. プロジェクトの概要と流れ、そしてゴールを示した資料をベースにプロジェクトキックオフ。

 

 

上記に関連するコラムとして、以下のようなものを述べたことがあります。

 

技術テーマは個人プレーではなくプロジェクト化する

 

技術者にマネジメント力をつけさせたい

 

若手技術者の暴走や立ち止まり回避に効果的な 技術評価計

 

 

恐らく多くの企業においても、上記のようなキックオフまではできているのではないかと思います。

 

この後は進捗確認に加え、適宜課題の抽出と共有、
並びにそれに対する指示やフォローを加えるといったマネジメントを行いながら、
プロジェクトを前に進めていきます。

 

 

日々のプロジェクト推進でのポイントは議事録を残すということ。

 

この辺りは以下のようなコラムで述べたことがあります。

 

生産性向上を目指した 工程変更推進 において、若手技術者に何をやらせるべきか

 

情報は 鮮度 が大切ということを意識させる

 

対面での打ち合わせやコミュニケーションの頻度と時間が限られる昨今では、
このような軸をぶらさないプロジェクト型の業務が基本となることについて、
異論のある方は少ないかと思います。

 

 

 

 

 

プロジェクト型業務を自社の血肉とするには完了のやり方が重要

 

多くの企業においての共通の願いは、

 

 

「業務を通じて得られた技術的知見が個人の頭で収まらずに企業のものとする」

 

 

という、

 

 

技術的知見やノウハウを企業のものとして蓄積する

 

 

事だと思います。

 

 

 

技術系企業の多くが直面する、ベテラン技術者の退職による技術の伝承不足、ということも本課題の一側面です。

 

 

技術の伝承は多くの技術系企業の抱える共通課題の一つとも言え、
過去にも何度かコラムやメルマガのテーマとして取り上げたことがあります。

 

技術の伝承 に必要なものは何か

 

 

技術伝承の難しさ

 

 

自社技術がじり貧となる危機打破に必要な技術者育成

 

 

 

生産性」という言葉がクローズアップされる昨今ではありますが、
まず第一に重要視しなくてはいけないのは、

 

業務に後戻りが無く、やったことが記録として蓄積されていくこと

 

です。

 

 

 

効率よくやるというのは、この辺りができた後の話なのです。

 

 

プロジェクト型業務を企業の知見として蓄積し、
伝承していくためには、業務を個々人の技術者の中にとどめず、
記録として残していくことが基本となります。

 

つまり、プロジェクト型業務は企画や推進はもちろん、
多くの企業で見逃されがちな「記録」に予め意識を持つことがポイントなのです。

 

 

 

 

 

プロジェクト型業務は複数の技術報告書を土台とする完了報告書という記録でまとめる

 

プロジェクト型業務は最後はテーマ完了報告書としてまとめることで、技術の伝承が可能となる

(Photographed by Markus Spiske)

 

プロジェクト型業務でまとめるというと、
膨大な資料を一緒くたに入れ、
それを一つの塊とするイメージを持つ方がいるかもしれません。

残念ながらこの手の膨大な量を基本とした報告書は、あまり読まれません。

 

当然ながら無いよりはずっといいのですが、
読まれない、または読む気を起こさせない時点で記録としては望ましいとは言えません。

 

そして何より、このような分量の大きい報告書を書くとなると、
書く方の負担も大変大きくなります。

 

 

 

このような事態を回避するために重要な役割を果たすのが、

 

技術報告書

 

です。

 

技術報告書については何度か取り上げたことがありますが、
一般的なビジネス文書とは異なる、
という点について技術者とマネジメントに理解いただくのは第一歩だと思います

 

ビジネス文書 と技術報告書の共通点と違い

 

 

技術報告書というと、技術者の多くは考察項をよく考えながら書くことが最も大切と考えるようですが、

 

 

「技術的な業務を通じて判明した事実を伝え、予め設定した目的に対して、結論で回答が導き出されているか」

 

 

という観点の方が大切です。つまり、

 

 

考察以前に事実をきちんと伝えられているか

 

の方が圧倒的に重要なのです。考察を考えるのは、事実をきちんと伝えられた後です。

 

 

 

 

プロジェクト型業務の中でも複数の技術評価や実験、作業等を行うと思います。

 

 

この技術的業務について、都度、技術報告書を作成しておくのです。

 

 

こうすると、その技術報告書の分量自体はそれほど多くならない上、
該当する技術業務の焦点が絞られるため、
書く側である技術者も書きやすくなり、また読み手から見て読みやすいものとなります。

 

 

そして、プロジェクト型業務の完了報告書というのは、

 

 

「プロジェクト型の技術業務で蓄積されてきた技術報告書をまとめる」

 

 

という内容になるのです。

 

 

技術報告書の構成と記載内容が的確であれば、
該当する技術業務の要点は既に抽出された状態にあるはずです。

 

完了報告書は、作成されてきた技術報告書を部品として組み立てることで完成となります。

 

詳細は技術報告書を参照させることで、記載内容は大幅に圧縮され、
読む側としては全体を理解することができるようになります。

 

必要に応じて詳細を見たいという要望は技術報告書が担うことで、
技術的知見の蓄積と伝承という役割を果たし、
また技術的なプロジェクトの完了報告書は、
そのプロジェクト全体を見渡す俯瞰的な視点を提供することが可能となります。

 

 

 

 

 

テーマ完了報告書の基本内容

 

技術的プロジェクト完了の時点で作成するテーマ完了報告書として網羅すべきは以下の観点です。

 

1.テーマ名、推進期間

 

2.テーマの到達目標

 

3.到達目標に対する実績、成果

 

4.本テーマ推進における課題

 

5.今後の展開への提言

 

 

それぞれ概要を述べます。

 

1.テーマ名、推進期間

これは、プロジェクトの看板ともいえるテーマ名を記載し、その期間を書きます。
将来検索された際に見つけやすくする、ということが主な狙いにあります。

 

2.テーマの到達目標

当初の狙いが何だったかを記載します。
ここは技術評価計画に記載された内容を明記する形となります。

 

3.到達目標に対する実績、成果

目標に対し、実際に何がわかったのか、何が成果だったのかについて記載します。
ここの項目で技術報告書の内容が参照されることが多くなります。

 

目標を達成できなかったとしても、それはそれで実績であり成果といえます。
もしかすると、この時は無駄と感じたことが、将来役に立つ知見となるかもしれません。

 

このように、うまくいかなかったことも決して無駄ではないことを技術者に理解させることも大切です。

 

4.本テーマ推進における課題

100点満点で終わる技術的プロジェクト型業務は皆無です。
突き詰め切れなかったこと、うまくいかなかったこと、わからなかったこと、
追加で評価しなければならないことなどが多く存在します。

これらを述べることで、今後の新しい展開に向けた検討の一助としてもらうことを狙いとしています。

 

5.今後の展開への提言

上記の課題を踏まえ、次にどのようなことをやるべきかについて述べることで、
知見をより深める方法や方向性について明文化します。

もちろん、これ以上の深追いは不要である、というテーマの終了を述べるのも提言の一つです。

 

 

 

 

 

いかがでしたでしょうか。

 

 

プロジェクト型業務といった言葉が先行している一方で、
それらを具体的にどのように運営していくのかといった実践的な情報が少ないのが現状です。

 

今回ご紹介した技術的プロジェクト型業務を、
完了報告書をもって企業の知見とするということについて、
実践を意識した上で概要をお伝えしました。

 

 

実際の企業指導において、この完了報告書まで到達できる企業は少数派で、
それ以前の「技術報告書作成の習慣化」という所で時間を費やすのが実情です。

 

しかし、このような視点を見失わずに日々の業務を推進するということが、
将来にわたってその企業の重要な知見蓄積、
つまり技術の伝承には不可欠であることをご理解いただければと思います。

 

 

技術戦略支援事業

⇑ PAGE TOP