こんにちは。くろしばです。開発現場で仕事をしていると、複数人でモノを作っていくことの難しさについて考えさせられることが多いです。
今日は開発現場の理想的なチームづくり、マネージメントについて考えをアウトプットしてみようかと思います。
スポンサーリンク
こんなことを考えた背景
ここ数年はフリーランスで色々なチーム、現場を渡り歩いているのでさまざまな色の開発プロジェクトを目にしてきました。
一方、2期目に入る起業した会社(まだまだ副業の域を脱せていませんが)での開発活動では事業が目指すところの目線に立って開発がどうあるべきかを常にウォッチしていく必要があります。
正直どんなチームも理想に掲げた状態でプロジェクトが進行していることはなく、理想を掲げることすらもしていないチームもありました。
まあつまり、
簡単なものではない
そんな当たり前の結論に行き着くことを出発点として理想的な開発、ないしはビジネスの進行を考えてみました。
先出ししておくと、現状で行き着いた結論はある意味思考のロジックから逃げ出したような、なんとも無責任なものになってしまっています。
でも今の僕の脳みそで行き着ける結論としてはそれがすべて、ということです。
マイクロマネージメントによる主従パターン
過剰な責任感が空回りしたり、あるいは個人的な支配欲をビジネスに反映してみた結果に陥るのがこれです。
部下は管理者の一挙手一投足を実現するための忠実な駒となります。
独自性は評価されず裁量の少ない生産活動が延々と続く現場になりがちです。
政治に例えると社会主義に近いものかもしれません。
日本は戦後長らく共産主義から民主主義に移行するための教育が行われてきているので独裁にはあまりいいイメージを持たない人も多いかもしれません。
ただ管理者の独裁にもメリットはあります。
それはTOPの判断が天才的なものであれば、メンバーは天才の手足として機能することできます。
その結果天才の思う方向に真っ直ぐに進んでいくことができます。
それはそれで効率が良いとも言えます。
中国の共産党がいい例かと思います。
ただしデメリットももちろん存在します。
独裁のワンマンマネージメントですべてトップダウンの命令がくだればメンバーはモチベーションを保つことが難しくなります。
高額な報酬を見返りとすればもしくはその仕組みも成り立つのかもしれません。
しかし多くの企業で仕事内容の不満を消し去るだけ高額な報酬を支払うことは難しいですし、組織の進化という意味ではメンバーの持っている可能性は一切日の目を見ない可能性が高いです。
優秀な管理者と潤沢な資本という2つがないと成し得ない構造なのではと思います。
僕が経験した中では、15分以下で自分の作業の報告を求められたものもありました。
自分の実働時間と進捗報告の時間の辻褄が合わない場合は、その"言い訳"を考える時間を毎日確保しなければなりません。
10分間トイレに席を外そうものなら3分ずつに分割して前倒して完了した作業のチケットに計上していく、そんな能力ばかり磨かれました。
上流担当者のリテラシー不足によるエンジニア過信パターン
これは独裁マイクロマネージメントとは反対にエンジニアの工数を過信するパターンです。
上流工程を担当するメンバーの実作業へのリテラシーが著しく低く、エンジニアが計上する工数を全て鵜呑みにしていく構造となっています。
規模の大きい組織では、事業の根幹で何を目指しているかなんて温度感は作業者であるエンジニアには伝わっていません。
その結果、少しでもゆとりを持って仕事するべく作業工数を"盛る"という力学が働きます。
潤沢に資本があれば開発費を湯水のごとく注ぎ込むことで一定期間はやり過ごせるかもしれません。
しかしそんな発展性のない構造の組織がいつまでも続くほど資本経済はあまくありません。
どこかで予算を切り詰められて仕舞えばあっという間に破綻してしまいますし、中で働くメンバーもモチベーション切れの状態になります。
比較的うまくいっているプロジェクトでは、この構造をベースに2つの要素を取り込むことで長期間うまくいっているチームもありました。
1つは、なぜか無心で平均〜ハイパフォーマンスを上げ続けるメンバーが居つくこと。
エンジニアとしての業務そのものに嗜好性を見出して半自動的にスムーズな作業進行を保ち続けるエンジニアも稀にいます。
転職が活発になった昨今では、そのようなエンジニアはある程度スキルアップに満足するとあっという間にいなくなってしまうので恒久的な策にはなりません。
2つ目は、エンジニアが含ませようとした過剰なバッファを、メンバー間の関係の良さによる、ある種の部活感で最小限にしていくことです。
適切なバッファと怠惰なバッファは外側からは分かりづらい状態になりがちです。
そのうち怠惰なバッファを「チームの一員としてがんばらなきゃな」というモチベーションによって自主的に最小限に削らせていきます。
今のところうまくいっているプロジェクトはこの人間関係性依存のパターンが多かったように思います。
理想の開発体制とは
部活パターンは、気の合う仲間が集合するという条件が前提になっています。
過去このようなチームが形成された背景には、部署のTOPが生え抜きで顔が広く、かつ政治力を持った人物であったことで気の合う仲間をうまく自分の部署に集合させることで実現されていました。
結論として「仲良い奴が集まればいいよね！」と言ってしまうと少し物足りない気もするのでもう少し抽象化してみます。
1つ大事なことは「人事」です。
どれだけ考えていっても人間が行う作業である以上は個々のセンスや能力に依存してしまうことは避けられません。
採用時点である程度仕事で成果を上げることが好きなメンバーを集結させることは絶対条件に見えます。
2つ目は「特定の目的」です。
プロジェクトを成功させること、
会社からの昇給を勝ち取ること、
会社の利益を上げること、
実績を収めてキャリアアップすること、
などのチームで共通の目的を追いかけることができれば、北風と太陽のどちらかが過剰になってしまうのようなチームマネージメントではなく、個々の内側からモチベーションの湧き上がる状態が作れるのではないかということです。
まとめ
今後のチームでは、会社の利益という共通の目的を全員で追いかけることとしました。
その場所で成果を上げたメンバーには惜しみなく報酬(給与や休暇など)をバックさせることを前提とします。(まだ創業メンバーの給料もろくに支払えていませんがw)
株式会社の場合、特定の目的は並列関係でどれかを選ぶのではなく、会社の利益を起点にいろいろなものを組み合わせたり捉え方を変えるようなものだと思っています。
ずいぶん長くなりましたがこんな感じで人間とシステム開発について考える起業をしている真っ最中です。
ほんとはだらだら過ごすのも大好きだけど30代は脳みそ麻痺するくらい力を出し切らなきゃなーと。
そしてずいぶん日が空いてしまいましたが思考整理がてらたまにアウトプットもしていこうと思います！
ではでは( *｀ω´)ノ
スポンサーリンク
