自分としては、エンジニアとしての現場を続けたいという思いもあるものの、「こういうものを作りたい」ということに対してどうそれをどう描いていくのかという事の楽しさというのをここ最近、実感したりしています。

考えるのが好きになったというか、エンジニアとしてももちろん考えることは多いのですが、そのレイヤーが変わったというのか、なんせ自分でどうやろうかというところから今あるリソースを使ってどう動かしていこうかとか、やはり自分ができることより大きなスケールを描けるので、自分ひとりでやるには億劫になってたことも大風呂敷を広げて考えることができるというか、そんなところで面白みを感じたりするわけです。

昔はエンジニアらしく何を作るのか、どうやって実装するのかということに集中していました。

何よりもプログラミングすることが好きでしたし、なんかエンジニアのよく描かれるキャリアパスのように、経験を積めば上流工程みたいなのに抵抗を持ってたりもしました。

考える仕事が良しとされるような風潮もありましたし、何時までもプログラミングなんてしててはいけないというようなところへの反発心もあったんでしょう。

あと、コンサルタントの仕事があまり好きになれなかったんですね。個人的に。

システム部門としては、たたき上げの人が多かったこともあり、頭の中で絵空事のように描いた資料を見せてこうやったら論理的にうまくいくはずだという話しを鵜呑みにできませんでした。

まぁ、今はどうやったら納得させられるかとか数字とか見せ方とか資料にこだわったりもするので、わからなくもないんですけどね。

そんなこんなで作ったシステムへの愛着というのもありましたし、やっぱり開発の現場に固執をしていました。

こういった状況だとなかなか描く仕事いうのもやるよしも無く、今思えばもったいなくもあり食わず嫌いなところもあったのかもしれません。

当然、描く仕事いうのはそれなりのポジションと時間を持たないとうまくいかないと思いますので、片手間でやっていてもあまり好きになれてなかったと思います。

描く仕事って、それを最終的に結び付けようとしたら一人では難しいですのでチームが必要になりますし、それを実現するための予算というのも要るでしょうし、長期的なスパンで計画するのでそれなりの時間を確保する必要があります。

ある程度のポジションになって体制や予算がついて、計画を発表できる立場であればそれを動かしていく面白さというのも感じられるのでしょうけど、早くに現場から離れて考える仕事をしろっていっても定型化された上流工程だけを任せるようなことであれば、エンジニアへの執着ってもっと長く持っていたような気がします。

考える仕事が増えてきたのは、悲しいかな自分が抵抗を持っていた上流工程へ突き上げをくらって追いやられた故にというところもあるのですが、やはり現場に若い子達が入ってくると、なかなかそこにしがみついていてもというところもあったりしました。

開発という業務でも、ある程度の経験を積めばルーチン的なものになってきたりもしますし、そういったことを惰性で繰り返すよりも、それさえも目新しく感じる若い人たちに譲った方がお互いのためだろうという考えもありました。

その空いた時間で必然的に考える時間が多くなったところからスタートしているわけですが、やってみたら結構新鮮だったりもします。

エンジニアとして何を作るかに集中していたところから、描くという仕事はその何かを定めないといけないわけですから、何が足りないのかというところを考える必要性が出てくるわけです。

何が足りないのかというのは何で足りないのかということをわかる必要性がでてきますし、そうすれば制約というのもみえてきます。

そうなれば、できることとできないことの領域がはっきり見えてきたりするわけですね。

こうなってきたときに、できることとできないことというのはエンジニア視点では結構見分けやすくなるわけです。

技術的な敷居であったり、膨大な工数であったり、予算であったり。

何ができるのかというのが見えるのは結構力になったりします。

非エンジニアの人だったら、これがわからないというのもよく聞きます。

こういうのを作りたいって思ってても、どうやって実現したらいいのかわからないって言う。

そういったものをどうやってカバーできるのかというのはエンジニアの知恵として有効に働くことが多かったりしますし、エンジニアだから描けることなんじゃないかなと思うわけです。

何が作れるかというのが見えるのは、何に当てはめられるのかというのが見えやすいですし、何に当てはめればいいのかという気付きは難しいんですけど、はまったときは突き進みやすいんじゃないかなと。

何ができるのかを知っていたらそこにかける労力も不要なわけですし、考えることに注力できる強みはあるんだろうなと思います。

とはいっても、このブログで書いているようにエンジニアとしての興味は引き続きありますし、作る楽しさというのもまだまだ自分の中では色あせてはいません。

結局はお前も型にはまったんだな、見たいな事を言われても言い返せない気もするんですが、エンジニアとして食ってくぞ、見たいな所からは随分変わってしまったのは確かです。

でも、描く対象はやはりITインフラを基盤としてどんなサービスを作っていくかというころにはあるので、その仕組みがわかるエンジニアからスタートできたことはよかったと思っています。

なんかの記事で、Twitterのコンセプトを書き記したメモがあったというのを読んだんですが、そうったサービスを作るうえでの描き方ってもっとラフで自由なんだなって思った記憶があります。

考えるという仕事が随分と堅苦しく思えていた時よりは今は抵抗が無くなっていっていますし、もっと好きに実現したいものを考える事をしていいんだな、と思うと結構ワクワクする今日この頃です。

[PR]エンジニアに特化！エンジニア専門の転職支援は「メイテックネクスト」

[PR]固定IPが【業界最安値クラス】＋【５分で発行】＋【２ヶ月無料体験】

[PR]安心・直販・カスタマイズ対応！ThinkPadのレノボ・ジャパン

あけましておめでとうございます。

昨年の12月はこのブログ始まって以来、初めての更新なしという結果を出してしまったわけですが、まだまだ終わったというわけではなく、今年もゆるい感じで続けていきたいと思っています。

こんなブログですが、本年もお付き合いいただけたら幸いです。

さて、新年一発目の記事ではありますが、本当のところは昨年の12月の最後にまとめとともに何か書こうかと思ってたネタではあるのですが、ブログ論何ぞで始めてみたいと思います。

このブログも早いもので7年目に突入していて徐々にですがPVも伸びてきています。

爆発的に読まれたという記事は無く、どちらかというと検索エンジンに引っかかってアクセス数が流入するというパターンで伸びてきたわけですが、その理由の一つは何よりも長く続けていることだと思っています。

長くその場にいるというのは認知度をあげることに貢献しますし、その期間でコミュニケーションが醸成されて信頼関係も築けるでしょうし、ちりも積もればそれなりの月間PV数をたたき出せたりもします（ちなみにこのブログは大体月間で4万PVほどです）。

昔は必死に毎日エントリを書いていましたが、たいした内容や文章をかけるわけでもないので、身の程を知ってか徐々に数よりも1エントリの内容を濃くしていこうという方向性を自分の中で持ち始め、ネタとして書きたいなぁと思うことがあっても、大して内容を広げられないと感じたら私も読む人も時間の無駄にはなるので、速攻で諦めるようにしました。

そんな状態でも、7年も続けていれば月にたいした記事数を書かなくてもそれなりのアクセス数が出てきたりします。

ブログ自体をしている人や始める人はSNSの勃興によってそんなに増えてはいないような気はしますが、自分の意見を体系的にまとめるのはやっぱりブログが一番かな、と個人的に思ってたりします。

Twitterのような、より発言しやすい環境であったとしてもタイムラインの面子は時とともに変わっていっています。

Twitterでさえ続けることが難しいのであれば、長文を書くブログを3年、5年と続けるのはなお更難しい状況にあると思うわけです。

もちろん、FacebookやG+やTumblrなどその他のサービスに移行していったというのもあると思いますが、一つのサービスと場所にい続けるのはその難しさから一つのメリットも生み出すのではないかなと感じます。

