若手PM必読！プロジェクト失敗４大パターンと失敗を防ぐ方法｜プロジェクト管理・工数管理「クラウドログ」
プロジェクトマネージャープロジェクト管理編集部おすすめ 公開日 2017/06/12最終更新日 2017/06/12 若手PM必読！プロジェクト失敗４大パターンと失敗を防ぐ方法 Share システム開発のプロジェクトを管理するプロジェクトマネージャー。プロジェクトが成功するかどうかは、プロジェクトマネージャーの腕に掛かっていると言っても過言ではありません。 プロジェクトが始まったものの、 要件がいつまでたっても固まらない 指示通りにメンバーが動いてくれない プロジェクトメンバー間のコミュニケーションがぎくしゃくしている どんどん進捗が遅れていく などの問題が発生したことがありませんか？ システム開発を成功に導く為には、緻密なプロジェクト計画と進捗管理、課題管理、プロジェクトメンバーへの適切な指示など多くのプロジェクト管理スキルが求められます。 プロジェクト管理スキルは１冊の本になるほどボリ
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
炎上プロジェクトはどうして復活できるのか―伝説のプロマネが会社を救う
数年前のある日のこと、重要顧客の最高情報責任者（CIO）から呼び出しを受けました。深刻な顔で打ち明けられたのはこんな相談でした。 「実はかなり困った案件がある。A社にお願いしている新規ビジネスのためのシステム開発プロジェクトだ。難航している。昨年リリースの予定だったが1年延期した。そろそろも延長した1年も過ぎるが未だにリリースのめどすら立ってない」 それは大変です。CIOによるとこのシステム開発の当初予算は30億円。1年半かけて導入/稼働の計画だったとか。しかし計画を1年遅らせてもまだ総合テストすら始まってない状態でした。 予算とスケジュールから要員計画はおおむね想像できます。ピーク時で月間2億～3億円、人員に直すと200～300名体制で開発/導入する計画だったはずです。12カ月の開発延長期間はピーク時の半分の人員で進めたとしてもざっと10億円が投入されたはずです。少なくとも当初予算の30
要件定義で必須の思考法、どうしたら身に付くか
システム開発プロジェクトでユーザーから要望を聞くとき、その目的を確認したうえで、それを実現するためのより良い解決策を考える。要件定義を担当するSEは、この思考法を習慣化すべきだ――。 2015年4月20日の本欄「ユーザーに遠慮するSEはバカになる」で、このことを指摘した。 上記の記事ではあえて上から目線で書いたが、ユーザーからの要望の目的を確認し、より良い解決策を考えるのは容易でない。このことを、記者は経験的に知っている。かつてシステムインテグレータの社内研修に参加させてもらい、要求分析の基礎トレーニングを受けた際、懇意にしていた講師から「（要件定義の記事を書いているので）もうちょっとできると思っていましたが…」と渋面を作られた経験がある。 要件定義の思考法は、手順を理解したつもりでも、実際にやると難しい。しかも、緻密な思考が求められ、かなり面倒だ。これをただちに習慣化せよというのは、いさ
イミュータブルデータモデル(入門編)
6. Step1 エンティティの抽出 発送担当者が受注リストをもとに、商品の在庫を確認し、在庫が あれば商品を発送する。 ① 要求仕様の「動詞」を抜き出しエンティティとする。 ② ①に関わる「名詞」を抜き出しエンティティとする。 ③ エンティティ間の関連に線を引く ④ 属性や候補キーも分かる範囲で書いておきます。 間違い！ この段階で実装をプロパティファイルにするとか、Enum にするとか決め打ちでエンティティとして表さないのはや めましょう。 まず、はじめにエンティティを抽出します。
多い日も安心設計 - Qiita
アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ
システムの引き継ぎをうまくやるために僕が思った４つのこと - 小さい頃はエラ呼吸
はじめに 先日とあるシステムの引き継ぎ作業が完了しました。ぼくの会社が引き継がれる側で、今までそのシステムを担当していた別の会社が引き継ぐ側になります。 ぼくは、引き継ぎ作業の発注から引き継ぎの実施、引き継ぎ資料のレビューまで、すべて担当しました。その中で引き継がれる側として、いくつか感じたことを書いてみたいと思います。 人生は「聞く力」で9割変わる (経済界新書 25)posted with amazlet at 13.03.09福田 健 経済界 売り上げランキング: 145,011 Amazon.co.jpで詳細を見る １．引き継ぐ側のモチベーションは低いと認識する はっきり言って、引き継ぐ側のモチベーションは低いです。もう終わりだからと思っているのかわかりませんが、ものづくりをしていた時期のモチベーションとは、あきらかに違うと思っていたほうが良いです。 たとえば、こちらから相手の担当
納期・コストを削減する“開発案件3分割”の術
開発案件に含まれる業務処理機能を精査して、カットオーバー日までに必要な機能とそうでないものを分けたうえで、開発作業に優先順位を付けてみよう。たとえ厳しいスケジュールでも、要求をクリアするための確かな抜け道が見えてくる 第4回『“設計思想書”で開発の効率と質を高めよう』では、開発の作業効率を高める方法として、システム設計の目的や要点をまとめた“設計思想書”を用意し、過去の開発資産を積極的に再利用する方法を紹介しました。 これは「日常的に行っている多数の開発案件の“基本部分を共通化”することで、あらゆる開発案件の作業を迅速化する」という考え方によるものです。しかし、開発案件はさまざまです。この考え方だけでは対応できないケースも出てきます。今回は、個々のシステム開発作業を迅速化する、別のアプローチを紹介しましょう。 顧客の求める開発期間をうのみにしない まず事例を通して考えてみましょう。第1回『
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
生き残るために「要求エンジニアリング」を学ぶ
生き残るために「要求エンジニアリング」を学ぶ：上を目指すエンジニアのための要求エンジニアリング入門（1）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 2009年、世界経済にとって厳しい年を迎えた。IT／ソフトウェア業界においても、ほかの業界と同じく厳しい時代になるだろう。この業界ではコストの大半を固定費である人件費が占めており、経済環境の変化に対応する力が弱い。だから、経済環境がいっそう厳しくなれば、プロジェクト価格の低下はもちろん、プロジェクト件数も減少し、ベンダ間の競争が激化する。企業は利益を出すために――いや、企業を存続させるために、多かれ少なかれ人件費の削減、時間単価の切り下げや時間当た
ソフトウェア開発組織が持つべきカルチャー（まとめ）: 柴田 芳樹 (Yoshiki Shibata)
2011年に主に書いた「ソフトウェア開発組織が持つべきカルチャー」を表にしてみました。評価列は、みなさんの組織ではどうかを振り返って記入してみてください。 ソフトウェア開発組織が持つカルチャーが、個々のソフトウェアエンジニアに大きな影響を与えるということで、一連の記事を書きますとした「まえがき」に相当するのが次の記事です。
内田樹の研究室: うなぎくん、小説を救う
2024 1月 - janvier 2月 - février 3月 - mars 4月 - avril 5月 - mai 6月 - juin 7月 - juillet 8月 - août 2023 1月 - janvier 2月 - février 3月 - mars 4月 - avril 5月 - mai 6月 - juin 7月 - juillet 8月 - août 9月 - septembre 10月 - octobre 11月 - novembre 12月 - décembre 2022 1月 - janvier 2月 - février 3月 - mars 4月 - avril 5月 - mai 6月 - juin 7月 - juillet 8月 - août 9月 - septembre 10月 - octobre 11月 - novembre 12月 - décembre
○○したら受託開発が180°変わった(10分版)
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
大規模スクラムの失敗から学んだこと #AgileJapan2015
「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ 2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。
ITプロジェクト戦略
私が日頃目にするITプロジェクト管理関連の書物はソフトウェア開発方法論や開発ツールに偏重していると感じています。また、方法論や開発ツールを導入すればプロジェクトの生産性が向上し、成功すると思い込んでいる経営者がいるようにも思います。方法論や開発ツールの重要性に疑義を差し挟む余地は些かもないのですが、プロジェクトの成功にはこうした方法論や開発ツールに加えて戦略が必要です。 また、上記の書物の多くは単独のプロジェクトに的を絞った議論になっています。プロジェクト管理を成功させるには、当該プロジェクトを含む組織がどう行動するかを考える必要があります。複数のプロジェクトが同時並行的に遂行されている組織（企業、システムプロバイダー）にとって、組織全体の利益（短期のみならず、中長期的利益）が得られなければ成功とは言えません。一つのプロジェクトの失敗が組織の生き残りを危うくすることがあり、逆に経営判断のミ
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
プロジェクトとプロジェクトマネジメントの基本
2. Disclaimer ● プロジェクトメンバー/プロジェクトマネージャの初心者向け資料です ● ハートビーツ社内勉強会向けに作りましたが公開できそうなので公開しちゃいま す ● ばば個人が知ってること、意識していることを書きました ○ 個人の見解です ○ プロジェクトマネジメントについてのインプットは実務+大学院での授業いく つか ○ 担当領域予算数百万円、工期〜1年程度の小規模プロジェクトを主に扱っ ています 4. プロジェクトとは 「独自の成果物、またはサービスを創出するための 期限のある活動」 (Project Management Institute定義) ・・・噛み砕くと ● 明確に定義された目標がある ○ 明確に＝計測・判定可能 ● 明確に定義された予算がある ○ (確保されるという意味ではなく定義されるという意味合い) ● 明確に定義された期限がある ○ 期限を決めずや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今どきのやり方でWebサービスを作ろう
ソースコードを書かないことが武器になる～あらゆる情報がクラウド化される時代の歩き方【連載:えふしん】 - エンジニアtype
八柱曼荼羅ツールの使い方