オレオレプロジェクトマネジメント

前職でマネージャーっぽいことやってたので、振り返りがてら自分が考えてたこと晒しておきます。正しいマネジメントなんかないと思うのし、あくまで個人の考え方に過ぎませんが、誰かの参考になれば幸いでっす

前提

とあるITの現場
なりたくてマネージャーになったわけじゃなく、あくまで上司から「お前ぐらいしか雰囲気出来そうな奴おらんからよろ」ぐらいの消去法で選任された状態からスタート

ポリシー

プロジェクトの成功は顧客を満足させるという普通の成功とメンバーの成長と2つ考える
コミュニケーションはフラットでメンバーとの距離はなるべくなくす
情報共有は行って基本オープン
上司は全力で使い倒す
リーダーシップを発揮する
その他いろいろ

プロジェクトの成功は2つの軸で考える

プロジェクトというのは何らかの目標に向かって進む集団であると思いますが、プロジェクトによって得られるものは基本的には顧客を満足させるもの。BtoCのビジネスであれば消費者に何らかの価値を提供するとかまぁ普通の話です。

ですが、その過程がグチャグチャになりプロジェクトで何のメンバーが何も得ることがないのは非常に嫌でした。プロジェクトが完了して、売上◯億円達成！ただし退職者が10人出てメンバー1/3消えたとか意味がわかりません。

なので自分がマネージャーのときはメンバーのモチベーションがどこにあるのかを考えてました。難しい技術的な負債に挑戦したい人、UIとかフロント寄りの技術やりたい人とかとか。

それぞれがやりたいことがあってその仕事がプロジェクトにあれば基本は任せていましたし、仕事がなかったら可能な限り自分が作ってました。モチベーションがある人がその仕事をやるのが一番パフォーマンスが出ると考えていました。

しかし、これが非常に難しい。

DeNA南場智子さんの講演「ことに向かう力」がいい話だった【全文】 - NAVER まとめ

モチベーションを何から得ているのかがまったく異なっている人たちをまとめていくのはすごく難しい。難易度が高いことだなと感じました。

あくまでマネージャーから見て思ったことを当てはめているだけにしかすぎないので、正解かどうかはわかりません。ですが、プロジェクトが終わった後にあのプロジェクトよかったねって言ってもらえるのがメンバーからの最大の賛辞だと思っています。

コミュニケーションはフラットでメンバーとの距離はなるべくなくす

コミュニケーション周りは結構気を使っていました（ただし若干雑）

メンバーが何を考えているのか？不満はないのか？みたいなことを聞き出せるといいんですが、まぁ普通は距離があるとそんなにぶっちゃけてはくれないものです。

そのためには自分を信頼してもらうしかないので、メンバーが不満に思っていることを改善したりしてマネージャーに話したら何かしてくれるオーラを出すことが大事。まぁでも一番効果があったのはオレがめちゃくちゃ悪口言いまくってたのがよかった気がする。 (良い子の皆さんはマネしないように)

やはり人との距離を縮めるのは陰口だな(とあるラノベ)

必要であればメンバーと1対1の面談もやる予定でしたが、必要性を感じなかったのでやってませんでしたが、無理矢理にでも話す環境を作るのが大事だと思ってます。 1対多では話す内容も変わってくるので思ってることぶちまけてもらったほうがいい

ほぼ日刊イトイ新聞 - 社長に学べ！任天堂の社長、岩田聡さん面談はこんなに大事なのか

最初に全員に話をきいてみて「面談してはじめてわかったこと」がものすごく多かったんです。「人は逆さにして振らないとこんなにもモノをいえないのか」とあらためて思いました。

いろんな人に面談すればするほど、わたしはいろんなことがわかりまして、そのなかからどういうふうに組織を作りなおして、どういう運営をしたらよくて、なにがみんなのやる気をひきだすことに役にたっていて、なにがみんなのやる気を阻害しているのかとか……すべて見えてくるんですね。

情報共有は行って基本オープン

これはTeamGeekの影響が強いです

Amazon.co.jp： Team Geek ―Googleのギークたちはいかにしてチームを作るのか