ブログやサイトのPV数を上げる方法というのは、毎年毎年人気を集めていたりもしますし、私自身も気になってチラ見したりもするのですが、何かそこまでがんばろうという気が起きません。

いや、がんばりたいのは山々なのですが仕事をしていたらそこまでの時間も取れませんし（業務中にブログを更新したいって思いはありますよ。はい。）、結婚してからなお更ブログを書く時間を確保するのが難しくなってきています。

ネタはあちこちから集めてはEvernoteなどに詰め込んで、そこで概要を書いてみては書ききれない、自分で読んでも面白みがないと消してみたりしては、数少ないエントリを築き上げているわけですが、何かそんなに気負わずにブログを書いていても全然良いと思うわけです。

ブログというプラットホームは、自分の中では結構大きなウェイトを占めていますし、常に何かネタになるものは無いか探していたりもします。

でもそれをきつく縛ることで自分の生活に制約ができることは嫌ですし、技術系ブログと銘打ってはいても定期的に情報を出していくことを握っているわけでもないので、あまり変に自分を縛り付ける必要は無いのかなと思っています。

元々、そんなゆるい感じで続けていれば、読む人も過度な期待もしないでしょうから、自分も周りも制約せずに済むと思います。

所詮は凡庸な人が書いたブログであり特別なことは何も無い、ただ読み手の日常となんらかリンクしたり感じるものがあれば狭い範囲でも満たせる領域というものは生まれるのではないかと考えています。

このブログでは、それはエンジニアとしての日常や考えであったり、その中で用いている技術のネタだったりもするのだと思いますが。

よくブログ書きやサイト運営において、それだけで飯が食っていけるようになりたい、またはその方法を論じるエントリがあったりして、私自身もいつかそうなれればいいなぁなんて思ってた時期がありましたが、かなり著名でアクセス数の多いサイトであってもその内訳を見てみると結構厳しいんだなと感じます。

ましてや片手間でこのブログをやっている自分ではそれはなお更難しいと痛感しますし、アフィリエイトなどやっていても、年収の数パーセントを稼ぎ出す！どころかお小遣いの足しになればいいなぁレベルまで落ちていたりもします（それさえも難しいわけですが）。

あまり、ブログを収入源にと変に気負いすぎるとろくなエントリが増えそうにもありませんし、自分本来が書きたいものをかけないというような状況は作りたくないですし、こうやって真面目にエントリを書くよりも適当なことを自動で書いてくれるツールでバンバンとコンテンツを作り出すという方向性にした方が楽なわけですが、何よりも長く続けるというのは好きでないとできないわけで、そんな適当なことをするぐらいならこんなに長くは続けないよ、という考えも持っています。

1ヶ月ぶりのエントリで自分でもあまり考えがまとまっているわけではないのですが、結局のところ長く続けるメリットというのはあるんだよという点と、長く続けるにはあまり気負わずに自分のペースで自分の書きたいことを書いていくというのがコツなんじゃないかなということが言いたかっただけです。

今年はもう少し力を入れてみるかとか、新年早々に意思表明しようかと思ってたりもしたのですが、何よりも当の本人がもう少しうまい文章やためになるネタの作り方を学んだ方が手っ取り早いでしょうかね。

そんなわけで、今年も気負わず自分のペースを守りつつ、7年目をクリアしていきたいと思います。

読んでいただいた方、このブログへたどり着いた方の何らかの助け、インプットになれば幸いです。

[PR]安心・直販・カスタマイズ対応！ThinkPadのレノボ・ジャパン

[PR]スカパー！プレミアムおまかせプランで標準取付け工事無料！故障時無料交換

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

僕たちはガンダムのジムである/ヴィレッジブックス

￥1,000

Amazon.co.jp

冬休み中に読んだ2013年最初の本。

内容としては、ガンダムの世界観を通して、私たちごく普通の人がこの厳しい社会の中でどう生き抜けばいいのかを、ガンダムの中で平凡（いや、アニメの中ではそれ以下の存在のように扱われているかもしれませんけど）な存在のジムに例えてそのヒントを解説しています。

「君は生き延びることができるか？」
まさに本書では、この問いの答えを考える。
（略）
本書は「機動戦士ガンダム」という作品を通して、僕たち普通のサラリーマンのこれからの生き方について考える、キャリア論の本である。

私自身も「自分は特別な存在」と思ってた時期はありました。

漫画の主人公のように、そしてその主人公が持っている特殊な能力があるかのように。　

このアイデアは自分しか思いつかないだろうとか、就職の面接ではその特別感を前面に出して伝えようとか、まぁ社会人になればそんな特別感など何も無く、どれも平凡なアイデアであるということには否応無く気づかされるわけですが。

ある意味、そういった特別感というのは漫画によって植えつけられたりもしますし、「君たちはやればできる」とか「夢をあきらめなければきっとかなう」といった周りや先輩から見聞きする言葉に見事に乗せられるところもあるのですが、それを諦めさせる「僕たちはガンダムにはなれない。僕たちはジムなのだ。」という言葉は潔く、その中で考える次のステップと戦略というものを考えさせられます。

ジムは量産型であり戦力としてはごく普通の兵器にはなっていますが、その戦力があるからこそ一年戦争の中で戦略が担えたわけです。

悪く言えば捨石のような存在なのかもしれませんが、その数が要るからこそ戦力というのが生まれるわけです。

そして、多くいるのは私も含めてその普通の人だと。

普通をまず普通と認めるところから始めるのは自己分析として必要なことではないかと思うわけです。

普通を特別と思い込むのは一番危険で、突っ込んでいったらやられるのは当たり前のことですから。

凄い人にならなければ、凄いスキルを身につけなければ、そんな堅苦しく自分を追い込む観念からフッと開放させてくれるそんな本かもしれません。

まぁ、ガンダムの世界観を基にして書いているわけなので、それを知らない人は少し読みづらいかもしれませんが、ただそこまでものすごく色濃く描かれているわけでもないのであまりそっちの突っ込んだ話を期待しても残念かもしれませんが。

私はガンダム好きではあるのでさくっと読める本でした。

第1章 僕たちの「戦場」は今、どうなっているのか？
　劣化する会社という名の「戦場」
　やりたいことができない会社
　「躁鬱」が激しい会社員の日々
　「親父にもぶたれたことない」人が結構殴られている日本の職場
　リーダー不在の僕たちの職場
　ジム型人材を襲う「曖昧な不安」の正体

第2章 僕たちはこうしてジムになる
　会社はジムで動いている
　僕たちがジムになる理由1 - 学校教育と受験戦争
　僕たちがジムになる理由2 - 就活
　僕たちがジムになる理由3 - 会社員という日々
　「すごい人」にならなければいけない病
　世の中は普通の人で動いている

第3章 僕たちジムのための人生戦略
　自分の存在価値を再確認する
　期待されていること、できることで仕事をする
　職場にいるジム型人材に学べ
　戦記を書く
　自分の人生戦略を考える
　騙されないための知識・情報武装法
　「幸せ」を客観視する
　「帰れるところ」を作る

おわりに 僕たちはガンダムのジムである

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[PR]重いパソコンがサクサク動くウイルス対策ソフト

[PR]高速・定額・低料金のイー・モバイル！

[PR]安心・直販・カスタマイズ対応！ThinkPadのレノボ・ジャパン

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

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

セッションアダプションの問題の根幹はこの部分にあって、セッション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により返されてしまいます。

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

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

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

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

簡単に言ってしまえば、PHPのセッションで使うためのものと同名のCookieが複数発行されてしまえば、任意のセッション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側であまりうまいことやってくれていないので、このようなアプリ側での配慮も必要になってきています。

