読者です 読者をやめる 読者になる 読者になる

coach4pm-プロジェクト管理をコーチングで支援-

Web業界で戦うプロジェクトマネージャーやディレクターのためのノウハウ

もう追従メニューに泣かない!スマホページ全体をきれいにキャプチャする方法とは?

ツール

f:id:chitoseweb:20160211201842p:plain

 

こんにちは、編集部のジェシカです。
みなさん、スマホサイトのページ全体のキャプチャが必要になったことは、ありませんか?


私は、競合調査やサイト改修の指示書作成など、これまでたくさんキャプチャをとる機会をいただきました(笑)。
PCとスマホのサイトURLが異なる場合は、PCのブラウザにスマホのURLを入力して、ブラウザサイズを調整してキャプチャ・・・という作業をご まかしながらやっていたのですが、PCと同じURLの場合は、この方法が通用しません。

スマホのスクリーンショットで表示されている画面を撮って、PCで開いてつなげるという作業もアリですが、不要なヘッダやフッタを切り取る 必要があり、一苦労です。

そこで、今回は簡単にスマホサイト全体のキャプチャを撮れる方法をご紹介します。

 

f:id:chitoseweb:20160813142822j:plain

 

PCでスマホのキャプチャをとる方法

まずは、PCで作業を完結させたい!という人におすすめの方法です。


●chromeのディベロッパーツールを使う方法  

1,最初に、chromeの拡張機能にキャプチャツールを追加します。私は、Full Page Screen Captureという機能を利用しています。

追加した後に、chromeの設定>拡張機能から、追加した機能を有効にすることをお忘れなく。機能を有効にすると、ブラウザの右上にカメラアイコンが表示されます。

 

2,キャプチャしたいサイトのページを表示している状態で、chromeの右上端にあるメニューから、その他ツール>ディベロッパーツールを選択します。

 

3,画面上部に幾つかのプルダウンメニューが表示されます。一番左のメニューから対応させたい画面サイズを選択します。 私はiPhoneを使っているので、現時点(2016/8)では、iPhone6をよく選択します。

 

4,選択後、サイトをリロードすると、スマホページが表示されるので、先ほど設定したカメラアイコンをクリックするとキャプチャがスタート。

完了したら、別ウィンドウで全体の画像が表示されるので、右クリックで画像を保存すれば作業は完了です。

ただ、上記の方法ではヘッダが固定されているスマホサイトだと、所々にヘッダが入ったキャプチャが撮れてしまいます。

 

f:id:rkmrmt:20160812222549p:plain

 

そこで、固定ヘッダを余計なところに表示させない方法をご紹介します。

 

●Firefoxで固定されたヘッダもきれいにキャプチャする方法

1,ブラウザを変えてFirefoxになるのですが、Pearl Crescent Page Saverというアドオンを追加し、有効にします。

Firefox右上端にあるメニュー内に「アドオン」があるので、そこから検索をすればすぐに見つかるでしょう。

 

2,キャプチャしたいページを表示して、Firefoxメニュー>開発ツール>レスポンシブデザインビューを選択すると、スマホサイズの画面に切り替わります。 プルダウンからサイズが選択できます。

 

3,しかし、画面サイズは変わったものの、リロードしても画面の中はPCサイズのまま!という場合があります。 そんな時は、User Agent Switcherもアドオンに追加して有効にしてください。

ただ、このアドオン、デフォルトがiOS3しか表示してくれない仕様になっています。選択肢を増やしたい場合は、下記のサイトで手順を詳しく紹介されているので参考にしてください。

blog.cgfm.jp

 

4,サイトがきれいに表示されたら、Pearl Crescent Page Saverで「ページ全体を画像として保存」を選択しスクリーンショットをとります。 サイトの最上部を表示した状態で実行するときれいに撮れます。

 

f:id:rkmrmt:20160812230529p:plain

 

ヘッダの追従がなくなりました!

設定さえしておけば、次回以降はすぐキャプチャができます。 ただ、設定が面倒と思われる方も多いでしょう。

アプリでスマホのキャプチャを撮る方法

私も最近まで上記の方法を使っていたのですが、スマホのアプリで簡単にサイト全体をキャプチャできる方法を見つけました!(遅い?)

なぜ早く気づかなかったのだろうとショックだったんですが……

 

