クソな職場でのスキルの磨き方：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■クソな職場こそ良い踏み台になる 試練を知らないと成長しない。IT系の仕事をやっていて最近そう思う。もちろん、安定した職場で着実にスキルを高めている人もいる。だがそれは恵まれたごく少数の人たちだ。最近の企業は、呑気に人を育てるなんてしない。 よくよく考えてみよう。ロクに世話もしてくれないのに、最大限の成果ばかり求めてくる。ものすごく図々しい話だ。ビジネスでギブ・アンド・テイクを声高に掲げる割に、内輪でやってることはただの酷使だ。だったらどうする。別に仕事をサボるとか、上司に対して反乱を起こすとか、そういう事をしても無益だ。こういうクソな事をぼやく職場はきっちり踏み台として利用しよう。 ■職場の腐り方を分析する 職場の踏み方はいろいろある。プロジェクトが終了すればある
なぜエンジニアは勉強会で会社名を出せないのか：雲（クラウド）の隙間から青空が見えた：エンジニアライフ
■勉強会で自社名を隠す人々 今年の2月に転職して以降、勉強会やカンファレンスでの発表資料に僕は会社名を書くようになった。 2010年9月にコミュニティで初めてのライトニングトークをして以降、今年の2月に転職するまで、僕は合計9回、ライトニングトークや、セッションで登壇している。そしてそのいずれも、会社名はあえて伏せていた。 そういった場面で名刺交換をする機会はあっても、僕は個人で作成した名刺を使い、会社の名刺を出すこともしていない。その当時、僕がなんという会社に勤務しているのか、おそらくほとんどの人は知らなかったはずだ。 転職以降も、こういった活動は続けているが、今は自己紹介で、どこの会社で、どういった仕事をしているか名乗るようになった。名刺交換でも、会社の名刺を出している。 勉強会やカンファレンスに行くと、様々な人と出会う。登壇者と仲良くなることもある。そういった人たちと話をしていると、
「なんでRubyなんか作った!? 迷惑だ！」に対するMatzの答え：Rails Hub情報局：エンジニアライフ
2012年9月に行われた札幌Ruby会議2012の基調講演の1つで、Rubyの生みの親のまつもとゆきひろさんが、最近あった面白いエピソードを混じえて“イノベーション”の本質について語っていました（44分の動画）。ポイントとなる部分をまとめてみました。まつもとさんの話はもちろん、統計的裏付けだとか学問的裏付けがある議論というものではありませんし、ご本人も楽しそうに話し、聴衆も楽しんでトークを聞くというゆるい感じのものでした。ただ、「イノベーションの本質は捉えがたい」というメッセージや、「だからあれこれ考えずにコードを書こう、われわれはコードを書くことにアイデンティティを感じているのだから、それこそがハッピーになる道だ」というメッセージは、参加していたRubyistたちの胸に響くものがあったのではないかと思います。 以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半
人形つかい（終） エピローグ：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 2月1日午前9時、「承認くん」は無事に本番稼働した。 橋本さんが電話してきたトラブルはたいした問題ではなかった。ログに出ていた、 java.lang.OutOfMemoryError: Java heap space のメッセージを見ただけで原因は明らかだった。APサーバのJVMパラメータを確認すると、案の定、-Xmx128m になっていた。これはテスト環境用のパラメータだ。-Xmx2048m に修正して再起動することで、問題はあっさり解決した。 東海林さんとぼくは、高杉さんの言うとおり、午前10時まで待機していたが、まだ利用者が少ないこともあって、システムが止まってしまうような深刻な問題は発生しなかった。東海林さんはその間に、予備環境としてtomcatをインストールし、「承認く
人形つかい（22） それでも、生きてゆく：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 お許しをもらったぼくたちは、一度、港北工場の敷地から出た。数千人が勤務する工場なので、近くには喫茶店かレストランがたくさんあるだろう、と思っていたが、意外に数は少ない。たぶん工場内に――社員には――安い食堂が完備されているためだろう。 「何にもないですねえ。あそこのミニップ行きますか？」 「ミニップって何だ？」 「ミニストップのことに決まってるじゃないですか」 「知るかそんなもん。お前、何でもかんでも略して話せば、若く見えるとでも思ってるのか？」 「ぼくは若く見えるじゃなくて、実際に若いんです」 結局、道路を渡ったところにあるココス・レストランに入ることにした。午前7時から朝食バイキングをやっていたのだ。店内はこんな早い時間にしては混んでいたが、ぼくたちは運良くボックス席に座るこ
ホウレンソウ？ いや、その前に何かないか。：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■ある万年炎上現場でのワンシーン 「おまえ、ホウレンソウって、意味わかってるか？」 チームリーダーらしき人が怒鳴っていた。そして、鬼のような形相で部下をなじる。 「なんでお前、こんな簡単なこともできないんだ？」 たまにこんな光景を見かけないだろうか。ホウレンソウとは、言わずとしれた「報告」「連絡」「相談」の頭をとって「ホウ・レン・ソウ」と言われている。 チームリーダーは部下にホウレンソウを説く。これは絶対守るべき約束だと。しかしその前に、私はチームリーダーに「GUNDAM」を説きたい。 ■人の上に立つなら、GUNDAMくらい知っておくべし では、GUNDAMとは何だろうか。 Gorioshi （ゴリ押し） Uso (嘘) Najiru （なじる） Donaru （怒
人形つかい（12） 増殖する作業、減少する時間：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 カレンダーが最後の1枚になり、カットオーバーまで2カ月を切った。この時期になると、さすがにオンスケとはいかず、数日程度だが遅れが出るようになってきた。テスト部門からのフィードバックによって、いくつかの機能を追加したり、作成済みの機能に修正が発生したためだ。橋本さんは毎日のように必死で設計書を修正し、申し訳なさそうにぼくたちに渡しに来るようになった。 東海林さんもぼくも、20:00過ぎまでエースシステムで作業し、自社に戻って続きを終電ぎりぎりまで行う、という日々が続いた。土日もどちらか1日、または両方とも出勤して実装を進め、何とか進ちょくの遅れを取り戻そうと努力していた。今年のクリスマスイブは金曜日なので、ぼくは年休を取得して、彼女と2人でゆっくり3日間のクリスマスデートを楽しむつ
人形つかい（9）上級SEは無慈悲な夜の女王：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 結局、橋本さんからの確認完了の電話は、終電ギリギリになって、ようやくかかってきた。ぼくは礼を言うのもそこそこに、PCをシャットダウンし、戸締まりを確認し、セコムのコンソールでロックをかけると、駅に向かってダッシュした。ホームに駆け込んだときには、すでに列車のドアが閉まりかけていたが、必死の形相を哀れに思ってくれたらしい車掌さんがドアを開けてくれたので、かろうじて飛び乗ることができた。日頃の運動不足がたたり、ぼくは肩で息をしながら座席に崩れこんだ。 次の朝は、東海林さんと2人でエースシステムに行くことになっていた。電車の中で昨夜の話をすると、東海林さんは同情してくれるどころか、「バカかお前は」と舌打ちした。 「そりゃ明らかに仕様追加だろうが。そういう場合は営業を通して追加見積を出さ
人形つかい（6） タンスターフル：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 その日、ぼくは1人でエースシステムの開発室で実装作業を続けていた。東海林さんは以前担当していたシステムにトラブルがあったため、こちらにはこないことになっていた。 この案件は「半常駐」という話だったはずだが、いつしかなし崩しに常駐と化していた。テストデータなどをエースシステムから外に出すのを禁止されていたこともあったが、一番の理由はAフレを使う開発環境をどうしても構築できなかったからだ。エースシステム社内の開発PCには、運用管理ソフトのアプリケーション配布機能によって自動的に最新版の開発環境が構築されるが、同じことを自社でやろうとすると、膨大な量のプロパティファイルやXMLを手動で追加／修正する作業が必要となる。しかも渡された手順書どおりにやっているのに成功した試しがない。業を煮や
次世代ソフトを提案する。 ―Microsoft編―：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■PCで使うソフトは、ここ5～6年、進化していない 最近、ソフトウェア売り場に行っても、目新しいソフトがない。バージョンアップ品ばかりで、目新しさを引くソフトがない。 これではつまらない。そういうわけで、新たな時代を担うソフトウェアを提案してみたい。 ■ExcelとWordの究極合体「Exord」(エグゾード） Excelではページの尺をとるのがしんどい。かといって、Wordでは書式の設定やら難しい…。そんな悩みを一気に払拭するソフト。それが、「Exord」(エグゾード)。 基本的な画面の構成は、Wordのレイアウトの横に、Excelでおなじみのセル番号がついている。まさに、Excelの操作感でWordが使える。下書き表示にすれば、今まで使い慣れたExcelのような
個人個人の最適解：地方からの戯言：エンジニアライフ
私は仕事柄、特定のユーザーに向けたプログラムやシステムを作成します。私自身のレベルはさておき、プロジェクトとして最初から運用・保守に至るまで、ほとんどのフェイズに関連できるようこなしてきているつもりでいます。 「受託開発」と呼ばれる様式ですが、この種類の案件に携わっていると感じるなかなかに難しい問題があります。それは、どのような技術をどこまで適用させて利用してもらうか、という点です。 私は今までのコラムでも、比較的多く最新の技術に触れていかなくてはいけない、というスタンスで書いてきました。その考えはまったくぶれないのですが、「そこで身に付けた技術や知識を、実際の業務においてどこまで適用するか」「どのように適用させるか」という部分では毎回、頭を悩ませています。 業務上では、多種多様な制約が存在します。例えばそれは費用であったり、人員であったり、はたまた政治的な制約というのも発生します。往々に
うんこに種をまくと花が咲く ～うんこシリーズ Part1～：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■とある飲み会の席で 「○○さん、いつもうんこ、うんこって仕事中に呟くんです～」 うら若き乙女が、飲み会の席でこんなことを言っていた。 まぁ、食事中だということは目をつぶろう。そんなことで、話に花が咲いていた。言われた○○さんも、まんざらではないようでした。 うんこにタネをまいて（というかネタにして）、話に花が咲いたな。そんな風に思い、一緒にほのぼのしていた。 ■女子はただ嫌悪し、子どもは嬉々ととする。 「うんこに種をまくと、花が咲く」 コレを女子に言ってみたらどうだろう。「うんこ」という汚物を連想し、強い嫌悪を表すだろう。きれいなものやかわいいものが大好きな女子ほど、その傾向は強いように思われる。 なぜなら、「うんこ」は、かわいいやきれいの対局にあるものだから。
1分で分かれ！ Wordの使い方：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■エンター改行の連発禁止 コレをやる人はかなり多い。マイクロソフトの公式ドキュメントでもやってるくらいだ。以下のような場合にこの“エンター改行の連続挿入”をやることが多い。 行間を調節したいとき 画像を挿入するとき ページ変えたい時 確かに、目の前にあるエンターを連打すれば簡単にできる。しかし、コレをやっているようではプロとは言えない。1つひとつの方法について方法を検討したい。 ■行間設定をしたければ、段落の設定を使おう 行間の調節をするのに改行を入れるのはスマートでない。そもそも、1行の半分空けたい時、どうするのだろうか？ フォントの大きさによっても、空くスペースはまちまちになる。まさか、改行した部分のフォントを小さく設定するなんてことはしませんよね？ そんなこと
高慢と偏見（終） エピローグ：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 私は予定どおり、9月末をもって新部品調達システム開発プロジェクトを後にした。苦楽をともにした開発メンバーと別れるのは寂しいが、正直なところ、これ以上、あの時代に逆行したような開発を続けずに済んで、心の底からほっとしている。 アツコさんとは、たまにメールを交換していたが、アツコさんの契約が年末で終了すると同時に、それも次第に疎遠になっていった。 冬が過ぎて、春がやってきたころ、K自動車の新部品調達システムが完成したという話を、営業の黒野から聞いた。 「へえ、やっと完成したの」 私は気のない返事をした。もともと新年にカットオーバーの予定だったから、まるまる四半期分の遅れが出たことになる。 「完成したのはしたんだがな。最初からトラブル続きみたいだな」 黒野も詳しいことは知らなかったので
高慢と偏見（13） 一矢：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 水曜日の朝。 三浦マネージャが開発室に入ってくるなり、佐久間くんはあいさつもそこそこに、うれしそうに報告した。 「修正、完了しました！」 声にならないどよめきが開発室の中に満ちた。一番驚いていたのは、三浦マネージャだろう。 「本当かね？」三浦マネージャは疑わしそうに佐久間くんの顔を見た。「じゃあ、動かしてみてもらおうか」 「はい！」 佐久間くんは自席のPCに戻ると、Eclipseを起動した。三浦マネージャは隣の席で、腕を組んで待っている。たまたま近くにいた私は、素早くすぐ後ろの位置を確保し、そっと画面をのぞき込んだ。何人かのメンバーも同じように、いろいろな方向から画面を見ていた。平良さんは同調せず、「結果は分かっている」と言わんばかりに、落ち着いた表情で自分の仕事をしている。 「
高慢と偏見（11） 現実は映画じゃない：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 レビューは三浦マネージャを完膚なきまでに打ちのめした。 若槻さんと私は、手際よく各クラスとメソッドの説明を行った。最初はバカにしたような態度だった三浦マネージャも、次第にオブジェクト指向の利点に気が付いてきたようで、こっそりメモを取っているのが見えた。 それでも何とか理屈をつけてはAチームの有利さを強調しようとしたが、それらの主張は私たちの的確な反論によって、次々と粉砕されていった。Aチームの新人くんたちでさえ、自分たちの書いたコードの欠点をつぶやき始める始末だった。 レビューの途中から、偉そうな顔をしたシステム部の部長が入ってきて、私たちの説明に賛意を示すように、いちいち頷いていた。そして、両チームのレビューが終わると、つかつかと進み出て、三浦マネージャに指をつきつけたのだ。
止まらないバグとコメントの嵐：効率化が嫌いなプログラマ：エンジニアライフ
難しいことを簡単にすることがSEの仕事なのか、簡単な仕事を難しくしないことがSEの仕事なのか、難しいところです。 開発環境の構築をするためにVMware Serverを導入して、2年ほど経った。 「効率化」が嫌いなのに、VMware Serverで開発環境を構築して、コピペでできる開発環境で構築時間を短縮することで、新プロジェクトに取り掛かる際の効率化（時間短縮）になればと思ったのだ。ライセンスはかかるため開発コストの圧縮まではできなかったが……。 ただ、たまにどこに何が入っているか分からなくなった時、効率化したつもりが非効率的になっている気がして、げんなりする。結局は運用まで検討しなければ、効率化にはならないのですね。目先の対応はいけません。 ＜重なるバグ＞ 僕は、いつもと同じように、MSプロジェクトに書かれた自分のスケジュールを確認して、コーディング作業に入っていた。 いつもと同じ、変
高慢と偏見（6） いつかの誰かのためのドキュメント：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 三浦マネージャがプロマネになって2週間が過ぎた。表面上は、それまでと変わらない開発風景だったが、水面下では激しいゲリラ戦が繰り広げられていた。とはいっても、敵、つまり三浦マネージャだけが、それに気付いていなかった。 三浦マネージャが不在だった月曜日、私たちは「すでにできているクラス」を作るのに全力を注いだ。たぶんムダなメソッドもたくさん作られたのだと思う。普通なら必要になった時点で作成すればいいものを、各メンバーの予測で作ったのだから。私も3つぐらいコミットした。 火曜日に戻ってきた三浦マネージャは早速、開発のあらゆる局面に口を挟み始めた。メンバーの誰かが平良さんに相談にいくと、横からじっと見ていて、おもむろに、 「そこは、○○と書いた方がいいね」 とか、 「それは分かりにくいだ
ソースコードの可読性や保守性：地方からの戯言：エンジニアライフ
プログラムの品質を表す、数多くの指針の中に「保守性」と「可読性」があることは、多くの方がご存じでしょう。そしてその指針について、今までも多くの議論がなされてきたことと思います。ですが、今に至っても議論の対象となりやすい話題ではないでしょうか。 新たに発生した要求に対応するためにプログラムを修正する際、それが容易であるかどうかが、保守性を考える指針となります。この場合、プログラムのソースコードだけに目がいきやすいですが、実際にはドキュメントなどの「ソースコード以外」も重要です。 もう1つの可読性とは、ソースコードがいかに読みやすいか、理解しやすいかについてです。コーディング規約などで定義されるもので、メソッドにおける行数やコメントの記載、命名規約などがそれに相当します。 開発をしている方でしたら、実施しているかどうかは別としても、このような定義には通じられていることと思います。 定義だけを見
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
