しるろぐスマートフォン用の表示で見るしるろぐいろいろ書きます。この広告は、90日以上更新していないブログに表示しています。勉強会いくつか読書会を開催してきたので、振り返りも兼ねてそれぞれの良いところと悪いところをメモ程度にまとめてみる。自分がやってきてこうだった、という内容なので、他のもっと進行がうまい人がやったなら違う結論になりそう。分類名や分類の仕方は適当。読書会のいいところまず最初に読書会の意義について。本を持ち寄って、ご飯食べたりお酒飲んたりしながらワイワイ本について話す。一人ずつ自分の持ってきた本を5分程度で紹介する時間などを取ると会も引き締まって良い。交換会は、いらない本持ち寄り会になる場合もあってなんともなーという感じになることもある。少人数から大人数まで対応可能。趣味が合わない人が多いと辛い感じになる主に紹介と雑談なので特に結論が決まるということがない毎回違う本好きなメンバーとワイワイして、刺激を受けるのにおすすめ。参加者はそれぞれ本を持ってきて、その場で読んで、感想や意見を言い合う方式。読みながら話してもいいが、読む速度が違う人がいると話が合わないので、節とかページで区切って全員が読み終わってから話すのが良い。その際、札みたいなものを用意して、読み終わったら札を倒す方式にすると全員が読み終わったのが分かりやすくてよい(立てるより倒すほうがわかりやすい)。全員が読み終わるまでの時間を記録したり、会が終わったときに読み終わったページ数を記録するのを続けると、だんだんと読む速度が上がっていくのがわかって楽しい。小出しに読むと分からない系の本には向かない(逆に技術書とかは良い)読む速度が遅い人が遠慮しがちになる問題提起をしたり積極的に話す人がいないと、「うん、なるほどね...」みたいな感じで終わりやすい参加者全員が本を持っていないといけない事前に読む時間が取れない場合や、関連する話や事例などをじっくり吟味して話し合いたいときにおすすめ。大学のゼミとかでよくやるアレ。章ごとに担当を分け、担当者が本の内容を発表・講義する。他の参加者は、発表を聞いて質問したり意見を言ったりする。発表者の内容が正しいとは限らないので、良さそうだなと思ったら、原本を読むことが必要。ある程度理解した状態で読めるのでスイスイ読める。全員がある程度、興味を持った本を対象にすると良い。意識の高い人たち向け。発表者が間違えた場合に、全員が間違えた解釈をしてしまう場合がある発表者によってクオリティが違いすぎる発表者以外はだらけるリスクがある同じ目的や問題意識を持ったメンバーで難しめの本を読むときにおすすめ。輪講形式と違い、参加者全員が対象の本を事前に読んで、議論する。本の内容や分量によっては章ごとに分けて1冊の本を何回かに分けて読む場合もある。一冊丸々の場合は、盛り上がり具合によってすごい時間になることがある。逆に盛り上がらないと時間が余ってしまうので、ちょっと余らせるぐらいの分量を予習するようにしておいて、話が長引いたら次回、にすると良い。予習がかなりアレで、開催頻度が高いと大分つらいので週一はおすすめしない...。参加者全員が本を持っていないといけない深い議論がしたくて、予習の時間を取る時間/意欲があるならおすすめ。本を読むのはおまけ程度で、本を実践するのを主眼に置いた会。読み方は特に決まっていないが、実際に自分で読んだほうが実践しやすいので、「その場で読む会」または「全員が読んでくる会」が良さそう。輪講形式は、先生(発表者)の言ったとおりに、みたいな感じになりやすい感がある。実際の実務に密接に関わった本を選ぶことが多いし、そうしたほうがモチベーションあがる。実践する内容によるが、1日かかることもあれば、実際に業務で試してみてどうだったかを発表するみたいなのをやることもある。本の選定が難しい社外の人とやるときはなかなか事例を出しづらい内容によっては一回でも休むとついていけないことがある実際に手を動かして何かしたいときにおすすめ。まとめ自分はやっぱり一番やってるっていうのもあるけど、その場で読む会が好きだなあ。他の人が開催してくれるならワークショップ形式や交流会は楽しいので参加したい。輪講形式は、それに向いた本やメンバーがいれば全然やっていけると思うので、これから数を重ねていきたい分野。さんの風林火山の話おもしろいなと思ったので真似して分類してみたメモ。顧客の要望に素早く対応し、プロダクトを成長させていくプロダクトマネージャー。立ち上げ直後のプロダクト向きで市場の変化にいち早く対応できる。冷静に市場分析や顧客分析を行い、プロダクトを改善していくプロダクトマネージャー。安定したプロダクト向きで着実に良い製品を作り出す。情熱を持ってチームを整え、強い開発力でプロダクトを飛躍させるプロダクトマネージャー。チームが一丸となり、短期間での目標達成に強い。プロダクトのロードマップを整え、プロダクトの品質を担保するプロダクトマネージャー。一貫した方針でプロダクトのブランドを守り、様々なしがらみからチームを守る。と3人で「チームおにやんま」として参加しました。当日の動きなどは他の二人が書いてくれると思うので、反省点をまとめておきます。昨年のふりかえりはこちら。2016年9月18日isucon.net以下の4チームは、最終スコアは上位10チームを上回っていたものの、それぞれ下記の理由により失格となりました。offがー、再起動がー)にハマったりしていたので、誰か一人が全メンバーのインスタンスでインフラ整えて渡すみたいなことをしておけばよかった。その間に残りのメンバーはアプリケーションの仕様を把握したりコード読んだり。昨年、このような反省をしたので、今回はきっちりと役割分担をした。githubのプルリクもうまく使えて、今回は誰が何をやっているか全員が把握しつつ、一度も作業がバッティングすることなく進められた。落ち着いて作業できたなんか午前中にインフラまわりで時間かけてしまって、進捗ゼロです!みたいなので、お昼の時間も忘れて焦ってしまった*1ので、もっと時間をかっちり決めても良かった音楽流したり、アロマを炊くなどして、精神を整えられた。思わぬ事態に遭遇したときも、固執せずに代替案などに切り替えられたと思う。相談の時間がとれた開始前に、XXXが終わったら相談の時間をとる。XX時になったらアレをする等、相談のルールを決めていたので、3人の方針の認識は統一がとれていたと思う。PROBLEM/TRY前回の反省と違って、細かい作業レベルの反省になってきたのは良さそうに感じる。配れるようにしておけばよかったなと反省。コードもデプロイできるようにする設定等はansibleで配布していたけれど、コード周りは環境でpullしていたのでいっそのことコードも配布できるようにする。早めの締切を作る18:00終了の予定で動いていたため17:00過ぎたあたりから最終調整に入ったが、毎回、最終調整の内容が重く、「あと数分あればかなり改善が見込める変更が反映出来たのに!!!」みたいな状況で終わってしまう。そのため、17:00を提出時間だと思っておくとよさそう。ふせんを使うホワイトボード、githubのissue、slack等情報が分散されてしまったのでタスク等は付箋で管理してみる(分散してそんなに困ったわけではないが、より良く情報を管理できそう)。最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。事前アンケートを用意するメリット話すことが事前に想定できるアンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない(雑談は雑談で良いものだけど)。その場で回答が思いつかなくて適当な返しになることがなくなる(お互いに)自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってからアレコレ思いついて、まあいっか、今度話そ、みたいになって忘れてしまうことがよくあって、それって非常にもったいないなと思っていた。事前に回答を用意する感じになれば、いくらでも悩めるし、アンケート時には思いつかなかったけどあとから「そういえば...」みたいなこともある。事前に準備ができるこれがすごい良くって、スピード感が出る。「会社やチームにこんな不満/要望がある」みたいなことが事前アンケートに書かれていれば、ミーティング前に調整を行って、ミーティング時には「あれ対応しといたよ」みたいなことが言える。報告みたいなフローをとる必要があって、結構面倒だったりする。全員に共有できる内容であれば対応後すぐに報告することもできるのだけれど、内容によっては個別に共有が必要で再度予定確認して会議室とって、みたいになると思いの外時間を使ってしまう原因になる。Aさんの話を聞いた後にBさんの話を聞いたらちょっと見え方が変わってきたみたいなことも多くって、それを事前にみんなの意見を見てからミーティングにのぞめるのも良い。アンケートの内容(レギュラー)常に表示しているアンケート項目。キャリアについて5年後どうなっていたいですか?そのために今年このチームでは何をしたいですか?将来のキャリアプランと計画を聞くことで、今後どのような業務・役割をしてもらうかを判断するために聞いている。場合によってはこのチームにいたら目標に近づけないこともあるので、別のチームを紹介するなど異動の手伝いをすることもある。目標/評価について目標や評価について何か悩んでいること・障害はありますか?期初に決めた目標の進捗がよろしくないみたいなときに、一緒に解決の方向を探るために聞いている。障害であればできる限り取り除き、自己評価と周りの評価が大きく違っていれば認識を合わせたりする。会社/経営についてプロダクト/チームについて一緒に働くメンバーについていろいろなカテゴリでとにかく話したいことがあれば書いてねという項目。ここも同様で、障害であれば取り除いたり、意見や提案であれば、取り入れるか取り入れられない理由を説明する。アンケート項目(季節替わり)チームのフェーズに合わせて変えていく質問。プロダクトをよくするために何をしたいですか?まずはプロダクトのマイルストーンを決めるために、チームメンバーがプロダクトをどう思っているか、どうしたいと思っているかを聞いた。現実的な回答よりは夢を語ってほしかったので、お金や時間やその他もろもろのしがらみを無視して答えてもらった。人によってプロダクトのとらえ方が違っていたので、回答をもとに改めてプロダクトの立ち位置やミッションを共有した。あなたがPMだとしたらプロダクト/チームをどう改善したいですか?ある程度運用を行ったので、それぞれが考えるプロダクトやチームと、PMが決めたマイルストーンとの差異を確認するために聞いた。すごい長文で回答をくれたメンバーもいて熱意が伝わってきたし、自分になかった切り口などを知れてとても勉強になった。今の仕事や環境は、あなたや周りのメンバーの能力をちゃんと引き出せていますか?みんなが同じ方向を向けるようになったので、今度は配置について聞いてみた。ほんとはこれがやりたい、あれがやりたい、みたいなことを期待していたのだけれど、そこは満足度が高くて良かった。かわりに、自分はあの人に以前一緒だったんだけどこういうこともできるので任せてみては?みたいな回答があって、なんか嬉しかった。あなたに与えられた仕事は、おもしろいですか?能力は引き出せているけど、ただの作業になってしまって学びがない、みたいなことを防ぐために聞いてみた。今チームでやっていることで1つだけやめるとしたら何ですか?(一番無駄だと思うことを教えてください)形骸化した習慣を捨てるために聞いてみた。いろいろな意見があったので、きっぱりやめてみたり、やめる検討中。「すごい考えたけど思いつかなかった」みたいな回答もあったけれど、今やっている習慣やフローの必要性や目的を振り返る良い機会になったと思う。まとめといった感じで事前アンケート良いよというお話でした。いう一年を振り返るLTをやりながら飲んだり騒いだりする会をやっているのだけれど、今年は参加できなかったのでブログにまとめておく。普段はいろいろな数値を出してアレコレするんだけど、今回は単純な振り返りで。スポーツ用品この商品を含むブログを見る会社の先輩からJawboneもらったので睡眠時間の計測をはじめたグラフみるだけで楽しい本棚を整理したり、靴や洋服のメンテナンスグッズを買っていたらしい定期的に整理してるけど整理するたびに2,30冊買ってて減らない3月マネジメント回りや感情の制御的な本をよく読んでいたらしい小布施ワイナリーが作った日本酒がおいしい疲れ気味だったので休養もかねて会津出張お酒も料理もおいしいしやすくて最高だった。社内でワークショップ開催したofsilvers.hatenablog.comAmazonプライムでドラえもんとクレヨンしんちゃんの映画ばかり見ているGoogleフォトで写真バックアップ始めたけどとても良い。社内の某プロジェクトのメンバー全員で「チームをつくるワークショップ」というワークショップを開催しました。背景2週間ごとに「チームメンバーの満足度をあげる」というテーマで振り返りを行っていたのですが、KEEPやPROBLEMが直近の物事に左右されがちという問題がありました。この1年でチームメンバーも増え、お互いが何を考えて仕事しているのか、どういう環境が嬉しいのかという情報共有が不足しているように感じました。そこで、1年の振り返りとして、お互いのことを深く知り、自分たちがどんなチームになることを選択するのか、というのを話し合う機会を用意しました。ofsilverswww.slideshare.net流れ4人一組のグループに分かれてもらって、グループごとにワークを行うようにしました。はじめに、以下のような話をして、チームを作る上でお互いのことを知るのが重要だ、みたいなことを話しました。チームを作る上で、メンバーのことを知ることが重要だよ。(自分たちの)チームの目標は、製品のビジョンを達成することに加え、メンバーのサポートをすることだよ。次に、以下の順番で5つのワークをこなしました。チームメンバーをもっと知ろう!個人ワークで自己紹介を考えてもらい、グループ内で自己紹介をしました。自己紹介を作る上で以下のような観点で自己紹介をしてもらうようにしました。理想的なチームについて話そう!過去の経験を元に、それぞれが思う理想的なチームについて考えてもらいました。その後、グループ内で「理想的なチームはどんなチームか」をまとめてもらい、全体に発表をしました。チームの現状を確認しよう!同様に、今のチームはどんなチームであるかをグループでまとめてもらい、全体に発表をしました。何ができるかを考えよう!理想と現実の差は何か、どこを改善すればよいか、どんなことをすればよいか、というのをグループ内でまとめてもらい、全体に発表をしました。4でまとめた課題に対して、各々が何をできるかを付箋にまとめてもらいました。自分が、理想的なチームに向けてできることはもちろん、みんなにやってもらいたいことを発表したり、誰かにやってもらいたいことを書いてその人に渡す、といったことをしました。各グループがまとめてくれた「理想」を右に各グループがまとめてくれた「現実」を左にメンバーごとのアクションカードをその間に貼ったボードを成果物として作成し、ワークショップを終了しました。やってみて感じたこと初めてのワークショップ(参加も開催も)だったのですが、比較的うまく行ったのかなと思います。思っていた以上に話が盛り上がり(特に自己紹介や理想のチーム)時間をオーバーしてしまったので、もう少し余裕を持った時間配分にすると良かったかなと思いました。全体的にワークの時間を2倍ぐらいにしても良い感じでした(印刷に1時間ぐらいかかってスタートが30分弱遅れてしまったの申し訳ない...)。あとは、時間がなくてアクションカードの共有がボードに貼るだけになってしまったけれど、本当は「誰々から誰々へ。理想的なチームにするためにほげほげしてほしいです」とか「私から私へ。理想的なチームにするためにほげほげをします」みたいな感じで宣言するような形をとりたかったなというのが反省点。参加者の反応ワークショップ後にアンケートに回答してもらったのですが、以下のような反応がもらえました(抜粋)。概ね好評だったようです。アクションカードを渡しあうのが面白かったアクションカードを貰えると、自分では気付いけない/気づかない、期待されている事を知れるチームメンバーの自己紹介で改めてどんな人物なのがわかった。全員分聞きたい普段の業務とは違う雰囲気でチームメンバーとのコミュニケーションがとれたところがよかった普段業務でかかわらない人の意見を聞くことができた目標や課題などについて改めて考え直すよい機会となった改めて「よいチームってなんだろう」「自分は何を期待されて何を貢献できるんだろう」と考えつつ、今の仕事を見つめなおせてよかったチームが目指したいこと、個人が目指したいことを考え直すいい機会になった個人の意見や目指すものが知れたこと。今後、コミュニケーションすすめる上での種にできそう普段言うタイミングを逃しがち、明文化されず雑談ベースで話しているような内容を表現出来た特に、他人にアクションカードを渡す部分と、できるだけ普段関わらない人とテーブルが同じになるようにしたのが評価が高かったです。似たようなワークショップがあれば是非参加したい。他のチームもやったほうが良いという回答も多かったので、アップデートしてまた開催できればいいな。逆に反省・改善点としては、ぼくが参加していなかったことホワイトボードが各テーブルにあれば発表楽かも話す時間とまとめる時間を分けてもらえると時間気にしなくていいので嬉しいといったものがありました。と3人で「チームおにやんま」として参加しました。当日の動きなどは他の二人が書いてくれると思うので、反省点をまとめておきます。offがー、再起動がー)にハマったりしていたので、誰か一人が全メンバーのインスタンスでインフラ整えて渡すみたいなことをしておけばよかった。その間に残りのメンバーはアプリケーションの仕様を把握したりコード読んだり。指示出すメンバーが明確に決まっていなくて、それぞれが判断してアプリいじってたり、「AとBとC直そう」みたいに話したあと、誰がどれやる決めてなくて、「誰かがやってると思った」みたいなのがあったので、作業方針が決まったあとに、この作業は誰々、この作業は誰々とちゃんと分担するべきだった。誰が何やっているか分かるようにする(小さい単位でブランチ切る)反省2:みんなで忙しくならない3人が3人ともゴリゴリコード書いていると相談もしづらいし、何かハマったときのヘルプが大変。誰か1人は、計測中心に動きつつ、何か会った時に遊撃手として動けるようにしたほうが良かった。あと開発しやすい環境を整えたり。全体を見る人を立てるその人は実作業はせず、サポートに徹する(ハマった時の聞き役や開発しやすい環境を整えたり)反省3:相談の時間を沢山とるいちおうpt-query-digestで上から順に撲滅していったけど、もうちょい実装方法について共有しても良かった。意見出たけど、どの作業方針が決定稿か、みたいな認識がとれてなかった気がする。全体を見る人を用意する大画面でコードレビューしつつ、方針をコメントしてみる?反省4:あわてないあわてないなんか午前中にインフラまわりで時間かけてしまって、進捗ゼロです!みたいなので、お昼の時間も忘れて焦ってしまった*1ので、もっと時間をかっちり決めても良かった。#isuconTweet広告を非表示にするもっと読むコメントを書く次のページプロフィールid:ofsilversいろいろ書きます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。