[PR]固定IPが【業界最安値クラス】＋【５分で発行】＋【２ヶ月無料体験】

[PR]重いパソコンがサクサク動くウイルス対策ソフト

[PR]SSLサーバ証明書なら[ドメインキーパー]◆VeriSign/GlobalSign/他取り扱い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[PR]【パソナの人材紹介】 パソナキャリアの転職情報、求人情報

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

[PR]安心・直販・カスタマイズ対応！ThinkPadのレノボ・ジャパン

昔に比べて時間は減ったものの、自宅でプログラミングすることはよくあります。

職場でプログラミングの仕事が減った分、相対的にみたら自宅でコードを書く時間の方が多くはなっているかもしれません。

何で家でまでプログラム書いたりするの？ってことは周りのエンジニアからも言われたりするのですが、単に趣味の世界から離れて職場に比べたら家でするほうが環境としてはそろっているような気もします。

何よりも大きいのは個人で楽しめるレベルの自由な環境が全然負担にならないレベルの金額で手に入れられるという点です。

少し前でも最低でも数千円、専用サーバーなら数万円出さないといけないというところから、仮想化などの技術の進展により千円を切るレンタルサーバーのサービスも出ています。

昔は、そういった金額さえも手を出すのが億劫になって、自宅で余剰となった使わなくなったPCに付録でついているLinuxインストールして遊んでたりもしましたが、今はそんなことする方が場所をとったり電気代とか壊れた場合の保守などを考えると高くつくかもしれません。

会社でサーバー導入するなら数十万するような高価なサーバーを導入しなくてはならず、個人で使いたいからという理由だけではなかなか承認が降りることもありません。

仮想化やりたいと言った場合も真面目な構成を考え出すと、ブレード入れたりストレージや高価なスイッチ用意したりすると個人だと目玉が飛び出るレベルの金額になってしまいます。

そもそも会社でサーバー買うとなると、プロジェクトや案件で必要になるものであり、個人の開発環境としてという理由では導入しにくかったりもします。

そして、そういった環境はOSが決まっていたり（そして、一度決めると変更できなかったり）言語やフレームワークが決まってたりと利用目的の制限の中で個人の好みややりたいこととマッチしないケースもあります。

個人でも安価で手に入れられるVPSプランなどを提供するサービスを利用すれば、手軽に仮想化環境を使えますし、気に入らなければ別のOSに乗り換えることもできますし、他のサービスにも手軽に移行できます。

要は、ちょっとプログラミングしたいな、って時に昔ほどお金をかけずに環境を手に入れられますし、始めるまでのスピードも早いわけです（もちろん手離れもいいわけです）。

もう1つは、仕事の環境に縛られない点があります。

失敗してもよい環境、壊しても壊れてもよい環境、関連がなく制約が無い環境、仕事で使う環境よりずっと自由なことができる環境があるわけです。

仕事の環境は失敗が許されず、壊れたら自分を苦しめ、関連システムがあるために作業できない制約があったりと窮屈であったりもします。

何よりも利用目的が決まっているがために、作るものにも制限が出ます。

今流行のこの言語で作りたい、このライブラリを試してみたい、既成のパッケージなど使いたくないといってもそのチームを取り仕切る権威ある人の鶴の一声や、リスクをとりたくないがためにレガシー化した技術に固執するということもしばしばあります。

責任を負うのは自分一人で済むのは随分と気が楽なことです。

そもそも自宅でのプログラミングは自分磨きなどとあまり堅苦しいことは考えていなくて、どちらかというと趣味の延長線上にあったりします。

これを勉強しようなんて気概で取り組んでもあまり長続きもしなかったりしますし、とりあえず動くものを作りたいとか、これが無いから自分で作ってしまおうというほうが吸収しやすかったりします。

会社の仕事は色々な制約があります。

納期に縛られるがための時間であったり、就業時間にも縛られますし、作る目的も求められます。

目的なんかは自分の意見も含まれるかもしれませんが、あくまでチームや組織の総意であることが求められたりもするので、その中に押し殺した自分の意見も含まれるでしょう。

そもそもオーナーあって作るものなので、その中には「この機能誰が使うんだよ」とか「その変更本当に必要なの？」とか「この期間で作れって氏ねって事ですか」とかｒｙ、あるわけですが自宅でのプログラミングはそういったことがありません。

何よりも時間に縛られない点で言えば、会社では打ち合わせや様々な依頼事項によって細切れになる時間で集中する時間をもてない点が大きいのではないでしょうか。

プログラミングが好きであれば、なお更自宅でコードを書ける環境を持つことのメリットは大きくなるはずです。

繰り返しにはなりますが、個人の環境を持つコストはどんどん低くなっていますし、様々なコードやライブラリが公開され、技術に選択の余地が多くなっている今であれば、それを自由に手軽に誰にも縛られなく使えるという点においてもメリットが大きくなっていると感じます。

[PR]【CPI】ディスク容量無制限で3990円のレンタルサーバー

[PR]固定IPが【業界最安値クラス】＋【５分で発行】＋【２ヶ月無料体験】

[PR]お名前.comのホームページ作成ツール★誰でも簡単にWebクリエイターに

ワーク・シフト ― 孤独と貧困から自由になる働き方の未来図〈2025〉/プレジデント社

￥2,100

Amazon.co.jp

未来の働き方を考える一冊。

私たちは、いつも仕事に関する悩みを持っています。

これはやりたい仕事かどうかと自問し、この仕事を何時まで続けられるのかということが気になり、取り巻くビジネス環境の変化に取り残されることへの不安に駆られます。

そんな、働き方への不安に対して真っ向から考え直してみることをさせてくれる本です。

この本の中で、そんなビジネス環境の変化を5つの要因（テクノロジーの変化、グローバル化の進展、人口構成の変化と長寿化、社会の変化、エネルギー・環境問題の深刻化）を元に未来への働き方の変革を予想しています。

面白いのは設定を2025年にして、その時の状況を登場人物や背景をはっきりさせて物語として描いているところです。

2025年のある日、その人は朝起きてどんなことをし、どういった状況で仕事をしているのか、そしてその時に起こっている問題とは何なのかを描いています。

まぁ、この手の未来予想というのは結構突拍子も無く見えてしまうわけで、誰も未来のことなどわからないのでその状況が正しいかどうかなんてわかりません。

ただ、未来を予測する上での5つの要因というのは、現在起きていることではありますので、その延長線上にどんな未来が待ち構えているのかというのを自分なりに予測するインプットにはなりえます。

この問題は決して自分だけを中心に考えられる問題ではありません。

自分がどう変わっていけばいいのかというのは自分たちの子供や新しく入社する新しい世代という人たちの考え方にも大きく影響を受けます。

働き方もお金を貰うためだけという割り切り方をして趣味の世界や仕事での充実感を得たいという人もいますし、もっとお金を稼いで豊かな生活を送りたいという考えを持っている人もいます。

どちらかというと、私たちは後者の考え方に偏重してきました。

働くというのは決して自分の好きなことだけをできるものではなく、ただお金は働かないといけない手に入らないから辛いことも受け入れられなくてはならないような雰囲気は自分の親の世代の働き方を見ていて自然に頭に植え付けられれますが、この考え方も世代とともに変化するだろうと予想しています。

私自身はエンジニアとして以前に、「クラウド時代のエンジニアの活きる道 」という記事の中で、エンジニアの働き方の変化を少し書いて見ましたが、ITという今やきっても切れないインフラを支えるエンジニアでさえ、未来的には二極化して中途半端な技術を持つエンジニアは淘汰されそうです。（そして、技術はそれほどでも無くてもアイデア次第で活躍できる）

