「継続的インテグレーション」について - cactusman日誌
id:Ewigkeitのブログで、CIについてはここのブログ読んでね、と言及されたんですが、対象記事はCIについてあまり書かれておらず、しかも、古い記事を調べてみてもいい内容がなかったので、ここで改めて「継続的インテグレーション」について説明します。 「継続的インテグレーション（以降、CI*1）」とはXPのベストプラクティスの一つです。 原典として、マーチン・ファウラーの論文があります。 ここでは頻繁にインテグレーション作業を行うと、少し難しく表現されていますが、ものすごく簡単に言いますと、デイリービルドやナイトリービルドのように1日に1回ビルドするのではなく、1日に何回もビルド*2を行う、ということです。 また、プロジェクトの後期に行われるモジュールの結合やシステムテストといったことも1日に何回も行います。 具体的な例として、 チェックアウト コンパイル Unitテスト パッケージング
【AIRコレ】"やる気"を生み出すプロジェクト管理ツール『echo』 | ネット | マイコミジャーナル
仕事を行う上で「スケジュールの管理」はたいへん重要です。「今、自分はどのような仕事を持っていて、いつまでに終える必要があるのか」。しっかり把握しておかないと、後々ミスへとつながり、うまくいかないもの。ましてやチームでのプロジェクト遂行となると、ひとりのミスがプロジェクト全体に響き、多大な損害につながる場合があります。 そうならないためにもメンバー内のコミュニケーションは大事で、一人ひとりが常にプロジェクト全体の動きを把握する必要があります。トラストコンベクションが提供するAdobe AIRアプリケーション『echo』は、仕事上で重要なチーム内のコミュニケーションや、ToDo管理などを円滑にフォローし、総合的なプロジェクト管理ツールとして登場しました。 「echo」を使う前に、まずは「プレイヤー登録」を行う必要がある。まるでスポーツを行うかのような感覚で、仕事のやりとりや管理できるのが特徴だ
【6】プロジェクトを成功させる5つの土台：日経ビジネスオンライン
【ドングリ化について】 チャンスを逃さないためには、ぼんやりと考えていることを明確化し、まとめておくことが大切だ。 5分から10分ぐらいの短い時間で小さなメモに書き出してみる。 これを「ドングリ化」と呼ぶ（第1回「30秒ごとのチャンス」参照）。 今回は新しいプロジェクトのための要点をつかむドングリ化を実行する。 【同じ目標なのにかみ合わない現場】 「もっとプロジェクト規模を大きくしよう」 「いや、そりゃ無理だよ！」 と意見が対立している2人の、そのプロジェクト像、同じだろうか。 Aさんは、今の構想が70という規模だと考えている。Ｂさんは100だと考えている。 そこで、Aさんは、せめて100ぐらいの規模はないといけないと思って、大きくしようと提案する。 ところがBさんはすでに100の規模を想定しているので、さらに大きくしようという提案を聞いて、130ぐらいにしようと言われたと感じる。 完成像
第28回 「上流工程に時間を」は正しいか？ つい“楽”を求めるSE心理を知れ
システム開発の世界では「下流工程よりも上流工程に時間をかけろ」という言葉をよく耳にする。これは本当に正しいのだろうか。 「要件定義や設計などの上流工程に資源を集中的に投入し，この段階でバグの芽を摘んでおくことで，コーディングやデバッグ，テストといった下流工程の負担を軽減すると同時に，予想外の手戻り作業を撲滅する。そうすれば，開発期間を短縮できるだけでなく，品質の向上にもつながる」。これが冒頭の言葉の意味するところである。 確かに，デバッグやテストの段階で，設計や要件定義のフェーズまでさかのぼる重大なバグが検出された場合，スケジュールの大幅な見直しを迫られる。ところが，プロジェクトの終盤になってカットオーバーを遅らせるのは現実問題として難しいので，結局デバッグやテストのフェーズが突貫工事になってしまう。そうなると，焦りと疲労が災いしてメンバーがミスを犯しやすくなり，泥沼状態に陥る。これでは，
プロジェクトの遅れを取り戻す方法10選
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます プロジェクトが計画通りに進まなくなる原因は数多くある。例えば、タスクの見積もりが甘かったり、プロジェクトから要員が抜けたり、リソースの割り当てがまずかったりということがある。本記事では、遅れの生じたプロジェクトを立て直すための実践的なテクニックを紹介する。 プロジェクトチームで働いた経験のある人であれば、様々な要因によってプロジェクトの納期がずれ込んでしまうということを知っているはずだ。一部の作業が当初の想定よりも手間取るものであったり、メンバーの入れ替わりが激しく、新担当者の業務知識に対する習得時間が無視できないものとなったりするのは珍しいことではない。また、単に作業見積もりが甘かっただけということもあるだろう。しかし原因がどのような
第23回 システム開発の“丸投げ”が命取りに
現行システムの維持・保守業務に加えて，新たなシステム開発案件に追われている情報システム部は多い。むしろほとんどの情報システム部は，途切れることのない開発案件の消化に明け暮れている。忙しさに加えて，リストラや慢性的な要員不足が理由で，開発案件のほとんどを外部企業にアウトソーシングするケースも増えている。外注化は有効な選択肢の一つだが，“丸投げ”になってしまっては，情報システムのみならず，企業の存亡にかかわりかねない。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 空調機器製造販売会社のB社では，全国の支店網をこれまで以上に地域密着型にして，ビジネスの活性化と同時に独立採算を徹底することになった。この方針の実施に合わせて新しい業務処理に適した販売管
「完ぺきな」プロジェクト計画書に潜む失敗の落とし穴
プロジェクトを開始するとき、多くのプロジェクトマネジャーはプロジェクトを計画し、その成果物として「プロジェクト計画書」を作成する。しかし会社や対象部門、プロジェクトなどによって、計画の進め方、計画書の形式や内容はさまざまであり、実態に合わない計画を立てたことが原因でプロジェクトが失敗してしまうこともある。 プロジェクト計画書は「絵に描いたもち」？ Y社は官公庁など公共機関のシステム構築を得意とするシステム開発会社である。大規模プロジェクトを扱うことが多いため、プロジェクトマネジメントを重要視しており、社内でマネジメントプロセスの標準化がなされている。 2007年、Y社はある地方自治体の工事管理システムを受注し、同様のシステム開発経験を持つA氏をプロジェクトマネジャーに任命した。A氏は顧客が作成した提案依頼書などを基にプロジェクト計画書を作成し、社内と顧客の承認を得て無事プロジェクトをスター
「納期に間に合わない！」の根本原因を探る － ＠IT自分戦略研究所
ソフトウェアを創造するエンジニア。しかし、その仕事は本当に「創造的」だろうか。仕事を創造的なものに変え、価値を生むための発想法を紹介する。 前回、自分の中に宝物が眠っていることを知った。どうすれば自分の宝物を掘り当てることができるだろうか。宝物探しの出発点は、身の回りに散在している問題を考えることだ。身近な問題を解決することができれば、その効果を直接獲得できるばかりでなく、解決策形成の体験を通じて、将来発生するであろう問題を解決するための応用力も獲得できる。 自分にとって身近な問題、自分のプロジェクトや自社が抱えている問題、あるいは自分のお客さまが抱えている問題に取り組むことから始めるといい。そして、問題解決のアイデアや提案を生み出し、自分だけでなく、プロジェクトチームにも、会社にも、そしてお客さまにも喜んでもらおう。 ■解決すべき問題をはっきりつかむ 前回挙げた、「身近な問題の例」を再掲
「下請けはきつい！」も見える化、新発想のToDo管理 － ＠IT
2008/11/17 システム開発やチームマネジメントのコンサルティングを行うトラストコンベクションは11月14日、タスク管理ツール「echo」（エコー）を正式リリースした。WindowsとMac OS Xで利用できるAdobe AIRで実装した専用クライアントと、ユーザー登録したオンラインサービスを組み合わせて利用する。利用は無料。 システム開発など大きなプロジェクトは、小さく分割して“タスクセル”と呼ぶ単位で扱う。このタスクセルをサッカーチームがボールをパスしあうようにチームメンバーの間でやり取りするのがechoの特徴。タスクセルには「準備」「実行」「確認」の3つのステータスがある。タスクセル自体が色分けして表示されるほか、メンバー間で授受の際にコメントを付けて投げ返すことができ、タスクの依頼状況、遅延状況、依頼側・受注者の感情を視覚的に確認できるという。また、タスク終了時には相互評価
完了報告書の作り方
誰が誰に何のために報告するのか。これを意識することが報告書の内容を考えるうえで重要である。 完了報告書を作成する役割は，プロジェクト・マネージャが担うケースが一般的である。システム開発プロジェクトでは発注側であるユーザー企業と受託側であるベンダーの双方にプロジェクト・マネージャが存在するが，どちらのプロジェクト・マネージャが誰に対して報告するのかによって完了報告書を書く目的は少々異なってくる。その報告者と報告先は下記の三つのパターンに分けることができる（図1）。 A.ユーザー企業のプロジェクト・マネージャが経営者や上長に報告する B.ベンダーのプロジェクト・マネージャがユーザー企業に報告する C.ベンダーのプロジェクト・マネージャが自社の経営者や上長に報告する Aの場合の完了報告書の主な目的は，経営者や上長が決断したシステム投資に対して，担当者として説明責任を果たすということである。システ
管理者とは - Fight the Future
システム開発の仕事は、「自ら考える」ことが必要な仕事です。自発的に工夫したり、考えたりしながら作業を進めているSEにとって、単なる作業マシーンの役目を指示されることは、とても苦痛なのではないでしょうか。 キャリア・働き方を考えるブログ: 第3回 システム開発とは「感謝／助け合いの連続」ではないかという考察（2） PMが単なる「丸投げ」をしていたのであれば、彼らのモチベーションは上がることもありませんでした。試行錯誤するメンバーと一緒に考え、時には手助けをしたからこそ、メンバーは継続的に期待に応えようとしたのです。 キャリア・働き方を考えるブログ: 第3回 システム開発とは「感謝／助け合いの連続」ではないかという考察（2） これこそ管理者の仕事だと思う。 スケジュールとか線表とかWBSを作るだけが仕事だと思っているPM？が多すぎる。 線を引いたらそのとおりにシステムができるんなら管理者なんて
ソフトウェアのプロジェクト管理に「実験」の余地を
毎週何千ものプロジェクトが頓挫していくのはなぜだろう。わたしたちは自分のプロジェクトとその環境で何が起きているかがつかめないのに、まるで未来を予言できる超能力があるかのように振る舞っているのが現実だ。われわれは愚か過ぎて現実が理解できない。 ではどうしたらいいのか。ガントチャートが作成できないというのなら、何が残っているのか。 作りたければガントチャートを作ればいい。問題なのはチャートではない。現実がそのチャート通りに進むと考えてしまうあなただ。言っておくが、チャートはただのコミュニケーションの道具にすぎない。ただのアイデアであって、不可侵なものでも何でもない。 自分も人間だと認めていいのだ。タスクが最終的にどうなるのかはっきり分からないからといって恥じることはない。とにかく試すこと、実験すること、試行錯誤だ。とにかくやってみて、どうなるか見極めることだ。それで正しい方向に向かうことができ
Amazon.co.jp: リストマニア
PMなら読んでるはずの本 asesino ソフトウェア品質管理のためのプロジェクトマネジメント "H14頃の「ソフトウェア産業、CMM、オフショア事情」などが紹介してある。CMMをとりましょうという啓蒙本か。" ITプロフェッショナルのためのビジネススキル プロジェクトマネジメント入門 "理論や技法の理想論で教科書風。図は整理されている。文章は分かり易い。でも続けて読める面白さはない。" 楽しく成功するプロジェクト・マネージメント (SCC Books) "非プログラマ向けPM講座、技術用語少なめ。流し読みするだけでもシステム開発の概要が頭に入るつくりが良い。" Joel on Software "プログラマ向けで読み物として面白い。でも開発経験ないと無理、面白さが分からないかと。" 要求仕様の探検学—設計に先立つ品質の作り込み "要件定義に失敗しているプロジェクトに参加しないといけない。
今だから出来る業務システムを
先日、とある業務システムの事例が発表されていました。最先端を好むエンジニアに評判の良い最新技術を採用しての開発ということで大きく注目を集めたようです。その事例記事自体は普通の紹介記事なので、そこからあれこれと邪推するのもどうかと思うのですがいくつか気になるところがあり、それが日本の業務システムの問題の一部を体現している気がするので、ちょっと気になるところを書き連ねてみます。 その記事には画面のスクリーンショットが掲載されていました。見た瞬間に「未だに？」と感じてしまいました。どういうことかというと、画面の一番上がラジオボタンになっており、 ◎追加 ○更新 ○削除 と、まずは今から行う操作の種別を入力するようになっているのです。 これは「伝票入力する」という業務がそのまま残っているということになります。どういうことかというと、昔々というのはコンピュータが非常に高価な時代でした。そこでまずは入
5分で絶対に分かるプロジェクト管理
メディア 記事一覧 オルタナティブ・ブログ 用語辞典 ITmedia エンタープライズ 5分で絶対に分かるプロジェクト管理：5分で絶対に分かる（2/6 ページ） » 2008年09月17日 12時00分 公開 [今田忠博，＠IT] 前のページへ 1|2|3|4|5|6 次のページへ 前のページへ 1|2|3|4|5|6 次のページへ Copyright © ITmedia, Inc. All Rights Reserved. SpecialPR 検索 SpecialPR 注目のテーマ 人気記事ランキング WSUSが廃止に Windows Serverアップデート管理はどうなる？ SAPの取締役会から2人が退任 オンプレユーザーのクラウドリフトへの難航が理由か リコージャパンがサプライチェーン攻撃被害を報告 委託先がランサムウェア感染か 「ChatGPT」がウソをつくのは使い方が悪いから？
「派生開発を成功させるプロセス改善の技術と極意」 - asa nisi masa
昨日読んだ本。いろいろ考えさせられる本だった。 「派生開発」を成功させるプロセス改善の技術と極意 作者: 清水吉男出版社/メーカー: 技術評論社発売日: 2007/10/27メディア: 単行本（ソフトカバー）購入: 10人 クリック: 127回この商品を含むブログ (28件) を見る 当書籍では、「派生開発」という用語を「新規開発」以外の開発すべてを指す用語として使用している。「派生開発」は、改修や機能追加のすべてを含む。 ※「派生開発」は、著者が作成した用語である。 よく知られている通り、ソフトウェアライフサイクルの殆どはこの「派生」に属し、費用も新規開発の何倍もかかる。従って、この部分をどれだけ効率よくできるかが、TCOの削減に大きく寄与する。また、当然のことながら、「派生」で障害が発生すると業務に支障が出、顧客に迷惑をかけることがあるため、重要度はとても高い。 にも関わらず、「派生」
「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えよう - kなんとかの日記
はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ
「Excelでプロジェクト管理」が圧倒的多数、しかし満足度は低め
昨今、システムの開発はより複雑化、多様化しており、開発者には成果物の品質向上や短納期、低コストをはじめとするさまざまな課題がのしかかっている。その中でも、現場の人間が最も問題だと感じているのはどの部分なのだろうか。 また、プロジェクトを成功させるためには「品質・コスト・納期」という3要素のバランスを取ることが不可欠となる。その実現をサポートするものの1つとしてプロジェクト管理ツールが挙げられるが、現場で求められている機能とはどのようなものか。本当に使いたい機能、使える機能とは何か？ そこで今回、TechTargetジャパンでは、プロジェクト管理に関する課題やプロジェクト管理ツールの利用状況を調査するため、会員を対象に「プロジェクト管理ツールの利用状況に関するアンケート」を実施した。656件の有効回答から見えてきた現状を読み解いていく。 関連ホワイトペーパー Excel | 工事進行基準 |
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクトの遅れを取り戻す方法10選 - finalventの日記
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist