なぜプロジェクトマネジメントは機能しないのか
みなさん、はじめまして。プロセスデザインエージェントの芝本秀徳です。本特集では、システム開発などのプロジェクトを成功に導くための大切な要素である「プロセス設計」と、そこから展開する「プロジェクトマネジメント」について解説していきます。まずは自己紹介を兼ねて、なぜ私が専業コンサルタントとしてこれらを追い求めることになったかというところから話を始めましょう。 「デスマーチ」体験からプロセス設計の重要性を知る 大学卒業後、私はソフトウエアエンジニアとして、ソフトウエアベンダーに入社しました。新入社員研修が終わり、その後はひたすら組み込みソフトウエアのテスト業務に取り組む日々が続きました。これが数カ月ほど続いた後、初めて開発メンバーとして参加したプロジェクトが、まさに“デスマーチ”となったのでした。 いつ収束するとも分からない不具合。本当の納期は客先の担当課長だけが知っていて、私たちは設定されたム
いずれにせよ貴方はシステム屋にボッタクられる
http://anond.hatelabo.jp/20131005064230 「システム屋に不当にボッタクられないための発注者心構え」の増田です。 システム発注業務を舐めきった増田に「ばーかばーか！お前のかーちゃんでーべーそー！」って煽り記事を書きましが、下の記事に、理性的かつ丁寧に諭されてしまいました。憑き物が落ちた気持ちです。 システム屋に不当にボッタクられたくない人のための要求講座 - novtan別館 http://d.hatena.ne.jp/NOV1975/20131008/p1 浅かった自分を恥じて素直に反省し、心を入れ替えて、更に丁寧に煽ろうと思います。 聞いて下さい、私の歌を。 ●「良い子、悪い子、普通の子」という幻想 良心的な企業なんてのは、存在しません。 「利益なんて１銭も要らない。人の笑顔が見られればそれで良い」。そんな奇特な偽善者は、営利企業じゃなくて慈善活動団
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
KLabが開発したゲームエンジン「Playground」のソースコードを公開（KLab株式会社 プレスリリース）
KLabが開発したゲームエンジン「Playground」のソースコードを公開 プレスリリース発表元企業：KLab株式会社 配信日時: 2013-09-26 14:00:00 KLab株式会社(本社：東京都港区、代表取締役社長：真田 哲弥、以下「KLab」)は、ソフトウェアのソースコード共有サービス「GitHub」に「Playground(プレイグラウンド)」をオープンソースとして公開しました。 「Playground」は、マルチプラットフォームな2D/2.5Dゲームを効率的に開発するためのフレームワークです。KLabのゲームタイトルではブシロード(本社：東京都中野区、代表取締役社長：木谷 高明)と共同開発した「ラブライブ！スクールアイドルフェスティバル」と、グローバル向けに開発した「Rise to the Throne(ライズ・トゥ・ザ・スローン)」(※1)に使用されています。 ＜ゲームタ
日本のシステム開発、たった1行の改修に1ヶ月 わずか1行でも影響調査に1ヶ月、テストに数週間かかる : SIerブログ
1: ドラゴンスープレックス(やわらか銀行) 2013/09/24(火) 22:43:10.25 ID:vEIJ3j4n0 BE:265920825-PLT(12070) ポイント特典 従来型開発の限界、たった1行の改修に1ヵ月 従来型開発では稼働開始時点の品質が最も高く、以降は低下していく。業務や外部環境の変化に素早く対応できるように、 カットオーバーを通過点と捉える「カイゼン型開発」に改めよう。 「改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった―」。アマダが従来利用していた基幹システムは、 長年の保守でシステムがつぎはぎ状態になっていた。保守作業は属人化が進んで、担当したベンダーの特定のエンジニアでないと、 手を付けられない部分が散在。過去の改修内容がドキュメントから漏れていたことがテスト段階で判明し、設計からやり直したことも1度や2度ではない。 シス
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
「技術的負債」とは何か。原典とその対応策を探る
負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,
[ThinkIT] 第7回：結合テストと総合テスト (1/3)
ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社
システム開発契約の基本契約と個別契約の違いとか - チョコっとラブ的なにか
システム開発契約についての勉強会に行ってきました。講師は、企業法務についてあれこれの雑記のkataさん（@katax）さんでした。即戦術的なTips話というより、啓蒙的＆根本的な話が中心で、それがなかなかに興味深かったです。 質疑応答というか雑談？で出た話が大事だと思うのでまとめてみるよ システム開発契約の基本契約と個別契約の違い 開発委託契約には、基本契約と個別契約というのがありますが、その違いが分からないという話がでました。 基本契約とは、企業間で、何度も反復・継続して行われる商取引に共通して適用される事項をまとめてあらかじめ定めたものです。この先、何度も契約を交わされるだろうと思われる企業間で、個別の取引全てに適用されるような、共通した約束ごとを先に決めておくための契約書が基本契約書です。 取引ごとに、著作権は・・・とか、いつから所有権が移転されるのか・・・とか、一から、都度都度条件
基礎から理解するデータベースのしくみ（8）
インデックスで検索を高速にする ここまでの説明でおわかりのように，一般にテーブル内のレコードがディスク上に格納される順序は，レコードを追加する順序やページに空きがあるかどうかなどに左右され，特定のキーの順番に並んでいるわけではありません。そのため例えば，従業員テーブル（emp）から従業員番号（eno）が71であるレコードを抽出するSQL文である SELECT * FROM emp WHERE eno = 71 のような単純な検索処理でも，テーブル内のすべてのレコードを一つずつ調べていかなくてはなりません。これではレコード数が膨大な場合に大変な時間がかかってしまいます。そこで，こうした特定のキーに対する検索を高速化するために用意されている仕組みがインデックス（索引）です。 インデックスの基本的な考え方は，書籍の索引と同じです。例えば，書籍の中から「テーブル」というキーワードを検索する場合，あ
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書 始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！ 1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。 これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視
RFP完全マニュアル 実践編
情報システムの調達におけるRFP（提案依頼書）の必要性は，ここ数年でかなり認知度が高まっている。以前はRFPを作らないユーザーも多かったが，厳しい経済状況の中，システム投資に慎重になっているユーザーにとって，RFPを作ることは不可欠になっている。本連載では，筆者が実際に経験したRFP作成・活用の現場の情報を基に，すぐに役立つ実践的な情報を提供していく。 なお，RFPの初歩から知りたいという方は，「RFP＆提案書完全マニュアル」（日経BP社）も併せて読んでみてほしい。 ■趣旨（目的・背景・狙い）」の実践的なまとめ方 趣旨はRFPの「ミッション・ステートメント」 「目的・背景・狙い」とは何か？ 趣旨をつかむための「ネタ」とは？ ケーススタディ：ガソリンスタンド会社の顧客情報システム 趣旨の具体的な書き方の例 ■業務要求とアウトプット RFPの基本構造 RFPにおける業務要求の洗い出しの目的とは
RFP（あーるえふえぴー）
request for proposal / リクエスト・フォー・プロポーザル / 提案依頼書 / 提案要請書 / 入札依頼書 企業が情報システムやITサービスなどを調達する際に、発注先となるITベンダに具体的なシステム提案を行うよう要求すること、またはその調達要件などを取りまとめたシステム仕様書を指す。日本語では「提案依頼（書）」「提案要請（書）」「提案要求（書）」「提案要望（書）」「提案募集（書）」「入札依頼（書）」「見積依頼（書）」「提案書提出要請（書）」など、さまざまな訳が使われる。 ITベンダ側はRFPに基づいて大まかなシステム設計を行って提案書を作成し、ユーザー企業に提出する。ユーザー企業はその提案書を評価して、調達先の決定や契約の締結などを行うことになる。 RFPには決まった書式はないが、システムの「概要と目的」「必要な機能」「求められるシステム条件」「サービスレベル」「予算
データベース設計はいつ、何をポイントに行うか
データベース設計はいつ、何をポイントに行うか：ゼロからのデータモデリング入門（4）（1/3 ページ） 前回までは、データベース設計の歴史的背景からデータベース設計の有効性までを解説しました。今回は、システム開発ライフサイクルと照らし合わせ、それぞれのフェイズで必要となるデータベース設計について、お話をします。 どの段階でどう設計すればいいのか 前回、データベース設計は自社のビジネス活動を理解している自社内の人間がやるべきであり、情報システム部門の存在意義を高めるために必要な技法であるとお伝えしました。しかし、システムの外部委託が多いというのもまた事実です。 筆者の職場では、お客様からデータモデリングに関するご相談をいただく際、最初に「貴社のデータモデルを拝見させてください」というお願いをします。システム開発を外部委託しているケースでは多くの場合、形として残っているのは「物理データモデル」で
バッチ処理を再考する - 急がば回れ、選ぶなら近道
最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、本人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと？なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