エンジニアはコミュニケーションをできるだけ排除してコードを書かなければいけないと考えている。しかし、情報を伝わっていなかったりすると、君が正しいコードを書いているという保証はない。できるだけ多くの人、プロジェクトの文章からすべての情報を取得できることが重要だ。

どこでもいいけど、情報が1箇所に集まっててそこから辿れるようにしておくことが重要だと思ってる。 URLさえわかっていればいいので、全部リンクをかき集めておくことを追えるようにしておいた。

さすがに新しいツールバンバン入れるのはつらいのでなるべく揃えるようにしていたが、デザイナーさんがDropBoxでエンジニアがgitでとかリソースがグチャグチャになるのは一定仕方ないと諦めてなるべく自分が間に入ってコントロールしていた。デザイナーさんにgit使ってやってよって頼んでもそこの学習コストで払うぐらいなら自分でコミットしたらいい。デザイナーさんが勉強したいって話であれば別だが…

エンジニアに優れた仕事をしてもらうにはエンジニアが安全にアイデアを共有できて、意思決定プロセスに口を挟めるような文化を作らなければいけない。開発に参加するだけでなく、プロダクトの意思決定プロセスに参加したいと考えてる。つまり合意ベースのマネジメントが必要。優秀なエンジニアは自分で運転できるバスに乗りたいからだ。(これもTeamGeek)

ただの席替えでもこう決まりましたって結果報告するだけ揉めるつらさ
基本はメンバーに意思決定プロセスに参加する必要があるが、全員参加させるとカオスになることもあるのでその辺はバランス見て調整する。トップダウンで進めるかボトムアップで進めるか考えながら情報共有してすることを意識

上司は全力で使い倒す

誰が言ったより何を言ったかが大事という話はありますが、やっぱり上司の発言はフラットな現場において重要。

6人の現場内で決めるのに10分かかった場合、工数は1時間にもなる。
しかしオレが上司に「これこれこういう理由でこういうことしたいんですけど、言ってもらっていいっすか」って丸投げしてって上司に発言してもらえれば5分で解決。
全体の工数浮くし、不満があとであってメンバーから上がってきたらあの時言ってないから合意してるはずなのになんで今更言うの？って聞けば感情的に収まりやすい。

上司とのやりとりはクローズで行う事が多い。なるべく情報やコミュニケーションの場所をオープンにしたほうがいいとは思うが、誰かが「私、◯◯さんのことが嫌い仕事したくないです」みたいな発言をオープンな場所でされたらチームの雰囲気が殺伐としまくる。
こういう情報はメンバーとの距離を縮めておくと事前に出てきやすいので、そのまま上司に丸投げ。
いろいろ調整したりとかはお願いしつつ、上司は現場と距離があるのでオレがメンバーの情報を伝えまくったりしてた。

この上司に情報を流すという一見スパイ活動のようなゴマすりはオレのためになるかは正直よくわからないが、ここではオレと上司との距離をなくす意味でも情報を全部吐き出しておくと一定の信頼をもらえるので、やっててよかったように感じる。

上司は上司で現場の情報欲しいだろうし、オレはオレで現場を動かして欲しいからお互いの利害が一致していたと信じてる。

リーダーシップを発揮する

マネージャーは何をするのかはドラッカーの本とかにいいこと書いてるかもしれないが、自分は以下の2つ

問題解決
何かを判断して仕事を1歩進めること

現場をとにかく回してプロジェクトを1歩進めることを意識。そのためにはリーダーシップを発揮して頑張るのが常だと思う。
リーダーシップって表現にはいろいろ含まれているだろうが、自分が考えるリーダーシップはなんだろうって考えたときに以下のブログが非常に共感できた。

僕は「リーダーシップ」なんてものを持ちあわせていない。 - 自省log

統率ができているわけではなく「僕を使って皆に楽しんでほしい」「楽しんでいただいている」という感覚で接することの結果が運良く出ているだけなのだ。一番後ろから、皆が進む先の障害物を取り除かせていただく。

リーダーって聞くと集団の先頭に立ってグイグイ引っ張っていくイメージが多いが、オレはそういうプレイヤーでもはない。
自分が先頭ってことはチームの先頭が自分であってそれがチームの限界ですって言ってるようなものだと感じる。
なのでオレがやってたリーダーシップってのは本当に後方支援タイプのリーダーシップだったと思う。