決して安心できる職業でもないわけですね。

この本の中では、そういった状況を打破するためには、色々なことを幅広く知っているゼネラリストではなく専門技術を深くまで追い求めたスペシャリストになる必要があると説いていますので、エンジニアとして食べていくには二極化する一旦の方を目指す必要があるということが伺えます。

もう一度言いますが未来など誰も予想はできません。

ただ、今の自分たちの行動の先に未来はつながっています。

そのことについて、この本では「漫然と迎える未来」と「主体的に築く未来」という視点で大きく変わってくるだろうと言っています。

自分たちがなるようになるだろうと何も行動しなければ未来での問題は大きくなります。

未来にあるべき姿というのを描き、それを実現するためにはどうすればいいのかというのを考えて行動する必要が出てくるわけです。

働き方さえも、そんな変化に飲まれて変わっていくわけですから、どうやって働いていけばいいのかというのを未来に向けて考えないといけないのかもしれません。

第1部 なにが働き方の未来を変えるのか
　第1章 未来を形づくる五つの要因

第2部 「漫然と迎える未来」の暗い現実
　第2章 いつも時間に追われ続ける未来 - 三分刻みの未来がやってくる
　第3章 孤独にさいなまれる未来 - 人との関係が断ち切られる
　第4章 反映から締め出される未来 - 新しい貧困層が生まれる

第3部 「主体的に築く未来」の明るい未来
　第5章 コ・クリエーションの未来 - みんなの力で大きな仕事をやり遂 げる
　第6章 積極的に社会と関わる未来 - 共感とバランスのある人生を送る
　第7章 ミニ企業家が活躍する未来 - 創造的な人生を切り開く

第4部 働き方を＜シフト＞する
　第8章 第一のシフト - ゼネラリストから「連続スペシャリスト」へ
　第9章 第二のシフト - 孤独な競争から「協力して起すイノベーション」へ
　第10層 第さんのシフト - 大量消費から「情熱を傾けられる経験」へ

情シスは本当に「もういらない」のか？ / ＠IT

確かにクラウドサービスの勃興により、リソースの調達手段というのはかなり迅速に便利になりました。

ただ、それだからといって情報システム部門が必要なくなるかというとそうでもないような気もします。

むしろ、だからこそ情シスって必要になるんじゃないかって気もしています。

クラウドサービスによって一番メリットを享受できるのは、システムから遠い位置にいる管理部門の人たちでしょう。

今までは、自分たちでシステム化施策の構想は練れてもそれを実現するためには、外部に発注するか社内の情報システム部門に頼るしかありませんでした。

それが、幅広いクラウドサービスにより自分たちの手で取捨選択できるだけでなく運用さえもまかなえてしまいます。

ただ、手軽に導入できるからといって全てが情報システム部門無しに導入や運用ができるわけではありません。

システム導入にはセキュリティであたり、アカウントの管理など運用面であったり、既存の社内システムへどうつなげさせるかなどデータ連携を考慮しないとけいませんが、そのようなことは管理部門の人たちは普段から考えているわけではありません。

その人たちに大事なのは業務プロセスをどう組み立て実装するかって方になるので、システム運用の方は二の次となります。

こういった話は自分もよく聞く話ではあるのですが、管理部門の人たちが勝手にASP導入に踏み切って、かなり話が進んだ段階で、「システム運用としてプロの意見を聞きたい」ということで情報システム部門へアドバイザーとして参画して欲しいという依頼がきたりすることがあるのですが、こうなったときには私たちとしては「勝手にそっちがやりたいといったんだから俺たちはシラネ」みたいな雰囲気で険悪になったりもします。

結局は、自分たちでやるだけでは不安という思いも管理部門の担当者は持っているのでしょう。

この辺を本当にサポートできるのは、社内システムを熟知しているシステム部門でしかないと思うわけで。

何でもかんでも手軽だと謳うクラウドサービス側に罠があるのは、実際にシステム運営に携わる側としても経験して痛い目を見ている人も多いとおもいます。

「○ステップで導入可能」とか「既存システムへの影響や改修無しに導入できます」なんてうたい文句を鵜呑みにしていると大抵は導入でなかされることになります。

似た話で、コストを抑えられるからよいということでオフショア開発が流行った時期がありましたが、今ではチャイナリスクとか言われる始末でうまく言った話をあまり聞きません。

言葉の壁以上に文化の壁があったりして、開発コストは抑えられても管理コストが増大したりして結局しわ寄せが別になった形で開発・運用費が抑えられているのか疑問にも感じたりします。

統制なきクラウドサービスの利用が社内に進むとシステムが乱立して混乱が生じます。

ただ、手軽に導入できるからこそ管理部門の要件も見えやすくなってくるわけで、そこをうまくフォローするニーズは高まってくるでしょう。

今まで手が出せなかったシステム導入が気軽にできる分、ユーザー主体でユーザーのニーズをそのままにサービスの導入が行われていきます。

こうなってくると情報システム部門の立ち位置も変わってくるわけで、今までのシステム開発の案件とは異なった役割が出てくるわけですが、そこは時代の流れに合わせた変化を求められてきます。

確かに今までの情報システム部門はIT投資の価値や統制やコストの適正化ができずにその存在意義を失いつつあるかもしれません。

そして、クラウドサービスの流行によりますます窮地に立たされているかもしれませんが、そんな玉石混合の時代だからこそ情報システム部門の価値が出てくるでしょうし、この状況は存在意義を見せるチャンスになるようにも思えます。

クラウドサービスの提供業者があなたの企業価値を高めることを本気で考えていることはありません。

社長が本気で自社のIT投資の価値を外部の業者がしてくると思っているようならよっぽどお人よしのように思えます。

こういってしまうと語弊があるかもしれませんが、ホームページや営業はそういう謳い方をしていますし、実際に一昔前のサービスに比べたら格段に質のよいものを提供してくれると思いますが、契約やコスト面で提供業者ができるサービスには限度が出てきますし、何よりもクラウドサービスは汎用的であるが故に細かなところに手が回らない課題もあります。

日本のシステム要件ってやたら重箱の隅をつつくようなものが多く、だけどそれが大事って考える風潮があったりしてクラウドサービスのような汎用的なものを使う場合、現行の業務プロセス側を変化させる必要があるのでなかなか導入が難しい側面もあるように思えます。

手軽に導入できるからという名目でクラウドサービスを利用しようとしても、要件がそぐわずに無理にそれを実装しようとしてカスタマイズが必要になったりして予算がオーバーとなったり、無理な機能追加をすることでプロジェクトが火を噴いたりというのはよく見る光景です。

結局、自分たちの企業価値やシステム投資を適正化できるのは自社で現場がわかっている人間でしかないわけで、だからこそ情報システム部門の価値を再確認しなくてはならなと思うわけです。

もちろんそれには情報システム部門の中にも変化が求められるわけですが。

[PR]エンジニアに特化！エンジニア専門の転職支援は「メイテックネクスト」

[PR]【CPI】ディスク容量無制限で3990円のレンタルサーバー

[PR]高速・定額・低料金のイー・モバイル！

たくらむ技術 (新潮新書)/新潮社

￥735

Amazon.co.jp

ロンドンハーツやアメトーーク！でおなじみのプロデューサーである加地さんが書いた本。

番組の裏側も踏まえて書かれているので番組のファンであれば楽しく読める本だと思います。

常に何か新しい企画を作り、世の中に出していくのはかなり難しいことですし、自分たちがやっている仕事に比べてそのスピード感というのは何倍も違うんだろうなと感じます。

