エンジニアにおけるマネジメントへのジレンマ

グリーCTO藤本氏が明かす、エンジニアリングの観点をマネジメントに生かす具体的な方法 / @IT

マネジメントやってと言ったら「ええっ」って反応が返ってくるというのは確かによく見る風景で、普段から技術的なことばかりしているとマネジメントというのが畑違いのように感じているエンジニアは多い気がします。

マネジメントという領域がシステム部門ではなく人事や総務、企画や戦略系などの他部門の仕事のように感じてしまうのかもしれません。

ただ、一方でマネジメントしてくれる人はエンジニア畑の人がいいと思っている人も多いのではないでしょうか。

つまりは、自分はやりたくないけど同じエンジニア出身の誰かに管理されたいと思ったりしていてそのジレンマがそこにはあるように思えます。

エンジニアとしてのこだわりが伝えられる相手

何故、エンジニア畑の人にマネジメントされたいかというと1つは話が通じる相手であってほしいということがあるでしょう。

エンジニアって説明下手な人も多かったりしますので、実際のコードや動作を見せるケースって多かったりしますからそれがわかる相手だと余計な説明が省けますし、同じ苦悩や仕事のプロセスなども同調しやすかったりします。

よくありがちなのが、何かを導入する際に作った資料が運用やリソースの状況など数値やグラフが羅列された現場に偏った資料になってしまい、決裁権のある人たちにうまく伝わらないというもので、なぜそれが必要かというのはエンジニア同士だと分かり合えたりしますけど、上層部にはコストやメリットや政治的な観点での説得が必要だったりもして、そういった次元の違うところの仕事に対して億劫になりがちですし、それをエンジニア視点でうまく要約できる人がマネージャーとして存在していれば心強く思うでしょう。

また、「プログラマにとって大事なことを考えるのが大事な理由」に書いたようなエンジニアとして正しいことというのは、非エンジニアにとっては全く理解ができないことだったりします。

コードを書くことのこだわりであったり、時間をかけてその構成を作る理由や、うまく動いているものを作り直す必要性といったことは説明が難しいことではあるんですけど、本人としては断固たる意志があってやっていることであったりもします。

もちろんエンジニア同士であったとしても、担当レイヤーや運用と開発といった組織の違いによっては全く異なるものだったりもするんですけど、譲れないものがあるというこだわりは何となく共有できることで、当人の意思が明確なものについては、エンジニア視点から見ると大体正しいことであったりするわけです。

それをきちんとわかってくれる相手としてマネージャは（元）エンジニアであってほしいと思ったりします。

マネージャとしての適性と適齢期

ただ、マネジメントをしてくれるエンジニアにしても比較的モダンな開発経験のある人にしてほしいと思うかもしれません。

それは、（よくありがちなことですけど）レガシーな開発経験しかない人にその経験論を振りかざされて現場が混乱したり、せっかくの効率化した手法が台無しになることを避けたいということなんですけど、こう考えると比較的マネジメントに向いているのは若いメンバーと歳が近いエンジニアということになるかもしれません。

つまりは、最近まで現場で働きそこで使われている技術やエンジニア文化を知っている人物がより望ましいと感じたりします。

こうなってくると35歳や40歳でのエンジニア定年説というものもマネジメントに移る指標という観点でとらえたら悪くはないのかもしれません（自分はこういった説は否定的ではあるんですけど）。

もちろん当人にとっては開発現場から離れることの抵抗感というのはあると思いますけど、先に書いたようにエンジニアとしての正しさやこだわりというものをきちんと上申できる役割を担えるのはエンジニアしかいないと思うわけで、それは自己表現力を一段階伸ばすきっかけにもなります。

また、世の中の著名なサービスの中にはエンジニアが発想したものというのが数多くあるわけですけど、単に設計書通りに何かを作るというのではなく、一から自分たちが考えたものを作るということは違った楽しさが生まれてきます。

見方を変えれば、現場のエンジニアを助けるには、現場のエンジニア上がりしかないと思いますし、それを担う役割を打診されるというのはそれを任せられる能力を買ってくれているのかもしれません。

マネージャがダメな場合のプロジェクトの末路なんて誰しも身に染みてわかっていると思いますから。

まとめ

実際には、自分たちが作り上げたいサービスやこだわりというものはエンジニア自身が説明すべきことです。

