Yunicode

永田ゆにこのブログです

違和感を無視しないで大事にする

最近チームで話すときにファシリテーションで大事にしていることは「メンバーがどこで違和感を感じているのか」を注意深く見る、ということです。

少しでも「( ・⊝・ )?」「( ˘•ω•˘ )?」って顔をするタイミングを見逃さない。

チームのエンジニアは、納得していないとき、何か疑問が残るとき、は絶対に納得していない顔をします。でも本人は最初「何に違和感を感じているか」よくわかっていなかったりするので発言はしない。なのでここで必ず声を掛けます。そうして、その違和感を丁寧に拾い上げて紐解いていくと、実は他のメンバーがそれまで誰も気づいていなかった課題に辿り着いたりする。本人が始めからそれを「課題」として認識していなくても「なんか変だな」という違和感がアラートになり話すきっかけにできる。

ここのシーンで見逃して先に進んでたら、結局後戻りになってまたここに来てたな、ということも少なくない。特に見落としていることがなかったとしても、そこの違和感についてきちんと話すことにより、本人の理解が深まり、腹落ち感がより得られるので、その先のコミュニケーションが少なくて済んだりします。

違和感を大事にするメリット

  • 話が進んでいるけど何か見落としていることに気づける
  • 腹落ちせずに進んでしまうことを避けられる
  • チーム内で大きな齟齬が生まれない
  • 腹落ち・納得することで熱量・コミット感が高まる
  • 結果的にコミュニケーションコストが抑えられる

違和感を大事にするデメリット

  • 時間がかかるのでめんどくさく感じるときもある

本質を理解しているとデメリットはさして問題じゃないので、ほぼメリットのみですね。違和感はすごく大事だと思います。幸い、いまのチームではそれを放置して前に進むことができない人ばかりなので、一見めんどくさく感じることもあるんですが、結果としてはそこがすごく安心できます。

というわけで、長期的な戦略に取り組んでいく上では、こういうコミュニケーションにとことん投資した方が、先でのエラーが少なくて済み良いです、という話でした。

構造的な文章を書くトレーニングはSlackでできる

ロケットスタートという会社の頃、自分の言葉は話すことも書くことも、全く構造的ではありませんでした。

たとえば誰かに何か相談をしても、まず最初に要点の整理を相手にしてもらってから本題、みたいになり、相談内容へ行く前の事前整理にすごく時間を使ってしまっていました。
ここをもっとできると、そのぶんの時間を肝心の相談内容や解決法に時間を割けるのでは、と思い、構造を整理しながら話す、ということを意識し始めました。話すときだけでなく、文章にアウトプットをする場合も同じで構造的になるようにしています。

構造的に文章が書けると、

  • 言いたいことが伝わりやすい
  • 相手に何をしてほしいか伝わりやすい
  • 記録に残しやすい(時間が経っても意味がわかる)
  • 結果自分も相手も時間が節約できる

みたいなメリットがあると思います。

個人的に、マークダウンで書かれた文章が一番理解しやすい。文章を整理するという意味ではマークアップとほぼ同じなので、デザイナーやエンジニアの人には馴染みがあるのかな。文章が整理され、要点をしっかり抑えることができ非常に良いです。いまはそこそこ書けるようになってきたと思います。

構造的な文章を身につける手段としては、

  • マークダウンで議事録をとる
  • Slackでの文章も構造を意識して送る

の2点をやってます。

マークダウンで議事録をとる、は議事録じゃなくてもいいんですが「話を聴きながらマークダウンで構造の整理しながらメモる」をやりまくるとだんだん整理をしながら話を聞く癖がつきます。カンファレンスへ行ったときに実践するとか。余談ですがnanapiはQiita:Teamを導入しており、Qiitaはマークダウンに対応しているので、そのまま議事録をアップできて便利。このブログもマークダウンに対応してます。

