四捨五入して30歳。酒と歌を愛します。飲み屋で社長と知り合ったのが人生の転機。事実は小説よりも奇なり。 早速、作業に取り掛かろうと思った。 メソッドは確かこうだったなぁ、などと考えながら書いていく。実は、レビュー用にと思って、ソースを印刷していたものがあった。少し古い状態のソースだが、ないよりははるかにましである。 分からなくなったらそれを見て確認し、作業を進めていく。ふと、横を見るとツルマキの手がまったく動いていない。 「どうしたんだ？」 気になって小声で話しかけた。左手にはエグチさんがいる。気づかせてはいけない。 「全然覚えてない」 「え？」 「ソースが全然思い出せない」 なんということだ。連日質問をし、周囲が一生懸命回答してそれを四苦八苦しながら自分なりに消化して書いたソースを覚えていないというのか。もちろん全部覚えているのは無理だろうが、まったく覚えてないとは……。 「例えばLoa

四捨五入して30歳。酒と歌を愛します。飲み屋で社長と知り合ったのが人生の転機。事実は小説よりも奇なり。 僕の名前はウエダ。今年からシステム開発会社の一員になった。外部研修でJavaを学んだけど、結局よく分からない。メソッドって何？ オブジェクト指向って何？ そんな状態で、あっという間に1カ月の研修は終わってしまった。正直何ができるのか皆目、見当がつかない。憂うつな気持ちで社内に戻った。 社内研修はこれから続くから、そのとき頑張れればいいよ、と同期のオオタニは慰めてくれた。こいつは大学時代からバリバリプログラムを組んでたから、研修程度のレベルではまったく物足りなかったらしい。 研修所の先生は「このころの実力差なんて1年もすればなくなるもんよ」といっていたが、果たして本当なのだろうか……。いまいち信用できない。 そんな風に思っていた折、会社の創立記念日に新しい人が2人入ってきた。 名前を、ヒラ

刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ

エンジニアとしてどうあればいいのか、企業の期待とどう折り合いをつけるのか、激しく変化する環境下で生き抜くための考え方 企業における戦略的IT活用を推進していくIT人材の役割は、今後ますます重要になると考えられます。しかし、その能力向上を妨げる大きな問題が表面化している側面も明らかになりつつあります。 昨今のオフショア開発の拡大や、今後はクラウド・コンピューティングの普及が現実的なものになることから、「ソフトウェアを作らない時代」への急速なシフトが考えられます。 それに対応するIT人材の可視化や能力定義が喫緊の課題となっており、さらに作らない時代へのシフトから、OJTなどでの経験を積める環境が無くなる可能性が大きく、IT人材の能力向上策やキャリアプラン策定に、大きな障害になることが考えられます。 IT人材の将来は IT企業では、筆者の知る一番深い下請け構造は16階層でした。大手が請けて利益を

いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 なんでこのタイトルかって？ 語呂が良かったからです。 実は私、作詞をやっておりまして。あわよくば、1曲くらい私の書いた歌をプロが歌ってくれたら。そんな淡い夢を抱いております（笑）。 ■ミーティング中、とある曲を思い出した とあるプロジェクトでのミーティング中のことです。いつものように激論（？）のようなもの、いわゆる駆け引きというやつを激しく繰り広げていた。 細かい内容は覚えてないんですが、「あなたの会社と仕事がしたい。関係を大事にしたいので聞いてほしいことがある」という内容だった。ちょっと離れた立場から聞いていたので、言葉の一言一句を聞きながら、妄想にふけっていた。 信頼から受注に至るプロセスって、恋愛から結婚に至るプロセスに似ているなぁ。そんなことを思いながらやり

