Amazon.co.jp: ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション: ThoughtWorks Inc. (著), 株式会社オージス総研オブジェクトの広場編集部 (翻訳): 本
オフショア時代を乗り切る明確な要求仕様作成術
正確で明確な「要求仕様」を作成するのは非常に難しい。それがオフショア開発となればなおさらである。 開発技術の発展により，従来よりも変更に強く，速くシステムを作ることは可能になった。しかし，実物を作らずに「紙上」だけで仕様を正確に定義するのは，いまだにとても難しい。 システム化の対象業務も様々で，近年では経理システムのように定型なものは少なくなった。要求を出す側のユーザーでも，アプリケーションを作成して初めて仕様が見えてくるといったことはよくあることだ。 システムに対する業務的な要求が，時間の流れによって変わってしまうこともよくある。チェンジビジョン代表の平鍋健児氏は，このことをで「ムービングターゲット」，つまり動く標的という言葉で説明している。 オフショア開発の場合，それが顕著になる。日本人同士のように，電車で移動すれば顔を合わせられる位置にいても，仕様に対する意識の違いや，仕様そのものの
株式会社オージス総研
大変申し訳ございません。 お客様が指定されたページは見つかりませんでした。 このページは存在しないか、別のURLに移動された可能性があります。 恐れ入りますが、オージス総研トップページより再度目的のページへのアクセスをお試しください。
Martin Fowler's Bliki in Japanese - C3
http://martinfowler.com/bliki/C3.html C3はクライスラー総合報酬プロジェクト(Chrysler Comprehensive Compensation project)の略称です*1。これは、クライスラーで実施された給与計算プロジェクトで、エクストリームプログラミングの誕生の地として、その後、名を知られるようになりました。 このプロジェクトは、それまでにあった多くのCOBOLベースの既存給与計算システムをリプレースしようとするものでした。私は1993年以来、コンサルタントとして様々な形で係わってきました。プロジェクトは1995年にSmalltalkによる本格的な開発作業をいくらか始めましたが、安定した状態に達することができず、1996年に Kent Beck の指導のもとで仕切り直しました。この、再開後のプロジェクトで、エクストリームプログラミングとして
＠IT：ソフトウェア開発をちゃんと考える（1）
本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分
開発プロセスを設計するという発想 - プログラマの思索
最近興味があること。 それは、「開発プロセスを自由自在に設計して、運営できるか？」ということ。 こんな本「SEの仕事を楽しくしよう」を読んでみて、色々と考えさせられる所があった。 RUP、XP、CMM/CMMI、ソフトウェアプロダクトラインなどを聞きかじって、自分で少しだけ試してみた経験を振り返ってみて、考察してみる。 【１】新規開発と派生開発～ＩＴ業界特有の開発プロセス 開発プロセスを勉強すると必ず「ウォーターフォール型開発よりもインクリメンタル型開発の方がいい」という文句に良く出る。 でも、実際の現場では、ウォーターフォール型開発でもインクリメンタル型開発でも、プロジェクトを制御できていない。 その原因は、2種類の開発プロセスがある事実を知らないことにあると思う。 最初からスクラッチ開発する時は、小さなサイクルでウォーターフォール型開発を行う時が多い。 最近なら、オブジェクト指向言語で
Google のソフトウェア開発 Days on the Moon
Google 技術講演会「Developing Software in the Real World」に行ってきました。講演者は Google 東京 R&D センター ソフトウェアエンジニアの南野朋之さん。その 1 週間前に行われた、Mozilla Corporation の Seth Bindernagel と Seth Spitzer との講演会 (Mozilla Party JP 8.0 とは別物) には参加できなかったので、リベンジ (?) という形になります。 南野さんはインターンを経て Google へ入社、Google マップでの写真表示を開発された方で、今回の公演内容は Google でのソフトウェア開発体制、および Photos on Google Maps 開発の舞台裏に関してでした。 Google でのソフトウェア開発体制 OKR (Objectives and Ke
GTDに学ぶプロジェクト管理ツール導入――3つのポイント
GTDに学ぶプロジェクト管理ツール導入の3つのポイント メンバー視点のリストを提供する メンバーのToDoも一緒に管理できるようにする メンバーの作業管理がしやすいものを選ぶ メンバー視点のリストを提供する まずプロジェクト管理ツールを利用する際に重要なのが、メンバー視点のリストを提供するという点です。管理者目線だと、ついつい全体のスケジュールをプロジェクト管理ツールやエクセルを使ってガントチャート形式でまとめて満足という流れになってしまいがちですが、これでは前回書いたようにプロジェクト管理者の自己満足になってしまいます。 では、どうすればいいのか――。まずは、全体のスケジュールから、個別のメンバーごとに作業リストを切り出して渡してあげましょう。ここで参考になるのがGTDです。 GTDでは、自分がやるべきことのリストを自分で作成します。ここではプロジェクトメンバーのスタッフ各人がやらなけれ
BMUF (Big Modeling Up Front)＝上流設計のインチキを斬る - masayang's diary
DDJのCounteracting the False Arguments for Big Modeling Up Front (BMUF)という記事が面白い。BMUFは、日本語なら「上流設計」だろうね。SI屋の自称上流設計エンジニアがやってる、アレだ。[*1] この記事を書いているのはScott Ambler。Refactoring Database著者だ。例によって無断適当意訳。読みやすくするために原文よりも段落を増やした。 上流設計(BMUF)にまつわる嘘を斬る 自分は１９８０年代から数々のプロジェクトで上流設計をしてきたし、様々な手法をみてきた。 そして、うまく行った事例よりは、うまくいかなかった事例の方が多いと言えるね。プロジェクトは明らかに失敗しつつあるのに、上流設計は順調に進んでいる、という現象を誰よりも多く見てきた、ということも言っておこう。 まだあるよ。上流設計担当の人た
QA と QC とテストエンジニアリングの違い [google]
Google Testing Blog より，QA と QC とテストエンジニアリングの違いについて． Google Testing Blog: The difference between QA, QC, and Test Engineering コミュニケーションを円滑に進める為に「用語の定義」は非常に大切だが，重要なのは世間一般の定義よりも，その組織 (や関連組織間) で定義が統一され，役割が明確になることだと思う． ということで，これはあくまでも Google Testing Team の見解に過ぎないが，まあなにかの参考にはなるかな，と． まず QC (Quality Control) はというと… In the classic definition QC is short for Quality Control, a process of verifying predefine
ビジネスリサーチの心得
コラム〜リサーチャーの日常 人生を通じてマッチクオリティーを追求する 知識の幅が最強の武器になる という本で初めて知った「 マッチクオリティー 」という言葉は、経済学の用語で、ある仕事をする人とその仕事がどれくらい合っているか、その人の能力… 2021.05.04 2021.05.13 311 view 1．ビジネスリサーチの基本・心構え すべては「依頼」から始まる〜社内リサーチャーと社外リサーチャ… 【 リサーチャー とは 】企業で企画系の仕事をしていると、上司の依頼で調べものをして資料にまとめるという仕事が多いと思います。企画系の業務では課長クラスまではこうしたリサ… 2021.01.18 2021.05.13 340 view 2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開
「設計」や「構築」よりも重宝されるスキル
IBMのRationalチームは現在、分析、設計、および構築と従来呼ばれていたものを拡張し、そこにアーキテクチャ管理を組み入れようとしている。本稿は、その原動力となる要件や、それをインプリメントするコードが変化する中でソフトウェアアーキテクチャの管理を行うこの専門分野について解説する。 The Rational Edgeより：IBMのRationalチームは現在、分析、設計、および構築と従来呼ばれていたものを拡張し、そこにアーキテクチャ管理を組み入れようとしている。本稿は、その原動力となる要件や、それをインプリメントするコードが変化する中でソフトウェアアーキテクチャの管理を行うこの専門分野について解説する。 ソフトウェアシステム全体の管理 先ごろ、IT部門を担当するある会社のバイスプレジデントから次のような感想が出てきた。「われわれはもはや、従来の感覚でソフトウェアを開発しているとはいえな
SE・PG入門
ここでは、システムを開発していくことについて触れていきたいと思います。例の如く、ここに書いてある内容は、私の経験から出たもので、一般的に列挙されている内容と異なる場合があります。 目次 システムを作成する上での重要なポイント ３つの基本（分類・共通化・抽象化） リファクタリングについて オブジェクト指向入門 デザインパターンを読み解く データ中心指向とオブジェクト指向 開発プロセス テストについて ドキュメントについて データを扱うアプリケーションの注意点 セキュリティについて フレームワークについて アーキテクチャ、設計について Webアプリケーション作成の一例 補遺：ブログから転載 ＳＥ／ＰＧのための学習ガイド
「仕事の流れをマンガ風にまとめよう」，スターロジックが業務分析ツールの新版「マジカ！」をお披露目
「マジカ」という業務分析ツールをご存じだろうか。仕事の流れを短時間で書き出すためのカードである。数種類ある名刺大のカードに普段の仕事を思いつくままに書き出し，決まったルールに沿って並べていくことで，仕事の流れを見える化できる。開発元のスターロジックは2006年1月16日，マジカのイベントを開催し，約1年半ぶりにバージョンアップした新しいマジカをお披露目した。旧バージョンは「おしごとマジカ」という名称だったが，新バージョンは「マジカ！」という。 仕事の流れの見える化は，仕事の引き継ぎ，新人研修，業務改善といった際には欠かせない。最近，話題になっている「企業の内部統制」も，仕事の流れを把握しないことには始まらない。ただ，仕事を見える化しようとする際には数々の問題がある，とスターロジック代表取締役兼CEOの羽生章洋氏は指摘する。「書き方がわからない」「（メリットがわからないので）面倒くさい」「書
Martin Fowler's Bliki in Japanese - 機能への執着
http://martinfowler.com/bliki/FeatureDevotion.html 2006/11/2 一般的な（おそらく最も使用されている）アジャイル方法論のプラクティスは、構築するソフトウェアの機能リスト（ストーリーカード）を作ることだろう。 リスト化された機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログなど、あなたにとって最適なツールで追跡することになる。 こういったやり方は、私は好きである。やるべきことをすべて数週間程度で完遂できる小さなタスクに分解し、進捗を見える化し、成し遂げたことを一目見て分かるようにする。 反復開発の利点は、ある程度まとまりのあるソフトウェアを完遂させることにより、リスクを低減することにある。これは、期間が長く管理しにくいアクティビティ（テスト、結合）をプロジェクトの後半まで残しておくウォーターフォール開発とは異なる
「XPは押しつけるものではない。自分が変われば必ず伝わる」，XPの提唱者Kent Beck氏語る
「自分を変えられるのは自分しかいない」。2006年9月5日，ソフトウエア開発プロセスの一つ，eXtreme Programming（XP）を提唱しているKent Beck氏を囲んで記者懇談会が開催された。自分が変われば，必ずまわりは変わる。そんな信念が感じられた懇談会だった。 Beck氏の著書である「XPエクストリーム・プログラミング入門 第2版」は「XP is about social change.」という文章で始まっている。日本語版では「XPとは社会改革のことである」と訳されているが，ソーシャルのニュアンスが少し違うという意見もある。そこでまず「XPでいうソーシャルとはどういう意味か」と質問した。 Beck氏はソーシャルの例として「14歳になる私の娘は，ある友人と1時間くらい話をし，別の友人と同じ話をまた1時間くらいする。彼女はソーシャルな子供だ」と語った。つまり「社交的」「コミュニ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
higaさんによるダイコン時代の設計方法 - tpircs
The Agile Unified Process (AUP) Home Page
http://www.epfwiki.net/wikis/openup/index.htm
Reading List: Agility and Discipline Made Easy