Slackで送るような短い文章も、構造を意識して書くようにしています。特に誰かに何かを依頼する場合。

xxxで使われているyyyに関して、zzzしたいと考えておりまして今プロトタイプを作成しております。そのプロトタイプに関してご確認いただきたいのですが、aaaa日の午前11時〜お時間をいただくことは可能でしょうか?プロトタイプの内容に関してはその打ち合わせ前日にはお送りするようにします

xxxで使われているyyyをzzzしたいと考えております。

プロトタイプを作成しましたので確認させてください。

確認いただきたいポイントは以下です。

  • ほげほげ
  • ふがふが
  • ぴよぴよ

mtgの日程は、aa日11:00はいかがでしょうか?

より詳細は追って前日にはお送りします。

みたいな感じでしょうか。

伝えたいことをだらだら書くのではなく、どうしたら簡潔にできるか。日々意識し積み重ねていくと、相手にも一層伝わりやすくなりますし、自身のトレーニングにもなり一石二鳥です。nanapiチーム内でも、伝わらない文章だと相手の時間を無駄にしてしまうので、なるべくロスタイムを生まないような伝え方をしよう、と共有しています。

しかしながら、すべての会話を構造的に意識してしまうと、それはそれでchannelが殺伐としてしまうので、適材適所というのはある。
エモい気持ちを伝えたいとき、エモいコンテンツをつくるときは、逆になにも意識しない方が伝わったりする場合もあるので、構造的な文章のすべてが正義というわけではないかなと思います。

しょうもない失敗をしてメンバーに許してもらいたいときは、わざとバカな感じの発言をして許してもらってます!

どこの話をしているのか確認しながら話すと結果無駄な時間を抑えることができる

nanapiメンバーでミーティングをするときにやってることを書いてみます。

f:id:yunico_jp:20180219135240p:plain

いつも新しい何かを話すときは、最初に↑の図を書いて、これから何の話をしようとしているかを、一番上段のAから確認します。最初の5〜10分くらいです。特にC、具体的な手法の話をしようとしているときは特に意識してこの確認をします。

目的は以下。

  • 上段にあるAとB「目的」「やり方」から順に確認していくことで「なぜやるのか」を再確認
  • 手段の話で盛り上がりすぎるのを防ぐ(Cの話をする場合)
  • 全員の熱量と目線の高さを合わせる

よく見かける、戦略・作戦・戦術っぽいですが、そこまでちゃんとしたものでなくてもよくて「目的からちゃんとブレイクダウンした上で、これから何を話そうとしているか/何を話すべきか」だけわかれば良い。この図があると、より可視化できるのでサッと書いてます。

これからCの具体的な施策(新機能の実装や、なんかキャンペーンとか)について話そうとしている場合、Cより上のAかBに空白、もしくは不透明なままの箇所があるなら、そこを埋めてからCの話したほうが良くない?というアラートにもなる。そこを空白にしたままそこより先の話をしてしまうと、すすんでからズレがわかり、場合によってはすごい後戻りになってしまうので。密なコミュニケーションをとってる同士でも、あとになって齟齬が発覚して無駄な時間が発生する、ということがわりとあります。

AとBのところが明確になって、じゃあ具体的なCの話をしようか、というときも、

  • AとBを実現するCは今から話そうとしているaでいいの?
  • その他にbやcになりうる案はないか検討した?
  • aとbとcがあったら本当にaが最適って明確なんだっけ?

も、一応話しとく。「aを実装したらBが実現しそう」っていう手段やアセットから逆算で考えるのとか、勢いで「一旦aをまずは実装してみますか」みたいなのをやりがちなんですが、サービス開発ってそんなに簡単なものじゃないし、経験上ほとんどうまくいかない印象。趣味やサークル的な集まりだったらいいけど、自分は天才でもないんで仕事ではあんまりやっちゃだめなやり方だと思ってます。

