顧客の目線に立った価値提案を学ぶ「カスタマージャーニーマップ」
先日、某若手社員からこんな相談がありました。
「全く接点がない新しい顧客へのアプローチ方法がわからない」 「営業の各個人にやり方があるが、それぞれのやり方でやっていてノウハウがわからない」 「自分で考えているが世の中の正しい方法がわからない」
そこで感じたのが、営業やマーケティングがいわゆる"暗黙知"になってしまっていること。 営業を体系的に教育することは果たして難しいことなのでしょうか?
問題は、営業としてのセオリーやノウハウが経験に裏付けされているという点です。
裏を返すと「経験がないとセンスや感覚で仕事をするしかない」という状態になってしまっているのでは?と思います。
ただ、私は営業職ではないので、残念なことにその"経験"を持ち合わせていません。
一方で、世の中のベストプラクティスや方法については調べれば出てくる便利な状態です。 そこで今回はそんな若手社員と行った「カスタマージャーニーマップ」についてまとめてみようと思います。
参考はこちらの書籍。
はじめてのカスタマージャーニーマップワークショップ(MarkeZine BOOKS) 「顧客視点」で考えるビジネスの課題と可能性
- 作者: 加藤希尊
- 出版社/メーカー: 翔泳社
- 発売日: 2018/09/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
カスタマージャーニーマップとは
カスタマージャーニーマップとは「顧客の行動、感情などを分析して、どうすれば自社のサービスが受け入れてもらえるかを体系的に考える手法」です。
具体的にはこのあと説明していきますが、「行動」「思考」「感情」の変化を追うことで「接点」や「打ち手」を整理するものです。
最終的なアウトプットのイメージはこんな感じです。(ちょっと業務に寄っちゃってるのでモザイクを・・・。)
では、実際にどんなステップで作成していくのか見ていきましょう。
Step1:テーマを決める
ここでは以下の項目を考えます。
- 今回のテーマ
- 今回の対象とするサービス
- スタート(ジャーニーの始まり)
- ゴール(ジャーニー完了時点のなっていて欲しい状態や状況)
- スタートからゴールまでの期間
これらは後のすべての状態に関わってくる重要な情報です。 「顧客がそのサービスを導入していること」がゴールなのか「それぞ使いこなして効果を感じていること」がゴールなのかなどそのプロダクトやサービスの目指すべきビジョンと照らし合わせて考えます。
Step2:ペルソナを設定する
ペルソナとはマーケティング用語として有名な言葉なので、営業の方はよく知っていると思いますが、「想定するターゲット像」を意味します。
ただ、「なんとなくこんな感じの人」ではなく部署、名前、年齢、決済可能予算額、性格、部下の数など、実際の顧客のような人物像をイメージします。
Step3:行動を洗い出す
次にスタートからゴールまでのペルソナの行動を洗い出します。 まずは思いつく限りたくさん行動を書いて、それを整理します。
ここでペルソナが活きてくるわけですが、今回のサービスを決済できるような権限を持っているのか否かで社内稟議など社内の事務手続きと共有、説得作業が伴うと思います。 この辺りの細かい部分こそが顧客が手間に思っている可能性があるリアルな部分なので、"いかにリアルに書くか"がこのステップの肝かもしれません。
Step4:行動をステージに分ける
次は各行動の塊を"ステージ"というカテゴリに分けます。 ある程度ステージ分けができたら、大きな流れを把握し、足りない行動を付け加えます。
このステージの塊がこの先の顧客との接点に大きく関わります。
Step5:感情の起伏を想像する
このステップでは、自分の気持ちを殺してペルソナの気持ちになりきります。 具体的には"顧客が何を感じ、どんな課題を抱えているのか"に焦点を当てて考えます。
Step6:顧客接点と自社の行動を名確認する
ここでは、各顧客の行動時の自社の行動や顧客との接点を明確にします。 その方法には「ツールを介した接点」や「人を介した接点」などいろんな要素が含まれます。 これを包み隠さず洗い出していきます。
Step7:対応策を考える
最後に、このジャーニーで課題になる部分の対応策を考えます。
主に
- 感情がネガティブになっている部分をどうポジティブに変えるか
- 縦軸で見たときの課題をどう解決するか
- 横軸で見てスピードが落ちそうな点、顧客が面倒に思う点をどう軽減するか
など、これまでに可視化できている部分を元に解決するための打ち手を洗い出します。
Step8:視点を変えてアイディアを追加する
最後に全体を眺めて、
- 「このジャーニーの期間を半分にするには?」
- 「このジャーニーの成功確率を上げるには?」
などを考えてみます。 さらに完成したジャーニーを元にタスクまで落とし込みができると次のアクションにつながります。
やってみた結果がこちら
やってみるといろんな気づきがあります。 そして、各自の脳内にはあっても共有できてなかった部分を共通認識にすることができます。
詳細はぜひ、こちらの書籍を参照してみてください! もしくはいつでもお声がけください!
はじめてのカスタマージャーニーマップワークショップ(MarkeZine BOOKS) 「顧客視点」で考えるビジネスの課題と可能性
- 作者: 加藤希尊
- 出版社/メーカー: 翔泳社
- 発売日: 2018/09/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
私がPMPを受けるワケ
突然ですが、今年はPMPを受験しようと思ってます。
PMPはご存知の方々もいらっしゃると思いますが、PMI本部が認定しているプロジェクトマネジメントの国際資格です。 めっきり、アジャイルにのめり込んでる私はこれまでCSPO研修を受け、CSPOを取得しました。
そんな私がなぜこのタイミングでPMPを取得するのか。既定路線のようにも見えますし、なんでそっち?と思う方もいると思います。
ただ、私なりの意志と目的が似ている境遇の人にも参考になればとまとめてみようと思います。
CSPOを取得してからの1年
私がCSPO研修を受講してから、約1年が経過しました。 約20万円とそれなりに大きな投資。新卒の初任給の手取りとそう変わらない投資です。
ありがたいことにこの20万円という金額を会社に出していただきました。未だに感謝してもしきれません。 つまり、私がCSPOを取得するということに対して3日間の研修期間と20万円という投資をするだけの価値があると認めてもらったワケです。
そのため、私はこの1年間、私に対するこの期待に誠心誠意答えることが最低限の恩返しだと心に刻み活動してきました。
具体的にはこのブログにもつらつらと書いてきましたが、
- カンバンやスクラムのセレモニーを通じた可視化
- チームビルディングや社内勉強会の立ち上げによる風通しの良い文化の構築
- インセプションデッキやユーザーストーリーマッピングを活用したプロジェクトの前進
- 新卒や学生インターンへの参画
我ながら、CSPO取得にかかった大きな投資に対する答えを出してきたと思っています。 そして、周りも認めてもらっていると自負があります。
仕事で評価してくれる人々と箔で評価をする人々
一方で今年30歳になる若造がどんなことをしても全く響かない状況にも少なからずぶつかりました。 平社員の私がいくら騒いでも、宣言しても声が届かない場所がまだまだあります。
端的にいうと箔があるとないとで、同じことを言っても効果がまるで違うことが多いワケです。
これは社内でも社外でもどちらでも起こり得ます。
では、その箔とは何か。 役職であり、資格であると私は考えます。
ここで誤解がないようにお話ししておくと、全員が全員箔を見て動いてるとは微塵も思いませんし、私も箔で評価されるのは不本意です。 ただ、影響力を広げているうちに箔がないと越えられそうにないラインに多く出会うようになりました。 そしてそれを迂回するたびにまた同じような箔にぶつかることがあり、影響力の速度がどんどん落ちていくような感触を感じています。
ちなみに、仕事で評価してくれるか、箔で評価するかには年齢は関係ないと思っています。働き方や考え方に寄ると感じています。
悲しくとも…自分に箔をつける
私はこのような箔で評価されるような方法は嫌いです。 そして、名刺に多くの箔を塗ったくって誇らしげに生きている人ほど疑わしいものはないとさえ思っています。
しかし、私の目標である「映像業界の働き方を、チームで働く業界に変える」ことを実現するためには 少なからず、今より大きな影響力と発言力が伴わないことには始まらないと思っています。
そのためには箔で評価するような人々にも認めてもらえるような実力と箔をつける必要があります。
ただ、スクラム、アジャイルどころかウォーターフォールという言葉すら馴染みがない非IT業界には、 "CSPO"という認定でさえも相手にしてもらえないことが多いのです。
そのため、PMPを取得して、「この若造は、プロジェクトマネジメントをちょっとはわかるようだな。話くらいは聞いてやるか」と まずは土台に乗せてもらうことを一つの目標にしたいと考えます。
もう一つの私が進めたい本当の理由
・・と、ここまで悲しくもドロドロとしたネガティブな理由を述べてきましたが、これだけではありません。 というより、PMPを取得することで映像業界をよくする可能性がさらに広がると考えています。
実は映像業界、いやどの業界にも"プロジェクト"は想像以上にあふれていると感じています。
- 顧客にサービスを導入してもらうためのプロセス
- 作品を企画から完成まで持っていくこと
- 1ヶ月での作業量を大きく増やすための効率化
- 採用活動
全てプロジェクトです。そしてこの業務を毎日のようにハンドリングしている人はプロジェクトマネージャーであり、プロジェクトマネジメントを自然と行っています。
ただ、それに気づいていません。なぜなら、"プロジェクトマネジメント"という言葉も、分野も知らないからです。 そのため、自分の仕事のベストプラクティスや参考にできる方法も見つからず「自分の仕事は特殊だ。」と決めつけて属人化し、疲弊していきます。
つまり、「あなたの仕事はプロジェクトマネジメントです!こういう方法が参考になるよ!」と発することができるといかがでしょうか? 少し、彼らに光を注ぐことができるのではないでしょうか?
ただ、これ自身も「いやいや、何を適当なことを言っているんだ」と言われかねないと思います。 なので、「プロジェクトマネジメントのプロの私が断言します!」と言えたらどうでしょう?
「なんとなく、信じてみようかな」と思ってもらえるかもしれません。
そのためには、プロジェクトマネジメントのなんたるかを学び、堂々と「私はプロジェクトマネジメントのプロです!」と言えるようになることが必要でしょう。
教えてください!
というわけで・・・「PMPを取得する!」と宣言はしたものの、まだこれからの挑戦です! そのため、オススメの勉強法や教材、通信講座などぜひ教えていただけたらと思います。
AWS構成図自動作成ツール比較 ~CloudMapper編~
注意事項
このエントリーは2019/1/25時点の情報です。 検討する際は、最新の状況を確認してください。
現状検討できる選択肢
主に下記が選択肢として上がります。
今回は Cloud Mapperを試してみました。
Cloud Mapperとは
- AWSの構成図を自動で作成できる
- 無料で使える(Githubで公開されている)
- 新しい。結構盛んにやり取りされている
- First Commit :2018/1/20
- Commit件数:299
- issue件数:86
- 最終Commit:2日前(2019/1/25時点)
検証対象、環境
- 今回はMacのローカル環境で実行しています。
導入手順
リポジトリをクローンする
$ git clone git@github.com:duo-labs/cloudmapper.git
必要なものをインストール
$ brew install autoconf automake libtool jq awscli pyenv pipenv
Python3のインストール(導入済みの方はスキップしてください。)
- python 3 (3.7.0rc1 is known to work)とのこと
pyenvのパスを通す
$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile $ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile $ echo 'eval "$(pyenv init -)"' >> ~/.bash_profile $ sourcce ~/.bash_profile $ which python
- pyenvの場所を参照して入ればOK
pyenv で Pythonをインストールする
$ pyenv install 3.7.0 $ pyenv rehash
使うPythonを指定
$ pyenv global 3.7.0 $ python --versions * 3.7.0が選択されていればOK
pipenvをインストール
プロジェクトディレクトリに移動
$ cd cloudmapper/
pipfileインストール
$ pipenv install --skip-lock
シェル起動(仮想化)
$ pipenv shell
設定ファイルコピー
$ cp config.json.demo config.json
設定ファイルの編集
- config.json
{ "accounts" : [ { "id" : "123456789012", - "name" : "demo", + "name" : "[~/.aws/credentialsに記載する環境名]", "default" : true } ], "cidrs" : { "1.1.1.1/32" : { "name" : "SF Office" }, "2.2.2.2/28" : { "name" : "NY Office" } } }
AWS Credentialsの設定
$ vi ~/.aws/credentials
- credentials
[環境名] aws_access_key_id = ****************** aws_secret_access_key = **********************************
実行
AWSから情報取得
$ ./collect_data.sh --account [~/.aws/credentialsに記載する環境名] --profile [~/.aws/credentialsに記載する環境名]
解析実行
$ python cloudmapper.py prepare --account [~/.aws/credentialsに記載する環境名]
構成図描画の為に,CloudMapperのサーバを起動する
$ python cloudmapper.py webserver CloudMapper serving on 127.0.0.1:8000
描画結果を確認
- 127.0.0.1:8000にアクセスする
- 実際の出力結果がこちら
所管
良い点
- 導入が簡単。
- アイコンも公式なのでわかりやすい
- 自分で追加編集ができそう
微妙な点
- 現状集められるリソースが少ない - VPC - AZ - subnet - EC2 - RDS - ELB - ALB - security - network interface - VPC peering
→ ただ、issueがたくさん上がっていて活発なので、時間の問題かも * 繋がれる線の並びが見辛い
次回予告
次はCacooを試してみます。
5分間ワークショップの舞台裏を公開!
昨日、こちらのイベントにLT(5分)枠で参加させていただきました!
運営の方々を始めとしたみなさん、ありがとうございました!
さて、その5分間のLTで無謀にもワークショップをやっちゃいました!
おかげさまでいくつか反響もいただきました。
5分でワークショップはすごすぎる #sdevtalks
— 岡 花太郎 (@hanataro_ym) 2019年1月22日
はちさんのLTワークショップやべえ。すごい。 #sdevtalks
— Yoshiki Iida / CrowdWorks Inc. (@ysk_118) 2019年1月22日
それにしても話すの巧すぎん? #sdevtalks
— すぱこー@エオルゼア新住人 (@SpicyCoffee66) 2019年1月22日
ということで、このLTをやるに至った舞台裏をまとめてみようと思います。
思いつき
- LT(5分)でワークショップってできるんだろうか?という疑問から挑戦
- テーマは「採用」なので、きっと「どうマッチングするか」という話が多いと想定
- 一方で「面接などに来てくれた人がいかに普段のパフォーマンスを発揮してもらえるか」も重要なので、これを伝えたい
- ここ最近、新卒インターンシップで行なったアイスブレイクが自分なりにかなりしっくり来ていた。
- 上記よりアイスブレイクの重要性をテーマに決定
- フレームとして1分sprint×4 +バッファを想定
・1sprint目:導入
・2sprint目:ワーク1
・3sprint目:ワーク2
・4sprint目:ふりかえり、定着
資料作成
- ワークショップの内容が「タイムボックスを区切ることが重要」という側面があったので、フラッシュスライド形式でファシリ側もスピード感を出すことを想定
- 5分間でパッパッと変わって行くので難しい単語や専門用語は極力排除。瞬時に理解できるような構成に
- 導入は時間を出来るだけ短いので自己紹介は写真中心
- 「他にも知りたい!」と思ってもらえた後のアクションを提示するために次回のイベントへの誘導で締める
- ちなみにできて資料がこちらです。
www.slideshare.net
場づくり、実践
- 内容的に場が温まってるほど成功するので、登壇順番は後ろ目に(いつもはトップバッターが好きだけど!)
- 一番重要。冷めきった空気だとお見合いになってしまうので一言目から空気を変える勢いで明るく
- 突然始めるとみんなワタワタするので、PCを接続しながら「これからワークショップやりますよ!机の上倒したりこぼさないように準備してくださいね!」と予告
- 準備してもらってる様子を見ながら温度感を確認
- 「え?なになに?」と言いながら笑顔が多く、協力してくれそうな雰囲気を察する(ひとえに運営の方とそれまでの登壇者の方々の場づくりの賜物)
- 導入からちょくちょくふざける。笑いを取りに行く(これはわりと好き)
- ワークの説明は簡潔に。
- 徐々に声のトーンとボルテージを上げて「いよいよやるぞ!」感を演出
- ワーク開始!一気にコミュニケーションが加速。場の声量も最大に。いい感じ。
- ワーク1の終了と同時にリアクションを見る。笑顔が多く良さそう
- そのままテンションが冷めないようにこちらのボルテージを最高潮に持っていき、2つ目のワークに流れで突入
- テンション上がって「スタート!」って言いながら指を鳴らしてた気がするw
- ワーク終了!それなりに盛り上がっていて、登壇スペースから近い人を探す(ワーク中に目星をつけておく)
- 「どんなチーム名になりました?」と聞く。ここまで来たらもう何が出てもだいたい面白い。そういう空気ができてる
- 最後にふりかえり。「ふりかえり」という言葉を今回はあえて使わず、「解説」とした。その方がイメージに合ってたのとワークは終わったと理解し、聞き入りやすいかなと判断
- 解説は冷静に、みんながうなづけるようにアイコンタクトを積極的に
- 1つの行動ごとにその意味を解説。
- 自身でも実践してもらいやすいように、ハードルが低いことをアピール
- 最後に宣伝をして、興味を持ってくれた方を引き入れる。そして次のアクションへとつなげてもらう道しるべとする
最後に
こんな感じで考えた内容をワークショップとしてやらせていただきましたが、自分なりにもかなり楽しくできました!
もし、
- うちでもやってほしい!
- 他の話も聞きたい!
などあったらお気軽にお声がけください!
そして、直近ではここでお話しする機会をいただきました!
こちらにも是非お越しください!
書評:「プラットフォーム革命 ~経済を支配するビジネスモデルは、どう機能し、どう作られるのか~」
今日はプロダクトマネージメント寄りの書評です。
読んだ本はこちら!
プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか
- 作者: アレックス・モザド,ニコラス・L・ジョンソン,藤原朝子
- 出版社/メーカー: 英治出版
- 発売日: 2018/02/07
- メディア: 単行本
- この商品を含むブログ (2件) を見る
なぜ読んだか
この本はとある勉強会でいただいたものでした。 日常のプロダクトマネージメントの業務の中で、 「どうプロダクトをグロースさせていくのか」「顧客体験を最大するにはどうするべきか」といった点の参考になればと読んでみました。
サンプル集であり、教科書である。
この本の中では実在する有名なプラットフォームで
"どんなことが起こったのか" "どう生まれたのか" "なぜ生まれたのか"
といった部分と
"なぜこのプラットフォームは死んだのか" "ターニングポイントはなんだったのか"
といった観点も触れられています。
その為、ベストプラクティスだけではなく、アンチパターンも学べます。
プロローグ「燃えるプラットフォーム」
この書籍の序文から紹介します。
2011年2月、ノキアは難題にぶつかっていた
いきなり、課題にぶつかったノキアのお話です。前述の通り、この本では成功、失敗の両方がサンプルとして描かれています。 この章ではこれまでのインフラやハードウェア産業とプラットフォーム事業の明確な違いと
「その立ち位置を変える舵取りをした企業」 「その道にとどまることを選択した企業」
の軌跡を1つの例を基に紹介しています。
1~4章 プラットフォームビジネスとは何か、プラットフォームビジネスが経済を成長させている理由
1章では
- ビジネスモデルの歴史
- プラットフォームにおける消費者とプロデューサーの関係性
- 商品の流れと情報の流れ
- プラットフォームの定義と例
- プラットフォームの構造
- マッチング意思
などに触れています。
これらの背景から、プラットフォームには「交換型」と「メーカー型」の二つの方式があり、自分のプラットフォームがどちらに適しているのかを理解することで、コア取引と4つの基本設計に通づると語っています。
2章では一転、20世紀における企業論と価値について振り返っています。
それを踏まえた企業の本質、コンピューターが市場に与えた影響などについて解説しています。
そして、このころの考え方はもはや時代遅れになっていると言っています。 その理由は今までのビジネスのスピード感に比べてプラットフォームビジネスは急激であり、急速であることであるということに由来しており、そのトレンドはもうしばらく続くことです。
3章では、プラットフォームビジネスには限界費用がないこと。それにはベンチャーキャピタルの存在が寄与しているといいます。 そしてプラットフォームは"成長ができる"だけでなく、"成長しなければならない"そのスケールかを最大限に活用することが必要です。
そのため、ほとんどのプラットフォームは成功/失敗の二極化すると解説しています。
4章ではそれらの成功に当たる「プラットフォームの支配」を"現代の独占"と定義しています。 そのためにはビジネスモデル、市場の拡大、競争的な独占という表現で"現代の独占"が意味するものを解説しています。
5~8章 プラットフォームビジネスの仕組みと現代の独占企業への道のり
5章からは現代の独占企業へ成長するための方法や仕組みに触れています。 まずはそんな企業をどうデザインするか。そのためには
- 創造する
- 結びつける
- 消費する
- 対価を支払う
という「コア取引をいかにシンプルに提供するか」とその重要性を説いています。
そして6章ではそのコア取引を実現するためのプラットフォームの4つのコア機能について解説しています。 4つのコア機能とは
- オーディエンス構築
- マッチメーキング
- 中核的ツールとサービスの提供
- ルールと基準の設定
です。その方法と具体例を基に7章では、
"プラットフォーム運営者ではなく、生まれたネットワークやコミュニティーに仕事を任せる"
というプラットフォームビジネスならではの重要な観点について解説しています。
最後の8章ではここまで解説してきたプラットフォームたちを基に
「あなたならどうしますか?」「こんなチャンスがありますよ?」
といった自身のプラットフォームを構築することに対するヒントをくれています。
ここまで理解してきたプラットフォームビジネスをどう体現するかのはじめの1歩といったところでしょうか。
どんな人にオススメか
ここまで述べてきたようにこの本では
「サンプルを交えてプラットフォームの理解をし、自身のプラットフォームを構築する」
といったことがまとめられています。
そのため、この本は
- プラットフォームビジネスに興味があり理解を深めたい
- 自身で立ち上げたい
- プラットフォーム開発にアサインされた
- これからのビジネスモデルを学びたい
といったライト層から実務者まで幅広く学べるものだと思います。
ぜひ、手にとってプラットフォームについての理解を深める教科書として活用することをお勧めします。
プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか
- 作者: アレックス・モザド,ニコラス・L・ジョンソン,藤原朝子
- 出版社/メーカー: 英治出版
- 発売日: 2018/02/07
- メディア: 単行本
- この商品を含むブログ (2件) を見る
プロダクトを成功に導くための発注者の責務
今日はプロダクト開発における発注者について私の考えをまとめていこうと思います。
発注者って誰?
まず、この記事で指す"発注者"と言う言葉について定義しておきます。
一番意図している人としては"プロダクト開発におけるステークホルダー(組織)の現場担当者"といったところでしょうか。 つまり、下記のような人ではありません。
- 発注作業の事務的な手続きを行う担当者
- お財布を握っているステークホルダー(組織)の偉い人
- 依頼があり、開発を行うチームとそのPM
また、発注という言葉も定義しておきます。
プロダクト開発の手段として「社内開発」「外注開発」と二つあると思います。 もちろん細かく分けると「SESで自社に来て貰う」とか「パートナー企業と協業で」などありますが、大別すると上記2種類かなと思ってます。
この記事で指す"発注"とは上記どちらにおいても発生していると思っています。
具体的には
「"新しいサービスを立ち上げたい人"が"開発を担当する人(チーム)"に開発を依頼(一緒に行う場合も含む)を行う行為」
と定義したいと思います。
この記事を書く理由
というわけで内容に入っていこうと思いますが、 そもそも、"なぜこの記事を書くのか"についてお話ししておこうと思います。
私はサービス会社のエンジニア組織に所属しています。
私の所属する企業では"現場"と呼ばれるオペレーションを担当している部署や"営業"と呼ばれるセールスとマーケティングを行なっている部署があらゆるドメイン知識を持って日々のBtoBサービスの提供を行なっています。
そこに"技術"と呼ばれる区分の3つに大別され、"技術"という区分には"メンテナンス"、"基幹のインフラやIT整備"、"社内外向けサービス開発"の3種類の部署が存在します。
私が所属するのは"社内外向けサービス開発"を担当する部署で10名超が属しています。 主な業務としてはプロダクトの要件定義、開発、運用保守を行なっており、現在は40程度のプロダクトがアクティブな状態です。
これらの開発はリソースやサービスの性質、スケジュールに応じて"内製"と"外注"を選択しています。
私のポジションは主にプロダクトマネージメント、プロジェクトマネージメント、インフラ、セールスエンジニアを各プロダクトで担当しています。
内製の場合は複数人の開発者でチームを組成します。
一方で、外注の場合は開発の部署としてはほぼ一人で動きます。
エンジニア1名 + ドメイン知識を持つ非エンジニア(現場や営業)複数名 でプロジェクトを組成し、プロジェクトを開始します。
その過程の中で成功するプロジェクトと失敗するプロジェクトに、ある一定の"発注者が押さえないといけないステップ"が見えて来ました。 もちろん、弊社だけの理由であったり、私の考えが甘いことも多くあるのでお手柔らかに読んで欲しいものですが、自分の備忘録と一つの仮説という意味でまとめます。
また、その背景にあるものとして、"いくら優秀なエンジニアやPMがいても発注者次第でプロジェクトは失敗する"とも感じています。
プロジェクトの始めにやるべきこと
まずはプロジェクトの立ち上げに関してです。
プロジェクト立ち上げのきっかけは「自らの企画が通る」パターンや「指名を受けてプロジェクトメンバーになる」といった方法があると思います。 そして、自分以外のプロジェクトメンバーに関しても「自ら指名する」「すでに決まっている」というパターンがあると思います。
どちらにしろ、発注サイドのプロジェクトメンバーは少なくともこのような条件が必要だと思っています。
- 現状のフローを熟知している
- 解決したい課題を認識している
- プロジェクトに当てる時間を捻出できる
これら全ての条件を備えている人がいれば、申し分ないと思いますが、プロジェクトのスタート時は"個々人がどれか1つ以上の要素を満たしている"という状況で良いと思っています。そして、"プロジェクトメンバー全員が集まると上記3要素を満たしている"という状態になっていれば、プロジェクトメンバーの選定は成功だと私は思います。
よく
- プロジェクトに前向きで、やる気がある人
- コミュニケーション能力に長けている人
といった条件がマストと言われていたりもしますが、私はそうは思いません。
というか、全員がこれを満たすのは無理な場合がほとんどだと思います。
そもそも、ドメイン知識が豊富な人は忙しいものです。そんな状態でよくわからないプロジェクトにアサインされたら、最初はやる気が起きないのも当然だと思います。 さらに、現状の課題が「属人化、ブラックボックス化」というのもよく聞きます。 正直、積極的でコミュニケーション能力が高い人だったら、プロジェクト化する前にそんな状態を解決していることもあるのでは?と思ってしまいます。
一方で、「全然参加できない、コミュニケーションが取れない人とプロジェクトを進めてもうまくいくわけないじゃないか」と思うかもしれません。
その通りです。 あくまで、"プロジェクト開始時は"この状態で良いと思っています。
つまり、プロジェクトを進めていく中でこのような状態を変えていくことが必要です。
なので私は始めに「チームビルディング」と「プロジェクトの方向性を整える」ということをやります。
ただの人の群れをチームにする
チームビルディングでは「どんな価値観を持っているのか」「メンバーに対してどんな期待をしているのか」を可視化することにフォーカスします。
具体的には 「価値観ババ抜き」でチームメンバーの価値観を可視化します。
※ 価値観ババ抜きについては過去記事にて。 passionate-po.hatenablog.com
それぞれがどんな価値観を持っているかが見えてくると初めて一緒に仕事をする相手でも"目の前に座っている人がどんな人なのか"が少し見えてきます。
その後は「ドラッガー風エクササイズ」を行います。
※ ドラッガー風エクササイズについてはギルドワークス中村洋さんの記事を引用させていただきます。
チームメンバーの期待をあわせる「ドラッカー風エクササイズ」 | DevTab - 成長しつづけるデベロッパーのための情報タブロイド
これでプロジェクトにおけるお互いの期待をすり合わせます。 この2つのワークについては必ずどんな手を使ってでもチームメンバー全員に参加してもらいます。
ここに参加しないひとが出ると文化祭や体育祭に欠席した学生のように共通の経験がなくなり、その後のプロジェクトに大きな悪影響を及ぼします。
不思議なもので、上記2つのワークはしばらく経っても随所でプロジェクトメンバーの話題に上がります。そのため、それについていけないと仲間外れ感からプロジェクトに対するモチベーションが落ちるだけでなく、周りのメンバーもその人が何を考えているのかさっぱりわからなくなってしまい、孤立していきます。
そのプロジェクトは何者かを考える
次にプロジェクトそのものを紐解きます。というより、この段階では「なんとなくこれがあった方がいいからプロジェクト化したよ」みたいな状態の場合もあるので、プロジェクトの存在意義をチームで固めていきます。
これももちろん全員で行います。
具体的には「インセプションデッキ」を作ります。
※ インセプションデッキについては過去記事にて
インセプションデッキの中では特に
- 我々はなぜここにいるのか
- エレベーターピッチ
- やらないことリスト
- 夜も眠れない問題
を重視します。 プロジェクトメンバーとして集まった個々人がプロジェクトへのアサインを受けた時点で少なくとも自分なりの方向性やあるべき姿を考えます。 ただそれは必ずと言っていいほどズレています。
にも関わらず「みんな同じことを思っているはずだ」と考えていることが多いです。 そのため、方向性を揃えるためにも必ずこれをやることをお勧めします。騙されたと思ってやってみてください。
そのあとはエンジニアと非エンジニアでタスクを分けることが多いです。
非エンジニアチームには現状のフローをフローチャートにまとめてもらいます。 この時の基準は「(ドメイン知識のない)新入社員がこの仕事を理解するために必要なレベルで」というイメージです。 これが後の開発チームの業務理解につながる重要な資料になります。
そしてエンジニア(主に私一人ですが)はRFPを書きます。 機能要件については足繁く現場に通い、キーパーソンに聞きながら書きます。 そして一番重要なのが"その作業を実際に見せてもらう"ことです。
これがかなり重要です。
というのも、実際のオペレーターは当たり前になってしまっている作業もフラットな目線で見ると「なぜ?」という点が多くあります。 そこをとにかく拾い、質問をし、そうしなくてはいけない理由を明確にします。
これにより、現状のフローの課題の解決手段とフロー改善における制約をリストアップできます。
これをもとに機能要件をまとめます。 機能要件がまとまったらチームでレビューをします。
ここは時間がかかります。なぜなら、現場のオペレーターはフローがガラッと変わることに対する想像力が必要になるからです。 そのため、確認フェーズでは図や表を使ってあらゆる手段でイメージを伝えます。
そして並行して非機能要件(性能要件含む)、セキュリティー要件、運用保守要件、プロジェクト管理要件など残りの部分をまとめます。
これらはどちらかというと技術的な側面を中心に進めるので、スラスラと書けると思います。
例えば、開発言語やフレームワークの指定やセキュリティー要件は組織のルールや自分なりの閾値があるのでスラスラ書けます。 プロジェクトの進め方、会議体、ツールの指定なども同様でしょう。
とにかく細かく書きます。そしてその要件がどのくらいマストなのかも書きます。 よく使う言葉としては
- 〇〇とすること。
- 〇〇だと望ましい。
- 〇〇について提案を求む。
などを使ったりしています。
RFPが完成したあとは、いよいよ開発チーム候補の選定です。
まずは内製か外注かですが、これは
- リソース状況
- スケジュール
- スキル
などの状況で判断します。内製となればあとは開発チームを組成し、実際の開発に入っていきますが、この部分は多く語られているので、今回は割愛します。
外注の選定基準についても上記と同様ですが、それに加え、
- 自身が一緒に仕事をしたい人、会社
- 開発手法や技術レベル
という側面でいくつか知り合いの方々に当たったり、周りの人に聞いて紹介してもらったりしてます。
だいたい3~4社くらいに絞り、お声がけさせていただきます。
プロジェクトのビジョンを伝える
さて、お声がけさせていただいた開発チーム候補には
を行います。
RFPのみを配って説明をするパターンが多いと思いますが、私はそれだけでは不十分だと思います。 そもそも「外注先なので、細かいビジネスについて共有する必要はない。下請けだ!」と思っている方がいたら、私は全力で反対します。
なぜなら、自社のビジネスを一緒に作るパートナーとなってもらうチームです。 そのため、「どういうビジネスなのか。サービスなのか」、「どういう業界なのか」を理解した上で開発を進めていく必要があります。
そして、開発パートナーとなるチームにも期待したいこととして、
- ビジネスやサービスの成長を意識した提案
- 時にはこちらからの機能要件にも疑問をぶつけてもらう
といったことをお願いします。そして、それができることも選定の基準とさせてもらっています。
開発チームの選定
いよいよもって、提案をいただく流れになります。 提案については公平を期すため、提出期限、提案時間は同じにしています。
そして、選定方法は定量的な方法で行なっています。
具体的には比較表を作ります。 比較表では
- RFPに記載した各項目を1行ごとに記載
- 各項目に重みをつける
- 各社の提案に対しての評価を行う(3点:要望を超える提案、2点:要件通りの提案、1点:要件を一部実現する提案、0点:要件を全く満たしていない提案)
- 各評価に重みを掛け合わせる
- 総合点で比較
という手順で評価を行います。 これをもって開発パートナーとなるチームを選定します。
偉い人に納得してお財布を開いてもらうための責務
さて、プロジェクトチームで一緒に働きたい開発パートナーを選定したら、お財布や稟議のお話です。 お財布を握る偉いひとは「このプロジェクトがうまくいくのか」を心配しています。
その心配を安心に変えることもプロジェクトメンバーの責務です。 実は、そのための材料はこの時点で揃っているのです。
私はここまでに用意したアウトプットとして
を提出します。
そして、そのサマリーの説明をすることで、発注根拠を説明します。 こうして、公平な基準で根拠をもって選定したことを理解してもらい、気持ちよく発注をしてもらいます。
これにて、開発プロジェクトはスタートラインに立ちました。 いよいよスタートです。
開発のキックオフ
さて、開発パートナーも決まり、開発プロジェクトのスタートです。 まずはキックオフですが、私はここで主に下記を行います。
- 発注側のメンバーと役割の紹介
- 開発側のメンバーと役割の紹介
- プロジェクトビジョンの確認
- スケジュールと進め方の擦り合わせ
表向きはこんな感じです。 そして、できればこのキックオフを夕方めに設定します。 その理由は御察しの通り、そのまま懇親会に突入させるためです。
これが実はかなり重要です。
初めて一緒に仕事をする相手に対してこれからお互いがオブラートに包まず、本心を言い合わなくてはなりません。 そのためには心理的な距離感を縮めることが必要です。
これは現時点の私の解なので最適解が他にあるかもしれませんが、 まずは全員で飲みに行きます。
そして、雑談をし、お互いのバックボーンを知り、距離感を縮めつつ、尊敬の念を持てるようにします。
とにかくフランクに、とにかく仲良くなることを重視します。 お互い楽しく仕事をし、良いプロダクトを作るために"チームとプロダクトに愛着と期待"を感じてもらいます。
開発サイクルの管理
さて、無事にキックオフができたら、いよいよ開発です。 開発中の具体的なプラクティスや方法論はたくさん出回っており、かつもっと詳しい方も多いので、今回は割愛したいと思います。 いずれ私の考えも記事にしていこうと思います。
ただ、私の立ち居振る舞いとしては
- 開発PMと同じレベルで仕様を理解する
- 要件定義に思いっきり口出しをする。時にアドバイスをする
- 全てのやりとりを把握する
といったことを徹底します。
「あくまで発注者だから開発チームに全部任せないと内政を変わらない。外注する意味がないじゃないか。」という声があるかもしれません。
ただ、やはり自分たちのサービス、プロダクトへの責任を持つということ、また緊急時の対応判断を即座にできることを考えると私はこのスタイルが必要だと考えています。
プロジェクトの終了
プロジェクトも終盤、クロージングについてです。 そのタイミングでは運用開始を想定する必要があります。
具体的には
- ユーザー教育
- 拡販
- 広報
- 運用保守
などを検討する必要があります。 この時にプロジェクトメンバーにお願いすることがあります。 それは
「プロジェクトメンバー以外のユーザーがプロダクトにポジティブな印象を持つように接すること」
です。プロジェクトメンバー以外のユーザーは「新しいやり方だ自分の仕事の仕方を変えようとしている。めんどくさい。」 という印象から始まることが多いです。
そんなユーザーをプロダクトのファンにするのもプロジェクトメンバーの仕事です。 そのため、いかにポジティブな印象を持ってもらい、利用を促進するかがポイントになります。
次のフェーズに向けての準備
そしてプロジェクトが終了。チームも解散になります。 その前には必ず、「ふりかえり」をすることにしています。
これは、「プロダクトの今後の成長」「プロジェクトメンバーの成長」の2つの側面で非常に重要です。
プロダクトについては、次のフェーズに進むために一歩立ち止まって、改めてプロジェクトを俯瞰してみることで学びを得ることを目的にします。
プロジェクトメンバーについては、このプロジェクトにおける進め方、自分の立ち居振る舞いからの学びや次のプロジェクト、働き方についての気づきを持ってもらえると成功だと考えます。 そしてそれらをできるだけポジティブな形で終えること。それが開発プロジェクトに不慣れな現場や営業のプロジェクトメンバーの自信とプロダクトへの愛情へと変わります。
と、ここまでで「みんなの期待に応えるプロダクト」と「プロジェクトから学びを得て成長したメンバー」が揃っていることが私なりのプロジェクトの成功だと感じています。
まとめ
というわけで少々長くなってしまいましたが、私の思う発注者の責務を書いてきました。 改めてまとめると
- プロジェクトメンバーがお互いの価値観と自分への期待を知り、チームとなること
- プロジェクトの方向性、ビジョンを全員が共有すること
- 開発パートナーは下請けではない。未来を共に創るチームの一員と理解すること
- 細かいところまで定義する。ビジョンやビジネスも共有する
- 心理的距離を縮める。本音を言い合える仲になる
- プロジェクトメンバー以外にも自信を持ってプロダクトを伝える
- 「みんなの期待に応えるプロダクト」と「プロジェクトから学びを得て成長したメンバー」をゴールとする
といった点を私は重視しています。
「いやいや、この要素が足りないだろ」「これは違うだろ」という声もあると思います。 ぜひ、私もより一層学んでいきたいと思っていますので、是非ともコメントやSNSなどでご意見やご感想をいただければと思います。
2018年のふりかえりと2019年の挑戦
2018年も残りわずかとなりました。 ここで自分のふりかえりと、今見えている来年の挑戦について書いていこうと思います。
主に2018年はわたしの中で"働き方を大きく変えた年"でした。 昨年までのわたしは典型的なサラリーマンというか、
朝から仕事をし、終わらなかった仕事はダラダラと残業をしてかたずけ、自分の精神を摩耗させていながらも、自分の成長の鈍化に恐れを感じているような状態でした。
2018年は大きな出会いと衝撃が次から次へと訪れ、本業以外でのチャネルができ、そこでの活動やそれに伴う自分の成長を大きく感じた年でした。
特に大きな下記についてまずは振り返っていきたいと思います。
- プロダクトマネージャーとしてのお仕事。
- カイゼン・ジャーニー、DevLOVEとの出逢い
- スクラムとカイゼンを根付かせた話
- The Agile Guildでの新たな試みを行う仲間たち
- ブログメンターをしてもらいました!
- 結婚しました。
プロダクトマネージャーとしてのお仕事。
これは本業の話ですね。2018年1月から新たなプロダクト開発を行っていました。自社のVOD関連事業の現場効率化を行うプラットフォームで、自社内のみならず、顧客にもプロダクトのユーザーとして参加してもらうことで今までの受発注やプロセス管理の工程をカイゼンするプラットフォームです。
というわけで、プロジェクトメンバーは開発職はわたし一人。あとはVODの現場のリーダー職数人でのプロジェクトチームで、外部の開発パートナーと協力して進めたプロジェクトでした。
このプロジェクトは二つの挑戦をしました。
スクラム開発に関しては2017年10月くらいから興味を持ち、ジワジワと調べていました。そのため、開発パートナーの選定も「スクラムで行うこと」を前提に探しました。 もう一つの観点として、私の立場は外部のパートナーとの開発以外に内製開発も担当しています。そのため、自社の自チームでの内製開発にもスクラムを取り入れるために自信が学びたいという側面も多くありました。
そのため、私自身も
- Scrum Alliece認定プロダクトオーナーの取得
- ベトナムでのチームビルディングへの参加
などを中心に自身の知識を伸ばすこともしてきました。
はじめてのオフショア開発のため、ベトナムでのチームビルディングへの参加は多くの学びがありました。
「初めてスクラム開発を行うチームがどのように学び、どのように成長していくのか」 という観点で今後自身がが社内アジャイルコーチとして立ち居振舞うにあたり、どう動けばいいのかを見て学ばせてもらいました。
また、プロダクト開発という観点においても、拙い英語でではありますが、
- このプロダクトがどんなものなのか
- 配信市場はどういう状況なのか
- どんな課題を解決するのか
といったものを自分の言葉で自分の表現で、チームに話せたことがとても有益だったと感じています。 また、実際に顔を見て話せたこと。一緒に飲めたこと。ベトナムのカラオケで肩を組んで歌えたこと(Michel Jacksonとか)。中にはFacebookで友達になるメンバーもできたくらい仲良くなれたことはとても受発注の関係を超えたチームとしてスタートが切れたとても良い要因となりました。
ベトナムから帰り、実際のチームでのプロジェクト運営においてもいくつかの取り組み行いました。
今回のようなDevOpsそのものの案件は会社の性質上、割と多いものの、エンジニアと非エンジニアの組織の温度差や知識の差を埋めることができす、チームになり切れないパターンが多くありました。
そのため、チームビルディングは丁寧に行いました。 具体的には
- プロジェクト開始時に全員でインセプションデッキを作成
- 開発プロジェクトとマーケティングプロジェクトの両方を組成
- チームメンバーの増減時にインセプションデッキをリファクタリング
- スクラムとは?アジャイルとはという説明と共通理解の場の設置
- 節目でのふりかえり
プロダクト自体はこれからユーザー獲得フェーズに入ります。 B to Bサービスのため、母数は少ないものの、業界のデファクトスタンダードになるべく、1月からもいろんな施策を打っていこうと思っています。
カイゼン・ジャーニー、DevLOVEとの出逢い
前述の通り、昨年後半からスクラムの勉強を進めてきたわけですが、そんな折、2018年2月に今の私を作った大きな出来事がありました。
それは、 Developers Summit 2018の 市谷さん、新井さんの講演、そしてカイゼン・ジャーニーです。
DevSumi自体は毎年いってはいるものの、あくまで技術的な知識を得るためのものという位置付けで考えていました。 その中で偶然、「アジャイル・スクラム」という文脈でセッションを選んでいたところであったのがお二人のセッションでした。
その講演が私にとってはとても新鮮で、何より心を大きく揺さぶられました。
技術論という面よりも
といったまさしく「会社で誰もやったことがないこと」を一人で進めることが多い自分の状況とその話が重なりすぎていて、まさに灯台のようにその先の私の道をてらし、燃料を注いでもらっているような気持ちでした。
後にも先にも講演を聴きながら今すぐにでもアクションを起こしたいと思ったのはこの講演だけだった気がします。
講演後の私はカイゼン・ジャーニーを購入し、足早に「スピーカーズラウンジ」に行きました。 この時が市谷さん、新井さんとの初めての出会いです。
まさかこの1ヶ月後に「週に2~3回もこのお二人と一緒に活動したり打合せをしたり、飲んだりする」ことになるとは思いもしませんでした・・・。
そして目黒雅叙園を離れた翌日。 土曜日ながら、動かずにはいられず、いくつかの新しい試みを始めました。
まずはTwitterとこのブログの開設です。
それまではほぼほぼ、インプットばっかりだった自分を変えるため、また、自分の中での目標としている
「映像業界の働き方を変える」
ということの実現のためには、アウトプットの必要性を感じたことがいちばんの要因です。 そして、数ヶ月ご、数年後に自らが登壇して話しているビジョンが思い浮かび、そのためのログを残すこと、その機会をもらうためにはアウトプットを絶やさないことが必要だと感じました。
その時の投稿がこちら。
退路を絶って本気で頑張るために新規アカウント開設!
— はち (@PassionateHachi) 2018年2月18日
よろしくお願いいたします。
そんなこんなでアウトプットを続けていると奇跡のような展開が待っていました。
そして・・・
今思うと、断ることもできました。 そして、今までの自分だったら断っていたのかもと。
ただ、自分の活動にドライブをかけるために。なにより、「映像業界をチームで働く業界に変える」という目標に近づくためにと考えると自然とここに力を注げるようになりました。
それから、DevLOVEの運営としていろんなイベントの企画や登壇、ワークショップもやりました。 例えば・・・
ナビタイムさんの会場でこんな話をしたり・・・
www.slideshare.net
価値観ババ抜きのワークショップをやったり・・・(1月に第2回やります!)
ビブリオバトルやったり・・・
中でも反響が大きかったのは私なりの新卒社員の育て方についてでした。
www.slideshare.net
ふとした2月の出逢いから、ここまで成長できたのは他でもないこの活動があったからだと思います。
そして、この活動は私個人のものから、社内での活動へも繋がりました。
スクラムとカイゼンを根付かせた話
さて、上記のような社外でのコミュニティー活動や出逢いは何も自分の個人活動のみに還元されているわけではありません。 この経験が本業の自分の部署のみならず、他部署への貢献につながったことも今年の大きな収穫でした。
まずは、社内スクラム勉強会の開催です。
毎週月曜日に1.5時間もらい、スクラムについての勉強会を全6回で行いました。 この勉強会の特徴は、
- スクラムや開発に関わるのはエンジニアだけじゃないので営業も参加。
- 決して開発に特化した方法論にはしない
- 毎回座学とワークの2部構成
という点です。
- 座学だけだと飽きてしまう。
- エンジニア向けだと難しくなってしまう。
- プロダクトを育てるのはエンジニアだけじゃない
という点からこのような構成にしました。
ワークの内容としては
- マシュマロチャレンジ
- デリゲーションポーカー
- プランニングポーカー
- ドラッガー風エクササイズ
- 価値観ババ抜き
などを行いました。
その様子がこんな感じでした。
そして、この勉強会で終わらせてしまうと、あくまで部署内に留まってしまいます。
そのため、社内ナレッジシェアツールに「なぜ、このようなことが必要か」と方法を少しずつ書いていきました。
また、この勉強会を機に「まずは何かやってみよう!」という空気を作ることができました。
そこで部署で始まったのが、Daily Scrumとふりかえりです。
Daily Scrumでは
- 昨日やったこと
- 今日やること
- 困っていること
を中心に構成し、最後にはファイブフィンガーで気持ちを可視化しました。
ふりかえりは KPT-Aの方式をとり、 それまでに行われていた部署の定例会議のやり方を改善しました。
運営をして1ヶ月。 この活動が起動に乗ったと感じたもののこれによりどう感じているかのフィードバックのもらい方とチームのモチベーションを上げる方法を考えたいと思い、もう一つのワークを始めました。
これは月間MVPという名前で
1か月間の「ありがとう!」と思う行動を「誰 to 誰さん。〇〇してくれてありがとう」という形式で付箋に書き出し、 みんなの前で顔を見て感謝を伝えます。そして、全て出揃った中から、最も素晴らしいものに1人1票、シールでドット投票するというものです。
これはとても効果が大きく、
翌週のふりかえりのKeepに
「MVPもらったことでモチベーションが振り切ってます!!」と書いてくれるメンバーがいたり、 「朝会のおかげで、体調不良や困りごとが言いやすい雰囲気でとても嬉しいです。」
という言葉をもらいました。
このような私の部署でのカイゼンも社内ナレッジシェアに書き込むこと、それを社内SNSに発信することを始めました。 すると、私の活動は次第に口コミで広がり・・・
- 「ぜひ教えてくれ!」
- 「うちでもやってくれ!」
- 「相談がある!」
と他の部署か声がかかるようになりました。
そこから生まれたのが、「こそ勉Lab.」という社内勉強会です。
この活動は主に休日、有志で集まって行う勉強会として立ち上げ、これまで半年で5回の開催ができました。
今では運営メンバーも10人を超え、来年1発目のイベントは自社のみならず、親会社やグループ会社まで活動が広がることが決まりました。 じわじわとではありますが、こういった形で業界に勉強会の流れを根付かせることができそうな雰囲気が出てきました。
また、業務においてもカイゼンの流れを大きく変えるきっかけがありました。 それはヴァル研究所さんへの見学です。
これはひとえに新井さんとの出会いがなければ生まれなかった経験で、自分の部署以外に活動が広がった大きなトリガーになりました。
見学は半年間待ってやっと順番が回ってきた上に限定10人ということもあり、この機会は絶対に逃せないものでした。 そのため、私は人選に力を注ぎました。
まずは、1人目のメンバーとして巻き込んだのが社長です。
ある日、社長室のドアをノックし、(エレベーターピッチ並みの)プレゼンを行い、社長の理解を得ることができました。 そして、社長と一緒に残りのメンバーの人選を行いました。
その結果、納会でしか集まれないような自社のエースを集めることができました。 具体的には・・・
映画、TV(2拠点)、VOD、業務管理、総務、CM、R&Dのマネージャー陣。
弊社のアベンジャーズのような存在です。
そのおかげで、各部署で強粘着の付箋やカンバンが日常の風景になり始めてきました。
来年はさらにまだ届いていない部門へこの波をたどり着かせること、そして、より高次元で社内改善が進むようにしていこうと思います。
The Agile Guildでの新たな試みを行う仲間たち
そして私のもう一つの活動が The Agile Guildです。
ここには、本業とは別に
- 自分の能力で試したい
- 世の中の課題を解決したい
- 貢献したい
- 能力を伸ばしたい
と純粋に思っている人々が平日の日中、夜、休日問わず、自分の時間をつぎ込んで集まっています。
そこには会社や組合などのしがらみから解放され、純粋に世界を変えようとしている人たちが100人以上存在します。 主に私はこの組織で
自分にも会社にも足りないと思っている「仮説検証」の分野で関わらせていただいています。
ここでの活動は企業に属していたら当然になってしまっている常識を良い意味で考慮しなくていい状況や、政治や大人の事業に引っ張られることなく、開発の力で課題を解決していくことができる環境が整い始めています。
ここでの活動はいつも私に新しい視点と側面をもたらしてくれており、ワクワク感と「できないことなんて実はあまりない」ということを思わせてくれています。
ブログメンターをしてもらいました!
10月より、カックさんにブログメンターをしていただきました。 おかげで、ブログを書くことの習慣化や記事以外のコンテンツの有効性などたくさんのことを教わりました。
前述の通り、私の目標を達成するためにはアウトプットは1,2を争う重要な取り組みです。 私の中で次のステージに進むために必要な、モチベーションの源泉に命の水を湧かせることができそうです。
結婚しました。
今年の出来事の最後は結婚です。 今年の6月に2年付き合った彼女と結婚しました。
このブログはきっと嫁は見ないだろうと思うので、照れ臭いことも書いていこうかと。
彼女は「ピアノを弾くこと」を生業としている人です。 そのため、プロとしてのものの見方や感性、考え方を持っていて、日々刺激を受けています。
そのため、いろんな部分でぶつかることは出てきつつも、そういった気持ちのぶつけ合いができる状況と最後には仲直りができる環境にとても心理的安全性を感じています。
ご存知の通り、夜の打合せやイベントなどで平日はほぼ毎日外食。そして夜も終電前後の私に対しても、それを許してくれるどころか、笑いに変えつつ、心配をしてくれる姿は感謝をしても仕切れません。
彼女と過ごす毎日がなければ、私自身のモチベーションは保てないし、前に進めないと日々感じています。
2019年、新たな挑戦。
2018年はこれらの活動から社会人7年目にして、最も濃厚な日々を送れました。 特に、平日の夜、休日時間の使い方が変わったことにより、1日の時間が24時間から48時間くらいに増えた感覚が強いです。 逆に言うと、今までの私の生活は24時間をフルに使えておらず、"時間"と言う限られた資源を無駄遣いしていたと痛感しています。
そして来年はこれらを加速度的にドライブをかけることのみならず、新たな出逢いが見えてきました。 最後にその4つのチャネルについて紹介してこの長文記事を終わろうと思います。
1/26(土) Backlog World 2019
まずは、2019年最初の登壇が決まりました。nulabさんのBacklogのユーザーグループであるjbugさん主催のBacklog world 2019です。
こちらの公募セッションに申し込んだところ、大変ありがたいことに6枠の公募セッション枠の一つに選んでいただきました。
ここで私がお話ししようと思っているのは、
そのため、プロジェクト管理ツールの導入とタスクの可視化を目的にこの半年で行った10の取り組みについてです。 2018年の私の活動は数々の方々との出会いに支えられたものであり、私自身は何の特殊な人間でもありません。
私の取り組みを惜しみなくお伝えし、DevSumiで私が勇気付けられ、1歩を踏み出せたように、聞いてくださる方が1歩踏み出せるような方法とマインドセットについてお話ししようと思います。
メディアエンジニア勉強会
そして同じく1月に始めようと考えているのが"映像業界のエンジニア向け勉強会の定期実施"です。 映像業界は数年前まではビデオ信号や放送機器の技術と言うIT業界とは全く別の技術が必要な業界でした。
近年ではこれだけではなく、ネットワーク速度の普及により、IT業界と変わらない技術が必要となってきました。
一方で、扱っているデータの容量は数TB~数PBが当たり前であり、放送機器との連携が必須です。
そのため、IT技術のみ持っているエンジニアも、映像技術のみ持っているエンジニアもまるで歯が立ちません。
しかしながら、閉塞された環境の中、お互いに知識を共有する場が限定的なのが事実です。 また、映像に参入し始めたIT企業が勉強会の場を提供しても「だれ?」と言う状態で誰も集まらない業界でもあります。
そんな状況を打破するためには業界のリーディングカンパニーが旗を振ることしか方法はなく、そのポジションは自社であり、私が切り開くべきだと自負しています。
そのため、来年の活動の主軸のひとつとして力を入れようと思っています。
ファシリテーション塾
そして、もう一つがまだ未確定ではありますが、"ファシリテーション塾"です。 これは私のスキルの向上、場づくりに対する理解と体現をより確実なものにするために個人の活動として参加を申し込んだものです。
プロダクト、プロジェクト、チームなど、人が集まるところにはファシリテーションが必要です。 それは「会の議事を進行する」ことではなく「場を作り、デザインすること」だと思っています。
そういった観点では自分はその時のメンバーによって精度がマチマチになっていたり、苦手意識を持ってしまうこともあります。 そんな自分のスキルを上げるためと言う点が動機の一つです。
もう一つの動機は、「ファシリテーターのための場づくり」です。
ファシリテーターは意図して自分がなる場合と、いつの間にか自分がやらざるを得ない場合があると感じています。
と言うのは社内会議など然り、
どうしたらいいのか分からないけど、言い出した手前、もしくは指名された手前、自分が進行しなくてはいけない
と言う状況です。
こういった状況でファシリテーションをしている場をよく見かけることもあり、そんな状況を生み出さないためにも ファシリテーションの重要性や必要な考え方などを伝えることができればと思っています。
そのため、ファシリテーターをサポートできるスキルやマインドセットを得たいと考えています。
最後に
ふとFacebookを見直してみました。 今年友達になった方が合計で125人でした。
日々感じるのは私の成長と新たな挑戦ができるのはいろんな方との出会いのおかげだと思っています。
みなさんからの応援であったり、機会をもらったり、声をかけていただくことがなければ、自分の目標は何一つ達成できていないと思います。
2019年はより一層の貢献ができるよう速度を上げていこうと思います。
私の活動や行動、言動に何かしら感じていただけたら、ぜひお声かけいただきたいです。 いろんな機械に対し、120%で答えられるように頑張っていきます。
来年も引き続き、よろしくお願いします!