Recommandé
Contenu connexe
Similaire à コロナウィルス以前から全国各地の少人数フルリモート体制。失敗から学んだ一番大切な事。
Similaire à コロナウィルス以前から全国各地の少人数フルリモート体制。失敗から学んだ一番大切な事。 (20)
コロナウィルス以前から全国各地の少人数フルリモート体制。失敗から学んだ一番大切な事。
- 1. 1 QuarkA 全国各地の少⼈数フルリモート体制 失敗から学んだ⼀番⼤切なこと D e v e l o p e r s S u m m i t 2 0 2 0 K A N S A I
- 2. 2 コロナ渦で注⽬を浴びるリモートワーク u リモートの⽅が効率的なのでは︖ u ⼈付き合いの⾯倒が減る︖ u 住む場所や採⽤が多様化する︖
- 3. 3 しかし・・・
- 7. 7 今⽇の話は・・・ 成功事例では出てこない、失敗を乗り越えた話をします。 ü チャットで効率化 ü 資料など可視化が⼤切 ü 雑談が⼤切 ü ツールを使いこなせ ü 同じ時間に働いてテレビ会議を繋ぎっぱなしに
- 8. 8 ⽬次 01 ⾃⼰紹介 02 リモートワーク5つのコツ 1. 仕事の種類を⾒極める 2. 孤⽴させない 3. 戦略で揉めることを知る 4. 伝わらないの解決法を知る 5. 教育を変える 03 まとめ Appendix 参考資料
- 9. 9 ⾃⼰紹介 ⽇本初のウェブ担当者教育サービス ウェブ担当者通信代表 丸⼭ 耕⼆ 1976年6⽉30⽇ 新潟⽣まれ。 • ⽴命館⼤学理⼯学部 電気電⼦⼯学科 • 学⽣時代に制御系プログラマーとして⽵中⼯務店の⾳響開発システムを担当 • 伊藤忠テクノソリューションズ株式会社（CTC）でシステムエンジニア • WEB系ベンチャー企業でビジネスコンサルタント • ウェブコンサルタントとして独⽴ • 株式会社ウェブジョブズを設⽴ 著作︓ 著書︓世界⼀やさしいGoogle Analyticsアクセス解析⼊⾨（秀和システム） 協⼒︓APIエコノミー 勝ち組企業が取り組むAPIファースト（⽇経ＢＰマーケティング） 連載・講演︓ ウェブ担当者フォーラム（インプレス） Bizコンパス（NTTコミュニケーションズ） 公益社団法⼈ ⽇本印刷技術協会 公益財団法⼈ 三重県産業⽀援センター 現︓株式会社ウェブジョブズ代表 ウェブ担当者通信運営責任者 三重県ICTアドバイザー データ解析プラットフォームQuarkA PdM
- 10. 10 スキル • 制御系プログラマ • インフラエンジニア • ウェブ系フロントエンジニア • マーケティング、セールス • 新規事業の推進 ⽴場 • ベンチャー経営者 • プロダクトマネージャー • チーム内の1⼈のプログラマ • ⼤企業内の⼀般社員 • ベンチャー内の⼀般社員 私の強み • さまざまな⼈の苦労や⽴場の難しさがわかる • 企業規模ごとの違いや難しさがわかる • それぞれでリモートワークを経験してきている
- 14. 14 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など 集計・分析対象データ 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など レポート 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など 消費者・顧客データ • 購買履歴 • 顧客属性 • 消費者・顧客アンケート結果 など ⾒逃せない「孤独」
- 15. 15 コミュニケーションの嘘 全て⼀⽅向からの⽅法論で、多様性を考えられていない。 ⼈付き合いが⾯倒くさい⼈もいるし、物理的にリアルで集まれない⼈もいる。 ü リアルで集まることが⼤切 ü チームワークが⼤切 ü 雑談が⼤切 ü 教育は不可能 ü オフィスで働いているような環境ツールが⼤切
- 18. 18 1. 仕事の種類を⾒極める How about your job?
- 20. 20 私の過去の⽅針 ⾃分が発注側で、全国各地リモートワークで過去何回も開発を成功させていた。 管理をしない（効率的︕） 【⽅法論】 • Google Docsを使い、Joelの機能仕様書&デザインドックを準備する • 紹介経由など信頼のおける⼈に開発を依頼する • リモートでも⼗分な実績がある⼈ • 進捗をこまめにチャットツールとドキュメントで共有 • 場合によっては電話で話し、疑問を残さないようにする
- 21. 21 開発ドキュメント デザインドックJoelの機能仕様書 Googleに代表される最先端の技術企業で取り ⼊れられている設計ドキュメントのスタイル。単にド キュメントの書式だけを指すのではなく、書いた後の 使い⽅までを含めた『開発のやり⽅』につながってい るドキュメント⽅式。 サンプルがGoogleによって公開されている。 元マクロソフトで初期Excelの開発に携わり、独⽴ 後はStack OverflowやTrelloを⽣み出すジョエ ル・スポルスキ（Joel Spolsky）が提唱している 開発ドキュメントのスタイル。 ユーザーが使うシーンを想定してストーリー形式で 開発ドキュメントを記述していく。 ※ジョエルはJoel on Softwareのブログ著者とし ても有名 プロジェクト成功確率向上の近道とは︖(寺⽥英雄） - @IT https://www.atmarkit.co.jp/ait/kw/project_doc.html
- 24. 24 普通の仕事 • 課題とその解決⽅法がほぼ決まっている • アイディアは不要 • 例） • 要件がぶれない開発案件 • 決済のカートプログラム • チームワークは不要 • ⽅法論でまわしやすい • 時間を読みやすくスケジュールは締切になる アイディアが必要な仕事 • 課題に対する決定打が存在しない • アイディアが必要 • 例） • 新規事業のプロダクト開発 • AIによるなんらかの課題解決 • チームワークが必要 • まず⼈間関係が⼤切となる • 時間が読めないのでスケジュールは⽬安になる 原因 【失敗の原因】 多くの場合「この仕事」を誰とどう進めるか︖という観点で考えてしまう。
- 25. 25 どんな仕事でも最初に⾏うべき仕事は「イシューの⾒極め」 分野 項⽬ 課題 解決策 マーケティング コアバリュー ︖ ︖ UX ︖ ︖ 開発 UI ︖ ︖ フロント ︖ ︖ バックエンド ︖ ︖ インフラ ︖ ︖ 運⽤ ︖ ︖ まずイシュー（課題）の洗い出しを徹底的にやらないとだめ。 解決策が未定のものは不確実要素が⾼くなりチームワークが必要。 ※逆に不確実性の低い作業は外注できる可能性がある
- 27. 27 私の過去の⽅針 1. ⻑いミーティングは⾮効率 2. ⼀⼈で集中する⽅が好き 3. ⾃分の時間をとられたくない 4. 移動時間も無駄 5. チャットツールやクラウド上での情報共有を推進 2012年より週2⽇出勤＆在宅勤務 今まで8年間、問題は発⽣していなかった。
- 30. 30 突然1⼈が⾏⽅不明に
- 31. 31 結末 • 独⾝のため、警察へ連絡。 • 会社の社⻑が⾃宅を⾒に⾏くも⼈の気配なし。最悪のケースを想定。 • カットオーバーは完全にリスケ ⼀⼈への負荷が⾼すぎたという⾃責の念。 顔が⾒えて⼊れば気づけたのに。。
- 32. 32 さらにその後から現在へ • 三週間後、突然ご親族から連絡が⼊る • 本⼈から改めて働きたいという申し出あり • 「⼤阪」という場所もあり、会うことができた • グランフロントの上階ロビーで⼀緒にコーヒーを飲んで語らう • その後、話しやすくなってきて⼀緒にコミュニティイベントに参加 • ラーメンを⾷べながらいろいろ話を聞く • そこからチームワークが格段によくなる • 全く違うレベルのプロダクトへ成⻑
- 33. 33 ⼼理的安全性
- 34. 34 ⼼理的安全性とは︖ Googleのピープルリサーチチームが「Project Oxygen」にてデータを基に発⾒したチームの⽣ 産性を⾼める根幹。 チームメンバーがリスクを取ることを安全だと感じ 、お互いに対して弱い部分もさらけ出すことがで きる。 有名なノウハウだが、使いづらかった。 • 具体的にどうすればよいのかが不明 • どの状態を「良い」とするのかが不明 効果的なチームとは何かを知る –re:Work https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/introduction/
- 35. 35 ケガの功名 • 本⼈が「復帰する」と決めた時にまず⼼がけたこと • 「私は怖い⼈ではない」と伝えよう • ちゃんと顔を合わせて笑顔でいよう ⼼理的安全性を⾼めるには ⾃分が「怖い⼈」じゃないことが⼤切 相⼿の問題ではなく、⾃分の問題だった
- 36. 36 変化したこと • 物理的な環境⾃体に⼤きな変化はない • 家族環境や居住はかわらず • 待遇⾯も変わっていない • その後、リアルで顔もあわせていない • チーム内の⾏動が変化 • ドキュメントへの書き込みが⼀気に増えた • 気軽なZoomミーティングの回数が増えた • 困っている⼈へのサポートが増えた
- 38. 38 参考 The ultimate guide to remote work Zapier社がリモートワークのノウハウをまとめて公開中(英語) 。 細かく記載しており参考になる部分が多い。 1. Automation for remote work 2. Teamwork on a remote team 3. Remote work for managers 4. Remote work for employees 5. Remote workspaces 6. Remote work tools 7. The state of remote work
- 41. 41 私の今までのプロジェクト経験 1. 資料を使って「⽬的」や「ユーザー像」などを共有 2. ステークホルダーの合意の上で上記をフィックス 3. WBSを作成してプロジェクトを推進 対⾯の時はやりながら修正できたが、 リモートだと意⾒のずれが⽬⽴つようになってきた。
- 42. 42 多くの仕事では「戦略」が合意に⾄っていない︕ 戦略は⽴案者の「視座」、および「状況」によって変わってくる。 理解できない戦略が提案された場合、⼤切なのは⽴案者の案を信じれるか否か。 【戦略の定義】 戦略とは、⽬的を達成するために資源（リソース）を配分する選択のこと。 A set of choices to define how to allocate resources in order to achieve an objective ※「戦争論」 Clausewitz, Karl Von（クラウゼヴィッツ）著
- 44. 44 4. 伝わらないの解決策を知る Understanding each other
- 45. 45 （※前出）私の過去の⽅針 ⾃分が発注側で、全国各地リモートワークで過去何回も開発を成功させていた。 管理をしない（効率的︕） 【⽅法論】 • Google Docsを使い、Joelの機能仕様書&デザインドックを準備する • 紹介経由など信頼のおける⼈に開発を依頼する • リモートでも⼗分な実績がある⼈ • 進捗をこまめにチャットツールとドキュメントで共有 • 場合によっては電話で話し、疑問を残さないようにする アイディアの仕事では通⽤しない
- 46. 46 効果的なチームとは何か︖ 真に重要なのは「チームがどのように協⼒してい るか」である。 ⾃分の考えを伝える⽬的が違う • 多くは「理解させよう」としてしまう • それはチーム活動では間違っている。 • ⽬的は「協⼒して問題を解決するため」 効果的なチームとは何かを知る –re:Work https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/introduction/ この⽬的に適した伝え⽅がある
- 47. 47 チームでドキュメントを完成させる • ⾃分1⼈でドキュメントを完成させない。 • ⾃分が作るのは「議論のためのたたき台」と認識する。 • 課題を明確にし、意⾒をいれる空欄を作る。 この活動のために「⼼理的安全性」が必要となる。 ※私の初期のしくじりは、この形式だけを真似て⼼理的安全性の確保を 怠ったため、チームメンバーに遠慮が⽣まれたこと。
- 50. 50 教育の失敗 QuarkAだけでなく、対⾯で伝えられないコロナ禍では、様々な失敗。 • 教える量が膨⼤で細かいことが伝わらない • まったく想定と違う成果物ができる。 • しかも伝わっていないことに後から気づく • 教える側も時間がなくしんどい • 1⼈の知識と経験のある⼈間に負荷が偏りがち
- 52. 52 考え⽅を変える 「理解させる」という考え⽅から「どうやったら勝⼿に成⻑するか︖」に変える。 • 教育しない • ⾃分で育ってもらう • 苦⼿をカバーさせるより、チーム内でより得意が活きるように伸ばす
- 56. 56 まとめ Summary
- 57. 57 コロナ禍で注⽬を浴びるリモートワーク u リモートの⽅が効率的なのでは︖ u ⼈付き合いの⾯倒が減る︖ u 住む場所や採⽤が多様化する︖ YES! 問題が発⽣したら誠実に向き合おう
- 58. 58 5つのコツ 1. 仕事の種類を⾒極める 1. 課題を明確にし、チームワークの必要性を⾒極める 2. 孤⽴させない 1. 急がば回れ。⼼理的安全性を⾼めるために、最初に⾃分は「怖くない⼈」だと伝える 3. 戦略で揉めることを知る 1. 必ず戦略を作成し、チームメンバーで共有しておく 4. 伝わらないの解決法を知る 1. 伝える⽬的を間違えない。「チームで協⼒するため」に伝える。 5. 教育を変える 1. 各メンバー⾃ら育ってもらう環境を作る
- 59. 59 ⼀般的な通説 ü チャットで効率化 ü 資料など可視化が⼤切 ü 雑談が⼤切 ü ツールを使いこなせ ü 同じ時間に働いてテレビ会議を繋ぎっぱなしに ü さぼる⼈はどう管理したらいいいか︖ ü ⻑時間働くのを避けるには︖ 原則をおさえれば応⽤が利く
- 60. 60
- 62. 62
- 64. 64 鉄鋼王 アンドリュー・カーネギー ⼈間、優れた仕事をするためには、 ⾃分⼀⼈でやるよりも、他⼈の助 けを借りるほうが、良いものが出来 ると悟ったとき、その⼈は偉⼤なる 成⻑を遂げるのである。
- 66. 66 出典 写真・イラスト https://pixabay.com/ja/ https://www.photo-ac.com/ ITエンジニアが考える「継続的なリモートワーク実施のための課題」とは –マイナビニュース Branding Engineerが全国の20〜50歳のITエンジニア、プログラマー(男⼥)400⼈を対象にインターネットで実施 https://news.mynavi.jp/article/20200424-1023453/ 効果的なチームとは何かを知る –re:Work https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/introduction/ パーソル総合研究所 https://rc.persol-group.co.jp/news/files/telework3-2.pdf プロジェクト成功確率向上の近道とは︖(寺⽥英雄） - @IT https://www.atmarkit.co.jp/ait/kw/project_doc.html The ultimate guide to remote work https://zapier.com/learn/remote-work/#teamwork