| Copyright (C) Ada72 All Rights Reserved. |
| 第60話 お抱えプログラマ | 2000/01/17 |
先週は新年早々暗い話題で失礼いたしました。
改めてあけましておめでとうございます。
本年もよろしくお願いいたします。
社内の勉強会で、
コーディングスタイルとコメント技術の話題が出ました。
その時、
ウチのプログラマはコードの記述に関して甘いのではないか、
という話になりました。
どういうことかというと、
ISO9000シリーズに準拠しているような大規模なプロジェクトに
参画しているプログラマには信じがたいことかもしれませんが、
パッケージの世界では、
一つのプロダクトを担当のSEとプログラマがかなり好きなように管理している場合が結構あります。
すると、
コーディングスタイルがプロダクトによってまちまち、
ひどい場合には同じプロダクトでも担当したプログラマによってまちまちだったりすることが多々あります。
その辺は派遣プログラマの方が、
大規模なプロジェクトに組み込まれ、
そのプロジェクトのコーディングスタイルを踏襲させられるため、
よりシビアであると言えます。
まあ、
コーディングスタイルなんて、
他のプログラマが見て分かればいいわけですから、
ある意味でどうでもいいのですが、
お抱えプログラマ、
つまり正社員のプログラマが派遣プログラマに比べて決定的に甘いかなぁと思うのは、
仕事に対する危機意識です。
私は社会人になってからずっとお抱えプログラマです。
ですから派遣プログラマが派遣会社とどのような契約を結んで派遣先に派遣されているのか、
どのような基準で仕事を割り当てられているのかについてはよく知りません。
きちんと取材すべきですが、
知り合いに派遣プログラマがいないため、
憶測で書くことをお許し下さい。
また、
誤りがあればご指摘下さい。
派遣プログラマの場合、
派遣会社の情報をもとに仕事の流れを推測すると、
自分のスキルなどを登録しておくと、
条件にあった仕事を紹介してくれるようです。
依頼会社とプログラマの間で合意に達すると派遣となります。
そして派遣先の労働基準・プロジェクト進行方式に従って業務に従事することになります。
そこまではいいのですが、
問題はその後です。
無事プロジェクトは終了し、
契約が切れます。
すると派遣プログラマは次の声がかかるまで、
事実上クビになってしまいます。
実際にはそんなことにならないよう、
派遣会社がちゃんと仕事をアサインしてくれるのでしょうけれど。
でも、
もし、
そのプログラマがCOBOLプログラマだったとして、
Y2Kで大忙しだったのに年が明けたら途端にCOBOLの仕事が急に減ったとしますよね。
するとそのプログラマは他のスキルを身につけるまでは本当にクビです。
ですから派遣プログラマは、
余程能天気な人を除けば、
次もちゃんと仕事を貰えるようにそれなりに努力しているんじゃないかと勝手に考えています。
翻ってお抱えプログラマはどうかというと、
何年も同じプロダクトを担当することは珍しいことではありません。
というより、
そちらの方が普通ではないでしょうか。
すると、
その担当を辞めさせられない限りメシが食えるわけですよ。
人間というのは元来怠惰な生き物ですから、
おのずと、
自分がかつて習得した技術だけでなんとかしようと思ってしまうのです。
でも、
ソフトハウスなんて元来水商売、
明日は会社がなくなっていてもおかしくない世界です。
我々お抱えプログラマだって、
会社が潰れても仕事にありつけるよう、
普段から努力しなければならないのです。
私は幸いなことに今までお抱えプログラマでした。
これからもお抱えプログラマでいようと思っています。
でも、
いつか独り立ちできるよう、
いつも目標は高く持っていたいものです。
独立より、 今のプロジェクトのメインプログラマの職を失わないようにしろって? 確かに…。
| 第61話 海よりも深く | 2000/01/23 |
ようやく身の回りも落ち着いてきたので、
久しぶりにジュンク堂へ行きました。
COMの本もATLの本も有名なものは大概買ってしまった後だし、
今日あたりは久々のウィンドウショッピングかなぁ、
と思いながら足を運んだのですが、
いざ行ってみるとやっぱり買ってしまいました。
その内訳は…。
後者は、
「
高い本買っちゃったし、
とっとと帰ろう
…
でも数学のコーナーも見とこうかなぁ
」
と数学のコーナーに立ち寄ったのが運の尽きでした。
このコラムを最初の方から読まれた方ならお気づきだと思いますが、
私は文学部出身なのです。
ですから、
数学に関しては高校数学で止まっています。
簡単な微積分ができるところまでです。
ビジネスアプリを組む分には数学なんてそんなに必要ではありません。
普通は
「
アルゴリズムとデータ構造
」
を読んで基本的なデータ構造とアルゴリズムを理解・利用できていれば問題ありません。
でも、
CADベンダーに勤務していて数学もろくにできないのは恥ずかしい
(笑)。
ところが、
勉強しようにも大学の数学の本っていきなり凄い数式がガンガン出てくるんですよね
(爆)。
困っていたところに見つけたのがこの本だった、
というわけです。
情報科学という学問は
(
まぁどんな学問でもそういう側面はありますが
)
、
様々な学問が寄り集まってできた経緯から、
様々な切り口から研究できる学問です。
現に私の修士研究テーマはヒューマンインターフェイスでした。
ヒューマンインターフェイスの研究は、
定量評価がしにくく、
どうしても定性評価で結論を出さざるを得ないため、
工学として認められたのはごく最近のことです。
社会人になってから、
プログラミング言語、
設計手法などに興味を持ち、
ソフトウェア工学に関しても自分なりに勉強してみました。
でもそれはまだまだ氷山の一角です。
私はもっと他にもいろいろ勉強したくなりました。
そこへ飛び込んできたのが数学だったのです。
情報科学に使われる数学は、
いわゆる数学科での数学とは少し趣を異にし、
独自の世界を築いています。
それはそれで、
興味深いテーマです。
というより、
情報科学においてはこちらの方が王道でしょう。
情報科学。
ここへは、
どこからでも来ることができる。
ここにいると、
様々なテーマがに触れることができる。
ここからは、
どこへでも行くことができる。
情報科学を海にたとえるなら、
船で新大陸へ渡ることもできる。
海底深く潜ることもできる。
空へ旅立つこともできる。
広く、深い海。
神様は私に、
なんて素晴らしい世界を与えてくれたのだろう!
私はまだ、
大海原に漕ぎ出した若き船乗りです。
どこを目指すのか、
それすら決めない気ままな船旅。
どこにたどり着くのか、
着いてみなければ分かりません。
とりあえず今は、
深い海の底に美しい真珠が輝いていると信じましょう。
一生浮いてくるなって? 正しいです。
| 第62話 第六感見積法 | 2000/01/31 |
正式な線表では、
現在私がかかわっているプロジェクトのタイムリミットはあと約1ヶ月となりました。
職業プログラマの皆様は、
SEがある程度線表を書いたら、
「
いついつまでにお願いね
」
という形で仕事を依頼され、
納期を守っている限りは時間配分は任せられると思います。
外注さんが非常に多い会社の場合は、
メチャクチャ細かい週報をあげなきゃいけないなんて話も聞きますけれど、
ウチの会社の場合はかなり個々のプログラマに任せられています。
隣のサブグループリーダのK氏に気が向いた時に現状報告をするのですが、
私の性格が災いしてそれが結構いい加減。
「
あぁ、
あと1月になりましたねぇ、
まぁなんとかなるでしょう。
うーん、
ちょっと残業が増えるかなー
」
といった具合です。
本当はそれなりの定量的手法を使って工数見積をしないといけないんじゃないか、 とは思うのですが、 例えばあるクラスAを作る予定だったとして、 クラスAにメソッドが10あるとしますよね。 だとすると、 単純に1メソッドに1時間費やすとしてクラスAは10時間で完成するかというと、 大概の場合答えはノーです。
よくあるパターンはこんなシナリオです。
クラスAのメソッド0からメソッド9までのうち、
メソッド0からメソッド8までは既存のライブラリを使用・流用することにより、
1メソッドあたりの構築に要する時間は30分程度である。
メソッド9については、
既存ライブラリの使用が効かないため、
コアのデータにアクセスするAPIを作成してからでなければメソッドの作成に取り掛かることはできない。
そこでそのAPIを作成するのに丸1日を要し、
メソッド9の作成にはトータルで1.5日かかった。
結局クラスAは約2日で完成した…。
まあ、
クラスが1個だけなら、
メソッド9に異様に時間を割かれることは容易に想像できますから最初の段階で細かく見積もることができます。
でも今私が作っているものはクラスライブラリ全体で700近いメソッドがあるんですよね。
もちろん実装が殆ど同じメソッドや、
マクロとテンプレートで実装は一瞬で完成するものも含まれていますから、
数字だけ見てびっくりしなくてもいいんですけれど。
で、
その規模になるといちいち
「
クラスAにはメソッド0からメソッド9までのメソッドがあるが、
メソッド0からメソッド8までは30分程度で実装可能、
メソッド9のみ1.5日を要します
」
なんて細かい見積りなんてやってられません。
結局どうするかというとエイヤで
「
えーい、
全部まとめて3ヶ月、
でどうだ!!
」
という、
他の業種の方が聞いたら卒倒しそうな方法で見積もってしまいます。
実際のところどうなのかというと、
どんなに細かく見積もっても、
思わぬところで時間を食ってしまって線表通りに進まないという現象が発生します。
というより、
この業界、
大半のプロジェクトは見積もりミスと予期せぬトラブルで途中で最低一回は線表を引き直します
(笑)。
結局細かい線表を引くだけ無駄で、
SEの経験と勘が頼りだったりするのです
(爆)。
ソフトウェア工学の分野では様々な見積り手法が研究されているようですが、
実用に耐えるものは寡聞にして知りません。
知ったとしても参考にする程度で、
暫くは第六感に頼るでしょう。
K氏の勘が正しいかは、
1ヶ月後に証明されます。
乞うご期待!!
間に合うように頑張れって? あ、 そっか。
| 第63話 最先端テクノロジー | 2000/02/06 |
最近安部清明が密かなブームらしいですね。
平安時代の当時は陰陽道が信じられていて、
宮廷にも陰陽道を司る部署が設けられていたのだそうです。
そんな話を聞くと現代の我々は驚きますが、
見方を変えれば、
当時は陰陽道や占星術が最先端テクノロジーだっただけの話です。
現代の我々は科学技術を最先端テクノロジーだと信じています。
ある意味で信仰に近いでしょう。
でも未来永劫科学が絶対である保証はないでしょう。
たとえば30世紀の歴史の教科書には
(
もちろんそれまで人類が滅びていなかったらの話ですが
)、
「
20世紀の人類は科学を信じており、
科学で説明できる現象は正しいのだと思っていました
」
なんて記述があるかもしれません。
政府の機関として
「
科学技術庁
」
が存在することを知って驚くかもしれません。
先にも延べたように、
我々が科学を信じているというのは言わば単なる信仰であり、
より大きなパラダイム・シフトが起きれば科学信仰は過去のものとなるはずなのです。
いきなりでかい話から入りましたが、
これは我々の世界にも当てはまることです。
我々は現在コンピュータとはこんなもので、
プログラミングとはこんなことで…、
という大前提のもとにプログラミングを行い、
メシを食っています。
様々なアーキテクチャ、
プログラミング言語が登場しましたが、
基本的なパラダイムはノイマン型コンピュータの誕生以来殆ど変わっていません。
しかし昨今の業界事情を見ていると、
この状況がそう何年も続くとは思えません。
もうあと何年かしたら、
パソコンなんて世の中から消滅していて、
その代わりみんなPDAのような端末で仕事をしていたりするかもしれません。
プログラミングも、
CASEツールが本当に実用レベルに到達し、
我々のようにゴリゴリ書くプログラマはクビかもしれません。
コンピュータそのものも、
別の何かに取って代わられるかもしれません。
私は自分の本業はモノ書きだと思っています。
たまたまプログラムを書いてメシを食っているだけで、
書くものはコラムでも評論でもいいのです。
構造化され、
論理的に展開する文章を書くのが好きでこの仕事をしています。
もしプログラミングがお絵描きになってしまったら、
プログラマを辞めてしまうかも、
と思っているくらいです。
今後どんなパラダイム・シフトが我々を待ち受けているのでしょうか。
そして、科学技術を超えるパラダイムは現れるのでしょうか。
30世紀の歴史の教科書を見ることが出来なくて残念です。
つべこべ言わずに現在の仕事に必要な技術をマスターしろって? ばれた!!
| 第64話 時には昔の話を | 2000/02/13 |
- 我が家には、 38個の将棋の駒があります。
父の入院中に、
2回だけ外泊許可が出ました。
母は大変喜んで、
父の好きな食事を振る舞っていました。
後で聞いた話ですが、
父はこの時のことがとても楽しかったらしく、
病院に戻ってからも看護婦さんに話していたそうです。
外泊といっても病人ですから、
安静にしていなければいけません。
もちろん外出はできません。
父が起きている間、
いろいろお相手をするのですが、
午後にもなってくるとさすがに時間を持て余してきました。
父は少し退屈そうにしはじめました。
せっかく久々に家で過ごせるわずかな時間です。
何とかして楽しい時間にしなければ、
と皆が思い始めたその時、
私に白羽の矢が立ちました。
父は将棋が好きだったのですが、
相手がいないので将棋盤と駒は片づけられたままになっていました。
私はちょうどその頃、
「
月下の棋士
」
にはまっていて、
詰め将棋をしていました。
「
あんた、
将棋指せるんやろ
」
母の鶴の一言で対局が決まりました。
いやぁ、
いくらなんでも無茶ですよ。
かたやNHK杯を録画してまで見てテレビの前で肯く人、
かたや
「
金は斜め後ろには進めないよね?
」
とか抜かしてるヤツです。
対局というよりは、
「
父と息子の相撲
」
状態です。
父
「
銀は真後ろには行かれへんで
」
私
「
あっ…
(
文字どおり
"
銀が泣いている
"
(爆)
)
」
とか、
父
「
お前、
そこ行ったら王手かかるで
」
私
「
うわーっ、
一手戻していい?
」
とか、
私
「
角交換しようか
」
父
「
そうやなあ
(
←
作戦バレてる
)
」
というようなひどいやりとりがあって、
父がおおまけにまけてお勉強して出血大サービスして私が勝ちました
(
わたしまけませんでしたけど情けなさすぎ
)
。
納棺の時、
葬儀屋さんが棺に納める物をチェックしました。
燃焼時に有害物質が発生するものは入れてはいけないからです。
納棺する物の中に、
将棋盤と駒、
父と子の対戦記録も入っていました。
将棋盤は木だったので問題なかったのですが、
駒はプラスチックだったため、
2個だけが納棺されました。
- 我が家には、 38個の将棋の駒があります。
…って、 ただの回想録ではこのコラムとしては成立しないので、 また例によって例のごとく強引にネタに持っていきます (笑) 。
父の入院生活が退屈だろうと、
母がゲームボーイを買って病院に持っていきました。
ソフトは詰め将棋とテトリスを用意しました。
結局画面が小さすぎて老眼の父は一度もゲームをしませんでした。
今や残された家族の暇つぶしの道具として大活躍です。
テトリスは、
レベルが上がっても、
落ちてくるブロックの順番がいじわるになったり、
落下速度が速くなる程度なのですが、
問題は詰め将棋です。
正解はデータとして持っているらしく、
詰むと一瞬で正解であることが表示されるのですが、
あまりにも妙な王手をかけると、
結構長い間戻ってこなくなります。
昔のパソコンで将棋ソフトを動かすと
「
落ちたのではないか
」
と思うほど長い間戻ってこなかったそうですが、
多分それに似た状態でしょう。
現在の私の愛機で将棋ソフトを動かすと、
一瞬で次の手を打ってきます。
普段あまり
「
今のパソコンって凄いなぁ
」
なんて思うことはあまりないのですが、
詰め将棋をしていてふと昔の話を思い出しました。
昔は make に時間がかかりました。
私がアルバイトに行っていた頃、
先輩たちはよく make をかけて食事に出かけましたが、
時々途中でエラーが出て止まっていて悲劇を見ていました。
そんな悲劇を未然に防ぐために、
先輩たちはプログラムを打ち込む前に頭の中でプログラムを書いていたようです。
余談ですが、
もっと昔はジョブの順番が回ってこないとコンパイルしてもらえなかったため、
紙の上で机上デバッグというのをやって
(
つまり、
自分がコンピュータになりきってプログラムを読むわけです
)
、
それからカードをオペレータに渡していたのだそうです。
私のかつての愛機 PC-98 RA21 は既に歴史の中に埋もれ、
プログラムをどんどん打ち込んでいって、
エラーが出たら修正するプログラマが増えました。
私もこの世代です。
納期が迫ってきて詳細設計うんぬんなんて言ってられなくなると、
ついついこれをやりはじめてしまいます。
exeやdllのサイズが小さい場合はベタ打ちでもさして大きな被害には遭いません。
後でいいかげんな設計に苦しむだけです(笑)。
しかしプロジェクトのサイズが大きくなると大変です。
プロジェクト全般に渡るような変更をして、
オールビルドをかけると、
先の先輩たちと同じ目に遭います。
今やっているものも、
オールビルドにはコーヒーをゆっくり飲めるぐらいの時間がかかります。
COMなので、
VBのテストプログラムで動作確認しなければなりません。
なるべくオールビルドしたくないので、
どんどん打ち込んでいくと…昔の先輩たちと同じ状態になります。
まず頭の中でプログラムを書く羽目になります。
というより、
本当はこちらの方が王道なのです
(
結局やってなかったりするんですけど(汗)
)
。
環境が良くなって、
開発の能率は上がりました。
しかし、
make がすぐに終わるからといって、
考えなしにプログラムを打ち込んではいけないのです。
COMコンポーネントの開発はCOMの技術以外にも私に様々なことを教えてくれます。
話が元に戻りますが、
詰め将棋なんて新聞に毎日出てるだろう、
と思われた方もいらっしゃるでしょう。
詰め将棋を紙ベースでやろうとすると、
将棋盤を頭の中に作り上げる技術が必要です。
記憶力のない私には11手詰み以上の詰め将棋を紙ベースで行うのは無理です。
でも、
ゲームボーイで苦戦するより、
頭の中でプログラムを書ききってから打ち込んでいた先輩たちに倣って、
この技術の習得に励んだ方がいいのかもしれません。
パソコン用の詰め将棋ソフトを買えばいいだろって? 徹夜しちゃうからやだ(爆)。
| 第65話 鯖を読む人 | 2000/02/21 |
金曜日の夕方。
余程せっぱ詰まった仕事があるか、
あの独特の雰囲気を楽しみながらのんびりと仕事をしたい人だけが残っている時間帯になりました。
K山氏が8mmテープからデータを吸い上げているのをK氏が目ざとく発見し、
8mmテープ装置の話をしていました。
私は8mmテープ装置はSunのものしか見たことがありません。
思わず吸い寄せられて、
話題に割り込んでしまいました。
その後は、
超カルトな話題で盛り上がりました。
前からいろんな人に、
「
お前絶対鯖読んでるだろ
」
と言われつづけていたのですが、
またしても言われてしまいました。
「
Ada72って、
ホントにパソコンから入ったの?
」
「
Z80でゴリゴリ書けるんじゃないの?
」
断じて言いますが私は386からこの世界に足を踏み入れたのです。
しかもその頃は一般ユーザです。
大学でのレポートを書くのに、
LaTEXを使っていたぐらいです。
じゃあなんでそんなことを言われるかというと、
昔のことを知っているからです。
パソコンの二次記憶装置がカセットテープだったことは、
学研の
「
科学
」
を読んで知っていました。
実物を見たのは大学生の時です。
誰かがジャンク品を拾ってきて部室に持ってきたのです。
8インチのフロッピーも、
前の会社で見たことがありました。
その他、
MSX、
X68000など、
マニアックなマシンの話題も通じてしまいます。
「
あんたホントに27なの?
」
と疑われるのも、
まあ無理はないのかもしれません。
技術者というのは不思議な生き物で、
普段は最新の技術を追い求めているくせに、
ふと過去を振り向いて、
時代が見捨てたものを愛情のまなざしで見つめ、
懐かしむものなのです。
逆行しようとは思いません。
開発環境は昔とは比べ物にならないほど性能が上がっていますし、
昔なら大変な労力と人員を要した開発も、
小人数のチームで可能になりました。
でも、
「
オールビルドをかけるから
」
と、
みんなで晩メシを食べに行ったり、
ソファで仮眠を取ったりというイベントはなくなってしまいました。
そんなおおらかな時代が、
時々懐かしくなるのです。
などと書くと、
やっぱり
「
お前鯖読んでるだろー!!
」
というツッコミが来そうですが、
断じて鯖は読んでいません。
ハンドルネームが示すとおり、
私は1972年生まれです。
余談ですがこのハンドルネームはY2K対応できていません。
ですから、
「 お前100年鯖読んでるだろー!! 」 というツッコミは甘んじて受けます。
| 第66話 哲学者よ箸を取れ | 2000/02/27 |
タイトルを見た瞬間に 「 デッドロック!! 」 と叫んだあなた! 正解です。 もれなくジャンクメールをプレゼント致しますので、 メールでご連絡下さい(ウソ)。
巷には糞なプログラミング入門書がゴマンとありますが、
アルゴリズムの本は非常に少ないのを私は以前から嘆いていました。
言語だけをマスターして、
それでプログラマとしてメシが食えるでしょうか?
新入社員に
「
C言語入門セミナー
」
だけを受講させて、
即現場に投入できるでしょうか?
この質問の答えがYESだと思っている人はかなり多いと思いますが、
私はいずれにもNOと答えます。
プログラムをレシピに例えるならば、
言語は調理器具、
アルゴリズムは、
素材を刻む、
炒める、
煮るなどの基本的な調理方法にあてはめることができると思います。
調理人がレストランに入門したら、
まず
「
これがフライパンです。
油をひいて炒めます
」
と、
調理器具について習うと思いますが、
調理器具の名前と使い方をマスターしただけで厨房に立たせてもらえるでしょうか?
レストランなら答えはNOです。
でもそれを平気でやるのがこのソフトウェア業界です。
そして大量の糞プログラムが生み出され、
メンテナンスにコストがかかり、
担当者が辞めるとメンテナンス不能に陥り、
同じ機能を果たすものを別のプログラマが一から作り直し…
という悲劇の無限ループがいたるところで繰り広げられました。
さすがにようやく最近になってみんな気づきはじめたようで、
プログラミング入門雑誌に
「
アルゴリズム特集
」
などが登場するようになりました。
そのような特集が組まれるようになったこと自身は評価すべきことであり、
私は喜んでいるのですが、
問題が一つあります。
その記事を本当に読むべき人に限って、
その記事を読まないのです。
情報工学出身でなくてソフトハウスに入社しても、
勉強熱心な人ならそれなりに勉強します。
そのうち
「
アルゴリズム入門
」
みたいな本を買ってきて自分で勉強してしまうものです。
どんなに出版社が啓蒙しようと特集しても、
読んでもらえないのでは意味がありません。
だからこそフォントを大にして叫びたい。
哲学者よ、 箸を取れ!
タイトルを見て正解を叫べなかった方へ。
「
哲学者の食事問題
」
を自分で実装することは少ないと思いますが、
マルチスレッドのプログラムを書く時は排他処理が必要になります。
暇な時にタネンバウム本などご覧になってはいかが。
お前には箸を渡さんって? 私は哲学者じゃないから手で食ってやる!!
| 第67話 あれもこれも | 2000/03/05 |
先日、
生まれて初めて見合いなるものをしました。
父が存命中に見合い会社に登録しておいてくれたのですが、
ようやく私に会ってみようという方が現れたのでした。
その会社のシステムは月に何人かの写真とプロフィールが会社から郵送されてきて、
会ってみようと思えば
「
会ってみたい
」
に丸をつけて送り返すというものです。
が、
私は入会以来半年ほどの間に紹介された方々からことごとく断られつづけました。
それも、
直接会ってから断られるのではなく、
写真とプロフィールの段階で断られるのです。
就職でいえば書類選考で落とされまくって真っ青な状況です(笑)。
ようやくご本人にお会いすることが出来たのが先週でした。
私は転職する時には転職雑誌を読んでいましたが、
あまりにも多くの条件を求めると転職に失敗すると書いてありました。
転職に失敗した人にインタビューすると、
「
収入アップしたい、
キャリアもあげたい、
面白い仕事をしたい、
ビッグプロジェクトに参加したい、
名の通った一流企業で、
残業は少なく、
福利厚生も行き届いており、
…
(
以下省略
)
」
みたいな条件で会社を探していたのですが、
結局あれこれ望みすぎて転職して得た現在の仕事には満足していない、、
などと言う人がいるというのです。
その記事の信頼性は分かりませんが、
確かに多くを望むのは無理というものです。
ただし、
自分のプロフィールが例えば、
「
MIT卒、
在学中に既に重要な研究成果を次々と発表し、
今後の科学技術の発展に多大なる寄与をもたらす天才といわれながら、
学閥は嫌いだと言い残してベンチャーへ。
多くのニュービジネス、
ビッグプロジェクトを手がけ、
産業界からも一目おかれる存在。
しかし安定を求め企業へ帰属することに決めた
」
みたいなのでしたらどうぞいくらでも高望みして下さい。
でもそんな人なら転職雑誌なんて見なくてもいいと思いますけどね。
結婚も同じことが言えるのだと思うのは私だけでしょうかね。
「
オックスフォード大学英文学科卒、
由緒正しいお家柄、
優しさと強さを併せ持ち、
才色兼備とは彼女のためにあるような言葉、
趣味は読書と乗馬、
…
(
以下省略
)
」
みたいなプロフィールなら、
相手に望むプロフィールだって、
先ほどのMIT出身者みたいなものを求め、
書類でバンバン落としていいと思うのですが、
お互い似たり寄ったり、
ましてや写真とプロフィールだけではどんな人かもさっぱり分からないのに、
何故そこまで断ってくるのか不思議です。
ま、
見合い会社の戦略で、
最初の半年ほどはもう縁談がまとまりかかっている人を紹介しておいて、
徐々に新規会員を紹介していって、
2年分の年会費を貰うってことになってるんだと思うんですがね。
それにしても結婚となるとあれもこれも望みすぎるのでしょうか。
あれもこれも望みすぎると、
先の転職に失敗した人みたいになると思うのは私だけでしょうか。
男性へ。メシを作って欲しければ家政婦を雇えばいいのです。
女性へ。カネが欲しければ自分で稼げばいいのです。
お互い与え合い、
求め合えるものがあるから男女は寄り添って生きるのです。
何を与え、
求めるのかは人によって異なるはずです。
自分が求めるものは何なのか、
自分が与えられるものは何なのか、
自分で分かっていなければ、
大勢の他人の中からたった一人、
一生一緒に生きて行く人を選ぶことは無理でしょう。
そうは思いませんか。
分かっていないからとりあえずあれもこれもとなるのでしょう。
私にはまだどちらも何だか分かりませんが…。
相手が見つからんということはまだ青いということだろうし、
まだ棺桶に片足を突っ込むには早いと思うので(笑)、
いつものように強引にネタに繋ぎましょう。
ここまでうだうだと述べてきたことは、
そっくりそのままソフトウェアにもあてはまります。
あれもこれもと多くの機能を満載したソフトに、
良いものがあったためしはありません。
例えばワープロと表計算とデータベースとブラウザと
…
という調子で何でもかんでもできるソフトがあったとして、
それを使うでしょうか。
それとも必要な時に必要な単機能のソフトを使うでしょうか。
使いもしない機能満載で高いソフトを1つ買うのと、
使う機能を満たす安いソフトを必要な時に買うのと、
どちらを選ぶでしょうか。
賢いユーザならまず後者を選ぶでしょう。
それはベンダだって十分分かっているのです。
大きな問題が一つあるのです。
選挙と同じで、
シェアを左右するのは
「
パソコン買ったけどどうしよっかなー
」
と思っているユーザなのです。
だいたい目的もなしにパソコンを買う神経からして既に分からないのですが、
それはここで述べても仕方がないので捨て置きます。
もう後は選挙と同じです。
これまで自社製品を使ってきてくれたユーザは選挙でいえば固定票にあたります。
固定票ユーザは、
ベンダが余程のミスをしなければ乗り換えたりしないでしょう。
これまでのデータがゴミになったり、
データ変換の膨大な作業が発生したりしてまで乗り換えるのは大変ですから。
あとは浮動票、
つまりどのソフトを買おうか迷っているユーザです。
浮動票ユーザは大抵パソコン雑誌の比較記事を参考にしてソフトを買います。
雑誌の比較記事なんて案外無責任なもので、
単純にどのソフトがどの機能を実装しているというスペック表を作って、
機能1についてはソフトAの方がソフトBに勝り、
ソフトCに至っては機能1を実装していない、
よって機能1についてはソフトAが一番だ、
なんてことが延々と書いてあるだけです。
で、
結局一番多機能のソフトがお買得、
なんて結論になっています。
浮動票ユーザはやりたいことが明確に決まっていないから、
いいかげんな比較記事を鵜呑みにし、
あれもこれもそろった多機能のソフトを求める傾向にあります。
固定票ユーザだけを相手にビジネスが成立するなら楽な話です。
圧倒的に多い浮動票ユーザをなびかせて初めてトップシェアに立てるわけですから、
雑誌に提灯記事を書いてもらわなければいけません。
雑誌に提灯記事を書かせるために、
まず
「
うちのソフトが一番多機能だ!
」
という証拠を作っておかなければなりません。
そのために、
浮動票ユーザが喜びそうな機能をとりあえずあれもこれもと詰め込む。
そして肥大化し、
遂には自重で崩壊するのです。
ユーザさん、
とりあえずソフトにあれもこれも望むのはやめましょうよ。
回りまわってあなたは結局質の悪いソフトをつかまされるのですよ。
これは開発者の逃げではありません。
例えばワープロソフトにワープロに関係のない機能がついていても仕方がないでしょう?
イルカが3Dになっても仕方がないでしょう?
やりたいことが明確になってから秋葉原に行っても遅くはないじゃないですか。
ね?
…とここに書いても殆ど無意味であることに今気づく!!
お前は棺桶に両足突っ込めって? ゾンビプロセスになるだけだと思うなぁ。
| 第68話 書類仕事 | 2000/03/12 |
このページ、
大した内容でもないのにカウンタだけはどんどん上がってくなぁ…と、
書いてる本人も不思議に思っているのですが、
どうもプログラマになってみたいと思っている方が読んでいるみたいです。
ということで学生さんや転職を考えている方のために、
今回は現場の作業について述べてみたいと思います。
プログラマの一日の、 もしくは一週間の仕事ってどんなのを想像しますか?
「
私はプログラマです
」
と言うと、
決まって
「
キーボード打つの、
速いんでしょ?
一日中キーボード叩いてるもんねぇ、
俺なんてキートップ見ないと打てなくてさぁ…
」
なんて言ってくれる人がいますが、
キーパンチャ
(
死語?
)
じゃあるまいし、
一日中猛烈なスピードでプログラムを打ち込んでいるわけではありません。
大体、
一日中打ち込んでいるとしたら、
アルゴリズムやロジックの選定、
クラス構成の策定、
設計はいつ行うのでしょう?
打ち込みながらリアルタイムで出来るとしたら会社勤めなんて辞めてフリーになりましょうね。
もうちょっとましな人だと、
「
ああ、
あれでしょ、
大企業のシステム部門とかに派遣されて仕様書通りにただプログラム書くだけなんでしょ?
」
と言ってくれます。
そういうプログラマがいるのは確かですが、
このページを読んでいる人にそんなプログラマになって欲しくはありません。
ISO9000シリーズ対応している発注会社では、
SEが
「
俺が今書いた方がよっぽど早いわい!
」
と思うほど細かい仕様書
(
プログラムの一行一行を日本語で書いてあるそうです。
「
iを1インクリメントする
」
とか
)
を受託会社に出すそうですが、
そんな仕事を受けてもちっとも楽しくありません。
大多数のプログラマは、
SEの概要設計に基づいて内部実装は自分で自由に組むような役割を担います。
中にはプログラマがもっと外部とも折衝する会社もあるようですが、
プロジェクトがある程度の規模になれば、
自動的に窓口が必要になります。
それで、
SEとプログラマの作業分担が発生します。
SEが上についていてくれると、
プログラマはプログラミングに専念することが出来ます。
営業からの、
「
こんな機能追加出来ないかなぁ
」
とか、
テスト部隊からの、
「
テストシナリオを作ってくれ!
」
といった要望は、
いったんSEに入って、
それからプログラマに知らされます。
やったことのない人にはピンと来ないかも知れませんが、
折衝ほど面倒な仕事はないのです。
こっちが必死でロジックを考えている真っ最中に内線電話をかけてきて、
くだらない質問をされた時には思わず切れそうになります。
さて折衝や概要設計はSEがやってくれるとしましょう。
ではプログラマは本当にコードをごりごり書いているだけでいいのかというと、
答えはNOなのです。
もちろん、
自分の書いたソースにコメントをつけるとか、
仕様や制限事項をまとめるとか、
そういった周辺業務はありますが、
それはプログラミングの中に入れてしまった上の話です。
プログラマも所詮サラリーマンですから、
会社勤めをする上で必要な事務処理等は当然しなければなりません。
週末には週報、
月末には月間稼働表、
休日出勤前には休日出勤票…。
雑務は意外と多いのです。
会社によって事務書類の種類や量は違うでしょう。
前の会社なんてもっといい加減で、
週報の提出はなし。
タイムレコーダの情報だけが毎月総務に送られていました。
受託系、
派遣系の会社は無茶苦茶細かい週報を提出させられることがあります。
そうなるともうプログラムを書きに会社に行っているのか、
書類を書きに会社に行っているのか分からなくなります。
月間稼働表は私にとっては敵でしかありません。
労働者が一日何時間働いたかを会社が把握するのは、
雇用者として当然の義務ですから、
プログラマがそれを入力するのはまあよしとしましょう。
さらに細かい工数まで提出しなければならない会社もあります。
○月×日の何時から何時まで何をしていた、
というのをいちいち細かく入力しなければならないのです。
従業員が何万人といて、
現場作業員がひょっとして昼飯を食いに行ってからずっと食堂でくっちゃべっていても上で把握できない、
というような会社なら分からなくもないのですが、
小さなソフトハウスでそれをやっているなら無駄以外の何物でもありません。
多分親会社にまで提出しているからこうなっちゃうんでしょうけどね。
プログラマというのは大体がぐうたらな生き物です。
細かい仕事を押し付けられると、
「
なんだこんな単調な仕事、
スクリプトでも書いて一気にこなせばいいじゃないか
」
と思うのが普通です。
元来細かな事務作業には向いていません。
もちろんプログラムはちゃんと書きますよ。
でもそれ以外は我関せず、
という人が多いのです。
かてて加えて事務処理なんて、
総務の人が適当に帳尻を合わせておいてくれれば事足りる程度のものですから、
なおさらいい加減に処理してしまいます。
第一、
プログラミングなんて、
何時から何時まで設計をしていて、
おもむろに書き始める、
なんて仕事じゃないでしょう。
ところがそうは問屋が卸さない。
プログラマがいい加減に書いた書類を実際に処理してくれるのは総務の人です。
総務という部門は、
後で役所から注意されないよう細心の注意を払って書類を扱う部門です。
役所に提出する書類で従業員の労働時間が間違っていたりすると問題になるかも知れませんが、
たかだか何百人しかいない会社の、
しかも社内でしか使っていない月間稼働表に、
たとえば14時から16時まで何をしていたのか書いてないというような入力ミスがあったところで大して問題になるとも思えないのですが、
マネージャに連絡が入り、
書類は再提出です。
これも多分親会社が書類の提出を要求しているから起きる事件なのでしょうが…。
しかしこうなるとさらに何しに会社に行っているのか分からなくなってきます。
他にも様々な申請書や申込書があり、
いちいち署名捺印です。
これがお役所だの法律事務所だのならいいのですが、
「
これからはe-ナントカだ!
」
とかほざいてるソフトハウスの社内実態がこれですから吉本新喜劇も真っ青のギャグです。
愚痴っぽくなってきたのでこの辺にしておきますが、
プログラマも会社員です。
他の部門の人ともめないように、
社会常識をわきまえて行動しましょう。
現場の話は、
他にもいろいろあるのですが、
また次回ということで。
一番社会常識をわきまえてないのはお前だろって? その通りでございます。
| 第69話 二番目に好きなこと | 2000/03/27 |
先週は無断でお休みしてしまいました。
がっかりしてしまった方、
すみません。
そういえば普通、
こういうコラム系のページってそれなりにルールがあったりしますけど、
我が家にはそんなものありませんね。
一応自分なりに決めているのは、
さて本日の本題に移りましょう。
私、
いろんな人から
「
趣味がそのまま仕事になったの?
」
とか、
「
趣味はないの?
」
とか言われるんですが、
そんなことはありません。
よく、
「
二番目に好きなことを仕事にしなさい
」
といいます。
全くその通りで、
私もそうです。
プログラミングって、
私にとっては
「
二番目に好きなこと
」
なんです。
じゃあ何が一番好きなのかと言われると、
文章を書くことなんですよね。
誰でも子供の頃、
一度は
「
芸術家になりたい
」
などと言って親を困らせたことがあると思います。
ご多分にもれず私もそうでした。
絵が少々描けたのと、
作文が少し上手かった程度でしたが、
「
イラストレーターになりたい
」
とか、
「
コラムニストになりたい
」
とか、
バカなことを言っていました。
高校生の頃には同人誌も作っていました。
あっ、
エロ本じゃないですよ、
三国志とかの歴史もの、
オリジナルが多かったです。
ところが問題が一つあって、
文章を書くにもネタがない。
課題とかテーマを出されればちゃんと書けるんですけどね。
お陰で論文試験で困ったことはありませんが、
コラムニストになるなら自分の得意分野が最低でも一つはないとコラムそのものが書けません。
そんな情けない状態ですから、
職業としてコラムニストを選ぶことは出来ません。
コラムニストは夢としてしまっておいて、
二番目に好きなことを仕事に選んだのです。
考えてみればプログラミングと文章を書くことは少し似ています。
読んでくれるものが、
片方は計算機、
片方は人間。
言語は、
片方は文脈自由文法、
片方は文脈依存文法。
その程度の違いしかなくて、
論理的厳密性をどこまで要求してくるかは、
程度の差でしかないと思っています。
ところが、
プログラミングを職業に選ぶのも問題はありました。
先の文章と同じく、
私はプログラミングそのものは出来ても、
「
何をプログラミングするか
」
というテーマはなかったのです。
つまり、
自作ソフトは作れないが受託ソフトは作れる状態です。
ということは、
私は一番目に好きなことも二番目に好きなことも、
「
作る能力はあるが生み出す能力はない
」
状態にあることになります。
ただし、
仕事でプログラミングをするとなると大半は受託です。
自社開発のソフトを持っている会社でも、
中に入れば製品企画をする人が決めた通り
「
受託開発
」
をすることになりますから。
要求仕様は勝手に向こうからやってきます。
深刻なのはむしろ一番目に好きなことです。
誰かが勝手に
「
これをテーマにコラムを書いてくれ
」
と依頼してくるわけではありません。
でも趣味が
「
文章を書くこと
」
である以上、
何か書いていたい。
折角インターネットが身近になって、
安い料金でホームページが維持できるようになったことだし…。
プロバイダと契約した頃、
何をテーマにホームページを作るか迷いました。
コラムはテーマの選択と切り口、
そして取材能力が命です。
仕事の片手間に取材が出来る素材、
それは二番目に好きなこと、
つまり仕事でした。
かくして
「
この人は仕事のことしか頭にないのではないか
」
と、
人格を疑われるようなホームページの誕生と相成りました。
本人は
「
ネタみっけ
」
と茶化してるつもりなんですけどね。
いつの日か本気で取り組めるテーマを見つけて、
じっくり取り組んでみたいのですが、
まだまだ馴らし期間ということで(笑)。
にしても自分はつくづく幸せだなぁと思うことがあります。
二番目に好きなことを仕事に選べるだけでもかなり幸せなことだと思います。
世の中には好きでもない仕事を様々な理由で嫌々やっている人も多いというのに。
かてて加えて一番目に好きなこともこうやって思う存分楽しめる。
強いて希望を言うなら一番目・二番目ともにふさわしいテーマを見つけられればいいな、
とか、
もっと間口・奥行きともに広げられたらいいな、
とは思いますけれど。
一番目がこの程度なら二番目はたかが知れてるって? ピンポーン!
| Copyright (C) Ada72 All Rights Reserved. |