注意点を先に。

まず、この記事では便宜上「マネージャさん」としてますが、
実際には「部下が１人でもいる人全員」が、
特にこの記事の対象だと思います。
もちろん、部下がいない人が読んでも良いんですけどね。

では本題に。

マネジメントにおいて必要な能力って、最低でも以下の様なモノがあると思います。
他にも、予算・進捗管理とか顧客折衝とか沢山あるでしょうけど。

１．自身がマネジメントを行う分野についてのスキル(ITエンジニアなら技術スキル)
２．部下の話を、「目線を合わせて」聞けるスキル(コミュニケーション"マインド")
３．部下をチームを引っ張っていく覚悟(統率力とかカリスマ性とか？)

んで、１は言うまでもありません。
例えば、ITエンジニアなら。
作業Aの難易度(何時間ぐらいで終わりそうか)を知るには、
その作業(もしくは類似)を深く理解していなければ分かりませんし。
また、成果物の品質の良し悪しだって、
どういう成果物なら品質が良いのかなどは、
最低でも中級以上の技術スキルがなければ、見極められません。
また、「作業が出来る」だけではダメでして、
その作業の目的(本質)の説明が出来る必要があると思います。
以前にも、ココ http://kitoku1.blog129.fc2.com/blog-entry-139.html に書きましたが。
とりあえず、ここは書き出したらキリがないので、今回はこの辺にしておきます。
まあ、上記の条件について、
実在する多くのマネージャさんが、実際どうなのかは取り敢えずおいとくとして（苦笑）

次に、目線を合わせて聞けるスキルについて。
貴方は出来るから、どうしても部下の仕事ぶりがもどかしく感じたり、
答えを教えたくなると思いますが。
誰でも最初から出来るわけではありませんし、
答えを教えると、部下が自分で何も考えなくなる(思考停止)ので、やってはいけません。
これも、以前にココ http://kitoku1.blog129.fc2.com/blog-entry-142.html に書いた通りです。
ですので、マネージャさん。
貴方が、今の部下のスキルレベルまで目線を下げて、部下の話を聞く必要があるわけです。
まあこれも、実在する多くのマネージャさんが、実際どうなのかは取り敢えずおいとくとして（苦笑）

最後に、スキルというか気持ち(覚悟)の問題の様な気がするんですが、
「貴方は部下をチームを組織をどうしたいのか？」みたいな話です。
これが、今回の主題です。
あと、ここからはかなりキツめの文章になりますので、ご注意下さい。

きちんとマネジメントを行えるだけの実力があっても、
部下の目線に合わせて話を聞けていたとしても。
マネージャさん、貴方がちゃんと行動でも見本を示して、
仮に上司や顧客相手でも、「ダメなものはダメ」という姿勢を見せなければいけないと思います。
それをしなければ、きっと部下は以下の様な事を思うのではないでしょうか？

「あの人は実力もあるし、自分の話もちゃんと聞いてくれるけど、
何となくこの人を信じてついて行こうとは思わないんだよな」

部下のこの考えに、問題が全くないとは私は思いません。
上司に寄っかかって、いつまでもおんぶに抱っこ状態なのも考えものです。
でも、マネージャさん。
貴方は、以下の様な事を最近言ったり思ったりしていませんか？

「問題なのは、俺よりもっと上の人間であったり、お客さんなんだよ。だから俺ではどうしようも出来ない」
「やりがいのない仕事かもしれないけど、これも経験の一つとして頑張ってみて」
「上の連中、全員終わってるから、もう俺は部下を置いて退職するわ」

マネージャさん、貴方にはある程度の裁量権はあるはずです。
で、その裁量権を使って。
どうして部下にもっと成長出来る様な仕事をさせる様に、
自分より上の人間と交渉しないのですか？
やる気がある部下であれば尚更。
言い方変えましょう。
マネージャさん、貴方が逆の立場で。
「自分の事しか考えない自己保身に走った上司を見たら、貴方はどう思いますか」？
そんな人間に、一生ついて行こうと思いますか？
きっと部下も、そんな貴方を見て同じ事を思うんじゃないですか？

また、守破離という言葉がありますが、その観点からみても。
守では、部下は上司の真似をします。
つまり、上司がちゃんとしなければ、
部下もそれを見て、ちゃんとしなくなるわけです。
そうしたら、仮にその部下が出世して上司になったら、
また、その部下もちゃんとしなくなっていくわけです。
以降、延々と続きます。
そしてその結果として、腐敗したチームや組織や国家が出来上がっていくのではないのですか？