あと時々ブレストが白熱すると、どっか一箇所にフォーカスしてめちゃくちゃ話込んじゃったりするんですが、一旦落ち着いて↑の図で「今どこの話してるんだっけ?」を確認すると、いまそこの話をすべきかどうかが冷静にわかっていいです。Bを固めようとしているのに、まだ決まってもないbの案について白熱してもしかたないですからね…。そんなバカなことある?って感じなんですが意外にやってしまうんです、、

そこはファシリテーターとかプロジェクトを引っ張るリーダーがズレのないように牽引せえよ、とも思いますが、誰かひとりだけがわかっててもみんながついてきてないとあんまり意味ない。プロジェクトはチームで進めるものなので、全員の腹落ちのためだったり、意識を揃える意味でも、毎回こういう丁寧な確認をしていく方が、結果無駄な時間を抑えられるんじゃないかなーと思います。

今のチームのメンバーはこの辺の理解があり面倒臭がらず確認してくれるし、手段の目的化もやめようと意識しあってます。どのプロジェクト、チームにも応用できるものかはわかんないですが、今のチームではこのように進めていて結構うまくいっています、という話でした。

これからのnanapiを考える

暮らしの情報サイトnanapiは、2009年9月から始まり、2018年の9月で丸9年です。

わたしは、今いるSupership株式会社、の前身、株式会社nanapi、の前身、株式会社ロケットスタート、に入社してから、2018年で9年目になりました。ほぼnanapiと同じく時を過ごしているということになります。

もともとnanapiは、ユーザーにレシピを書いてもらうというCGMスタイルで、わたしはそのうちの熱心なユーザーの一人でした。受託デザインしか経験のないなか、熱量のみでデザイナーとして5人目の社員として迎え入れていただき、最初の3年ぐらいはとんでもないポンコツでしたが、たくさんの人に支えられながらここまできて、今はnanapiのプロデューサーをしています。ずっとnanapiとともに、たくさんの人に出会い、いろんな歴史をみてきました。

2015年にnanapi社がM&Aされ、カルチャーや事業内容に大きな変化が起き多くの人が去る中で、まだここにいます。いまだにぬるく残ってる、などと言われたりもしますが、実際そういう時期もありました。でもぬるく残るにはつらすぎることもたくさんあった。辞めたいと思って辞めようとしたこともあります。それらを乗り越えてここに残り、そしてずっとそこにあったnanapiを、もう一度このタイミングで、自分が中心となり再起させようと思っています。

なぜ再起か。いまのnanapiはとても好調とは言えない状況で、それは昨年の年末にリニューアルしたときにCodeIQさんでも取材していただき別に隠してもないんですが、とにかくそんなにいい状態ではないです。数字的には、調子が良かった頃にいた人が見たらびっくりするぐらいかもしれない。2016年は本当にいろいろあったので。その辺もCodeIQ見てもらえばいいか。トップの写真がすごいノーテンキなんですが…

next.rikunabi.com


状況としてはそんな良くはないけれど、いろいろあったことが逆に追い風となり、ようやく「本当にnanapiの価値を提供する」という本質のところにテコを入れられそうです。今まではGoogle検索の延長上に存在していたnanapiですが、これからは「○○だったらnanapi」と言ってもらうものを作りたい。インターネット上に様々なメディアがある中で、こういうところはnanapiだよね、って思ってもらえるところを作り、価値提供していきたいです。いま、いろんな人に協力してもらながら設計・構築中。

nanapiのツイッターの方はなかなか好調だったりします。フォロワーも10万を超え、ユーザーさんともいい感じでコミュニケーションがはかれています。需要があるのはやっぱり季節もの。シーズナルに関するコンテンツがツイッター上では必要とされています。nanapiは生活や暮らしの情報サイトなので、バズったりするような派手さはないものの、必要なときに必要な情報をいい感じに届けること(わたしたちはそれを「実家感」と呼んでいる)が使命なんじゃないかなあと。何か大きなアクションを示したりはできないんですが、実際にこれをどう届ければいいのか、を小さく検証しながら、今後の大きな強みにしていければと思います。

