アジャイルのレイヤ 〜 アジャイルを整理し直して理解する - kuranukiの日記
【アジャイル】という言葉は、システム開発の世界ではかなり一般的な言葉になりつつあります。大手のSIerの経営者までが当たり前のように使うようになったことは、ある意味で感慨深いものです。しかし、言葉としてメジャーになりつつある一方で、その言葉の本当の実体を理解しないで誤解したまま使っているケースが多くあるように思います。アジャイルで開発すれば「速い・安い・旨い」が手に入るという誤解や、プログラミング工程だけで使う手法だという誤解、朝会やふりかえりをすることがアジャイルだという誤解、などなど。どれも、完全な誤解という訳ではなく、あながち間違いでもないところが、さらなる混乱を産んでいるように感じます。 最近では、アジャイルの事例も多く出てきたように思いますが、それらの事例も具体的にどういったことを実践したからアジャイルだったかと問われるとそこに明確な答えは無いように思えます。アジャイルとは何か、
日本のソフトウエア産業、衰退の真因
ソフトウエア・エンジニアリングのリーダーの一人、エド・ヨードンは1992年に、『Decline and Fall of the American Programmer 』を著し、米国のソフトウエア産業の衰退と挫折を警告した。この本を出す少し前まで、彼は「この国が危ない（A Nation at Risk）」というタイトルで講演行脚をしており、同書はそれをまとめたものである。 この本の中で、ヨードンは日本をソフトウエア開発における優等生の一人として挙げ、インドの飛躍を予見している。本が書かれた時点では、インドのＩＴ産業はまだ黎明（れいめい）期にあったが、彼の予想通り、現在は英語圏で質の高いソフトウエア開発力が得られる国として、欧米から頼られる存在になり、ＩＴ立国を目指す他のアジア諸国からお手本と見なされるまでになった。 「この国が危ない」というヨードンの警告に触発されたのか、米国上院の「米国の
日本のソフトウエア生産性と品質は世界最高水準〜なぜ日本のソフトは国際競争力がないのか。 - 木走日記
●日本のソフトウエア生産性と品質は世界最高水準〜ではなぜ日本のソフトは国際競争力がないのか。 私の知人のアメリカ人スティーブ氏はＩＴコンサル業として長年日本で日本人スタッフとともにシステム開発に携わってきました。 同業者でもある彼は私の良き飲み仲間でもあり、私とは長年仕事の話から政治・経済の話まで本音で話のできる間柄であり、そして双方の奥さん同士も親友という家族ぐるみのつきあいをさせていただいております。 彼の日本のＩＴ業、特にソフトウエア開発業に関する知見は、日米双方の開発現場を渡り歩いてきた技術者として、とても参考になるのであります。 彼は大の親日家であり、ＩＴ業を通じて日米の架け橋となることを生涯の仕事と心に定めているのであります。 ■日本には下らない商習慣が多すぎる スティーブ「しかし日本のこの会計年度が３月末に集中している悪習はどうにかならんかね。なんで年度末になるとこうも忙しく
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> `���U ��'��U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
『ちよろず。』 - WebサービスAPI充実に想う「B2D(Business to Developer)ビジネスモデル」の可能性
最近、昔ちょこっとかじったPHPを使って、Amazon Web ServiceやYahoo!オークションWebサービスAPIをイジってるんですが、すごく面白いんですよ！わずか数行のコードを書くだけで、膨大な情報を引き出して自分のアプリに組み込むことが出来るんですから「おっ、俺ってちょっとスゴイ？」なんて悦に浸れる事に間違いありません。「これが開発者の特権、マッシュアップかぁ！ずるいなぁ〜楽しいなぁ〜」なんてひがんだりしながらも、ふと思ったのがサービス開発者の立場として「WebサービスAPIの提供をビジネスモデルとして説明できるか？」ということです。WebサービスAPI提供のビジネスモデルを説明してみる...んだけども。そこで、ビジネスモデルの説明としてB2C(Business to Consumer)やB2B(Business to Business)といった考え方を使ってみたのですが、し
ウノウラボ Unoh Labs: チームリーダーが心掛けるべき10のポイント（テストチーム編）
こんにちはー！ やまもと＠テスト番長です。 現在ウノウのテスト専任のスタッフは自分一人です。 いわば一人親方（建設業界用語）状態なのですが、 前職では総勢6人のテストチームを組織しておりました。 その頃心掛けていた、チームリーダー心得を書いてみたいと思います。 1.聞き上手になる 組織はコミュニケーションが命です。 話しにくいリーダーだと、必要な情報がうまく伝わりません。 気軽に相談を受ける・噂話が耳に入ってくるようでなくてはいけません。 そのためには聞き上手に徹すること。特に批判的な態度は控えることが重要です。 そんな相手には、誰も何も相談しないでしょう。 2.「おいしい仕事」を独り占めしない。 重要な判断や、やりがいのある仕事はなるべくメンバーに廻すようにします。 一見、重要な仕事はリーダーがこなすべき事のように見えますが、 その裏で他のメンバーがつまらない仕事ば
要求2.0開発 (arclamp.jp アークランプ)
要求開発アライアンスの10月定例にて「要求2.0開発」というテーマで話をしてきました。題名は理事の細川さんから依頼をいただいたときにノリでつけた名前です。かなり勢いに任せた内容はなっていますが、まぁまぁ（ｗ。 要求開発2.0ではなくて、要求2.0の開発。これからの時代は要求その物が2.0化してきます。手法うんぬんではないのです。言い換えれば「ビジネスのシステム化2.0」ではなくて「ビジネス2.0のシステム化」をテーマにしていかないといけないと考えまています。 資料はアライアンスのページにあがると思いますがサマリを書いておきたいと思います。 今、何が起きているのか 次のスクリーンショットを見てください。なんだと思いますか？ 実はこれ、日本全国1万ヶ所のホテルに●を置き、最低価格が高いほど赤くしたものなのです。長野から伊豆とか、京都奈良ならあたりが赤くて、東京、大阪は件数が多いものの価格が高
外注さんに知っておいてほしいこと - swat_memo
とあるプロジェクトで外注さんを探しており、昨日BPさんの面談をしたんだけれど、そのときに実際に仕事する場合の心構えというか、こういう意気込みで来てほしいというような話をしたら、妙に感心されてしまった。私自身には当たり前の感覚なので、逆にこっちが面食らってしまったのだが、まあ減るもんじゃないのでポイントだけ書いておこうと思う。 基本的に外注として現場に入ると、学習曲線があがっているうちは楽しくても、そのうち学習曲線は平坦になってくる。 平坦になったとしてもお客さんは外注を育てる義務がないし、学習曲線が平坦だと、どんどんモチベーションは落ちてくるかもしれない。 実際、発注する側は成長する可能性のある仕事はプロパーにふるもんである。私だってそうする。 となると、外注として現場に入ったからには、成長する可能性がいつもある、ということはないし、まったくないこともある、ということを意識しておかなきゃい
アンカテ(Uncategorizable Blog) - 「スモールビジネスの国」と「強者と弱者の国」
アメリカでは、「スモールビジネス」というのがこれから流行るみたいです。 ベンチャーのように大金を集めない バブリーに稼ぐのではなくて、小さいことを武器にして小回りをきかせて稼ぐ 経営者(創業者)のアイディアと情熱と信念による経営 成長指向ではない というタイプの小さな会社による新しい経済が急速に伸びているが、気づいている人はあまりいない、というような話が、Rex Hammockという人のブログに出ています。派手な資金の動きがないから見過されているが、実はそういう層が厚みを持って育っているそうです。 この人がやっている My Business Magazine という雑誌で、37 Signals の Jason Friedさんをインタビューしたそうで、そのことが彼のブログのMy Business Magazine: The Next Small Thing - Signal vs. Nois
階層化するサービス (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ SOA自体、特に難しい概念ではありません。しかし、どうしてもややこしくなるのがサービスという概念です。栗原さんの書かれた「本当は単純な「SOA」という考え方」では、 実際には、SOAの考え方は極めて単純である。ソフトウェアを「サービス」という部品の集まりとして構築しようというだけのことなのだ。 サービスとは「複数のアプリケーションをまたがって共用され得るソフトウェア部品である」と言える。 サービスはビジネスプロセスの一部（サブプロセス）を表現していることが多い。 このことから、SOAとBPMの相性は極めて良いということが言える。SOAにより、ビジネスプロセス（を実装するソフトウェア）を部品化し、BPMでそれを組み合わせ、ワークフロー管理することで自由度の高い業務システ
Ruby on Railsのチームから学ぶ仕事術
Ruby on Rails自体についての解説は、「WebプログラマはRailsに乗るべきか？」や、「Rubyでアジャイルプロトタイピング」にもありますので、そちらもぜひご覧ください。本記事は2006年に執筆されたものです。RubyやRuby on Rails全般の最新情報は＠IT Coding Edgeフォーラムをご参照ください。 素早く開発が行えるRuby on Railsに驚くとともに、Railsのプロジェクトの素早さの根源はどこにあるのか不思議に思った人も多いことでしょう。 Ruby on Railsの開発には、37singals社のDavid Heinemeier Hansson氏を中心とする11名で構成されたチームがかかわっています。 Core team behind Ruby on Rails Ruby on RailsによるWebアプリケーション構築風景を撮影したいくつかのス
Life is beautiful: SEはメニューのないレストランのウェイターか？
一昨日書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーに対して沢山の人からフィードバックをいただいた。このように情報を発信すると、逆により多くの情報が集まり自分にとっても勉強になる、というフィードバックプロセスがあるからブログは楽しくて仕方がない。 フィードバックの中に「これでSE不要論も再燃か？」などという過激なコメントから、自分自身がSEという立場の方からのものすごく真面目なフィードバックまでが集まったので、これを機会に、ここに私なりに「SE」という職業をどう解釈しているか書いてみようと思う。もちろん、私自身がSEという職業を経験したことがあるわけでなないので、間違っているかも知れないが、その場合は遠慮なく指摘していただきたい。 私の理解では、SEという職業はレストランに例えればウェイターである。それも、メニューから料理を選んでもらう通常のレストランとは異なり、「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日経SYSTEMS：お役立ちWebサイト101
ロングテール時代のSI