オレはチームの主役じゃなくていい(スラムダンク魚住)

オレみたいな人間が一番できるみたいな思いあがりはせずにチームのためにいかに動けるかを意識

その他

いろいろな人に相談した時のメモが残ってたので残骸晒しておく

QCDで物事を判断しろ(品質 Quality、価格 Cost、納期 Delivery)
仕事を作れる人になれ
メンバーの手を止めるな
マネジメントはケツをふくのであってクビをツッコむな
最短時間で最低機能を作ることを目指す
周りが何してるがわからないと不信感が生まれるのでいけない
失敗しても人は死なないし、成功しても同じチームをマネジメントする経験はないだろうし、気楽に楽しもう

採用決定権のある/なし

この間とあるところで話してて思っただけだが、自分がマネージャーやってた当時は自分にエンジニアの採用決定権がなかったのでちょっと視点が違うなと違和感があった。 (これは良い悪いという話ではなく、あくまで視点が違うなというだけ)

ゴミ拾いばかりしてたら「夢の島」が出来ちゃった！――伝説のクリエイター集団Bio_100％の森栄樹氏がゲストの「ゲーマーはもっと経営者を目指すべき！」第10回 - 4Gamer.net

川上氏：いやいや，優秀だったって。森さんのデッキはSレアカードだらけだったじゃないですか。こいちゃんとかさ。

森氏：確かに僕は，レアガチャを引いてた感じだったね（笑）。

川上氏：そうでしょう。清水くんだってさ，能力は偏ってるけど，ある種のスーパーレアだったわけだし。

川上氏：僕なんかずっと無料ガチャで，ノーマルカードで勝負してたんだから。しかも，全員めちゃくちゃパラメータが偏った使いづらいカードばっかでさ。酷い話ですよ。

この記事読んで変に共感してしまった。

上司から「お前このデッキで半年戦ってくれ。よろ」って投げられたデッキが全部ノーマルカードみたいな状態だったらどう思うか。
ノーマルカードを成長させてレアカードぐらい強いカードに成長させる以外の選択肢がなくて、そのためにはメンバーのモチベーションどうしようかっていろいろ試行錯誤の日々。

が、採用決定権がある人だとガチャ回してレアカード引くかという視点でモノを考えるんじゃないかなぁと思いました。
チームの文化作りとか会社を中長期的に考えて採用をするので視点が現場よりも高い目線にはなるはずです。これが現場にどう影響出るのかとか考えると採用ってやっぱ難しいなぁ…

当時読んだ本とかリンク

リンク

ぽんぽんぺいんなう＼(^O^)／ | プロジェクトマネジメントなう＼(^O^)／

監督とは、他人が打ったホームランで金を稼ぐことだ。

かつてネトゲで数十人を率いた妻の「マネジメント論」 - chocontaの日記

かつてネトゲで数十人を率いていたという妻「相手が欲していることは何で、どうやったらモチベーションを高く持ってくれるかを必死に考え抜くの。そうしたら勝手にみんなが動いてくれる。それがマネジメントだよ。

プロジェクト推進者のための議事録の書き方 - 人と組織と、fukui's blog

プロジェクトを前に進めるために、ちょっとしたTIPSのようなものも身につけてはいるつもりだけど、基本はやっぱり議事録だと思う。

本

Amazon.co.jp： Team Geek ―Googleのギークたちはいかにしてチームを作るのか

エンジニアが他人とうまく開発するコツが書いてある。

Amazon.co.jp：ピープルウエア

実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。

まとめ

マネージャーやっててよかったと思う。
マネージャー視点の現場って貴重かどうかはわからないが、上司の気持ちみたいなものを理解して仕事をするって結構大事で仕事の進め方とかは以前よりはうまくはなったはず。。。。

実際に上に書いたようなものを100％実践できていたとは思いませんし、失敗も死ぬほどやってます。同じ失敗を2度と繰り返さないことを意識しつつ、人間という形でできた知恵の輪を解くみたいな感覚で楽しみながらマネジメントしてみてはいかがですかねー。

困ったら始末書出したらええねん(オレ)