本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部がおすすめするコラムを紹介しよう。物覚えが悪いことのメリット、Google Developer Days 2010 レポート、ライブコーディングの魅力、の3つのコラムを取り上げる。 分かりやすいコード Google Developer Days 2010に行ってきました 美しいコードに鼻血をふいてもいいですか？ 1週間後の自分のために、分かりやすいコードを書く シンガポールで働くエンジニア 山本保男氏による『アジアのソフトウエア開発現場にて』。物覚えが悪いことと、可読性の高いコードを書くことの意外な関係。 「自分は恐ろしいほど物覚えが悪い」、山本氏はこう切り出す。物覚えが悪いということは、どちらかといえばあまりいいイメージがない。しかし、プログラ

近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読

少しご無沙汰しています。 今回からまた新しいシリーズです。ソフトウェアに関係する事柄のあれこれについて書いてみたいと思います。3回程度の予定です。 今回はコーディング規約についてです。コーディング規約がどんなものかはプログラマやSEなどを経験していれば知らない人はまずいないと思います。会社としてきちんとドキュメントになっているところもあれば、部や課、プロジェクト単位で適用している所もあるようです。 ただ、わたしの経験では、なぜか、なかったところの方が多かった気がします（気がするというのは実際はあったが見たことがなかっただけかもしれないので。もっともそれじゃないのと同じですが）。 現在のわたしの状況に関しては、「なかった」ので、わたしが作ってメンバーに周知しています。わたしが作るコーディング規約に関しては基本的にA4用紙に1枚程度の量で、そんなにきつく縛っていません（たぶん）昔ほどコーディン

わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他

ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。 K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。 「オブジェクト指向など、実業務では使いものにならない！」 私の名前は川嶋ミナコ。横浜市内の某所にオフィスを構えるシステム開発会社――いわゆるベンチャー企業というやつ――に勤務しているエンジニアだ。社員数は20人前後。最近は受託開発の案件はほとんどなく、大手ベンダやエンドユーザーのシステム部門に常駐して開発を行うことが多い。 K自動車への常駐もその1つだった。部品調達システムの大規模なリニューアル中で、あちこ

玄米茶さんの「気難しいプログラマ：4.あなたの問いかけに反応が悪いとき」を読ませていただきまして、おもわず「分かる分かる～」とつぶやいてしまいました（苦笑）。 ということは、わたしこそが「不機嫌なプログラマ」に違いありません。なんかもう、あっちこっちに向かって「ごめんなさい」といいまくらなければいけないような気がしてきました……。 コーディングは脳内リソースを食い散らかすので、集中してロジックを考えたりコードをタイプしているときに割り込みが発生すると、頭の中で展開中のものがグチャッとなって、なんとか収拾つけようとしてかる～くパニックをおこし、その結果、反応がえらく鈍くなります。あれですよ、CPU使用率が100％になったまま天井にはりついちゃってる感じですよ。 この動きが止まっている状態をみて「反応が悪い」＝「機嫌が悪い」ととられることがままあるようなのです。ていうか、正直なところ、本当に機

シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしは48才ですが、プロのプログラマとしての経験は10年以下。プロのプログラマになる前は、コンピュータ関係の仕事ではありましたが、別の職種でした。事情により、前の職種で仕事を続けることができなくなったため、約10年前に、一念発起して前からなりたかったプログラマに職種変更したのです。 わたしが就職した1985年ごろ、そうです、今は昔、”Japan as Number 1” の時代です。今でも、日本のソフトウエア開発の現場だけが、まだその呪縛から完全に抜け切れていないようなのですが、その当時のソフトウエア開発では、実際にコードを書く人はコーダと呼ばれ、詳細設計書に書かれた内容をコードにほぼ1対1で書き写すだけの、かなり単純な仕

