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

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

可視化された課題に向き合うことで逃げずに解決へ向けた行動を取れた(ビジネスコーチング体験談)

こんにちは。東京でSEO屋を営んでおります、株式会社ユナイテッドリバーズの岡崎です。 役員2名、スタッフ2名の小所帯で日々Google先生に振り回されております。

2月から7月にかけて、coarch4pmのコーチングを6回受講しました。 本稿では、受講を通じて変化した行動や感想についてつらつらと書き連ねていきます。

初回にも感想を寄せているので、そちらから読みたい方は下記のリンクをどうぞ。

コーチング体験談

f:id:okachan_man:20160911184945j:plain

ビジネス的課題をコーチング的アプローチで解決するサービス

そもそもcoach4pmって何やねん、というお話。

コーチングという言葉を耳にしたことのある方は多いと思いますが、具体的な内容を知っている方は少ないんじゃあないでしょうか。また、知っている方も、マネージャー研修等々で「部下を教育するための手法」として学ぶケースがほとんどではないかと思います。

しかし、coach4pmが提供しているのは、「コーチングができるよう指導する」サービスではなく、「サービス利用者のビジネス的課題をコーチング的アプローチで解決する」サービスです。コーチとのセッションを通じて課題や打ち手を明確にし、それによって行動を改善するというわけですね。

私が受けたのは、コーチとの1時間のセッション(Skype面談)を月1回程度、合計6回受講するコースでした。

もやもやしていた課題が可視化されてすっきりする

人によって状況が異なるので話す内容も変わると思うのですが、私の場合はいま直面している課題の棚卸しと、それに対する打ち手の素案、打ち手の進捗状況の報告を毎回行っていました。

方向性が迷子になってるな…というときは、中長期の目標を改めて確認したり、というかんじです。3年後の事業規模だとか、その時点でどんな事業構造にしていたいかなどなどですね。

こういう話はもちろん社内でも行うんですが、利害関係者同士で話すと遠慮が生じてしまったり、熱くなって客観性を欠いてしまったりするので、完全な第三者に向かって話せる場は貴重でした。

いや、居酒屋などで友人に話すこともゼロではないですが、真剣に耳を傾けてくれる人なんてめったにいないですし、的外れなアドバイスをされて逆にストレスを貯めてしまうことのほうが多い気がします(笑)。

その点、coach4pmのセッションでは、コーチが可能な限り主観を廃した質問で課題や打ち手を引き出してくれるのでノーストレスでした。セッションの後にはもやもやと悩んでいたことが可視化されて精神的にかなりすっきりします。

可視化された課題に向き合うことで、逃げずに解決へ向けた行動を取れる

課題と打ち手の可視化も大きな収穫だったのですが、それ以上に大きかったこととして、後回しにしてしまいがちだった課題に対して、逃げずに解決へ向けた行動を取れるようになったことが挙げられます。

私が抱えていた課題をまとめると、「スタッフや外注さんへの指示・教育体制の強化」でした。コーチングで可視化する以前からぼんやり問題に感じていたのですが、ひたすら後回しになり続け、ずっと手を付けられていない状況が続いていました。

進められなかったのはひとえに私の怠慢が原因です。クライアントワークは進めなければ売上が立たなくなってしまうので、どんなにやる気がわかなくてもやらざるを得ません。一方、社内改善にはそうした推進を後押しするプレッシャーがありません。長い目で見れば損失を生んでいるのですが、浅はかなもので、ケツに火がつかないとなかなか腰が上がらないんですよね…。

その状況を変えてくれたのもコーチングです。coach4pmのコーチングでは、セッションごとに「次回までにやっておくことのコミット」と「進捗報告」の2つを行います。何も進捗していないと、コーチングのたびに「あれもやっていません。これもやっていません」となってしまい、非常に気まずくなります(汗)。

これを避けるために、セッションが近づくたびに慌てて宿題としてコミットしていたことを片付けていたりしました。コーチとの約束が、納期・締め切り的な機能を果たすわけです。

では、実際にどんな改善を行ったのか、2つほどご紹介します。

改善1.Backlog(バックログ)によるタスクのチケット管理を開始

「なんだ、そんなことか」と思われるかもしれませんが、弊社にとっては画期的でした。

弊社はリモートで働いていることが多く、勤務時間もバラバラだったりするため、指示や申し送りにかなりの工数が取られていました。チャットが流れてしまって抜け漏れが発生する…といった事故もしばしば。手間もかかるしストレスもたまる状態でした。

そこであるとき一念発起し、社長と二人でほぼ丸一日かけてタスクを洗い出し、Backlogに投入。チケット管理の経験はほとんどないので、チケットの粒度は後述の記事を参考に、4つの原則に沿って作りました。

  • 作業はとにかくチケットに起票。起票されていないものはやらない
  • 必ず、ボールを持っている人を担当者に設定する
  • 完了基準を決める
  • その他細かい設定は最初からしない
参考記事:

Redmine

また、はじめから100%うまくいくはずもないので、問題が生じたら後から直せばよいという方針にしました。完璧を求めるとしんどいですからね…。

