数年前と比べてエンジニアを取り巻く環境は劇的に変わってきています。

クラウドサービスが提供 されるようになり、自社で構築しなくても素早く安価にサービスインできたり、非エンジニアでもアイデアを実現するツールとして比較的容易に利用できます。

こうなってくるとエンジニアの生きる道というのも限られてくるのではないかなと、自分としても不安に思ってきてしまいます。

クラウドサービスがユーザーの要件を満たす環境を素早く提供しだすと、エンジニアの仕事はどんどんとそのサービスによって搾取されていきそうです。

今更BBSやブログシステムを一から作ってサービスとして公開しようと思うエンジニアはいないしょう。

その辺は既に大規模なサービスやパッケージやそしてオープンなライブラリが提供されており、自分で作るより高機能でそして優秀です。

また、個人レベルてはなくSIerのような受託開発業者も一からスクラッチで作ってくれという案件も減ってくるかもしれません。
日本人は細かな所にこだわりますし、クラウドやパッケージで提供されるサービスが一見無駄と思える日本企業の文化に何処までマッチしてるかは不明ですが、要件に多少目を瞑れば遥かに高速、低コストで環境を揃えられるようになっています。

こうなってくるとエンジニアが例えシステムを作り上げる力量があったとしてもそれを活かす場が少なくなってきます。
もはや、エンジニアはクラウドやパッケージなど、ある程度シェアを誇るサービスを提供する企業でその中の人をやるか、 サービスをカスタマイズしたり上手く組み合わせて付加価値を提供する使う側に回るという二極化をしてしまうかもしれません。

前者は豊富な経験と知識を兼ね備えたエンジニアが求められますので狭き門になりそうですし、後者はエンジニア以外にもアイデア次第でどうにかなってしまうところもあるので厳しい競争になりそうです。

一から何かを作るにしても大規模なサービスが完全に覇権を握ってしまっている領域ではとても太刀打ちできないでしょうから、ひと昔前のようになかなか新たに開拓して切り開くのは難しく思えます。

ここまでの事は少し前まで自分が思ってたことですが、最近はそんな事もないのかなと感じてきたりしています。

理由は、大きなサービスはその提供範囲が広い故に必ず隙間ができてしまうということです。

その隙間、つまりはニッチな所で個人のエンジニアが活きる道はあるのではないかなと。

そのサービスのど真ん中に突っ込んで行くのは、先ほども言ったとおり到底太刀打ちできず、結果は目に見えているのでやめた方が良いでしょう。

しかし、大規模なサービスはその大きさゆえに小回りが効かなかったり、必ず取りこぼす領域がでてきます。

マイノリティだけど確かにニーズがある機能や、特定の地域にフォーカスを当てたサービスや、他社との利権が絡むような領域であったり、ニーズは多いんだけどマネタイズすることが難しかったりと、それは大企業だと目に入らない領域であったり、大きなサービスをそのためだけにカスタマイズするのは採算が合わなかったり、そんな小さなところに目を向けるぐらいならもっと金のなる木を見つけようとしたりと、規模が大きくなるサービス故の問題点やジレンマも出てきます。

だからこそそんなニッチな所に個人が入り込む隙間があるのではないかなと思うわけです。
大企業が手を出せない部分ってのはあるわけですから、そこを個としてのエンジニアがついていくというのはありでしょうし、小回りが効く故の利点もでてきます。
すべての顧客が既存のサービスを使う事を望んでるわけでもないでしょうし、差別化を図るならそのニーズもより協力に生まれてきます。
場合によっては大きく成長できる分野も出てくるのでしょうし、他の切り口から既存のサービスを切り崩していける可能性もあるでしょう。

ここで書いた事は別に目新しい事ではありません。

IT業界を切り開いた先人も最初はそのニッチな分野から始めたという例も多々あります。

似たようなサービスでも視点を変えて、自分ならこうするのにってアイデアとそれが実現できるというエンジニアならではの自負があるからこそ新たなサービスが生まれてくるのでしょう。

OSS界では、似たようなパッケージやライブラリが次々出てきたりすることが多いですが、その辺も見た目は同じでも設計思想やユーザーに与えるメリットが異なるものが多かったりします。

これからのエンジニアはより、その隙間を見つける力も必要になってくるのだと思います。

この分野はあのサービスが抑えていると諦めるのではなく、ターゲットや切り口をを変えてみたりして隙間を狙って見ることも大事なんだなと最近感じます。

[PR]安心の365日電話サポート付きWADAXレンタルサーバー。

[PR]ビジネスの最前線で勝ち残るための必要な情報が凝縮　日経ビジネス

[PR]集客にお困りの方は必見。Yahoo! JAPANが提案する集客アップの方法。

今の会社には、世間一般の役職のような概念がないのでちゃんと部下と呼べないのかもしれませんが 、チームの中で一緒に働く下の子達がいて、その子に色々仕事を頼んだりするわけです。

勝手な想像としては、「○○くん、これを頼む」って言えば後は勝手に仕事が進むようなイメージを持ってたりもしたんですが、この状況は状況で別でやる事も増え、 返ってもどかしさが募るもんだなと感じたりします。

そのもどかしさの一つが 、自分がやった方が早いという気持ちを抑えるというものだったりします。

自分が下の立場だった時に上司も感じていたことなんでしょうけど、やはり何かとつたない感じで仕事をしているのを見ると、自分がやればすぐに終わる事でも想定以上の時間がかかり、何でこんなやり方してんだろって気持ちにもなります。

エンジニアの仕事柄、色んな技術やツールや手法があるわけですけど、そういったものって経験が優位に働くことも多いので、回りくどいやり方をしているのを見ると「それ、○○でできるよ」といちいちツッコミたくなるもどかしさがでてきます。

ただ、その気持ちを優先させて何でもやってしまうと、部下に経験を積ませる事もできませんし、自分も本来違う事をやる為に仕事を振ってるわけで、その本来やるべき事に注力できないという事態に陥ります。
部下に任せる許容力が必要ですし、 何かあった際に責任をとる覚悟も必要でしょう。

もう一つは、現場から離れるもどかしさです。
自分がやった方が早いというのは、どこかしらその現場に固執してる自分がいたりして、今までや自負みたいなものもあったりして捨てきれない気持ちがあります。

こういったもどかしさは、現場を離れて間もないうちなのかもしれません。
現場での仕事がまだ頭から離れてないから、そういったもどかしさが募るわけで、もう頭の片隅からも消えたって状態になれば、部下がやってる内容を理解できず、一歩下がってスケジュールとタスク管理を淡々とこなせるのかなと。

まぁ、その現場を理解できるというのは、何かあったら自分で責任取れるって強みにもなると思います。
なので、余計に強みがあるのに発揮できないもどかしさと、現場を忘れていくことへのもどかしさが複雑に絡まってくるのかなとも思います。

部下に仕事を頼めば時間に余裕ができ、随分と仕事も楽になるだろうなと思ってたりもしましたが、実際のところそこまで楽にはなりません。

部下がする仕事をマネジメントするのに時間がかかりますし、部下がした仕事をチェックする時間も必ず必要になりますので、100の仕事を割り当ててもそのうちの3割ぐらいは自分が担当する事になるのではないかと思います。

実際、タスクの量は同じでも処理する時間が違うため、これまた自分がやった方が早いとなるかもしれません。

下の子が書いたコードをレビューすることもあるでしょうし、その過程で指摘したことを積み上げると、自分で書いたのと変わらないじゃんという気持ちにもなったりするわけです。

まぁ、それが上司の仕事なわけではありますが、部下は一人ではなかったりして、自分の時間が結構細切れに削り取られます。
そういうのをなくす為には仕事を丸投げするしかないのかなと。
ただ、自分が楽するだけでなく部下も与えられた範囲が多くなれば責任を感じたりもしますし、たまには丸投げも必要なんじゃないかなと思ったりします。
もちろん、何かあった際の責任はとる覚悟は必要になってくるので、現場と一定の距離を置くとはいえ、そこでの知識や技能というのは常に持っていないといけないと感じます。

