エスカレーターの作法

週末に京都まで行ってきた。
ちょっと面白かったのはエスカレーターの乗り方。

東京だと、右側を空ける。

右のレーンに入った人は何があっても歩いて上っていくべし。
通勤時間帯、それも長めのエスカレータでの隊列は見事（異様）なものだ。

西日本は、左側を空けるものだと思っていた。
実際に福岡も神戸もそうだった。

しかし、京都。これがばらばら。

右側が空くケースが多かったけど、きれいに左側が空くケースもあった。
そもそもレーンがあいていないことが多かった。

古都まで来て、あわてて歩くんじゃないよ。とか、そんなことなのかな。

すべてのタスクを割り当てる

すべてのタスクに担当者を割り当てることが重要だ！

当たり前だ！

なのですが、この当たり前がしばしば実行されない局面があります。
それは、タスクの依頼がチームをまたがるときです。

たとえば、業務設計を担当するチームが、インフラ系のチームにテスト環境の構築を依頼するとします。
こんな風になったりしませんか？

「xx日までに、テスト環境を作っておいて欲しい。以上！」。

そして、ふたを開けると、インフラ系チーム内でうまくタスクが展開できておらず、環境が完成してない、
という自体になったりします。

業務とインフラくらい分野が違うと、確かに頼みにくいのです。だってわからないから。
どうやって何を依頼したらいいかわからない。でも、こっちも相手も忙しそう。とりあえず投げちゃえ。

ってことになりがちです。本当はこう頼むべきでした。

「xx日までに、テスト環境を作っておいて欲しい。WBSもしくはタスクリストができたら確認したいので見せて欲しい。」

わからないなりに、タスクが洗い出されていて、担当が割りあたっていることを確認しないとね。
もちろん、こまめに進捗も確認します。

プロジェクト全体のタスクが見えるようになっていて、いつ誰がなにをやっているかが、簡単に（これ重要）
見えるようになっていれば、こんな苦労も少しは減るかもしれません。

今日の話はつまらないな。。。内容が当たり前だ！

環境依存の設定ファイルとかの話

環境に依存する設定情報の取り扱いって、結構面倒。
開発機と本番機で違う設定値、開発機の間でも違う設定値、いろいろあります。

設定とそれに関連したアプリケーションのパッケージングで注意しておくべきこと（というかハマッタこと）を

あげておきます。

1.アプリケーション一式（設定ファイル含む）は、どの環境にもって行っても動くような構成にする。

　（Webアプリケーションなら、WARやEARのこと）

2・設定ファイルの設定値で、アプリケーション開発チームで決められるものと、そうではないものを意識する。

　機能と機能外という観点でも良い。　
　アプリケーション開発チーム側で決められないものは、設定ファイルに直書きしないで済むように考慮する。

1について

大きなプロジェクトになるほど、開発機も本番機も数が多いです。　

間に「ステージング」と呼ばれるサーバもあるかもしれません。 開発機が10台なんてざら。そこで数十のWebAPサーバのインスタンスが上がってます。

これら複数のサーバについて、同じアプリケーション一式をもっていけば動く状態にするよう頑張りましょう。

何が何でも、という勢いでやるべき。頑張った分報われます。

環境によってリリース物を変えると、アプリケーションのビルドとリリース時にかなり苦労します。　

想像以上に面倒で不都合、と言っておきます。 　

環境に依存するところはどうするか？

それは環境側で持ってもらうべき。　

例えば、環境変数に外出しにして、WebAPサーバ起動時にシステムプロパティで指定してもらう、など。

log4jでログの出力先を指定するのであれば、　 　　

<param file="/home/app_dev_user1/log/app_error..log" /> と書くのではなく、 　　

<param file="${APP_LOG_DIR}/app_error.log"/>って書いて、

起動時に-DAPP_LOG_DIR=... と指定するような感じ。

2について

まずい例を上げます。例えば、こんなプロパティファイルがあったとします。

設定値はなんとなく雰囲気でご理解ください。 　

Application.properties

app.company.name=xx株式会社

app.account.lockCount=10

db.username=user

db.password=pass

url.crypt.key=abcd　

この設定ファイルでまずいのは、機能系の設定値（app～）と機能外の設定値（db～,url～）が混ざっていること。

もっとまずいのは、機能外の設定値を直書きしていることです。 セキュリティ上NGだから、という話では無いですよ（まあNGなんだけど）。

これらの機能外の設定値って、業務系システム開発では、アプリケーション開発チームには公開されないことがほとんどです。

特にパスワードや暗号化キー値などは、開発期間中は公開されていても、本番移行直前に変更されます。

こういった情報を、アプリケーション開発チームで持っている設定ファイルに書くのは無理があります。

ということで、

・機能と機能外で設定ファイルを分ける。

・アプリケーション開発チーム側では知り得ない設定値を外だしできるようにする

　（例えば、db.username=${USER} とする）。

といったことを考える必要があります。

この設定ファイルは誰の持ちもので、持ち主は記述される情報を知りえるのか、ということを意識したいです。