不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
プロジェクト炎上を防ぐ10の法則 - WBS作成の極意 | INIブログ
※インテリジェントネットではWBSを引いたり、WBSに沿って一緒にものづくりをする仲間を募集しています。詳しくは【インテリジェントネット採用情報】をご覧ください。 先日、当社インテリジェントネットにてフリーランスとしてご活躍されているd-threeの大崎さんをお招きして社内勉強会「WBS講座」を開催しました。 ほぼ全員参加だったため、全くWBSやスケジュールをひいたことのない初心者もいれば、日頃から中～大規模サイト構築案件のディレクターとしてWBSをひいてプロジェクトマネジメントをしている中級者（どこまでが中級者でどこからが上級者かわかりませんが）まで幅広いメンバーが参加しました。初心者向けのレポートは新人ディレクターがアップしますので、このエントリでは中級者向けのレポートをアップしたいと思います。 そもそもWBSとは？ 「Work Breakdown Structure」です。ここまでは
WBS は、作業分解構造ではないのよ。 - haradakiro's blog
ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb
“技術だけ”では、開発プロジェクトは失敗する
システム開発は、「人と人との強い結び付き」と、開発に向ける「思いの強さ」「やり抜く姿勢」が成功の大前提となる。 呉医療センターの医療情報システム全面刷新の案件には、複数の競合ベンダが入札していた。当初は劣勢だったが、最終的に落札できたのは、プロジェクトを担当した富士通中国システムズ（2010年当時）の甲野義久が、「足繁く呉医療センターに通い、医師と向き合い、丹念にヒアリングを」行った結果だった。途中からプロジェクトに参加した富士通 ヘルスケアソリューション事業本部の山岡弘明は語る。「仮想化とかクラウドとかいう言葉は、どうしても一人歩きしがちです。でも実際には、そういった技術は手段であって、それをやることそのものが目的じゃないんです」「技術中心に考えるとそこが逆転してしまうこともありますが、あくまでも診療のシステムをこう作りますと提案できたのが大きいと思います」――。 本書「挑む力～世界一を
第2回 Trac Lightningで簡単インストール
2004年にTracの存在を知って惚れ込む。Tracや同様のソフトウエアを普及させるべく，収集した情報をdiscypus.jpにて発信している。 今回は，最初にTracの稼働に必要なソフトウエアについて説明します。その後，Trac Lightningを実際にWindowsにインストールする手順と，Trac Lightningのディレクトリ構成，そしてTrac Lightningが稼働しないときの解決方法を説明します。 Tracのソフトウエア構成 Tracは，プログラミング言語Pythonで記述されています。チケットやWikiなどのデータを保存するために，標準では組み込み型リレーショナル・データベースSQLiteを用いています（PostgreSQLおよびMySQLも使用できますが，Trac 0.10/0.11では実験的なサポートに留まっています）。 Tracは，Webアプリケーションです。W
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
「大丈夫」という部下の報告を信じてはいけない理由
1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 「あのメンバー、仕事の進捗（しんちょく）は大丈夫かな？」 PM（プロジェクトマネージャ）なら、誰もが気になるところです。 「予定の期日に間に合います！」というメンバーの力強い返事を信じて任せていたら、完了予定日になって「実はまだできていませんでした」という相談が来て、結局対応に追われるはめになる……そんな経験はないでしょうか。 しかも、往々にしてこのようなことは1回だけでなく、何度も繰り返し起こります。一段落した時、メンバーに仕事が遅れた理由を聞いても、返ってくるのは「申し訳ありません」という平謝りと「今後はしません」という形ばかりの口約束だけ。 こんな調子じゃ、安心して仕事を任せられません。しかし、こんなふうになってしまうのには
ソフトウェア開発における、実現可能性を判断することの重要性：エンジニアの年輪：エンジニアライフ
ソフトウェア開発をする上で、要求が実現可能か否かの判断は非常に重要です。その理由は、開発工程の後半のフェイズで実現不可能であることが発覚しても、後戻りがきかない場合があるからです。冷静に考えれば誰でも理解できることですが、なぜかこの手の失敗は多く発生しています。では、失敗しないためには、どのようなアプローチをすればいいのでしょうか。今回は、これに対するひとつの考え方をご紹介します。 1．求められていることは何なのか？ “求められていること”、これはソフトウェアを開発する上で非常に重要であると共に、必ず抑えるべきポイントです。これを外してしまうと実現可否以前に、要求通りのソフトウェアを完成させることができなくなってしまうからです。 求められていること＝要求事項です。 この要求事項は、分類すると以下のようになります。 上記の表は、ソフトウェアに対する品質属性モデルとして、米国ヒューレット・パッ
redMine｜Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう!:第1回 プロジェクト管理ツールの必要性/Tracとの違い/redMineがオススメな理由|gihyo.jp
プロジェクト管理ツールの必要性 みなさんのプロジェクトは上手に運営できていますか？ プロジェクトメンバーのタスクの進捗管理はできていますか？ 問題・課題管理はスムーズに行えていますか？ ExcelやWord、紙資料を用いた管理で、作業が煩雑になっていませんか？ 進捗報告ミーティング用の会議資料作成やチームメンバとの情報共有のために、大きく時間を取られていませんか？ ファイルサーバには必要かどうか判断できない無駄な資料があふれかえっていませんか？ ソースコードはきちんと管理されていますか？ リリース用のソースコードに、どんな機能が盛り込まれ、どんな不具合が解決したのか、ちゃんと把握できてますか？ プロジェクトが混沌としてくると、ドキュメントやソースコードの構成管理がぼろぼろになり、プロジェクトメンバの作業の進捗具合をリーダが見通せなくなります。その結果、上記のような問いかけに対して「できてい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
