当たり前のことなんですが、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になると言う意味は、ソフ

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

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

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

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

来年も作りたい！ふきのとう料理を満喫した　2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ

教育界、技術者コミュニティでJava言語の教育と啓蒙に長年携わってきた筆者が、独自の視点からJavaの面白さを掘り下げていく。（編集部） ここのところJavaの世界でも、「クラウドコンピューティング（cloud computing）」という用語が使われることが多くなって、注目されています（参考：他社にないピースを持つ：Sun、総合的クラウドを提案）。 2007年のJavaOneの記事である「Sun、Javaモバイルデバイス展開をブレイ氏語る」「『Javaに並列処理と関数型言語の要素を』、ティム・ブレイ氏」を読んでみると分かるように、サン・マイクロシステムズでは、Atomの推進やJava VMによるJava以外の言語のサポート、並列プログラミングのサポートなどを推進していましたが、2008年はクラウドコンピューティングを前面に出してきました。今回は、Javaについて、クラウドコンピューティン

多くの企業において，現行システムのブラックボックス化が進んでいる。ここで言う「ブラックボックス化」とは，システムが大規模化・複雑化してプログラムの構造やロジックが不透明になることを指す。内部仕様だけでなく，業務フローや画面，帳票など外部仕様が分からなくなるケースも珍しくない。 システムがブラックボックス化する理由は，プログラムの度重なる改修や，ドキュメントの不備，担当者の退職などさまざまだ。ところが，それにより新規・保守開発の調査工数が膨らんだり，予期せぬ障害を招いたりするケースが後を絶たない。 こうしたこともあって，システムの見える化は開発・運用現場が抱える大きな課題の一つになっている。筆者は取材を通じてそれを痛感し，ITproおよび日経SYSTEMSで「現行システムの見える化」に関する特集を担当することにした。ここでは1週間にわたって，現行システムの見える化に悩む現場の実態を紹介すると

おととい、Seasarの理事、主にまさたかさんと、しばらくぶりにちゃんと話しました。そこで、おいらが、この2年間くらいの間、何を考え、何をしていたか話したんだけど、「ひがさんが何をしていたかしらなかったよ」と、まさたかさんがいってたので、きっと、コミッタの人やユーザーの方も同じだと思うので、Seasarに関してこの2年間やってきたことについて書いておこうと思います。 まさたかさんと、ここんとこ話をしていなかったのは、別に仲が悪かったわけではなく、はぶさんが理事を抜けた後、飲み会とかやらなくなったから、というのが原因。後、おいらも結婚したので、あまり外で飲まなくなったってのもあります。 2年前のSeasarがどのような状態にあったかっていうと、ちょうど、キャズムに陥っている状態。そこそこの知名度はあるけど、アーリーアダブタ以外は手を出さない。 そこで、私が行なったのは、HOT deploy、