技術テーマは個人プレーではなくプロジェクト化する
公開日: 2021年3月9日 | 最終更新日: 2023年1月29日
Tags: イノベーションと企画力, プロジェクト型技術業務, マネジメント, 技術の伝承, 技術者のモチベーション, 技術者の自主性と実行力を育むために
中小企業を中心に、技術者が業務を推進するにあたり、
「担当者である技術者を基軸とする個人プレーが多い」
という傾向があります。
これは柔軟かつスピード感が出やすいというメリットもありますが、
デメリットもあります。
今日のコラムでは技術テーマを担当者である技術者の個人プレーにならない様、
プロジェクトで推進するということについて考えてみたいと思います。
技術者は個人プレーを好む
技術者は自分がやりたいように業務を推進する傾向があるため、
個人プレーを望む傾向にあります。
当然ながら状況によってはそのような進め方が望ましい場合があります。
技術者の個人プレーが許されるのは以下の状況が整った時です。
1. 会社組織において周りの信頼を勝ち得る何かしらの実績があること
2. 担当者である技術者が、その技術テーマを最後までやり切り、
最終的なアウトプットを出すというずば抜けた当事者意識と覚悟があること。
3. 企業のマネジメントが、その技術者がテーマを進めるとういうことを承認し、社内公知のテーマであること。
それぞれ述べます。
1. 会社組織における実績
これはテーマを成功させるにおいて必要条件でしょう。
企業組織として求めることを何もできていない、やっていない技術者が、
自分のテーマを持っても、テーマ推進力があるか否かの判断ができていないままのスタートになるため、
中途半端に終わる可能性が極めて高い。
また、周りからの信頼が無ければ困った時に手を貸してくれる人も社内にいません。
企業としてはその技術者が企業組織内で信頼を得ているか否かという点をよく見極める必要があります。
2. 技術テーマをやり切る当事者意識と覚悟
これは必須の条件です。どのような状況にあったとしても、
「他に業務があるので」
という発言をする技術者に絶対担当させてはいけません。
できない理由を考える代わりに
「どうしたら、仕事を前に進められるのか」
ということに神経と頭脳を使える技術者が求められます。
同時にそのような逃げの言動は見られず何でもやりますという受け入れ姿勢の一方で、
報告や相談なしに仕事の遅れがでる技術者も不適合です。
ため込むだけため込んで、問題がかなり大きくなってから突然 Give up というのが落ちです。
このような自己管理が全くできない技術者は技術以前に、時間管理や計画、必要に応じた相談ができないという点で、個人で技術テーマを推進する基本資質に欠けるといえます。
3. 社内公知のテーマである
仮に技術者が個人で進めるテーマであっても、
「社内で認知されている」
ということであれば大きな問題は無いでしょう。
組織として、技術者個人がそのテーマを進めるということを認めているからです。
一般的には、上記の3つの条件をすべて満たしているケースはあまりないのではないかと思います。
つまり、技術者が個人プレーをするということが認められるには、
技術者が考えるよりもはるかに厳しい条件を満たす必要があるのです。
技術テーマは基本的にプロジェクト化する
技術者の個人プレーでの技術テーマ推進が難しいとなった場合、
マネジメントが考えるべき技術テーマ推進の枠組みが、
「プロジェクト化」
です。
技術テーマのプロジェクト化で必要なのは以下の点です。
1. 到達したい目標、得たいアウトプットといったゴールが明確であること。
2. プロジェクトの報告や終了の時間軸が明確であること。
3. プロジェクトに入るメンバーの担当業務が明文化されていること。
4. 計画→承認→実施→報告のプロジェクト運営体制が整っていること。
5. 常に相談できるサポート体制があること。
それぞれ概要を説明します。
1. ゴールが明確である
多くのプロジェクトがここをあやふやに進んでしまうことが多いです。
最終的なゴールを強く意識するということが、
現場の技術者はもちろんですがマネジメントにも強く求められます。
当然ながらこのゴールは口頭ではなく、
「明文化することは必須」
という理解も不可欠でしょう。
プロジェクトを推進するにあたり、プロジェクトメンバーの視線はずれていく可能性もあるため、プロジェクトマネジメントは繰り返しこのゴールを伝えるという姿勢が重要です。
2. プロジェクトの時間軸が明確である
これも大変重要です。
特に重要なのが、
「いつまでに終わらせるのか」
という終了時期です。
加えて、途中の進捗確認などの報告会を数回に分けて行う必要があるでしょう。
そのような報告頻度等も事前に決めることが重要です。
3. プロジェクトメンバーの担当業務の明文化
日本企業は全般的に不得意とされていますが、
「担当業務の明文化」
です。
最近はやりのジョブ型での雇用を進めるにあたっては必須の知見ですが、
マネジメントが担当してもらう業務を読み切れないため、
業務の明文化を避け、仮に明文化しても抽象的な表現にとどまることが多くあります。
ジョブ型については以下のようなコラムでも述べました。
誤解があってはいけないので述べなくてはいけないのは、
「プロジェクトでの承認を経れば担当業務は後から加筆修正できる」
ということです。
最初にすべてを想定するのは難しいので、
後から担当業務を加筆修正する必要性は出てきます。
その際にポイントとなるのは、当初想定したものからの変更点をプロジェクトとして把握し、承認を得るということです。
このような手続きをきちんと行えば、
「これは私の仕事ではありません」
という技術者の発言の妥当性を客観的に判断できるようになるでしょう。
4. 計画→承認→実施→報告のプロジェクト運営体制構築
これは日本企業に多い傾向ですが、
「計画を立案するのが不得意」
と感じています。日本人技術者のほぼ全員がこの傾向にあると感じます。
先を見据えて計画を立てるということは技術系業務に限らず仕事の基本なのですが、
理由をつけては計画があやふやなままスタートする、
または計画を立案することさえしない、というケースが散見されます。
計画の重要性については以下のコラムでも述べていますのでご参照いただければと思います。
※ 若手技術者の暴走や立ち止まり回避に効果的な 技術評価計画
https://engineer-development.jp/column-2/evaluation-plan-for-effective-work
さらに活字化の苦手な技術者は報告をプレゼンテーションで終わらせようとします。
当然ながら経営陣や顧客に対して
「概要を説明する」
ということであればプレゼンテーションも有効です。
しかし、実際にどのような実験や試験を行い、その結果が何だったのか、
そして技術的な考察に関する技術者の考えの記載等は技術報告書の形にすべきであり、
この技術報告書こそが、
「技術の伝承の基本」
になることを忘れてはいけません。
プロジェクト化した技術テーマは技術報告書まで完成して初めて完結するのです。プレゼン資料は技術報告書という基本、つまり企画が存在して初めて意味を成します。
技術報告書については過去に何度か述べたことがありますので、以下のコラムもご参照ください。
5. 常に相談できるサポート体制
マネジメントとしてはプロジェクトとして立ち上げたら後はお任せ、
というスタンスではいけません。
問題が起こった時、相談したいときに誰に相談すべきかという窓口を作っておくことも必要です。
窓口は統一化してもいいですし、管理的な内容と技術的な内容で分けてもかまいません。
しかし、何か問題が生じた場合にどこに相談すべきかを明確化しておくことも、
プロジェクト推進において大変重要であることをマネジメントは理解する必要があります。
いかがでしたでしょうか。
技術テーマをプロジェクト化すると一言でいっても、概要を述べただけでも上記の通りいくつか重要なポイントがあります。
これらのポイントを一つひとつ丁寧に押さえ、
技術テーマを推進するプロジェクトの枠組みを設計することが、
技術系企業のマネジメントに求められる考え方なのです。
ご参考になれば幸いです。
技術者育成に関するご相談や詳細情報をご希望の方は こちら
技術者育成の主な事業については、以下のリンクをご覧ください：
