生煮えなことを話したいし話して欲しい
この記事は株式会社エス・エム・エス Advent Calendar 2023の15日目の記事です。
https://qiita.com/advent-calendar/2023/bm-sms
リモートワーク以前にはあった「間」や「場」がなくなったことにより、チームメンバーの「生煮え」なことを話したり、聞いたりする機会が減ったと思っていて、意識的に行動を起こさないといけないと思っている。
リモートワーク以前でも難しく完璧にできていなかったと思っていて、より難しくなったというニュアンス。
「生煮え」とは
この記事内では以下のようなことを指している。
- 整理できていない考え途中のもの
- ただ単に今考えていること
- ただの感想
リモートワーク以前にはあった「間」や「場」とは
リモート以前のことを思い返すと、意図せずに発生するちょっとした「間」や「場」で話したりすることで、その場で話すこともあれば、持ち帰って改めてちゃんと話したりするきっかけになったことがあったなと思っている。
例えば以下のようなもの。
- 自販機前でたまたま会う
- 物理カンバン前でたまたま会う
- 打ち合わせ終わった後の移動時間
- 業務時間後の帰り際
- 飲みの場
など
なぜ生煮えな考えを相手に話したいのか
「考えを整理してもらったり、後押しして欲しい」
自分だけだと悩みすぎたり、考えすぎて行動できなかったりすることが多い。 そういうときに、こうすればいいんじゃない?とか、良い考えだと思うのでやってみるのがよさそうとか、一緒にやりませんかとか言ってもらえると一歩前に進めることがある。
なぜ生煮えな考えを相手に話して欲しいのか
「どういうことを日頃考えているか知りたいし、モヤモヤしているなら一緒に考えたりして気持ちよく仕事がしたい」
日頃考えていることを知ることで、発言の背景が汲み取れたり、考えていることやどういうことを気にするのか知っているからこそ、腹の中を探るみたいなことをせずともちょっと言いにくいけど大事なことが言えるようになると思っている。
他の人が考えていることを一緒に考えたりすることもできますし、自分が持ってない視点で考える物事を考えるきっかけになったりする。
誰かがもっているモヤモヤからチームとして上手くいっていないことを改善するきっかけにもなる。
試してみたこと
雑談タイム
週に1回30分 雑談しましょうという時間をとってみた。
試してみた結果として、親睦を深めたり会話しやすくするためみたいな、自己紹介の延長みたいな意味合いで機能することはあっても「生煮え」の相談をする場としては機能しづらかった。
雑談会という名前をつけて雑談しようとすると、「雑談している状態」というより、なにもない中でなにか話さなくてはいけない!というプレッシャーがかかり、堅い会話になりがちだったり、だんだん話題がなくなって続かなくなるということがおきた。
「雑談している状態」とは、複数人がリラックスして同じ場にいる状態で、結果的に起きることがある事象だと考えているので、雑談が自然発生するような「間」や「場」を設計していくことが重要だと思っている。
整理できていないことでもなんでも話す時間
毎日20分 チームの一部のメンバーで、話すことがなければすぐ解散という前提で時間をとっている。
試してみた結果として、普段は別のことをやっていてゆっくり会話しない人と「生煮え」の話をする「場」としては機能することがたまにある形になっていて今も続けている。
言葉にできない課題感が話せたり、この場に集まっていたからこの話できた!みたいなことが毎日じゃなくていいけど、やってるうちに数回起きたら成功だと思っているみたいなことをすり合わせをした上で会を始めた。
「雑談タイム」と違って会の意図を伝えた上で実施していて、うまく活用できたら良いねぐらいの認識をメンバーがもっているので無理に絞り出すことをせずに実施できていると考えている。
加えて毎日時間をとることで、週1回開催と比べて「生煮え」になっているタイミングと会の時間がぶつかりやすく、毎日会があるのでこのために何か考えておかなきゃというプレッシャーも緩和されていると思っている。
ただ、この時間自体は多くの人が集まると話しにくくなることも気にして、特定のメンバーのみで行なっているため、チーム全体に効果があるものではない。
今後
1人でも多くの人が「生煮え」なことを出すことを通して、何か前に進んだり、お互いの理解が進むようになると良いなと思っている。
「生煮え」なことを出すことが目的ではなく、あくまで何か前に進んだり、お互いの理解が進んでいけるようになる方がメインで、「生煮え」なことを出すというのは出すと促進されると思っている仮説ではあるので、そこを間違えないようにしたい。
その上で具体的に試してみたいと考えていること
似たような課題感を持っているチームメンバーがいるので「生煮え」なことを話しても大丈夫な「場」があると認識をもつ、もってもらうためにSlackチャンネルを作って、チャンネルの意図を周知し「生煮え」なことを自発的に書いていく
- 手段についてはohbarye さん の Working Out Loud 大声作業(しなさい)を流用しようと考えている
- Atsushi Sakai さんの(マネジメントの密度を高める (エス・エム・エス Advent Calendar 2023) に紹介されている活動を、Slack上で見ていて自分のチームでも流用できるのではという考えに至り検討をしている
打ち合わせ最中だと自分の考えを言うことを遠慮したりする場合があり、「間」がないので打ち合わせの最後に打ち合わせの感想を書いたり話す時間を設けてみる
- 手段については、@kedamattiさんの リモートワークにおけるファシリテーションの方法論[増補版]_COPILOTを流用しようと考えている
- 社内で上記スライドを用いた輪読会を行った際に、「間」を作り出すひとつの手段になりうるのではないかという考えに至り検討をしている
最後に
本記事自体も、まさにこれからブラッシュアップしていく前提の「生煮え」な考えを吐き出しているので、誰かの考えの刺激になったり、フィードバックをもらって自分の考えを深められたら嬉しい。
チームの状況を明確にするためにインセプションデッキの一部を使って話してみた
なぜインセプションデッキを作ろうと思ったか
1. 今後やることなどを考える余力がでてきた
やらなきゃいけないことが山住みで、何をしたいか考える余裕もなくただ作るしかなかった。
状況が変わってきた。
やりたいことを考える余裕ができた時てきて、やるタスクどうしよっかねー・・・って話に。
そこでチームの方向性をすり合わせて行きたいなという流れになった。
2. 良いチームメンバーだけどお互い何を考えているか知らない
優しく居心地がよく良いメンバーだとはチーム全員が思っているけど、それぞれがどんなことが得意で何して欲しいかなど(期待)が不明確で、なんかいい感じに空気読んでやってるけど、これでよかったんだっけという不安感があったり、ほんとはどういうところで頼っていいのか、どういうことがしたいのかがわからないという話があった。
方向性を決めて立ち向かっていく時辛い時は必ずくる。そういう時にこそ協力し合える関係を作っていくべきだなと(自分が)思っていた。
インセプションデッキのどの部分を作ったか
1. 我々はなぜここにいるのか
方向性を決めるためになんでここにいるんだっけ、どういうことを核として持っているチームなのかを明確にするための一歩目として作成
2. 俺たちのAチーム
チームメンバーが何を考えているのか、何が得意なのかなどを明らかにすることによって、頼ったり頼られたり、迷いなく行動したりするための一歩目にするために作成
上記以外のものについては、チームメンバーのやる施策ごとに変わると思うという話になり、今回は実施しないことにした。
反応はどうだったか
以下のような内容が出てきた。
- 目指すところ、立ち戻るところを言語化できたのはよかった
- これで迷いがなくなりそうな感覚を得た
- 「言語化したことを定期的に見直す」というところの具体的な取り組みも決めないと、いつの間にか忘れそうだなと思った
- こういったチームビルディングの方法があると知れてよかった
- 他のメンバーの考えを言葉で知れたのでよかった
- 自分の考えとメンバーの考えのギャップをすり合わせられたのは良かった
- こういった取り組みの「効果」を比較したい。やった場合とやってない場合の比較(これからやっていく)
- 自分たちの目指すところを短い言葉として表現することで、その内容が身近なものになり、日々の判断にある程度自信が持てそうと思った (言葉の選択をみんなで試行錯誤する過程も認識のすり合わせに効果があると感じた)
- 自分の仕事への関わり方が今の状態で大丈夫かなという不安がたまにあるので、メンバーから期待されることを教えてもらったことで、安心してその方向に進めると思った - 自分自身がチームにどんな貢献ができるのか、どんな役割が期待されているのか迷ったり悩んでしまう事があったので、よい取り組みだなと思いました。
どういう流れで作ったか
我々はなぜここにいるのか
それぞれが思うチームの我々がなぜにここにいるのか事前に考えてきてもらい発表
共通点をフセンにだしてみたり、どう言うものがキーワードになりそうかを話ながら並べる
キーワード一つ一つに対して、深掘りをする
叩きにするものを選んでチームとしての我々はなぜここにいるのかを明文化する
(かなり時間かかったので、早い段階で投票で誰のが叩きとして良さそうか選んで、そこから足したり引いたりするのが良いかもという話がふりかえりで出た)
俺たちのAチーム
スプレッドシートにあらかじめ以下をいれてもらう
- 自分はなぜここにいるのか
- このチームで実現させたい世界
- 自分は何が得意なのか
- 自分はどうやって貢献するつもりか
- 価値観と地雷(地雷とはxxされたら悲しいとか、怒るとかそういうもの)
- それぞれのチームメンバーに期待していること
当日はそのスプレッドシートを上から読んで、気になるところとか共感するところなど感想を言い合う
今後の話
やってよかったと言う声はあるので、また状況が変わったり時間がたつと考えも変わるのでそう言う時の変化を話したりする時にまたやると効果がありそうだなと思った。
実施後1ヵ月ぐらいたった個人的な感想
- お互いがどう言うところが得意だからお願いしようとか、やりたいとかそういう会話を聴く回数が増えた
- 地雷がどこかを覚えているので、あ。このパターンはxxさん嫌いなやつですね・・・!気をつけよみたいな会話が生まれている
- あまり話さないけど熱い想いを持っているから聞いてみようとか任せてみようとか考えられるようになって遠慮が減った(自分が)
もともとお互いを尊重するチームだったのもあるけど、 より変な距離感がなくなって、お互いの良いところを認識して具体的に活かし合おうとするような動きが見えるようになってきてとても良いなと思った。
いちエンジニアがCSPO研修に参加した結果
参加した研修
認定スクラムプロダクトオーナー研修 by James Coplien
参加目的
POをやるやらないに関係なく、 何を考えているのか知って、視座を切り替えられるようにするため。
やれる人がいなくなった時に、いないから何も出来ないではなくやれるようにしておくため
POって何を背負っているのか
- ROI(ここでは価値)を最大化すること
- 大事なことは、「価値を何と置くか」
- プロダクトによって儲けだけが価値ではない場合があるため
背負ったものを実現するためにやっていることは
- ビジョンを創り伝える
- 価値を届けるためのプロダクトバックログの優先順を決める
- その価値あるプロダクトを形にできるようにチームに伝える
- 予算やスケジュールやリスクも管理する
それぞれの細かいプラクティス
- 今回は書くといっぱいになるので書かない
改めて心に残った話
チームのコミットメントを甘く見てはいけないよね
チームは常に見積もりして、毎週ゴールに対して全力を尽くしている。 そこに、「やること増えちゃったてへぺろ。」って言われると 「そんな簡単に増やすなら見積もる意味ないし全力でやる意味なくね・・・」って全力でやる気が冷めるよなーと思った。
だから、状況の変化に対応するのは大事だけど、本当に増やさない理由を真剣に考えないといけないし、これを追加するとこのままでいくよりも価値提供できることを真剣に伝えて理解してもらわないといけないなと思った。
要件や調査の漏れが発生する理由って・・・
「人がいなくなるからだよね。」
すごいシンプルな答えだった。
チームが続くことっていいよねとか、チームの学習って大事だよねって漠然と思っていたけど、近頃人が増えたり、周りのビジネスの変化の早さについていくために並列で動かしたいって時が多くて、誰が入ってもできるようにならないとダメだよねとか色々考えて、チームって継続する意味ってあるんだっけ(ここが飛躍していたことには気づいてない)みたいになってしまっていた。
それが、やっぱりチームが続くといいことあるよねって、強いよねってシンプルに思えた。属人化が良い訳ではないので、それは別問題で、続くチーム作りができたら学習したことは残るし、毎回細かい認識合わせみたいなのしなくても仕事が進むよねってそれだけのことだよねって。
ベロシティに対して真剣に向き合えてなかったな・・・
人が減ったり、やることが増えていたり、やりながら気づいたことがあったのに、悩んでばっかで相談せず抱え込んで再計画するのが遅くなって無理が生じた時があった。
何かが変わったら、そりゃそのままでは行くわけないからすぐ再計画しないと。
まず開発チームを集めてそのままでいけるのか、
↓
いけないなら、何か違うことを試せるか
↓
それもないなら、チームの外に助けを出せるのか(ここまでが、開発チームでも考えられること)
↓
それができないなってなったらPOの判断する領域に踏み込み
↓
スコープを減らせないか
↓
それでもどうしようもないってなったらスプリントを緊急停止
今度から一人で悩んでないで、上から順に動き出そう。
なぜ変化に対応できるようにしないといけないのか
変化の対応って大事だし、変化が激しいから対応しなきゃってとても浅い整理だったけどしっくりした表現を聞けた。
扱っているものが「後発的な要求が発生する」から。
今やっていることは、ビジネスの状況、人の状況、周辺技術の状況なで後発的要求が発生する難しい。
まとめ
いちメンバーであればPOの情熱を理解する努力をしたいし、全員が伝わってる状態にしたいなって思ったし、わからなかったら素直に伝えてみる。 そうやって理解したビジョンを、ずれないようにエンドユーザに提供していけるように学習していく。
POであれば、考えてるだけではなく、その情熱をメンバーに伝えてみる。 そして変化する状況の中で「価値」あるものになっているのか自分で情報収集したり、開発チームの力も頼りながら、価値あるものになるようにアップデートしていく。
インプット量が多かったので整理するのが大変なので、 取り急ぎ今回知りたかったことと、印象に残ったことを書いて見た。
Elastic Beanstalkのトラブルシューティングに役立ったlog
背景
Elastic Beanstalkで環境構築するときに、マネジメントコンソールだけみててもエラーの理由がよくわからず詰んでいたときに、助けられたので紹介
linuxの場合のlogの場所
/var/log/eb-activity.log
(公式ドキュメントにも書いてあります) docs.aws.amazon.com
感想
このlogを見るようになってから、エラーが出るまでにどこまで動いて、何をしたかなど追えるようになったので、自分の設定のどこが悪いか気づけました。
エラーちゃんと読もう。ちゃんとlog見よう。って心から思いました。
yii2 で「joinWith」した側のテーブルの値を取得
背景
yii2 のアクティブレコードにて、リレーションしていて「joinWith」で結合したのだが、joinした相手の値を取得できずに困ったので記録しておく
joinWith参考:ActiveQuery, yii\db\ActiveQuery | API Documentation for Yii 2.0 | Yii PHP Framework
起きた問題
用意していたテーブル
①hoge_sourceテーブル
- id
- code
- created_at
②hoge_source_associations
- id
- hoge_source_id ← ①のidとforeignkey
- huga_destination_id
- value
- is_public
- created_at
書いていたコード
$hogeSource = HogeSource::find()->joinWith('hogeSourceAssociations') ->where([ HogeSourceAssociation::tableName(). '.is_public' => true, HogeSource::tableName(). '.code' => $code, ])->one();
アクティブレコードの結果
SELECT `hoge_source`.* FROM ....
上記のように、`hoge._source`.* になってしまうので
$hogeSource->value;
とやっても、
hoge_source_associationsテーブルのvalueが取れない。
解決策
$hogeSource->hogeSourceAssociations[0]->value;
ってやってリレーション先から値をとってくることで解決した。
まとめ
リレーション先から取得することで一旦解決はしたが、もっといい方法があれば知りたいなー
Elastic Beanstalkの.ebextentionのパスが通らない
背景
elasticbeanstalkで環境構築しようとしたときに「.ebextention」パスがうまく通らなくて苦戦したのでメモ
原因
GitHubからコードをzipダウンロードしたときに、不要なディレクトリがはいることによって、ebextensionのパスが通らなくなっていた。
elastick beanstalkの「container_commands」に記述したもののワーキングディレクトリは、「/var/app/ondeck/」。
しかしGitHubから落とすと「/var/app/ondeck/test-hogehoge/」みたいに不要な階層が入ってしまう。
ebextentionのコマンド関係で No such file or directory って出て来ていたら疑ってみると良い。
解決方法
GitHubで落としたものを一度解凍し、フォルダで圧縮せず必要なファイルを選択して圧縮する。
※MACの場合は、zipの中に不要なディレクトリが「__MACOSX」できるので削除しなければならない。ここも苦戦の原因になった・・・。
大規模プロジェクトのキックオフでやったことを整理して発表した
毎日全社の前で朝会発表の時間があり、順番が回ってきたので、 初めて経験した大きなプロジェクトを蹴り出すまでのプロセスを自分なりに整理して発表してみた。
ざっくり内容
プロジェクトで実現したいことから、作るものの認識をチームの中で揃えて開発スタートするためのバックログを出すところまでの一部分をまとめたもの。 (今回は、インセプションデッキの作成して、フロー作って、ユーザストーリマッピングを書いてって感じだった)
#発表に使ったスライド
www.slideshare.net
発表後に出た印象的だった質問
Q.プロジェクトの目的のすり合わせから機能リストを出すまでに、なんども見直しとかしたくなってやめどきが難しいなと思うことがあります。今回はどうしましたか?
A.背骨の機能からまずは、考えてあとは、時間と、同じところで議論がぐるぐる回っていたり、あとは決めの問題だよねーとかって言葉が出てきたタイミングで、今これ以上話してもよりよくはならなそうだねーって空気になった時に一旦区切った気がします。
質問に回答してから思ったこと
- 実際いいものを作りたい、考慮漏れを少なくしたいって思うと永遠と話してしまうしやめどきって確かに難しいなと思った。終わった後1日後に考慮漏れとか、やっぱりきになるところがあるとか出てきたし。
思ったことから考えてみたこと
どうやっても完璧なものはできないかなと思うので、
やっぱり時間決めてそこで、無駄なループした会話を減らしたり、みんなが話せるような空気にしたりして、その時その場は出し切ったと思えるまでやる。
後はやって見なきゃ見つからないこととかもあるのでやってみる。 やっていったら見えてくる問題を、つどつどリカバリプランを考えながら進めるしかないのではないかなと思った。
完成品ができてからやろうと思ったら一歩も進めない。