前回は「チームの自律的なプライオリティ設定」についてふれました。 技術者はどの企業でも多忙であり、忙しさの中で悪循環へ陥りやすい。 悪循環を断ち切るには、常にプライオリティを見定めていることが大切。もっとも優先順位の低いことへの取り組みを止めるか保留すれば、全体への影響が少なく、忙しさへの対策（工数確保）になる。 最も重要なテーマは、重要であるが急ぎではないテーマ。チームの持続的な成長につながるテーマである。 プライオリティはチーム全体で議論することから見えてくる。個人では、担当したことが重要なことになるため、「止める、保留する」という判断は現実的にはできない。 優先順位を定めたテーマのすべてに人を割り振ってはいけない。全てを個々人に配分した段階で「個人の課題」となってしまい個人任せとなる。上位の集中すべきテーマを配分、計画し、それらの進捗に応じて下位のテーマを逐次実施する。テーマと優先順位は個人ではなくチームとして把握、管理する。

目次

４、業務の特徴からみたチームのタイプ

４、業務の特徴からみたチームのタイプ

ハーバード大学のエイミー・C・エドモンソンは、チームのタイプを分ける観点として、「知識の成熟度の高さ」と「不確実性の高さ」を挙げています。「ルーチンの業務」は成熟度が高く、不確実性が低いと言えるし、「イノベーションな業務」は成熟度が低く、不確実性が高いとしています。そして、成熟度と不確実性の双方が中間くらいの業務は「複雑な業務」に分類されます。

上記はチームのタイプでもあり、各々の業務比率とも言えます。例えばルーチンの業務であっても、改善のアイディアを考える場はイノベーティブ ですし、研究職でも事務処理的な業務はあります。また、複雑な業務である保守業務でも、システムの不具合修正など予測できないことへの対応では創造性が問われることもあれば、反復的に繰り返す仕事もあります。

これらのチームの特徴によって、チームの育て方は異なります。

「ルーチンの業務」「複雑な業務」「イノベーションな業務」の各々について、これまで述べてきた、計画立ての場づくり、集合知、自律的なプライオリティ設定の発揮のしかたについてお話しします。

４－１）ルーチンの業務

サイクルで仕事が回るので、個々のサイクルの中での気づきを日々のミーティング等の中で共有し、次のサイクルですぐに試す等の「サイクルアウト」（図７）の考え方を用いることが必要となります。

サイクルで仕事が回るので、個々のサイクルの中での気づきを日々のミーティング等の中で共有し、次のサイクルですぐに試す等の「サイクルアウト」（図７）の考え方を用いることが必要となります。

ⅰ）計画立て

短サイクルのルーチンの場合、計画立ては日々の業務の比率の立案となります。日常業務と改善活動の両立を図り、改善活動への投入工数の目標を設け、目標達成度を評価しながら業務の密度を高めることが大切です。

• 共通の改善対象を持ち、日程計画に組み込む。
• 小日程で改善の前倒しのセルフマネジメントを行う。
• 振り返りに、工数だけの量の評価ではなく、改善の取組みや結果の質の評価を加える。

ⅱ）集合知

問題発生の未然防止に向けたヒントは、「障害をうまく回避した例」にあります。どのような危ない瞬間があり、それをどのように対策し回避したかという、いわゆる「ヒヤリハット」を共有します。困りごとの事象からさかのぼれるように形式知化し、マニュアルやデータベースとすることが肝要です。

• 人に行き当たれるデータベースを構築しコミュニケーションの契機とする。
• アドバイスを基盤に相互依存を高める。

ⅲ）プライオリティの観点

計画立ての項でも述べたましたが、実務だけではなく改善業務を必ず織り込むことが必要です。３－３）自律的なプライオリティ設定でも述べたとおり、チームと個々人の持続的な成長のために、投資として改善活動を行います。

• 改善と実務を同価値とする。
• 改善へは一定のリソースを必ず配置する。

仕事を行いながら日々改善を進め、日々の気づきをすぐに活かす場を設ける。サイクルアウト型の成長を遂げることを目指します。

４－２）複雑な業務

業務環境のIT化が進んだことで、一人当たりの情報量や関連する部門も増しています。ほとんどのチームに「複雑な業務」が存在し、多いチームでは仕事の8割が「複雑な業務」となっている場合もあります。

