本当は楽しいドキュメント作成
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 文書作りは好きですか？ 今回からこの連載を担当いたします、アクセンチュア・テクノロジー・ソリューションズの宮本和洋です。 システム開発プロジェクトでは、さまざまな文書が作られます。私の連載ではこの文書に注目し、「文書ドリブン開発」という考え方を紹介したいと思います。 文書ドリブン開発は私の造語です。「文書が作成されることにより、具体的な開発作業が進行していく」ことを意図しています。 多くのITエンジニアは、文書作りではなく、動くものを作ることに楽しさを見いだすと思います。その作業の楽しさの中には、システムの設計に悩み、動作実証実験を繰り返す楽しさも含まれているのではないでしょうか。「この仕組みでちゃんと動くかな～、どうかな～」と試してみることが、ワク
発想を引き出すチャート
問題解決のような何らかの意思決定をする思考過程では通常，「発散（拡散）」と「収束（集中）」という二つのプロセスを繰り返す。 発散のプロセスを簡単に言うと，改善すべき現状の問題，その原因，解決策などについて，自由な発想で幅広くアイデアを出すというものである。その際，アイデアを出すのに論理性に縛られる必要はない。思いつきでポンポン言うことが許されるし，実現不可能なアイデアも歓迎される。別のアイデアを思いつくのに役立つからである。 一方，収束のプロセスは，出てきたアイデアを組み合わせ，すり合わせてうまく機能するようにきっちりハメ込むという段階である。きっちりハメ込むことを要求されるため，厳密な論理性が要求される。 前述したフローチャートとIDEF0はどちらも主に収束のプロセスで使う。ITエンジニアは収束のプロセスが得意で熱心に行うが，発散のプロセスは不十分なことが多い。そこで発散のプロセスを強化
IT企業を襲う「優秀なプロマネ不足」の打開策
IT企業の人事担当者に読んでほしい、人事制度導入ノウハウ。導入プロジェクト開始の準備から設計、導入、実際の運用まで、ステップごとに詳細に解説する。 この連載では、IT企業の人事担当者、人事制度に興味を持つ人に向けて、制度導入のノウハウをお伝えします。準備、現状分析、設計、導入などのステップごとにその手法を解説し、気を付けるべき点を紹介します。 現在、IT企業で起こっている問題 人事制度導入の検討を始める前に、現在IT企業で起こっている「人」の問題について考えてみましょう。 ここでは、「組織レベルで起きている問題」「個人レベルで起きている問題」という観点で整理します。 組織レベルの問題 現在、IT企業に組織レベルで起こっている問題として、以下の3つが挙げられます。 （1）人材育成が後回しにされるプロジェクトチーム中心のマネジメント 通常、システム開発は、案件ごとにプロジェクトチームを組んで行
提案書作成支援ツール
マーケティング・マーチャンダイジング・マネジメント HOME 情報システム提案書作成支援ツール Downloadコーナー 下線のついたファイルをクリックするとPDFがダウンロードできます。 Adobe Acrobat Readerが必要です。 必要に応じて左下＜Get Acrobat Reader＞をクリックして、インストールをして下さい。 提案型セールスの質を強化し、営業生産性を強化するためのツール ＜サンプルファイルが閲覧できます。＞ このCD 1枚で ワンランク上の提案活動の展開が可能となります。 左記のCDをクリックすると、CDの詳細ページへ
提案書作成支援ツール
【改訂版】 提案型セールスの質を強化し、営業生産性を強化するためのツール ＜サンプルファイルが閲覧できます。＞ このCD 1枚で ワンランク上の提案活動の展開が可能となります。 左記のCDをクリックすると、CDの詳細ページへ
進ちょく管理で実践したいプラクティス
今回は、PMBOKとCMMIという既存の体系が、どのように進ちょく管理をとらえているかを紹介し、工事進行基準が当たり前となるこれからのプロジェクト管理の参考にしたい。 既存の知識から学べることがある 本連載第1回の「工事進行基準が進ちょく管理に変化をもたらす」では、工事進行基準の採用が、ソフトウェア開発プロジェクトの進ちょく管理現場にどのような変化をもたらすことになるかという点を中心に説明しました。 具体的な対応方法は、プロジェクトまたは企業それぞれで異なるはずですが、いざ自分が対応する場合に備え、現場のプロジェクトマネージャが今後の進ちょく管理でどのような点を重視すべきかという点について、ご理解いただけたのではないかと思います。 今回は、プロジェクトマネジメントや開発プロセスの代表的な知識体系であるPMBOK、CMMIでは、進ちょく管理に関して、どのように考えられているかを紹介していきた
リーダーへの4つの問い
成功の条件と失敗の背景 「第1回：リーダーシップなくして生産はなされない」で、ドラッカーの説く経営理論の全体像を説明しながら、プロジェクトマネジャーの方も「経営」「マネジメント」についての理解を深めるべき時代がきたと書いた。 今回は、「経営」「マネジメント」とは何か、成功するための条件とは何か、また失敗する背景には何があるのか。これらについてのドラッカーの考え方を説明する。 マネジメントとリーダーシップについての「誤解」 「マネジメント」や「リーダーシップ」は、よく使われる言葉だが、それぞれの言葉の定義を聞かれて、正確に答えられる人は少ない。「マネジメントとは何か？」と問うと、「組織を管理すること」あるいは「目標に向かって人的リソースを最適化すること」といった回答が多い。 おそらく、「組織体が何らかの正当な目的に向かって、順調に活動している」状態を「マネジメントの成功している姿」としてイメ
［姿勢編］自己研鑽を怠ってはならない
自己研鑽については，社会人なら誰しも意識しているところだろう。プロジェクト・マネージャ（PM）にとっても当然のことである。IT技術者になりたてのころは基本情報処理試験など資格取得に向けた自己研鑽に始まり，仕事の合間を見つけては努力した人も少なくない。しかし，年次を重ねるにつれ，段々と自分の時間を作ることが困難になってくる。特に結婚したり社内での職制が上がり職責権限が増えたりすると，どうしても自己研鑽に割く時間が減ってしまうと感じる技術者も少なくないだろう。筆者はあえて言いたい。そのような状況であったとしても，PMたるもの，常に自己研鑽を続けるべきである。 筆者の失敗例 筆者が初めてPMをやったときの話である。そのプロジェクトには入社2年目の社員Y君が配属されてきた。筆者よりも3年後輩の社員であった。そのころの筆者は仕事にも慣れ，上司からも認められる存在であると自負していた。要するにてんぐに
赤字プロジェクトは減少傾向だが，本当の試練はこれから
システム開発において，赤字プロジェクトの解消は昔から大きな課題である。その点において，ここ数年のシステム・インテグレーション市場は“金融特需”に沸き，大手ベンダーは「赤字プロジェクトを大幅に圧縮した」として好決算を連発してきた。だが今，サブプライムローン問題が引き金となって世界的な景気後退が起こりつつあり，予断を許さない。 そんな景気の転換点にあって，システム開発における赤字プロジェクトの現状と今後の見通しを探るべく，ITproは「赤字プロジェクトに関する調査」を実施した。調査期間は2008年9月25日～10月2日。863人から回答を得た。 プロジェクトの半数近くが「赤字」か「赤字スレスレ」の綱渡り まず，現時点におけるシステム開発プロジェクトの収支状況を見てみよう（図1）。最も多い回答は，「赤字ではないが，利益も出ていない」（30.1％）だった。厳しい環境の中で，プロジェクトのおよそ3分
リーダーシップなくして生産はなされない
なぜ、今「ドラッカー」なのか ピーター・フェルディナンド・ドラッカーをご存じだろうか。一般的には「経営学の父」「マネジメントを発明した人」として知られている。ベニントン大学、ニューヨーク大学教授を経て、2003年までカリフォルニア州クレアモント大学院教授を歴任した。2005年に95歳で亡くなるまで、大学教授だけでなく、コンサルタント、著述家としても幅広く活動し、世界中の経営者や組織リーダーに影響を与えた。 米国ではGEやP&Gといった一流企業に加え、最近ではGoogle社の組織デザインにおいても多大な影響を与えていると言う。日本でも、セブン＆アイ・ホールディングスの伊藤雅俊名誉会長、松下電器産業の中村邦夫会長、富士ゼロックス相談役最高顧問の小林陽太郎氏、さらに起業家として成功をおさめたファーストリテイリングの柳井正会長兼CEO、リクルート創業者の江副浩正氏なども、ドラッカーの考え方に学び、
世界最大のプロジェクトをこう見積もった
大規模，複雑，厳しい納期――。昨年秋に完全統合したJAL/JASの情報システム。成功を収めたプロジェクトの裏に，見積もり精度の高さがあった。プロジェクト・マネージャ（PM）を務めた岡村正司氏に，どのように見積もったのかを聞いた。（聞き手は本誌 池上俊也） JAL/JAS統合とはどんなプロジェクトだったんでしょうか。 岡村：昨年10月に完全統合しましたが，日本航空（JAL）と日本エアシステム（JAS）の約160のシステムを，JAL側のシステムに片寄せするものでした。工数は全体で1万2000人月，規模は8000万ステップと，とんでもなくデカいものです。IBMが手掛けてきた案件の中でも世界最大級でした。 時間の制約も厳しい。2002年初頭に始まったプロジェクトは，2年間で中核部分をすべて統合しなければならない。失敗は許されませんでした。 岡村さんがPMとして招かれたときの様子を聞かせてください。
5分で絶対に分かるプロジェクト管理 ― ＠IT情報マネジメント
プロジェクト管理ってよく聞くけれど…… ソフトウェアの開発は、よく家を建てることにたとえられます。家を建てる場合、顧客の要望を聞いて設計などが終わった段階から、施工のスケジュールを立て、さまざまな関係者が予定に沿って作業を進めていきます。作業が予定どおりに進んでいるかを施工業者がチェックしたり、作業の途中で建築士が品質をチェックしたりしながら、家の完成まで工事全体を管理します。その管理をせずに家がちゃんと建つ保証はありません。 ソフトウェアを開発する場合も、顧客の要望を聞いて設計をした後に開発やテストの作業があり、その作業をさまざまな関係者が予定に沿って進めます。途中で作業が予定どおりに進んでいるかをチェックしたり、品質をチェックしたりしながら、完成までプロジェクト全体を管理する必要があります。 家を建てることは、何千年も前から行われてきているため、どうしたらうまくいくのか、何を管理してお
偽装請負から身を守るための法律知識
ITエンジニアだろうがなかろうが、論理的な思考はビジネスパーソン共通のスキルである。では、それをすぐに学習する方法は何か？ そう、記事を読むことだ。そんな記事を紹介しよう。記事を読み、論理思考を身に付けよう。 フリーとして活躍するITエンジニアにとって、法律の知識は必須であるといえるだろう。本記事では、＠IT自分戦略研究所主催のカンファレンス「フリーエンジニアのための法律入門講座」でのセッションから、特に「偽装請負」に関する法的知識をまとめた。 セッションの担当は、クレア法律事務所所属の弁護士 佐藤未央氏。佐藤氏は元ITエンジニアであるため現場の状況に明るく（参考記事：「ITエンジニア経験を生かし法律のプロに！」）、ITエンジニアを取り巻く社会環境にも関心が高い人物だ。これからの社会をつくっていくITエンジニアが、どのような視点を持って業務に臨むべきかを、法律の観点から語ってくれた。 偽装
開発着手が突然延期、客の“わがまま”をいつまで許すのか
システム開発の着手間際になって、ユーザー都合でプロジェクトが延期。ITベンダーにとっては真っ青な事態だが、不思議なことにこのトラブルだけはユーザー企業はどうもお気楽。というか、トラブルとの認識すらない人もいたりする。少し前に会ったシステム部長も「仕方ないよ」と平然と言っていた。IT投資の凍結話がちらほら聞こえるようになった今、着手延期のリスクには要注意かもしれない。 開発着手の直前の延期というのは、大型案件なら即、ITベンダーの経営問題だ。多数の技術者をプロジェクトにアサインしたのに、延期になれば簡単に数千万円の売上が吹き飛ぶ。技術者の人件費は固定費だから、技術者が塩漬けになりワークできないとなると、ITベンダーにとってはその分が損害となる。 アサインした技術者をすぐにリリースし、別の案件に参画させられるなら損害は軽微だが、それもまた難しい。いったんリリースしてしまえば、数カ月遅れで開発着
プロマネ最強マニュアル---目次
プロジェクトの記録を残そう プロジェクトを一つ回すと，たくさんの情報が出てくる。それらはすべて現場の資産である。資産を残し，生かす方法を紹介する。 なぜ過ちを繰り返すのか？ 残した記録は“現場の資産” これならできる9ステップ 記録マスターへの道：記録を残す 記録マスターへの道：記録を活用する 記録マスターへの道：運用を回す 東レの挑戦，10年以上続く「情報システム白書」 完了報告書の作り方 プロジェクトの火消し術 システム開発プロジェクトを進めていくと，必ず何らかの問題（火事）が発生する。それに先手を打って「消火」していかなければ，やがて「大火事」に発展してしまうこともある。本特集では，プロジェクトが火を噴いたときの「火消し術」を，現場の工夫と達人の技を基に，徹底解説する。 初期消火が大火事を防ぐ 「俯瞰図」で危機要因を抽出 ［マネジメント編］目標が不明瞭 ［マネジメント編］不適切な計画
3000億円企業のシステム統合 わずか8カ月間でR/3を片寄せ
田辺三菱製薬は2007年10月1日の合併を機に、旧田辺製薬と旧三菱ウェルファーマの基幹システムを統合した。合併の基本合意から、8カ月後の本番稼働という“超”短納期の統合だった。成功の要因は、スケジュール順守の目標を掲げ、基幹系、営業系など4つの主要システムのすべてを、旧会社のいずれかのシステムに片寄せしたこと。そのシステム評価と、事業部門に対する説得に注力した。 「新システムになると、そんなこともできなくなるのか。この前も我慢してくれと言われたが、まだ我慢しなければいけないのか？」。事業部からは容赦ない言葉を浴びせられる。「すみません。すべてを今まで通りにしようとすれば、10月1日にシステムが稼働できなくなるんです」。田辺製薬（当時、現在は田辺三菱製薬）の木之下敦彦情報システム部長はプロジェクトが始まってからというもの、事業部に頭を下げてばかりだった。「システム統合が間に合わなければ顧客に
見積もり、まずはざっくり理解せよ − ＠IT情報マネジメント
最初に、工事進行基準に関して簡単におさらいしておこう。 工事進行基準とは、＠ITのニュースによると「会計基準の変更によって2009年4月にシステムインテグレータ（SIer）など受注ソフトウェア開発業に原則として義務付けられる収益の計上方法。開発期間中にその売り上げと原価（費用）を、工事（ソフトウェア開発、システム開発）の進ちょく度に応じて、分散して計上する仕組み」とあります（「デスマーチがなくなる？ IT業界に義務付け『工事進行基準』ってなんだ」を参照）。 この工事進行基準を適用するためには、「工事収益総額」「工事原価総額」「決算日における進ちょく度」の3つを、信頼性をもって見積もることが必要となります。この3つの条件を工事進行基準適用の3点セットと呼ぶことにしましょう。工事進行基準に関しては、前述の記事のほかに下記の記事を参考にしてください。 この3点セットを見ても分かるように、どれもプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
芦屋広太のプロマネ歌留多---目次
上流工程-見積もり---目次：ITpro
テクノロジー : 日経電子版