チョコ配る？ 配らない？ 予算は～？ という声の中、聞こえないフリして仕事を続けているdemitasuです。 ■プロジェクトに恋愛感情は無用 社内恋愛カップルがプロジェクト参入して、よかった結果など一度もありません。そんなことないよっていう人もいると思いますが、それは付き合っている人たちだけ。周りは気がつかないフリをしてることが多く、仕事に影響が出始めた時にその取り扱いに悩むわけです。 ■栄枯盛衰 あるカップルを紹介しましょう。彼は初PM、彼女はSE2年目という、典型的？ なパターン。当然、付き合っていることは隠しているつもり。でも仕事をレビューすると、なんとなくほころびが見えてくるものです。 各PMが担当しているプロジェクトの進捗報告とともに工程／担当区分の用紙を配布します。作業内容をレビューして明らかにおかしかったものに気がつきました。その人だけ作業量が極端に少ないのです。普通のSEが

バッチ処理はSQLの一括処理で行うべきです。 しかし、バッチ処理を一括処理で行うときには一括でできる処理量の限界は存在し、それはマシンのスペックによって違います。限界を知っていれば怖くはありません。これまでも何度か、開発ではなく、テストや保守でも、SQLができるかどうかで大幅に工数が違うと書いてきましたが、それも合わせて、限界をみていきましょう。 条件はテストサーバがあって、本番と同じデータが入っているとしましょう。対象となるメインのデータの入っているテーブルをTableAとし、対象の処理は日次バッチだとします。 負荷テストの手順は以下の通りです。 現時点のピークを特定する ピーク時点のリソースの消費量を測り限界を予測する テストデータを作る 予想した限界量のデータでテストする ■ 1．現時点のピークを特定する まずは、本番と同じデータですから最も多くのトランザクションが起きている日を特定

月刊「Windows Server World」の連載コラム「IT嫌いはまだ早い」の編集前原稿です。もし、このコラムを読んで面白いと思ったら、ぜひバックナンバー（2006年12月号）をお求めください。もっと面白いはずです。なお、本文中の情報は原則として連載当時のものですのでご了承ください。 IT業界には実にさまざまな職種がある。その中には、IT業界に入って最初に務める職種もあれば、一定のキャリアを積んでから務める職種もある。また、意図的、あるいは偶然に職種転換を行うこともある。 今月は、ITエンジニアの職種転換、つまりキャリアパスの話である。誌面の都合で今回はプログラマ系の職種に限定するが、他の職種でも成り立つ部分があるはずだ。 ●ITエンジニアの職種 同じITエンジニアであっても、職種によってステータスが違う。高いステータスの職種は、それだけ多くの経験が必要とされているからだ。筆者が日頃

ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。SEとPGの分業がIT業界にもたらしている問題が今回のテーマです。 ●SEとは何か、PGとは何か まずそれぞれの職分を正しく認識することからはじめましょう。プログラマ（PG）とはどういう仕事をする人たちでしょうか。 いうまでもありません。プログラムを作る人たちのことです。大工さんは家を作る人、漁師さんは魚を取る人。こういった人々と同様にPGもその仕事の内容から自明です。 一方SE――システムエンジニアの方は必ずしもそうではありません。システムのエンジニア？ システムの技術者？ ひどくあいまいな言葉です。この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。海外のコンピュータ技術書にもSEという言葉はほとんど見かけません。日本人が適当に言い始めた言葉だとしたら、あいまいなのも当然です

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 前の続き。 上から目線ですまないけれど、イロイロと考えさせられたので、もったいないから書いておこうと思う。新人は「ググれよ！」がよいタイプと「ググるな！」がよいタイプがいるなと思い至りました。ので、そのことについて。 若者が常識を知らないというのは当たり前なのです。いつの時代も「最近の若者は……」と言われてきました。 「在庫」を知らない、というのはかなりヤバいというか、わたしらの時代なら、「幼稚園からやり直せ～ぇ！」っていわれてたと思う。ただ、若いうちはそういうことがあっても良いのです。笑われるのも、叱られるのも仕事のうちです。 というわけで適切な例かは分かりませんが、「在庫ってなんですか？」というレベルで笑われたとしましょう。常識を知らなければ笑われて当たり前