6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

クリティカル・パスを一人にまかせる(押し付ける)のか、仲間として解決するのか

Last updated at Posted at 2018-07-11

開発を行なっているとそこにはクリティカル・パスが存在します。
そのクリティカル・パスをどう解決するかが、組織の明暗を左右します。

組織の運営のしかたによって、クリティカル・パスの解決のしかたに違いがでてきます。

硬直した組織の中では、えてしてクリティカル・パスを一人にまかせる状況を放置します。
また介入する場合でも「問い詰める」タイプの介入のしかたをしてしまいます。
そのことは、負担を増やす方向に作用することがあります。
その結果に、クリティカル・パスを改善する決定がなされればいいのですが、
ときとして、プロジェクトの責任者の責任回避の行動がされることがあります。

そのような状況はクリティカル・パスを解決するものではありません。

クリティカル・パスが解決されないときに起きること

  • そのプロジェクトがたった1つのクリティカル・パスによって失敗になることがあるのです。
  • クリティカル・パスは達成時期の場合もあります、達成精度の場合もあるでしょう。
  • Oリング1つが、スペースシャトルの爆発の引き金になったといように、我々は謙虚でなければなりません。自然が忖度してくれることはありません。
  • 重要な部分をたった一人に背負わせ、その一人が入院しただけで、プロジェクトが失敗するなどというのは、組織のマネジメントではありません。

以下、それぞれの組織について、どのような要因があって、どのように対応するのがよいのか、
私の貧弱な経験の中での視点を述べたいと思います。

縦割り型の組織の場合

縦割り型の組織の場合には、組織全体に影響するクリティカル・パスであっても、縦割りの内部でだけ解決しようとするし、クリティカル・パスがあること自体も隠そうとしてしまいます。

  • 所属長を通さないで、他のチームのメンバーと直接技術上の話をしてはならない。
  • 別なチームの人が課題にアドバイスを述べてはいけない。
  • 所属長を通さないで、さらに上の人と直接話をすることを嫌がる。

このようなアプローチをしている限り、現場を知っている人同士が実際的な解決方法を提案することを不可能にします。
複数の部署・組織(社内・社外を問わない)が関わるプロジェクトの場合、関係者がいっしょに顔を合わせて、共通の目標を達成するのだという熱意を確かめあうことは有効です。そして、成功させるためには何が必要かをいっしょに考え合うことです。そのような場を持つように所属長に働きかけてみましょう。

そうすれば、クリティカル・パスの存在も共通に認識されて解決しやすい方向にはたらきます。

組織運営を縛る要因

組織運営を縛る要因が増えれば増えるほど、クリティカル・パスを解決する可能性は低下します。

  • 1年間のチームの目標を年度の冒頭に細部にわたって規定します。
  • 1年間の成果目標を年度に冒頭に個人レベルで規定します。
  • 個人の裁量で作業をできる時間をまったく排除して、すべてを明確な管理下におきます。

個人の裁量でできることを著しく低下させてしまいますから、開発中の課題に対して、別なアプローチならば解決できるのではなかろうかという試行錯誤をすることができなくなります。

特に、1年間の成果目標を年度の冒頭に個人レベルで規定すると、そのことが1年間全体の作業の詳細をしばってしまいます。状況が年度の冒頭と変わっているのに、年度の途中で計画を修正できなくなってしまいのです。

まず、個人の裁量で作業できる時間を確保するようにしたたかに行動することが必要かもしれません。
アンダー・ザ・テーブルの作業をすることも、開発の現場では必要だと私は考えます。
「△%ルール」

従業員が自分の業務時間の20%を好きなことに使ってよいとする、いわゆる「20%ルール」は、従来の勤務体系では思いつかないような斬新なアイデアを生み出そうという考えから生まれたものだが、以前から同じようなルールを(ときには暗黙のルールとして)運用してきた日本企業は少なくない。成長の鈍化で余裕がなくなり、一時は有名無実化してしまったものの、最近になって再び光を当てようとしている企業もある。

引用元 http://www.foresight.ext.hitachi.co.jp/_ct/16935550

1 年の間の技術の進歩は、特に機械学習の分野ではめまぐるしい状況です。
1年の冒頭に決めたスケジュールから、何の修正も必要なく、業務が推進できる状況にあるのかどうなのか、組織の運営者に問いかけることです。
当初の計画は書き換える必要があるとなった時に、書き換えられる自由度を獲得するようにあがくしかありません。

上下関係重視の組織

  • 上の職制に位置する人は、判断を間違えないという前提で組織運営がされます。
  • 上下関係を意識したがる組織の場合には、メンバーに対して服従することを要求します。
  • 仕事を割り当てたら、後は割り当てられた人の責任であって、組織として共通に問題を解決しなければならないという意識は時として希薄です。
  • 時として、新しいアイディア・新しい改良をできる人よりも、上の職制に位置するということだけを元に、十分な説明もなしに、無理強いします。

そのような状況では、クリティカル・パスを報告しても、報告にともなう作業量が増えるばかりで、あては、「うまくいかないのは、担当者が無能なせいなんじゃないだろうか」という不名誉な疑いを被ることになる。クリティカル・パスを解決するための方策を担当者が取りやすくするほうに働くのではなくて、クリティカル・パスの解決をしようとしている人の手足を縛る方向にはたらくこともある。

だれが、話がわかる人なのかを見抜く必要があります。直属の上司が解決策を理解しない時には、さらにその上にはたらきかけることです。
そうすることで、状況を変えた人はあなたの周りでもきっといるはずです。

 上下関係重視の組織であっても、次のような方策を少しづつ導入させる手もあるかもしれません。

  • すべての人に発言させるために、発言時間をタイマーで管理する。
  • メンバー全体で投票をする。