このあたりのことは、現場での最新技術についていけなくても、長年の現場の感って結構当たったりして、なんとなく何が悪いのかとか、どう直せばよいのかとかの気付きが得られたりもするものです。

ただ、何時までも同じコードを書くようなことには興味が薄れてきたりして、アーキテクチャやシステムデザインやら別のところへ移っていったりもしますので、同じレベルで仕事は出来ないなとも思ったりします。

結局、部下が出来ても周りに気を使いながら自分の仕事をこなしていく起用さが必要になってきます。
それはやっぱり仕事が楽にはならないわけで、ただ本来の仕事とは関係ないところで忙しくなってるわけですよね。
上司だろってことで、本来のミッションとは違うところで時間が取られことが多くなるなと感じています。

エンジニアの35歳定年説とかを信じているわけではないですが、実際にそんな立場の変化によって、効率的に人を育てながらもエンジニアとして生き残っていくための術を身につけていく必要があるなと感じたりしています。

優秀な部下が育つことはうれしいことですが、それはそれで現場から自分の必要性が失われるので寂しいとともに、競争による努力をよりいっそうする必要も出てきます。

そのためにも、もどかしさはあるもののそんな中でも一定の現場での空気感には触れておいた方がいいんでしょうね。

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

[PR]光ファイバー/ADSLを楽しむなら「安心」「安全」の@nifty！

[PR]ビジネスホテル予約サイト [Yahoo!ビジネストラベル]

30代を後悔しない50のリスト 1万人の失敗談からわかった人生の法則/大塚寿

￥1,500

Amazon.co.jp

2012年になり、「自分今年の誕生日迎えたら四捨五入して40歳になるんだ」とか思ったら急に焦燥感が生まれたりしまして、そんなときにふと本屋で目に留まった本です。

昨年結婚して急にプライベートでも時間も取れなくなってきたり、仕事ではやはり自分がやりたいことをやるというよりは部下をマネジメントしたり成長させる方向に仕事も向きだして、30代中盤になりこんな状態で本当にいいのかなという不安はやはり付きまとうものです。

30代も今年入れて残り6年となるわけですが、やはり今のペースのままで行くよりはしっかりと人生設計を立てなくてはいけないんだなとこの本を通して改めて思ったりもしました。

この本に書かれていることは、著者の経験だけでなく多くの人からヒアリングした30代の後悔というものが描かれています。

人生は一度きりであり、誰の生まれ変わりであろうと前の記憶というものを引き継ぐことは出来ません。

つまりは、誰しもが同じ間違いを身をもって味わうことでしか理解できないわけで、やはり他人の教訓というものは重く受け止めるべきなんだなと感じたりします。

ここに書かれていることは、30代半ばになった自分もよく感じることも多々あります。

本の内容は「20歳のときに知っておきたかったこと 」に書いてある内容と近いものがありますが、より30代の現実というものにテーマを絞り込んだ内容になっています。

それをどう解決するかのアドバイスも含めて年初に味わった焦燥感を少しは軽減できたと感じます。

人の後悔というのは、他人と比較してうまれたりするのだと思いますが、人間は経験しないとなかなかわからないもので、後悔をしないためにはそれを感じた人のアドバイスを受けて自分の人生を調整していくしかないのだと思います。

20代では何も考えず我武者羅に目の前にあることをこなしていくことで手一杯にもなっていたり、そもそもそんな不安さえも頭をよぎりませんでした。

しかし、歳を取っていくと時間は恐ろしいほど早く経過していくように感じますし、やはり後悔をせずに人生を終えたいという気持ちも強くなります。

人生のテーマなんてそのうち見つかるだろうと思っていても、実際に30代になっても漠然とした自分の進む道が見えはするものの、本当にそれは自分がしたいことだったのだろうか？ただレールを歩いていたから今にたどり着いただけじゃないのか？って懐疑的になったりもします。

30代だけでなく、20代の人もぜひ読んで欲しいと思います。

今はそんなことは考えられないといっても、そのうち考えざるを得なくもなってくるものです。

早めにその種を自分の頭の中に植えつけておくことで、来るべき時にもっと柔軟に対応が出来るかもしれません。

ちなみに、著者は

40代を後悔しない50のリスト 1万人の失敗談からわかった人生の法則/大塚　寿

￥1,500

Amazon.co.jp

という本も出しているようです。

第1章 この10年で何よりも大切にしたいこと
1  「自分のテーマ」が見つからなかった
2  「リアル人生設計」を描けなかった
3  憧れの理想像を持てなかった
4  誰と付き合うか真剣に考えるべきだった
5  「稼ぐ力」を身につけたかった
6  真面目だけではうまくいかなかった
7  もっと多くの人と出会っておけばよかった
8  失敗から真剣に学ぶべきだった
9  「良い習慣」を身につければよかった
10 偶然と上手に付き合うべきだった

第2章 プロフェッショナルとして絶対に必要なこと
11 コミュニケーション能力を高める努力をすればよかった
12 人前で話せるスキルを身につければよかった
13 「雑談力」を身につけたかった
14 会社や上司の「本音」を慮るべきだった
15 「段取り」のスキルを身につければよかった
16 チャンスにすぐ対応すればよかった
17 組織の中で「自分」を貫けなかった
18 「正しい努力」ができなかった
19 仕事とプライベートを線引きしなければよかった
20 大量行動ができなかった
21 「自分時間」を確保できなかった
22 「年収を上げる努力」をしていなかった

第3章 人生を左右する決断について知っておくべきこと
23 転職すればよかった
24 起業すればよかった
25 結局、「好き」を仕事にできなかった
26 家を買えばよかった
27 人生をともに過ごす仲間が見つからなかった
28 結婚すればよかった
29 結婚しなければよかった
30 一人で生きることを選んでしまった

第4章 「仕事以外」で必ず考えておくべきこと
31 「二つ以上の世界」を持っておけばよかった
32 体を鍛えておけばよかった
33 「大人の遊び」を知っておけばよかった
34 自分を磨くべきだった
35 気づいたらサラリーマンのレールの上を走っていた
36 もっと海外旅行に行けばよかった
37 忙しくても家事をもっとやればよかった
38 もっと子育てに参加すればよかった
39 子供の「叱り方」を学べばよかった

第5章 「お金のこと」で知っておくべきこと
40 お金を貯めるクセをつけておくべきだった
41 税金についてもっと勉強しておくべきだった
42 「生き金」は使うべきだった
43 お金に対する「自分のルール」をしっかり持つべきだった
44 家の買い方をもっと工夫するべきだった

第6章 揺れ動く心を支えるためにやっておくこと
45 利他の心を持つべきだった
46 他人の意見を聞くべきだった
47 自分が年をとることをもっと真剣に意識するべきだった
48 無意識に好奇心が衰えてしまった
49 「打たれ強さ」を身につければよかった
50 世間を意識しすぎた

イシューからはじめよ―知的生産の「シンプルな本質」/安宅和人

￥1,890

Amazon.co.jp

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

11年のまとめも書いてないんですが、12年もゆったりと活動を開始していきたいと思います。

本年も本ブログの記事が何かお役に立てれば幸いです。

ということで、12年最初の記事は書評からスタートしたいと思いますが、この本自体は11年の積読してた本でありまして、帰省中に読んだものであります・・・。

この「イシューからはじめよ」は、私たちが仕事の中で取り組む目的や課題をよりはっきりさせ、意味のある成果をあげるための考え方やフローをまとめたものになっています。

