ポエム

エンジニアから見た残念なマネージャーの5つの特徴

今回はエンジニア目線でちょっと残念だなと思うマネージャーの特徴というものを列挙してみたいと思います。

※私個人の主観になります。(独断と偏見とも言う。。。) 愚痴っぽくなったら、すいません。

1. 技術知識が古い or まったく知らない

酷いマネージャーに共通している特徴がこれです。

プロジェクトマネージャーがこの特徴をもっていると、最悪の場合、プロジェクトが終わらない、プロジェクト後半、酷い場合はリリースしてから動かないことが判明するなどに進展します。

マネージャーをする人はだいたい元エンジニアだったりするので、技術をまったく知らないという人はあまりいないのですが、知識が古い人が多いです。そもそも技術にあまり興味がないからマネージャーにシフトしたというタイプの人がこれにあたります。中には技術がまったくわからないという人がマネージャーの場合もあります。別の専門からやってきてマネジメント経験はあるというパターンですね。

いずれにせよマネージャーがこれらのタイプだと、開発陣には悲劇しか待っていません。そもそも技術がわからない、知識が古いとなると、いわゆる話ができない状態になるので、開発はマネージャーを諫めることができません。そんな気もおきません。辟易として適当にタスクをこなすだけになります。プロジェクトがどんどん変な方向に進みます。

マネージャーの皆さんへ

いや、わかります。マネージャーはやらなきゃいけないことが多岐にわたります。進捗管理、予算管理、HR、ユーザ折衝、etc… 技術なんて専門家にまかせておけばいいですよね。開発陣は皆、マネージャーがプロジェクト成功に向けて邁進していることを知っています。感謝しています。でも、もう少しだけ技術把握の優先度を高めていただけないでしょうか。

雑誌購読しろとまではいいませんが、せめてQiitaの週間ランキングにあがるものの中で、今のプロジェクトと関わりがあるものは理解できるレベルでいてください。理解できるだけでなく自らそのぐらいの情報はキャッチしていくマインドは持っていて下さい。

2. 設定したものをいつまでも使おうとしない

開発がせっかく実装したもの、セットアップしたものをいつまでも使わないというのは開発のモチベーションを一気に下げます。それを使わないから、新たな問題が発生したり必要なテストが増えたりで余計ないタスクが増えます。

これもそもそもの原因には、技術知識のなさ、興味のなさがあります。興味がない、知識がないから使おうとしないんですね。

で、すごいあとになって使ってみて、動かない、使えないと騒ぎ出します。開発はずっと前のことすぎて覚えていない可能性がありますし、時間経過によって前提が変わっていて動かないの当たり前でしょということになります。

マネージャーの皆さんへ

いや、わかります。時間がないとかまだ煮詰まっていないとかいろいろ事情はあることでしょう。

でもなるべく、自分が要求したものは、あがってきた時点ですぐ取り入れるようにしてみて下さい。取り入れることで良い方向に進む可能性があります。先送りにすると後で余計なタスクが発生する可能性が高いです。

3. すぐにバージョン固定しようとする

マネージャーはすぐに動作環境、つまり、言語、フレームワーク、コンテナのベースイメージあたりのバージョンを固定したがります。何かあったときに、「この環境(バージョン)では、動作できることは確認済みです」と言えるようにしておきたいからなんですね。

これはよくわかります。開発の人でもバージョンを固定したがる人は多いです。

プロジェクト規模が大きい(人が多い、入れ替わりが激しい)場合は仕方がないと思うのですが、私は開発期間はなるべくバージョンは固定せずlatestで回した方がいいと思っています。バージョン固定はリリース前にするのが理想です。理由は以下。

  • 開発期間にバージョン依存の問題を発生させたほうが知見がたまり、リリースしたときも役立つ可能性がある。
  • latestにしたほうが便利なことが多く、何か課題が発生したとき解決する可能性が高い。
  • バージョン移行に強い実装になりやすい(旧バージョン前提の実装をなくしやすい)。
  • 開発者のモチベーションを維持しやすい。

マネージャーの皆さんへ

いや、わかります。バージョンなんて固定してしまって問題の発生源は1つでも潰しておくにこしたことはないですよね。でもlatestバージョンにするメリットもかなりあるんです。せめて比較検討ぐらいはしていただけませんでしょうか。

4. 運用を見据えてない

運用まで見据えた意思決定ができないマネージャーがいます。現在のフェーズ、開発フェーズやテストフェーズを終わらせることを目的とした意思決定をする人がいます。

それゆえ開発陣は運用には関係ない暫定対応のバグに追われる、テストのためのテスト、運用では発生しえないケースのテストをしたりとかに陥っています。

システム構築の目的は、リリース後、安定して運用し続けること、もっと言えば運用し続けて顧客の利益に結びつけることです。リリースすることが目的ではありません。(受託なら、それが目的かもしれませんが・・・)

マネージャーの皆さんへ

いや、わかります。まずは検収を通してリリースに至らないことには何にもならないですよね。とりあえず進めるという選択肢は間違っていないですよね。でももう少しリリース後のことを、運用のことを、全体最適という視点から考えていただけないでしょうか。

5. Excel信仰

いまだにExcel信仰のマネージャーがこの世に現存しています。全てのドキュメントをExcel方眼紙で作り、印刷して納品しようとする人がいます。マークダウンって知っていますか。ドキュメントツールというものを知らないのでしょうか。静的コンテンツを簡単にWeb化できることを知らないのでしょうか。

酷いのになると、プロジェクト管理ツールを導入しているのに、独自のフォーマットをExcelに落とし込んで、それで進捗管理を強要しようとする人がいます。

Excelを使う領域は、簡易的なデータ管理やデータ分析ですよ? 方眼紙にして好き勝手に使うって、それもうただのお遊びですよ? 何の生産性もない行為ですよ?

マネージャーの皆さんへ

すいません、わかりません。ITリテラシーを上げてください。そもそもマネージャーに向いていない可能性がありますので、別の道を探してみるのも、いいんじゃないでしょうか。