まだ運用開始から3~4ヶ月ほどで改善ポイントも多いのですが、これのおかげで業務指示の工数は大幅に削減され、抜け漏れも激減しました。チケット管理尊い。

f:id:okachan_man:20160911185545p:plain
出典:Backlog

改善2.マニュアル類の整備

Backlogの導入に合わせて、業務マニュアルの整備にも力を入れました。それまでは口頭やチャットで場当たり的に業務を教えていたのですが、同じやり取りを何度もしていたり、指示の抜け漏れが発生したりと非効率でした。

そこで、繰り返し行う業務についてはGoogleドキュメントやBacklogのWikiにマニュアルを残すようにしました。教えるときはそのURLを伝えて、不明な点を質問してもらえばよいのでやり取りがかなり楽になっています。

また、頻出しそうな質問はマニュアルに反映し、なるべく同じ質問がまた発生しないようにしています。

おわりに

コーチングを通じて改善できたことはまだまだたくさんあるのですが、業務内容に思いっきり踏み込むので書きづらいところもあり、これくらいとさせていただきます。

繰り返しになりますが、外部のプロにコーチングを頼む最大のメリットは、利害関係のない第三者を相手に壁打ちをすることで、抱えている課題を冷静に俯瞰し、打ち手を考えられる点だと思います。上司だろうと部下だろうと、そうしたフラットな立場で相談できる相手を持っている人はそうそういないでしょうし、その人がコーチングのスキルを持っているケースはいっそう稀でしょう。

仕事に行き詰まりやもやもやを感じているけれど、誰に相談してもいまひとつよい答えにたどり着つけないという方は、コーチングを試してみるとよいかもしれませんよ。

プロジェクトに課題を抱える管理職の救世主!coach4pmのコーチングの効果

f:id:chitoseweb:20160211201842p:plain

 

こんにちは、ジェシカです。
以前、こちらの記事でコーチングとは何かをご紹介しました。

media.coach4pm.com

”コーチングとは、専門的なトレーニングを受けたコーチとのセッションの中で、目標設定と現状分析を定期的に行いながらリーダーシップや課題解決力を養成する人材開発手法です。”

 
coach4pmが提供しているプログラムについてもご紹介していましたが、今回はより詳しくお伝えします。 

管理職やリーダーになったものの、メンバーがついてきてくれない、業績目標が達成できないなどの悩みを抱えている方や、これから管理職を目指す方におすすめです。

f:id:chitoseweb:20160831174026j:plain



目次:coach4pmのコーチングプログラム

コーチング型リーダーシップ研修

大量生産中心だった時代の指揮・命令の一元化、垂直コミュニケーションを基軸としたトップダウン型のマネージメントだけでは、価値観が多様化して変化のスピードが増加した現在では機能しなくなっています。

リーダーの判断と指示を待っていては、変化の速度について行けませんし、1人のリーダーの経験と知識だけでは正しい判断ができません。
つまりトップダウン型の権限だけではメンバーを機能的に動かすことができない時代になっています。

今求められるリーダーシップは、権限で人を動かすやり方だけではなく、メンバーと積極的に関わりながら影響することでメンバーを動かすマネージメントのやり方です。

メンバーに影響することで自発的な行動を促すスタイルのリーダーシップを「コーチング型リーダーシップ」と呼びます。

f:id:rkmrmt:20160830183558j:plain

コーチング型リーダーシップ研修では、下記を習得することが期待できます。

  • コーチング型リーダーシップとは何か
  • コーチング型リーダーとしての振る舞い
  • コーチング型リーダーに求められる要件
  • コーチング型リーダーとして何を目指すか

マンツーマンのコーチングプログラム

ここでは、各役職で抱えがちな課題を踏まえてcoach4pmのコーチングプログラムをご紹介します。

【部課長向け】マネージメント・コーチング

部長職や課長職などの中間管理職層は、上層部のマネージャーから与えられたミッションを達成するために意思決定を行い、部下やメンバーのモチベーションを高く維持しなければいけません。


新任部長・新任課長・中堅社員の課題

新任部長や新任課長、中堅社員の方は、こんな悩みをお持ちではないでしょうか。

入社以来、上司の命令にノーとは言わず、期待に応える事だけを考えてきたので、上司からの指示が無いと自分のありたい姿が描けなくなっています。 

 

目の前の仕事の方が気がかりで、ワクワクするような自分の未来の姿を想像できません。こんな状況なので、5年後のキャリアなんて考えることができません。 


このような課題を抱えている方は、コーチングで以下のような効果が期待できます。

  • 本当にありたい姿を発見できる
  • 今何をすべきかが見えてくる
  • 自分が納得して判断出来るようになっていく


R&D部長・課長の課題

研究・開発職として業務に没頭してきた人が、ある日マネージメントを任されるということもあります。

研究開発業務だけでも手一杯なのに、部下の面倒を見るなんて・・・と考える人も多いそうです。

例えば、こんな課題があります。

