忍者ブログ

東からの放浪者

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

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

マネジメントが根付かない開発現場 その2

×

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

マネジメントが根付かない開発現場 その2

外部からマネージャを雇い入れたり、コンサルタントからアドバイスを受けたりしても、
結局、その人が去ると元に戻ってしまう。

個人の意思に頼っていると、職場全体にマネジメントが根付くことはない。
マネジメントを根付かせる仕組み、または圧力のようなものが必要です。

前回の記事に引き続き、開発現場に偏った視点ですが、整理してみます。

マネジメントを根付かせる仕組み

仕組み、枠組み、システム。どれも「面倒臭い」という響きがします。

生産性を下げている、というイメージすらあるかもしれませんが、
規模の不経済(※参考)が働くソフトウェアの開発では、「仕組み+運用」を上手く回し、
開発現場の生産性を落とさないようにする必要があります。

そして、組織やその中の人たちというものは、
その仕組みに強い影響を受けることがあります。

開発プロセスの有無

「開発プロセス」と聞くと、お堅いイメージがあるかもしれませんが、
ここでは、高度に文書化された開発プロセスを指しているわけではありません。

最低限、以下の質問に全て「はい」と答えてほしいのです。

  • 定常業務とプロジェクトの区別はついていますか?
  • プロジェクトの責任者は明確ですか?
  • これらのことが会社の方針として定められていますか?

開発プロセスは、なければ作ればいいのです。(どの会社も初めは持っていません)
問題なのは「開発プロセスなしで開発を始めてもよい」となってしまっている現場です。

開発プロセスがないと・・・

まず、定常業務とプロジェクトには、以下の違いがあります。
(PMBOK より)

定常業務 プロジェクト
継続的な目的・目標を達成する 独自性があり、有期性の業務
あらかじめ配属されている要員で活動する 運営組織は期間限定の体制となる
決められた方法で活動する プロジェクトごとにテーラリングを行う
継続的に活動する 目的・目標を達成したら活動は終結する


これらの区別がないと、以下のような問題が起きます。

  • プロジェクト計画書がない
  • 開発体制図がない
  • 見積りや予算が決まっていない
  • プロジェクトの開始と終結がない

そして、これらのことを執り行う責任者が不在となると、現場には混乱しかありません。

さらに、プロジェクトの終結が存在していないと、
マネージャは自分の仕事の成果を振り返る機会さえありません。
つまり、責任を自覚する機会がないのです。

そして、開発プロセスが会社の方針として定められていないと、

マネージャはプロジェクトにおいて何もしなくてもよいし、責任も取らなくてよい

ということを暗にメッセージとして伝えてしまうことになります。

開発プロセスは、単なる開発の枠組みにとどまらず、
マネージャを育成するための枠組み、という側面もあるのです。

評価制度

これまた、開発者にとっては面倒なだけ、と思われがちな評価制度。
けれど、運用次第で組織に良い影響をもたらすこともあります。

最も有害なマネジメント

評価制度を決める前に、みなさんは「最も有害なマネジメントとは?」と聞かれたら
何と答えますか?

私は

何もしないマネジメント

と答えます。

何もしないマネジメントは、最も効率的に組織の生産性を下げ、
プロジェクトを失敗に導きます。


つまり、評価制度には、これを防ぐ仕組みを入れる必要があります。

減点評価と加点評価

最もよくない評価制度は、減点評価のみで構成されています。
つまり、「何もしない=減点0」となっている評価制度です。

基本は、加点評価でないといけません。
つまり「何もしない=0点」となっている評価制度です。

減点評価の元で育ったマネージャは、
とにかく「自分が何もしなくてよい」方向に、ものごとを進めようとします。

自分から提案はせず、部下からの提案に対しては、まず却下する理由を探し、
そして開発者たちが勝手に動くことを嫌います。
(そのくせ、開発者には「主体的に仕事をするように」と言ったりします。)

人事制度・教育制度

これまた、堅苦しい言葉が並びましたが、
高度に整備された、厳しい人事制度・教育制度のことではありません。

その会社で、マネージャという職種がどのように扱われているか?
という部分が問題になります。

マネージャは専門職

開発プロジェクトのマネージャは、そのほとんどが開発者出身です。
これには何の問題もありません。

例えば、ソフトウェア開発のプロジェクトマネージャは、
ソフトウェア開発の経験が必須だと思います。

しかし、開発職からマネージャ職になることは、ある意味「職種替え」です。
プログラミングの知識だけで、マネージャが務まるかというと、そんなことはありません。

会社によっては、マネジメント教育を修了しないとマネージャになれない、
というところもあります。

ただし、すべての会社で、そのような制度を採用するのは無理があります。
また、開発者としての経験をないがしろにするのは、よくありません。

しかし、人事制度によって「マネージャ1年目」であることを自覚してもらい、
教育制度によって、「マネージャには専門知識が必須」ということを
自覚してもらう必要があるのです。

以前、このような方針が存在しない職場で働いていたことがあります。
その職場のマネージャたちは、まるで隠居先かのように過ごしている人が多くいました。

制度というものは、ときに足枷になってしまうこともありますが、
なければないで、人を堕落させてしまうこともあるのです。

今日のまとめ

マネジメントを根付かせるには、仕組みが必要です。

ただし、何も厳格な仕組みが必要、というわけではありません。
大事なのは「仕組みの中に会社からのメッセージ込める」ということです。

優れた仕組みを、上手く運用すれば、
マネージャたちに、メッセージを送り続けることができます。
これは、言葉によるメッセージよりも効果的、かつ継続的です。

逆に、仕組みの運用が上手くない、または仕組みが存在しない職場では、

  • マネジメントは重要ではない
  • マネージャは何もしなくてよい
  • マネージャは責任を取らなくてよい
  • マネージャに自己研鑽はいらない

といった、メッセージを送り続けてしまう結果になります。

これでは、外部から優秀なマネージャを雇い入れても、
コンサルタントからアドバイスを受けても、マネジメントが根付くはずはありません。


確かに、マネジメントを根付かせるには仕組みが必要だ!と思われた方はバナーをクリック!
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓


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