●iPhoneの人におすすめキャプチャアプリ 「Awesome screenshot for safari」

Awesome screenshot for safari

 iPhoneで閲覧しているサイトのページ全体をキャプチャできるアプリです。

 

1,アプリをインストールしたら、キャプチャしたいページをsafariで開き、ブラウザのフッタに表示されるシェアアイコンをタップ。 一番右端にある「その他」の中からScreenshotの設定をオンにしてください。

 

2,オンにすると、シェアアイコン中のメニューにScreenshotが表示されるので、アイコンをタップし、ページ全体をキャプチャするか、表示されている箇所のみにするか選択します。

ちなみに、キャプチャした後、メモしたり、枠で囲ったりなどといった編集も可能です。

 

3,キャプチャを保存するとカメラロールとアプリ内の両方に格納されます。

 

●Androidの人におすすめキャプチャアプリ 「ウェブクリッパー 」

ウェブクリッパー - Google Play の Android アプリ

Android端末で閲覧しているサイトのページ全体をキャプチャできるツールです。

 

1,アプリをインストールしたら、キャプチャしたいページをsafariで開き、ブラウザURL欄の右側にあるメニューを開きます。

 

2,「ページを共有」をタップすると共有アプリが表示されるので「ウェブクリッパー」を選択します。

 

3,選択するとヘッダにカメラアイコンが表示されるのでタップすれば完了です。アルバムの中にページ全体のキャプチャが格納されています。 撮影範囲は、アプリの設定で変更できます。

まとめ

スマホアプリでキャプチャをとる場合は、iCloud、Dropbox、Evernote、Skype等のアプリと共有できるように設定しておくと便利です。 

いちいちメールに添付して送ったりしなくとも、PCから簡単にキャプチャした画像へアクセスできます。

 

上記で挙げた他にも、キャプチャアプリがたくさんあるので、目的にあったものを探してみてください。

 

みなさんのキャプチャ作業が少しでもストレスフリーになれば幸いです!

 

▼プロマネにおすすめのツールを紹介しているコラムはこちら▼

プロジェクト管理にredmineはいかが? 

 

チャットワークの記法を活用しよう

 

f:id:chitoseweb:20160211201842p:plain

SIPOC - プロジェクトを俯瞰して本当にやるべきことを明確にする改善ツール

プロジェクトマネジメント

f:id:chitoseweb:20160211201842p:plain

 

頑張っているのに課題ばかりが増え続けて、なかなか成果が出ないプロジェクトに悩んでいませんか?

目の前にある課題を片っ端からつぶしていく仕事のやり方を繰り返していると、頑張れば頑張るほど課題が山積みになってしまうことがあります。

 

見つかった課題にひたすら対処しているその姿はあたかもモグラたたきのようで、課題を解決した瞬間の「頑張っている感」は得られますが、際限なくモグラ(課題)が頭を出してくるのでいつまでたっても状況が改善されません。

 

そんな状況から脱却して目に見える成果を手に入れるためには、まずプロジェクトの全体像を俯瞰しなければなりません。

 

俯瞰的な視点がないと、常に局所的な課題にばかりに目が行ってしまいます。
全体像を俯瞰する事で自分やそのプロジェクトが置かれている状況を客観視できて、もぐらたたき状態から脱却するきっかけをつかめるはずです。

 

f:id:chitoseweb:20160728170741j:plain

 

SIPOCはプロジェクトの全体像を捉えるのにシンプルで有効なツール  

 

もぐらたたきに夢中になっていると目の前の課題に近視眼的に取り憑かれてしまい、頑張っているという満足感も得られてしまうため余計に全体像の俯瞰ができなくなってしまいます。

 

そこで有効なのがSIPOCというツールです。

サイポックと読みます。

以下の5つの要素を整理することで、プロジェクトの全体像を俯瞰します。

 

S:Supplier(供給者)

I:Input(インプット)

P:Process(プロセス)

O:Output(アウトプット)

C:Customer(顧客)

 

f:id:rkmrmt:20160728161418p:plain 

