エンタプライズ系事業/機能要件の合意形成技法 | アーカイブ | IPA 独立行政法人 情報処理推進機構
発注者と開発者の認識の齟齬により要求と実現されるソフトとの間に「ギャップ」が生じます。具体的には、次の（1）～（3）のようなギャップが生じます。 要件定義すべき内容が抜けており、開発者に説明していない。 発注者が開発者に説明したが、何らかの理由で漏れた。 開発者が何らかの理由により誤認・拡大解釈し、実現範囲に取り込んでしまった。 機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するための次のようなコツを集めたものです。 実現したい情報システム像について発注者と開発者が合意形成するために、伝える側が漏れなく正確に情報を提供するためのコツ 発注者と開発者との不充分な合意形成が原因で下流工程で発生する手戻りを防止するための先人の開発者のコツ 機能要件の合意形成ガイドは、「概要編」 と次の6つの技術領域のコツをまと
プロジェクト工程の比率について | ReMIXのブログ
プロジェクトの前提条件や性質により、変化があるものではありますが、おおよその参考にはなるかと思います。使い方として、例えば製作の工数が決まっているのであれば、そこから基本設計や詳細設計などの工程の工数を算出することができます。もちろん、プロジェクトによって、設計書の求められる分量や精度など変わってくるのでそのあたりはチューニングしていく必要があると思います。 さらに予測精度を上げるには、やはり自社開発の計測値を蓄積し、同一のお客様や類似案件の割合などを参考にするのが良いと思います。 工程別工数の割合(新規開発) 新規開発の場合の工程別工数比率になります。箱ひげ図になっています。○になっているのは外れ値になっているので、平均や中央値には反映されません。難しいという人は、箱ひげ図の見方を検索するか、下の表に中央値や平均値が載ってますのでそちらを参考にしてもらえばと思います。 ソフトウェア開発デ
GTD歴６年目の私が、これ以上ないくらい丁寧に解説します【総括】 – BrownDots
メンテナンス作業に失敗し、すべてのエントリーから画像を削除してしましました。 過去ログの中でもこちらのエントリーだけ特に需要が多いため、新ブログにて改めて同様の内容のものを再掲しております。 よろしければ、そちらを御覧ください。 【再掲】GTD歴６年目の私が、これ以上ないくらい丁寧に解説します | BrownDots こちらのページをブクマされている方がいらっしゃいましたら、お手数ですが新しいページヘブクマ下さい。 様子を見て、こちらのエントリーを非公開へ切り替えるつもりです。 毎日更新は無理だろうけれど、せめて平日更新でライフハック記事を！と、挑戦してきたGTD連載だけれど、今回がいよいよフィナーレ！ ……と、言っても、もう付加情報はなくて、ただのブクマまとめだけれど、まあ、とりあえず読んでほしい。 それぞれのエントリーについての要点をまとめたので、内容も整理されてて読みやすくなってるよ
優れたリーダーに学歴は関係ない。Googleが自社社員をデータ分析して得られた意外な知見(ライフハッカー［日本版］) - goo ニュース
(ライフハッカー［日本版］) Inc.：シリコンバレーで成功を収めている人は、スタンフォード、MIT、ハーバード出身の天才ばかりだと思っていませんか？ 冴えわたる技術力を武器に、ビジョンに突き動かされ、急場をしのぐ。そんな典型像を持っている人は多いでしょう。Googleに就職するには、スタンフォードまたはMITを出ていなければならないと言われていた時期もありました。2012年ごろまでは、大学を出て10年以上たっていても、大学時代や高校時代の成績を聞かれるのが常だったのです。しかしGoogleは、仕事での成功と学歴はまったく無関係であることを発見しました。従業員がリーダーとして成功を収める条件を知るためにデータを分析したところ、驚くべき結果が出たのです。結論から言うと、典型的なイメージはまったくの間違いでした。リーダーとしてもっとも重要な資質は、卒業した学校でもIQでもありません。むしろ、も
「できない人」にいくら教えても「できる人」にならないのか
「こういう言い方をしたらいけないのかもしれないが、結局は生まれつきですよ。できる人に機会を与えれば、自分でできるようになる。できない人にいくら懇切丁寧に教えても、できる人にはならないね」 この身も蓋もない発言を聞いたのは、筆者が駈け出しの頃だったから、もう20年以上も前だ。情報システムの開発を成功させるにはどうすればよいか、色々な方を取材していたとき、「開発で一度も失敗したことがない人がいる」と紹介され、その人に会ったところ、こう言われてしまった。 そもそも、失敗しないその人との話はあまり弾まなかった。「なぜ失敗しないのですか」と聞くと相手は「うーん。失敗したことがないからなあ」と首をひねった。「あなたのように失敗しない部下をどう育てますか」と問うと、冒頭の答えが返ってきた。 当時のことを思い起こしてみると、筆者の取材能力に問題があり、相手から話をうまく聞き出せなかった。その人が不親切であ
第12回 「自動化」と「可視化」でプロジェクトを管理、進捗や品質が一目瞭然に
第12回 「自動化」と「可視化」でプロジェクトを管理、進捗や品質が一目瞭然に ソフトウエア開発の自動化（6）プロジェクト管理の自動化 ビジネスを取り巻く環境の変化が速くなり、それとともにソフトウエア開発プロジェクトの短期間化が進んでいます。このような中では、プロジェクトの一部に数日の遅延が発生しただけで、プロジェクト全体の進行に影響する大きなダメージとなりえます。 このためシステム開発プロジェクトの進捗や品質を管理するプロジェクト管理では、「プロジェクトの見える化」そして「リアルタイムなプロジェクト管理」が非常に重要になります。「プロジェクトの見える化」によって、遅延や遅延しそうな傾向にあるチームの状態を把握できるようになります。「リアルタイムなプロジェクト管理」によって、その遅延を早期に検知でき、素早くアクションをとることで、フィードバックの高速化を実現できます。 「プロジェクトの見える
「新3種の神器」で開発現場を改革しよう
「プロジェクト管理（PM）ツールや情報共有ツール、継続的インテグレーション（CI）ツール、継続的デリバリー（CD）ツールの導入状況は、どうなっているのか？」。 この実態を明らかにすべく、日経SYSTEMS編集部では3月15日から4月18日にかけて「開発支援ツール徹底調査2013」を実施した。同調査は以前の記者の眼で協力をお願いしたものだが、結果が出そろったので、ここに詳細を報告したい。 なお、調査ではカテゴリーを「PM/情報共有ツール」「CI/CDツール」の2つに分けて、カテゴリーごとに利用状況や利用しているツール名、利用開始時期などを尋ねている。有効回答件数は1532件となった。 PM/情報共有ツールは使い分けが進む まずは、PM/情報共有ツールの調査結果から見ていこう。直近2年間でPM/情報共有ツールを利用したことがあるという回答は、846件に当たる55.2％だった。回答者の2人に1人
第89回 PMOとして品質にどう向き合うか？（後編）
前回は、品質管理の勘所として次の4点を挙げ、最初のポンインについて考察しました。（1）品質指標の妥当性と目標値の意味づけ、（2）設計品質と開発品質、（3）プロセス品質とプロダクト品質、（4）非機能要件に関する品質の確保――。今回は残りの（2）～（4）のポイントを見ていくことにしましょう。 後藤 年成 マネジメントソリューションズ 取締役 PMP 私はプロジェクトの現場で「良いシステムを開発するために、テスト期間を長めにとって、たくさんテストを実施しましょう」という言葉を何度か耳にしたことがあります。「品質を上げるには、テストでたくさんのバグを出せばよい」と信じている方もいらっしゃいます。 確かに、アジャイル開発のように「設計～テスト」を繰り返し実施することで品質を実用レベルに高めていく開発手法もあります。しかし、ウォーターフォール型の一般的な開発手法においては、上流工程（要件定義や基本設計
Redmine 1.1 新機能紹介: コミットメッセージによる作業時間の記録
Redmineには チケットに記録した作業を実施するのに要した時間を記録する機能 があり、チケット更新時に「時間を記録」欄を記入するか、チケットを表示して画面右上の「時間を記録」をクリックして表示される「作業時間の記録」画面によって作業時間を記録することができました。 Redmine 1.1ではこれらの方法に加え、Subversion等のリポジトリにソースコードをコミットする際のコミットメッセージに作業時間を記述することでも記録できるようになりました。 以下は、チケット#9999にコミットを関連づけた上で作業時間2時間30分を登録する例です。リポジトリのリビジョンとチケットを関連づけるrefs, fixes, closes等のキーワードとともに作業時間を記述できます。 ○○画面の表示不具合(カラム落ち)を修正。 refs #9999 @2h30m コミットメッセージによる作業時間の記録機能
Redmineの工数管理機能
作業時間の記録 作業時間の記録は、チケットまたはプロジェクトに対して行います。原則としてはチケットに対して記録しますが、対応するチケットがない作業などは、プロジェクトに対して作業時間を記録することもできます。 作業時間を記録する方法は4つあります。1つ目と2つ目はチケットに対して記録する方法です。3つ目と4つ目の方法は、チケットまたはプロジェクトに対して作業時間を記録することができます。 チケットの更新時に「作業時間」欄を入力 リポジトリへのコミット時、コミットメッセージに記述 チケット表示画面で「時間を記録」をクリックすると表示される画面から入力 プロジェクトメニュー「＋」ボタンから「時間を記録」をクリックすると表示される画面から入力 記録方法1: チケット更新時に作業時間を記録する 項目「作業時間」に作業時間(時間単位)を入力し、項目「作業分類」で作業内容の分類を選択してください。入力
管理職のコミュニケーション、3つの基本
管理職の仕事は、メンバーを「監視し、働かせる」ことではない。彼らの考えていることをキャッチし、自立的な行動を促し、それを仕事の成果に結びつけられるよう導くことである。 もともと管理職には調整役としてのコミュニケーション・スキルが求められる。だが、昨今のIT管理職に必要なのは、さらに一歩踏み込んだコミュニケーション・スキルである。具体的には次の3つがあるという。 （1）センシング：メンバーの夢・興味のあること、隠されている不平不満などを察知するスキル （2）共感：メンバーの想いに共感し、さらに考えていることを引き出すスキル （3）演出：メンバーの主体性を引き出し、自立的な行動を促すスキル 連載『IT管理職のコミュニケーション新常識』では、メンバーとのコミュニケーションや人材育成に頭を悩ましているIT管理職の人たちに役立ち、しかもすぐに始められるテクニックやツールを解説している。ぜひ参考にして
NECが提供するクラウド型ソフトウェア開発環境「ソフトウェアファクトリ」の利用者が1万人を突破
NECは、ソフトウェア開発の品質やコスト、納期の改善を目的として、ソフトウェア生産革新活動を推進しており、「ソフトウェアファクトリ」はソフトウェア生産革新活動のプロジェクト管理と、技法・ツール等のエンジニアリング面において、中心的な役割を果たしている。 「ソフトウェアファクトリ」の使用によって、開発プロセスや方法論、ツールの標準化や、ソースコードおよび仕様書などを共有が可能になるとともに、セキュリティ脆弱性検査やバグ検出などの自動化を促進して、生産性と品質の向上を目指す。また、開発状況のリアルタイムでの「見える化」によって、マネジメント力の強化を実現する。 「ソフトウェアファクトリ」の利用が拡大した結果、拠点が国内外に分散している場合でも、開発環境や仕様書などの共有によって作業のやり直しなどが減り、製造やテスト工程のコストを10～20％削減した。また、ハードウェアの用意や、プロジェクトごと
成果を生む人間関係の「グッドサイクル」と「バッドサイクル」
プロジェクトの成果を上げる秘策は、良い人間関係を築くこと。それをどのようにすれば実現でき、どうなれば失敗に陥ってしまうのか、ご存じだろうか。 前回はプロジェクトを働きづらいものにしてしまう、リーダーが抱きがちな「思考の枠」とその広げ方を紹介した。今回は、「働きやすいプロジェクト」をつくることが成果につながる理由について解説しよう。 「働きやすいプロジェクト」と聞くと、仲良しクラブのようなものをイメージするかもしれない。しかし、ここでいう「働きやすいプロジェクトづくり」の目的は、メンバーと仲良くすることではなく、あくまでもITマネージャーの責務である「成果を上げる」ことにある。成果を上げるための最短のプロセスが「働きやすいプロジェクトづくり」なのだ。 ITエンジニアの中には、何か新しいことを始めたり他人から仕事を頼まれたりした時に、その目的や理由が論理的で、なおかつ、自分が納得できなければ動
上司を巻き込むための6つのステップ
今回は連載の最後として、あなたが平社員で組織の末端にいる立場でも、上司や先輩を巻き込んで組織を動かすためにどうすればよいかを考えていきましょう。組織末端から全体を動かすという壮大なテーマです。 これまで3回の連載で説明してきたことを復習してみましょう。 1．自分に閉じないこと（自分が一生懸命やっているなら、他人も一生懸命） 2．物事は因果で考える（考え方を変えれば、行動か変わり、結果が変わる） 3．ジレンマはWin-Winの解決策が必ずある（思考のボトルネックはWin-Winで解ける） 今回はこの3つで改革を成し遂げるためにどうすればよいかを考えていきます。 誰を巻き込むかで結果は変わる 巻き込む相手を間違えれば、永久に願いは成就しません。ですから改革を仕掛ける第一歩は、仕掛ける価値のある相手を見抜くことなのです。 連載第1回の冒頭に「自分に閉じないことが大事だ」というお話をしました。良い
評価を高める仕事術（25）「話が伝わらない人」の頭の中
この連載では，「ダメに見せないことで評価を高める」ための仕事術を扱っている。前回までは、「仕事が進まない、放置体質」というネガティブ特性について説明した。ネガティブ特性は以下の通りである。 先を読まない、深読みしない、刹那主義 主体性がない、受け身である うっかりが多い、思慮が浅い 無責任、逃げ腰体質 本質が語れない、理解が浅い ひと言で語れない、話が冗長 抽象的、具体性がない、表面的 説得力がない、納得感が得られない 仕事が進まない、放置体質 言いたいことが不明、論点が絞れない、話が拡散 駆け引きできない、せっかち、期を待てない 今回から10番目の「言いたいことが不明、論点が絞れない、話が拡散」について説明する。 「言いたいことが不明」「論点が絞れない」「話が拡散」の三つは、ここではどれも同じこと＝「何を伝えたいのか分からない、相手に伝わらない状況」を意味する。「何らかの目的を持つ説明に
第1回 3割減の工期で「いつもの疲弊が無い」
富士通グループと大和ハウス工業は、現在進行中の基幹系再構築プロジェクトにCCPM（クリティカルチェーン・プロジェクトマネジメント）という管理手法を適用した。この結果、開発フェーズとテストフェーズでそれぞれ3割近い工期短縮に成功した。2012年4月の稼働開始に向けて、現在は既存システムからの移行準備と運用テストを進めている。 プロジェクトの遅延が当たり前、とも言われているシステム開発分野において、3割ほどの工期短縮は珍しい。そこで本連載では、CCPMがどのように効果的だったのか、マネジメントをどう工夫したのかなどを3回にわたって詳しく解説していく。第1回では、プロジェクトの概要を紹介するとともに、CCPMとは何か、CCPM採用の経緯、導入効果などについて、プロジェクトリーダーたちの声を交えながら探る。 富士通グループと大和ハウス工業は2010年1月から、大和ハウス工業の基幹系システムの再構築
TimingAndEstimationPlugin – Trac Hacks - Plugins Macros etc.
Download and Source SVN Trac 1.0 branch. SVN Trac 1.0 branch with permissions. Zipped source for plugin for Trac 1.0. Zipped source for plugin for Trac 1.0 with permissions. When downloading these files then either the extension is lost or the filename corrupted. A simple rename to filename.zip seems to resolve it and the contents remain intact. Note: Email Notifications are currently unaffected b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ipa.go.jp/sec/old/users/events/events_tokyo_20170310-2.pdf
少人数チームにおけるプロジェクト管理のベストプラクティス
日本語 : Jenkins