［作業指示、進ちょく管理編］気付いたときにはもう遅い、手戻り・遅延は起こさない
今回は、「バッファー込みで作業をさせてはいけない」「報告を待ってはいけない」など、「作業指示」と「進ちょく管理」という2つの場面における、7種類の禁じ手を解説しよう。 作業指示：バッファー込みで作業をさせてはいけない PMはスケジュールを見積もるとき、問題が起こった場合などに備えて、作業や工程ごとに遅延を見込んだ「バッファー」を確保しておく。そしてそのスケジュールをユーザーと合意した上で、プロジェクトを進めていくことになる。 このときPMがやりがちなのは、バッファー込みのスケジュールを、バッファーが含まれていることを伝えないままチームリーダーやメンバーに示して、作業指示をしてしまうことだ。みずほ情報総研の百井氏は「PMが忙しいときは特に、ユーザーに見せたスケジュール表を、そのまま示しがちだ」という。 しかし、バッファー込みのスケジュールで、リーダーやメンバーに作業をさせてはいけない。「作業
丸投げせず、自力でできる作業を探し出せ
サーバーソフトのバージョンアップ作業は、一般にコスト削減の余地が大きい。ベンダーに作業を丸投げにせず、自力でできる作業をあの手この手で探し出せば、予想外に大きな効果を得られる。今回紹介するアメリカンファミリー生命保険は1億円以上のコスト削減効果を得た。クラレも数千万円以上かかるERP（統合基幹業務システム）ソフトの移行作業を700万円で済ませた。外為どっとコムやエイチアールワンなどの秘策も紹介する。 本業に役立たないバージョンアップ作業は外注する、という企業も多いだろう。だがコストを抑制するためには、外部に委託するだけでなく、できる範囲で移行作業を自力で進めることも一考の余地がありそうだ。 丸投げ回避でコストを3分の2に 移行作業をできるだけ自力で進めるやり方によって、アメリカンファミリー生命保険（アフラック）は、日本オラクル製ERPパッケージ「Oracle E-Business Suit
「上流」が上流とは限らない
情報システムの開発プロセスは、「上流工程」「下流工程」に分けてとらえることが多い。通常は、計画から要求（要件）分析、基本設計までの工程を「上流」、詳細設計から実装（プログラミング）、テストまでを「下流」と位置づける。IT業界に長くいる方なら「上流CASE」「下流CASE」といった言葉をご存じだろう。 開発プロセスを「上流」「下流」と分けることに異議を唱える声は以前からあった。そもそもこの区別はウォータフォール型の開発プロセスに基づくもので、繰り返し型の開発にはなじみにくい部分が多い。特に分析・設計から実装・テストまでを2週間あるいは1カ月といった短い期間で繰り返しつつ、ソフトウエアを成長させていくアジャイル開発では、上流・下流と呼ぶことにほとんど意味はない。 何よりこの分け方や呼び方は、特に「下流」に属する人たちや組織・会社にとって、好ましいものではない。上流というと、実態はともかくとして
「プロジェクトの失敗につながる九つの要因に注意」、NTTデータの岩本副社長
「予算オーバーや納期遅れ、品質低下といった失敗プロジェクトをIT企業の視点で調べると、九つの共通点が見つかった。九つのうち三つを満たす案件については、特に注意が必要だ」。NTTデータの岩本敏男副社長パブリック＆フィナンシャルカンパニー長は2010年1月15日、プロジェクトマネジメント（PM）の国際標準化について議論する「PM国際標準化フォーラム」に登壇し、こう述べた（写真）。 岩本副社長が挙げた九つの要因とは、次のものである。一つ目は、対象プロジェクトが新規顧客からの受注であること。二つ目は、新システムの要件が「現行どおり」とされていること。三つ目は、新技術や経験のない処理方式を採用していること。四つ目は、IT企業と顧客との間で一括請負契約を結んでいること。 五つ目は、IT企業のプロジェクト原価率が95％以上であること。六つ目は、開発期間が6カ月以内といった短期プロジェクトであること。七つ
あなたの説明責任(Accountability)がなんぼのもんじゃ - masayang's diary
相変わらずのマイクロマネージメントな現場だらけで心が荒む日本出張。 が、よく見るとマイクロマネージメントには二種類あることがわかる。 「管理される側が力量不足なので、管理する側は細々と面倒みないといかん」 「管理する側の説明責任を取り繕うために、管理される側に対して細々指示を飛ばす」 今回問題にしたいのは、後者。 「私には説明責任がある。だから○○と△△と××しろ。」と部下に細々指示を出すのは簡単である。 だが、その説明責任とやらを遂行できない場合にどれくらいの損失が発生するというのだろう？ 降格・減給といった、認識可能な損失？ それとも、「こら！」と誰かに怒られるだけ？ あるいはプロジェクトがお取り潰しになる？ 説明責任を果たせない代償は様々だろう。 でも、その「代償」は「チーム全体の生産性」「部下のやる気」あるいは「部下が将来役立つ技術を学ぶための機会」を奪ってでも回避したいものなの？
［IT業界の弱者］開発者に代わってユーザーに陳謝
「いったん開発が終わってしまえば，後はすべて運用担当者の仕事」。そのように考えている開発担当者はいないだろうか。もし設計や開発で不備があれば，そうしたシステムを使わされるユーザーは不満を感じる。その不満は開発担当者がもたらしたものと言えるが，ユーザーから文句を言われるのはいつも運用担当者である。 大手製造業の情報システム部員である細川仁さん（仮名）は，運用チームに所属し，ヘルプデスクの責任者を務める。運用チームは設計にも開発にもかかわらないが，「ユーザーの声に耳を傾けてシステムの改善を提案する。それがヘルプデスク担当者の役割」と，この仕事に誇りを持つ。 そんな細川さんにとって忘れられないシステムがある。そのシステムの稼働直後は，ユーザーからの問い合わせは少なく静かな滑り出しだったが，稼働から3カ月を迎えると事態は急変。ヘルプデスクへの問い合わせが激増した。しかも，問い合わせ内容はほぼすべて
6000人が作ったシステムは見事に動き、それを報じた3人の仕事は遅れた
「Day2を見習い、締め切り厳守でいく」。記者2人にこう指示し、「Day2特集作成プロジェクト」を開始した。Day2は三菱東京UFJ銀行が先頃終えた開発プロジェクトの通称で、6000人の技術者が参加した。世界最大と言われた開発を納期と予算通りに終えた同行にあやかり、その顛末を報じる我々3人も納期を守ろうとした。しかし、現実は厳しかった。 厳しかった現実を以下に紹介する。その前にお断りしておくが、今回の原稿は「記者の眼」ではなく、正確には「編集長の眼」である。この原稿を書いている筆者が、記者ではなく、日経コンピュータの編集長だからだ。何らかの知見を披露するわけではまったくないので、もっと正確に書けば「記者のつぶやき」ならぬ「編集長のつぶやき」というべき内容になっている。 ITproの「記者の眼」欄の原稿はITpro編集部に加え、各雑誌の編集部が交代で執筆を受け持っている。この2月、ITpro
「現状のソフトウェア開発は間違っていないか？」（プロセス編）
失敗例その1 「要件定義が終わらない」 ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基本設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに１カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。 失敗例その2 「設計工程の無駄」 オープン系の開発でウォーターフォール開発を行っている。設計工程は、基本設計、詳細設計に分かれている。基本設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるた
第23回 システム開発の“丸投げ”が命取りに
現行システムの維持・保守業務に加えて，新たなシステム開発案件に追われている情報システム部は多い。むしろほとんどの情報システム部は，途切れることのない開発案件の消化に明け暮れている。忙しさに加えて，リストラや慢性的な要員不足が理由で，開発案件のほとんどを外部企業にアウトソーシングするケースも増えている。外注化は有効な選択肢の一つだが，“丸投げ”になってしまっては，情報システムのみならず，企業の存亡にかかわりかねない。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 空調機器製造販売会社のB社では，全国の支店網をこれまで以上に地域密着型にして，ビジネスの活性化と同時に独立採算を徹底することになった。この方針の実施に合わせて新しい業務処理に適した販売管
「納期に間に合わない！」の根本原因を探る － ＠IT自分戦略研究所
ソフトウェアを創造するエンジニア。しかし、その仕事は本当に「創造的」だろうか。仕事を創造的なものに変え、価値を生むための発想法を紹介する。 前回、自分の中に宝物が眠っていることを知った。どうすれば自分の宝物を掘り当てることができるだろうか。宝物探しの出発点は、身の回りに散在している問題を考えることだ。身近な問題を解決することができれば、その効果を直接獲得できるばかりでなく、解決策形成の体験を通じて、将来発生するであろう問題を解決するための応用力も獲得できる。 自分にとって身近な問題、自分のプロジェクトや自社が抱えている問題、あるいは自分のお客さまが抱えている問題に取り組むことから始めるといい。そして、問題解決のアイデアや提案を生み出し、自分だけでなく、プロジェクトチームにも、会社にも、そしてお客さまにも喜んでもらおう。 ■解決すべき問題をはっきりつかむ 前回挙げた、「身近な問題の例」を再掲
今だから出来る業務システムを
先日、とある業務システムの事例が発表されていました。最先端を好むエンジニアに評判の良い最新技術を採用しての開発ということで大きく注目を集めたようです。その事例記事自体は普通の紹介記事なので、そこからあれこれと邪推するのもどうかと思うのですがいくつか気になるところがあり、それが日本の業務システムの問題の一部を体現している気がするので、ちょっと気になるところを書き連ねてみます。 その記事には画面のスクリーンショットが掲載されていました。見た瞬間に「未だに？」と感じてしまいました。どういうことかというと、画面の一番上がラジオボタンになっており、 ◎追加 ○更新 ○削除 と、まずは今から行う操作の種別を入力するようになっているのです。 これは「伝票入力する」という業務がそのまま残っているということになります。どういうことかというと、昔々というのはコンピュータが非常に高価な時代でした。そこでまずは入
第1回 20年は遅れているITプロマネ | 日経 xTECH（クロステック）
近年，システム開発のプロジェクトマネジメントについての関心が高まっており，プロジェクトマネジメントに関する資格を取る人も増えています。しかし，そのために「システム開発の失敗事例が減ってきた」という話はあまり聞きません。 システム開発プロジェクトは，建築やプラント建設，船や工作物などの機械組み立てのプロジェクトと比べて，失敗事例があまりにも多く，納期どおりに完成する例は多くありません。実際，日本情報システム・ユーザー協会（JUAS）の「ユーザ企業IT動向調査 2006」でも，500人月以上の大規模プロジェクトでは相変わらず5割近くで工期遅れ，4割近くで予算超過が発生しています。スケジュールが遅れ，その結果としてコストが増加することが当然と受け取られています(図1）。 図1●プロジェクトは基本的に成功するもの プロジェクトは，プロジェクト・マネジャーがしっかりと顧客とメンバーを把握して，品質（
第5回 開発コストにムダが多いIT業界，解決策は「分離発注」と「分割発注」
第4回では，システム開発プロジェクトで起こりがちなコスト膨張のからくりについて，主にベンダー側の視点から説明しました。 ではユーザー企業は，ベンダーに任せっきりにして，膨れ上がるコストを眺めているだけでよいのでしょうか？あるいは，「絶対に追加費用は一銭も認めないぞ」とベンダーと強硬に交渉して，予算内で吸収するように持っていけばよいのでしょうか？ 今回は，ユーザー企業がプロジェクトを円滑に進め，なおかつコストを最低限に持っていける方法について解説しましょう。 随意契約では，開発コストが高くなる 第1回にも述べたように，システム開発プロジェクトはほとんどの場合，プラント建設で言うところの“改造プロジェクト”に相当します。 “改造プロジェクト”では，ユーザー企業の内部事情を知っている特定のベンダー（既存システムの開発を担当したベンダー）が，仕様を確認するうえでは非常に有利になります。しかし，内部
手戻りできない短期決戦 ＳＥを使い倒して競合に勝つ
サーバーや通信ネットワークの再構築案件。難題はオフィス移転までの6カ月以内に完了させること。入社2年目の女性営業担当者が周囲を巻き込んで、初の大型商談の獲得に奔走する。 「こんなに大きい商談を経験したことがない。大丈夫だろうか」。リコーテクノシステムズ（以下、リコーテクノ）の首都圏支社ITサービス販売事業部IT サービス第2営業部営業1グループに所属する立神由紀子は、懸命に不安と闘っていた。入社2年目（当時）の若手営業担当者である立神は、責任の重さに押しつぶされそうだった。 「私が“2年生”であることは、ユーザー側には隠しておいてください」。営業担当者が若手かベテランかどうかなど、ユーザー企業には関係ない。提案の内容で勝負が決まる。そう信じる立神はコンペが本格化する前に、直属の上司である営業1グループリーダーの渡邊克巳に進言した。「営業経験が浅いことを先に伝えてしまうと、ユーザー企業から頼
Java400万行の大規模再構築，1年3カ月遅れるも全面稼働 | 日経 xTECH（クロステック）
輸出入リスクに対する保険を提供する日本貿易保険は2007年4月、メインフレーム上で稼働していた保険業務システムの再構築を完遂した。設計、開発は日本IBMが担当。その開発規模はJavaで400万行に上る。仕様漏れによるやり直しから、当初計画より稼働が1年3カ月遅れた。 「『来月にはプロジェクトの遅れを取り戻せる』と先月言っていたが状況は変わっていない。いったいどうなっているんですか」。 ベンダーの経営層が集まるプロジェクト進捗会議の席上、日本貿易保険（NEXI）の情報システム担当理事である大林直樹氏は、保険業務システムの遅れについて日本IBMの役員に問いただした。約2年で完了予定のプロジェクトが、残り半年にきたところで遅れが拡大していた。それとともに、大林理事の不安は膨らんでいった―。 結果的にその不安は現実のものとなる。稼働開始が1年3カ月遅れ、ユーザー、ベンダー合わせて数十億円とみられる
告白 - 宇宙行きたい
俗に言う「ウォーターフォール」な開発には欠点がいっぱいあることが各所で言及されてる。 大きいイテレーションをまわしての開発には予定外の事に対処しにくいので 小さいイテレーションを短い期間でまわしながら少しづつ軌道修正もふくめ柔軟に対処していったほうが 成功する確立が高いのはいうまでもない。 その最小単位とも言えるのが単体テストで、まずは単体テストを通すことからはじめる。 いきなり大きな目標を見ないで、小さいことから少しづつ成功させていくんだ。 「結婚を前提につきあってくれ」なんて耳障りはよくきこえるかもしれないけど、 君にあわせて少しづつ軌道修正するつもりなんか全く無い人間の台詞だ。 僕は君との出会いを大切にしたい。失敗したくないんだ。 だから小さいイテレーションを回すことに全力をつくそうと思う。 というわけで電話番号おしえて♪ - という告白はどうか? らんぐじゃ
「今からエベレスト上れ。期間は１か月」 - 岡村日記
大規模システム開発について、最近思うことを寓話として。 「今からエベレスト上れ。期間は１か月」 上司からそういう指令を受けてあなたは今、ボンベイの港に降り立った。 （現実にはありえないだろうけど）エベレストが遥か彼方遠くに見えているものとする。 「おまえがパイオニアだ。道は自分で切り開け」 そんなふうに激励されて、日本を出発してきた。 山は遠くに見えている。 しかし、そこまでどう行ったらいいのかわからない。 だけど「１か月あるしな」何とかなると思う。 なんか交通機関を利用したらいいだろうと考えるが、窓口で言葉が通じない。 とりあえず切符は買ったものの、日本と違って列車が時刻通りに発車しない。苛立つ。 切符を買い間違えたのか、なんか予想と違う方向に向かっている。ような気がする。 車掌を捕まえて話そうとするが、やはり意思の疎通がとんちんかんになる。 こんなことを考え出す。 「これなら歩いた方が
1年遅れたパッケージ導入 初期の意思疎通ミスが響く
1. 基幹システムを統合業務パッケージで再構築し，運用コストの1億円強削減を見込む。 2. プロジェクト初期のミスが尾を引き，本稼働をのべ1年間延期した。 3. 新プロマネの投入でコミュニケーションを回復し，チームがまとまった。 「これでバージョン・ゼロがようやく完成した」――。東急建設 経営企画室 システムグループ リーダーの木吉博志氏は，2004年9月の中間決算を処理し終えた新システムをそう評価した。NECの建設業向け統合業務パッケージ・ソフト「C-BARX」をカスタマイズした新基幹システムの稼働後，利用者の混乱や細かいトラブルも収束し，本来の導入目的である新しい会計基準に沿った決算を達成できた。 だが，ここまでの道のりは平坦でなかった（図1）。システム構築を請け負うNECと東急建設との間で，業務用語の不統一によりパッケージ・ソフトのカスタマイズの内容について意見が相違したり，2カ月間
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
