WBSはプロジェクト管理の基本にして極意！PJを成功に導くWBS作成3つのポイントと注意点
こんにちは、編集部のジェシカです。
今回は、既にご存知の方も多いと思いますが、改めてWBSについておさらいしてみます。
プロジェクトになくてはならないWBS。
きちんと作成・運用をしてプロジェクト炎上ゼロ「0」を目指しましょう！
WBSとは？
WBS（ダブリュービーエス）は、 Work Breakdown Structure（ワークブレークダウンストラクチャー） の略で、プロジェクトで発生するタスクを一覧化したものを指し、担当者アサインやスケジューリングの 基礎になるものです。
WBSはタスクの最小単位までブレイクダウンしたものと思われがちですが、PMBOKで定義されるWBSはワーク パッケージの一覧とされていて粒度が粗いものです。
PMBOKではワークパッケージをさらに「アクティビティ」に分解しますが、これが世間一般に言われるWBSです。
WBSはプロジェクトの肝といっても過言ではありません。
タスクがきちんと洗い出されていなければ見積もりやスケジューリング、担当者アサインや進捗管理が適切 にできないからです。これでは、プロジェクトは円滑に進行できません。
タスクを雑に洗い出したWBSを元に作成された見積もりやスケジュールは確実にブレが生じます。
そんなWBSを見たときは、プロジェクトが炎上している未来が目に浮かんで背筋が寒くなります…（泣）
PMBOKではWBSの作成は計画プロセスの「プロジェクト・スコープ・マネジメント」に規定されていて、 「WBS =スコープを明確にする」役割が強いものです。
「何をやるか」を定義するのと同時に「何をやらないか」を明確にしてプロジェクトオーナーの期待値を コントロールする役割があり、単なるスケジュール表ではないということを理解しておきましょう。
▼やらないことを定義する重要性についてはこちらの記事もオススメです▼
WBSの作り方と注意点
まず、WBSを作成する時におすすめのツールが、マインドマップです。
WBSは、大きなタスクの塊で全体像をとらえて、そこから作業工数見積もりができるレベルまでタスク分解 していくことが重要です。
マインドマップを利用すると、タスク分解が視覚的に把握でき整理しやすくなります。
（参考） マインドマップで「やりたいこと」を芋づる式に洗い出そう！
マインドマップとは、頭の中で考えていることを視覚化できるようにした思考ツールです。
いろんな種類の マインドマップアプリがあるので、使いやすいものを選んでみましょう。
（参考）
マインドマップで発生するタスクを洗いざらい書き出してエクセルで一覧にすれば、WBSが完成です。
あとは、各タスクにかかる工数や担当者を記載すればOK。
工数が洗い出せれば見積もりやスケジューリング が結果としてアウトプットされます。
WBSはプロマネやディレクターが中心となって作成・運用をしますが、プロマネが1人で進めるのではなく、 プロジェクトメンバー全員とディスカッションをしながら作成しましょう。
タスクの展開は、各人の経験やスキルに依存するので、専門の担当者を交えて意見を吸い上げることでより 精度の高い洗い出しができます。
私がWBSを作るときには、以下のような点を意識しています。
・タスクをチケットにできる粒度まで掘り下げる
チケットとは、プロジェクト管理ツール（RedmineやBacklog）で必要な作業を管理する単位です。
チケットに登録することを想定しながら作成すれば、「あれも必要だった」と思いがけないタスクを発見 できるかもしれません。
この方法でWBSを作成すると、WBS上のタスクをプロジェクト管理ツールへそのまま起票でき、プロジェクト 立ち上げ時の無駄な工数を減らすこともできます。
・承認フローも1つのタスクとして入れる
これはさすがにチケット化しづらいのですが…
WBS上では、作成→確認→修正→再確認→修正→再々確認→凍結という流れをある程度可視化しておきましょう。
承認フェーズで想定外の時間がかかって製造工程がパツパツになり、メンバーが泣きを見る事態に陥る ケースが多々あります。
・依頼者（上司やクライアント）に提出する前にプロジェクトメンバーと合意をとる
WBSを提出する前には、必ず各担当に最終合意をとりましょう。
確認者が多いほうがミスに気づけますし、 後から「こんな工数でできるわけない」など言われなくて済みます。
WBS運用時の注意点
WBSは作成してからが本当のスタートです。
プロジェクトメンバーとは1日に1度はコミュニケーションをとって進捗状況を確認しましょう。
当然ですが、1日の遅れを取り戻すには＋1日、3日遅れれば＋3日必要になります。
遅延やリスクにいかに早く気づき、リカバリー策を立てられるかがプロマネの腕の見せどころ。
人によって「できている」「できていない」のジャッジポイントは違います。
状況に応じてWBSを更新し、調整・共有するようにしましょう。
さいごに
WBSをイチからつくるのは大変労力がかかるものです。
できれば、プロジェクトのタイプに合った過去のWBSを参考にし、改良していくことをおすすめします。
プロジェクトタイプに合ったWBS標準があれば、安定したプロジェクト運用がしやすくなるでしょう。
▼プロマネの基礎を押さえるならこちらのコラムがおすすめです▼
EVM - プロジェクトのパフォーマンスをリアルタイムに可視化する管理手法
こんにちは、編集部のジェシカです。
EVMというプロジェクト管理手法は、プロジェクトマネジメントに携わる人なら聞いたことくらいはありますよね？
．．．実は私、聞いたことありませんでした。
．．．上司に「え、、、ジェシカ、EVMの概念も知らないの・・・。」
と言われました。
そんなわけで今日は、EVMについて調べてみたのでまとめてみました。
EVMは、Earned Value Management（アーンド・バリュー・マネジメント）の略で、「コスト」「スケジュール」 「品質等のパフォーマンス」に焦点を当ててプロジェクトのパフォーマンスを視覚的に管理する手法です。
EVMの歴史
EVMは1960年代に米国国防総省の調達規則の一部として制定されたものが元となり、1990年代にクリントン大統領政権下で国家的プロジェクトのパフォーマンス改善のために改良されて発展してきました。
国内でも、大手SIerが大規模プロジェクトでEVMによる進捗管理を必須にするポリシーを制定した事例があります。
EVMは非常に優れた管理手法なのですが管理コストが高く、大規模なプロジェクトでないと管理コストが効果を 上回ってしまうため、１億円以上のプロジェクトが一般的な目安です。
でも、「１億円以上」を見て「オレには関係ない」と思わないでください！
厳密にEVMを適用するとコストがかかりすぎますが、考え方を知って小規模なプロジェクトに活かすことはできます。
EVMを理解するために知っておくべき4つの用語
EVMを理解するためには、まず以下の4つの用語を理解しましょう。
・BAC（Budget At Completion）：完了時総予算
プロジェクトが完了するまでに必要となる当初予算。
・PV（Planned Value）：出来高計画値
成果物を期限内に達成するために必要なコストの時系列の計画値。
・EV（Earned Value）：出来高実績値
一般的には出来高と言われ、作業により完了した一定時点の実際の価値。
・AC（Actual Cost）：出来高実績コスト
作業で実際にかかった一定時点のコスト。計画どおりに進んでいれば、PVと同じ数値になります。
EVMでは、これらの数値をグラフにして、計画と実績値の差を視覚的に表現します。
そして、計画値と実績値の乖離が許容範囲を越えたらすぐに手を打つことで、「発覚したときにはもうリカバリできない状態になっていた」という最悪の事態を防ぐことができるのです。
一般的なWBSはスケジュールに焦点をあてた管理ですが、EVMは「コスト」「スケジュール」「品質等のパフォーマンス」の3つの観点で総合的にプロジェクトを管理できます。
EVMを勉強しながら、実際にやってみた方のスライドがとてもわかりやすかったのでご紹介します。
計画と実績の乖離をリアルタイムで把握するのがポイント
EVMを実際のプロジェクトに適用するハードルは高そうですが、参考にできるところはあります。
開発が遅れてスケジュールが伸びそうになったときに、なんとか間に合わせるために「自分が無理をすればいけ る」と誰かが長時間残業をしていませんか？
そのようになるのはたいてい、問題に気づくのが遅いことが原因です。
EVMの考え方を応用して、今の時点で何がどこまでできていればよいかきちんと把握しておけば、そのような 事態を予防できます。
そのためには、より細かい粒度でWBSを作成して工数見積もりを行い、デイリーで進捗をウォッチするとよいでしょう。
▼プロジェクト管理には、こちらの記事もおすすめです▼
「HOME’S」の超高速改善プロセスの秘密とは？！大規模サービスにおけるプロジェクト管理の最前線を丸ごと聞いてきた
物件数No.1の不動産・住宅情報サイトHOME’S。
この大規模サービスを運営する株式会社ネクストは、カイゼンプロセスが超高速だとプロマネ界隈でよく話題に上がります。
その謎に迫るべく、HOME’Sの中の人にプロジェクトの進め方についてインタビューしてきました。
インタビューしたのは、デバイスソリューションユニット デザイナーの小林武蔵さん
小林さんは、2009年に新卒で株式会社ネクストに入社。
現在まで一貫してHOME’Sのデザイナーとして活躍してきました。
入社当時はPCサイトのデザインから始まり、ガラケーサイト、スマホサイトのカイゼンやフルリニューアルに携わったのち、メールマーケティングでHTMLメールのデザインをゴリゴリ作る期間を経て、2014年からiOS、Androidアプリを管轄するスマートデバイス部門に異動。
現在はAndroidアプリをメインに日々のカイゼンプロジェクトに取り組んでいます。
左：coach4pm 千歳紘史（インタビュワー）／右：株式会社ネクスト 小林武蔵氏
Q. いきなり本題です。何でそんなにカイゼンが速いんですか？
元々ネクストは開発の品質と速度に対する社内外からの評価が高い会社でしたが、それでも色々な課題がありました。
その中で僕が所属するデバイスソリューションユニットは、特に高速な開発スピードを誇っています。
その秘密は、ウォーターフォール×アジャイルのハイブリッド型開発プロセスです。
最初はウォーターフォール型、次にアジャイル開発、そしてプロダクトデザインスプリント（Product Design Sprint）を試して最終的に型にはまったのがこの形です。
僕たちの組織にとてもフィットしていて、一気にスピードが上がりました。
Q. 最初はウォーターフォール型だったんですね。どんな点が課題だったんですか？
僕のチームはプランナー、デザイナー、エンジニアが全員いる、いわゆるCFT（クロスファンクナルチーム）です。
このメンバー構成でウォーターフォール型の開発プロセスを取ると、どうしてもデザイナーとエンジニアの待ち状態ができてしまいます。
複数の施策の実施タイミングをうまく重ねることで緩和できる部分もありますが、それでも稼働のロスがかなり発生してしまっていたんです。
ウォーターフォール型の利点である手戻りの少なさは確かにあったのですが、それよりも待ち時間の問題が大きいと考えていました。
だからカイゼンをさらに高速化するには、とにかく稼働ロスをなくさなければと考えて、次にアジャイル開発を取り入れてみました。
Q. アジャイル開発なら、待ち時間の問題は解決しそうですね。
いえ、実は解決しなかったんです。
HOME’Sのような大規模サービスの場合、関係各部との仕様調整、数字的裏付け、他デバイスや関連サイトへの影響の確認など、仕様凍結するために行わなければいけないタスクが膨大にあります。
これらのタスクはプランナーが担うのですが、1～2週間のスプリントで開発を進めながらこれらの調整を行うのは限界がありました。
プランナーの仕様凍結が完了しないと最終的なデザイン・実装も完了できないため、結局足並みを揃える必要があります。
そうするとプランナーがボトルネックになってしまうので、デザイナー、エンジニアの待ち時間を減らすことはできませんでした。
Q. アジャイルサムライの教科書的に言えば、デザイナーやエンジニアがプランナーのタスクをカバーすべしとなりますが、それではダメ？
人員リソースの偏りや、個々のスキル不足の問題がありました。
デザイナーやエンジニアがそれぞれの立場からアドバイスはできても、企画面の深い話まで入り込むことができません。
メンバーが固定的で、プロダクトさえ成長すればいいのであれば、四苦八苦しながらもデザイナーやエンジニアが実装以外のタスクをこなし、徐々にスキルを身に付けていけばよいかもしれません。
みんながゼネラリストになろう！という発想です。
でも現実的には、メンバーそれぞれのキャリアプランがあり、それぞれの専門性を高めたい人もいますし、常にいまのメンバーのリソースを確保しつづけることも難しいです。
だから、デザイナーやエンジニアがプランナーの職務を補うのではなく、開発プロセスを改善して課題解決を図ろうと、次はプロダクトデザインスプリントにチャレンジしました。
Q. プロダクトデザインスプリント・・・？
プロダクトデザインスプリントは、Google Venturesが提唱している開発プロセスで、Design ThinkingやIDEOのメソッドをGoogle Venturesがスタートアップ向けに最適化したものです。
この方法論も考え方としてはアジャイル開発のように「創りながら考える」ので、結論としてはHOME’Sには馴染みませんでした。
ただ、Google社が主催しているデザインスプリントのワークショップなどにも参加して勉強する中で、プロダクトを中心に考えることの重要性や、創りながら考えることの重要性を感じ、その部分は取り入れなければと強く感じました。
だから、創りながら考えるスタイルを取り入れつつ、プランナーがボトルネックにならないようにするためにはどうしたらいいだろう？と考えて生まれたのが、冒頭でお伝えしたウォーターフォール×アジャイルのハイブリッド型開発プロセスなんです。
Q. ハイブリッドって何かカッコイイですね。2つの開発手法のどんな要素を組み合わせたんですか？
プランナーはウォーターフォールで作業を進め、デザイナーとエンジニアはアジャイルで開発を進めます。
図で表すとこんな感じです↓
プランナーが施策を起案するところがすべてのスタートになります。
他部署調整や数字的な裏取りをして仕様を凍結する作業をプランナーが進めている最中に、デザイナーとエンジニアはプロトタイプを作り始めてしまいます。
チームは同じオフィスの同じ島に座っていますので、プランナー、デザイナー、エンジニアが常時コミュニケーションをとりながら、仕様が固まるにつれてプロトタイプに反映していきます。内製のいいところですね！
そうすると、すべての調整が完了して仕様が凍結されるときには、大枠のデザインとUI側の実装が終わっている状態（いわゆるホットモック）になります。
この段階が、僕のチームでは「キックオフミーティング」になります。
すべての仕様が固まっているので、あとは正式にリリースするための本実装とテストを行うのみ。
そこから一気に作って、施策規模によってスケジュールにバラつきはありますが平均1週間から2週間程度で作業完了となります。
現在はプランナー1名、デザイン1名、エンジニア4名のチームで、常時4本程度の施策を進めている状態です。
Q. キックオフのときには仕様が確定しているって素敵すぎますね！このプロセスを導入する上でのポイントなどはありますか？
プロトタイピングの段階では当然手戻りは発生しますし、社内の承認が通る前に作り始めるので最悪お蔵入りになるリスクがあることをメンバー全員で受け入れるのが最大のポイントだと思います。
手戻りやお蔵入りのリスクと引き換えに、稼働ロスをなくし、実際動くものをつくることで実装期間を確保し、納得できる品質のモノにまで仕上げているんです。
Q. 最悪お蔵入り・・・。メンバーのモチベーション下がりませんか？
実はそこは逆で、メンバーのモチベーションが高く保てるようになったんです。
これまではプランナーが考えたものを実装メンバーが実装する構図だったので、どうしても実装メンバーの当事者意識が高まり切らず、特に期間が長いプロジェクトではモチベーションが維持できない傾向がありました。
施策の狙いや仕様に納得はしていても、そこに自分の意見は反映されていないからですね。
ハイブリッド型に移行すると、プロトタイピング期間にプランナー、デザイナー、エンジニアの3職種のコミュニケーションが非常に活発になります。
実装メンバーが企画の意図を汲み取り、同時並行で進めていくことで当事者意識が高まり、比例してモチベーションも高まります。
そもそも前提として、手戻りやお蔵入りリスクを受け入れるのがメンバー全員の共通認識ですから、仕様が固まる前に作り始めたものがポシャったとしてもモチベーションに与える影響は軽微です。
むしろお蔵入りというより、持ち球が増えたという認識でいます。
いまは難しくても、いつかリリースできるときにそこからコンテニューできますからね！
Q. そんな素敵なプロセスを実現しているプロジェクト管理ツールがあれば教えていただけますか？
ツールとしてはChatWork、Confluence 、JIRAの3つを併用しています。
企画が起案されるたらチャットワークの部屋を作ってコミュニケーションを開始します。
日常のコミュニケーションはすべてこの部屋で行っています。
ドキュメント管理に使用しているのが、Atlassian社が提供しているConfluence（コンフルエンス）です。
議事録や仕様書などのドキュメント類はすべてコンフルエンス上に格納する運用をしています。
ただ、数字の計算が苦手なツールなので、まだまだエクセルを使うことも多いです。
タスク管理はJIRAです。
コンフルエンスと同じAtlassian社が提供しているものですね。
作業ごとにチケットを発行してチケット上でステータス管理や実装の記録などを行うような、よくあるチケット開発をしています。
過去には影舞やRedmineなどを使っていたこともありました。
RedmineよりJIRAのほうが高機能なのだとは思うのですが、正直なところRedmine以上の使い方は残念ながらできていません。
ただ、それでもJIRAを使うのは、コンフルエンスとの相性がとても良いためです。
JIRA側でコンフルエンスへのURLを記述すると自動的に相互リンクが表示されるなど、痒いところに手が届く感じです。
1つ1つを取り上げると大したことではないのですが、毎日何度も発生する作業が簡略化されるのは作業するのにとても気持ちがいいです。
JIRAもコンフルエンスもマクロで自由度の高いカスタマイズができるので、今後さらに組織にフィットした運用ができるよう運用改善を進めたいと思っています。
Q. とても勉強になりました、ありがとうございます。最後に、プロジェクトマネジメントに悩む読者に一言お願いします！
今日お話しした開発プロセスやプロジェクトマネジメント手法がうまくいっているのは、HOME’Sの文化や組織体制にうまくフィットしているからです。
つまり、ネクスト以外の会社でこれをそのまま適用しようとしても必ずしもうまくいかないはずです。
それはスクラム開発であれ、エクストリームプログラミングであれ同じこと。
本に書いてあったり、誰かが教えてくれたりした開発プロセスをそのまま適用しようとするのではなく、 僕たちがこのスタイルにたどり着いたように「プロセスに対してのPDCA」を回していく思想を皆さんと共有したいです。
そして僕自身はHOME’Sのモノづくりを担う立場としてより良いプロダクトを作り続けていくと同時に、HOME’Sのモノづくり文化を積極的に社外に発信して業界にも貢献していきますので今後のHOME’Sにご注目ください♪
よろしければ、ぜひ僕たちの創ったアプリもダウンロードしてみてください！
■Android
HOMES(ホームズ)-賃貸・不動産-住まい探し検索アプリ - Google Play の Android アプリ
■iOS
【書評】クリティカルチェーン – プロジェクトマネージャー必読の一冊。古典と思って侮るなかれ
プロジェクトマネジメントやWebディレクションに関わっている人であれば、表紙くらいは見たことがあるのではないでしょうか。
プロジェクトが遅れる原因とそれに対するソリューションを小説仕立てにした、イスラエルの物理学者エリヤフ・ゴールドラッド氏の名著です。
▼クリティカルチェーン／なぜ、プロジェクトは予定どおりに進まないのか▼
2003年に出版された本で10年以上立っているので、もはや古典と思っている人も多いのではないかと思いますが、いま読んでもたくさんのヒントが得られます。
なかなか分厚いので読破するのに少し時間を要しますが、まだ読んでない方は是非。
そして一度読んだ方も、新たな気づきがあるかもしれませんので再読してみてはいかがでしょうか。
僕もこの週末に久々に再読してみて、改めて良著だなぁと思ったので簡単にまとめてみます。
こんなキーワードにピンとくる人にオススメ
- 炎上プロジェクト
- プロジェクトメンバーの最適なアサイン
- リソースの最適化
- PERTやガントチャート
- TOC（theory of constraints / 制約理論）
- クリティカルパスとクリティカルチェーン
- CCPM
プロジェクトスケジュールを最短にするクリティカルチェーン
もともと非現実的なスケジュールを会社側に押し付けられたり、あまり信頼できない発注先でもコスト優先で決定せざるをえなかったりした経験は誰しもあると思います。
そういった要因から予算がオーバーし、スケジュールが遅延し、計画の縮小を余儀なくされる事態が頻発するという問題提起から物語は始まります。
そんな炎上を誰もが経験し、見積もりには一定のセーフティー（バッファ）が多く含めているはずなのにプロジェクトの炎上がなくならないのは何故でしょうか？
（各人の見積もりにセーフティーが含まれているという文脈で） このプロジェクトのリーダーは、各人に見積もりを立てるように指示します。 集まった見積もり時間をリーダーは全部合計します。 ただし、それだけではないんです。 その合計にリーダーも自分のセーフティーを足してしまうんです。 （中略） マネジメントが、何段階か関わっている場合もあります。 その場合も各段階ごとにセーフティーが追加されます。
それぞれのステップで作業が速く終わったり、逆に遅く終わっても、これが平均化されることはない。 つまり、作業が遅れた場合は時間が溜まっていくが、早く終わってもその分時間が減ることはない。 たくさん用意されているはずのセーフティーが消えてしまうのは、これで説明がつく
その答えは「バッファ・マネジメント」だというのがこの本の主張です。
そして、バッファ・マネジメントの方法として物語の中に出てくるものこそ「クリティカルチェーン」なんです。
書籍内には（たぶん）出でこない用語ですが、このプロジェクトマネジメント手法は一般にCCPM（クリティカルチェーンプロジェクトマネジメント）と略して呼ばれています。
CCPMは単なる数学的な理論ではなく、プロジェクトメンバーの心理的側面も十分に考慮されていて、実務に適用しやすい考え方になっています。
クリティカルチェーン・プロジェクトマネジメント（CCPM）については、こちらの記事で簡単にまとめていますので、よろしければご参照ください。
ほんっっとーに概要だけを簡単にまとめたので、一度は本を手にとってみることをオススメします。
ちなみに、物語の中ではちょっとしたロマンスもありますよ(￣▽￣)V
プロジェクトマネジメントはアートではありません。
プロジェクトの不確実性をプロマネのセンスで乗り越えるような職人芸的なマネジメントでは、次第にプロダクトの競争力を失ってしまいます。
アートではなくサイエンスとしてのプロジェクト管理手法を学んで、より確実でスピード感のあるプロジェクトどんどん生み出していきたいですね♪
▼プロジェクトマネジメントに悩むあなたにこちらの記事もオススメです▼
「伝わるチケット」でプロジェクト管理をスムーズに！Redmineを見やすくするtextile記法9選
Redmineでプロジェクトを管理しているみなさん、こんにちは。ジェシカです。
あなたが書いたチケット、ちゃんとメンバーに伝わっていますか？
意味不明なチケットや、あとから振り返ると起票者でも記憶を辿るのに時間がかかるチケットなどが乱立していることがよくあります。
情報は書いただけでは意味がなく、相手に正確に伝わって初めて意味があります。
チケットを見たメンバーから「これ、どういう意味ですか？」などと質問がくるうちは、まだ「伝わるチケット」になっていないということです。
チケットは起票後すぐに対応するとは限りません。
あなたが既にプロジェクトから離れていて質問すらできない状況になっているかもしれません。
誰がいつ見ても迷うことなく対応できるのが「伝わるチケット」です。
「伝わるチケット」にするためには、あとからプロジェクトに参加したメンバーでも迷わないように、背景や目的をきちんと書く、可能な限りスクリーンショットを添付するなど気を付けるべきポイントがたくさんあります。
本記事では、少しでもチケットがわかりやすくするために効果的なtextile記法をご紹介します。
最新のバージョンでは、WYSIWYG（ウィジウィグ）で表現できるようになっていますが、まだ古いバージョンを使っているRedmineユーザーは、込み入った説明をする時に、文字だらけで読みづらい体裁にならないよう上手に記法を活用できるといいですね。
文字を強調したい時
該当テキストや文章を、以下の記号で挟んでください。
- 太字にしたい・・・「*太字*」のように、アスタリスクで囲む
- 下線を引きたい・・・「＋下線＋」のように、プラスで囲む
- 斜体にしたい・・・「_shatai_」のように、アンダーバーで囲む。但し、日本語は斜体にできないので注意してください。
他のチケットにリンク
「#チケット番号」で他のチケットにリンクできます。 前後に半角スペースを入れるのを忘れずに。
左側にインデント（スペース）を入れたい時
” p(. ”でインデントを設定できます。
” ( ”の数を増やすことで、インデントの階層を表現できます。
文章の上下には空行を入れましょう。また、ピリオドの後は半角スペースが必要です。
（記法例）
p. 左にインデントを入れない場合
p(. 左にインデントを一文字分入れたい場合
↓ ↓ ↓ ↓
（表示例）
左にインデントを入れない場合
左にインデントを一文字分入れたい場合
リストや番号で箇条書きをきれいに見せたい時
「*」アスタリスクや「#」シャープを使って箇条書きを見やすく整えます。
【リストの場合】
該当のテキストの先頭にアスタリスクと半角スペースを入れましょう。アスタリスクの数によって、表示される記号やインデントが変わります。
【箇条書きの場合】
（記法例）
* カルビー
** じゃがりこ
*** サラダ味
*** チーズ味
↓ ↓ ↓ ↓
（表示例）
●カルビー
◯じゃがりこ
■サラダ味
■チーズ味
【番号の場合】
シャープと半角スペースを入れましょう。シャープの数によってインデントが変わります。
（記法例）
# バラ
# チューリップ
## 赤
##白
### きれい
↓ ↓ ↓ ↓
（表示例）
1. バラ
2. チューリップ
1. 赤
2. 白
1.きれい
見出しをわかりやすくしたい時
h1.からh6.まで使用できます。見出しの先頭に希望のサイズを入力します。ピリオドの後ろに半角スペースを入れることをお忘れなく！
（記法例）
h1. 改修概要
水平線を引きたい時
画面いっぱいに水平線を引きたいときは、「---」のように、ハイフンを３つ並べ、上下は空行にしておきます。HTMLのhr /タグに該当します。
（記法例）
---
↓ ↓ ↓ ↓
（表示例）
リンクをつけたい時
リンクをつけたいテキストを「“」ダブルクォーテーションで囲み、「：」コロンをつけてURLを記載します。URLの末尾には半角スペースを入れます。
（記法例）
"URLはこちら":http://media.coach4pm.com/
↓ ↓ ↓ ↓
（表示例）
URL はこちら
表（テーブル）をつくりたい時
文字列を「｜」（パイプライン）で囲むと表示されます。
（記法例）
|No|国名|首都|
|1|フランス|パリ|
|2|オーストラリア|キャンベラ|
↓ ↓ ↓ ↓
( 表示例)
「_.」アンダーバー＋ピリオドをテキストの前につけると、その行のテーブルヘッダとして太字でセンター表示してくれるので、表が見やすくなります。
（記法例）
|_.No|_.国名|_.首都|
|1|フランス|パリ|
|2|オーストラリア|キャンベラ|
↓ ↓ ↓ ↓
( 表示例)
ソースコードを記載したい時
ソースコードなどの記述や表記を加工せず、そのまま掲載したい場合は、preタグで囲むと、該当のソース箇所を囲って見やすく表示してくれます。
さいごに
textile記法は、半角スペースや文章の前後に空行が必要なことが多いので、「うまく表示されない」時にはこれらがきちんと入っているか確認してください。
文字だけで込み入った内容を伝えることは難しく、相手に誤解を与える内容になってしまう恐れがあります。
一度相手に誤解されると、軌道修正に時間がかかってしまい、プロジェクトの進行に影響を与えかねません。
相手に伝わりやすい、思いやりのあるチケットが作成できるよう、ぜひtextile記法を取り入れてプロジェクトをスムーズに進行させてください！
★Redmineの活用についてはこちらの記事もオススメです。★
CCPM - 約束したスケジュールを確実に達成するプロジェクト管理手法
どんなプロジェクトにおいても、スケジュールは重要な制約条件のひとつです。
約束したスケジュールを確実に守るために様々なリスクをコントロールしていくことがプロジェクトマネージャーの責任です。
スケジュールを左右するリスクはたくさんありますが、そのうちのひとつがプロジェクトメンバーの生産性です。
予定していた作業日数で作業を終わらせてもらうために、プロジェクト管理の視点でどのようなアプローチをとったらよいでしょうか？
各作業にバッファを設けてもプロジェクトは遅延する
約束したスケジュールを確実に守るためにまず思いつくのは、プロジェクトの各タスクに対してバッファを設けることです。
▼こんな感じ▼
これなら確実にスケジュールを守れそうな気もしますが、このようなスケジューリングには大きな落とし穴があります。
落とし穴１．プロジェクト期間が間延びする
上記のようなスケジューリングは、各タスクにバッファを用意しているため、目標となる工期と約束するスケジュールにかなりの開きが出てしまいます。
もちろん約束したスケジュールを確実に達成するのはプロジェクトマネージャーの責務ではあるのですが、一方でいかに早くプロジェクトを完了させるかもプロジェクトマネージャーの腕の見せ所です。
これでは余裕を持ちすぎたスケジュールとなってしまい、リリースが必要以上に遅くなってしまいます。
落とし穴２．プロジェクトメンバー間に不公平感が出る
さらに、このようなスケジュール管理手法を採用した場合、主にクリティカルパス上のタスクを管理します。
クリティカルパス上のタスクにもそれぞれバッファを設けているので、そこまでメンバーのプレッシャーになることはないかもしれません。
しかし、クリティカルパス上にないタスクを担当している人と比べると、やはりクリティカルパス上のタスクを担当しているメンバーへのプロジェクトマネージャーの態度は厳しくなりがちです。
こういったことから不公平感が生まれてしまうと、チーム全体の雰囲気が悪化してしまいます。
落とし穴３．そもそも、リスクがあまり減っていない
なにより根本的な問題は、いくらバッファをとったところでリスクがあまり減っていないことです。
これには人間の2つの行動特性が大きく関係しています。
・作業着手を遅らせる「学生症候群」（Student syndrome）
日程に余裕があるときに、日程の余裕がなくなるまで作業着手を遅らせる傾向を、学生症候群と呼びます。
夏休みに宿題を課せられた学生が、休みが終わるギリギリまで宿題に着手しないシーンは容易に想像ができると思います。
これは学生に限らず仕事でもよく見られる傾向です。
・作業期間を間延びさせる「パーキンソンの法則」（Parkinson’s law）
イギリスの政治学者シリル・ノースコート・パーキンソンが提唱した法則で、完了しなければならないその日まで作業が行われるという性質です。
ダラダラ作業をしてしまったり、必要以上に細部にこだわってしまったり、完了基準が曖昧なためいつまでも作業をしてしまったりと、要因は様々ですが、早めに作業を切り上げられない行動特性をいいます。
このような人間の性質によって、タスクごとのバッファは見事に食いつぶされ、結局はギリギリのスケジュールでプロジェクトを進行させることになるのです。
落とし穴４．だからと言って、メンバーにバッファを伝えないとマネージャーの不信感を生む
学生症候群やパーキンソンの法則を回避するために、バッファの存在をメンバーに伝えずに作業してもらうのもひとつの方法です。
しかし、頑張って終わらせたのに実はバッファがあったことがメンバーに知れたときのマネージャーへの不信感は相当なものです。
そのようなことが続くと、「このマネージャーは本音を話してくれない」と思われて信頼を失ったり、「どうせ余裕があるから多少遅れてもいいだろう」という甘えが生まれてしまったりします。
これらを克服するのがCCPMという管理手法
CCPM（Critical Chain Project Management／クリティカル・チェーン・プロジェクト・マネジメント）とは、イスラエルの物理学者であるエリヤフ・ゴールドラット博士が提唱した管理手法で、PMBOKにも記載があります。
ゴールドラット博士の名著「クリティカルチェーン」の中で紹介されたことで世の中に広く広まりました。
CCPMでは、タスクごとにバッファをとるのではなく、全タスクの後ろでまとめてバッファをとります。
▼こんな感じ▼
このようにスケジューリングするとそれぞれのタスクにはバッファがなくなり、学生症候群やパーキンソンの法則を防ぐことができます。
もちろん作業が遅れてしまうこともありますが、全体のバッファで調整します。
全体のバッファは、個人の作業バッファに比べて「使わないようにしよう」という意識がプロジェクトメンバーに働きやすいメリットがあります。
バッファの存在をメンバー隠す必要がなくなるので、チームの信頼関係も向上します。
用意すべきバッファは（HBP－ABP）×0.5
では、どの程度バッファを設ければよいでしょうか？ 具体的なバッファ計算例として、以下の考え方をご紹介します。
１． 各タスクのABP（Aggressive but Possible／目標スケジュール）を見積もる
ABPとは、何とか達成できそうなギリギリのスケジュールのことを言います。
あくまで一般論ですが、この観点で出した見積もりは50%の確率で達成されると言われています。
２． 各タスクのHBP（Highly Possible／確実なスケジュール）を見積もる
HBPとは、余裕をもって立てた確実なスケジュールで、バッファが含まれたものです。
３．（全タスクのHBPの合計－全タスクのABPの合計）×0.5＝用意すべきバッファ
ABPが50%の確率で達成されるとすれば、全体でまとめたバッファのうち半分のスケジュールを確保しておけばよいことになります。
これによって、各タスクにバッファを設けるよりも短い期間でプロジェクトが完了する目途が立てられ、前図のように間延びしないスケジュールになります。
もちろん50%というのは一般論に過ぎません。 実際はアサインされているプロジェクトメンバーの過去の実績などを参考に恣意的に設定します。
バッファをどの程度を取るかはプロジェクトマネージャーのさじ加減です。
日ごろからプロジェクトの作業データを蓄積したり、メンバーの生産性をウォッチしたりして経験を積んで、過不足のないバッファ設定ができるようになりましょう。
▼プロジェクト管理に悩むプロジェクトマネージャーにはこちらの記事もオススメです▼
見逃すと99%失敗するWebサービス立ち上げで制作・開発会社を選定する10のポイント
Webサービス立ち上げチームに配属されたり、素晴らしいアイデアで独立起業をされたりと、Web制作・開発会社の選定を行う機会は意外と多いのではないかと思います。
Webサービスの立ち上げは、リリースまでが大変だと思いがちですが、実はリリース後もそれ以上に大変！
リリース後の運用フェーズでは、不具合の対応や改善施策の策定・実施などやるべきことが盛りだくさんなんです。
ですから、継続して運用するWebサービスを作るときには、発注先と末永い付き合いになることを考慮して慎重に選ぶことが大切です。
今回は、Webサービスの立ち上げで制作・開発会社を選定する際の10のポイントをご紹介します。
選定に入るその前に、まず事前に発注サイドで準備しておくべきことは？
何も準備をせず、開発会社を呼んで「こんなものが作りたいんだ！これで世界を変えるんだ！！」と話すだけでは、話は遅々として進みません。
どんなサービスを、どんな規模で、いつまでにリリースしたいかなどを盛り込んだ提案依頼書（RFP）をしっかりまとめておきましょう。
また、サイトの内容だけでなく運用体制や業務プロセスについて考えておくことも大切です。
- Webサービスの立ち上げに必要な体制はどんな形か。
- その中で、自社で対応できる部分はどこか。人員は足りているか。
- 自社で対応できない部分を発注先に依頼する場合の費用はいくら必要か。
などをきちんと検討しておかないと、発注会社の選定に手間取り、開発着手が遅れてしまいます。
Webサービスの立ち上げ・運用に必要な役割を把握しておこう！
Webサービス開発における開発会社との関係は、プロジェクトに必要な様々な役割を分担するパートナーシップです。
とりあえず開発会社を信頼して任せておけばうまくいくという考えは炎上の火種。
まずはどんな役割が必要なのかを把握しましょう。
以下に一例を挙げます。
・プロデューサー
サービスの全体を設計する。どんなサービスなら戦えるか、どんな体制 なら成長させられるのかを考える。Webサービスの立ち上げ・運用 経験が必須。
・プランナー（編集）
プロデューサーより、もう少し具体的な企画やコンテンツを考える。ユーザーの声や様々なトレンド、競合の動きなどをキャッチしてコンテンツに落とし込む力が必要。
・マーケター
広告戦略、SEO戦略、プロモーション戦略、その他のPR 戦略を検討する。Webマーケティングに関わった経験が必須。
・フロント設計
IA（インフォメーションアーキテクチャ）と呼ばれることもある。
サイトの表面的な画面設計をする人。主に、ワイヤーフレーム制作を行う。Web制作に関わった経験が必須。
・システム設計
SE（システムエンジニア）が対応することが多い。サイトをどんな仕組みで動かすかを考える。開発経験が必須。
・デザイナー
Webデザイン経験が豊富な人が望ましい。できれば、サービスの立ち上げ と改善の両方を経験している人がよい。
・フロントエンドエンジニア
表面上の、見える画面のプログラムをつくる人。HTML、CSS、JSなど。 サーバサイドはわからなくてもよいが、できればJSをゴリゴリかける人が よい。
・サーバサイドエンジニア
システムが動的に処理をする仕組みをつくる人。DB、各種ファイルへのアクセスなど。
・インフラエンジニア
WebサーバやDBサーバ等を構築し、管理する人。
・テスター
出来上がった画面やシステムのテスト（検証）を実施し、不具合報告、修 正やステータスの管理をする人。
・ライター
キャッチコピーやサイト内の各種コンテンツの原稿を書く人。
・カメラマン
サイト上に掲載する商品や人物の撮影を行う人。
・アナリスト、リサーチャー
運用で重要な役割。最低限、GoogleAnalyticsを使って、数字を読み解ける 人がよい。アクセス解析だけではなく、アンケート設計やユーザーリサーチ等にも対応できる人であれば、なおよい。
・ディレクター
上記の制作に関わる役割をとりまとめ、進捗を管理しながら進行する人。 幅広い知識とコミュニケーション能力が必須。経験豊富なほどよい。
・プロジェクトマネージャー
プロジェクトマネジメントの観点で、全体をコントロールできる人。プロデューサーやディレクターが兼務することが多い。経験豊富なほどよい。
これらすべての役割が必要というわけではありませんし、プロジェクトによってはこれ以外の役割が必要になる場合もあります。
自社でまかなえる部分と、アウトソースする部分を検討して提案依頼書に盛り込みましょう。
では本題。制作・開発会社を選定する際の10のポイントはこれ！
提案依頼書ができたら、候補の会社に説明を行い、見積もりの他に、以下の内容を提示してもらうようにしましょう。
各項目に簡単な説明を入れていますので参考にしてください。
1. 見積もりで想定している機能一覧、開発環境、フレームワーク等
2. 見積もりで想定しているWeb/DBサーバ構成
上記2つは、見積もりがどれだけ練られているかを確認するためのものです。
要件定義前なので概算であることは当然ですが、だからと言って適当な見積もりではダメ！
どこまで想定できているか、きちんと確認しましょう。
（ここだけの話、適当な見積もりの会社がかなりあります。）
ここがずれると、プロジェクト終盤で機能を縮小したりスケジュールを延期したりせざるを得ない事態に陥ってしまいます。
3. 対応可能な保守体制、監視体制
例えば、24時間365日の保守管理ができるのか、膨大なトラフィックのサイトに成長した時の運用を想定できているのか等、作りたいサイト規模やサービスに合わせて確認しておきましょう。
小規模な会社の場合、体制が整いづらいケースがあります。
4. 想定している開発体制とスキルセット
5. 正社員以外のリソース利用の有無
提案時は、「できます！」とみんな言います（苦笑）。
しかし、「できる」の程度は会社によってバラつきがあるのが事実。
プロジェクトがスムーズに進むかどうかは結局は担当者次第という側面が大きいので、体制や担当者のスキルセットを細かく聞いてみましょう。
私は、大きい案件の場合は担当者の社歴もヒアリングしていました。
社歴が浅いと横のつながりが薄く、開発会社社内の協力関係がとりにくい場合があるからです。
6. 見積もりで想定していない範囲も含めた対応可能業務領域 （特にディレクション領域についてどこまで対応可能か）
前述した通り、Webサービス立ち上げ・運用における開発会社との関係性は「役割分担」です。
直近で必要ではなくても、いずれ必要になる役割もありますので、将来的にどこまでの依頼ができるか確認をとるとよいでしょう。
プロジェクトは、常にハプニングの連続です。 予想が外れた時に「想定外なので対応できません」と言われては困ります。
柔軟性を持ってどこまで対応してもらえるかを確認することが大切です。
「ディレクション」業務について言えば、人によって業務範囲の捉え方が異なるので、業務の認識の食い違いがないよう、ディレクションの作業内訳をリストにしたPDFをご用意しています。
発注先との業務擦り合わせで、活用できると思いますので、ぜひダウンロードしてご利用ください。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
※今後のさらに役に立つ情報提供のために、簡単なアンケートにご協力いただけますと幸いです。なお以前アンケートにお答えいただいた方は、直接メールいただければお送りします。
よろしければこちらの記事も参考にしてみてください。
7. 慣れている開発プロセス・カイゼンプロセス
8. よく利用するコミュニケーションツールとプロジェクト管理ツール
発注側がアジャイルな開発プロセスを求めているのに、受注側はウォーターフォール型の開発しかやったことがない、あるいはその逆など、開発プロセスがフィットしないことがあります。
開発プロセスには慣れも必要で、いきなり「こういうプロセスでやりましょう」と取り組んでもうまく進まないことがほとんどです。想定している開発プロセスを必ず合意するようにしましょう。
また、どんなツールを使っているかもポイント。 コミュニケーションメールベースなのか、SkypeやChatwork、Slack等のコミュニケーションツールを使っているのか。
プロジェクト管理はエクセルベースなのか、RedmineやBacklog、JIRA等のプロジェクト管理ツールを使っているのかなどです。
お互いに慣れたツールを使って進められると、ツールに慣れる期間が短縮できるのでとても効率的です。
9. 過去の実績と詳細な対応範囲
多くの会社が、見栄えのよい有名企業のサイトを事例として紹介してくれるのですが、見た目にだまされず、具体的にどの部分をどれくらいの期間で対応したのか説明を受けましょう。
実績の中に、似たサービスの開発実績があれば、うれしいですね。
プロジェクトはそうそう順調に進むものではありませんから、少しでも経験を積んで、想定外のことを排除できる会社へ依頼するほうがリスクヘッジになります。
10. 通常利用されている業務委託契約書ひな形
プロジェクトが中止になったりサイトが約束の期限までにできなかったりという最悪の事態も想定しておきましょう。
途中解約の条件、瑕疵担保や損害賠償の上限などはしっかり確認しておきましょう。
中小企業の場合は損害賠償が支払えない場合もあるので、IT保険に入っているかどうかも選定のポイントです。
さいごに
複数の開発会社と話をするとよくわかりますが、得意な分野や担当者の雰囲気は会社によってさまざまです。
プロジェクトがスムーズに進むよう、事前準備と発注会社へのヒアリングをしっかり行い、よいパートナーを見つけてサービス開発を成功させてください！
▼プロジェクトを成功させたいプロマネ・ディレクターにおすすめの記事▼