これらを整理することで視界が広がり、プロジェクトに含まれる要素が可視化された結果、以下の効果をもたらします。

 

  • 顧客との結びつきが確認できる
  • 重要な活動から認識できる
  • 細かいところで行き詰まるのを避けられる
  • 一眼でプロセスの全体像を捉えられる
  • 本質的な課題の解決を改善計画に結び付けられる
  • 詳細な分析の焦点を必要な部分のみに絞れて、コミュニケーションの土台になる

 

それでは、SIPOCを活用するための具体的な手順を紹介していきましょう。

 

5つのプロセスでSIPOCを作成しよう

 

f:id:rkmrmt:20160728161407p:plain

 

手順1.業務プロセスの境界を明らかにする

SIPOCは全体像をとらえるツールですが、対象は明確にしなければなりません。

業務プロセスという観点で、自分たちが検討の対象にすべき境界を明確にしましょう。

 

自分のプロジェクトの役割や、責任と権限の範囲が「暗黙の了解」的に理解したつもりになっていて、社内外の関係者間、上司、顧客などと明示的に話し合って合意していないケースが多くあります。

例えば、自分には十分な権限が与えられていないのに、上司や依頼主が丸投げでやらせようとしているケースなどはないでしょうか?

そういったケースでは、SIPOCを描いた段階でそのプロジェクトがうまく行かないことが明確になりますので早期に対策をとることができます。

 

何をやるべきかを明確にするということについては、以下の記事もオススメです。

Webディレクションの作業領域

 

業務プロセスの境界を明らかにする上でのポイントは以下の6つです。

  • 業務プロセスの「呼び名」を定義する
  • 活動/作業を記述する
  • プロセスの全体を含める
  • プロセスの開始と終了を明らかにする
  • ここに定義したプロセスの全体をコントロールできるかを確認する
  • 課題/問題はプロセスの領域内にあるかを確認する

 

手順2.プロセスのアウトプットを明確にする

手順1で定義したプロセスが、何を創るのかをリストアップしましょう。

製品やサービス、書類、情報、ソースコードなど、何かしらのアウトプットがあるはずです。

現状のアウトプットのみをリストアップし、希望的なアウトプットや将来的なアウトプットは含めないようにしましょう。

 

手順3.顧客とその要求(VOC / Voice of Customer)を明確にする

手順2で定義したアウトプットを受け取る人をリストアップしましょう。

外部顧客だけでなく、内部顧客(経営陣、他部門、上司、チームの他メンバーなど)も漏れなくリストアップすることが重要です。

顧客が明確になったら、プロジェクトの成果として顧客が何を求めているかを再確認します。

アウトプットと顧客を1対1で関連付けて、それぞれのアウトプットが顧客の要求を満たしているかを確認しましょう。

この時点で、顧客の要求を満たしていないアウトプットは見直し、そもそも要求が存在しないアウトプットは無駄なアウトプットとして排除することで生産性を大幅に向上できます。

 

なお、顧客の要求は具体的かつ定量的に定義しなければいけません。

もし具体的かつ定量的な要求がSIPOC上に書けなければ、要求の確認から再スタートするべきです。

 

顧客の要求を明確にするために、以下のようなことを行いましょう。

  • どのように製品/サービスが使われているかを観察する
  • 自分で製品を使ってみる。顧客としてサービスを受けてみる
  • 顧客を調査する
    • 顧客は何を入手するか?
    • 顧客は何をしているか?
  • 顧客にインタビューする

 

なお、顧客へのインタビューを行う際は、「はい」「いいえ」で答えられる質問(クローズド・クエスチョン)は使わず、より多くの情報が得られる質問(オープン・クエスチョン)を使うと効果的です。

現在の要求だけでなく、顧客、市場、現在から将来への機会(チャンス)に目を向けて、将来の要求も探るようにしましょう。

 

手順4.プロセスへのインプットを明確にする

業務プロセスを開始するには、必ず何らかのインプットが必要です。

プロセスのアウトプットを作る上で必要なものをリストアップしておくことで、あとから必要な資源や情報がなくて作業が止まってしまうことを防ぎましょう。

インプットは、以下の6Mを参考にして考えると抜け漏れなく洗い出すことができます。

  • Man(人、人材、リソース)
  • Material(材料、情報)
  • Method(方法、道具)
  • Measurement(測定、評価)
  • Machine(機械、装置)
  • Mother Nature(環境)

 

手順5.インプットの供給者を明確にする

