システム開発案件が寄せられた時、それがどの程度の工数を必要とするかを見積もることはとても重要だ。開発の「規模感」がイメージできれば、投入すべきリソースも見当がつくし、それはそのままコスト面での計画にも結び付く。 経験則に拠ったり、開発協力ベンダーが提示してきた概算に頼るという方法もあるが、世の中一般の開発プロジェクトから導き出した「指標」を参考にすることも検討したい。 日本情報システム・ユーザー協会（JUAS）が2004年度から毎年続けている「ソフトウェアメトリックス調査」では興味深い調査結果を発表している。スクラッチ開発、つまりパッケージソフトを利用せずに独自でゼロから開発することを前提とした場合、対象システムに実装する「画面数」「バッチ処理数」から、おおよその総工数が見積もれるというものだ。その計算式は以下で表される。 総工数（人月） ＝ 0.97 × 画面数 ＋ 0.26 × バッチ
結局皆さんテスト密度等の実際の数字が気になるところですよね。今まで出てきた数字をまとめてみます。指標の数字は実施している手順やテストケースの書き方等に大きく影響されるので一概にこれが正しいという数字はありません。しかしなにも手がかりや実績も無いという人もいらっしゃるかと思いますのでそのような場合は以下のような設定をおいてみるのも良いかもしれません。ちなみにKLOCはJavaがベースです。 開発期間 開発期間＝工数^0.5 開発期間は平方根で求めます。たとえば9人月の作業は3人で3ヶ月です。 最大期間短縮率 最短開発期間＝工数^0.5*0.75 短縮率は最大75%。これ以下の開発期間はデスマ高し。 工数割合 設計:実装・テスト 3:7 設計終了段階で既に4割くらい使ってしまっているとかなりデスマ率は高いと思うので機能を減らす等早めに手を打った方が得策かもしれません。 ケース数 単体：150ケ
Sign in - Google Accounts
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
本気で独立するなら己の部隊を持つがいい。規定によれば部隊の最小人数は、指揮官1名に隊員6名だ 攻殻機動隊ARISE 見ました。私は精神的・心理的世界描写が多い作品というのはあまり好きではないのですが、珍しく素子の柔らかい心の描写があり、新鮮で面白かったです。 さて、ある場面で荒巻課長が、素子に上記のような言葉を投げかけるシーンがあります。これを聞いてある書籍を思い出した。 プロジェクトリーダーのための入門チームマネジメント 理想のチーム構成数は7人 組織の最大規模は150人 日本の会社の組織を振り返って プロジェクトリーダーのための入門チームマネジメント プロジェクトリーダーのための入門チームマネジメント―6人で9人分の仕事をする組織最適化の法則 (PHPビジネス選書) 作者: インタービジョン総合研究所,小林惠智 出版社/メーカー: PHP研究所 発売日: 2001/05 メディア: 単
「イノベーション」 という言葉を聞くとウンザリ、という方は少なくないのではないでしょうか？ 社内横断で、新たな事業領域を創りだそう 今までとは発想を変えたプロジェクトを起案して欲しい 社内コンペを開催し、資金獲得や、子会社設立のチャンスも与える こうした話は、 「GoogleやFacebook、Appleみたいなイノベーションを起こさないと」 「低価格のサービスは、中国・インド・東南アジアなどに奪われる」 といった言葉とともに、「イノベーションで、圧倒的付加価値を付けた製品・サービスを提供しなければならない」という文脈の中で、多くの企業で語られています。 そして、ご存知の通り、こうした営みの多くは、企画・検討段階を抜けられない事業案で終わったり、そこに至ることもなく解散したりしてしまうことがほとんどです。 そこで本記事では、時価総額１兆円を超えるメガベンチャーを次々と生み出すシリコンバレー
http://www.slideshare.net/reed2001/culture-1798664 どうして高いパフォーマンスにこだわるかというと、よいチームづくりができれば、業務フローベースの仕事だと２倍、クリエティブ/開発系の仕事だと10倍成果が違ってくるからです。 パフォーマンスよりも職を失わないことを重視する人には向かない職場です。 責任感がある人は自分で行動を起こせます。ですので自由な環境で活かすことができます。多くの会社は大きくなるにつれて自由度が狭まりますが、うちは逆に広げます。 会社は大きくなると運営が複雑になり、高いパフォーマンスの社員率が減ります。そこで、「複雑化する業務プロセス」と「高いパフォーマンスの社員がこなせる業務範囲」の差分を埋めるために、官僚化が進み、つまらなく感じた高いパフォーマンスの社員が更に減るというサイクルにおちいます。 プロセスを整備して官僚化す
２０代後半から１５年ほどSIプロジェクトのリーダー／マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル（MLB監督） ●ポリシー １）全てのメンバーが目的・段取りのわからない仕事をしない／させない。 ２）プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 ３）プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 ４）プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 ５）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ６）みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 ７）人は一人一人別人であり仕事に対するスタ
ソフトウェアアーキテクチャとプロジェクトマネジメントは相互に絡み合う要素です。この関係性を歴史の流れから考えていくと面白い推測が成り立ちます。 アーキテクチャの歴史 「アーキテクチャとは」というのに定まった定義はありませんが、大枠では「システムの目的や環境を前提とし、様々な利害関係者の関心事を整合させた、システムの構成や構造」のことです。 これはもちろん「あるべき姿」です。完成されたシステムには必ず構成や構造がありますが、それが「システムの目的や環境、あるいは様々な利害関係者の関心事」と完全に合致しているとは限りません。 （ソフトウェア）アーキテクチャという言葉、あるいは（ソフトウェア）アーキテクトという用語は2000年前後から一般的になってきました。逆にいえば当時は「システムの構造や構成」と「システムの目的や環境、あるいは様々な利害関係者の関心事」の不一致があったということでしょう。 で
Web業界の業務委託について考察してみたので記事を書いてみる。 今回は、業務委託費として必要な単価を、各種パラメータを適当に置いて計算した。 アウトプットは、「会社がそれなりに幸せであるための、平均単価」です。 ■必要なパラメータ 1. 必要な給料の定義 社員平均 700万円／年とする。 なお、労働35年として、35-40歳くらいでピークで700万とした場合、大体、生涯賃金は下記。 青棒：1億9000万円（ピーク後の下がり方が緩やか） 赤棒：1億5000万円（ピーク後の下がり方が急） 現実的には、赤棒よりもさらに厳しい業界かも。ここは別途考察します。 2. 平均チャージ率 80%とする。 日々の業務のなかで、クライアントにチャージ（請求）できる業務の割合が何%くらいかという指標。 たとえば社内の行事や、営業にかかる時間、瑕疵対応にかかる時間とかは、クライアントにチャージできない。 もちろん
わたしは今、顧客と興味深いやりとりをしている真っ最中なのだが、他の顧客や組織も同じ問題で苦しんでいるのかと気になった。この顧客のところでは、開発者として契約したスタッフメンバーが、（リソース不足と人員削減のあおりで）テスターとビジネスアナリスト（BA）を兼ね、時にはプロジェクトマネージャー（PM）の役割も果たすことを求められている。この状況で起きる困難には、リソース管理の難しさ、役割の混乱、スキルの不一致、士気ややる気の低下、そしてビジネス上の成果を上げることの難しさも含まれる。 では、これらの困難についてもう少し詳しく見てみよう。 開発者として投入されたチームメンバーや契約業者がBAやPMの役割も果たさなくてはならない場合、リソースプールの状態を理解したり、管理したりするのが難しくなる。例えば、ある開発者は、ビジネスの分析やプロジェクト管理、テストにどれだけの時間を割いたのだろうか？事業
変更履歴 2012-06-24 ドキュメントの所に *diag シリーズについて追記 概要 開発があればリリースがあり、リリースが終われば、メンテナンスがあり、さらに開発があります。プロダクトが EOSL (End Of Service Life) を迎えるまではこれを続ける必要があります。 去年の 8 月に「継続開発のススメ」というので、やっていることをまとめたのですが約 1 年経ってもう少し細かくまとめて見ようと思いました。基本的には自分がいる環境を前提に書いてます。 継続開発のススメ http://d.hatena.ne.jp/Voluntas/20110823/1314036482 開発スタイルは常に変化し続けていくべきだと思っています。これだ、というのを作らないのが一番良い開発スタイルでは無いかなと。 脳内を書き出しているので、日本語がおかしい上に一貫性が無いと思います ...
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
※最後に2つ追記しました。 この話面白い。 11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - デジタル - 日経トレンディネット http://trendy.nikkeibp.co.jp/article/column/20111215/1039018/ スマホゲームアプリの開発を命じられたのは、東日本大震災直後の今年3月。 出された課題は 「4月から開発に着手し、7月末までに70タイトルそろえる」 「開発スタッフは既に決まっている人間で進める」 「8月にTVCMなど大々的なPRを行うため遅延は許されない」の3点 『11のやめたこと。』 1.「組織の細分化、階層化をやめる」 マネジャーが増えるということは、ゲームの作り手が一人減るということ。 優秀な人間がマネジャーになるほど、アプリの制作力は低下する。 2.「職種別の目標設定をやめる」 プログラマー、企画など
組織パターンのジム・コプリエン(James O Coplien)氏と、スクラムの共同開発者のジェフ・サザーランド(Jeff Sutherland)さんが中心になって、スクラムを組織パターンで説明する取り組みがありました。その成果であるパターンの概要を日本語にしてみました。内容に変なところ等がありましたらぜひご指摘ください(GitHubにホストしました)。 原文はこちらにあります。 スクラムパターン概要 スクラムが効きそうにないところを除いたパターン これらのパターンがスクラムそのものだ。2008年6月、スクラムの創立者(訳注:ジェフ・サザーランド氏)と組織パターンの開発者(訳注: ジム・コプリエン氏)が、数名のエキスパートとともに、組織パターンの本に記述されたパターンを、スクラムフレームワークの中で適用する際の、全体像(マップ)を作成した。これらのパターンは、スクラムフレームワークの代表的
ソフトウェアプロセス改善カンファレンス2011で細谷，吉岡，森崎「産学連携によるデザインレビューの改善事例」が実行委員長賞を受賞しました。発表は細谷氏（三菱電機）。アブストラクト、発表スライド、発表とも細谷氏が中心に実施くださいました。発表スライドはここ(ソフトウェアプロセス改善カンファレンス2011のサイト)で公開されています。 社内で使うレビューのガイドライン作成をご一緒しました。プロジェクトにあわせて選択しながら使えるようなガイドライン作成を目指しました。細谷氏、吉岡氏とも社内のプロジェクトをよくご覧になっていて、プロジェクト全体の特徴や傾向を踏まえた上で検討できました。 公開資料にも掲載されています検討結果の1つをここで紹介します。ガイドラインでは、ウォータフォール開発でのレビューを工程完了間際だけでなく、工程の早い段階、途中の段階でも実施するための方法を紹介しています。ただし同じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