会社の中で部署間の競争(時としてつぶしあい)がある場合

  • 部署を超えてアイディアを共有することがいやがる。
  • どの新規テーマをどちらの部署で獲得するかをめぐって競争して潰し合うことがある。
  • アイディアを提供した先が無断で自前で実装してしまうこともある。
  • あとは製造に近い部署の側が開発するからといって、オリジナルの開発部署を解散させてしまうことがある。

このような状況は、大企業では起こることがあります。これに対する有効な解決策を私は知りません。

これに対しては、次のことは述べておきたいと思います。

  • 共有されることのないアイディアはなかったと同じアイディアになる。
  • 議論することの中でお互いによりよいアイディアを得ることが大事。
  • 議論することもなければ、アイディアは洗練されるきっかけを失ってしまう。
  • あなたが実装する前に、その人が実装したなら、その人の手際の良さを褒めよう。

このメモが、あなたが置かれた困難な状況をぬけ出すヒントになれば幸いです。


参考記事
qiita 「進捗どうですか?」より2015倍捗る「困ってますか?」

付記:

上下関係重視の組織だからといって必ずしも失敗するわけではありません。

  • 判断を間違える怖さを上位の職制の人も持ち合わせていた。
    • 特に、第2次世界大戦を経験していた人、終戦後の混乱をを経験した人、朝鮮戦争が朝鮮半島を超えるかもしれないという時代の実体験を持ちあわせていた人は、間違った判断が引き起こした結末に対して怖さを持っていた。
  • 判断を間違えないための努力を上位の職制の人がしていた。
    • 今の大卒の50代よりは、20年昔の大卒の50代の方が、文系であっても数学や理科を素養としてもっていたように思います。
    • (今の50代は、既に共通一次試験の影響で、考えの視野が狭くなる方向になっています。)
    • 話を聞く努力。(話の主張を全面的に受け入れるわけではなく、相手は何を元に何を語っているのかを知る努力)
    • 朝令暮改になるほどにその判断が正しいのかを自分に問い続けていたこと。
  • 世の中が今後どうなるということについて、アメリカの市場をみることによって、未来を構想することがあった。
  • 「10年全く同じ手順のまま、10年まったく生産規模が拡大ししていない(縮小している)」状態ではなく、常に変化し続ける状況のなかにありました。成功するプロジェクトもあれば、失敗するプロジェクトもありました。変化が少なくなり過ぎた状況の中では、失敗に学ぶことのない組織ができあがってしまっているのでしょう。

第109号 「みんなが賛成することはたいてい失敗し、反対されることはなぜか成功する。」

縦割り型の組織でもうまくいっていた時代

  • 縦割り型の組織でもうまくいっていた時代は、もうすこし個人の自由度があった。すくなくとも解決方法を探して、会社の中を駆けずり回る自由度があった。
  • たいがいの問題に対しては、自分よりも詳しい人がどこかにいて、その知恵を拝借することができたものだった。
  • 社員同士が、べつの部署の社員の場所にいくのに何も問題はなかった。
  • 部屋ごとにセキュリティを管理するセキュリティシステムなどはなかった。
  • それがある時代からは、会社の中の自分の入れる場所が次第に狭くなってしまい、別の分野の人と話をする機会は失われていくようになった。
  • ある時代のある部署においては、会社の中の入れる場所は、いつもの部屋の他には食堂だけという極めて管理された時代になってしまった。
  • アイディアを交換しあうことも、解決方法をさがして会社の中を駆けずり回ることもできない時代になってしまった。
  • 縦割り型の組織でもうまくいっていた時代には、今ほど縦割りが部屋を行き来できないほど硬直していなかったし、別の部署の人を見て、自分達のプロジェクトに有用な人物を社内でスカウトできる程度には自由度を持っていた。

クリティカル・パスを抱え込んでしまったときに

悲鳴をあげよう。
助けを求めよう。
何がどう問題なのかを知るべき人がわかえるようにしよう。
問題が早い段階で見つかることは問題ではない。問題が遅い時期に見つかって対策不能になることの方が怖い。
職場の同僚たちは、共通の利害関係者だ。ともに事業を成功させることが職場の同僚たちとともに幸せになる方法だ。
見えている問題は解決できる。
(隠されている問題・気づいていない問題は、問題解決をするチャンスがない。)
一緒に解決に取り組んでくれる同僚は、あなたの宝です。感謝の心を伝えましょう。

問題を分割分割しよう

クリティカル・パスのやっかいな問題は、実はいくつかの問題に分割できるはずです。
その分割した問題の1つは、別な人が解決できる場合がある。

クリティカル・パスとなって助けを求めている人があなたの近くにいたら

可能な手助けをしよう。
仕事を解決していく中では、クリティカル・パスは必ずある。
組織の困難をどう解決していくのかは、その組織がどう強みをもつのかと関係する。
かつては強かった組織も、年月の経過と人の入れ替わりは、その強みを失わせていたりします。
クリティカル・パスをともに解決していくことは、組織を強くします。


追記
 あなたの組織が、 クリティカル・パスを一人にまかせる(押し付ける)タイプだっとして、それで機能しているだろうか?

組織が機能がするやり方を、組織は学んでいくことです。

他にいろいろ手法がありますが、スクラムという組織運営手法は、組織の進め方の1つです。

スクラムという組織運営をしている場合には、そもそも「クリティカル・パスを一人にまかせる(押し付ける)」状況は発生しません。

また、スクラムの運営形態では、課題を割り当てて問い詰めるだけのマネジャーは存在しません。 

6
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?