ただ、それにはその感覚的なものをちゃんと説明できるプレゼンテーション能力や、単に数値として羅列したものを組織や事業の発展のためにどう結び付けるのかといった戦略的な観点が必要になってきて、それを億劫に感じてしまうから足踏みしてしまい、それを伝えてくれるマネージャーという存在に頼ってしまう。

ですので、開発現場への執着というもの自分自身凄くわかることなんですけど、マネジメントへの誘いというのはそういった不足している領域を補う一つのきっかけに捉えれば悪くはないことなのかもしれません。

[PR]未経験からプロのエンジニアを育てるオンラインブートキャンプ

[PR]初心者おススメ！24時間サポートセキュリティ特化レンサバ！

[PR]スマートフォンならワイモバイル

関連記事

すぐに身につく技術、すぐに身につかない技術

細切れの時間と細切れのタスク。なぜやるべき事を後回しにしてしまうのか。

開発における感動は薄くなったのか

運営体制とサービスの衰退

40代のエンジニアの働き方を考える

独りのコード、みんなのコード

プログラマにとって大事なことを考えるのが大事な理由

エンジニアの評価と組織の立ち位置との矛盾

エンジニアの想像力を活かす環境、殺す環境

フルスタックエンジニアなんて目指さない方がいい

開発における感動は薄くなったのか

自分も経験があることですけど、開発していて思い通りに動いた時の感動というのはあって、ただ様々な経験を経て新人の時に体験したそれとは違って年々その喜びというのは当たり前へと変化していったりします。

これは慣れと感心ごとの移り変わりの問題であったりして単純な動くものを作るという喜びから、例えばそれがユーザーから得られた感謝とか、より複雑なサービスを長い年月苦労しながらリリースした時の喜びへとシフトしていっているからだと思うのですけど、それでも例え小さなものでも何かものづくりを体験した時の感動というのはエンジニアとして持っておきたいなと思ったりしています。

ただ、近年ではその単純な感動も得にくい状況になりつつあるのではないかと感じたりしています。

単純なものでは喜ばれない時代

1つは、高度なサービスが巷に溢れていて単純な仕組みづくりでは感動を得にくいからかもしれません。

現状では様々な企業が非常に高レベルで複合的なサービスを展開していて、個人のエンジンニアが作るものなど程度が知れていると感じてしまう傾向にあったりします。

また、個人や小さなチームが作り上げたものに対して目の肥えたユーザーが単純にすごいと思ってくれない時代であったりもするので、一昔前の競合がいない（と見えていた）時代からいきなりラスボス級の高レベルなサービスと戦わないといけない状況になってたりもします。

そして、大抵は「それ、あのサービス使えばできるよね」で、打ちのめされます。

システム開発というものがエンジニアの特権であった時代は終わっていて、今では少しの学習と（その気になれば、一定のレベルまでプログラミングは高速に学べますし）高機能で無料のサービスの組み合わせによって簡単に新しいものが作れてしまったりもします。

そして、そういった誰でも作れる新しいものが氾濫していく中で、エンジニアの優位としてのモノづくりというのはその地位が失われつつあるんじゃないかと感じたりします。

これは、以前に「クラウド時代のエンジニアの活きる道 」の中で書いたように、エンジニアとしてもより高度なサービスを支える尖ったスキルを持ったエンジニアと、そうではないエンジニア（これは、より大衆に近い立場にある人たちとなるわけですけど）の二極化が進んでいくのではないかという話に通じるものであったりします。

簡単にモノづくりができる裏返し

もう1つが、簡単にモノづくりができてしまう時代であるが故というのがあるかもしれません。

一昔前では、すべて自前で実装しなくてはならなかったものが、現状では高機能なライブラリや豊富なサービスが提供するAPIなどを通して簡単に新規サービスが作れたりもします。

ただそれは、同時に「自分たちが作っている」という感覚が薄くなってそこから得られる単純なモノづくりへの感動というのが乏しくなってしまったりします。

これは、エンジニア個人としての自己満足な世界であったりもするので、小さくて単純でも自分一人で何かを作れたという感動と、より大きく複雑なものだけど出来合いのものを組み合わせて作れたという感動というのには、実際のところ違いはないんだと思うんですけど、そこで自分が介入できる余地がどれだけあったかで作った感覚というものを通して生まれてくる感情なのかもしれません。

先ほども書いたようにエンジニアとしてのモノづくりの優位性は薄くなってきてはいるので、モノづくりの感動というものも単純に動くものや目に見えるものを作るというところから、より多くの人が使うものや求めているものを作り上げるというところへのシフトというのは避けられないところかなと思います。

