孤独なソフトウェアエンジニアの味方です - rabbit2goのブログ
好きでやっているソフトウェア開発の仕事だけど、周囲を見渡すと実はこんな仕事は好きではないと言い切る人が多くて驚いたことがある。与えられた仕事だけをやっておけば万事OK、チーム全体のレベル向上やプロセス改善、新しい創意工夫なんて自分には関係ないことだし、そもそも仕事に関係しない余計なことに巻き込まないで欲しいと、面と向かって言われたこともある。会社で働く人の目的は実に様々なのだ。 このような開発者が増えてくると、チーム全体としての品質・生産性向上なんて見込めなくなるし、投資対効果を求める会社としては「スキルなんか要らないから人月単価の安い人が欲しい」と外部の会社に求めるようになってくる。一部のやる気とスキルのある人たちが方針と手順を決めて、残りの人はそのルールに従うのみという「ソフトウェア工場」が出来上がるわけだ。 ソフトウェアエンジニアとそれを取り巻く不幸な環境は、長い年月に渡って形成され
生き残れなかったエンジニアとは？エンジニアとしての死とは？ - しんさんの出張所 はてなブログ編
http://slashdot.jp/askslashdot/article.pl?sid=08/03/16/041249 表現力とは、例えば図面を書く能力であったり、コードを書く能力であるのですが、それだけではなく人に物を伝える能力や統率力も含まれます。 図面を書いたり、コードを書く直接的な表現力は、歳を重ねるごとに絶対的（手が遅くなるとか、直感的な思いつきが減って考える時間が増えるとか）・相対的（新しい手法をもった若手が増えることで、結果的に同じ事を表現するのに時間が掛かるようになったり、そもそも新しい環境向けたハード・ソフトを設計できなくなる）に失われていきます。 http://slashdot.jp/askslashdot/comments.pl?sid=393811&cid=1313966 これはないと思う。やっぱりずっとコードかいてる人はどんどん効率のよいコード書くようになって
素のPHPをテンプレートエンジンとして使うときのコーディング規約
プログラムとしてPHPを書くときのコーディング規約は、PEARやZendなど代表的なものがたくさんありますが、テンプレートエンジンとしてPHPを使う場合にはそのまま適用しにくいものです。 テンプレートエンジンのコーディング規約って、検索してもあまり見つからなかったので、個人的に採用しているものを晒してみます。あんまり語る人を見たことがないので、「俺はこうしてるよ」とか「ここキモくね？」とかご意見いただけるとうれしいです。 目指すところ 複雑なロジックをテンプレートに書かない / 書けないように規約で縛る 少しでも読みやすさを追求する できあがりのHTMLの美しさも追及する <%= $this->doctype() %> <html> <head> <%= $this->headMeta() %> <%= $this->headLink() %> <%= $this->headTitle()
無知なリーダーに対してはメンバが自分で判断して動いてしまうことも必要かも
無知なリーダーがもたらす災厄 - Basic 無知というのは恐ろしい。ほんの少しばかりの好奇心を持って書籍を読んだり、ブログを読んだりして勉強していれば当然知っているはずのアタリマエの知識を知らなかったりする。しかもこの人はチームを取りまとめるリーダーという存在なのだ。効率の悪い作業方法をメンバに命じて、結果的に組織へ損失をもたらしているのに、その結果に気がついていないのだ。 無知というのは恐ろしいというのはその通りなんだけど、これはリーダー一人を責めても仕方ない面もあるかなとは思う。 私自身、評判のイマイチなSIerに長く在籍していて技術力や知識の無い人と一緒に仕事したり山ほど見てきたりして麻痺しているのかもしれないけど、上記のようなケースでは配下のメンバーから突き上げが必要なんじゃ無いのかなぁとも思う。 例えば上の例だとコミットメールを引き合いに出しているけど、配下メンバーが誰もSub
リーダはコードに関心を持つ（3）: 柴田 芳樹 (Yoshiki Shibata)
リーダがコードに関心を持たないような組織においては、継続的インテグレーション環境を導入してビルドやテスト実行だけでなく、FindBugsを含む様々な静的解析ツールを実行させても、それらの結果に関心を持たなかったりします。 ビルドの失敗に関しては、どのような原因で失敗しているのかログを見ることで、現場の開発者がどのような開発をしているのかが分かる場合があります。たとえば、単純なコンパイルエラーが発生していたりすると、開発者がローカルでコンパイルもせずにコミットしている可能性があります。 FindBugsの警告の内容を確認することで、どのようなコードが書かれているのかも理解することができます。そして、警告が何日も放置されているようなら対処するように指示する必要があります。 カバレッジの結果を見て、テストが十分に行われているか、特に、C2カバレッジまで測定できている環境であれば、テストで条件漏れ
リーダはコードに関心を持つ（2）: 柴田 芳樹 (Yoshiki Shibata)
実際に書かれているコードの品質を確認できない、しないリーダであれば、単にスケジュール管理だけになりがちです。そのため、品質優先ではなく納期優先の管理となったりします。遅れが発生した場合に、何が原因かということに対して現状把握を行い対策を打つことをせずに、担当者に「納期に間に合うように対策を考えて再スケジュールしなさい」という指示だけだったりします。 しかし、遅れの原因は、仕事の難易度が高かったり、あるいは、担当者のスキルレベルが低かったりすることがあります。その場合、コードを書いている担当者は、遅れを挽回する対策を考えることは無理かもしれません。しかし、リーダは、コードを見ることもないので、再スケジュールしなさいとか、早く不具合を修正しなさいとしか言えなかったりします。 リーダがコードを読んで品質を確認できることは、仕事の難易度と技術者のスキルレベルを把握して、適切な仕事の割り当てを行い、
レビューのアウトプットは、レビューアのレベルを超えない（2）: 柴田 芳樹 (Yoshiki Shibata)
開発組織としてメンバーのスキル向上を行うためには、経験豊富なエンジニアの知識をレビューという形式で伝えていくことが重要です。そして、たとえ初心者であっても、繰り返しきちんとしたレビューを受け続けることにより、成長させていく必要があります。コードレビューは、ソフトウェアの品質を作り込む場でもあるのですが、同時にエンジニアを教育する場でもあったりします。 しかし、開発組織がコードレビューに関して否定的だと、開発プロセスでレビューすることが規定されているというだけの理由で、初心者レベルのエンジニアだけでレビューを行わせたりします。ここで「初心者レベル」というのは、ソフトウェア開発経験年数が少ないという意味ではなく、きちんとしたコードを書くということに関して初心者レベルという意味です。 コードの品質に興味がない人がリーダとして開発チームをリーディングしている場合には、開発が遅れてくると大量に初心者
ソフトウェア開発が好きでないサラリーマンエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
ソフトウェア開発は、自分で考えて手を動かしてプログラミングして動くものを作ることを繰り返す訳ですが、そもそもソフトウェア開発という「物作り」を好きではないサラリーマンエンジニアが日本には多いのではないかと思います。 その理由は単純で、新卒新人でも中途入社であっても、自分で分析・設計から実装・デバッグまでするのが好きな人を採用していないからだと思います。たとえば、メーカーでソフトウェア開発部門に配属されるような新卒新人でも、大学ではほとんどプログラミングしたことがない人をメーカーは採用します。中途採用であっても、採用面接でプログラミングを伴う技術的な質問をほとんどしません。 その結果、企業の中には、本当にソフトウェア開発が好きなソフトウェアエンジニアと仕事だからというサラリーマンエンジニアがいることになります。そして、サラリーマンエンジニアは、そもそも好きではないので、業務がこなせるようにな
プログラマ70歳定年説
最近またプログラマ35歳定年説をよく目にするようになりました。 「日本の典型的なSIerの世界では」という前提であれば、35歳定年説はあながち間違ってないのかもしれません。でもその前提となっているSIerの体制自体には大きな疑問を感じます。いったい何が問題で、どうすれば生涯プログラマとして生きていけるのでしょう？ 日本のSIerの不自然なカースト制度 プログラマ35歳定年説はPM・SE・PGといった日本のSIerの不自然な職種分離が最大の原因です。 PM/SE/PGは別のスキルが必要なのに、年齢とともにジョブチェンジしていかなくてはならないプレッシャーがあります。大手SIerではろくにプログラマを経ることなくいきなりSEとしてデビューしたりもします。 こんな変な仕組みが出来た原因はソフトウェア開発の本質があまりわかってないときに製造業モデルを無理やり当てはめたからではないでしょうか。 この
Linux上のApacheで，複数のWebサイトを同時テストできる環境を作る （仮想ホストでサイト住み分け ＋ SVNフックスクリプトで自動デプロイ＋ユーザ認証でチーム作業） - 主に言語とシステム開発に関して
複数のWebサイトのメンテナンス作業を，Windowsマシン上で実施しているとする。 各Webサイトのソースコードは，別個のSVNプロジェクトに属する。 これらの全Webサイトを，１台のLinuxマシン内の１台のWebサーバで動作確認したい。 しかもSVNコミットした瞬間に，すぐ動作確認できるようにしたい。 さらに，複数人から成るチームで作業できるように，リポジトリ操作にはユーザ認証をかけたい。 以下は，そのような環境の構築方法。 全体構成図 （１）Linux上にApacheを導入 （２）Linux上にSubversionを導入 （３）Linun上のSubversionを，WebDAV経由で利用可能にする （４）Windows上でTortoiseSVNを導入 （５）Linux上に複数プロジェクトを作成 （６）Linux上のSubversionに，フックスクリプトで自動デプロイ設定 （７）W
作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな
さて、アルゴリズムの勉強のしかたと、ラムダ計算の勉強のしかたの目星をつけました。 アルゴリズムの勉強のしかた - きしだのはてな ラムダ計算の勉強のしかた、プログラム意味論 - きしだのはてな これでここで書いたプログラムの理論の基礎は勉強できたことになるんじゃないかと思います。 プログラムの理論とはなにか - きしだのはてな ところで、プログラムの勉強地図としてこういう図を書きました。 で、ハードウェアまわりについても、プロセッサを支える技術やネットワークはなぜつながるのかでひととおり勉強したとしましょう。 じゃあ次は、アジャイルか？テストか？UIデザインか？となるわけですが、やはりプログラマなら、プログラムの作り方や使いやすさの前に、作るプログラムの機能や性能で勝負したいじゃないですか。 いい感じに関数が分割できるよとか、読みやすい名前がつけれるよとか、効率よく仕事して定時に帰れるよと
無知なリーダーがもたらす災厄 - rabbit2goのブログ
隣のチームの仕事ぶりを知ると、自チームで当たり前に出来ていることが全然出来ていなかったり、或いはその逆のケースも有ったりして興味深い。ペアプログラミングなんて言う言葉があるけれど、チームリーダは隣のリーダと一緒に働いて互いの働き方から学ぶべきではないかと思ったりする。リーダーがペアでマネジメントを行えば、もう少しマトモになるチームも多いのではないだろうか。 以前に見たある開発チームでは、ソースコードのコミットの度にその旨を通知するメールをメンバー全員に手作業で送っていた。もちろん、手作業だから忘れることもあるし、必要な情報が欠落していたり、誤記が有ったりする。そんな面倒で、しかも不確実な作業をなぜ繰り返し行なっているのか担当者に聞いてみたら「それが決まりだから」という返事しか返ってこなかった。 ルールであることは分かっている。知りたいのは「何のためにそのようなルールがあり、メール送ることが
オブジェクト指向を理解したければRubyを使え！ - 是非に及ばず
普通の構造化プログラマーがオブジェクト指向の存在意義を理解するコツ を読んで脊髄反射してみる。 自分自身がRuby信者(笑)なので、Rubyをおすすめするわけなんだけども、中途半端にオブジェクト指向機能が入っている言語で学習したところで構造化プログラミングから抜け出せないんじゃないかなと思う。 環境が人を作るという事もあるので、まずは全てがオブジェクトであるRubyでしばらくプログラムしていれば、オブジェクトの世界で自分がどう歩くべきか自然と分かるんじゃないかな。 なにしろ、Rubyの世界にはオブジェクトしかないわけで、int型とかなくて1とか2とかの数字は実はFixnumクラスのインスタンスだったりする。だから、1.to_sだとか、1.absなんてのが実行できるし、1.methodsで1が持つメソッド一覧を取得できたりする。 なにそれ、すげー！と感じたら、あなたは分かっている、または分か
Twitter 社採用面接受験記 - elm200 の日記(旧はてなダイアリー)
1ヶ月ほどまえに、私はシリコンバレーを訪れたのだが、そのときサンフランシスコの本社で Twitter の採用面接を受けてきた。結果は残念、ということだったのだが、その経緯について書いてみようと思う。 なぜ Twitter 社の面接を受けたのか。7月の終わりころ、私はシリコンバレーで働くにはどうすべきなのか、ということについて頭を悩ませていた。考えながらぼうっと Twitter のタイムラインを眺めていたのだが、Twitter が日本人エンジニアを求人しているという情報が飛び込んできた。おお〜、と思って軽い気持ちで職務経歴書を Twitter に送ってみたのだ。 相当数の人たちが職務経歴書を送ったはずだし、私は書類選考で落とされると高をくくっていた。ところが、数日してTwitter の人事担当者からメールがあり、電話面接をやるからいつがいいか？という。まさかの展開に私はやや慌てた。電話面接を
プログラマ35歳定年説、定年後の未来 - GoTheDistance
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
プログラミングは「名前」が9割。 - このブログは証明できない。
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは？」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアかく語りき
IPA セキュア・プログラミング講座
コラム 2011/7/26 【第151回】35歳定年説の真実
