A Day In The Boy's Life -26ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

最近、採用の広告などでフルスタックエンジニアという言葉を見かけます。

あんまりよくわかっては無いんですが、ネットワークやサーバー、OSなどのインフラ関連からプログラミングやHTMLなど幅広いレイヤーの知識を持っている人を募集しているようです。

 

個人的にはそんな人がチームに入ってくれるんなら願ったりかなったりだとは思うのですが、技術が複雑さを増していく中でそんなレイヤー1から7とかまでをちゃんとわかっている人なんてそうそういないだろうとかも思ったりするわけです。

 

 

 

フルスタックであることの難しさ

 

 

 

最近は高度なライブラリが揃っていたりクラウド系のサービスによってそんなに知識が無くても新しい仕組みを作ったりすることはできたりします。

 

ただ、それを支えるエンジニアという職業から見れば、やっぱり一つ一つに対してきちんとしたスキルを持ってないと通用しないわけで、じゃあそれが幅広いスキルを横断的に身につけられるかというと技術の多様化によって決して楽なわけではない状況です。

 

確かにネット上には技術ネタを書いているエンジニアブロガーや、企業でもその情報を数多く公開していたりもしますので、一昔前よりは困るレベルは低くなっています。

 

それでも技術の変化などによって新たに会得しないといけない知識は年々増えていっているわけで、確かにインフラからフロントエンドまでかなり密に連携しているわけですからそれらを全てマスターしているに越したことはありませんけど、エンジニアの求められるスキルレベルは上がっていっていると思ったりします。

 

前に「クラウド時代のエンジニアの活きる道 」というエントリで書きましたが、この辺は募集対象のエンジニアの仕事によるんでしょうけど、現在ではクラウドサービスを作る側と使う側とで二極化していったりしてるので、後者ならまだしも前者においてはかなり複雑なスキルが求められます

 

そんな中で、フルスタックな知識を求めるなんて、おいおいちょっと待てよって気分にもなってくるわけですけど、確かに技術というのは1つの分野で完結するものではなく、関連性があるものまで知識を持っていないとなかなか解決できない問題もあったりします。

 

一極集中、この分野だけで飯を食っていくんだと言ったところで、例えばプログラミングだけであったとしても、通信においてはネットワークが、ファイル操作においてはOSやファイルシステムの知識も要るわけですから、なかなかプログラムの知識が非情に長けているから良いというわけにもいきませんし、そういった関連性のある知識は必然的に持っていないとプロフェッショナルな領域まで到達することもできません。

 

まぁ、そんなギークな世界につかっている人にとってはフルスタックエンジニアなんて言葉を聞いても鼻で笑えばよいわけですが、私のような凡人エンジニアにとっては1つのコアとなるスキルを磨きつつ、関連があるところも通信簿で言うところの普通レベルの知識を持つところで結構四苦八苦しているわけです。

 

 

フルスタックに夢見るエンジニア

 

 

 

何よりこの言葉について疑問に思うのは、あたかも幅広い知識を求め、そしてそれに応じた様々なレイヤーでの仕事ができるように謳っているところなわけですけど、ブッフェで自分が好きなものを取って食べるかのように自分の興味のある仕事だけができるとは限りません(多くの場合できないでしょう)。

 

 

会社としては幅広い知識を持っている人がきてくれたほうが当然助かります。
プログラムができ、ネットワーク機器の設定もでき、サーバーのセットアップやミドルウェアにも理解があれば色んなプロジェクトや状況に応じて(というのは多くの場合は炎上している場合かもしれませんが)その人のポジションを変えることができます。

 

 

これはある意味、会社にとって都合のいい人となるリスクもあったりします。

 

わからないことがあったらあの人に任せればいいとか、この分野を担当できる人がいないからやってもらおうとか。

それによって希望する経験と知識を得ることができたのならよいかもしれませんが、そうではなく自分が持っている知識を淡々とこなせば済むようなタスクの繰り返しになることもあります。

それは最初は楽しいことのように感じるかもしれませんが、新たに得るものがなくそのうちその技術も枯れていってしまっては将来的にエンジニアとして活きる道が無くなる可能性もあります。

 

そもそも全てのレイヤーの仕事がその人に任せることができるほどシステム構築の作業は単純ではないので、酷く疲弊しなくてはならない仕事となるか、先ほど書いたように都合のよいポジションに当てはめられるということも考えておかなくてはなりません。

 

そういうことを考え出すとフルスタックというスキルを求められる仕事というのは、物理的に不可能な仕事を求められたり、酷く単調な仕事を求められたり、という感じで個人的にあまり良いイメージを持つことはできないなとか思ったりもするわけです。

エンジニアと一言でいっても色んなレイヤーの仕事があり、それぞれに面白そうと興味を引かれることもあるでしょう。

ただ、その多くを体得することはかなりの時間を使わなくてはならないことで、やっぱり自分の中で得意とするもの、面白いと思うものをきちんと見つけて、そこから異なるレイヤーにも知識や興味を広げていくということをしないと、フルスタックという言葉に惑わされて横断的なスキルはあるものの中途半端となってしまっては都合のよい扱われ方しかされなくなってしまうのではないかと思うわけです。

 