そうならない為にも。
まず、部下を知ってスキルレベルや適性を知り。
その上で、「この部下にこの作業は簡単過ぎる」と思えば。
その作業を指示した大元の人間と交渉して、
他の人間(やる気のない人間とか)と作業を交換したり。
また、自分より上の人間が、
明らかにおかしいスケジュールや作業割りなどをしてきたら。
きちんと理由を述べて、「おかしい」と声を上げなければ。
というか、それがマネージャであり、マネジメントでは無いのですか？
だから、単にイイ人ではマネージャは出来ないと思います。

私が以前大好きだった、プロレスの話で恐縮ですが。
グレート・ムタという選手がいまして、
「ムタがやらねば誰がやる！」という言葉というか、正確にはアナウンスですが、
そういう言葉があります。
で、マネージャさん、貴方「が」やらねば誰がやるのですか？
進化ではない退化を、指を加えて見て見ぬふりをするのですか？
どんな問題であろうが、真っ向から対峙しなければいけないのです。
貴方が逃げたら、部下も逃げようとするだけです。
そうしたら、その仕事どうなります？
貴方の手元にあるお金は、その仕事を通じてお客さんから頂いてはいないのですか？

自分を助けるのは、正直誰でもすると思います。
でも、マネージャさん。
貴方は、自分だけではなく、部下やチームや組織も助けなければいけないのではないでしょうか？

参考：
・マネジメントは、多分「真摯なコミュニケーション」→「背中で語る」
http://d.hatena.ne.jp/gallu/20110428/p1
・現大阪市長の橋下さん
・日本の多くの経営者や政治家（苦笑）

先に書いておきますが、これは「ダメダメマネジメント」話です。
といっても、真っ当と思われる締めですけど。

では、一例を。
難易度高の画面A(画面の無い機能AとかでもOK)がありました。
画面Aは仕様的に、実装が技術的に不可能では「なさそう(ココ重要)」だけど難しい画面です。

もう一方は、画面B～Kがあり、それぞれの画面の難易度が全て、
上記の画面Aに比べて、十分の一と見積もられました。
見積もり手法がどうなのかの議論もあると思いますが、
ここでは「少なくても悪くはない手法」とします。
少なくても、LOC法では「ない」。
で、画面B～Kのイメージとしては。
一つの画面の実装も簡単に加え、
一つが出来たら、他の画面も大半はコピペで作れそうな感じです。

次に、ある２人の技術者がいます。
技術者Aは、業界経験年数はともかく、スキル的には「中級」で、
技術者Bは、業界経験年数はともかく(しつこいw)、スキル的には「新人」です。
働いてほしい時間は、当然ですが同一です。

さて、ここで貴方ならどの様な担当割りを考えるでしょうか？
難易度が十分の一だから、どっちがどっちを担当しても「同じ」だと思いますか？

このシチュエーションは、実装の担当者を決める段階なので、
当然ながら、実装は未着手です。
なので、見積もりは確かに悪くはないのですが、
「不透明な部分」も当然あるわけです。
で、難易度の高い画面で往々にしてあるのが、

「この機能、こうすれば実装出来るはず」
↓
「出来ない」
↓
「ああすれば実装出来るはず」
↓
「出来たけど、速度が遅いとか別の問題が発生」
↓
「じゃあ、こうすれば」

みたいな、思い通りになかなか進まないってケース。
上記の「不透明な部分」がまさにコレ。
勿論、画面B～Kでも発生する可能性はありますが、
でも、簡単であれば簡単であるほど、
「予想」とか「見通し」とかって立てやすいじゃないですか。

で、そんな事を考えると。
これまでの経験で身に付けた問題解決能力を活かせる、中級技術者Aを画面Aの担当にして。
新人技術者Bには、誰がやってもかかる時間がそんなに変わらない画面B～Kの担当にするのが、
比較的安全なマネジメントなんじゃないのでしょうか。

まあ、技術者のスキル評価を「業界経験年数とか資格の有無とかコミュニケーション能力とか」でしている様な人達には、
分からないかもしれませんけど。

しかしコレ、難易度を十分の一と「数値化」したことで、
難易度が同じぐらいに見えるというトリックというか罠というか。
まあ、数値化してはいけないというわけではないのですが。
数値化したことで、上記の「不透明な部分」とかが失われている事に、注意しなきゃいけないって事だと思います。

参考：
質に関する質問

今回は、ソフトウェア開発者なら誰でも知ってる（はず）の、
書籍「人月の神話」に出てくる「ブルックスの法則」について、
筆者の現在の実作業を踏まえて、検証してみたいと思います。
結論を先に書きますと、法則は「やっぱり正しそう」です。
ただし、まだプロジェクトの途中なので、何とも言えない部分もあります。
あと、ブルックスの法則について、一応以下に書いておきます。

