InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
チェンジビジョン社の設計支援ツール,JUDEの開発は,日本と中国での分散開発で行われている,いわゆるオフショア開発である。 私は,現在日本が行っている典型的なオフショア開発には,大きな問題があると考えている。それは「日本が上流」「中国が下流」というわけ方であったり,「いちども顔を合わせたことのない人がメールと仕様書のやり取りをしている」というコミュニケーションの仕方だったりする。 私たちは,2002年から様々な開発手法,コラボレーション手法を試してきた。やり方を変えながら,改善してきたのだが,大きくコミュニケーションが変わったのは,ある日本在住の中国出身技術者が,チームに偶然加わったことだ。それが,この連載の著者,周翼(しゅうよく:周が苗字,翼が名前)である。 もともと,私たちは英語とUMLを使った図,そしてコード自身で会話しており,いわゆる「ブリッジSE」と呼ばれるような,中国語と日本語
世界的に認知されているソフトウェア開発プロセスのエキスパート。彼のWebサイトJoel on Softwareは、世界中のソフトウェア開発者に人気があり、30以上の言語に翻訳されている。ニューヨークにあるFog Creek Softwareを創業し、ソフトウェアチームのためのプロジェクトマネジメントシステムとして人気のあるFogBugzを作った。JoelはMicrosoftでExcelチームのメンバーとしてVBAをデザインし、Juno Online Servicesでは数百万人が使うインターネットクライアントを開発した。 優れた開発者の要件――まず、「優れた開発者にはどのようなことが求められるか」についてお聞かせください ああ、大変だ。それなら12箇条ありますね。(笑) まじめに答えると、見方が二つあって、ひとつは成功するチームを作る上で誰を選ぶかということです。私はそういうとき、頭がよく
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。 注意:以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。 なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか) Tuesday, February 19, 2008 先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。 それぞれのExcelワークブックは1つのcompound fileに収められている つまり、Excel 97-
カーニハンが、ベントリーが、「コードの美しさ」を熱く語る珠玉のエッセイ集、『ビューティフルコード』今春刊行予定!サンプルPDFを公開 Posted by Editor : 2008-02-03 16:59 「ビューティフルコード」をテーマに、K&R、AWKのブライアン・カーニハン、『珠玉のプログラミング』のジョン・ベントリー、XMLの父ティム・ブレイ、ゲノム解析のジム・ケント、そしてRubyのまつもとゆきひろ氏など、一流プログラマたちが思い入れを語る珠玉のエッセイ集、『ビューティフルコード』(久野禎子、久野靖訳)がいよいよ今春発刊されます。今回、カーニハンの1章とベントリーの3章のPDFを公開いたします。ほかにもSubversion開発者のカール・フォーゲル、『Linuxデバイスドライバ』のグレッグ・クローハートマン、『プログラミング言語SCHEME』のR.ケント・ディヴィグ、『ハッカーの
2008年2月13日,ソフトウエア開発者向けイベント「Developers Summit 2008」(主催:翔泳社)が始まり,米Fog Creek SoftwareのCEOであるJoel Spolsky氏(写真1)がセッションに登壇した。Spolsky氏は,ソフトウエア開発についての諸問題を皮肉とユーモアたっぷりに論じた書籍およびブログ,「Joel on Software」で有名。セッションも著書と同じく皮肉とユーモアに満ちたものになった。 セッションのテーマは「素晴らしいソフトウェアを作るということ」。機能的に優れた製品を作っても,市場で優位に立てないというよくある現象を分析し,万人に愛されるソフトウエアを作る方法を探るという流れでセッションは進んだ。 セッションの冒頭でSpolsky氏は,いきなりサッカー選手David Beckhamとその同僚Landon Donovan(どちらもLo
先に書くとして書かなかったエントリ。 世のフレームワークの中には簡単開発が売りで、それこそStrutsやHibernateなどの既存のデファクトっぽいフレームワークを組み合わせたうえ、技術的な選択の幅を狭めることによって技術習熟度の低いプログラマーでもほぼコピペの域でOKというものがあります。私は、これはダメだと思っています。量産やオフショアやバカ対策という内容で生産性、生産性と連呼していますが、果たして生産性があがってるのかなぁと。 プログラマーのやることを単純化するために、スタックを重ねることはたぶんフレームワーク実装者の考える幻想的な生産性であることが多いのではないかなと。たとえばStrutsを便利にするのにActionを至れりつくせりで数行POJOで書けばOKみたいなものをやったとして、使う側がモチベーション高くやれるかどうか。もちろんスタックを重ねることと利用者モチベーションの高
システムは単体と全体っていう単純な構成じゃないし、単体だけ開発するってこともないし、一連のシステムはすべて自分の開発環境で動かせるし、単体テストとか結合テストとかってどうよ?と思うわけですよ。 っていうか「JUnitで単体テストはできますか?」っていう質問は、ようするにJUnitでテストしてるのは「単体」ですか?って質問なわけで、ようするに、今やってるのは単体・結合という区分でわけてるもんじゃないわけですよ。 「JUnitで単体テストはできますか?」のあとに「何を単体としましょうか?」って聞き返さないといけないのは、もうナンセンスだと思うのです。 メソッドテストとかロジックテストとか画面テストとかでいいじゃないか。
2006/11/29 情報処理推進機構(IPA)は11月29日、2006年度「情報処理産業経営実態調査」の結果を発表した。この調査は「情報処理産業界の財務、経営状況の現状を把握し、今後の経営の参考に供する」(IPA)ことが目的で、1978年以降毎年実施されている。28回目となる今年は従来のアンケート調査に加えてヒアリングも実施し、労働生産性の分析などを行った点が特徴だという。アンケートでは861社から有効な回答が得られた。ヒアリングは25社に対して行った。 2005年度の情報処理産業全体の売上高は0.8%の増加で、伸び率は鈍っているものの2003年度から連続でプラス成長している。経常利益も22.6%の増加で、増収増益となった。ヒアリングの結果でも、経営状況は昨年と比べ良好であるという意見が多く聞かれたという。 生産性に関しては、ソフトウェア業界において、ソフトウェアプロダクト販売分野の売上
SDAS(エスダス)(注1)は、開発期間短縮を実現し、お客様のビジネスのスピードアップに貢献する為の総合システム開発体系です。 新しい「SDAS」は、「短期間・高品質」のシステム開発を実現するとともに、「オープン性・国際標準」「ライフサイクル全般でのシステム最適化」「エンジニアリングとマネジメントを両輪とするプロジェクト遂行」を特長としています。 これにより、システム開発期間を従来と比べ、概ね半減することが可能となり、ITの観点から、お客様のマーケットの動きを先取りしたビジネス展開を支援していくことで、競争優位確保に貢献します。 システム開発を「要件定義」「設計」「構築」「テスティング」の4フェーズに分け、それぞれのフェーズを最短化する開発手法、標準技術に基づくツール群およびテンプレートを適用することで、トータルの期間短縮を実現します。 注1 SDAS: System Developmen
「Nine Things Developers Want More Than Money」という記事がありました。 面白かったので要約してみました。 誤訳や勘違いがあるかも知れないので詳細は元記事をご覧下さい。 1. 成功するプロジェクトであること 多くのプロジェクトはそもそも失敗するような計画で行われているという悲しい現実があると書いてありました。 成功の要素として、現実的な納期、安物のツールを使うことを強制されないこと、ろくでもないマネジメント・仕様変更・暗黙の仕様 などを要求する発注先にあたらないなどが重要だそうです。 2. すばらしいマネジメントが行われていること プロジェクトと人の両面ですばらしいマネジメントが行われていることが重要だそうです。 身を挺してチームを守るようなすばらしいマネージャに対してはプログラマはソフトウェアの品質で応えるそうです。 3. 新しいことを学べること
Part7では,数あるアジャイル型プロセスの中でも,最も取り決めが緩い「クリスタル・ファミリー」について紹介する。最大の特徴は,プロジェクトを実施する過程で,開発プロセスの内容そのものをチューニングしていくことにある。 本講座ではこれまで,開発者個人の生産性向上に焦点を当てた「プロダクト重視型」プロセスとしてXP(eXtreme Programming)を,チームの生産性向上に焦点を当てた「マネジメント重視型」プロセスとしてスクラムを取り上げ,各々の基礎と,実践の勘所を解説してきた。Part7ではプロダクト重視型とマネジメント重視型の中間に位置するプロセス,いわば「中庸型」のプロセスとして,「クリスタル・ファミリー」を取り上げる。 一般にアジャイル型プロセスは,メンバー個人の自主性を尊重する傾向が強く,ウォーターフォールやRUP(Rational Unified Process)といった“
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く