ⅰ）計画立て

複雑な業務のチームには、「複数の部門や顧客に関わるため、環境や前提条件が変わりやすい」「多くの情報や要望に基づいて物事を進めるため、状況変化が激しい」「過去に起きたトラブルへの抜本策が取られておらず、再発する場合がある」という特徴があります。

従って、計画には柔軟さが必要です。

• 業務の効率を追求した計画よりも、迅速な修正が可能な日程計画を組む。
• 関係部門の状況を踏まえて、先行した中日程の調整を行う。
• 環境変化へのリスクを想定し、未然防止策を盛り込む。

ⅱ）集合知

技術的にはそれほど高度ではない業務でも、トラブルによって一気に仕事が複雑化し難題となる場合があります。自部門の類似例や過去のトラブルを他部門と共有し、未然防止やトラブルが発現した場合のリスク対応策への知恵出しが必要です。

• トラブルへの想定を織り込み、
• 想定外は、エスカレーションを先行させる。
• マネジメントはチームの仕事環境を整えることに注力する。

ⅲ）プライオリティの観点

複雑な業務で、仕事がうまく進んでいないチームの特徴は、リスクが発現しないことを前提に、物事を進めようとしていることにありあます。リスクは発現するものとし、リスクヘッジの選択肢を常に設定し、プライオリティの中位以上に置くことで、「想定内」を広く持つことが肝要です。

• 選択肢が上手く機能し、迅速な修正とリスク軽減ができる状態を狙う。
• 状況の変化に対して、事前の想定に基づいて阿吽で動けるチームとなる。

 

イノベーションな業務の典型は、研究や開発などの「これから新しいことを進める」場合です。イノベーションなチームで仕事がうまく進んでいない場合、「課題が見えないまま、とりあえず計画を作り（内容の無い作業計画）進めてしまう。」「事前の準備に時間を割かずとにかく動き始める。」「先を急ぐあまり検討不十分なまま、次ステップに移る。」などが起こっています。

ⅰ）計画立て

計画立ては、作業の計画ではなく「課題を解く中身のある計画」にする必要があります。

これには、これまで述べてきた課題バラシや作戦ストーリーの検討を行うことそのものを計画として持っていなければなりません。

• プロジェクトや開発テーマの背景、目的を共有し、マイルストーンを明確にする。
• 各マイルストーンの目標に予め、準OKなど完成度が上がらない場合の対応を設定する。
• マイルストーンを経て次の中日程を具体的に描く。

ⅱ）集合知

直近のマイルストーン毎に、アウトプットイメージを描いて共有し、個々へ向けた課題を徹底的に抽出します。これからやることへの課題バラシですから、「今できていないこと」「心配事」「気になること」を全てあげることが必要です。

• アウトプットイメージをしっかりと共有し、個々の感じている課題を出し切る。
• 源流段階で時間を取り、課題バラシを徹底して行う。
• 解決へは仮説を持って臨み、失敗から学べる環境を整える。

ⅲ）プライオリティの観点

プライオリティを決める際の観点は2軸あります。一つは、遂行すべきテーマのQCD目標をしっかり達成することです。目標達成に向けた不確実性が高いということは、試行が繰り返さるということです。試すことから得られるチャンスの大きさをもとに方向を定め順位を設定することが必要です。もう一つの観点として、成長軸の目標があります。個々人の技術者としてのスキルが上がることやチームとしてのノウハウ蓄積を進めることがこれに相当します。

• 積極的に試行し、正しく失敗し早く成功する。
• 狙われた小さな失敗とリカバーで、よりよいやり方への発展を行う。
• 得られた知見を暗黙知とせず、形式知に残す。

失敗から学んだことが具体化すること、正しく失敗すること、これを蓄積し資産とすることで成功への道筋を得ること、これらがイノベーションな業務のチームを強くしてくれます。

以上のように、チームの特性によってチームの目指す成長像は異なります。また、当然ながら、改善対象の業務によって改善の考え方も異なります。例えば、開発部門でも事務処理的な業務を改善する場合は、サイクルアウトの考え方を適用すると良いでしょう。

参考文献　　エイミー・C・エドモンソン著　「Teaming」