「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」

では本題。
現在、筆者はココに書いた増員メンバーの教育（と進捗管理）をしながら、自分の作業をこなしています。
で、増員に伴う作業を加えた上での自分の進捗と、
加えない上での自分の進捗に、だいぶん差が発生しました。
その差、「約1.5(多分この数値が妥当)～2倍」です。
で、実値は出せないので、実値を「アレンジした（もちろん意味は変わらない様に）」数値を用いて、
詳しく分析してみます。
あと、作業内容も若干ぼかします。

1.増員に伴う作業
1-1.増員メンバーへのプロジェクトの説明
1-2.増員メンバーが書いたソースコードのレビュー
1-3.増員メンバーからの質問や相談の受け付け
1-4.増員メンバーの現進捗と今後の見通しの分析

2.増員しなくても行う作業
2-1.自分担当のソースコードを書く
2-2.自分の現進捗と今後の見通しの分析

この内、1-1は基本最初しか行わないですし、
1-3と1-4は大して時間を食わないと思います。
まあ、1-3は本来、結構時間を食われる気もするんですが、
今回のメンバーの場合は、あまり食われないです（苦笑）
原因が筆者にあるのか増員メンバーにあるのかは、読者の皆様のご想像にお任せしますが（苦笑）

なので、今回のポイントは1-2になるのですが、
これが「かなり時間を食う」のです。
なので、ココを更に詳しく見てみます。

増員メンバーが来た2日間は、
プロジェクトの説明と、教育資料的なモノが既にあったので、
それを見てもらって、不明点を質疑応答する形を取っていました。
で、別に筆者はそんなに急がなくても良いと思っていたのですが、
増員メンバーがソースを書き出すと言うので、
3日目からソースを書き出して、それを筆者がチェックする様になりました。
で、そのチェックなんですが、
最初は慣れていないだろうということで、
作業順序を簡単そうなクラス（作業順序の指定はほぼありません）からにして、
徐々に難しくしていく形式にしました。
具体的には、クラスの中の全てのメソッド（関数）を、難易度別に３つ（低中高）に分けて、
最初の数週間（３週間程度）は、全メソッドを（作業フェーズAとする）、
その次の数週間（３週間程度）は、難易度が中と高のメソッドを（作業フェーズBとする）、
その次の数週間（今ココ）は、難易度が高のメソッドのみチェック（作業フェーズCとする）する事にしました。

で、ポイントである筆者自身の進捗（増員メンバーは進捗「は」全く問題なし）なのですが。
上記の作業フェーズAの時と、作業フェーズCの時で、
筆者の日々の進捗に約1.5倍の差が出たのです。
当然といえば当然です。
フェーズAでは、難易度無関係で「全」メソッドをチェックしていたのに対し、
フェーズCでは、難易度高のメソッド「だけ」しかチェックしていないわけで、
チェック量がかなり減っていますから。

さて、ここからが数字（実値をアレンジしたもの）を使います。

A.増員メンバーの今回の作業量→130
B.筆者の今回の作業量→310
C.上記作業フェーズC（ただしチェックはしていない日）の時の筆者の日々の進捗→10
D.上記Bを消化するのに、筆者に与えられた作業日数→54
E.上記A + B（筆者と増員メンバーの作業量の加算合計）→440
F.上記C * D（筆者が作業期間内の消化可能な見通しの作業量）→540

えっと、EよりFの方が「圧倒的に」多いですね・・・
実際には、ここまで単純ではない（作業日数は多分51ぐらい）のですが、ここまで「圧倒的」だと・・・
しかし、予想はしていましたが、まさかここまでとは・・・
計算を間違えたのではと思ったのですが、やっぱり合っているんですよね・・・

今回の場合、「現時点では」ですが、
増員メンバーが居ても、増員メンバーは勿論、筆者の進捗も問題ありません。
ただし、増員メンバーが「どこまで」理解出来ているかは「微妙」な感じであります。
というか、そこが一番重要な所だと思うのですが。
「教育コスト」というのは、
まず「教えられるスキル（知っている程度では教えられないと予想）」が必要と思いますし、
相手が理解出来ているかどうかは、
相手との「コミュニケーション」と「ソース」でしか判断出来ないと思います。
で、今回の場合、感触としては、
ソースチェックは十分だが、コミュニケーションチェックが不十分な感じなので、
「進捗は問題無いが、品質に問題が発生するかもしれない」懸念があると思います。
また、筆者自身の「教えられるスキル」がそもそもどうかというのもありますが、
「不明点は遠慮せずに、つまらない事でも何でも聞いて下さい」とは、
「口を酸っぱくして」言ってますし、
質問や相談が来た時には、自分で判断出来なければ、更に上席に判断を仰いでますって普通の事ですけど。