1つのインプットに対しては、必ず1つの供給者がいます。
手順4で必要なインプットが明確になったら、それはどこから手に入れられるかを考えましょう。

さらに、供給者に対してどのような要求をすれば最適なインプットを提供してくれるのかもあわせて考えます。
手順3で顧客の要求が具体的且つ定量的であるべきと書きましたが、同様に供給者への要求も具体的且つ定量的である必要があります。

 

SIPOC図の参考例はこちら

 

例: SIPOC (設計業務)

f:id:rkmrmt:20160728161359p:plain

例: 不動産会社用ホームページ作成会社

f:id:rkmrmt:20160728161351p:plain

 

f:id:rkmrmt:20160728161340p:plain

 

まとめ

業務プロセスには必ず始まりと終わりがあり、必ず前工程と後工程があります。
SIPOC図を書くことで、ビジネスの前後関係が明らかになり、プロジェクトにおいてやるべきことが明確になります。

プロジェクトの立ち上げ時はもちろん、中盤でプロジェクトに混乱の兆候が見えた際などにSIPOC図を描いて全体像を俯瞰してみてはいかがでしょうか?

 

▼その他のプロマネにおすすめコラムはこちら▼

WBSについておさらいしよう!

 

メンタルヘルス対策は大切です。

 

f:id:chitoseweb:20160211201842p:plain

プロジェクト管理ツール【マンモスプロジェクト / Mammmoth Projet】レビュー・評価・口コミ

プロジェクトマネジメント

f:id:chitoseweb:20160211201842p:plain

 

パラダイスウェア株式会社が提供しているプロジェクト管理ツール「マンモスプロジェクト」の商用版がリリースされたので早速使ってみました。

 

同社が主催しているプロジェクトマネジメント勉強会「マンモスアカデミー」に僕も先日参加させていただいたのですが、そこで代表の橋本将功氏がこだわったとおっしゃられていたのは「プロジェクトの見える化」。

当たり前すぎることですが、それを当たり前に行うことが難しいのはプロジェクトマネジメントに関わる方なら痛いほどわかっていることではないでしょうか。

 

プロジェクトの見える化の難しさは僕も日々の実務で感じているところです。

見える化が難しい理由は、大きく以下の2つに集約されます。

 

1.プロジェクトは生き物で、時間とともに変化する

2.プロジェクトは立体的で、見る角度によって姿が違う

 

マンモスプロジェクトでは特に、「2.見る角度によって姿が違うという点」を4つのビューによって解決するツールだなと実際に触ってみて感じました。

 

f:id:chitoseweb:20160712191758j:plain

 

マンモスプロジェクトの4つのビュー

マンモスプロジェクトには、以下の4つのビューが用意されています。

 

  • リスト
  • カンバン
  • プロジェクトマップ
  • スケジュール

 

リスト

f:id:chitoseweb:20160712094304p:plain

※スクリーンショットは公式サイトより引用しております。以下のスクリーンショットも同様です。

 

RedmineやBacklogをはじめ、各種プロジェクト管理ツールと同様の標準的なビューです。

 

カンバン

f:id:chitoseweb:20160712094318p:plain

 

カンバンビューは、株式会社スキップフォワードが提供しているタスク管理ツール【Jooto / ジョートー】が有名ですね。

Jootoは小規模なプロジェクトで以前私も使ってみたことがありますが、タスクのステータスが視覚的にわかりやすくとても便利でした。

ただ、ビューがカンバンのみであることから中規模以上のプロジェクトで膨大なタスクを管理するには向かないように感じています。

プロジェクト管理ツールというよりはタスク管理ツールで、個人や小規模プロジェクト、あるいは定型業務の管理にはマッチしそうです

※使ってみたのがだいぶ前なので、もしかするとその後改善されているかもしれませんが・・・。

 

マンモスプロジェクトにも同等のカンバンビューが実装されています。

マンモスプロジェクトでは、リストビューや次に紹介するプロジェクトマップビューと連携してカンバンビューが利用できるため、タスクが膨大な場合でもストレスなく活用できるのではと思っています。

この点は、引き続きもう少し使い込んでみながら操作感を試してみたいと思っています。

 

プロジェクトマップ

f:id:chitoseweb:20160712094334p:plain

 

これがマンモスプロジェクトの最大のポイントではないでしょうか。

