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

A Day In The Boy's Life

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

って言うような話題が社内で出たことは無いでしょうか?

要は優秀な人がいて「あの人がもう一人いたら・・・」とか「あの人がいなくなったらやばいから、同等の能力を持った人を育てることが急務だよね」みたいな話が出てくるというものです。

気持ちはわからなくも無いんですが、そういった話を聞いてなんか根本的に考え方がおかしいと思ったりもします。



そもそもそんな優秀な人がいなくても済む現場の方がいい


社内で持ち上げられるその優秀な人というのが求められる時というのは、たいてい状況が悪いときではないでしょうか

トラブルが起きていてプロジェクトが火を噴いているとか。

その人の問題解決能力が高いから買われていて、そういった人がたくさんいた方がリスクヘッジできていいよね、みたいな感じで考えられていたりするんですが、そもそもトラブルが起きない現場の方がみんな幸せです。


もちろんトラブルがゼロの現場を作り出すなんて無理でしょうから、そういった人の活躍が求められるシーンというのは多分にあります。

本来、その会社の命運をかけたプロジェクトというものに最初から投入すれば成功を収めるかもしれないのに、使いどころを誤ってかその人が現場に投入されるのはもうどうしようもないときであったりもするわけです。


「火消し役」なんて権限も役職手当もつかないポジションにいいように投入されてしまう人っていたりするものですが、こう考えるとその人は優秀な人というよりは切り札的な存在として扱われているだけのかもしれません。

切り札をたくさん持つことはいいことだと思いますが、切り札の使い方がそもそも下手なんじゃないのとか、こんなことしてたら切り札は何枚合っても足らないぞっていう現場の方がまずいわけです。


いやいやそんなトラブルへの備えとかネガティブな考えじゃなくて、単にあの人が優秀なプログラマだから他にもいた方が機能拡張も進んでユーザー拡大できるでしょ、というのも意見としてあったりすると思いますが、実際そういった優秀な人が投入されるのはデスマーチ化したプロジェクトだったりするわけです。

あの人は社内の知識を豊富に持っているとか、あの人に聞かないとわからないことが結構あるんだよ、だからああいう知識や経験豊富な人がもっと必要なんだよ、って問題に対してもそれってそもそもノウハウのため方を工夫したり、単にナレッジが体系的に整理できていないだけじゃないのかって別の課題が見えてなかったりします。


もし現場が平和であれば、そもそも「あの人がもう一人いたら・・・」なんて課題も出ません。

今ある牌で戦うことができているわけですから。



こんな人がいないよねというのが考えられない現場


書いたように切り札的な存在の人のストックを作りたいという考えを持っている人は、その考え方をしている方に結構問題があるように思えます。

備えという観点で優秀な人を育てたいという思いだけで、平時の使い方は持て余していたりするわけです。

切り札を何枚を持っておいて安心感を得たいというだけなのかもしれません。


火が出たときの対策を考えるより火を出ないように注意しろ、というのが根本としてあるわけですが、そもそもこの人がもう一人いたら・・・というよりは、この領域の人がいないから補充した方がよいよねという観点が必要になります。

まず、切り札を使わなくても勝負できる状況にした上で、新しい勝負に投入できる別の切り札をちゃんと作っておくことです。


ある人が優秀でその領域で遺憾なく力を発揮できる状況であればその部分は任せてしまえばいいわけで、それ以外のレイヤーで足りていない部分っていないんだっけ?そこって補っておかないと事業展開に支障が出るよねって観点です。

同じ人がいたところでせいぜい現状維持に回るだけですが、足りない能力を持った人を補うことができたら現場は成長することができます。


ここでよく起きる失敗談の一つが、その優秀な人を新たな領域にチャレンジさせてみて本来の能力を潰してしまうというケースです。

その人が優秀でも、活躍できる場というのは決まっています。

何でもかんでも優秀な人なんてそうそういません。

業務拡大に伴って新たな領域に踏み込もうとしたときに、新たに優秀な専門家を入れるのではなく、その優秀な人を当てはめてそこでも能力を発揮させようとマネジメントしたりする人もいるのですが、必ずしも何でもかんでもその優秀な能力が発揮できるわけでもありませんし、誰しも得て不得手はあるわけなので手を広げすぎて平凡な能力に成り下がってしまうのを見ると残念でならなかったりします。


そもそも新たな領域というのをちゃんと見定めずに、今いる人の中で無理にやらせてみようとして失敗するケースで、優秀な専門家を優秀な専門家のままでいさせないところを見ると単に自滅行為をしているだけのように見受けられます。

