忍者ブログ

東からの放浪者

様々なソフトウェア開発を経験してきた視点から、開発、マネジメント、経済などについて書いています。
タイトルは、あるレトロゲームからのオマージュ。

ツイッターアカウントはこちら。

体制図の意味

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

体制図の意味

プロジェクトの体制図、会社の組織図などは、
ヒューマンリソース(人的資源)マネジメントの基盤となる文書です。

ただ、それ以外にも隠れた意味があります。

体制図の基本的な意味

まず、基本的な意味や、基本的な注意点をおさらい。

開発体制図 

※これは架空の(かなり適当な)開発体制図です。

人員配置と責任の明確化

基本中の基本ですが、開発体制図は、
このプロジェクトにどのような人が関わっているかを明確にし、
また、責任の所在を明らかにしてくれます。

大規模なプロジェクトになると、
「開発者が全体像を把握していない」というプロジェクトによく遭遇します。

そういうプロジェクトでは、要求漏れ、作業の重複などによるコストの増大が各所で発生し、
結果的に、高い確率で製品の品質に悪影響を与えることになります。

開発者が主体的に、状況把握に努めるべきでは?(*'-')

数十人~数百人の開発者が、独自に状況把握を行って、
全員が同じ認識になるかというと、それはほぼ不可能です。
また、コストがかかりすぎます。

マネージャが体制図を管理し、「体制の把握は大事だ」という姿勢を見せれば、
それによって開発者たちの意識が変わることもあります。

体制図は単なるお絵かきではなく、マネージャが積極的に運用してこそ、意味を成すのです。

コミュニケーション・マネジメントは別に行う

体制図は、コンタクト・パーソンも明確にしてくれます。
しかし、先の図をみれば分かりますが、情報経路をすべて示してくれるわけではありません。

先の図で、アプリケーション設計者ソフトウェアQA担当者は、
お互いリーダを通してやり取りを行うのか?というと、それは非現実的です。

外注先との連絡も、すべて事務局を通していたのでは時間がかかりすぎます。
コミュニケーション方法の確立は、別途行う必要があります。

管理人の体験談

以前、私が関わっていたプロジェクトで、
体制図を元に情報経路を洗い出してみたところ、

  • 経路が複雑すぎて情報が伝わるのに時間がかかっている
  • 経路が繋がっていないチームがあり、スケジュールがまったく伝わっていなかった
ということがありました。
体制図はきれいに書けていても、現場は混乱していたのです。( -_-)ヾ

体制図の隠れたメッセージ

これまた、適当に作った架空の部署の組織図です。
この図から、何が読み取れるでしょうか?

組織図 

私は、まずこう思います。

プロジェクト運営課には配属されたくねぇ!

業務内容と人員数が見合っていません。
かなり冷遇されているのが分かります。

体制図は投資計画の一部

人員配置は、「この領域に、これだけの人的コストをかける!」という意志の表れです。
つまり、投資の意志を伝える手段にもなっているわけです。

「組織の体制」「どこに投資しているか」をみれば、
その組織の「将来どの領域が伸びてくるのか」が分かります。

また、開発プロジェクトの体制図においては、
プロジェクトの成否すら分かってしまうこともあります。

優秀な開発者たちは、
体制図に込められたマネージャたちからのメッセージを敏感に感じ取ります。

ちなみに、先の「架空の組織図」の部署は、
プロジェクト管理や製品品質、ドキュメントの品質などを軽視していることが分かります。
その領域の作業品質が伸びることはないでしょう。

体制図が運用されていなかった組織

体制図を書いても、実体に即していなかったり、運用できなければ効果はありません。
体制図をうまく運用できているかどうかで、その組織のマネジメント力が分かります。

私が経験した、よくない運用例を紹介します。

体制図が定常業務とプロジェクト兼用

人事制度によって作られる組織図と、有期的な存在であるプロジェクトの開発体制図は、
本来別に作るべきです。

その組織では、この2つが兼用されており、以下のような問題が起きていました。

プロジェクトの体制は頻繁に変わるが、
体制図の変更は人事異動を伴うため時間がかかる

プロジェクトは生ものなので、頻繁に状況が変わります。
また、開発フェーズが変われば、体制も変えていく必要があります。

その職場では、次第に体制図と現場が乖離していき、
体制図の運用が形だけのものになっていました。

さらに深刻な事態

体制図の兼用は、さらに深刻な問題がありました。
それは、責任の所在が曖昧になることです。

でも、体制図があるんなら、責任の所在は明確なのでは?(*'-')

問題は、プロジェクトの責任者が、そのときどきで、
「都合のよい方の体制」の立場を使用してしまうことでした。

つまり、マネージャが都合の良いときはプロジェクトの当事者になり、
都合が悪くなると第三者のふりをする、という現象が起きたことです。

「何のための体制図なのか?」が、はっきりしていなかったため、
責任を逃れるための抜け道になってしまったわけです。

今日のまとめ

  • 体制図は、投資計画の一部という隠れた意味を持っている
  • 定常業務用の組織図と、プロジェクト用の開発体制図の兼用は危険

先の体制図の運用ができていなかった組織では、さらに先の話があります。

組織変更があり、新しい体制図が発表になったのですが、
「なんで、このチームがこのマネージャの下に?」という意味不明な図になっていました。

そして、マネージャが

人数が多くて管理が大変なので、チームを移動させました。

と言ったときには、私はズッコけそうになりました。_(:3」z)_

組織の今後に対する投資の意思表示が、それでいいんですか・・・?

たかが体制図。
しかし、軽視しているとマネジメントさえ行われない組織になってしまうのです。
確かに、体制図の運用を見れば組織のマネジメント力が分かる!と思われた方はバナーをクリック!
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓


PR

コメント

プロフィール

HN:
なかば
性別:
男性
職業:
元ソフトウェアエンジニア
自己紹介:
東京のゲーム会社でゲームプログラマ。
家電メーカーで組み込みエンジニア。
その後、京都に移動して観光を楽しみながら
製品開発、業務改善、QA管理などを経験。
今は東京に戻って暮らしています。

詳細な自己紹介は、こちら

ブログ紹介

管理人(なかば)の個人ブログです。

もともと、以前の職場で投稿していた社内ブログの延長で書き始めました。
エンジニア仲間に向けた雑な口調はそのままにしていますが、その辺は気にせず読んでもらえると嬉しいです(*'-')

諸事情により更新を停止していますが、生きています。そのうち再開する予定です。

カレンダー

03 2024/04 05
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30