仕事をしていると色んなプロジェクトや資料作成を行ったりしていますが、途中で「何のためにこれをやっているんだっけ？」とか、当初の目的から方向性がずれだして取り合えず与えられた成果物を作ることだけが目的になっているということはよくあったりします。

プロジェクトの方向転換とかはよくあることでそれは特に問題ないとは思いますが、そもそもの目的設定が間違っていたり、意外と自分たちで「この目的設定は間違えていない」と思っていても視点を変えてみるとそれは全然必要ないことだったりで、プロジェクトが達成した翌年には別の課題が持ち上がってその解決に向けて別のプロジェクトが立ち上がるということもあったりします。

要は最初の課題の捕らえ方、目的の設定やそれを解決するためのフローがそもそも間違えているということがあるわけです。

この本では、本当に価値ある仕事をするためにその「価値ある仕事」をどうやって見つけていくか、それを達成するためのフローが描かれています。

「数をこなしていけば真価にたどり着く」という発想は止めようということも書かれていたりして、自分の仕事のやり方に対してドキッとさせられたりもするんですが、なかなか本当に解決すべき問題というのを見つけ出すのは難しいものです。

よく上司から「こういう課題があがっている」ということを聞いたりして、それを解決するための施策が立ち上がったりしますけど、これって全然問題解決になってなかったりもするわけです。

その上司の課題設定が間違っていたら、先に書いたように別の課題が持ち上がったりもしますし、その上司もさらにその上の人から伝え聞いたことを伝言ゲームのように流してくることもあるわけで。

また、こういう仕事の進め方をしていたら、上下関係の権限の問題から課題の真価には何時まで経ってもたどり着かずに、お上が言うことを延々とこなしていくということにもなってしまうため、単なるインプットとしてその先に考えるべき問題って何があるんだろうというところ俯瞰的にみていく必要もあります。

今一度自分たちがやっている仕事の価値とは何か、達成すべき目的設定はどうあるべきかということを考えさせられる一冊でした。

第1章 イシュードリブン - 「解く」前に「見極める」
イシューを見極める
仮説を立てる
よいイシューの3条件
イシュー特定のための情報収集
イシュー特定の5つのアプローチ

第2章 仮説ドリブン1 - イシューを分解し、ストーリーラインを組み立てる
イシュー分析とは何か
イシューを分解する
ストーリーラインを組み立てる

第3章 仮説ドリブン2 - ストーリーを絵コンテにする
絵コンテとは何か
軸を整理する
イメージを具体化する
方法を明示する

第4章 アウトプットドリブン - 実際の分析を進める
アウトプットを生み出すとは
トラブルをさばく
軽快に答えを出す

第5章 メッセージドリブン - 「伝えるもの」をまとめる
「本質的」「シンプル」を実現する
ストーリーラインを磨き込む
チャートを磨き込む

HTMLタグをそのままユーザーに入力させ、それを正しい形で利用したいというケースは少ないかもしれませんが、ブログシステムやそれに似通った機能をユーザーに提供したい場合、その中から不正なHTMLタグをチェックするロジックを作ることは結構大変なことです。

こういったケースでは、HTML Purifier を使えば比較的容易に安全にHTMLタグを扱えるようになります。

OSSのブログシステム用プログラムとして有名なWordpress も、HTMLタグのフィルタとしてHTML Purifierを利用しているようです。

Wordpressを使ってなくても、例えば「高機能でカスタマイズも容易なWYSIWYGエディタ [CKEditor] 」で書いたような独自の入力フォーム用のブログシステムを作りたいといったケースでも適用できるかもしれません。

HTML Purifierのインストール方法は何種類か用意されており、PEARからインストールすることや、ソースプログラムをダウンロードして適当なディレクトリに保存すること、gitからインストールするというパターンなどがあります。

ここでは、簡単に導入できるPEARを使うパターンで書いています。

# pear channel-discover htmlpurifier.org
# pear install hp/HTMLPurifier

上記のようにインストールすると、PEARのディレクトリ内にHTML Purifierのプログラムが展開されます。

HTML Purifierの利用は、下記のように使います。

<?php

require_once 'HTMLPurifier.auto.php';

$config = HTMLPurifier_Config::createDefault();
$config->set('Core.Encoding', 'UTF-8');
$config->set('Core.Language', 'ja');
$config->set('HTML.AllowedElements', array('a', 'em', 'p', 'h2', 'span', 'br'));