まぁ、本来はそれが当たり前で個人としての感動というのは大局的に見れば意味のないもののようにとらえられてしまうんですけど、それでも最初に書いたようにモノづくりの感動というものがなければ新しいものを作る喜びもまたないわけで、そんなシンプルな感動というものをいつまでもエンジニアとしては持っておいてほしいなと思ったりします。

まとめ

個人として作れるサービスというのは、大規模なサービスに比べて非常に限定的で非常に不格好なもので到底太刀打ちができないかもしれません。

ただ、大企業の展開するサービスと競合しないニッチなモノづくりというものにフォーカスを当てれば、まだまだ余地は残っていたりもするので、そういったところから小さなモノづくりを進めていくというやり方はあるでしょう。

そこには、失われつつあるエンジニアとしてのモノづくりの感動がまだあるかもしれませんし、そこで得られる感謝やちょっとした優位性を感じられるかもしれません。

そのことが意味のある事かどうかは置いといて、大きなモノづくりでも小さなモノづくりでも何かを作り上げられた時の喜びというのは持ち続けたいなと感じたりしています。

[PR]未経験からプロのエンジニアを育てるオンラインブートキャンプ

[PR]初心者おススメ！24時間サポートセキュリティ特化レンサバ！

[PR]So-netでauひかり！戸建て3年間2,980円～！

関連記事

エンジニアにおけるマネジメントへのジレンマ

独りのコード、みんなのコード

プログラマにとって大事なことを考えるのが大事な理由

エンジニアの評価と組織の立ち位置との矛盾

エンジニアの想像力を活かす環境、殺す環境

フルスタックエンジニアなんて目指さない方がいい

クラウド時代のエンジニアの活きる道

[jQuery] 組織図が簡単に書けるOrgChart

あまりニーズがないかもしれませんが、社内の組織などを階層構造で視覚化したいという場合に使えるjQueryベースのライブラリです。

体制図を作りたいといった場合にも使えるかもしれません。

OrgChartは、決められたデータソースを指定するだけで組織図を表示できます。

似たようなものとしては、Google ChartのOrganization Chartがありますが、デザイン的にOrgChartのほうが綺麗に見せることが出来る点や、Googleのほうはライブラリのソースをウェブ経由で読み込んで利用するため、サーバーにライブラリを保存して使いたいといった場合にOrgChartのほうが利用しやすいかもしれません。

ただ、jQuery3系でしか動かないため注意が必要です。

OrgChartの使い方

まずは、OrgChartをサーバーにインストール（というか設置）する必要がありますが、方法はページに記載のとおりBowerやnpmコマンド経由でも可能ですが、対応してない場合はGitHubからソース一式をダウンロードして適当な場所にJavaScriptを保存しておきましょう。

後は、サンプルなども付属していますのでその辺を見ればわかるのですが、シンプルな組織図を書く例のHTMLは下記のような感じ。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>組織図</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" />
<script type='text/javascript' src="https://localhost/cmm/js/jquery3.js"></script>
<link rel="stylesheet" href="https://localhost/cmm/css/jquery.orgchart.css">
<script type="text/javascript" src="https://localhost/cmm/js/jquery.orgchart.js"></script>
<script type="text/javascript">
(function ($)
    $(function () {
        var datascource = {
                  'name': '鈴木 一郎',
                  'title': '社長',
                  'children': [
                    { 'name': '田中 太郎', 'title': '部長', 'className': 'manager',
                    },
                    { 'name': '佐藤 花子', 'title': '部長', 'className': 'manager',
                      'children': [
                        { 'name': '渡辺 次郎', 'title': '課長' },
                        { 'name': '高橋 三郎', 'title': '課長',
                        }
                      ]
                    }
                  ]
                };
        $('#chart-container').orgchart({
            'data' : datascource,
            'nodeContent': 'title'
        });
    });
)(jQuery);
</script>
</head>
<body>
<div id="chart-container"></div>
</body>
</html>

上記で出来上がった組織図は下記。

基本的に、dataというプロパティにJSON形式のデータを渡せばそれに従って組織図を表示してくれます。

サンプルにもありますが、HTMLソース内のUL/LIタグを読み取って解析させることも出来るようです。

後は、幾つかオプションが用意されており、例えばデフォルトでは上記のように縦の組織階層で表示されますが、左右にトップ階層を表示したりもできます。

