プログラマに必要なたった一つの力
この記事は小飼弾氏が，2008年3月24日に発売した日経ソフトウエア2008年5月号の特集「はじめてのプログラミング」向けに著したものの再掲です。記述された内容は，執筆当時の情報に基づいています。 あなた，プログラマになりたいんですって？ 本当に？ 本当に？ もう一度尋ねます。本当に？ 3回も念を押したのには，理由があります。このあと，さらに念を押します。この手紙を読み進めれば，あなたにもその理由がおわかりいただけるかと思います。 「日経ソフトウエア」を読んでいただいているからには，あなたは「プログラマ」という職業について，ある程度のイメージをお持ちだと思います。プログラマ，プログラムを作る人。では，プログラムって何でしょうか？ その定義は，これをお読みになった人の数かそれ以上存在しますが，私にとっての定義は「コンピュータが仕事をできるようにすること」です。ご存じだとは思いますが，コンピュ
NTTデータがウォーターフォールから脱却? - ひがやすを技術ブログ
筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３?８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して
プログラミングファーストでもまだ中途半端 (mark-wada blog)
ひがやすをｂlogで「プログラミングファースト開発の必要性」が書かれている。このひがさんのプログラミングファーストは以前あるセミナーでプレゼンを直接聞いたことがあるのでだいたいの考え方や内容も理解しているが、ぼくの感想はまだ中途半端のような気がする。まずはそのブログから。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 プロトタイプ開発との違いは、最初に作ったものを捨てずに、本番で動かすものとして開発し続けること。アジャイルとの違いは、全工程をテレーション（筆者注：イテレーション？）でまわすのではなく、顧客と仕様をつめるところのみを何度も繰り返し仕様が固まるまで行なうこと。 これは、現在のような人月ビジネス化し
プログラミングファースト開発のアキレス腱 : 404 Blog Not Found
2008年07月21日15:00 カテゴリArt プログラミングファースト開発のアキレス腱 ktkt. プログラミングファースト開発の必要性 - ひがやすを blog これをふまえて考えたのが、以前提案したプログラミングファースト開発だ。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 実は私自身、この言葉が生まれる前から実践してきたのだけど、一つけったいな問題点があるので、それを指摘しておく。 それが何かというと、 客がそれを安易だと勘違いして、安価だと思いやすい こと。 プログラミングファーストの場合、最早だと打ち合わせのその場で動くものを見せたりする場合がある。客が分かっている人だと、その事にボーナスを出
2008-07-22
タイトルだけで全て終わりそうだけどｗ、まあいいか。 メインフレームの事情について興味深く読んだ。 メインフレーム=ホストが最近では崩れ始めてるのはそのとおりだと思うし、 ホストが圧倒的な高可用性が出せるのも事実だと思う。 実際ちょっと前にホストの人と話をしたときには、最近のオープン系の進化も凄いけど ホストまわりの進化も並じゃないって言ってた。ハードウェアの進化の恩恵はかけられるコストと比例したりするので、 オープン系よりもホストなどの方がより直接的に受けれるっていうのもあると思う。 唯一違和感あったのは人材についてのところかな。 続きを読む T2をServlet3.0風に使ってみた。 多分これが一番プリミティブな使い方だと思う。 以下の例だと、通常のWebアプリからはGET/POSTなので、@Defaultがついたメソッドは 呼ばれることはないです。リクエストしたときも@GETのほうが呼
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
伊藤直也の「アルファギークのブックマーク」 - 誤解から賞賛へ。Ajaxで再評価されたJavaScriptから学ぶこと
■ Googleマップによる“Ajax”の隆盛 最近、「Ajax」という言葉を耳にすることはありませんか？ Ajaxとは、「Asynchronous JavaScript + XML」の略称で、「えいじゃっくす」と呼ばれています。このワード、半年ほど前に突然盛り上がりだして、いまではWebエンジニアの間ではお馴染みの言葉になっています。 今年の2月に、Googleが「Googleマップ」という地図サービスのベータリリースを行ないました。 地図に関するサービスは、これまでも数多く存在していますし、特にYahoo!やその他大手ポータルのそれは高機能かつデータベースも充実していて、実用性十分です。そんな地図サービス界隈に、いまになってGoogleが乗り込んでくる、というので、Webな人たちは固唾を呑んでそのリリースを待っていました。 そうしてリリースされたGoogleマップは、人々の期待を裏切ら
株式会社マジカジャパンの羽生章洋が書いてるブログ:本当にERPは効果を出しているのか？ - livedoor Blog（ブログ）
ERPと呼ばれるものがあります。エンタープライズリソースプランニングの略で、経営資源計画と訳されます。統合基幹システムという言い方のほうが最近では一般的になりつつあるようです。要するに大きな業務システムということです。 業務システムの世界は大きく二分されていて、フルスクラッチ派とパッケージ派に分かれます。そして日本はスクラッチ派がまだまだ大勢を占めており、パッケージを導入する場合にもカスタマイズと呼ばれる、つまりパッケージに独自修正を加える比率が非常に高いとされています。 この事態をして「日本の業務は」云々をいう方が多いです。いわくもっとパッケージに合わせるべきである、と。独自の業務にこだわるからシステムの導入に膨大な手間がかかるのだといいます。 さて、では海外で業務をパッケージに合わせて導入をした企業がその後いったいどれほどの業績向上を達成したのでしょうか。これを追いかけると、実はさほど
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
小野和俊のブログ:総務省「事業計画作成とベンチャー経営の手引き」がすごい件
ベンチャー支援をしている知人から、総務省のプロジェクトでこんなんつくりましたということで、「事業計画作成とベンチャー経営の手引き」という資料が送られてきたのだが、これが無料で配布されている資料とは思えないほどの非常に充実した内容で、いつか会社を始めるかもしれないと思っている人にはきっと役に立つだろうと思ったのでブログで紹介したいと思う。 冒頭に下記のように宣言されているだけあって、その内容は実に生々しい。 説得力ある合理的な事業計画」をどう作成し、日々の経営にどう活かすのか、相談相手の少ないベンチャー経営者の参考にしていただくこと、指針を少しでもご提供することを意図している。こういった努力の結果、日本から急成長ベンチャーが1社でも多く生み出されることを強く祈願したい。 P.5 総務省 ICTベンチャー向け事業計画作成支援コースの意義 より 事業計画作成について詳しく記された書籍は10年来多
いまさら聞けない「Webブラウザ」超入門
新人に捧げる「Webブラウザの仕組み」 皆さんが毎日利用している「Webブラウザ」。インターネットの創成期から現在まで進化を続けながら、一線で活躍する技術です。今回はこのWebブラウザについてあらためて見てみましょう。 前編・後編2回に分けて、前編ではWebブラウザとサーバの通信の仕組みや役割、後編ではWebブラウザやHTMLの歴史と未来について説明します。 基本的な説明ですが、読めば新しい発見があるかもしれません。 WebサーバとWebブラウザの甘い関係 インターネットを通じてWebブラウジングするとき、私たちはInternet Explorer（以下、IE）やFirefoxといった「Webブラウザ」ソフトを使ってWebサーバにアクセスします。Webサーバが画像やテキストといったデータをWebブラウザに送り、Webブラウザが情報を解釈して表示します。では、ここでのWebサーバとWebブラ
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
みえてきたSpringの戦略 - ひがやすを技術ブログ
ロッドジョンソンのこのエントリやHibernateの中の人のエントリをみるとSpringの戦略が大体見えてきます。 まず、Springの現状を整理すると VCから出資を受けた 教育中心のビジネスモデルでは、VCの期待するリターンを稼げない ということ、意外なのは、サポートはあまりビジネスになっていないということですね。 教育のビジネスは、長く続けるのは、実は難しいんですよ。一度教育を受けたお客様は、次の案件で引き続き同じプロダクトを使う場合でも、教育は二度は買わないから。ビジネスを継続させるためには、新規のお客様が、増え続けなければいけない。それに対して、サポートビジネスは、案件が続く間、サポートフィーを払ってもらえるし、次のプロジェクトでもきっと、サポートを買ってくれる。 教育ビジネスは、かならず人を張りつけなければいけないので、スケールしにくい。売上を増やそうと思えば、人を増やさなけれ
技術が枯れる瞬間の見極め - ひがやすを技術ブログ
ギークなら、わくわくするような新しい技術をいつも試してみたいと思っているでしょう。しかし、現実の開発の現場では、ギーク以外の人がほとんどなので、新しい技術には興味がないわけです。たぶん、新しいことを覚えること自体面倒だと思っているでしょう。 そういう中に新しい技術を導入するには、「生産性が高くなる」「開発が楽になる」ということをまわりに納得してもらわなければいけない。最初は、反対されるでしょう。自分が責任取るからと強引に導入しようとするときに、考えて欲しいのは、その技術の枯れ具合です。 新しい技術なので、枯れていないのは当たり前です。なにかあったときに、頼れる場所があることが重要です。頼れる場所とは多くの場合、MLやフォーラムなどでしょう。そこでのレスポンスが早ければ、多少枯れてなくても何とかなります。 何とかなるとはいえ、枯れていない状態が長く続けば、それだけ利用者の負担も増える(MLな
なぜ、SIerが「なにを」作ったのかを公開しないのか - ひがやすを技術ブログ
なぜ、SIerが「なにを」作ったのかを公開しないのか、それが私には不思議でならない。同じくソフトウェアを開発するものとして、納得が行かない。もちろんNDAの壁はある。私でさえ、開発に携わった事実そのものを公開できない案件をいくつか手がけて来た。しかし誰がどの案件を手がけたかすらデフォルトで非公開というのは理解に苦しむ。 あいかわらず弾さんの突っ込みは、内藤のフェイント(相手を見ずに自分の打ちたいところに打つ)のようだと思いつつコメント。 「NDAがあるから」デフォルトで非公開というのは、「あたりまえ」だと思うけど、これだけだとつまらないので、もうちょっと突っ込んで書きます。 一番の原因は、「公開することがお客様にとってメリットがない」あるいは「公開するとマイナスになる」ことが多いからです。 特に社内に閉じているようなイントラ案件は、自分たちの動きが同業他社に知られないように隠しておきたいも
WEB+DB PRESS Tech Meeting ［資料＆動画］｜gihyo.jp … 技術評論社
当日の講演資料と動画を公開です。 動画はニコニコ動画を利用して配信しています。ニコニコ動画のアカウントをお持ちでない方でも，gihyo.jp上で動画を再生できます（コメントの書き込みはできません）。 動画の最後でニコスクリプトを使ったアンケートを行っていますので，ニコニコ動画のアカウントをお持ちの方はご協力いただければ幸いです。動画をクリックすることでニコニコ動画の該当ページへアクセスすることができます（ニコニコ動画のマイリストはこちら）。 今回の動画公開にあたって，gihyo.jp用に新たなニコニコ動画プレーヤーを作っていただきました。この場を借りてニコニコ動画の方にお礼を申し上げます。 JavaScript Tips & Technique IT戦士amachangが最近のJavaScriptのテクニックやTipsについてご紹介します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
