先日、特許庁のポシャったプロジェクトのことを聞いてインドの優秀なSEが
あんなプロジェクトに何千人もかける必要ない。
４０人もいれば充分
とかいう話をしたとかいう記事をどこかで見ました。
インドのSEは優秀みたいですね。以前にやったJavaの仕事でDBとのやりとりをするフレームワークを作ったのがインドの技術者でとても凝った作りで技術力があるな～と感じたのを思い出しました。
でも、日本の優秀なSEはちがうのです。
まず、日本のSEはどれだけ大きな仕事をするかで優秀かどうかが決まります。
規模が大きいということはそれだけ沢山のお金がまわるということで、
内容に関わらず、大きな仕事をまわすことができるのが優秀なSEです。
なので、仕事が架橋に入ると嬉々として増員します。
総員すれば、人数で割ったぶんだけ早くおわりますから！という理由で、許される限り増員します。
そして沢山増員しても、忙しいので早く帰るのは許されない雰囲気をつくりあげます。
さくさくと定時に帰るのはよくないことです。暇そうだと増員できないですから。
まあ、人が増えれば意思の疎通などに時間がかかってしまうのは当然なことなので計算が合わなくなる分、人が増えれば増えるほど仕事も増えていきます。
沢山の人はそれぞれものすごく細分化された仕事に就きます。
ソース管理する人はソース管理しかしません。沢山のソースがあるのですから、管理だけで一仕事なのです。そして、個々のプログラマがルールに則ってソース管理のツール使えば済むんじゃね？とか口が裂けても言ってはいけません。なんせ、ソースを払い出すのに書類を書いて、沢山の人にはんこをもらってレビューをして、また戻すのにも沢山の書類を書いて、はんこを押してと沢山やることがあるのでその精査だけでもたいへんな量なんですから。
そして、ちゃんとした物を作ってるんだぞという印として紙をいっぱい作ります。
概要設計書、詳細設計書、単体、結合テスト計画書、テスト仕様書とか。。。。
そして、大勢で会議を開いてその精査をします。なので、会議の回数も多くなります。
前にやった超大きなプロジェクト、大手金融機関といっておきますが、キックオフの会場は近くのホテルの宴会場を借り切って数えきれない人が集まりました。
わたしが最初にやった仕事は、結合テストで必要なログを２行足すこと。
これのために、キングファイル２冊のテストエビデンスを作り、開発機にあげるのに必要な書類を作るのに３日かかりました。
ハイセキュリティエリアにソースを持ち込むのに、FTPとかは使っちゃだめで、もちろん自分の記録媒体なんか使っちゃだめ。
共有のサーバに、これをあげてください。とファイルを置いて、書類を何枚か書き、正しい書類か数名のレビューを通し、係の人がCDRに焼く。
書類には「個人情報に関わるものはありません」と明記してないと戻されたり、なんだかんだで３日かかりました。
そして、そのチームではその手続きをしたのがワタシが最初だったので、それはノウハウだ！スキルだ！次にやるときに誰もわからないので、是非残って仕事をしてください、と頼まれたのですが、延長は丁寧にお断りしました。
そんなん、スキルでもノウハウでもないわっ！
そこのプロジェクト、プログラムを作るのにもものすごい丁寧な仕様書を何枚も書いていましたが、DBの接続が静的だったので２こいっぺんに動かして、前のコネクションがクローズした時点で次のタスクも落ちていました。結合テストフェーズなのに！
丁寧な仕様書にはDBの接続方法とか、XMLの読み込み方法とかの記述がなく、なんとプログラマまかせの手作りだったので。あんなソース初めて見ました。
つーか、そこが一番大事なとこなんじゃないの？会議とかで誰も気づかなかったの？？
とか思ってしまうワタシは優秀ではないのでしょう。
まして、空気を読まないで仕事が終わったらさっくり帰っていたので、とてもダメな技術者だったと思います。
あんなプロジェクトに何千人もかける必要ない。
４０人もいれば充分
とかいう話をしたとかいう記事をどこかで見ました。
インドのSEは優秀みたいですね。以前にやったJavaの仕事でDBとのやりとりをするフレームワークを作ったのがインドの技術者でとても凝った作りで技術力があるな～と感じたのを思い出しました。
でも、日本の優秀なSEはちがうのです。
まず、日本のSEはどれだけ大きな仕事をするかで優秀かどうかが決まります。
規模が大きいということはそれだけ沢山のお金がまわるということで、
内容に関わらず、大きな仕事をまわすことができるのが優秀なSEです。
なので、仕事が架橋に入ると嬉々として増員します。
総員すれば、人数で割ったぶんだけ早くおわりますから！という理由で、許される限り増員します。
そして沢山増員しても、忙しいので早く帰るのは許されない雰囲気をつくりあげます。
さくさくと定時に帰るのはよくないことです。暇そうだと増員できないですから。
まあ、人が増えれば意思の疎通などに時間がかかってしまうのは当然なことなので計算が合わなくなる分、人が増えれば増えるほど仕事も増えていきます。
沢山の人はそれぞれものすごく細分化された仕事に就きます。
ソース管理する人はソース管理しかしません。沢山のソースがあるのですから、管理だけで一仕事なのです。そして、個々のプログラマがルールに則ってソース管理のツール使えば済むんじゃね？とか口が裂けても言ってはいけません。なんせ、ソースを払い出すのに書類を書いて、沢山の人にはんこをもらってレビューをして、また戻すのにも沢山の書類を書いて、はんこを押してと沢山やることがあるのでその精査だけでもたいへんな量なんですから。
そして、ちゃんとした物を作ってるんだぞという印として紙をいっぱい作ります。
概要設計書、詳細設計書、単体、結合テスト計画書、テスト仕様書とか。。。。
そして、大勢で会議を開いてその精査をします。なので、会議の回数も多くなります。
前にやった超大きなプロジェクト、大手金融機関といっておきますが、キックオフの会場は近くのホテルの宴会場を借り切って数えきれない人が集まりました。
わたしが最初にやった仕事は、結合テストで必要なログを２行足すこと。
これのために、キングファイル２冊のテストエビデンスを作り、開発機にあげるのに必要な書類を作るのに３日かかりました。
ハイセキュリティエリアにソースを持ち込むのに、FTPとかは使っちゃだめで、もちろん自分の記録媒体なんか使っちゃだめ。
共有のサーバに、これをあげてください。とファイルを置いて、書類を何枚か書き、正しい書類か数名のレビューを通し、係の人がCDRに焼く。
書類には「個人情報に関わるものはありません」と明記してないと戻されたり、なんだかんだで３日かかりました。
そして、そのチームではその手続きをしたのがワタシが最初だったので、それはノウハウだ！スキルだ！次にやるときに誰もわからないので、是非残って仕事をしてください、と頼まれたのですが、延長は丁寧にお断りしました。
そんなん、スキルでもノウハウでもないわっ！
そこのプロジェクト、プログラムを作るのにもものすごい丁寧な仕様書を何枚も書いていましたが、DBの接続が静的だったので２こいっぺんに動かして、前のコネクションがクローズした時点で次のタスクも落ちていました。結合テストフェーズなのに！
丁寧な仕様書にはDBの接続方法とか、XMLの読み込み方法とかの記述がなく、なんとプログラマまかせの手作りだったので。あんなソース初めて見ました。
つーか、そこが一番大事なとこなんじゃないの？会議とかで誰も気づかなかったの？？
とか思ってしまうワタシは優秀ではないのでしょう。
まして、空気を読まないで仕事が終わったらさっくり帰っていたので、とてもダメな技術者だったと思います。