ツイッターを介してユーザーさんとコミュニケーションをとってみると、こちらが発信した情報に対して返ってくる反応の中に、有益なものが含まれていることに気づきます。普通の人の何気ないひとことなんですけど、こちら側では気づけなかった光るものが混ざってる。nanapiとして提供する情報に、そんなユーザーの方からもらった新たな情報を付加価値として追加していけると、そのレシピを次に見た人がもっと良い体験をできるんじゃないかと。ただ情報を発信しコンテンツを消費していくだけでなく、それぞれに価値を持たせて蓄積していく、蓄積したものを良きタイミングで提供する、をnanapiならではのやり方で実現できればいいなあと思っています。

「○○だったらnanapi」を築き上げるのはもちろん大変。きっと時間もかかる。特段派手でもないことを地道にやり続けていくことは一見つまんなくも見えたりもする。でもいまは、メディアもブランドが信頼が大事で、それを獲得するには高い熱量で地道にやり続けるしかない、という時代が来ている気もします。もう量産とかハックとか思いつきとかではやれない時代なんじゃないかなーと。いまはnanapiを理解してサポートしてくれる人たちもいるし、足の長い戦略を理解して日々足元を固めてくれるメンバーもいて、なんかできそうな気がします。自分たちの中の正義を定義して設計し考え抜きやり通す、の繰り返し、をみんなとやりたい。あと、ここまで共にきたんだからという意地と、勝手な責任みたいなものもあったりなかったり。

というわけで、12/20に全面リニューアルした以外、外からはあんまり見えないんですがこんなことを考えて日々がんばっていますよということを書いてみました。本質を考え直すのはすごい楽しいです。これからはそのチーム内でのあれこれや、プロジェクトを進めていく上でのあれこれなんかを、記録という意味も込めてブログに記していけたらいいなあと思ってます。初回なので長くなりましたが、、

【読書メモ】この1冊ですべてわかる コーチングの基本

些細なことでもアウトプットしていこう〜とか言ってたのにだいぶ間が空いてしまいましたが久しぶりに読書メモ。新しいスキルとしてマネジメントを勉強中。

この1冊ですべてわかる 新版 コーチングの基本

この1冊ですべてわかる 新版 コーチングの基本

感想

本当に基礎の基礎から丁寧に書いてある本で、一年生の人は入門書として必読。

マネジメントというふわっとした形のわかりづらいものに対してなぜコーチングをするのか、どのようにするのか、というところから丁寧に解説がある。「相手にする質問でより効果の出そうな質問例はどんなものがあるか」など一通りの流れなど、具体的なアクションまで書かれているのですぐ実践に活かせそう。取り掛かりとしてはとてもよい本だったと思います。紹介していただけてよかった。

それにしてもマネジメント(コーチング)を実践するのって本で読むと、そりゃそうだろうな〜ってことも多いのだけど、実際にやろうとすると相手も自分も人間なのでそう簡単にはいかないことばかり。とはいえ、そんなあれこれもこの仕事も面白さだと思うので誠実に向き合っていこうと思います。

以下、自分用要約まとめ。 ※手描き

f:id:yunico_jp:20190728123117p:plain

続きを読む

なぜ技術ブログを書くのか?を考える

少し前にホッテントリ入りしていた【転職後1ヶ月目】ガチ未経験でwebエンジニアになって困ったことという記事について、同僚の小川さんが自分のブログで言及をしていた。
blog.koogawa.com

元の記事の内容は「Webエンジニアになったけど些細なこともわからない!」というかんじで、Webエンジニアっていうか、フロントエンドエンジニアなのかな?

元記事に対して、小川さんは「なぜ技術ブログを書くのか」というテーマで書いていて、その中に