echo $hp->purify($_POST['data'];

上記は、dataというパラメータで送られてきた値をHTML Purifierで処理しています。

基本的には、許可したいタグや動作をConfigオプションで指定し、処理させる変数に対して最後にpurify()メソッドを通すことで余計なタグを除去したりすることが出来ます。

HTML.AllowedElementsでは、入力を許可したいHTMLタグを指定します。

上記の場合はアンカータグや改行タグは許可しますが、記述していないタグは全て取り除かれます。

<h3>foo</h3><br />
<span>bar</span><br />
<div>hoge</div><br />

上記のようなタグをユーザーが入力した場合、下記のように変換されます。

foo<br />
<span>bar</span><br />
hoge<br />

使い方の基本系は、先に書いた例のようにConfigオプションを指定して、許可したいタグや属性を決めていきます。

指定できるオプション はかなり多いので、マニュアルも参照してみてください。

以下、よく使いそうなものから幾つかピックアップして解説します。

・不許可にしたいHTMLタグを指定する

HTML.AllowedElementsでは、ホワイトリスト方式で許可するHTMLタグを指定しましたが、HTML.ForbiddenElementsを使えば、その逆のブラックリスト方式で不許可にするHTMLタグを指定できます。

HTML.AllowedElementsを使わない場合でも、scriptタグやembedタグなど動作に問題がありそうなタグは一通り除去してくれたりします。

ここに許可するHTMLタグをリストアップするのが大変な場合は、こちらを使った方が楽に指定できます。

$config->set('HTML.ForbiddenElements', array('table', 'tr', 'td', 'tbody'));

・特定のドメインへのリンクを禁止する

問題のあるサイトへのリンクを作らせたくない場合は、下記のようにブラックリストのドメインを指定することができます。

$config->set('URI.HostBlacklist', array('example.com'));

処理例は、下記のようになります。

<a href="http://www.example.com">こちらへ</a><br />
<a href="http://www.example.co.jp">こちらへ</a>

上記のHTMLタグが入力された場合、禁止しているexample.comの方のアンカータグが無効化されます。

一方、example.co.jpドメインは禁止していないのでそのまま通ります。

<a>こちらへ</a><br />
<a href="http://www.example.co.jp">こちらへ</a>

・リンク（アンカータグの使用）を禁止する

こちらは、もう少し厳しくなりHTMLタグ内にアンカータグを使わせたくないという場合です。

$config->set('URI.Disable', true);

結果は、URI.HostBlacklistを使った場合と同様に、アンカータグが無効化されます。

・リンクのターゲットを限定する

アンカータグ内で指定できるtarget属性を限定させるということも出来ます。

下記の場合は、targetに「_self」と「_top」しか指定できません。

$config->set('Attr.AllowedFrameTargets', array('_self','_top'));

例えば、新しいウィンドウを開く「_blank」を指定するとその属性値が丸ごと削除されます。

<a href="http://www.example.com" target="_blank">こちらへ</a><br />
<a href="http://www.example.co.jp" target="_top">こちらへ</a>

以下のように、アンカータグは使えますがtarget属性が削除されています。

<a href="http://www.example.com">こちらへ</a><br />
<a href="http://www.example.co.jp">こちらへ</a>

・指定できるクラス名を限定する

例えば予め適用できるCSSがあり、そこに定義されているクラス以外を指定させたくないということも出来たりします。

$config->set('Attr.AllowedClasses', array('foo', 'test'));

上記の場合は、class属性にfooとtestしか指定できません。

これ以外のクラス名を指定した場合は、class属性から削除されます。

・要素と属性の組み合わせを限定する

より厳密に利用できる要素と属性の組み合わせを指定したい場合は、HTML.AllowedAttributesを利用します。

$config->set('HTML.AllowedAttributes', array('span.style', 'a.href', 'p.id' ,'div.class'));

上記の場合は、spanタグにはstyle属性を、aタグにはhref属性を、pタグにはid属性を、divタグにはclassタグを指定できますが、これ以外の組み合わせは利用できません。

<span class="foo" style="color:#FF0000">test</span>
<div class="bar">hoge</div>
<p class="bar">fuga</p>

上記のように入力された場合、HTML Purifierで処理後は下記のように変換されます。

<span style="color:#FF0000;">test</span>
<div class="bar">hoge</div>
<p>fuga</p>

spanとpタグの中ではclass属性は使えないので削除され、divタグは組み合わせが正しいのでclass属性を指定できています。

紹介できたのは本の一例なんですが、組み合わせ方ではかなり強力なHTMLタグのフィルタを書く事が出来るかと思います。

HTMLタグをそのままユーザーに入力させたいけど、セキュリティを考慮したら利用を一部制限したい、というようなケースにうまく使えるかもしれません。

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

[PR]Windows から Mac への引っ越しツール！

[PR]光ファイバー/ADSLを楽しむなら「安心」「安全」の@nifty！

一昔前ならシステム構築の手間って膨大な時間と労力をつぎ込んで作るものってイメージがありました。

例えちょっとした機能変更でさえも、開発側の担当者は「それは多くの機能に影響を与えるからかなり時間がかかる」とか何かと理由を付けて拒む姿勢もよく見かけました。

まぁ、これは担当者が面倒くさがっていたり、品質や納期の観点からこの時期にその要求を受け入れるリスクを嫌っていってたのかもしれません。

しかし、今ではその労力というのはだいぶ軽減されてきています。

もちろん要件の規模によりますけど、その一部の機能を構築するのにも昔に比べたらはるかに楽になっているでしょう。

技術の標準化や多様なライブラリ、ネット上に発信される多くのノウハウ、IDEなど開発環境の進化などその理由は多々ありますが、そういった開発コストの低下の中で思うのは、システムを構築する手間っていうのはもはや構築をする側より仕様を決める側の方が大きく、ボトルネックってむしろ提案側になってしまっているのではないかと感じたりもします。

この話はもちろん「一般的な」って枕詞が付くので、世の中にない先進的なサービスを作ろうとした場合は、その限りではありません。

まぁ、世の中にない先進的なサービスってのは多くは、それを生み出す技術が根幹にあったりして、そういうのって提案側と構築側が一緒になってたりもするのですが、ボトルネックが発生する場所としては同じかもしれませんけど。

要は、こういった問題を解決するためのサービスを提供し、その仕様としてこういうシステムを作りたいってのがあった場合に、その要求を取りまとめる側の方が今や多くの時間がかかったりします。

これは、別に今に始まったことではありません。

ただ、昔のようにウォータフォールモデルのシステム開発手法を主としていた頃には、要件定義に多くの時間を割くものの、それが終わってしまえば後は製作をスケジュールどおりに進めていくというスタイルのため、要件定義の遅れは製作全体がシフトするということで済みましたが（プロジェクトとしては済みませんけど）、今や製作にかかる時間が短縮され、機能構築をスパイラルに進めていくようなやり方を取ることが多くなってきた中で、要求が出てこないというのは、個々の製作が始まっているため、問題が大きくなりがちです。

機能ごとに要件決めとその構築を短い期間でまわしていくことになると、そのイテレーションの中では、都度提案側から要求を貰うことになりますが、提案側から出てくる要求というのは、構築期間より長く時間がかかることが多くあります。

元々、要件定義自体は開発プロセスに関わらず多くの時間が費やされます。

要求そのものを取りまとめることになるので当然なのですが、開発プロセスの変化に要求をまとめるプロセスが追いつけてない事は多いのではないでしょうか。

この要求をまとめるプロセスというのは、業務プロセスをモデル化するということもそうですし、具体的にITを頼って何をしたいのかという目的設定もそうですし、じゃあそのシステムっていうのはどういったもので、誰がどんなシーンで利用するものなのかっていうのもそうです。

業務プロセスをモデル化するってのは、過大や要求からシステム部門が作業を請け負うことも出来るでしょうが、もっと根本的な目的設定とかどんなシステムやサービスを作りたいのかってイメージが頭の中に思い描けてなかったりするのは、開発プロセス上では結構大きな問題だったりします。

IT自体がコモディティ化した今は、それを取り扱う人は専門家だけではありません。

人事や総務などの管理部門にいる人や、そのサービスを望んでいるが技術には全く詳しくないという人まで、「こういったものを作りたい」という漠然としたイメージしか持ってない人が提案側のメンバーとして入っています。

提案書の中には、たどたどしい感じで画面設計や状態遷移や機能要件などが盛り込まれていますが、実際それを具体的に頭の中でイメージできているのは、あまりいないのではないでしょうか。

要は、実際に動かしてみないとわからない、という人が多いということです。

あとは、体制の話で「取り合えずチームで検討します」と言って決定までに1週間かかるとか。

こういった状況に追い込まれないためにも、提案側との要件決めには幾つか留意しておくことがあります。

・ 何を解決したい（作りたい）のかということを双方ちゃんと理解する

提案側から出された要求書は大体システムありきで書かれていて、それがなんの役に立つのかってことが頭の中から飛んでたりもします。

一昔前なら開発側で偏った思考によって起きる問題が今や提案側で起きてたりもします。

・ 最低限作りたいものは何なのかを理解しておく

提案側は、色んな機能を詰め込みたがりますが、それによって何時までもリリースできないプロジェクトを続けたり、時間がかかることで当初の目的がずれてくることもあるので、最低限何を実現してそのためにどんな機能が必要なのかをちゃんとヒアリングしておいた方がよいです。

もしそれが出来たなら、その時点で一旦リリースしてしまうということで、運用を開始することで得るものも数多くあったりします。

・ 提案された設計はゼロベースで考え直す

一旦向こうから提案された画面イメージとかは忘れて考え直すのも視野に入れてた方が良かったりします。

目的設定がずれていたら、何も解決しないシステムを作るだけになってしまいますので。

・ 共有イメージを持っておく

今や似たようなサービスというのは数多く存在するので、事前に「このサイトみたいなレイアウトですかね？」とか、この機能というのは「このサイトのこの部分のようなイメージですか？」ってことを共有しておくと楽になります。

・ なるべく早く動くものを共有しておく

提案側にある漠然としたイメージをより具体化するためにも、早めに動くものを見せておいた方がよいでしょう。

これは、裏側が張りぼての機能がない状態でも問題ありません。

気にされるのはだいたい画面上のUIであり、裏側の状態遷移やロジックというのは気にされません。（というか「そこは良いようにやってよ」ってまかせっきりになってたりもしますので）

・ 決定権を持つ人を巻き込んでおく

ボトルネックになるのが偉い人へのお伺いだったりするので、予めそういった決定権を持つ人も巻き込んでシステムレビューを進めた方が話が早かったりします。

仕様の決定、製作、確認（確定）と製作の過程で間に2つの確認事項が含まれるのでそれに割かれる時間というのは馬鹿になりません。

・ システム構築には時間がかかるという概念を払拭しておく

もちろん、全体を通しては長い時間がかかるプロジェクトにはなりますけど、先に書いたように機能一つ一つにかかる時間はそれほど多くはなくなってきています。

ボトルネックが提案側に移ってきているので、さっさと作って見せたところで仕様確認に時間がかかり、先に進めなくなる事態に陥ることも多々あります。

ある程度の目処を早めに伝え、提案側にタスク期限を明確にしておくことでボトルネックの解消につなげることもできるかもしれません。

開発の主導者が変遷していく中で、それに適した開発プロセスというものも求められてきていますし、問題が発生するポイントも変化してきています。

サービスの構築は、システム担当者だけでということも行かない時代になってきていますし、それは別に面倒なことが増えたというよりは、より多くの可能性を広げているとも捉えられます。

ただ、構築が楽になったとは言っても話が二転三転されたりすると、納期だけでなく開発側にも大きなストレスとなりますので、提案側と構築側のギャップを埋めてうまく進めていく仕組みづくりというものにも気を使わないといけないと感じたりします。

[PR]ビジネスの最前線で勝ち残るための必要な情報が凝縮　日経ビジネス

[PR]集客にお困りの方は必見。Yahoo! JAPANが提案する集客アップの方法。

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

「[お名前.com] サービスを構築するまでに行ったサーバー設定作業もろもろ 」の続き。

次は、メール関係の設定です。

Postfixを使ってSMTP-Authによるメール送信とメール転送設定を行います。

・ 必要なパッケージのインストール

メール送信には、Postfixを使います。

また、SMTP-Authに対応するためにcyrus系のパッケージを追加インストールします。

# yum install postfix.x86_64
# yum install cyrus-sasl-devel.x86_64
# yum install cyrus-sasl-plain.x86_64
# yum install cyrus-sasl-md5.x86_64

・ main.cfファイル編集

メールを送信するためのPostfix設定作業を行います。

なお、メールのリレー先のサーバーなど、お名前.com用の設定が混じってます。

下記、詰めて編集箇所のみを書いてますので、実際の設定ファイル（/etc/postfix/main.cf）内から、適宜該当箇所を修正してください。

また、設定箇所が無い場合は追記します。

myhostname = smtp.example.jp
mydomain = example.jp
myorigin = $myhostname
inet_interfaces = all
#inet_interfaces = localhost
mydestination = localhost.$mydomain, localhost, $myhostname
mynetworks = 127.0.0.0/8
home_mailbox = Maildir/

#virtualmailbox setting
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:6001
virtual_gid_maps = static:1000
virtual_mailbox_domains = hash:/etc/postfix/virtual_domain_maps
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

#smtpauth setting
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions =
   permit_sasl_authenticated,
   permit_mynetworks,
   reject_unauth_destination,
   reject_invalid_hostname,
   reject_non_fqdn_recipient,
   reject_non_fqdn_sender,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   reject_unauth_pipelining
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd

#ssl
smtpd_use_tls = yes
smtpd_tls_key_file = /etc/pki/tls/certs/mail.pem
smtpd_tls_cert_file= /etc/pki/tls/certs/mail.pem
smtpd_tls_loglevel = 1
smtpd_tls_recived_header = yes
smtpd_tls_session_cache_timeout = 3600s
broken_sasl_auth_clients = yes

relayhost = [mailgw.vps.gmoserver.jp]

・ vmailユーザーの作成

main.cfファイルの「#virtualmailbox setting」の項目で記載しているvmailユーザーを作成します。

なお、ユーザーIDとグループIDは予め指定して作成します。

# groupadd -g 1000 vmail
# useradd -u 6001 -g 1000 -d /var/vmail -s /sbin/nologin vmail

・ virtual_alias_maps、virtual_domain_maps、virtual_mailbox_mapsファイルの作成

main.cfファイルの「#virtualmailbox setting」の項目で記載しているvirtual_alias_maps、virtual_domain_maps、virtual_mailbox_mapsの3ファイルを作成します。

virtual_alias_mapsファイルでは、バーチャルユーザーのメールの転送設定（メールのエイリアス設定）を行います。

##### virtual email alias list #####
webmaster@example.jp itboy.org@gmail.com

上記のように設定することで、webmaster@example.jp 宛のメールを別の個人のメールアドレスへ転送することができます。

virtual_domain_mapsファイルでは、バーチャルドメインのリストを記述しておきます。

##### virtual domain list #####
example.jp OK

最後のvirtual_mailbox_mapsでは、バーチャルユーザーのメールボックスのパスを指定します。

##### virtual email mailbox list #####
webmaster@example.jp example.jp/webmaster/Maildir/

ファイルの作成後は、postmapコマンドを利用してDBファイルを作成します。

# postmap virtual_alias_maps virtual_domain_maps virtual_mailbox_maps

これで、virtual_xxxx_maps.dbファイルが作成されます。

・ 証明書および秘密鍵の作成

main.cfファイルの「#ssl」の項目で設定した独自の証明書と秘密鍵ファイルを作成します。

# cd /etc/pki/tls/certs
# make mail.pem

下記のように証明書に埋め込む情報を幾つか質問されるので、適宜情報を入力します。

Country Name (2 letter code) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:Shibuya
Organization Name (eg, company) [My Company Ltd]:Foo
Organizational Unit Name (eg, section) []:Bar
Common Name (eg, your name or your server's hostname) []:example.jp
Email Address []:webmaster@example.jp

・ master.cfファイルの編集

Postfixのもう1つの重要な設定ファイルであるmaster.cfファイルを編集します。

master.cfファイルでは接続方式やデーモンの挙動を定義するファイルになっています。

submission inet n       -       n       -       -       smtpd
  -o smtpd_enforce_tls=no
  -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#cyrus     unix  -       n       n       -       -       pipe
#  user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}

・ smtpd.confファイルの編集

SASLの設定ファイル「/usr/lib64/sasl2/smtpd.conf」を編集して、SASLのパスワードファイルを利用するように設定します。

pwcheck_method: auxprop

・ ユーザーとパスワードの設定

メールアカウントとそのパスワードを設定します。

# saslpasswd2 -u example.jp webmaster

メールアカウントが作成されたか確認しておきます。

# sasldblistusers2
webmaster@example.jp: userPassword

ユーザーリストを作成すると/etc/sasldb2ファイルが出来上がるので、権限を変更しておきます。

# chown root:postfix /etc/sasldb2

・ デーモンの起動

一通り設定が終わったのでPostfixとSASLのデーモンを起動します。

# /etc/init.d/postfix start
# /etc/init.d/saslauthd start

自動起動するように設定するのもお忘れなく。

# chkconfig --level 3 postfix on
# chkconfig --level 3 saslauthd on

・ メールサーバーへの接続確認

最後に、メールサーバーへの接続確認を行います。

まずは、telnetを使った接続・認証テストです。

# telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 smtp.example.jp ESMTP Postfix
EHLO localhost
250-smtp.exapmle.jp
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN CRAM-MD5 LOGIN DIGEST-MD5
250-AUTH=PLAIN CRAM-MD5 LOGIN DIGEST-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH CRAM-MD5
334 PDIxNzY5NTM1MTUuMTM1MjY4MzdAc210cC5pbmRvZy5qcD4=
d2VibWFzdGVyQGV4YW1wbGUuanAgN2FjOGIxNGQ5YzQxZGUzZTI4MDc3ZDYxOTlkYzgzMzI
235 2.0.0 Authentication successful

※ ハイライト箇所は手動で入力した箇所です。

ちゃんと認証が成功しました。

CRAM-MD5による認証方法（MD5ダイジェストの作成）に関しては、下記のサイトを参考にさせていただきました。

telnetでsmtp-auth ＠ Kung Noi

コードは、「AUTH CRAM-MD5」と入力した後に返ってくる「334 XXXXX」の部分（334以降）を指定します。

なので、2つ端末を開いて一方でtelnet接続し、もう一方で上記サイトで紹介されているPerlスクリプトのコード部分に埋め込んで結果を貼り付けたりすればよいかと思います。

次に、PHPからメール送信テストを行います。

SMTP-AUTHを通して、メールを送信するためPEARパッケージを使います。

# pear install Mail
pear install Net_SMTP

メールを送信するPHPプログラムは、下記のサイトを参考にしました。

How to Send Email from a PHP Script Using SMTP Authentication ＠ about.com

<?php

require_once "Mail.php";

$from = "webmaster <webmaster@example.jp&>";
$to = "Foo <foo@bar.com>";
$subject = "Hi!";
$body = "hello world";

$host = "smtp.example.jp";
$username = "webmaster@example.jp";
$password = "HogeHoge";
$port = "587";

$headers = array ('From' => $from,
  'To' => $to,
  'Subject' => $subject);
$smtp = Mail::factory('smtp',
  array ('host' => $host,
    'auth' => true,
    'port' => $port,
    'username' => $username,
    'password' => $password));

$mail = $smtp->send($to, $headers, $body);

if (PEAR::isError($mail)) {
  echo("<p>" . $mail->getMessage() . "</p>");
} else {
  echo("<p>Message successfully sent!</p>");
}

長くなってしまいましたが、これで一通り設定完了です。

[PR]マルチドメイン無制限・大容量100GB・月額1,365円～ ⇒ 共用サーバー SD

[PR]世界にたった一つ、あなただけのドメインを登録しよう！

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

ひょんなことからお名前.comのVPS環境に触れる機会があったので、その上でシステムを作るまでに行ったサーバー設定作業のメモを残しておきます。

システム自体は、PHPアプリが動くことを想定しています。

お名前.com用の設定を基本としていますが、その他のサーバーでも応用できるかと思います。

なお、記事が長くなってしまったので2回に分割しています。

後半は、メール設定作業 をまとめています。

・ OSを変える

デフォルトはCentOS5.3だったのですが、CentOS5.5へ（最終的にはyum updateで5.7へ）変更しました。

OSが古いというよりは、デフォルトの5.3環境の場合、お名前.comのコントロールパネルが結構権限を握っていて自由度が低かった、というのが変更理由です。

Apacheの設定ファイルも別の場所に用意されていてDocumentRootも変更できないような感じになっていましたので。

まぁその分、iptablesの設定やメール設定とかはコントロールパネルからできなくなるので、運用の手間は増えてしまいますが。

コマンドラインからガリガリと設定ファイル変更するのは苦手という場合は、デフォルトのOSのまま利用していた方がよいかと思います。

OSの変更は、コントロールパネルから行います。

※ 必要があれば、事前にちゃんとバックアップを取っておきましょう。

・ パッケージのアップデート

取り合えず、

# yum -y update

で、全パッケージをアップデート。

これによりCentOS release 5.7 (Final)へアップグレードされます。

# more /etc/redhat-release
CentOS release 5.7 (Final)

・ 必要なパッケージを追加インストール

PHPやPostgreSQLやvsftpdなど。

この辺は、サービスで利用したいパッケージを適宜インストールします。

# yum install php53.x86_64

あと、PHPでPEARを使いたいので追加インストール。

ただし、x86_64のパッケージが用意されていないみたいなんで、下記のようにnoarchのPEARをインストールした後に強制的にアップグレードしました。

# yum install php-pear.noarch
# pear upgrade --force PEAR

途中でereg系の関数を利用してエラーが出まくりますが、アップグレード自体は完了します。

# pear list
Installed packages, channel pear.php.net:
=========================================
Package          Version State
Archive_Tar      1.3.8   stable
Console_Getopt   1.3.1   stable
PEAR             1.9.4   stable
Structures_Graph 1.0.4   stable
XML_RPC          1.5.0   stable
XML_Util         1.2.1   stable

・ yumのアップデート除外設定

運用開始後は、何でもかんでもパッケージをアップデートしてたらバージョンアップによってトラブルが起きたりするので、アプリに蜜に連携するパッケージを取り合えずアップデート対象外にしおきます。

exclude=kernel* php* httpd* postgresql*

・ yumの自動アップデート設定変更

とはいえ、毎回新しく出たパッケージを1つずつ確認していくのも手間なんで、関係なさそうなパッケージは自動アップデート（実際には、パッケージのダウンロードだけで適用させませんが）を設定しておきます。

まず、yum-updatesdパッケージをインストール。

# yum-updatesd.noarch

次に、設定ファイルを編集します。

# yum updateの実行間隔（秒）
run_interval = 86400
updaterefresh = 6000

# アップデートがあった場合の通知方法（E-Mail）
emit_via = email
email_to=webmaster@example.jp
email_from=yum-updatesd@localhost
smtp_server=localhost:25

# 更新があった場合、関連するパッケージも含めてダウンロード（ただし勝手にアップデートしない）
do_update = no
do_download = yes
do_download_deps = yes

最後に、yum-updatesdのデーモンを起動。

# /etc/init.d/yum-updatesd start

・ logrotate.conf設定変更

デフォルトだと4週分しかログが保存されないので変更（24週分保存へ）

rotate 24

あと、/var/log以下でほっとくと大容量になってしまうログファイルを幾つかローテーションの対象へ追加。

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron /var/log/btmp /var/log/lastlog /var/log/wtmp {
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
        /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

・ SSH設定変更

お名前.comの場合、デフォルトの状態で作業用ユーザー（vpsXXXXXXXX）が作られてたりしますが、ユーザー名が覚えにくいので、別のユーザーを追加しそのユーザーSSH接続できるようにします。

# useradd -m -d /home/hogeuser -s /bin/bash hogeuser
# passwd hogeuser

続いて、セキュリティを考慮してSSHできるユーザーを限定し、利用するポートを変更しておきます。

（ポートを変えるだけで単調なアタックをかなり防げたりもします）

Port 10022
AllowUsers vpsusername hogeuser

※ iptablesの設定が済んでいないので、この時点でSSHDを再起動するとサーバーへ接続できなくなります。

より、サーバーをセキュアにするなら公開鍵認証方式 を取るのもよいかもしれません。

・ FTP設定変更

標準のCentOS5.3だとProFTPDを利用しているのですが、個人的な好みでvsfptdを利用します。

OSユーザーを使うのではなく、バーチャルユーザーを使ってFTP接続させるように設定を変更します。

設定方法は、以前に書いた「OS上にいないバーチャルユーザーを使ってFTP接続する 」を参照。

なお、FTP接続はパッシブモードで30000番から31999番ポートまでを利用しています。

設定方法は、「FTPのアクティブモードとパッシブモード ＋ vsftpdでの設定方法 」を参照。

・ iptables設定

お名前.comの場合、CentOS5.5へ変更してもデフォルトで幾つかファイアーウォールの設定が既にされていたりもするんですが、SSHのポートを変えたり、FTP用のポート（30000 ～ 31999番ポート）を開放をしておきます。

あと、後述するメール設定のためにサブミッション・ポート（587）も許可しています。

# iptables -A INPUT -m state --state NEW -m multiport -p tcp --dports 20,21 -j ACCEPT
# iptables -A INPUT -m state --state NEW -m multiport -p tcp --dports 30000:31999 -j ACCEPT
# iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 10022 -j ACCEPTiptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPTiptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
# iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT

設定が終わったら確認し、不要なポートを削除しておきます。

# iptables -L --line-number
Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere
2    REJECT     all  --  anywhere             127.0.0.0/8         reject-with icmp-port-unreachable
3    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
4    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
5    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:smtp
6    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http
7    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:pop3
8    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https
9    ACCEPT     tcp  --  anywhere             anywhere            state NEW multiport dports ftp-data,ftp
10   ACCEPT     tcp  --  anywhere             anywhere            state NEW multiport dports 30000:31999
11   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:10022
12   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http
13   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https
14   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:submission

Chain FORWARD (policy DROP)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere

今回、SSHのポートを変更していますので22番ポートを削除しておきます。

iptablesのフィルタ削除は、下記のように左端に表示される番号を指定して削除できます。

# iptables -D INPUT 4

設定が完了したら、iptablesの設定を保存しておきます。

# service iptables save

念のために、iptablesのデーモンを再起動してフィルタが正しいかと、別の端末からSSHやFTPでサーバーへ接続可能かを確認しておきます。

接続できない場合、SSHDやvsftpdの設定かiptablesの設定に誤りがある可能性があります。

全ての端末を閉じてしまうと、二度とサーバーへ接続できないという自体にもなりかねないので注意が必要です。（実際、やってしまいましたし・・・）

・ デーモンの自動起動

追加でインストールしたパッケージや必要なデーモンを自動起動するように設定しておきます。

# chkconfig --level 3 vsftpd on
# chkconfig --level 3 httpd on
# chkconfig --level 3 rsyslog on

・ 不要なデーモンの停止

さっきとは逆に、不要なデーモンが起動しないように停止しておきます。

# chkconfig mcstrans off
# chkconfig lvm2-monitor off
# chkconfig netfs off
# chkconfig rawdevices off
# chkconfig iscsi off
# chkconfig iscsid off

この辺は、環境によって異なると思いますので、chkconfig --listで結果を見て不要なものを適宜停止していきます。

余談にはなりますけど、iscsiとiscsidデーモンを起動していたら/var/log/brcm-iscsi.logに毎秒ごとに下記のようなエラーが吐き出されてかなり大きなファイルとなっていました。

ERR [Sun Nov 20 22:17:08 2011]NIC_NL waiting binding to NETLINK_ISCSI socket
ERR [Sun Nov 20 22:17:09 2011]NIC_NL waiting binding to NETLINK_ISCSI socket

実害は無いと思ってたんですが、上記のような理由から停止しました。

・ sysstatの設定

サーバーに異常があったときにその際の状況を確認したいという場合がありますので、sarコマンドでCPUの統計を取れるようにしておきます。

# yum install sysstat.x86_64

デフォルトだと10分ごとに統計が取られますが、もう少し間隔を短くしたいのでCronで定期実行されている設定を変更します。

# run system activity accounting tool every 5 minutes
*/5 * * * * root /usr/lib64/sa/sa1 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

コマンドの使い方などについては「サーバー管理で知っておきたいコマンドあれこれ。 - sysstat編 - 」を参照。

・ logwatchの設定

サーバー上には大量のログが出力されますが、それを1つずつ確認するのはかなり手間になります。

なので、Logwatchを使って問題のありそうなログのレポートを送ってもらうようにします。

# yum install logwatch.noarch

次に、レポートの詳細やメールの送信先を設定します。

MailTo = webmaster@example.jp
Detail = Med

ログの見方などは、「Logwatchでサーバー上のログを集約する 」を参照。

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

[PR]【早い者勝ち！】　.com／.net／.jp　ドメイン取るならお名前.com

[PR]格安固定IPが【５分で発行】＋【初期無料】＋【２ヶ月無料体験】

うまく説明するのが難しいので、一番はデモ を見てもらうことでしょうか。

（この記事の最後にもデモを用意しています）

リスト表示をしていてその順番を入れ替えたいときに、古典的なやり方をしようとしたら、プルダウンメニューで順番に選択して言ったり、ボタンで画面遷移を繰り返しながら順番を入れ替えるという方法があるかもしれませんが、jQuery UIを使えば簡単にスタイリッシュな並び替え画面を実装することが出来ます。

まず始めに、jQuery本体とjQuery UIをロードできるようにしておきます。

自サーバーに無い場合は、Google code上にホストされているものを利用してもよいかもしれません。

最も簡単な使い方は、下記のようにulタグにidを指定して実際に動かすためのliタグを記述します。

<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<style>
    #sortable { list-style-type: none; margin: 0; padding: 0; width: 300px; }
    #sortable li { margin: 0 3px 3px 3px; padding: 0.4em; padding-left: 1.5em; font-size:
1.4em; height: 18px; border: solid 2px #ccc; }
</style>
<script type="text/javascript" src="js/jquery/jquery.min.js"></script>
<script type="text/javascript" src="js/jquery/jquery-ui.min.js"></script>
<script>
    $(function() {
        $("#sortable").sortable({ items: 'li', cursor: 'move', opacity: 0.6 });
        $("#sortable").disableSelection();
    });
</script>

<ul id="sortable">
    <li id="list-1">Item 1</li>
    <li id="list-2">Item 2</li>
    <li id="list-3">Item 3</li>
    <li id="list-4">Item 4</li>
    <li id="list-5">Item 5</li>
</ul>

</body>
</html>

実際にSortableの機能を制御しているjQueryスクリプトは、ハイライト表示している4行のみです。

ulタグに指定するidは、jQueryの制御スクリプト内に指定している「$("#id名")」部分と一致していれば何でもかまいません。

liタグの各々にidを指定しているのは、並べている状態をシリアライズしてURL用のパラメータとして取得するためです。（詳しくは後述）

Sotableには幾つかのオプションがあります。

上記で指定しているのは、「items」で動かす対象のDOM要素（デフォルトでもliタグは自動認識してくれますが）、cursorで要素をドラッグしたときのマウスカーソルのスタイル、opacityで動かした際の透明度を指定しています。

なんとなく、スタイル系の変更はCSSで直接した方が早いような気もしますが。

この他にも多くのオプションや、動作時のイベントをフックさせることも出来ます。

詳しくは、下記のサイトが参考になるかと思います。

jQuery UI API 1.8.4 日本語リファレンス > Interactions > Sortable ＠ Stack Trace

上記の例では、liタグを動かす対象にしましたが、その他にもdivタグやtableタグでも動かすことが可能です。

<table id="sortable">
    <tr><td>Item 1</td></tr>
    <tr><td>Item 2</td></tr>
    <tr><td>Item 3</td></tr>
    <tr><td>Item 4</td></tr>
    <tr><td>Item 5</td></tr>
</table>

ただし、divタグは自動で要素を認識しえくれますが、tableタグを使う場合は、itemsオプションにtrを指定する必要があります。

（じゃないと、テーブルごと動いてしまいます）

$("#sortable").sortable({ items: 'tr' });

簡単に導入できるので、既存のサイトでもそんなに手を加えることなく変更することも可能ではないでしょうか。

せっかくなので、デモサイトに少し手を加えてソート対象要素の追加・削除や送信時のパラメータ取得ができるサンプルコードを書いてみました。

- リストの並び替え、追加、削除、送信（するためのパラメータ取得）をするデモ

リストをドラッグ＆ドロップで並び替えるだけでなく、「Add Item」のリンクからリストを追加できます。

削除はリストの右脇にある「×」ボタンで行います。

「Send Data」のリンクをクリックすると、リストの状態をシリアライズしてURLパラメータに変換してくれます。

実際には、送信先にこのURLを付け加えれば状態を保存するということも出来るでしょう。

ソースコードは下記のようになります。

<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/themes/ui-lightness/jquery-ui.css">
<style>
    #sortable { list-style-type: none; margin: 0; padding: 0; width: 400px; }
    #sortable li { margin: 0 3px 3px 3px; padding: 0.4em; padding-left: 1.5em; font-size: 1.4em; height: 18px; }
    #sortable li span.ui-icon-arrow-4 { position: absolute; margin-left: -1.3em; }
    #sortable li span.ui-icon-circle-close { position: absolute; margin-left: 330px; }
    span.ui-icon-plusthick, span.ui-icon-transferthick-e-w { float:left; }
    a.link { cursor: pointer; }
</style>
<script type="text/javascript" src="js/jquery/jquery.min.js"></script>
<script type="text/javascript" src="js/jquery/jquery-ui.min.js"></script>
<script>
    $(function() {
        for (item_cnt = 1; item_cnt < 6; item_cnt++) {
            addItem(item_cnt);
        }
        $("#sortable").sortable({ items: 'li', cursor: 'move', opacity: 0.6 });
        $("#sortable").disableSelection();
        $("#addItem").click(function() {
            addItem(item_cnt);
            item_cnt++;
        });
        $("#sendData").click(function() {
            $("span.param").text($("#sortable").sortable("serialize"));
        });
    });
    function addItem(cnt) {
        $("#sortable").append('<li id="list-' + cnt + '" class="ui-state-default"><span class="ui-icon ui-icon-arrow-4"></span><span class="ui-icon ui-icon-circle-close delete_item"></span>アイテム' + cnt + '</li>');
        $(".delete_item").click(function() {
            $(this).parent().remove();
        });
    }
</script>
</head>
<body>
<ul id="sortable">
</ul>
<span class="ui-icon ui-icon-plusthick"></span><a id="addItem" class="link">Add Item</a>
</div>
<div>
<span class="ui-icon ui-icon-transferthick-e-w"></span><a id="sendData" class="link">Send Data</a>
<br />
<span class="param"></span>
</body>
</html>

シリアライズの部分で少しはまったので補足しておくと、動かす対象のliタグのid名で「id名-数値」のようにしておくことで、パラメータは「id名=数値」というように分割して生成されます。

意図的にURLのキーを変更したい場合は、

$("#sortable").sortable("serialize", {key:'order[]'})

のように、第2引数の「key」にキー名を指定します。

こうすることで、

order[]=1&order[]=2&order[]=3&order[]=4&order[]=5

というようなURLを生成することができます。

jQuery UIのマニュアルを見ると、ポートレットのような機能を作ることも出来るみたいなので、用途の幅は結構広いかもしれません。

[PR]格安固定IPが【５分で発行】＋【初期無料】＋【２ヶ月無料体験】

[PR]送料無料でご自宅まで集荷いたします。eBOOKOFFのらくらく買取サービス！

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

このタイトルは、先日読んだ「プログラマが知るべき97のこと 」の74番目に登場します。

そこには、下記のようなことが書かれています。

私はテクニカルリーダーという立場になったばかりの頃、自分の役目は、プロダクトマネージャやビジネスアナリストから来るバカげた要求をはねつけ、自分たちのチームの素晴らしソフトウェアを守ることだけと思っていました。何か要求が来た時には、それを「受け入れるべきもの」ではなく、常に「却下するもの」と捉え、その前提でほとんどの会話を始めていたのです。
（略）
「イエス」から始めるようにする、という簡単な変化だけで、私の仕事への取り組み方は劇的に変わりました。わかったのは「イエス」という返事の仕方にも多くの種類があるということです。

こういったことを思い当たる人、または周りにいるって人は多いのではないでしょうか。

IT部門に勤めていると、絶えず顧客からの要求にさらされます。

その中には、聞くに堪えないものも数多くあり、一通りの話を終える前にその話を握りつぶすかのように反論を始めたりもします。

しかし、そんな話の中にでもユーザーは目的を持って話しており、論点がずれていたりはするものの確かに解決すべき課題というのが見えてくることも多々あります。

立場の違いから、言われたことは受け入れざるを得ないというエンジニアも数多くいると思います。

そういった人から見れば、要求に「イエス」ということへのリスクというもの強く認識しているでしょう。

要求を受け入れることで面倒な仕事は増えるは、何らかの変化をもたらすことで実行リスクが大きくなるは、スケジュールがタイトな中でリソースは不足するは、丸投げされるは、とネガティブな要素しか考えられなくなってしまったりもします。

過去に一度痛い経験をしてしまうと、もう二度と簡単に「イエス」なんて言うもんかという態度も取りがちです。

そんな経験があるかないかはわかりませんが、まずは「ノー」と突き放す人は自分たちの領域を守ろうとえらく保守的になってしまっていたりもします。

「ノー」という答えの中には、「それは自分たちの仕事ではない」という意味が含まれていることがあります。

しかし、自分たちがノーと突き放したその要求は誰が解決するのでしょうか。

確かに、しかるべきところがまずは要件を固めるべきという問題もあります。

システム化の施策の中で解決を図ろうにも、IT部門で考える前にその業務であったりルールであったりを整備する担当部門というものの存在があり、そっちで検討してきてから話しましょうね、というような意味合いでノーと答える人もいるのでしょう。

「ノー」という人の中には、ノーといった理由を示さないでただ拒否する人や、たいしたリスクではないのだけど、さも致命的であるかのように拡大解釈して理由を付けるという人もいます。

「客先で資料を参照したいのですが」と聞かれれば「セキュリティの関係でそれは無理です」と答え、「じゃあオンラインストレージでファイル転送とか出来ませんか？」と聞かれれば「予算がありません。おたくの部門で費用を持ってもらえるんですか？」ってな具合で、押し問答を繰り返したり。

頭ごなしに「ノー」と言ってしまうとそのユーザーの要求は行き場を失い、ただただその人の心のうちで消滅するしかなくなってしまいます。

それが本当に会社にとって解決すべき重要な要求や課題であったとしても。

情報システム部門の役割は、自社の業務ドメインを認識し、そこでの問題や変化に対してITを投入して管理していくというものがあるでしょうが、自分たちの領域を守ろうとするあまり、そこに踏み入る勇気を失っていたりもします。

ITのプロ集団であるはずなのに、ITによる解決案さえも出さないのは悲しいことではありますが。

ノーと答えることで「情報システム部門がノーと言ったのでダメになった」という変な軋轢も生まれます。

まぁ、イエスと答えると、「じゃあ、後は情報システム部門でよろしく」と丸投げされたりもするので、それはそれでユーザー部門への疑心が募る結果となり、そのバランスの取り方も難しい場合がありますが。

一昔前では、システムは魔法のように思われていたのかもしれません。

そして、餅は餅屋にのように魔法は魔法使いにと情報システム部門に頼っておけばどうにかなるという考えの人も多かったのでしょう。

現在では、ITサービスはコモディティ化しており、魔法使いとしての威厳や持ち味も失われつつあります。

その過去にいいように扱われた苦い経験からか、ユーザー部門と情報システム部門との信頼関係も失われつつあるように思えます。

「イエス」と答えてきた過去があるがその報いが無いからこそ、現在は「ノー」と答えたくなるのかもしれません。

または、「イエス」と答えるだけの力を持ち合わせなくなってしまったということも考えられます。

ただ、それは「イエス」の答え方にもよるもので、きちんと解決すべき課題に対して要求する部門とシステム部門とでどのような体制で取り組んでいくべきかという検討が必要でしょう。

その中には、業務担当部門でしか考えることが出来ないプロセスであったり、解決手法というものが存在します。

お互いがその問題を解決するためにどのように取り組んでいくべきかというのを、双方の役割を明確にしながら進めていけばいいわけで、その一部を担うことに対して「イエス」と答えればいいわけです。

まさに「イエス」にも様々な種類があるということです。

ユーザーの要求というのはいきなりゴールかのように見えて、実際は方向違いでスタートを切っていることも多々あります。

その要求の向こうにある本質的な課題を聞き、別の手段からのアプローチを提供すれば解決する問題かもしれません。

「イエス」から始めれば道は開けますが、「ノー」から始めれば始まりもしません。

「Yes or No」の二極化した答えしかないわけではありません。

その答えはそんなに単純なものではなく、ずっと複雑であり紐解かなくてはならないものでしょう。

それはお互い認識しつつも、双方が自分たちの利益を守るためのカードとしてしか使ってないようであれば本末転倒ではあります。

そのきっかけである「イエス」という回答が望まれるのだと感じます。

[PR]独立・開業・起業のサポート情報の検索・資料請求サイト「アントレnet」

[PR]忙しい人に朗報！【便利な出前】ネットでらくらく注文♪

[PR]集客にお困りの方は必見。Yahoo! JAPANが提案する集客アップの方法。