すごいのは、表示した組織図を保存することが出来たり、自分で組織を追加したりといったカスタマイズが出来ることでしょうか。

色合いなどを変えたい場合は、CSSで該当クラスのプロパティを上書きしていくような感じとなります。

ただ、そこまで自由度が高くも無いので例えば組織の箱の幅が狭いから広げたいといった場合に、単純に該当のCSSのwidthとかを弄ると縦表示の場合は綺麗に広がってくれるけど、横表示にすると罫線が崩れてしまうといったところもあるようです。

OrgChartを使うときのTipsなど

組織図の表示は簡単にできるのですが、何が一番大変かってそのデータ構造を作る部分だったりします。

組織は動的に動くことが多いと思いますし、組織が大きい場合はデータ量が多いためHTMLを手動で作り上げるのは現実的ではなかったりします。

組織情報はデータベースなどにあるかと思うので、それを利用してJSON形式に変換するのが手っ取り早いのですが、DBのデータ構造とOrgChartで必要なJSON形式の配列構造には違いがあるのでその差分を吸収する必要があります。

例えば、組織図のデータ構造が下記のようになっているとします。

組織コード	組織名	親組織コード
100	人事部	000
110	採用課	100
120	管理課	100
130	労務課	100

で、OrgChartに渡す必要があるデータ構造は下記（PHPの場合の例）。

array (
  0 => 
  array (
    'CODE' => '100',
    'NAME' => '人事部',
    'PARENT' => '000',
    'children' => 
    array (
      0 => 
      array (
        'CODE' => '110',
        'NAME' => '採用課',
        'PARENT' => '100',
      ),
      1 => 
      array (
        'CODE' => '120',
        'NAME' => '管理課',
        'PARENT' => '100',
      ),
      2 => 
      array (
        'CODE' => '130',
        'NAME' => '労務課',
        'PARENT' => '100',
      ),
    ),
  ),
)

要は、親組織の中にchildrenキーをつくりその中に子組織の情報を入れ子にしてあげなくてはなりません。

で、これを作るための変換用PHPスクリプトが下記。

public function createTreeInArray($divisionList = [], $rootParantCode = "000", $codeColumn = 'CODE', $parentColumn = 'PARENT') {
    if (! is_array($divisionList)) {
        return false;
    }
    $tree  = [];
    $index = [];
    foreach ($divisionList as $value) {
        $id = $value[$codeColumn];
        $pid = $value[$parentColumn];
        if (isset($index[$id])) {
            $value['children'] = $index[$id]['children'];
        }
        $index[$id] = $value;
        if ($pid == $rootParantCode) {
            $tree[] = & $index[$id];
        } else {
            $index[$pid]["children"][] = & $index[$id];
        }
    }
    return $tree;
}

データ構造の変換ができれば、後はjson_encode()を通すだけです。

もう1つは、組織の箱をクリックした際に開閉するようなイベントが付随しているのですが、個人的にはいらないと思ったり。

ただ、オプションで消すことが出来そうにないので、クラスを削除することで開閉イベントのトリガーが発生しないようにしてみました。

$('.leftEdge').removeClass('leftEdge');
$('.rightEdge').removeClass('rightEdge');

後は、組織や人名をクリックした際にイベントを発火させたいということをしたいかもしれません。

これについては、シンプルに受け渡すデータの中にJavaScriptのコードを埋め込むか、クラスの指定ができるのでクラス名を指定しておいて、別でそのクラスに対してのクリックイベントを付け加えるということで対応ができます。

最初の例で書いたJavaScript内には部長に対してclassNameのプロパティでmanagerをセットしています。

あとは、このクラスに対してclickイベントを書いてあげるといった具合です。

[PR]サインアップ３分、すぐに固定IPが利用できるプロバイダ

[PR]スマホやTV、PCで、いつでも映画や海外ドラマを見れる！今すぐ無料視聴！

[PR]初心者おススメ！24時間サポートセキュリティ特化レンサバ！

関連記事

[JS] 多様なグラフを作ることができるC3.js

[JS] Webアプリケーションでデスクトップへの通知機能を作る

Datepickerで日付を連続して選択できるようにする

ノンプログラミングでも利用可能！PHPで多様なグラフを作れるpChart

[PHP] 簡単に画像の加工ができるintervention/image

ImageMagickを使ってコマンドラインからCAPTCHAを作ってみる