ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ

TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。

日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問　日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海

引越し遍歴パートⅡ 2018年に「上京して10年で引越しを6回した」というブログを書いた。 月日は流れ、あれから6年…さらに2回の引越しをした。ホテル暮らしも含めると3回かもしれない。 前回の記事では主に神奈川〜千葉〜東京の引越し事情を書いた。関東の浅瀬でちゃぷちゃぷ遊んでいたに過…

今時はやりのソフトウエア開発手法のひとつに「ペアプログラミング」という手法があります。その名の通り、二人ひと組でプログラミングすれば、お互いのチェックによりミスは減少、やる気は倍増、生産性は二倍以上になってお得、てな感じで夢のような手法です。 まぁ、人間のやることですから、実際にはそう上手くいくとも限らないのですが。 で、それの亜種（というかシャレ）で、「ベア(bear)プログラミング」というのがあるそうです。 これは、とある計算機センターのヘルプデスクに、テディベアのぬいぐるみが置いてあることに由来します。 どうしてもプログラムが上手く動かない。いったいどこが悪いのか、考えても考えても解決できない。……こんな時、一度煮詰まってしまった脳みそでは、それ以上いくら時間をかけても自分だけの力では解決できません。 でも、その悩みを他人に説明しようとした途端、自分自身の問題点に気づいてしまう場合が

「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか

昨日はIBMのラショナルソフトウェアカンファレンスに参加しました。1日中、ソフトウェア開発方法論に関するセッションを聞いていたのですが（最後のセッションは、自分が司会のパネルディスカッションでもありましたが）、その中で最も印象的だったウォーカー・ロイス氏のプレゼンテーションを紹介したいと思います。 ウォーカー・ロイス氏はIBMラショナルソフトウェア部門のバイスプレジデントで、アジャイル開発手法としてよく知られるRUP（Rational Unified Process）の創始者でもあります。彼の講演は、この日の基調講演の1つでした。

XPJUGで「見積りポーカー」を教わって来ました。 前々からやりたいやりたいっておもっていたんです。 やっとむさん、おさそいありがとうございます。 ＝見積りポーカーのあそびかた＝ １）「１」「３」「５」「８」「１３」「２０」のカードを各々手元に用意します。 ２）「〜の値段は？」「〜の人数は？」「〜の工数は？」などなど、数値化できるお題をだします。 ３）いっせーーのせ、で数字カードを出します。 ４）最小値と最大値の人の意見を聞きます。 ５）もう一度、いっせーーーのせ、で数字カードを出します。 このゲームのいいところは、最小値と最大値の意見を聞くところです。 自分が想定していなかった要素がばんばんでてきます。 さっきのTRUNCATEの話、本番作業の前に これから作業するシステムがどれくらいの価値を生み出しているか 作業前にバックアップ＆リカバリの状況を確認し、 十分でないなら一筆とる、などの

ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの

晴天の価値 2月中旬に出張で千葉へ行った。5日間の滞在中はずっと快晴で、気温は20℃に迫る春のような暖かさだった。仕事は朝から晩まで現場を走り回る過酷なもので、身体的にも精神的にも追い込まれた。毎朝、京葉線から見える美しい景色を眺めて正気を保っていた。太平洋へ燦々と…

その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの

3連休が明けて仕事が始まった。連休明けで頭がまだ仕事モードになっていない人が多いから余計にそう感じる部分もあるのかも知れないが、現在社内で進行しているプロジェクトで「担当者が一人」というプロジェクトの進捗が気になる。そろそろ何かしらのアウトプットや確認が自分のところに来ても良い頃だろう、と思っているプロジェクトも、少し停滞しているように感じる。毎日淡々と作業を続けるのが少し難しく、周りがやきもきしているプロジェクトもある。 それで少し昨日の映画を見ている最中のネットの話と関連するんだけど、今の社内だと仕事は必ず2人で一緒に取り組む、と決めた方が良いのかも知れないなと考えた。お互いが別々のプロジェクトを抱えていると、それぞれが「別の世界」の取り組みをすることになるけど、新しい世界を一人でも迷い無くどんどん切り拓いていける人はそう多くは無い。そういう自分も、1人で取り組むよりも、人と組んで仕事

「戦略的思考のなんとか」みたいな本は、ほとんど戦争の本ではなくてビジネスの本です。 軍事→ビジネス→その他の組織 という経路で導入された考え方のなんと多いことか。 そもそも、官僚制というやり方自体が、だいたいはこの経路で一般化したものでしょう。 形式的で恒常的な規則に基づいて運営される。 上意下達の指揮命令系統を持つ。 一定の資格・資質を持った者を採用し、組織への貢献度に応じて地位、報償が与えられる。 職務が専門的に分化され、各セクションが協力して組織を運営していく分業の形態をとる。 20世紀は「官僚制の世紀」です。ほとんどあらゆる組織がこの原則で運営され、この方法が社会の常識となっています。 もちろん、それは20世紀の環境ではうまくいったから広まったのですが、この限界と弊害もいろんな所に見られるようになっています。21世紀はこれを解体、止揚していくことが、社会のさまざまな局面において必要

仕事は7.5時間で終わらせるというエントリーに結構な反響があったので、コメントの疑問などに答えてみます。 実際どのくらい効率的なんでしょうか。またどうやって効率を計測しているんでしょうか。その辺を詳しく知りたい！ アウトプットを定量的に測ることができる、ということか？永遠の課題に思えていたけど。 人それぞれで違う業務を行っている以上、アウトプットを正確に計測するというのは、こちらでも難しい問題です。 ただ、だからといって労働時間で測ることはないです。 長い会議は誰のためにあるのだろう。残業代稼ぎか？ 偉い人への丁寧な説明のために多くの時間を割いていた気がします。 進捗報告用エクセル命の某社とはえらい違いだ。 はい。前職の関係者ですか？ 立って会議するのはよさそう。でもちょうどいい高さにテーブルがない /立ち話の延長なのでいらないのかな？ テーブルは使っていません。報告だけなので。 ホワイト

Ruby on Railsが、エンタープライズの中でどのように広まっていくのか。スーツの奴らが金のために煽ってるだとか、エンタープライズRailsってどうよとか、バブルだとか、バブルは弾けたとか、色々な意見があるようです。 言語やフレームワークの考え方の好き嫌いといった哲学的な観点で色々な意見が出たり、テクノロジの観点で様々な意見が出るのは、むしろ良いことだなぁと思うわけですが、どうも違うなぁという考え方が１つあります。 それは「価格競争になったときの選択肢」のためにRailsに取り組もうとすること。それがエンタープライズにおけるRailsの価値なのでしょうか。私は違うと考えています。 単純に、金額のためだけにRailsを選ぶくらいならば、Javaでオフショアを選んだ方がよほど低リスク・低価格だと思いますし、せっかくの生産性の高さを安売りしている風に聞こえます。（それはSIの人月ビジネスの