読者です 読者をやめる 読者になる 読者になる

開発するときに考えていること。信頼関係 マネージャ編。

組織パターンを読んでたら@haradakiroさんに「そんな風にして自分の頭の整理できるよ」と言われ。なるほど。と。なので整理。とはいえパターンに昇華させられるまで考えられたりはできないので雑だよ。

作りながら書いてるから最終的にどうなるかは僕も知らんよ。

立ち位置

最初に立ち位置を簡単に。
僕は自社でWebサービス作ってる会社のいちウェブアプリエンジニアです。

いい感じのチームでコードを書いて過ごしたい!

じゃあいい感じのチームを自分で作ろう!

じゃあチームの外側のコントロールしなきゃ!

ってだんだんやりたい場所から遠ざかっている感じ。てイマココ。
まぁこれも悪くない。

開発するときに考えていること

f:id:bufferings:20131008230854p:plain

まずは何をやるにも信頼関係を築くのが最初に必要よね。ないと色々面倒。

信頼を得て最初に取り組んだのが、プロジェクトのリーダーをBizLeadとDevLeadに分けたこと。

  • BizLead: プロジェクトのビジネスサイドのことをリーディングする人
  • DevLead: プロジェクトの開発サイドのことをリーディングする人

に分けて、自分がDevLeadをやることにしました。

DevLeadとしてプロジェクトをどんな風に回そうかと考えた時、まずAgileを捨てましたAgileのプロセスを採用するんじゃなくて、現状にあったプラクティスを採用することにしました。なので、例えばイテレーティブなウォーターフォールが一番あってそうだと思ったらそれを採用しようと思ってました。(結果としてScrumになっちゃいましたが:)

それを土台にして、プロジェクトマネージメントチーム作りDevLeadとしての動きを考え中。

信頼関係 マネージャ編

全体はそんな感じで、今日は自分がマネージャの信頼を得ることに関して考えてることをつらつらと。

f:id:bufferings:20131008235829p:plain

まずは相手の立場を考えるところから。自分の視点からだけで、いくらやりたいことを言っても届かなくて、相手の立場で「それはいいねー」って思ってもらえなきゃ。

3ヶ月だけ会社の研修でサンフランシスコで仕事してたときがあって。それで日本に帰ってきて気づいたのが。日本のマネージャって「プロジェクトの最終責任者」だし「人材育成の責任者」でもあるのね。

プロジェクトを僕が回して失敗したとして、その責任って僕だけじゃなくてマネージャがとるし。僕が誰かに迷惑かけたとしてそれを謝るのもマネージャだったりするわけ。

さて。ゴールからの逆引きで考えよう。

僕がそんなマネージャのポジションにいたとして、こいつにならプロジェクトを任せてもイイ。と思えるのはどんな人だろう?こいつはマイクロマネージメントしておきたい!と思わせてしまうのはどんな人だろう?

それは、安心感と納得感かなと思いました。

情報共有に対する安心感

状況を聞かなきゃ教えてもらえないのは嫌。じゃ、報告ミーティングしてよ。ってなっちゃうし。
そもそもそれで大丈夫だと考える人を信用するの僕は無理だなー。

さらに、マネージャって忙しいよね。
見える化して状況見えてたとして、見えるようにしてるのに見てないあなたが悪い、的なのも嫌だな。
忙しい中でも情報がちゃんとpushされて伝わってくる状態、つまり見せる化しておきたい。

それと、マネージャしてて困るだろうなーと思うのは。導火線のなくなった爆弾を渡されること。
いや、お前、もっと導火線長い時に渡してくれたらなんか色々手がうてたかもやん!もう爆発するやんこれ!

たぶん、プロジェクトが失敗すること自体よりも、もう何も手が打てない状態で渡されるのが嫌。
マネージャとしても全部手を打ったけど爆発しちゃった、ならまだましよね。
だから特に、悪い情報はできるだけ早く見せること。

あと、何か問題を報告をしてくれたのはいいけど、どうしたいと思っているのかを添えて欲しい。
「問題が起こりました」「・・・で?」ってなるよね。
問題が起こった時に、自分の意見を出しもせずに言われたとおりにするだけなら、いやこっちで管理するわ。

スキルに対する安心感

エンジニアだからね。任せても大丈夫だと思える開発スキルがないと始まらないかなと。

また、新しいことを提案するときに、あると便利だなーと思うのが「これまでのやり方でもうまく回せること」。
これまでのやり方ですらうまく回せないのに、新しいやり方で回せるの?って思うかなー。

失敗に対する安心感

情報共有のところでも挙げたけど。リスクの認識や、失敗の認識や、嗅覚が、鋭いほうが良いね。
失敗するかもしれないけどギリギリまでがんばってみる!ってのはエンジニアとしては分かるけど。
全体を考えたら、それ導火線なくなるよね。

こいつに任せておいたら、失敗する可能性が出てきたかもって感じた瞬間に教えてくれるから安心だわー。
が必要かな。

責任感は説明いらんや。

んで、失敗の理由を誰か自分以外のせいにしたり、状況のせいにしたりする人は、嫌だな。
同じ状況になればまた同じ失敗をする。

失敗の理由を自分の中に探して、次は自分がこう動けば失敗しなくて済む、と考えられる人は同じ失敗はしないよね。

また、そんな風にして、同じ失敗をしないというのは信頼のために大切。

組織に対する安心感

現状で何か歪を見つけたとして、そこって、不満を言ってても仕方がなくて。
どういう経緯や理由でそうなっているのかをよく考えて、それを改善していく提案をしていけばいいかなーと。

変化というのは関係する人に負担を強いるので、僕みたいな現場から動く場合は
大きく変えようとするより、小さな改善を積み重ねる方が良いかなと思うす。

それと、僕らはプロジェクトを成功させようとして取り組むわけだけど。
それとは別に、会社全体のことを考えると、メンバーの成長ってのは後に残る価値なのよね。
だからそこも考えたい。

プロセスに対する安心感

Agile開発をやりたいです!って言う人に任せるのは心配だなー。
そうじゃなくて、どうすればビジネスにとって最も価値のある開発をできるかを考え続けてる人の方がいい。

安心感と納得感

まとめると、こいつに任せておいたら

  • ビジネスのことを中心に考えてくれるし
  • 必要な情報を必要なだけ必要なときに共有してくれるし
  • 必要なときに判断を仰いでくれるし
  • プロジェクト全体を見てリスクの判断をしてくれるし
  • 開発スキルもあるし
  • だけど失敗しそうな場合は早めにアラート上げてくれるし
  • 組織をどんどん良くしていってくれる
  • そして、こいつと一緒に仕事をして失敗したなら、それは仕方がない。と納得できる。

と思ってもらえたら、信頼して任せてくれるかなー。
と僕は考えてるってことですね。なるほど。

ごちゃごちゃと自分の言葉で長くなったけど。うまく伝わってるといいな・・・。