リーダーの仕事って何だろう？：あるエンジニア、かく語りき（2）（3/3 ページ）

» 2013年12月16日 00時00分公開

　私にとってこれは、本当に幸運でした。問題点を指摘されたり批判されることはあっても、「どのようにまずいのか」「どう改善するべきか」を正面からぶつけられることはほとんどありませんでしたから。言われたことで落ち込みもしましたが、同時に感謝もしましたし、言われっぱなしではあまりにも癪だったので、何とかしようと思いました。

　M君とはそれからたびたび話をするようになり、いろいろなフィードバックをもらいました。

　「あなたが舐められると、チームの影響力が低下する。影響力を失ったアーキテクトは惨めなものです。根拠のある見積もりを示し、予実を見えるように管理してください。スケジュールを見せないリーダーはゴミだし、管理されていない進捗管理表もゴミです」

　「クライアント側の動向、意向は早めにつかまないと、変化を予測して対応できませんよ。どうして『それは営業サイドの話』なんて、他人ごとのような顔してるんですか？必要なら介入してコントロールしてください」

　「教育の意識、持ってますか？今のチームの力で目的達成が難しくて、人の追加の権限もないなら、チームを育てるしかあなたにできることはないでしょう」

　「チームの外でルール外の戦いが起こっているなら、あなたは何でチームの外に出ていかないんですか？政治に背を向けた時点で、あなたは対等の勝負ができなくなっているんですよ」

　などなど。ワンコインバーで終電近くまで、こんな感じの会議をしました。酒が入っていたので、後半はお互いに適当な感じになっていました。自分の名誉のために書き添えておくと、プロジェクトの後半に入ったころにはこういった指摘はあまり受けなくなりました。ある程度は改善されたのだと思います。

　リーダーという仕事を実際に務めて学んだことは、突き詰めると「戦う必要がある」「リーダーの判断には、他人も巻き込まれる」ということです。

　大勢が関わる仕事には、さまざまな要因でいろいろな思惑が入ります。利害は対立するし、外部のチャチャは入るし、上司は間違えます。ルールを決めても無視されるし、変えようとすれば抵抗に逢います。あらゆるところで衝突が発生するし、衝突を回避しすぎれば何もできなくなります。必要であれば戦いながら、それらの混沌とした状態をうまいこと目標に向けていくのがマネジメントなのでしょう。

　また、こういった問題を継続的に乗り越えていける組織を作ろうとするなら、それは「システムを作るシステム」の構築に他ならないとも思いました。納品の直前に私は別のプロジェクトに異動しましたが、風の便りでプロジェクトがうまく着地しなかったことを聞きました。仕事上の失敗で本気で悔しいと思ったのは、それが最初です。

戦うリーダー

　今回は、マネジメントについて学習する機会があったこと、実際にリーダーという役割に立って失敗したことを紹介しました。

　「リーダー」や「マネージャー」という言葉は、エンジニアのキャリアの上で1つのキーワードだと思います。規模によっても立場によっても、関わっている契約の形態によってもその役割はさまざまですが、私がポイントであると思う点は、以下のようなものです。

マネジメントやリーダーシップは、生来の性格や資質によって自然にできる行動ではなく、目的が明確にある行動である。
責任範囲の仕事を確実にこなすためには、責任範囲の中だけを見ていては絶対にまずい。要求のマネジメントや外部要因のコントロールはとても重要で、関われない範囲があったらリスクとして警戒するべきだ。
プロジェクトにはいろいろな立場の人が関わっていて、内部での利害対立が簡単に起こる。上司やその派閥と対立することもある。
必要なら戦うこと。大きな声の人におびえて不戦敗しないこと。

　「生来の性格や資質で自然にやる行動ではなく、目的が明確にある行動」という感覚は、前回の「規範があって分かりやすい」という感想にも通じるのかもしれませんね。

　今回の話で、私は「アーキテクト」という仕事をしています。この言葉、最近もてはやされていますが、当時は「何それ？」という感じでしたし、自分でも「何それ？」でした。けれども「プログラマー」から「アーキテクト」へと肩書きが変わると、考えることが変わってきます。

　それはまた次回に。