まぁ、そういう人って知識の幅があることを理由に最終的には上流工程の担当や管理職に当てはめられたりするんですが、本人が納得するなら全然かまわないわけですがエンジニアとしての道はなくなるわけで、どういうキャリアパスを描くかしっかり考えておく必要があるなって思います。

 

 

 

 

Active Directoryでアカウントロックをした場合、AD上の「lockouttime」属性の値でロックの有無を検知できると思っていたんですけど、できないみたいですね。


ユーザがロックアウトしてるかどうかの判断@マイナーでもいいよね??


アカウントロックを解除したい場合、この属性値に「0」をセットすることでロックは解除されるようですが、AD上のグループポリシーでアカウントロックを自動解除する(例えば、ロック後に一定時間経過したらロックを解除する)場合、「lockouttime」の属性は「前回ロックした時刻(最終ロック時間)」が何時までも残ってしまうようです。

その他に、badpwdcount属性を使ってパスワードを間違えた回数を拾えば、グループポリシーに設定している閾値に達しているものはアカウントロックしているはず、という基準のものロジックを組み立ててみたりもしたのですが、このbadpwdcount属性はAD間で同期されるものではなくそのADローカルで管理されている属性のようです。


ってことでかなり途方にくれていたのですが、「msds-user-account-control-computed」という属性を調べればアカウントのロックアウトステータスなどを確認することができるようです。



ADのアカウントロック状態をLDAPを通して検知する


PHPで書いてしまいますが、LDAP使っているのでほかのプログラムでも置き換え可能です。


<?php
// ADサーバーのホスト
$host = "ldaps://192.168.0.100";

// ロックアウトをチェックする対象ユーザー名
$user = "username@testdomain.test";

// ADサーバーの管理者ユーザー
$adminId = "admin@testdomain.test";
$adminPass = "FooBar";

// LDAPに接続
$conn = ldap_connect($host, 636);
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);

// 管理者ユーザーでBIND
$auth = ldap_bind($conn, $adminId, $adminPass);

// msds-user-account-control-computed属性を検索
$ldapSearch = ldap_search($conn, "OU=Employee,OU=Users,DC=testdomain,DC=test", "userprincipalname=" . $user, array("msds-user-account-control-computed"));
$info = ldap_get_entries($conn, $ldapSearch);
$msds = $info[0]['msds-user-account-control-computed'][0];

// ロックアウトしているか検証
if (($info[0]['msds-user-account-control-computed'][0] & 16) === 16) {
    echo $user . "はロックアウト中" . PHP_EOL;
} else {
    echo $user . "はロックアウトしていません" . PHP_EOL;
}

ADへの認証方法やLDAPSを使う場合の設定などは前回書いた「PHPからActive Directoryに認証・パスワード変更する方法 」を参考にしてください。


属性の検索は一般的な方法ですが、ロックアウトの検証に関してはちょっと特殊で「msds-user-account-control-computed」の値と16の論理積が16の場合はアカウントロックしているという判断になります。


ms-DS-User-Account-Control-Computed attribute@Microsoft Developer Network


こちらに値についての説明が書かれていますが、「msds-user-account-control-computed」属性の値はその他のアカウントのステータスを表す数字との積み上げになっています。

アカウントロック(UF_LOCKOUT)を表す数値は16(16進でいう0x0010)となっていて、パスワードの有効期限切れ(UF_PASSWORD_EXPIRED)は8388608(16進でいう0x800000)となっています。

パスワードの有効期限切れかつアカウントロックしている場合の数字はこの足し算の「8388624」となり、このような場合でも論理積は16であるのでアカウントロックしているということがわかります。


予断ですが、ldap_searchは第3引数の検索フィルタに「array("*")」を指定すると全属性を引っ張ってこれるんですけど、その中に「msds-user-account-control-computed」属性はありません(全属性を引っ張ってこれるという思い違いをしていたみたい)。

なので、この属性はLDAPを通して取得できないんだと思い込んではまってました。





先日、同じチームの部下が一人辞めまして、まぁその子は少し前からそんなニュアンスをほのめかしていましたので話を聞いたときは致し方ないかとは思ったりしたんですが、仕事に対するモチベーションというのは環境にも増して自分自身の内から来るものが大きかったりするのでどうやってそれを外からの刺激として向上させるのかというのは難しい問題であると痛感したりしました。



どうやってモチベーションを与えるのか


チームメンバーが流動的であることは決して悪いことではありませんし、それによって新しい知識やその人が他のメンバーの模範となることによってモチベーションが生まれることもあります。

ただ、一般的に人が新しく入ってくるのは、それまでの過程も含めて手続きや教育のコスト、その人が立ち上がるまでの一時的な戦力ダウンを補うための編成などなどを考慮すると大きな労力がかかることです。


組織長から見れば人を一人入れたんだから要員は足りているはずだし戦力もアップしているだろうと考えられたりもするのですが、現場をまとめる立場からすればそうも簡単な話ではなく、やっぱり(優秀であって)その環境に慣れていて話を通しやすいメンバーがいてくれた方がチーム運営としては随分と楽なことではあるわけです。