「君たちはスペシャリストになりなさい」といわれる割には、色んな部門を転々とさせられて「いやいやゼネラリストも必要だよ」という割には得たものは掻い摘んだだけの中途半端な知識を持っただけの人というのもよくあることで、あの優秀な人のクローンを作るんだって言う計画もそんな現場で育つはずも無いというのはよく思ったりもします。


ちゃんと現場の役割や強み・弱みというのを分析した上で、どういった能力を持った人を育てたり補填したりする必要があるのか考える必要があるわけです。

それは、単に今いる優秀なクローン人間だけというわけではないでしょうから。





昨年末にPHPのセッションアダプションの話題が出ていて、そういった記事を読んでいるうちに自分の環境を見直してみると全然理解していない部分があったんだなということで、その辺をまとめてみたいと思います。


PHPのセッションアダプション脆弱性は修正して当然の脆弱性 @ yohgaki's blog



PHPの未初期化のセッションIDは何でも受け入れられる


セッションアダプションの問題の根幹はこの部分にあって、セッションIDはプログラム側で作られるものだと思い込んでたものが、Cookieを通して任意のセッションIDを送り込まれてそのまま利用されてしまうという問題です。

確認(攻撃)方法はいたって簡単で、PHPのセッション管理をCookieベースで行っている場合に、そのCookie内のセッション変数(php.iniのsession.name)に任意の文字列を入れて送り込めば、そのセッションIDで利用が開始されてしまいます。


例えば、よくあるログイン管理のプログラムで、


<?php

if (checkLogin($_POST['id'], $_POST['password'])) {
    session_start();
    $sess_id = session_id();
}


というような処理をしていた場合、通常$sess_idにはsession_id() が作り出す26桁の英数字の文字列が返されることを期待していますが、下記のようにCookieのセッション用のパラメータに予め任意の文字を指定してリクエストを送信するとそのセッションID(mySessionId)がsession_idにより返されてしまいます。


A Day In The Boy&#39;s Life-任意のセッションIDをCookieに埋め込む


もちろん、Cookieのセッション変数名がなんであるかわかっていないといけませんし、ログインは成功しないといけないわけですけど、よく利用しているサイトであればそれは簡単にわかるわけなので、任意のセッションIDを流し込んで最悪セッションハイジャックができたりしてしまいます。

ログインが成功して発行したセッションIDは絶対だから安心なんて思っていると簡単に書き換えが可能なわけです。



セッションアダプションを無効化する


このセッションIDを固定化する攻撃の問題点は、先のエントリと同じ大垣さんが書かれた下記の記事がわかりやすいです。


第25回 PHPのアキレス腱 ── セッション管理 @ gihyo.jp


簡単に言ってしまえば、PHPのセッションで使うためのものと同名のCookieが複数発行されてしまえば、任意のセッションIDで利用されてしまう可能性があるというものです。


A Day In The Boy&#39;s Life-任意のセッションIDを送り込んだ場合


上記の場合、「/」で発行されたのが本来のセッションIDで、それを「/2013」のパスで発行したCookieにより上書きしています。

利用されるセッションIDは、出力結果のように任意で送り込んだセッションIDの方です。


この対処として、1つは発行されたCookieを事前に削除するようにしておくこと、もう1つはsession_regenerate_id() を利用して、セッションIDを毎回再発行することです。


<?php

if (checkLogin($_POST['id'], $_POST['password'])) {
    session_start();
    setcookie("PHPSESSID", "", time() -3600, "/2013", "www.example.com");
    setcookie("PHPSESSID", "", time() -3600, "/", "www.example.com");
    session_regenerate_id(TRUE);
    $sess_id = session_id();
}


ただし、Cookieは発行している全てのCookieを削除しないと意味がありませんが(しかし、それはアプリの構成によっては非常に手間がかかるものですので、発行するCookieの箇所を一元化しておくことと、ここのアプリの中でXSSなどのセキュリティホールを生まないようにしておく必要もあったりするわけですが)。


session_regenerate_id()を利用することで、毎回異なるセッションIDが発行されます。

たとえ、前回のセッションできちんとログアウトができていなかったとしても、セッションIDは新しいものに置き換わります(引数にTRUEを指定することで、過去のセッションは削除されます)。

サイト内で多重ログインするような仕様があったらその時点でセッションIDが変わってしまうので、アプリ内部での挙動も気をつける必要が出てくるかもしれません。


セッションは、ログインを管理する重要な要素なのでかなり重要なのですが、そのセッションの管理って結構PHPにまかせっきりに考えていたりするのに、PHP側であまりうまいことやってくれていないので、このようなアプリ側での配慮も必要になってきています。





業務改善という名の下に様々な改善施策が持ち上げられては実行に移されます。

しかし、根本的な業務改善というものはなかなか成功に結びつきません。