これまで研究者、開発エンジニアとして文献や開発ツールを相手に仕事をしてきましたが、人を相手にして研究開発チームをマネージメントしなくてはならなくなりました。人は開発ツールの様にコマンドを入力すれば期待する結果を出力してはくれないもので・・・

 

人の心は目に見えるものではありませんし、扱いを失敗すると復活できないこともあります。

そんなときこそコーチングの出番です。

コーチをつける事で部下とのコミュニケーション手法の糸口がつかめるかもしれません。

コーチングセッションは、人とのコミュニケーションを円滑にするための第一歩です。コーチと話す事で、自分の感じること、部下の感じることをあなた自身が気付けるようになります。
研究開発職は部下であっても、皆がそれぞれの分野の専門家です。
トップダウンで手足として使うマネージメントは機能しません。

チームとして共通のターゲットを目指しつつもメンバー個々の才能を最大限に発揮してもらうマネージメントこそが、イノベーションを生むチームに求められているスタイルです。

コーチング型リーダーシップを身につけることで部下とビジョン、目的、ゴール、目標を共有できるようになるだけでなく、部下のモチベーションを高く保てるようになります。

また、研究開発の価値や課題を正しく理解して貰うことは非常に重要ですが、とても難しい事でもあります。
なぜなら、最先端の研究テーマや最先端の技術は、他の人の理解の限界を超えているからです。
コーチをつけることで研究開発の価値や課題を理解し、自分がどう行動すればよいかがわかるようになります。

【PM・PL向け】プロジェクト・コーチング

プロジェクトリーダーは常にプロジェクトの達成目標を明確にして、チームメンバーの能力を最大限に引き出し、プロジェクトを成功して終了させなくてはいけません。

coach4pmでは、プロジェクトの迷走を防止し、最高の結果を導き出すためのコーチングを行います。

<お悩み事例>

●事例1 
プロジェクトが計画より遅れてしまい、プロジェクトチームのモチベーションは下降気味でした。
ミーティングは進捗確認だけの一方的なコミュニケーションが多くなり、PMとして、こんな時こそチームのモチベーションを向上させなければならないのにと思いながら、実行できません。

【コーチングでは】
ミーティング・マネージメントを行い、メンバーとのコミュニケーションを双方向にします。

 

●事例2
顧客が価値を感じ本当に欲しいものは何か?課題は何か?といった情報を、プロジェクトメンバーにうまく伝えられずにいました。
メンバーが共通認識を持つために、どんなふうに情報を共有すればいいのかいつも悩んでしまいます。

【コーチングでは】
メンバーや顧客とのコミュニケーションを、より目的達成の方向へと導きます。

●事例3

完璧な計画を立てても、成功するとは限らないプロジェクト。
メンバーのモチベーションが維持できず、プロジェクトが失速することもありました。リーダーとしてメンバーからの信頼を獲得したいのですが、モチベーションを維持させるような発言、振る舞い方がわからず悩んでしまいます。

【コーチングでは】
リーダーとしてのライフバランスを整えられるように導き、メンバーにとって頼りがいがある、魅力的なリーダーになることが期待できます。

coach4pmのコーチングの流れ

ここでは、コーチングがどのような流れで進められていくかをご紹介します。

1,オリエンテーションの実施

<オリエンテーションの目的>
・コーチングの内容や進め方について紹介し、疑問に思う所があれば明確にします。
・コーチ(コーチングの相手)、を見ていただき、コーチングを始める前の準備を行います。

<方法>
・基本的に対面で行い、所要時間は1時間程度です。
・面会場所(東京都近郊)はクライアントに指定していただきます。

料金は無料です。

2,契約について
・クライアント
コーチングを開始するという合意が取れたら、「コーチング契約」に署名をします。

・コーチ
「コーチからあなたへの約束事項」に署名をします。

3,コーチング・セッションの開始
会社での課題をテーマにコーチングを行います。

【課題例】
ビジョンと目標設定、部下へのモチベーション面談、アサーティブ・コミュニケーション、ステップアップ、ライフバランス向上 など。

クライアントとコーチが一対一で行うコーチングで、基本的に月2回、1回50分間行います。

対面で行う場合は、クライアントに面会場所を設定して頂きます。電話もしくはSkypeで行う場合は、クライアントからコールしていただきます。

4,継続/終了の確認、最終評価

クライアントがコーチングの継続または継続の判断を行います。

コーチング・セッションは6回以上継続する事を推奨しますが、クライアントは契約期間中いつでもコーチングの終了を行うことができます。


●まとめ

少し長い記事になってしまいましたが、コーチングの種類やコーチングで習得できる効果について理解していただけたでしょうか?

無料トライアルも実施していますので、「こんな悩みでも解決できるのか?」など疑問があれば、まずは問い合わせページから質問をしてみてください。

こちらのページに、詳しいプランや料金体系を掲載していますのでぜひご覧ください!

coach4pm.com


▼コーチングに興味を持ったあなたに、おすすめのコラム▼

コーチングの受講感想 

coach4pm誕生秘話

 

f:id:chitoseweb:20160211201842p:plain

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

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