ただ、TV業界って一般的な企業とは少し異質な感じもするので、その辺のワークスタイルの違いや、加地さん自身のゆるいキャラからくる文章なのかもしれませんが、タイトルの「たくらむ技術」については少しわかりづらいとも思いました。

番組内のかなり細かいところが書かれていたりもするので、番組を知らなかったり業界に興味がなければ少し飽きてしまうかもしれません。

一番わかるのは、観察能力やコミュニケーション能力が高いんだなという点と、物事を決め付けずに常に中間の立ち位置で判断する人なんだなという点。

そういった能力を活かして様々な番組企画を考えたり、出演者との絡みをうまくやっていっているんだなというのは本からも見て取れます。

こういった業界の人はかなり多くの人と接して仕事をしていっているでしょうから、人付き合いをうまくするコツであったり、相手が何を考えているかを読む気配りであったり、場を壊さないためのテクニックというものが必要になってくるのでしょう。

どちらかというと仕事の取り組み姿勢や考え方についてヒントになる本かもしれません。

1. バカげた企みほど手間をかける

2. 企画は自分の中にしかない

3. 会議は短い方がいい

4. 勝ち続けるために負けておく

5. 文句や悪口にこそヒントがある

6. 「イヤな気持ち」は排除する

7. 計算だけで100点は取れない

8. マジメと迷走は紙一重

9. 企画書を通すにはコツがある

10. かわいがられたほうが絶対にトク

11. 仕事は自分から取りに行け

12. 常識がないと「面白さ」は作れない

13. 芸人は何を企んでいるのか

14. 「企み」は仲間と共に

CakePHPに限らず多くのフレームワークは、レイアウトを制御し所定のフォーマットを各画面に適用する機能を持っています。

ちょっとしたデザイン変更をしたい場合やユーザーの設定によりテーマを切り替えさせたいといった場合、レイアウトの機能をうまく使いこなせればかなり効率化でき便利に使えます。

CakePHPのレイアウト機能でどのようなことができるのかは、デフォルトで用意されているレイアウトファイルを見てみると大体のことがわかってきます（ここでは、バージョン2.3.1を使っています）。

$cakeDescription = __d('cake_dev', 'CakePHP: the rapid development php framework');
?>
<!DOCTYPE html>
<html>
<head>
    <?php echo $this->Html->charset(); ?>
    <title>
        <?php echo $cakeDescription ?>:
        <?php echo $title_for_layout; ?>
    </title>
    <?php
        echo $this->Html->meta('icon');

        echo $this->Html->css('cake.generic');

        echo $this->fetch('meta');
        echo $this->fetch('css');
        echo $this->fetch('script');
    ?>
</head>
<body>
    <div id="container">
        <div id="header">
            <h1><?php echo $this->Html->link($cakeDescription, 'http://cakephp.org'); ?></h1>
        </div>
        <div id="content">

            <?php echo $this->Session->flash(); ?>

            <?php echo $this->fetch('content'); ?>
        </div>
        <div id="footer">
            <?php echo $this->Html->link(
                    $this->Html->image('cake.power.gif', array('alt' => $cakeDescription, 'border' => '0')),
                    'http://www.cakephp.org/',
                    array('target' => '_blank', 'escape' => false)
                );
            ?>
        </div>
    </div>
    <?php echo $this->element('sql_dump'); ?>
</body>
</html>

CakePHPでアプリを作り始める際にはレイアウトは上記のような構造となっており、これは主にデバッグ用の機能がちりばめられています。

肝心のコンテンツ（/path/to/cakephp/app/View/AppName/TemplateName.ctp）を出力するのは、

<?php echo $this->fetch('content'); ?>

という1行だけでよいので、各Viewファイルで<html>から</html>までを書いているなら、上記の1行をdefault.ctpとして保存すれば余計なデバッグ情報を出さずにコンテンツのみを表示できます。
余談にはなりますが、バージョン2.3以前では$content_for_layoutという変数に上記の結果が含まれており、2.3以降でもこの変数は利用可能ですが、正しい書き方としては構文が上記のように変更されています。

このdefault.ctpの中で幾つか便利な機能が提供されています。

<?php echo $this->Html->charset(); ?>

上記は、HTML内のMETAタグの文字コードを定義してくれ、展開されると

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

という風に出力されます。
これの便利なところとしては、CakePHPの設定ファイル（core.php）とリンクしており

Configure::write('App.encoding', 'UTF-8');

の設定を拾ってMETAタグを生成してくれます。

他にも

echo $this->Html->css('cake.generic');

という書き方で、CSSを自動的に読込んでくれます。

このCSSは、「/path/to/cakephp/app/webroot/css/」ディレクトリ内にあるものを読込みます。

（拡張子の.cssは不要です）

LINKタグを書くよりは若干楽でしょうか。

レイアウトファイルは、抽象化したテンプレートファイルであるため、動的に出力するHTMLを変えていきたいというような要件がでてきます。

もちろん、コントローラー側でどうにかする方法もありますが、ビューブロックという機能を使えばより単純に後付でテンプレートの内容を変えていくということが可能です。

echo $this->fetch('meta');
echo $this->fetch('css');
echo $this->fetch('script');

デフォルトテンプレートの中では、上記のようなロジックが書かれている箇所がありますが、この箇所にViewファイル側から動的に結果を埋め込んでいくというようなことが可能です。

（デフォルトテンプレートだけでは、この結果は何も出力しませんが）

ビューブロックを使うには、下記のようにViewファイル側でそれぞれのブロックに出力する処理を書いていきます。

一番最初に書かれているmetaブロックに出力するには、

<?php $this->assign('meta', 'fugafuga'); ?>

または、

<?php
$this->start('meta');
echo "hogehoge";
$this->end();
?>

のような書き方ができます。

前者の書き方はmetaというブロックに文字列を割り当て、後者の書き方ではmetaというブロックの開始（start）を宣言し、終了（end）までの出力結果を割り当ててくれます。

また、デフォルトテンプレートに記載のmetaというブロックは、HTMLで言うところのMETAタグやLINKタグなどが出力されることを想定しているものだったりもしますので、下記のようにHTMLヘルパーを使ってmetaブロックにHTMLを出力することも可能です。

<?php $this->Html->meta('icon', 'favicon.ico', array("inline" => false)); ?>

上記の結果により、metaブロックに下記のHTMLが出力されます。

<link href="favicon.ico" type="image/x-icon" rel="icon" />

metaブロックへどこで出力の制御を行っているんだという話ですが、第3引数の配列キー「inline」をfalseで渡すとmetaブロックへ出力してくれます。

他にも、

$this->Html->meta('description', 'A great page', array('inline' => false));

という処理で、METAタグのdescriptionのHTMLをmetaブロックへ出力してくれたりします。

これは、CakePHP標準として実装されているHTMLヘルパーですので、cssやscriptの場合どうするのかや引数の詳細については、「/path/to/cakephp/lib/Cake/View/Helper/HtmlHelper.php」を参照してみてください。

または、CakePHPのマニュアル も参考になるかと思います。

レイアウトファイルは、テンプレートファイルのさらに元となるファイルですので、その共通部分をうまく抽出して定義してあげればデザインの変更や切り替え機能などが簡単に実装できるかもしれません。

[PR]安心・直販・カスタマイズ対応！ThinkPadのレノボ・ジャパン

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

[PR]固定IPが【業界最安値クラス】＋【５分で発行】＋【２ヶ月無料体験】

「CakePHPのデフォルトレイアウト「default.ctp」を読み解く 」の続きにはなりますが、テンプレートやビューの機能の中にはこの他にも便利な機能が幾つかあります。

