エンジニア?プログラマ?

日々考えたことやメモを書いていきます

Cygwinにnkfをインストールする方法

Cygwinで日本語扱ってると、ファイル開いたら文字化けしたりとか、

文字コードの問題にかなり頻繁にぶちあたる。

変換したいだけならテキストエディタでもいいしいろいろ方法はあるけど、

結局一番なじみも深いし簡単に使えるnkfを導入してみようってことになる。

こういうのってたいてい自動化に組み込みたくなるし。

 

nkfとはNetwork Kanji Filterでかなり昔からある日本語コード変換プログラム。

よくあるSJISEUCUTF-8を自由に変換することができる。

おまけに、-gで文字コードを調べることもできるし、

-Lで改行コードの変換とかもできちゃう、お手軽で便利なツール。

一回慣れてしまうとどの環境でも欲しくなってしまう。

 

Cygwinでファイルリストを見る時にコマンドラインが文字化けてしまう場合も、

ls | nkf -w

とかで表示できるようになる。

 

そしてインストール作業。

昔はもうちょっと頑張った気がするけど、

最近やってみたらすごく楽にできた。

 

以下のsourceforgeのサイトから最新版のソース(執筆時点でnkf-2.1.2.tar.gz)を入手

http://sourceforge.jp/projects/nkf/

 

1. ダウンロードしたファイルを展開する

$ tar xvfz nkf-2.1.2.tar.gz

 

2. Makefileの中身を確認する

  • CCに設定されているccが存在するか
  • CFLAGSが適切か
  • PERLに設定されているperlが存在するか
  • prefixが自分の環境に合った(インストール用の)ディレクトリになっているか

 

3. 展開したディレクトリでmakeする

$ cd nkf-2.1.2/
$ make 

4. インストールする

$ make install

5. 実行

$ nkf --help

 

快適快適。

実はもうCygwinのパッケージとして配布してる所があったりするのかなぁ。

 

やっぱり失敗する大きいプロジェクト

最近も大きいところがぽしゃったと話題になっているけど、

今のSI業界の構造では当然の結果だろうなと思う。

 

原因としてよく言われているのが、

ユーザー企業がもっと責任と力を持つべきだ、外国はそうだし、みたいな事だけど、

じゃあほいそれとユーザー企業がそうなれるかというと絶対できないと思う。

そんな人材も持ち合わせていなければ育てる能力もない。

こんな状況ではわかってても(わかってないだろうけど)

システム部門にリソースを割くことはできないでしょ。

 

では実際どうなったらいい方向に物事が運ぶんだろう?

多くのプロジェクトではユーザー企業、SIer、開発会社の3社間でやり取りしてると思うので、

世間話などを元にそれぞれの言い分について考えてみた。

 

ユーザー企業:

SIerは業務を理解しようとしない

SIerは協力的ではない、すぐに仕事を減らそうとする

SIerはITに詳しくない、ごまかして丸め込もうとしてくる

・話を聞け

 

SIer

・ユーザーは丸投げすぎる

・ユーザーは無茶な納期を設定する

・開発会社は納期を守らない

・開発会社のソフトウェア品質が悪い

 

開発会社:

SIerは納期の無茶を言いすぎ

SIerは何も知らないくせに注文つけすぎ

・話を聞け

 

もうびっくりするほど完全に敵対している。

こんな3者が同じプロジェクトで同じ目的に向かって仕事をしてるっていうのが

不思議で不思議で仕方ない。

やっぱり最大の問題はここにあり、お互いに全くリスペクトしてないところだと思う。

リスペクトどころかすぐにお互いの批判が始まったりもする。

(敵対関係の理由として当然契約形態とかの問題もあるが、それはまた別の話とする。)

 

当然火のないところに煙は立たないというように、

批判が上がるということは自分の仕事を全うできてないということになる。

じゃあ誰が全うできてないのか。

 

ユーザー企業はそもそもの発端でありここの業務が全ての正である。

業務知識に関しては全てを知っているしこれに関して能力的に不足があるわけではない。

開発会社も決められた設計書を元に決められた納期内にプログラムを作る点においては

仕事を全うできるはずでありそんなこともできないようであれば消えるべきである。

よってその前提においては能力的に不足があるわけではない。

 

このように考えると元凶の多くの部分はSIerにあると言えるのではないかと思う。

SIerがSI知識のなさを棚にあげて「依頼があいまいだ!」といちゃもんをつけ、

SIerが設計書を作る知識のなさを棚にあげて「ちゃんと作ってくれない!」と

いちゃもんをつけている。

SIerだけ「ここは任せてください!」と言えるものを持っていない。

とっても残念な現実。

 

やらなきゃいけない幅が多すぎだという言い分もあるかもしれないが、

それがSIerの仕事なんだと思う。

それだけのことをやるから価格も高いんじゃなかったのか。

最近は自分の分の仕事を減らそう減らそうとする人ばっかりだし、

なのに料金はそのままというどうしようもない状況。

 

もっとSIerには自分のやるべきことを理解してプライドを持ってやってほしい。

そして他の2者はもっとSIerに対して厳しいチェックの目を持つための力を身につけてほしい。

いつまで双方にとってSIerの「ブランド」がはびこっているのだろう。

プログラマとお話しするためには

プログラマはたいていコミュニケーション能力にコンプレックスを持っていると思う。

別に能力が低いわけじゃないのに巷でそう言われるから。

 

いわゆるチームリーダーなるものは

そういうコミュニケーションに乏しいプログラマをうまくコントロールして

プロジェクトを進めるものだってのが一般の認識であるから。

 

基本的にこういう線引きをした瞬間に、

チームリーダーとプログラマはお互い敵同士になる。

同じチームなのに。

「プロジェクトマネジメント」って前面に押し出してる会社では

役割が完全に縦割りなのでかなり多くの場合でこういうことが起きていると思う。

 

プログラマは自分の作業一つ一つのレベルから物事を組み立てて考えている。

とっても地道なのだ。

だってコードを1行も書いてないのにデバッグで2,3日費やすこともある。

ボタン一個を押すテストのパターンを腐るほど考えなきゃいけなかったりする。

 

「えいっ、ここからここまで線引いちゃえ」から始まるマネージメントとは正反対なのだ。

 

そのプログラマに対して「結局どうなの?」とか言ってしまうと、

その組み立ててきたものが全部吹っ飛ばされた気分になる。

自分が何もやってないと言われてるような気分になる。

だからリーダーの聞きたくないようなことまでうだうだと説明しだしてしまうのだ。

「そんなこと聞きたいんじゃない」なんて言われようものなら更にどツボにはまる。

 

なので、リーダーはまずすべてを包み込もう。

「よく頑張ってるね」「働きすぎじゃない?」とか声をかけて

プログラマの労をまず認めてあげる。

時間があれば「あのやばそうな障害の対応大変だったと思うけどすごいね」とかだと

なおGood。

 

「お前どんだけ大変かわかってねーのに!」ってのがプログラマの根本にあるのだから、

それを崩してあげれば説明に力を注いでくれるようになる。

自分が何を知りたいのかを説明してあげればプログラマはちゃんと丁寧に考えてくれる。

 

プログラマはコミュニケーションも地道なのだ。