その維持のためにメンバーにどうやってモチベーションを持続させるのか、というのは自分自身のモチベーションを維持する話より難しいことであると思ったりしています。


親の世代ならいざ知らず、自分たちの世代では終身雇用なんてものは全然実感がわかなかったりするもので、現に周りでは人の出入りが多かったりしますからそんなに難しく考える必要が無いことなのかもしれません。

ただ、自分が小さくとも組織というものを管理する立場になったりすると、優秀な人材は長くいて欲しいと思いますし、今要るリソースでその後のプロジェクトの計画を立てるのでその要員が抜けたりすると頭を抱えることになったりします。


その人のモチベーションをあげる方法は、その対象者によって給与だったり、やりがいであったり、職場の雰囲気や仲間であったりと異なってくるのですが、管理するマネージャーの立場からみればその要素を与えること自体が最初から難しいということもあります。

例えば如何に組織を管理する立場でも給与を大幅に上げることは難しいでしょうし、変な会社の文化というものが根付いているところではそれを大きく変えることに抵抗が生まれたり、ある人のために仲間を選定するということも本末転倒なことになったりします。(ここでの話はたいした権限も持たない中間管理職ってことで)


結局のところ、一番それっぽくそして融通が利きそうなところで「やりがい」という言葉を口に出したりもするのですが、それでもその組織のミッションが決まっていることから、システム運用をするチームでバリバリ開発業務を与えるというのは難しかったりもするので、かなり制限をさせられる結果になります。

私の場合も、一番手っ取り早いところで「やりがい」というものを何とかその子に与えてやれないかと考えてたりもしましたが、最終的には本人の希望に沿うことができなかったようです。


「やりがい」というものも当然本人が意図しているところと、会社として与えるものとの差は大きくあったりもして、「そんなことに興味は無い。面白いとは思わない」といわれたらそれまでなんですが、それでもこの「やりがい」という言葉を会社として多用するのは、半ばやりがいという言葉と組織としてのミッションと一緒くたにしてしまおうという打算も見え隠れします。

ですので、最初からその当人に対して(そもそもそれを求めているかも含め)やりがいを与えることでもベーションを維持させることすら難しいケースも多々あるかと思います。



どんな仕事の楽しさを与えられるか


モチベーションというのは自分で見出すものだという意見もあったりします。

現に、そんな啓発本なんかいっぱい目にしたりもしますし、(外部からの助言によって増減するところではありますが)、最終的にやる気というのは自分の内から出てくるものなので、気持ちの持ちようってところもあります。


モチベーションがあがらないといって辞めたはいいものの、結局次の職場でも同じような仕事をしていてまた転職していくという人を見てきてますが、職場が変われば雰囲気も違うしその環境だったらもっと楽しく仕事ができるのかもしれないと考えているのかもしれませんが隣の芝生は青く見えるだけなところも否めません。

給与だけを追い求めて転職を繰り返し、やっぱり定時に上がれる仕事をしてた方がいいなんて愚痴を聞いたりもしますけど、そうやって経験をしないとなかなか本人的にわからないことなのだと感じます。


仕事のモチベーションが給与だけといわれたんなら、(それをどうにかできる権限が自分に無いとして)転職を勧めることも本人のためかもしれませんが、そうではないのであればやはりモチベーションを上げる環境を提供することでそれを向上させてあげるしかありません。

やりがいという言葉について先ほど書きましたが、なんとなく今のこの言葉は本人の内なる気持ちを表す言葉なのに会社が与える使命のように使われている気がしてならないんですが、もっと簡単に言ってしまえば仕事が楽しいって思ってくれることなんではないかと思うわけです。


この仕事が楽しいって言葉は言うのは簡単でもそんな単純ではないのですが、仕事に集中できる環境があり、自身が思い描くキャリアパスを通ることができ、切磋琢磨できる仲間がいて、アイデアが沸いてくる刺激があり、政治的な立場に巻き込まれる面倒がなく、快適なオフィスがあって・・・、と言い出したらきりが無いわけですけど、実際問題それらを全て与えることもよっぽどの大企業でもない限りできませんし、それがよい方向に必ず転ぶわけでもなく賛否両論もあったりします。


結局のところ自分のような小さなチームの中でのエンジニアとしての楽しさを出すためには、同じ開発手法をとらないとか、違った言語やフレームワークを採用するとか、業務のローテーションをさせてインフラからアプリケーションレイヤまで幅広い仕事をさせてみるとか、客先に出して生の声を聞いてみるとか、小さなことでも色々と目新しいことを当人にさせてみるうちにどの分野で楽しさを実感するのかということを試行錯誤ぐらいしかないかなと思ったりします。

一口にエンジニアといっても、技術のコアの細部まで突き詰めていくような博士肌な人もいれば、上流工程でお客さんと話しをするのが好きとか色々タイプも異なりますので。


結局は自分で楽しいと思えることに気が付いてくれ、その仕事をしたいと思ってくれないのとなかなかそのチームに長く居座ってくれないんでしょうけど、その環境やきっかけを与えるために何をしてあげられるのかって考えるのは大事なことではないかと思うわけです。