当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。 SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。 ・アジャイル開発のボトルネック ・Publickey「納期を半分にしてくれ、金なら出す」 大規模なソフトウェアを作るには、大人数が必要と考えがち

最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

信頼度成長曲線の使い方について、フジハラさんのBlogによいリンクがあったのでメモ。 【元ネタ】 Redmine プラグイン開発 - テストレポートプラグイン開発中 - フジハラボ -- 目指せ！スーパーエンジニア どこでテストをやめるのか？ 日本電気株式会社 川村真弥さん オープンソースソフトウェアにおけるコードの 安定性予測に向けたゴンペルツ曲線の適用 成長曲線（ゴンペルツ曲線とロジスティック曲線） つれづれなる技術屋日記: バグカーブ　対数曲線や二次曲線での近似のお勧め テスト消化曲線とバグ発生曲線の7パターン診断 － ＠IT MONOist プログラムバグの成長曲線とプログラム品質の判定 テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索 信頼度成長曲線の使い道は、テストでソフトウェアの品質が歩溜りに達したかどうかを判定するのに使う。 つまり、テストの止め時は、信頼度成

この二年仕事をしてきた会社ですが、アジア圏での更なる発展をめざし、東京オフィスを香港に移転することになりました。(http://www.cufp.org でも既に東京の求人は止めて、香港で出しています。) え、どこの会社？まぁ調べてくださいよ。(追記: Jane Street Global Trading, LLC です。) アジア金融圏でニューヨーク、ロンドンなみの地位を築けた東京も今は昔。ぼぉっと10年無駄にしてる間に、日本はその地位を確固とすることのないまま、香港、シンガポールと比べ、規模はともかく、税制、規制面で劣るマーケットになってしまいました。地理的なしがらみの少ないファンドやウチの会社のような prop trading の会社の日本脱出は非常に合理的な判断と言えましょう。日本人関数型言語プログラマとしては日本から関数型言語で飯が食える場所が一つ消えてしまうのは忸怩たる思いがあ

全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

UnicodeとUTF-8の違いは？ - Humanityはあんなに反響があるとは思わなかった。 ブコメにコピペじゃなくてまとめを書いてくれれば良い資料になるのにと書いてあったので今度は自分の知識をまとめてみる。 と言っても自分もあのスレを見るまでUnicodeとUTF-8を混同してた一人なのでほとんどあのスレからの知識ですが...orz なので簡単なまとめ。引用を多分に含みます。間違ってたらつっこんでいただけるとうれしいです。 調べる際に弾さんのエントリがかなり参考になったので(今頃意味が分かってきた)関連リンクとして度々載せさせていただきます。 参考リンクじゃない理由は解説しているエントリだけじゃなくて既存のエンコーディングを拡張するといった高度なエントリも含まれているため。 UnicodeとUTF-8 まず一番重要なことは Unicodeは「符号化文字集合(Coded Charact

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

Jalopnik経由: 'X' man's tag leads to more than $19,000 in Birmingham parking tickets 米国アラバマ州Birmingham市でのお話。 車の登録番号に「XXXXXXX」を選んだScottie Roberson氏。 なぜか、Birmingham市当局から駐車違反切符総計$19,000(ざっと180万円)をもらう羽目に。 →Birmingham市の駐車違反管理システムでは自動車登録番号標を装備していない車については、「XXXXXXX」を入力する仕組みになっていたから、らしい。 結果、登録番号標なしの車の切符全部を受け取ることになった、と。 データに意味を持たせてはいけない これもCOBOL文化の名残でしょ。 '9999999'で最大値とか。 'XXXXXXX'でデータなし、とか。 NULLという概念がなかった時代から

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。 【元ネタ】 Subversion のフォルダ構成 - かおるんダイアリー Subversionのフォルダ構成 | Ryuzee.com Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 InfoQ: 複数のアジャイルチームでのバージョン管理 【問題】 SVN直下のディレクトリは、branch/tag/trunkになっている。 ソースやドキュメントはどこに配置すべきか？ 【結論】 管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag　を作った方がブランチを管理しやすいと思っていた。 最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。 でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。 思い出してみたら、下記の

最近忙しくて……というか、本音をいうと「エンジニアライフで投稿していくことに意味があるのか」と真剣に考えましたが、わたしで伝えられることがあれば伝えるべきだと思い再開させていただくことにしました。 さて前回、業務分析についてエンジニアの皆様が興味をもたれているのかいないのかをうかがいましたが、独断でそこそこニーズはあると判断させていただきましたので、具体的な話を進めていきたいと思います。 要求の源泉。それは「そのシステムの機能をナゼ実装する必要があるのか」を示した理由です。 わたしが新人に近いころ、要求の源泉を把握できるチャンスはありませんでした。「仕様書にかかれたモノを作りなさい」と、ドキュメントを渡されただけです（逆にそれ以上のアクションができなかったわたしのスキルがシレテいますが）。 そうなると普通の感覚では仕様書にかかれた以上のモノはできないわけですが、たぶん日本の文化なのでしょう

「生産効率を上げろ！生産効率がすべてだ！」と叫んでやまない弊社と弊社の極悪評価制度（生産効率のみに特化した評価基準）を打破すべく、「生産性も大事だけど、それと同じくらい品質も大事でしょ？」という思いを明日、経営者レベルの幹部の方々にぶつけてこようと思います。変わるかどうかはわかりませんけど。言わないより言ったほうがいいじゃないですか。 なんで「生産効率」が第一で「品質」が二の次なのか - とりあえずなんですけどね ↓ 結果報告 僕「プログラマの評価が"生産効率"だけなのはおかしいです。"品質"も評価軸に入れるべきでは」 経営幹部Ａ「今、高品質な部品を別の部署で作ってるから、それを使えばおｋ」 経営幹部Ｂ「高収益を目指すためには生産性の向上は絶対不可欠」 経営幹部Ｃ「（うなずいてる）」 経営幹部Ｄ「（うなずいてる）」 経営幹部Ａ「その高品質な部品を顧客に提供すること、そしてその上で使われるシ

良品計画は独自の開発手法を採用することで、システム開発の短期化とコスト削減を図った。2006年12月に再構築したMD（マーチャンダイジング）システムを皮切りに、08年12月までに約130のアプリケーションを社内で開発。一方で、IT 投資の売上高比率は04年の1.8％から0.9％に半減させた。「7割主義」と「スピード対応」を方針に掲げ、利用部門の要望に最速1日、遅くとも1～2週間で対応する。開発手法の独創性と、経営に資するシステム部門の姿が評価された。 「無印良品」ブランドの小売店を展開する良品計画は、1週間に1本という猛スピードで新しいアプリケーションを開発したり、機能を強化したりしている。「思い立ったら即実行。合格最低ラインの7割主義で素早くシステムを開発し、検証と改善を繰り返す」。IT戦略を統括する小森孝取締役 情報システム担当部長兼流通推進担当管掌は強調する。 同社は独自の開発方法論

GNUプロジェクトの配布アーカイブなどを中心に、LZMAを用いた圧縮形式を目にする機会が増えてきた。組み込み用途などへの活用も期待されるこの圧縮形式を紹介しよう。 2001年に開発された可逆圧縮アルゴリズム「LZMA」（Lempel-Ziv-Markov chain-Algorithm）が静かな注目を集めている。LZMAといえば、高い圧縮率を備え、Windowsアーカイバ「7-Zip」に採用されていることでも知られる。 ZIPやLHAなど、ファイルのアーカイブと圧縮が統合されているWindows由来のプログラムとは異なり、UNIXやLinuxでは伝統的にアーカイブと圧縮が個々のコマンドとして用意されており、それらを組み合わせて利用することになる。現在では、アーカイブがtar、圧縮にはGNU zip（.gz）やbzip2（.bz2）が併用されることが多い。 .gzや.bz2をしのぐ圧縮率が特

チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。 「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？　それともプロセスで改善したのですか？」 質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。 そのプロセス改善はツールに依存しすぎではないか？ ツール無しの開発プロセスにできるのか？ チケット駆動開発は、BTSがなければ運用できないのか？ と。 この質問は今の僕が抱える問題点の一つを持っている。 それについては後でまとめる。 【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。 すなわち、障害だけでなく要望なども取り扱う。 この方法は、Issue Trackingとも呼ばれている。 つまり、障害修正のワークフローをSW開発における全ての作業の

八朔さんによるチケット駆動開発の運用例をメモ。 【元ネタ】 チケット駆動開発 - Live a meaningful Life プロジェクトの作業をWBSの観点で、要件→成果物→作業のツリー構造へ分解している。 プロマネらしく、チケットの構造が上手だと思う。 このやり方ならば、ソース←【チケット(作業)】→【チケット(要件)】の観点で追跡可能だ。 【チケット(要件)】で集計すれば、顧客向けの進捗報告として、進捗率や工数を集計できる。 アジャイル開発の観点では、要件はストーリーカード、成果物や作業はタスクカードに割り当てられると思う。 顧客の観点でシステムの価値を表すのがストーリーカードであり、チケット駆動開発における成果物は、開発者の観点で捕らえるべきだろうと思う。 そうでなければ、開発者が作業するレベルにならないからだ。 後で、八朔さんに聞いたら、要件のチケットから実際のテストケースへ落