各タスクの前後関係や並列関係が見事に見える化されます。

インターフェースもとてもよくできていて、ドラッグ&ドロップによって依存関係の設定が可能です。

これまでなかなかブラウザ上で表示できるツールがなかったスケジュールネットワーク的なものを表示でき、プロジェクト実務で重宝しそうです。

 

スケジュール

f:id:chitoseweb:20160712094401p:plain

 

日付を指定したタスクがカレンダー形式で表示されます。

ガントチャート表示ができないので一覧性という観点で少し残念ですが、そのうち機能追加されたらいいなぁ。

でも、ガントチャートは使えないと同社運営のメディアで言い切っているので、そもそもの設計思想として今後もガントチャートは提供されないのかもしれませんね。

なぜガントチャートはプロジェクトで使えないのか

 

気になる料金は?

料金はユーザー数ごとの課金で、1ユーザー500円/月です。

編集権限のない閲覧のみのユーザーの場合は無料で使えます。

 

最後に

マンモスプロジェクトは、クリティカルパスを可視化できるツールがこれまでなかったという不満がプロダクト開発の背景にあるそうです。

クリティカルパスやクリティカルチェーンマネジメントの重要性については本ブログでも何度か書かせていただいているところですが、確かにそれを現場でサクサク運用できるツールがないのが事実。

そういったマネジメント手法に関心のある方は、是非一度マンモスプロジェクトを使ってみてはいかがでしょうか?

 

クリティカルパスやクリティカルチェーンなどの管理手法に関心のあるプロジェクトマネージャーの方にはこちらの記事もオススメです。

▼▼▼

 

書評:クリティカルチェーン

 

CCPM / クリティカルチェーンプロジェクトマネジメント

 

工数見積もり

 

 

f:id:chitoseweb:20160211201842p:plain

ABテストは地道なPDCAとチームづくりが最重要!ABテストの壁を乗り越えてサイトの成長速度を最大化しよう

プロジェクトマネジメント

f:id:chitoseweb:20160211201842p:plain

 

こんにちは、編集部のジェシカです。

みなさん、ABテストできちんと成果を出せていますか?

 

ABテストというと施策内容や結果ばかりに注目しがちですが、運用体制を整えておかなくては、せっかく手間ひまかけて実施したのに何の効果や知見も得られなかった….という状況に陥ります。


今回は、ABテストで成果を出すために大切なポイントをご紹介します。

f:id:chitoseweb:20160711110136j:plain

 

そもそも、ABテストとは

ABテストとは、バナーやキャッチコピーから、画面レイアウトや遷移まで、課題になっている部分を改善する複数案を同時期に同条件で配信し、どのパターンが優れているか検証するテストのことです。

 

ABテストでよく使われるツールには以下のようなものがあります。

  • Optimizely(オプティマイズリ-)
  • KAIZEN PLATFORM(カイゼン プラットフォーム)
  • Visual Website Optimizer(ビジュアル ウェブサイト オプティマイザー)
  • Google Analytics(グーグルアナリティクス)

Google Analyticsは無料でテストが作成できるので、ひとまずABテストを始めてみたい方におすすめです。

 

ABテストで絶対に必要なPDCAサイクル

ABテストは、施策策定→ABテスト実装→結果検証→サイトへの実装というPDCAをしっかり回すことが大切 です。

 

思いつきでテストを始めたものの、結局何が知りたかったのかわからなくなることも多々あります。

ここでは、ABテストで押さえておきたいPDCAをご紹介します。

 

Plan / 施策策定

(テスト施策、改善指標、工数見積もり、スケジュール等)

 

サイトの課題を洗い出し、どの部分にどんな効果を見込むか、仮説を立てることが大切です。

仮説が曖昧なABテストは害悪と言っても過言ではありません。

テスト箇所は、ユーザーがアクションを起こす箇所(問い合わせ・会員登録ボタン等)に近い部分から始めるのがよいでしょう。

 

改善指標(KPI)を決め、各KPIでどれくらいの効果(例:ボタンクリック数2倍)が見込めるか予測しま す。

 

また、この段階でABテストの工数見積もりやスケジュールを把握しておきましょう。

スケジュールは、ツールへの実装・検証期間、テスト運用期間、結果検証期間を加味して作成します。

 