まあ、いずれにせよ。
現作業ではなく今後の作業を見越しての増員という可能性は残されていますが、
増員が「マイナスにはなっても、プラスになることはない」ぐらいは、
現時点でも言えるのではないかと思います。
別に、増員者が他の人でも特に変わりませんっていうか、
増員者のスキルが高ければ高いほど、筆者の進捗に悪影響が出るだけだと思います。
まず間違いなくコミュニケーションコストが増えるから。

タイトルの通り、今回はPart1ということで、現時点での印象を書いてみました。
Part2はあるかもしれないし、ないかもしれません（苦笑）

今回は、以下の記事に対して突っ込みつつ、
後半は「マネージャとは何か？」について、持論を展開したいと思います。

突っ込む記事：
残業を要求する心理

いわゆる「残業」に対して、とても強い関心をお持ちな現場とか個人(マネージャもどきさん)とか、がいらっさいます

いらっしゃいますね。それも「沢山」（苦笑）
口では出さずに「雰囲気で出す」マネージャさんなんかも。
で、全ての部下がそうなのかまでは分からないのですが、
そういった「雰囲気」を「敏感に察知」して、
マネージャが先に帰るか、「帰れ」って言われるまで、
帰らないんですよね。
だから、マネージャの「帰るなっていう雰囲気を出す作戦？」は、
見事なまでに成功していると思います、困ったことに。
でも、「帰りたいのに帰れない」様な、
そんな気持ちで残業なんてしたって、
良い仕事なんて出来るわけないでしょうにって感じです。
なので筆者は、まず朝に、
「さあ、定時で帰れる様な仕事のスケジュールを考えましょう！」と言い、
そして定時になったら、
「さあ、定時です！帰れ！帰れ！」と、言っています。
「定時で予定していた仕事が終わらなかった場合」は、
「翌日に挽回する」ってスタンスです。
原因と対策を練れば、大体は解決出来ると思いますが。
それ以外（ずっと遅れ続けた場合とか）の場合は、また改めてって事で。

まず、もし「遅延しているとか、そのために増援しているとか」という理由の場合。
「全員残業」ってのはそりゃまぁ「お客様にとってわかりやすい」アピールではあるのですが、この問題の根底にあるのは「営業レイヤーでの伝達と説得が出来ていない」だけです。

ココの伝達と説得が何なのかがちょっと分からなかったんですが。
「残業することは、品質を下げること」を、
営業「が」お客様「に」伝えきれていないってことかなと思いました。

えぇもちろん「綿密な計画に基づく上手な残業」も、理論的には存在しますが。

これは全然分かりませんでした。
こっちは検討すらつかないです。
何かの本にでも載っているのか。

あるいはもし「今後の営業のため」であるのだとすれば、それもまた、根本的な誤りがあります。
もしそれを見てお客様が「是」というのであれば、それはつまり「中身の品質を見ずに、椅子を暖めただけのものを欲しがる」ダメ客である、ということです。ダメなお客様とのビジネスは、必ずダメダメになります。

椅子を暖めたって所は、「ソースコードの行数が多い」によく置き換えられていると思います（苦笑）
好きなんですよね～行数。
そもそも、コードは資産というより負債だって言葉もあるように、
ソースの量は少なければ少ないほどバグも発生しにくいし、良いんですがね。

彼らは「負の生産性」を珍重し、全体的に「技術的負債」がたまっていくのを見て、マイナス記号に気付かずに「をを資産がたまっていっている」とか勘違いしやがります。
現場では、ある程度以上のレベルのエンジニアがそれをみて…あるいは逃げ(正解)、あるいはドンビキして(もう一歩！！)、あるいは絶望にとらわれます(逃げて！！)。

えっと、ここまでブッ飛んだマネージャさんは見たことはありませんが、
筆者は現在「逃げる準備」をしています。
ぶっちゃけると、多分「何をどうした所で、改善は無理」だと思うんですよね。

時々「進言」を果敢にチャレンジしてみたりする人もいるのですが、それで改善されることは極めて稀です。九分九厘、改善されない上に「いやなやつ」扱いされます。下手をすると「作業もしないで余計な事ばかりする人」という認識をもたれます。

