＠IT：初めてのソフトウェアメトリクス（前編）
ソフトウェアメトリクスとは ソフトウェアメトリクス（品質測定：メトリクス）とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。普段実際の開発現場では触れられることの少ないキーワードですが、本記事では「ソフトウェアの品質向上」という視点からソフトウェアメトリクスに焦点を当て、開発現場へのメトリクスの導入方法やその効果について解説していきます。 ソフトウェアにとっての品質 エンジニアなら誰もが、良いソフトウェアを作りたい、という思いを持っていると思います。ところが現実には、理想的なソフトウェアを作成するための十分な時間も潤沢な予算もなかなかないのが現状だと思います。それは、ソフトウェアの良しあし、すなわち品質ということについて、顧客と開発会社双方に十分な認識がないからです。このような“慣習”がソフトウェアの開発業界において「作りっ放しで終わり」という悲しい風潮をまかり通らせる背
「現状のソフトウェア開発は間違っていないか？」（プロセス編）
失敗例その1 「要件定義が終わらない」 ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基本設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに１カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。 失敗例その2 「設計工程の無駄」 オープン系の開発でウォーターフォール開発を行っている。設計工程は、基本設計、詳細設計に分かれている。基本設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるた
第1回 「インターネットショップ」はすぐには作れない
この連載では、ITプロジェクトの立ち上げからサービスイン・メンテナンスという実際のプロジェクトの進行に沿って話を進めながら、それぞれの場面で必要な基礎知識をあらためて解説し、「最低限押さえておきたいキーワード」を紹介していきます。 この季節、真新しいスーツに身を包み、毎日の技術研修に明け暮れるフレッシュなシステム・エンジニア（の卵）たちが目立つ一方で、年度初めの4月からいままでとは全く畑違いのIT部門の責任者に任命され、いまさら基本的な技術をどう学んでいこうか？ 何も知らなくて話についていけるだろうか……と頭を悩ませている読者の方もいるのではないでしょうか。私自身の経験として、それまで従事していたインターネット系システム部門から金融系システム部門に異動となり、「COBOLって？ JCLって？」とメンバーとの技術的な議論についていけるよう、そのときになって必死に入門書を読みあさった記憶があり
エンジニアにとっての本当の「顧客」は誰？！
システム開発における「人」（＝開発担当者）に視点を当て、普遍性を持ったプロジェクト運営プロセスを探り出す連載の第3回です 前回「エンジニアのやる気は報酬だけじゃ維持できない、前々回「スキルシートでいったい何が分かるのか」は、プロジェクト内でうまく活躍できなかった担当者を例に取り、その原因を探りました。今回はプロジェクトでは活躍し、貢献したものの、プロジェクトを去らねばならなかった例を見てみましょう。その中から、これまでと同様、「プロジェクトと人」をうまく結び付ける要因を探ります。 まずは、前回のWeb投票「プロジェクトへのモチベーションが一番高まるのは以下のうちどれを獲得したときといえますか？」の結果を確認してみます。 金銭的報酬 107人 35.2％ 107人 35.2％ 顧客からの評価 73人 24.01％ 73人 24.01％ チームメンバーからの評価 21人 6.91％ 21人 6
エンジニアのやる気は報酬だけじゃ維持できない（Page 1） ― ＠IT情報マネジメント
本連載は「プロジェクトと人」を「人」に視点を当て、そこからある程度の普遍性を持ったプロジェクト運営のプロセスを探り出すことを目的としています。第1回（「スキルシートでいったい何が分かるのか」）はEさんを例に、プロジェクト内でうまく活躍できずに去らざるを得なかった経緯を見ながら、「チーム構成プロセス」や「開発プロセス」の「難しさ／問題点」を洗い出しました。今回は、皆さんから寄せていただいた第1回記事に対するWeb投票結果の考察から話を展開していきます。 集計結果から導き出される次なる課題 以下がWeb投票の結果です。「第1回において、Eさんがチームを去らねばならなかった最大の問題点は何だと思いますか」というのが質問です。選択肢は5つ設定しました。 プロジェクト入隊試験などフィルタリングを行わないチーム構築プロセスの未整備。あるいはメンバー選びなどを支援するノウハウのない所属する組織 メンバー
すごい技術者はすごいマネージャになれるか？
前回「エンジニアにとっての本当の『顧客』は誰？！」はFさんを例に、単に活躍するだけでもうまくいかない事例を通して「ステークホルダー」の調整の難しさを考えてみました。 さて、早速前回のWeb投票の 結果（2007年3月5日時点）を簡単に分析してみましょう。 ［質問］ ITプロジェクトの運営・遂行の上で非常に重要なのは？ ■アンケート結果 メンバーのスキル 23人 33.82％ マネージャのスキル 19人 27.94％ 見積もり 13人 19.12％ プロセス 6人 8.82％ 根性 7人 10.29％ まず2位について。やはりプロジェクトの成否において、マネージャのスキルは誰もが重要だと考えています。プロジェクトの遂行に責任を負っているのが「プロジェクトマネージャ」という言葉の意味である以上、最初に「重要な要素」として挙げられるのは理解できます。 例えば、多くの場合システムが「オーダーメイド
スキルシートでいったい何が分かるのか（Page 1） − ＠IT情報マネジメント
本連載はプロジェクトの成否を握る大きな要素「人とチーム」の関係に焦点を当てます。開発プロジェクトが成功するか失敗するかは結局、開発チームを構成するそれぞれのスタッフの力量にかかっているといってもいいかもしれません。 ITプロジェクトの人集めって何だろう？ システム構築と「人集め」 プロジェクトを遂行するとき、マネージャとアーキテクチャの大切な仕事の中に「チームづくり」があります。プロジェクトの成否・効率は「人選び」によって左右されるといっても過言ではありません。 この「人選び」にも大きく分けて2種類あります。1つは「プロジェクトの命運を握る人」という意味での人選びです。「マネージャ」「アーキテクチャ」といった中心的な役割を果たす1、2名がこれに当たります。もう1つは、そういった「命運を握る人」が一連托生（いちれんたくしょう）として選ぶ「プロジェクトメンバー」です。 無論、人選をはじめとする
お茶でも飲みながら会計入門 インデックス － ＠IT自分戦略研究所
売上検収×債務支払×給与 新春三題噺 お茶でも飲みながら会計入門（88）「請求書がなくても支払われるものなーんだ？」今回はランダムに選んだ3つのテーマで、お話します
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