テスト運用期間をどれくらいにするかの判断は難しいところです。

トラフィックの多いサイトは「統計的有意性」(差の優位性等ともいます)が現れやすく、テストの決着がつきやすい場合がありますが、トラフィックが集まりにくい場合は、長い目での運用が必要になるからです。

 

統計的有意性がはっきり現れず、管理画面にあるグラフの動きが落ち着いているようでしたら、最長2週間でストップするのがオススメです。

私の経験上、2週間以上テストをして結果が逆転した!ということはあまりありませんでした。

ですから、テスト運用期間を最長2週間に設定しておけば余裕を持ったテスト運用ができると考えています。

 

テストの施策を立てたけど、実装できないということのないように、実現可能か確認しておくことも 大切です。

 

Do / テストの実装、公開

施策が決まれば、次はテストの実装です。 

複雑なシステムで作られたサイトの場合、実装や検証に意外と時間がかかることがあるので、その点も考慮しておきましょう。

 

検証は、動作確認だけでなく取得したいデータが取れているかも合わせて確認します。

ABテストツールはJSで処理しますので、既存のサイトのJSと競合してうまくデータが取得できなかったり、単純に設定ミスをしている場合があるので、すべてのKPIが取得できているのかを必ず確認しま しょう。

 

Check / ABテスト結果検証

テストが終了したら結果を元に、仮説と比較してどうだったか確認し、サイトに実装するかしないかの判断をします。

 

やってはいけないのは、コンバージョンに設定した指標の差が小さいのに、無理やり勝ち負けをつけてしまうことです。

結果は、統計的有意性を見て判断しましょう。優位性が低ければ、中間指標を元に判断するのもひとつの方法です。

仮説を見直して再テストという結論になることもあります。

 

経験上、単発で様々な箇所のテストを繰り返すよりは、1つの仮説に対して地道に別の角度からアプ ローチを続けるほうが、根本的な解決の近道になると思います。

アプローチを継続してもダメだったら、「その箇所は今後やらない」と判断できます。

テスト結果は、プロジェクト管理ツールやエクセルで管理しておきましょう。

何度もテストしていると何をやったか忘れてしまいがちです。

 

また、勝ちパターンや負けパターンをそれぞれソートして一覧化すると何かの法則が見えてくるかもしれません。

 

Action / サイトへの実装

テスト結果をサイトに実装する場合は、改めてサイト実装の工数を確認しましょう。

ABテストツールへの実装と、サイトへの実装は手法が異なります。

テストでよい結果が出ればすぐにサイトに反映できるとも限らず、もどかしい思いをするかもしれませ んが、その点も留意しておきましょう。

 

PDCAのサイクルは、早いほどサイト改善に直結します。

テストスケジュールをきちんと管理しながらテンポよく進めていきましょう。

 

ABテストの理想的なチームとは

上述したように、ABテストで成果を出すにはたくさんのプロセスがあります。

これを1人ですべて担当するのは難しく、チームでの役割分担が不可欠です。

 

最低限、プランナー兼ディレクター、エンジニア、デザイナーの3職種でチームを組むようにしましょう。

 

また、あまり肩書に偏って運用すると、エンジニアやデザイナーは「言われたことだけをやる」とい うスタンスになってしまいがちです。

せっかくのチームですから、施策策定や効果検証ではみんなで意見を出しあい、よりよいテストがで きるような関係性になれるとよいですね。

社内リソースが確保できない場合は、外部パートナーに参加してもらうことも検討するとよいでしょう。

 

※宣伝になり恐縮ですが、当社でもABテスト運用の支援をしていますので、ご興味ありましたらお気軽 にお問い合わせください。

■お問い合わせ先 → coach4pm@riso-labo.com

 

ABテストの壁

気軽にABテストを始めたけれど、行き詰まってしまった経験はないでしょうか。

  • サイトの負荷、不具合の発生を危惧してテスト配信を嫌がられる
  • 思いつきでテストの実装要望が集まり、収拾がつかない
  • テストの結果に有意差が出ない

ABテストは、うまく結果が出るテストばかりではありませんし、テスト自体を好意的に思っていない 人も中にはいます。

 

でも、サイトの成長速度を最大化したいなら、ABテストはとても効果的な手法です。