ええ、進言をした事が過去にあるのですが、
「面と向かって睨まれました」ね。
で、改善は「されませんでした」。
ああそういえば、「あの上司の下ではもう働けない」と、
その上司の更に上の上司にお願いした時には、
「クビを切られました」ね。
ですのでまあ、「何も言わずに去る」のがベストではないかと。

真摯に「マネジメントとはなにか？」を己に問いかけ続けることが出来る人。

で、こっからが持論です。
タイトルの通りですが、筆者は「マネージャとは親子の親」だと思っています。
で、部下が「子」です。
マネージャが取るべき態度としては、
「部下が今持っている最大限の能力を引き出す為の"環境作り"」だと思います。
で、環境が出来た後は「何もしない」。

では、どうやってその環境を作るのかについてですが。
上記の通り、部下はマネージャが帰れって言わないと帰らない人が多いと思います。
なので、最初は「帰れ！」とは言いましょう。
そうしているうちに、「帰れっていう雰囲気」が出来てきて、
「言わなくても勝手に帰る」様になります。

あと、仕事の仕方やら姿勢に対しては。
これも「最初だけ」は、「どう？順調？ハマっている所とか無い？」とかって、
マネージャ「が」部下「に」声をかけて、
「相談出来る雰囲気」を作ります。
部下は、マネージャが声をかけないと、「何も相談して来ません」。
正確には、相談してくる部下も居るんですが、
そういう部下は、「自分で解決しようとする姿勢が薄い」って事で、
将来的には「あまり伸びない」と筆者は予想します。

そうそう、話が逸れますが、
「自分一人でずっと考えこまないで、"適度なタイミング"で周りに相談しなさい」っていうマネージャさんがいらっしゃいますが、
子供である部下に、"適度なタイミング"なんて自分で判断出来るんですかね？
この発言は単に、声をかけない「マネージャさんの怠慢」です。

で、話を戻して。
マネージャが積極的に声をかけて、「相談出来る雰囲気」が出来れば、
あとは、何もしなくても部下「から」勝手に相談してきます。
で、そこまで出来たらそれ以降は、
子供を砂場で遊ばせてあげる様に、
「何もしない」事です。
勿論、相談されたら、それは話を聞きましょう。

あとは進捗報告なんかも同じですね。
最初「だけ」は、マネージャ「が」部下「に」、
「調子どう？」などと状況を聞いて、「黙っていても報告する雰囲気」を作ると。
それ以降は上記と同じです。

と、まあ、基本はこんな感じではないかと。

そうそう、忘れていました。
突っ込む記事の最後にあった、

マネージャーってのは「上級職」だと思っているので。
基本職が一定レベル以下の人間が、なっていい職分ではないと思うんですがねぇ？

ですが。
えっと、なっていい職分ではないというか、
なったら「プロジェクト失敗します」。
部下が相談（技術的な話だったり、仕事の進め方の話だったり）してきた時に、
マネージャが解決出来なかったらどうするんでしょう？
また、「中途半端に知識があるが故に言う事を聞かない部下」の、
やり方や考え方を改めさせるには、
その部下「以上」の技術力がないと、相手は納得しないと思うのですが。
まあでも、「基本職が一定レベル以下の人間」が、マネージャに「なっても良い」んじゃないでしょうかね。

「プロジェクトが失敗しても良いなら」

進捗会議って、「問題解決の場」ではないでしょうかね？
進捗を報告するだけなら、わざわざメンバー全員を集めなくても良いでしょうし。
メンバー全員を集める目的は、
「どうやってピンチを乗り越えるかを話し合う為」ではないでしょうかね？
で、ピンチって事は、問題だって当然有りますよね？
「ピンチなので、作業に集中して貰いたい。なので、進捗会議は行わない」って、
どうしてピンチになったのかを考えずに、作業に集中させてどうするのでしょう？
ピンチになった原因は管理者が考えるから良い？
管理者が考えてもダメだったから、ピンチになったのではないでしょうか？

今度は、逆の方向から書いてみましょう。
「進捗や品質など何も問題が無い時に、進捗会議を行っても進捗報告だけで終わりません」？
進捗報告だけで終わるなら、わざわざ全員を集めなくても良いのでは無いでしょうか？
コミュニケーションを図る為に？
昼食を一緒に取ったり、仕事が終わった後に夕食や呑みに行けば良いのではないでしょうか？

筆者は上記の様な考えなのですが。
大変残念ながら、同じ考えの人を見たことがないか、
記憶違いだったとしても極少数なのが現状です。

そんなに変な考えでしょうかね？