その1つが、よくあるパターンとしてレイアウトの一部分がどれも共通で同じものを表示したいというようなときに使えるエレメントという機能があります。

ビューの中にまともに書いていくと、テンプレートファイルが数個のレベルであれば手作業でいけるかもしれませんが、数十や数百という数字になってくるとデザインの変更依頼がきたら発狂したくなるレベルになってしまいます。

こんなときに、共通部分をパーツとして切り出し、その他のレイアウトにも適用するのがエレメントの機能です。

例えば、どのページでも共通で使うフッター部分として、下記のようなHTMLがあったとします。

<address>Copyright &copy; itboy All Rights Reserved.</address>
</body>
</html>

これを共通パーツとしてエレメントに登録したい場合は、下記のパスに保存します。

/path/to/cakephp/app/View/Elements/footer.ctp

レイアウトやビューファイルからは、下記のように呼び出すだけでどのテンプレートファイルからも共通のHTMLを出力させることが可能になります。

<?php echo $this->element("footer")?>

こうすることで、Elementsディレクトリにあるfooter.ctpが自動的に呼び出されます。

エレメントへは引数を渡すことも可能ですので、共通ではあるんだけど微妙に出力されるデータが違うとかといった場合でも対応が可能です。

<?php echo $this->element("footer", array("hoge" => "Hello World"))?>

エレメント用のファイルであるfooter.ctpは、下記のように書いておきます。

<address><?php echo $hoge; ?></address>
</body>
</html>

上記の実行結果は、下記のようになります。

<address>Hello World</address>
</body>
</html>

今回紹介したようなフッタ以外にもヘッダやグローバルメニュー、広告などなどテンプレートで共通化できる部分って多いと思いますので、1つのファイルで一元管理され、1つを変更することで全てのHTMLファイルを書き換えてくれるので保守・運用を楽にしてくれる便利な機能だと思います。

[PR]【航空券＋ホテル】海外旅行エクスペディア★パッケージツアー

[PR]お名前.comのホームページ作成ツール★誰でも簡単にWebクリエイターに

[PR]iPhone家族無料キャンペーン

情報を検索するというのは、どんなサービスであれ重要な機能になってきますが、単純なDB検索などでは情報の精度が悪かったり、パフォーマンスが出ないといった問題が出てきます。

SQLのLIKE文ではIndexが使われなかったり、あいまい検索をすると余計な情報が引っかかったりして、その検索順位のスコア付けをしようとすると別のロジックが必要になってきたりして、かなり複雑な処理になってきます。

そんなこんなで億劫になってしまう検索システムですが、Apache Solr を利用すると手軽に高度な検索システムを導入することができます。

Apache SolrはJavaで書かれているため、利用するためにはJava（バージョン1.5以上）の環境を用意する必要があります。

今回の環境では、CentOS6.4にApache Solr4.2をインストールします。

Javaの環境が用意されていない場合は、yum経由とかでインストールしておきましょう。

# yum install java-1.6.0-openjdk.x86_64
# yum install java-1.6.0-openjdk-devel.x86_64
# yum install ant.x86_64

antは、後で説明する形態素解析用エンジンであるSenを利用する際に必要になってきますのであわせて準備しておきます。

Javaの環境が整ったら、Apache Solrのソースファイルをダウンロード します。

ファイルのダウンロードが終わったらサーバーにアップロードし、適当なディレクトリに展開します。

最もシンプルに使う方法としては、インストールはたったこれだけで完了です。

試しにApache Solrを起動してみます。

起動用のjarファイルがexampleディレクトリ内にあります。

# cd /path/to/solr/example/
# java -jar start.jar >> /var/log/solr.log 2>&1 &

これで起動完了です。

エラーがある場合は、ログに書き出されるので確認してみましょう。

ちなみに、デフォルト設定だとApache Solrは8983ポートを使います。

iptablesの設定をしている場合は、そのポートを解除しておきましょう。

起動ができたら、管理サイトにアクセスしてみましょう。

http://localhost:8983/solr/#/

下記のような管理サイトが表示されたらインストール成功です。

ちなみに、このインストール方法はSolrに内蔵されているJettyを利用しているため、既存環境にApacheが動いていても平行稼動ができます。

利用する際のポート番号を変えたい場合は、下記Jetty用のファイルを編集しましょう。

/path/to/solr/example/etc/jetty.xml

最後に、毎回start.jarファイルをたたくのも面倒なので、自動起動用スクリプトを作って/etc/init.d（と、ランレベルに応じてrc3.dとか）に配置しておきます。

#!/bin/sh
# chkconfig: 345 90 90
# description: Solr Boot
JETTY_HOME_DIR=/path/to/solr/example/
cd $JETTY_HOME_DIR
JAVA="/usr/bin/java"
LOG_FILE="/var/log/solr.log"

KEY=stopkey
CORE=solr
cd $JETTY_HOME_DIR
start() {
  $JAVA -Dsolr.solr.home=$CORE -DSTOP.PORT=8079 -DSTOP.KEY=$KEY -jar start.jar >> $LOG_FILE 2>&1 &
  echo "Solr started!"
}

stop() {
  $JAVA -DSTOP.PORT=8079 -DSTOP.KEY=$KEY -jar start.jar --stop
  echo "Solr stopped!"
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
      stop
      start
      ;;
    *)
      echo "Usage: $0 {start|stop|restart}"
      exit 1
esac

chkconfigとかはお好みでどうぞ。

ここまでの作業でSolrは利用可能になっていますが、データに日本語が入っている場合は検索できません。

英文と違って日本語は単語の区切りがわかりづらいので、形態素解析を使って文章内のキーワードを抽出する仕組みが必要になってきます。

Senは形態素解析エンジンのMeCabをJava用のライブラリとして移植したものです。

Senのソースファイルのダウンロードはブラウザ経由でできないため、SVN経由で落としてきます。

$ svn co https://svn.java.net/svn/sen~svn/tags/SEN_1_2_2_1/sen
$ cd sen
$ ant

「BUILD SUCCESSFUL」というメッセージが最後に表示されたら完了です。

Senのビルドが終わったら形態素解析の元データとなる辞書登録を行います。

今回はIPAdic legacy を使います（バージョン2.7）。

上記のサイトから辞書データのtarボールをダウンロードしてサーバーにアップしておきます。

元々、Sen自体の辞書登録スクリプト（ビルド用ファイル）がIPAdicを使うようになっているのですが、Senのバージョン1.2.2.1ではこの辞書登録用のスクリプトが古くそのままだと動かないので編集します。

$ cd /path/to/sen/dic

上記フォルダ内にある、build.xmlを編集します。

まずは、17行目あたりにあるバージョン情報を「2.6.0」から「2.7.0」に変更。

<property name="ipadic.version" value="2.7.0"/>

次に、このビルド用のファイルはサーバーから直接ファイルをダウンロードして辞書登録する仕組みになっていますが、そのパスに現在はファイルが存在しません。

そして、先ほど辞書データをダウンロードしてサーバーにアップしているのでそちらを利用してもらうように編集します。

具体的には、サーバーから直接取りにいく処理をコメントアウトしてしまいます（64行目あたり）。

  <target name="download" depends="prepare-proxy,prepare-archive,prepare-dics0,prepare-dics" unless="ipadic.archive.present">
<!--
    for proxy
    <setproxy socksproxyhost="proxyhost" proxyport="8080" />
    <get src="${ipadic.home}/${ipadic.archive}" dest="${ipadic.archive}" />
-->
  </target>
  <target name="melt" depends="download,prepare-dics" unless="dics1.present">