多くは場当たり的な改善施策が取り上げられ、その実行過程では色々な問題が出てきますし、実行完了後もその効果は決して大きくないというのが現実ではないでしょうか。


業務改善というのは、対象を見直して根本的に変えていくということです。

しかし、それに大きな変化が伴うことは主管である運用業務担当者は嫌っているように思うことが多々あります。



ルーチンを変える恐怖


運用担当者はすべての作業をルーチン化したいと考えています

それが仕事の効率化だと思っているわけです。

そのために多くのマニュアルが作られ、多くの共有の時間を割いて言い方は悪いですがマニュアル人間を作り出したりします。

業務改善に伴う変化はルーチンの妨げになると思い、それを恐れて抜本的な対策に乗り出すことに億劫になりがちです。


業務フローが変わり現場が混乱することを懸念していますし、変わったことで多くの学習時間を割かれることを嫌っていますし、これまでのノウハウが水の泡になることを恐れています。

例え普段利用しているシステムのボタンの位置や名称を変えるだけでも作業効率の低下やマニュアルの変更が伴うことを嫌っています。

彼らにとって、なるべくルーチン化したい業務は作業時間を1秒でも短縮したいと思っていますし、なるべく簡単に担当者の頭に定着することを望んでいます。


業務改善により抜本的に作業効率化が図られるとしても、担当者にとってはその変化に恐怖を感じている人も少なくありません。



運用担当者が改善施策に参画することで発生するしわ寄せ


運用担当者は日々多くの業務を抱えています。

その業務を一番理解している担当者を業務改善プロジェクトに参画させたいというのは当たり前のことではありますが、その担当者は引き続き運用業務を抱えているため、プロジェクトに多くの時間を割くことができなかったりします


もちろん、そうした改善施策に参画する場合は、その担当者は現行業務から引き離して注力できる環境を作るべきでしょう。

しかし、運用担当者のリソースにも限りがありますし、そうした余裕が無いということはよくあることです。

こうして、現行業務と並行して施策の業務も担当することになり、なかなかプロジェクトの中での業務を思うように進められないという事態となります。


運用担当者から見ればその業務を動かして当たり前という状況に置かれているため、例え改善施策によりあるべき姿の業務となり自身の作業に効率化がもたらされるとしても、その仕事に参画することを嫌う人もいます。

また、周りもそのリソースが抜けることでのしわ寄せが来ることを嫌ったりもします。


多くのリソースが裂かれている業務であればあるほど、その改善の効果というのは大きくはなりますが、その改善に裂くためのリソースが取れないという矛盾が業務担当者を悩ませたりしているわけです。



自分の担当業務を無くす事を考えていない


業務担当者は自分の業務を無くすことを考えていません

その仕事ありきで考えています。

それが仕事だと思っているので当たり前ですが、本当に改善するなら根本的にその担当業務の意義や存在を検討してしかるべきでしょう。


そもそも、その仕事は必要なのかという検討をせず、この仕事は必要だという固定観念の下で小手先の改善で効率化を図ろうとします

それでも幾分は前よりましになるかもしれません。

しかし、その仕事をやらなくていいという結果になった場合、より多くの時間を他に使うことができますし、新たな業務改善にも結びつけることができるわけです。


その業務を無くすという視点では第三者がその施策を取りまとめる必要があるでしょう。

自分自身で自分の仕事を無くそうというのは、実際にその仕事はやりたくないと思っていてもなかなか言い出せないものです。

また、その仕事に愛着を持っていて手放すことを嫌う人もいるかもしれません。

その仕事により今の地位にあるのであればなお更です。


業務改善という名前だと、その業務ありきでどう変えようかという視点になりがちですが、そもそもその業務なんてやらなくていいという結果になればみんなハッピーになれるでしょう。

その業務が何らかの形で担保できるようなればよい訳ですし、そもそも必要の無いことに時間をかけていたということがわかれば、本来やらなければならない業務に注力できるわけですから。



まとめ


社内の業務改善施策なんかは毎年のように持ち上がって実行されては行きますが、一向に収束する気配はありません。

以前に業務改善施策が実行されたはずが数年後にまた業務改善だ!なんて叫ばれて、前回のプロジェクトはいったいなんだったんだ、何を検討したんだという気持ちになったりします。


全てが業務担当者に責任があるわけでもありませんし、彼らは彼らで今の業務に手一杯になり、改善までなかなか手を回せないという状況があります。

そして、その状況に検討事項がのめり込んでしまったが故に本当に改善しないといけないポイントがずれてしまったということもよくあることです。


こういったことが無いように、業務担当者の懸念事項を1つ1つ解消していくことはとても大切なことではないかと思います。

変化することが恐怖ではなく、明るい未来につながるということをちゃんと理解してもらうことは改善の前提として重要なことではないかと思うわけです。