なんとなく書いたTipsが意外にも多くの反応を頂けたりすることもあるので(困っていることはみんな一緒だったりする)、どんな些細な事でもアウトプットしていくことが大事なんだなぁ、と思いました。

というものがあった。この「どんな些細な事でもアウトプットしていくことが大事」に対して、わたしも最近同じことを思ったのでそれについて書きます。

旧nanapiブログに載せていた「本当は怖くない!デザイナーがGitを大好きになった♡5つの理由」という記事を先日Qiitaに移行しました。内容は「デザイナーがGitを使ってみたけど実は全然難しくなかったよ!」っていう体験談で、特に便利なTipsとかを書いているわけではないのだけど、公開した初日から2週間で350くらいストックされました。TwitterやFacebookでの言及も多い。

移行する前、nanapiブログに置いてたときも800以上のはてぶがついていたし、ただの体験談がどうしてこんなに注目されるのかな?と考えてみた。Gitに関する情報って世の中に山ほどあるんだけど、もしかしたらこういう「最初にどういう風に感じて、その後どうやって克服していったか」みたいな超超初心者レベルの序章的なものってあまりない気がする。できるようになった人目線のものは多くあるけど、0から1、みたいなレベルのものは他に比べて実は少ないのかもしれない。みんなここから入るのにね。それがデザイナー向けであれば尚更。

このGitの記事の話に限らず「そんなこと、今更わざわざ聞く?」みたいなレベルの情報って意外となくて、でもネット上で「わからない」って言うと、はてぶ等で意見を言う人やツッコミをする人はいるけど、ストックされるような情報にアウトプットしてくれる人は稀。だから「こんなこと今更すぎるけど一応〜」みたいな感じで書くと意外と反応もらえることがある。「新人必見!倍速かつ高品質なバナーを作るためのコツを全公開します」という記事も、誰でもやっていそうなバナー作成の手順を書いてるだけなのだけど、そんな当たり前そうなことでも書いてみると需要があった。そういう話をslackのblogチャンネルで話していたとき、@wadapが「10人が目にすると2〜3人くらい「今更www」とかいう人がいるけど、1人でも役に立つ人がいるならそれでいいよね」と言っていて、本当にそれに尽きると思った。

ふと「前にもこんな話したな?」とデジャヴのようなものを感じて色々思い出してみたら「自分ではできて当たり前と思っていることが、必ずしも他人も当たり前のようにできるわけではない。だからそれをライフレシピにすることで、世界の誰かの役に立つはず」ってけんすうさんがよくnanapiというメディアについて言っていたことだった。そこに共感してnanapiに来たのだから、こういうアウトプットの考え方になるのはある意味当たり前かもしれない?今更だけど。

社内のQiita:Teamも些細なことでもネタっぽいことでも書いておく。意外とあとで何かのヒントになったりするし。Qiita公式でも「Qiitaで春の新生活を応援しましょう!」みたいなこういうのやってていいですね。あと最近、わからない人目線での説明がうまい、と褒められたので、そういうところを生かしつつ、わたしも小川さん同様些細な事でもアウトプットしていこう〜と改めて思いました。

新年度の抱負風にしておわり。FY16もがんばるぞ!

リーダー合宿で学んだこと・得たもの

先日参加したリーダー以上の合宿がすごいいい体験だったので書きます。

概要

日程など

日程は10/16(金),17(土)の2日間。1日目は池尻大橋にある世田谷ものづくり学校で、2日目は会社のフリースペースで行いました。両日とも雨。

参加者

プロジェクト内グループリーダー全員、上司、ファシリテーターの方、合計7名。

1日目:エピソードワーク

目的
  • 相互理解
  • 同じ目標に向かって一致団結する仲間の人となりを理解することで、より推進力をあげる
  • チームワークの形成
ゴール
  • リーダー全員が自分以外の全員のメンバーの人となり、ルーツを開始前以上に理解し本音でコミュニケーションできるようになっている状態