<!--
    <gunzip src="${ipadic.archive}"/>
    <untar src="${ipadic.dir}.tar" dest="." />
    <delete file="${ipadic.dir}.tar"/>
-->
  </target>

そして、先ほどアップしておいた辞書データをSenの辞書データ保管用のディレクトリに移動させます。

$ cd /path/to/sen/dic
$ cp -R /path/to/ipadic-2.7.0 ./
$ ant

こちらも最後に「BUILD SUCCESSFUL」というメッセージが出てきたらビルド完了です。
最後に、出来上がった辞書用のライブラリをSolrに組み込みます。

$ cd /path/to/sen/lib
$ cp sen.jar /path/to/solr/example/solr-webapp/webapp/WEB-INF/lib/

この一連の作業で、Apache Solrで形態素解析が利用できるようになります。

以下、余談ですがSenのインストール時にエラーが出た場合の対処です。

まず、Senをantでビルドする際に文字コードに関するWarningが出たりします。

compile:
    [javac] Compiling 31 source files to /path/to/sen/build/classes
    [javac] /path/to/sen/src/java/net/java/sen/SenUtils.java:158: warning: unmappable character for encoding euc_jp

が、これは基本的にメッセージなので無視してかまいません。

そして、個人的にはまったのが

[javac] /path/to/sen/src/java/net/java/sen/util/DoubleArrayTrie.java:1: class or interface expected
    [javac] cpp: error trying to exec 'cc1plus': execvp: No such file or directory
    [javac] ^
    [javac] /path/to/sen/src/java/net/java/sen/util/DoubleArrayTrie.java:1: unclosed character literal
    [javac] cpp: error trying to exec 'cc1plus': execvp: No such file or directory
    [javac]                           ^
    [javac] /path/to/sen/src/java/net/java/sen/util/DoubleArrayTrie.java:1: unclosed character literal
    [javac] cpp: error trying to exec 'cc1plus': execvp: No such file or directory

というエラーで、結論から言うとJavaやantの環境ではなく、gccやgcc-c++パッケージが入っていなかったために起きるという問題でしたので、yum経由でパッケージをインストールしたらantのビルドがうまくいきました。

そして、Solrの具体的な使い方の話を書いていきたいのですが、記事が結構長くなってしまったので、また次回にまとめていきたいと思います。

[PR]固定IPが【業界最安値クラス】＋【５分で発行】＋【２ヶ月無料体験】

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

[PR]SSLサーバ証明書なら[ドメインキーパー]◆VeriSign/GlobalSign/他取り扱い

前回の「Apache Solrを利用して本格的な検索エンジンを導入する 」の続き。

前回のエントリでApache Solr4.2のインストールと日本語検索の環境設定を行いましたが、今回は具体的なApache Solrの操作感をまとめていきたいと思います。

何にせよやっぱり動く環境を見ていくのが一番理解しやすいわけですが、デモサイトを一から用意してとなると結構手間になることから、下記のサイトの情報をベースに書いていきます。

第5回　全文検索エンジン「Lucene/Solr」を導入する ＠ ITpro

この記事はApache Solr1.3系の古いバージョンでの解説記事なので、このエントリではそれを4系のバージョンに焼きなおしたようなものになっています。

まず、P.1のSolrのインストールや環境準備は前回のエントリで整っているので割愛します。

ということで、P.2以降（要会員登録）のところからですが、簡易的な住所検索のプログラムのソースが一式ダウンロードできますので落としておきます。

このデモは、このアプリを使ってApache Solr上で住所検索をするというものです。

適宜、上記のITproのサイトも参照しながら読んでみてください。

住所検索プログラム（html、js、xslファイル）は、サーバー上にアップロード後、Apache Solrの公開ディレクトリに展開します。

便宜上、ディレクトリ名はデフォルトのCustomModulesからsearchという名前に変更しています。

$ cd /path/to/solr/example/solr-webapp/webapp/
$ cp ~/CustomModules.zip ./
$ unzip CustomModules.zip
$ mv CustomModules search
$ cd search
$ mkdir js
$ cd js
$ mv ../prototype-1.6.0.3.js ./

最後にしている作業は、prototype.jsファイルの呼び出し方がjsディレクトリにあるものを読込むようになっているため、ファイルを移動させています。

次に、Apache Solrの定義ファイル（schema.xml）をSolrのconfディレクトリに展開します。

$ cd /path/to/solr/example/solr/collection1/conf/
$ mv /path/to/solr/example/solr-webapp/webapp/search/schema.xml ./

ちなみに、collection1というのはSolrの検索エンジンのコアディレクトリになっており、コアごとに設定ファイルやデータファイルが存在します。

これで準備完了ということで住所録をSolrにインポートさせたいところですが、Apache Solr4系から幾つか仕様が変わっているめこのままだとエラーが出てうまくいきません。

そのため、先ほど展開したschema.xmlファイルを編集します。

<!--
<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />
-->

上記を編集しなかった場合、Solrを起動したときに下記のようなエラーが発生します。

collection1: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Plugin init failure for [schema.xml] fieldType "textTight": Plugin init failure for [schema.xml] analyzer/filter: Error loading class 'solr.EnglishPorterFilterFactory' 

Apache Solrではデータのインポートや検索のときに幾つかフィルタを通すことができます。

フィルタを通すことでデータを加工したり（例えば大文字を小文字にしたり、日本語の場合は形態素解析エンジンを指定したり、インデックスしないキーワードを指定したりなど）しながら利用できます。

そのフィルタが存在しないためのエラーなのですが、フィルタを使わなくても利用可能なためコメントアウトしてしまいます。

次に、fieldsタグの最後（93行目あたりの</fields>の直前）に、下記の項目を追加します。

<field name="_version_" type="long" indexed="true" stored="true"/>

これも登録しておかないと下記のようなエラーが出てしまいます。

collection1: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Unable to use updateLog: _version_field must exist in schema, using indexed="true" stored="true" and multiValued="false" (_version_ does not exist) 

私は、Solr4系からしか触っていないのですが、どうも4系から_version_というフィールドが必須となっているようです。

これで、schema.xmlファイルの編集は完了です。

もし、Solrを起動している場合は再起動しておきます。

前回のエントリで書いたように児童起動スクリプトを用意している場合は、

# /etc/init.d/solr restart

のようにしておきます。

これでようやくSolrに住所録データを登録できるので、サーバーに展開したディレクトリに含まれるzip-code.xmlをSolrに取り込みます。

$ cd /path/to/solr/example/exampledocs
$ ./post.sh zip-code.xml
Posting file zip-code.xml to http://localhost:8983/solr/update

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader"><int name="status">0</int><int name="QTime">21506</int></lst>
</response>
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader"><int name="status">0</int><int name="QTime">352</int></lst>
</response>

post.shは、Solrに付属しているSolrと対話するためのシェルスクリプトです。

Solrとの対話はRESTなAPIを通して行います。

post.shのシンプルなシェルスクリプトの中身を見ればわかりますが、実質

curl $URL --data-binary @$f -H 'Content-type:application/xml'

という一行だけで、このようにHTTPを通してSolrにデータの取り込みや検索など様々な実効命令が行えます。

要はHTTPクライアントとして動作する環境があればよいので、その他のプログラムからも簡易的に対話プログラムを書く事ができます。

もし、住所録データの取り込みがうまくいかない場合は、zip-code.xmlの文字コード周りかもしれません。

私の場合、サーバー環境がEUC-JPだったため少してこずったりしました。

zip-code.xmlをEUCで保存して、iconvなどからUTF-8に変換しなおして取り込んだらうまくいったりしました。

ここまでうまくいったら一旦、Solrの管理サイトから検索を実行してみましょう。