大変かもしれませんが、サイトをよくしたい!という志を強く持って周りを巻き込み、ABテスト っていいね!という空気感を作ってみましょう。

 

やりたい施策がたくさん集まってどうしたらいいかわからない時は、仮説や優先度(最終コンバージョンへの影響度)によって整理する、 テストの結果がうまく出ない場合は、テスト設計を仮説から見直す・中間CVを設けるなど、幅広い角度からアプローチし続けることが大切です。

 

PDCAの、特に「P」と「C」の部分に重点を置いて運用してみてください。

 

▼チームづくりに参考になる、おすすめのコラムはこちら▼

プロマネは好かれないとプロジェクトは上手くいかないのか?

 

プロジェクトメンバーの疲弊シグナルとは?

 

f:id:chitoseweb:20160211201842p:plain

「エンジニアはメンタルが弱い」なんて嘘!プロマネが行うべき3つのメンタルヘルス対策

プロジェクトマネジメント

f:id:chitoseweb:20160211201842p:plain

 

鬱や適応障害で休職を余儀なくされるエンジニアは少なくありません。

その原因を「エンジニアは元々メンタルが弱い生き物だから」と考えて、自分に責任のある問題ではないと開き直ってしまっているプロマネはいないでしょうか?

 

確かに内向的でコミュニケーションの苦手なエンジニアは多いので、非技術系の人間からすると、そう感じてしまうこともあるかもしれません。

 

でも、内向的であることとメンタルが弱いこととはまったく別の問題です。

内向的なエンジニアを見て、メンタルが弱そうという偏見をもってしまったら、それは本質が見えていないのかもしれません。

エンジニアが他の職種同様、あるいはそれ以上に抱えているプレッシャーを理解して、適切なケアをするようにしましょう。

エンジニアのプレッシャーを軽減し、気持ちよく働けるようにするのもプロジェクトマネージャーの職責です。

 

f:id:chitoseweb:20160702094403j:plain

 

リリースのプレッシャー

例えば、何ということはないメールフォームの改修リリースだったとしても、万が一ミスがあったときの影響範囲は甚大です。

問い合わせを獲得できなかった機会損失が全部その人の責任にされてしまいかねません。

<対策>

綿密なテスト計画を立案した上でそれに沿ってテストを行い、その結果をきちんと確認して責任を持ちましょう。

その上でリリース後に何かあれば、担当エンジニアの責任ではないということをちゃんと伝えるようにしてください。

 

24時間365日のプレッシャー

特にインフラ系のエンジニアが味わっているプレッシャーです。

時間を問わず監視ツールのアラートメールが届き、夜中にドキッとして目が覚める恐怖は半端ではありません。

営業系職種の方が、土日にクライアントから携帯の着信があってドキッとするのに近いものがありますが、それが24時間365日続いているようなものです。

<対策>

プロジェクトマネージャーがスケジュールをきちんと管理し、エンジニアがパソコンを持ち歩かず、携帯の電源を切って完全にオフになれる日を作るようにしましょう。

 

下流の不公平感

上流のスケジュールの遅れを吸収して頑張ったのに、不具合等が発生したら、下流工程を担当したエンジニアの責任にされてしまう理不尽なケースも少なくありません。

<対策>

下流工程のバッファが上流工程で食いつぶされないように、プロジェクトマネージャーは他部門やクライアントと戦ってでも現場のエンジニアにしわ寄せが行かないようにしましょう。

 

おわりに

エンジニアのメンタルヘルスは、エンジニア特有のプレッシャー等を理解しなければケアすることができません。

「エンジニアはメンタルが弱い」という偏見を捨てて、本質的なケアができるようになりましょう。

 

▼メンタルヘルス対策に悩むプロジェクトマネージャーには、こちらの記事もオススメです▼

プロジェクトメンバーのメンタルヘルス対策

 

女性メンバーのマネジメント

 

文系ディレクターのためのマネジメント

 

f:id:chitoseweb:20160211201842p:plain

WBSはプロジェクト管理の基本にして極意!PJを成功に導くWBS作成3つのポイントと注意点

プロジェクトマネジメント

f:id:chitoseweb:20160211201842p:plain

 

こんにちは、編集部のジェシカです。

 

今回は、既にご存知の方も多いと思いますが、改めてWBSについておさらいしてみます。