2日目:事業計画発表による目線合わせとアクションプラン作成

目的
  • 中期経営計画の理解
  • 来期の戦略についてアクションプランを作成し目線をあげる
  • チームを引っ張っていける状態
ゴール
  • なんのために誰が何をやるのかを全員が説明できる
  • アクションプランと担当が決まり、翌日からアクションできる状態

1日目:エピソードワーク

9:55世田谷ものづくり学校集合。早めに家を出たが電車遅延。雨の中タクシーを捕まえようにもうまくいかず遅刻。初日の初っ端からいきなりみなさんを待たせてしまいました。申し訳ないです。

人生のターニングポイント3つを各人75分話す

この日は丸1日かけてリーダー全員の話を聞く、というだけの日。それぞれの人生の背景を知ってよりお互いを理解しよう、が目的です。事前に「自分の人生で起こったターニングポイントを3つ、話せるように準備する」という宿題。

一人当たりぶっ続けで75分。ターニングポイントひとつ話し終わったところで、全員から質問タイム。時計回りに2周。質問を考えながら聞くためメモは欠かせません。質問は「相手への理解をより深めるための深掘りするようなもの」という観点で。でも結構興味本位の質問もしちゃいました。

もとよりわたしは思い出話が大好きで、飲みの席などでもよく人に昔の話などをするので、75分も話を聞いてもらい、更に質問で深掘りしてもらえるという時間はすごく楽しかった!自分の人生のターニングポイントは、

  • 2000年上京
  • 2004年新しいネットワークへの参加
  • 2009年ブロガー活動とみんなのレシピnanapiとの出会い

の3つ。深く考えずともこの3つに尽きます。

3つのエピソードとそれぞれの質問、一人分75分が終わったところで、聞いていた側にカードが配られます。そこにいま話を聞いた感想や、話した人への想いを書き発表しつつ手渡します。これが、実際にもらってみるとめちゃくちゃ嬉しい!意外と自分では気づいていなかった性格や能力を知ることができる。こういうところが魅力だと思われていて期待されている、ということもわかるので自信にもなります。

今回初めて同じプロジェクトになったのでお互いまだよく知り合えていなかった人とも理解が深まったし、普段から仲がよく割となんでも知っていると思っていた人とはもっと深くまで知り合えたし、上司への尊敬はより高まりました。これだけに1日かけただけあり、だいぶリーダー内でチームワークもできあがり収穫が多かった1日目でした。

宿題がきつかった

1日目おわり〜!さてチームワークも深まったところで飲みに行きますか〜!とはならない。

実は一週間前から今回の合宿に向けて宿題が出ていたのだけどこれがまじでめちゃ辛かった!w

宿題:自分なりの3カ年の事業計画を作る
  • 19年3月までの通期で売上××億(利益で××億)
  • MAU××××万

という前提があり、そこから自分なりの事業計画を立てる。期間内に目標売上を達成するため「ユーザーニーズ」「マネタイズ」「集客」「差別化」についてバランスよく考えなくてはならない。むちゃくちゃな計画を立てると、MAUは稼いでいてもマネタイズに繋がらなかったり、単価は高いけどそもそもニーズがないからMAUが集まらなそうだったり、ととにかく仮の数字を当ててはその辺の情報を漁りまくって計算しながら計画を立てていく、という感じを延々。

なぜこんなことをするか?

自分がいつも共有される事業計画とはどのようなふうにできあがるのか?そもそも自分の業務のもっと上にはどんなことや数字があるのか?というのを体験し視座を上げるため。正しい数字を算出すること自体は目的ではなく考え方を学ぶ。

直前まで終わらない宿題…!

約一週間前から宿題はもらっていたけど、その週は実務でもバタついていてなかなか時間が取れず、合宿数日前にようやく本腰入れてやり始めたものの全然うまくできない。営業部の人や事業戦略部の人にヒントをもらいつつなんとか形にしていきました。