Solr管理サイトにアクセスし、左下のリストボックスから「collection1」を選択し、Queryメニューを開きます。

そこで、何も入力・変更しない状態で下のほうにある「Execute Query」ボタンをクリックして結果が表示されればうまく取り込まれています。

データの取り込みと管理サイト上での検索がうまくいったらデモ環境の構築に戻りましょう。

http://localhost:8983/solr/search/search.html

へアクセスしてみます。

これで、ITproの記事で解説されているように住所検索システムへアクセスできます。

しかし、最初のテキストボックスに例えば都道府県名を入力して検索しても何も反応がありません。

先ほど検索してみた、Solrの管理サイトのQueryメニューから「q」と書かれたテキストエリアに都道府県名を入力してみても同様にヒットしません。

<?xml version="1.0" encoding="UTF-8"?>
<response>

<lst name="responseHeader">
  <int name="status">400</int>
  <int name="QTime">1</int>
  <lst name="params">
    <str name="indent">true</str>
    <str name="q">北海道</str>
    <str name="_">1368198319211</str>
    <str name="wt">xml</str>
  </lst>
</lst>
<lst name="error">
  <str name="msg">undefined field text</str>
  <int name="code">400</int>
</lst>
</response>

この理由は、キーワードの検索対象フィールドが設定ファイル内で定義されているためです。

試しに検索キーワードに「prefecture:北海道」と入力して検索してみるとヒットするはずです。

これは、prefectureフィールドに対して検索しろって指定になります。
エラーメッセージにあるようにデフォルトでは、textという名前のフィールドに対して検索をしており、そのようなフィールドは取り込んだデータの中では存在していないためエラーを返してきます。

ということで、Solrの設定ファイル（solrconfig.xml）を編集します。

$ cd /path/to/solr/example/solr/collection1/conf/
$ vi solrconfig.xml

この中で、774行目あたりに検索実施時のデフォルトで検索するフィールド（dfという名前のフィールド）が定義されていますので、コメントアウトしてしまいます。

  <requestHandler name="/select" class="solr.SearchHandler">
    <!-- default values for query parameters can be specified, these
         will be overridden by parameters in the request
      -->
     <lst name="defaults">
       <str name="echoParams">explicit</str>
       <int name="rows">10</int>
       <!-- <str name="df">text</str> -->
     </lst>

編集が完了したらSolrの再起動が必要です。

これで再度、都道府県名だけで検索してみると結果が表示されるはずです。

ということで、デモサイトが出来上がったのでSolrの検索の最初の最初に触れる環境が整いました。

具体的な使い方を書きたいところですが、エントリも長くなったのでまた次回に。

[PR]SSLサーバ証明書なら[ドメインキーパー]◆VeriSign/GlobalSign/他取り扱い

[PR]20GB 1,995円の高機能レンタルサーバ

[PR]GMOクラウドのビジネス向けレンタルサーバー＜iCLUSTA+＞

自分の職場にも外国人の人がいたりして、そういった人から日本で働く難しさというものの中に「文化の違い」っていう言葉を耳にすることがたびたびあります。

確かに言葉だけでなく生活スタイルや企業独自のルールなどもあいまって形成される目に見えない文化というものを理解できなくは無いのですが、難しくしているのはそれだけなのかなって思ったりもします。

文化って特に住む国の間にあるものだけでなく、日本国内でも仕事をしているとその企業文化というのは耳にするところです。

ですので、外国にいるからとか外国人だからってわけだけでなく、その職場や属するチームにおいても面倒なルールが蔓延して文化を形成していたりもするわけですね。

「日本人は行間を読むから多少曖昧な仕様でも適当に取り繕ってくれるけど、オフショアで出してみたら仕様どおりにしか実装してこないのな」、なんて話をされたこともあるんですけど、それって別に文化の違いってわけでもなんでもなくて、同じ日本人でも空気読む力って個人で全然違いますから当然のように品質も異なるわけで、単純に第一印象が悪かったからそう思っているんでしょうと感じたりする部分もあります。

まぁ、言葉の壁って結構でかいので細かい行間を読むどころか正しく情報を伝えられていないというところがあるのは身を持って経験していたりするところではありますけど、どちらかというとそういうのが気になるのは細かすぎる性格というか、繊細に人をコントロールしすぎようとして失敗しているのではないかと思ったりもします。

ですので文化の違いといっても、日本人である私にも適用されていて、その変なルールや規律の中で仕事をしなくてはなりませんので条件は同じです。

転職したら新しい会社での企業文化を理解していかなくてはありませんし、プログラマとしてはその環境でのコーディングスタイルや開発環境を理解していかなくてはならないってな具合にです。

過去の経験に似たようなものがあればカンが働いての見込みが早くなりますが、全くの新境地であれば一度怒られたり、指摘されて恥じかいてってな具合にその領域を埋める経験をしない限りは気づきもしません。

文化の違いが難しいというのは、そういった独自のルールというものを覚えたり、そもそも自分が全く知らない領域のところを当たり前のように振舞われ、それに従わなくてはならないところに大変さがあったりもするんですが、簡単に言ってしまえば経験の積み重ねでどうにかなる部分でもあります。

この辺で、真っ向から覚えていこうというのは当たり前のように大変なわけですが、ただその文化を形成するのはそこにいる個の人たちの集合であるので、その人たちをよく観察してみたら見えてくるものもあって理解を助けることにはつなげられます。

要はそのローカルルールを覚えるのにいちいち手順書や規定を読んだりってな事をしなくても、そこに長くいる人と話をしたり、その人自身の行動を見てたら「あそこはあーやればいいのね」ってわかるところも多くあります。

まぁ、大概は単にその人が気分屋さんだったり、お堅い人で細かく管理しないときがすまない人であったり、取りあえず権力があるんだから俺様のルールに従えだったり、民主制で決めたものが幾年も受け継がれていたりと、そんな感じで変な文化が形成されていたりもするんですが。

結局のところ文化の違いに対応するためには、そこにいる人をよく観察したり、そこでの経験を活かして現場に適応していく能力次第なのかなと思ったりします。

まぁ、私は外国で仕事をしたこともありませんし、色んな企業を渡り歩いているわけでもないので、その文化の違いという苦労を実際のところ体験してないからそんなことが言えるのかもしれませんが。

自分の経験では、子供の頃に転校を繰り返したことがあって新しい環境にどう適応しようかと悩んだ時期がありました。

一番強烈だったのは、関西から関東に移り住んだときで、普通に関西弁で喋ったら全く通じないわけです。

当時は関西弁なんてテレビでも喋っている人が少なかったですし、ましてや子供でしたのでそれをどう標準語に翻訳すればいいのか頭を悩ませた記憶があります。

そんな環境があったからか、（職場には関西人が多いんですが）今でも関東に住んでも関西弁を喋ることは無いですし、その環境環境でどう適応していくのが一番手っ取り早く波風立たないのかなんて事を昔から考えるようになってしまいました。

話を戻すとそういった文化の違いって言うのはあるのが当然ですから難しく考えずに郷に入れば郷に従えでいいんじゃなかろうかと思います。

それは何でもかんでも従順に受け入れろということではなく、そのルールを理解してみることからスタートする必要はあります。

「文化の違いだ」なんて言葉を使ってしまえばそこで思考停止してしまって互いに歩み寄ることもできないでしょうから、単に環境が違うだけ、価値観が違うだけ、考えの方向性が違うだけとシンプルに考えてみたらいいのではと思うわけです。

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

[PR]高速・定額・低料金のイー・モバイル！

[PR]【パソナの人材紹介】 パソナキャリアの転職情報、求人情報