プロジェクトになくてはならないWBS。

きちんと作成・運用をしてプロジェクト炎上ゼロ「0」を目指しましょう!

 

f:id:chitoseweb:20160629120929j:plain

 

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標準があれば、安定したプロジェクト運用がしやすくなるでしょう。

 

▼プロマネの基礎を押さえるならこちらのコラムがおすすめです▼

PMBOKを現場に活かすには? 

 

CCPMとは?

 

 

f:id:chitoseweb:20160211201842p:plain

EVM - プロジェクトのパフォーマンスをリアルタイムに可視化する管理手法

PMBOK

f:id:chitoseweb:20160211201842p:plain

 

こんにちは、編集部のジェシカです。

EVMというプロジェクト管理手法は、プロジェクトマネジメントに携わる人なら聞いたことくらいはありますよね?

...実は私、聞いたことありませんでした。

...上司に「え、、、ジェシカ、EVMの概念も知らないの・・・。」

と言われました。

そんなわけで今日は、EVMについて調べてみたのでまとめてみました。


EVMは、Earned Value Management(アーンド・バリュー・マネジメント)の略で、「コスト」「スケジュール」 「品質等のパフォーマンス」に焦点を当ててプロジェクトのパフォーマンスを視覚的に管理する手法です。

f:id:chitoseweb:20160614124930j:plain

 

EVMの歴史

EVMは1960年代に米国国防総省の調達規則の一部として制定されたものが元となり、1990年代にクリントン大統領政権下で国家的プロジェクトのパフォーマンス改善のために改良されて発展してきました。 

国内でも、大手SIerが大規模プロジェクトでEVMによる進捗管理を必須にするポリシーを制定した事例があります。

 

EVMは非常に優れた管理手法なのですが管理コストが高く、大規模なプロジェクトでないと管理コストが効果を 上回ってしまうため、1億円以上のプロジェクトが一般的な目安です。

でも、「1億円以上」を見て「オレには関係ない」と思わないでください!

厳密にEVMを適用するとコストがかかりすぎますが、考え方を知って小規模なプロジェクトに活かすことはできます。

 

EVMを理解するために知っておくべき4つの用語

EVMを理解するためには、まず以下の4つの用語を理解しましょう。

 

・BAC(Budget At Completion):完了時総予算

プロジェクトが完了するまでに必要となる当初予算。

 

・PV(Planned Value):出来高計画値

成果物を期限内に達成するために必要なコストの時系列の計画値。

 

・EV(Earned Value):出来高実績値

一般的には出来高と言われ、作業により完了した一定時点の実際の価値。

 

・AC(Actual Cost):出来高実績コスト

作業で実際にかかった一定時点のコスト。計画どおりに進んでいれば、PVと同じ数値になります。

 

EVMでは、これらの数値をグラフにして、計画と実績値の差を視覚的に表現します。

そして、計画値と実績値の乖離が許容範囲を越えたらすぐに手を打つことで、「発覚したときにはもうリカバリできない状態になっていた」という最悪の事態を防ぐことができるのです。 

一般的なWBSはスケジュールに焦点をあてた管理ですが、EVMは「コスト」「スケジュール」「品質等のパフォーマンス」の3つの観点で総合的にプロジェクトを管理できます。

 

EVMを勉強しながら、実際にやってみた方のスライドがとてもわかりやすかったのでご紹介します。

 

www.slideshare.net

 

計画と実績の乖離をリアルタイムで把握するのがポイント

EVMを実際のプロジェクトに適用するハードルは高そうですが、参考にできるところはあります。 

開発が遅れてスケジュールが伸びそうになったときに、なんとか間に合わせるために「自分が無理をすればいけ る」と誰かが長時間残業をしていませんか?

そのようになるのはたいてい、問題に気づくのが遅いことが原因です。

 

EVMの考え方を応用して、今の時点で何がどこまでできていればよいかきちんと把握しておけば、そのような 事態を予防できます。

そのためには、より細かい粒度でWBSを作成して工数見積もりを行い、デイリーで進捗をウォッチするとよいでしょう。

 

▼プロジェクト管理には、こちらの記事もおすすめです▼

PMBOKを現場で活かそう

  

スケジュール管理をしっかり!CCPMとは?

 

f:id:chitoseweb:20160211201842p:plain