下記2エントリを見て、腑に落ちました。 十年一日のやりかたでいるところに一石を投じることができれば、泥にならずに済むかもしれませんね。自発的な苦労がついてきますが。
泥カンと未来サミットとIT業界の現実 - ひがやすを blog http://d.hatena.ne.jp/higayasuo/20080717/1216274298
10年泥が嫌ならITお勧めだよ - 雑種路線でいこう http://d.hatena.ne.jp/mkusunok/20080717/it
2002年、新卒で入社したとき配属されたプロジェクトでの話です。 IT土方の頂点SIerの迷惑な新人として、社会デビューです。
プロジェクトの概要は以下のとおり。 (新人のときに見えたものなので、全体はまるで見えていないですが)
[全体] ・ホストで動いていた企業内の基幹(企業内会計)システム(旧)を、オープン系(新)に移行して、維持管理削減を目指す ・情報系のシステムを刷新(というかほぼ新規構築) ・移行期間中の基幹系システムの出力は新旧比較
[新・基幹系(筆者所属チーム)] ・新側のシステム開発 ・開発言語はCOBOL ・新の本番サーバはUNIXだが、個々のプログラムの開発環境はWindowsのPC上で構築(Unix, WindowsそれぞれをサポートしているCOBOLコンパイラ製品を使用する)
[基幹系移行チーム(プロジェクト途中から筆者所属チーム)] ・旧→新への移行のためのプログラム/フロー/時間割作成 ・移行データの洗い替え/検証
私が担当になったのは、移行データの洗い替え/検証の作業でした。
それまでは、指示にしたがって、Unix開発機のセットアップや本番で動く担当プログラムの開発に従事していたのですが、生産性は協力会社のばりばりCOBOLerには劣るし、ただの一作業者っていう感じで一生懸命、詳細設計して、コーディングして、単体テストしてました。
10年泥が嫌ならITお勧めだよ - 雑種路線でいこう http://d.hatena.ne.jp/mkusunok/20080717/it
結局10年以上の経験を持つ先輩がいる職場って10年泥なんだよ。経験を積んだ先輩と生産性を比較され、出来が悪いんだから下積みやって追いつけ、となる。
移行データ関連の作業は最初、Unixの本番機とホストでやっていたのですが、プロジェクトでの環境の割り当て優先順位がどうにも低く、検証作業が予定通り進みません。 たくさんの端末で動かして、移行データ関連作業もはやくすませるのに、単体プログラム開発のとき使っていたWindowsのPCを使ってできないか? と上司に相談を受けました。
「UnixのシェルをWindowsのバッチで動かすようにすればいいんですよね? シェルが不足しているところも、現行システムJCLを見て、プログラム含めて同じようなものを作ればいいんですよね?」 「それができる人がいないんだ。やってみる?」 「とりあえずやってみます」
当時の私は、MS-DOS時代から.batは触ってきているので問題なし。大学の学生用計算機環境はUNIXでしたので、.shも読み書きできました。JCLは業界入ってからこのプロジェクトで見たのがはじめてでしたが、「だいたい、シェルみたいなものなんですね」と理解して、それほど困ることはありませんでした。
Job Control Language - Wikipedia http://ja.wikipedia.org/wiki/Job_Control_Language
ただ、「それができる人がいないんだ。」という上司の言葉が信じられずにいたので、周囲の人々の知識なりを探ってみました。
ホストをメンテしてきたお客様のシステム部門では、Unixをわかる人がいない。 Unixのシェルについて詳しいとされていたチームメンバーは、「Windowsの.batがわからない」とか言う。仕事の契約とか責任分界点のせいで、やるわけにはいかないのかと思っていたのだが、どうやら本当にUnixのシェルのことしかわからないらしい。 で、JCLが読めて、Unixのシェルがそこそこ読み書きできて、Windowsの.batについてわかる人が私しかいなかった。
つまり、チームのなかではいちばん業界キャリアの浅い私が、オープン系のシステムの知識をいちばん(浅く広くの観点では)持っていて、作業の効率化に貢献できた...ということです。 サンプルテストデータ作るのに、Perlや秀丸マクロ使って生成しているだけで驚かれたことに、驚いていました。 (2002年当時は、SIerの現場ではそれほど浸透してになかったんでしょうか?)
この仕事をこなしてから、プロジェクトでの居心地が格段によくなりました。 本当に小さな小さな世界ですが「JCLとUnixシェルとWindowsバッチがわかる専門家」扱いです。んで、「専門家」とされている部分で、質問されたとき答えられないといけないから、より必死に勉強する、と。 また、仕事の量は減ったものの、今までは仮眠時間に割り当てられていた会議で、無責任に発言ができないので、精神的にしんどくなりました。
泥カンと未来サミットとIT業界の現実 - ひがやすを blog http://d.hatena.ne.jp/higayasuo/20080717/1216274298
「新しいことに挑戦して道を切り開かなければいけない」
ってことですね。レベルはぜんぜん違いますけど。 これをやらないと、10年下の後輩にも、お客さまの期待にも負けちゃいます。
以上、自分の体験から、10年先輩のやりかたよりも新人のやりかたの方が生産性が高いなんてことがありうるこの業界、開発フェーズについては、泥になりづらいのではないでしょうか。
※ SIerの対顧客窓口(営業とかプロマネも含め)については、どちらかというと「泥」でいくしかない世界だと思っています。もうすこし、考えてみたいとは思います。