しかし合宿1日目が終わった時点で進捗は40%程度。次の日に発表だと言うのにまだ資料にまとめるどころかロジックさえも固まっていない状況。めちゃやば!!というわけで、1日目のエピソードワークが終わったところで飲みに行くでもなく、会社に直帰し宿題の続き。普段は買わないレッドブルを飲んでみたり、会社付近のビジネスホテルを検索しまくったりしたけどまじで終わらないので終電で帰宅し、引き続き家で作業。深夜に電卓を叩きまくる!!なんとか形になったのは午前4時…

2日目:事業計画発表による目線合わせとアクションプラン作成

9:00会社集合。3時間睡眠で雨の表参道。宿題がまだ不完全なので朝の電車の中でもやる。

作った事業計画を発表

まずは、資料を各人7分で発表し、5分質疑、3分評価。

結局わたしは弊社の強み、他社との差別化を全面に押し出した事業計画を立てて発表しました。やや現実味はない部分もあったけど、こういう機会なので自分の本当にやりたいと思ったものを盛り込みました。このアドバイスは営業の人にも、事業戦略の人にも言われたこと。いろんな方法でマネタイズとか新規事業も考えたけど、やっぱり自分でやりたいと思えないものはうまくいかない気がしたので。評価はまずまず。やや滑った感があったかと思ったけど上司には褒めてもらえたのでここ数日のがんばりが報われたような気がしましたw

VISION、MISSION、中期事業計画発表

目線を上げたところで、今度は実際に自分のプロジェクト、チームでやっていく中期事業計画を上司から共有いただき、今後何をどうやって達成していくか、を皆で考える。更にそれをブラッシュアップすることで、より自分ごと化。最後に実際行うアクションプランを各チーム毎で具体的に書き出し目に見えるようにまとめます。先ほど発表したとっ散らかった自分の考えた事業計画とは違い、実際の事業計画はロジックが整理されていて実に現実味のあるものだ、、

10月から新しく期が始まったことで、既にチームの持つ数字をどう達成していくかのアクションプランとロードマップは個人的にはまとめていたので、その辺を軸にしながら書きましたが大きな齟齬はなかったと確認でき一安心。しかし、夕方くらいで昨日今日の疲れがピークになり、あまり物事がうまく考えられない状況にw すごいがんばって考えてはいたのですがあまりよく覚えていない…

宣言

チーム毎の具体的なアクションプランが決まったところで宣言をして終わり。宣言は、

  • 自分がコミットして成し遂げること
  • このリーダーズで成し遂げたいこと
  • 次回の全体合宿で取り組むべきこと

の3つをそれぞれ発表。疲れているときにまとめたものでしたが、後日見返してみても納得できるものだったのでよかった。この宣言を中心に、今期も走っていきます!

合宿をしてみて

視座を上げた

一連を通して改めてわかったことは、自分のチームは会社の歯車の一部でしかないこと。チームでの目標だけを追っていても仕方ないこと、全体を見据えてプロジェクトの全員で目指さないといけないこと、ただしチームの歯車がうまく回らないとそもそも全体がうまくいかないこと。自分のチームを俯瞰してみるところから、施策レベルのミニマムな目線まで、柔軟に目標とやるべきことを考えられるようになったと思う。

やはり自分は体育会系

終わったあとのなんか知ってるこの感じ…、これは学生時代の部活の合宿が終わったあとに感じたそれと同じであった。自分に負荷をかけ、乗り越えたあとは爽快感が残る。最中はつらいけど…。

チームワークで何かをする、ということが結構好きなので、根本の「相互理解」みたいな部分をしっかりを作り上げた上でみんなで何かする、みたいなやり方は自分には合っていると感じました。

今度来月はプロジェクト全体の合宿もあるので、今回学んだことをそこで生かせるようにがんばるぞ!


おわり