吉祥寺.pm16 で登壇してきました (後編 2/3)
後編 1/3 の続きです。
Talk3: スクラムマスターやってみた(papix)
前々回 でお話しされていた スクラムやってみた の続編でした。
冒頭で 続いていなかったらここにいないので、ちゃんと続いています とのことで、ワクワクします。 今回も泰然自若とした独特の語り調で、やはりこう漫談でも鑑賞しているのかなという気にさせるんですが、内容は濃密そのもの。
スプリントは1wから2wになった
やはり1wは早すぎるんだろうなあと。僕もやったことあるけどやはり2wになったなーと思うなどしてました。 計測できる一定の期間ってあるよなあ。
カンバンが物理になった
前回はgithubのprojectだったっておっしゃってたけど、Issueがあるし、ユーザーストーリーとタスクが混じるので物理になったとのことでした。
でもリモートの人が多い場合だとどうなるかは今でも気になるなあ…と思っていたら以下の方法で実践されてるかたもいらして安心。
自分のところは, GitHubProject + Asanaでやっています。 #kichijojipm
— micchie🍻WWGT (@micchiebear) 2018年11月22日
デイリースクラムがある
座るってのMTGスタイルだと、どうしても長くなるよな。毎日必要なものだから実施するのはわかるけど、だからこそより短く。 というわけで物理カンバンの前でスタンディングにした結果、シンプルに早く終わるようになったとのこと。
とはいえ雑になるわけでも大事なことがすっ飛ばされるわけでもなく、ちゃんと振り返りで気持ちの共有とかしてるところはさすがだな、と思いました。
企画(ユーザーストーリー)と開発タスクのカンバンがある
次のスプリントに何が入ってくるのか、それがどのくらい練られているのか、どのくらいエンジニア側に共有され対話されているのか。 そういったことを重視した結果、カンバン(というかレーンかな)が分かれたってことなんだろうな。
企画カンバンはユーザーストーリーのIssueが集まる、次のスプリントどうするか、オーナーの説明をバックログ整備会をスプリントの真ん中に実施。プロダクトオーナー準備完了レーンが次の優先度の高いもの。なるほどー。 #kichijojipm
— まみー (@mamy1326) 2018年11月22日
対話を重視する
ユーザーストーリーを考える側との対話を重視する、というのも非常に共感を持てました。 何より「本当に必要なのか」とか「やるならどこまで」「エンジニアとどのくらい共有できてる?」が明確になっていくので、よりスクラムが回るよな、って思いながら聞いてました。
きっとこの一文に集約されてると思います。
ユーザーストーリのブラッシュアップができる段階、実装の検討が必要な段階を経て、準備完了(開発に着手できる) #kichijojipm
— める@12/16はアンサンブルコンテスト! (@c5meru) 2018年11月22日
KPTは飽きる
わかるし、形骸化するし、毎週とかやる意味がない場合もあるよなって思いつつ。たぶん月イチくらいで良いんだと思う。大事なのはKPTよりも、きっと気持ちや状態の共有なんじゃないかな、と思っていたら次にその話が出てきて「なるほど!」ってなってました。
重視すべきは出来事、気持ち、投票
タスクやってる時どういう気持ちだったかとか共有するのすごい大事だよな、カンバンやってスクラムやるんだからそれがないと意味がないよなって思いました。 僕も経験したことあるんですが、なんか不安だったり、しんどかったりするの、タスクを実行してる時はわかるんですけど、じゃあ振り返りってなったときって忘れてるんですよね。
なので、振り返りシートに感情を込めて書いていって、気持ちの欄を作って、出来事と気持ちを書いてよかった悪かったを数値化する。 あーすごいなこれ。それをみんなと共有するのがすごいなって思いつつ、良いチーム作ってるなーと頷くばかり。
感情を見える化すると、その時のチームの状態とリンクしていることに気づいたりするとのことで、今後人が増えたりしていった時に参考にしたいな。感情を色分けするってのもすごい。
そしてやはり、これ大事だなってタイムライン見ながら思いました。
プロダクトオーナーからのコミットメントが自然に達成されるような仕組み作りの重要さをひしひしと感じる。 #kichijojipm
— Korenari (@Korenari_D) 2018年11月22日
あと、同じくタイムライン見ていてこれ良いなあって思いました。
弊社のKPT、Keep Problem Try と ありがとう(最近GJになったけれど)があって、会がほっこりした感じになる #kichijojipm
— トーカナイザの守護霊 (@mackee_w) 2018年11月22日
アジャイルやスクラムにゴールはない
僕の意訳ですけど、進み続けるわけだから、ゴールはないんだよな。本とは違う現実があって、そのチームのやプロダクトの特性、オーナーが求めるもの、感情、などなど、数値化して見える化してこそ、みんなどんな気持ちで仕事してるのかわかる。
それってやっぱり人間同士がやってるからだよね、ってことを教えてもらったような気がします。
Talk4: 起業クエスト(Yoshitaka Kawashima)
このかたのトークというかプレイというか、筆舌に尽くしがたい! 今までの登壇スタイルを根底から覆しつつ、圧倒的な実装、物量、丁寧さ、情報量をこれでもかと伝えてくれる。
トークはRPGツクールで作った「起業クエスト」を実際にプレイしながら、起業のために必要なものを解説しつつ、しんどかったこととか大事なことをしっかり丁寧に「ゲーム内のコンテンツやアイテムとして」伝えてくれました。
いやー、これはすごかった。 だってね、登壇者が持ってるの、PCじゃなくコントローラーなんですよw
しかも「BGM必要ですよね」ってスマホでドラクエの音楽流したりして、アドリブもすごいw
しかしまだ途中までの内容だったようで、オチが黒塗りの車に衝突して終了w
ギットクエストの作者さんでもあるらしく、ここでプレイできます。
起業クエストの公開も待ち遠しい!
LT3: プロキシサーバを作って覚えるHTTP(tsucchi)
Perlでプロキシサーバを作って覚えるHTTPということで、様々なハマりどころとソースコードでわかりやすいトーク。
確かにPHPとかだとあんまり意識しないかもしれないなーと思いつつ、Real World HTTPを読み進める時にGoでHTTPサーバ作って色々試したなー、本の内容にもHTTP通信の大事なところ書いてあったし、それやってなかったら理解が曖昧だったな、と思いながら視聴しました。
やっぱり作って覚えるのが一番!
LT4: なぜ私はPerlでコーディングするのか@吉祥寺.pm16(Korenari_D)
理由:「はやい、やすい、うまい」
確かにPerlは宣言など特にしなくとも、いきなりif文とかに正規表現が使えるんだよな、15年前に使ってたなー、と思い出しながら聞いてました。
いやこれすごく便利で、おかげで当時は正規表現を難なく使いこなせてたんだけど、今じゃすっかり落ちぶれてしまった…。
この正規表現リテラル、正規表現を言語処理系でコンパイルして使い回すそうで、実行速度が向上するそう。なるほど全く知らなかったぜ。
LT5: 転生したら会社がわかれていた件(setoazusa)
安定のせとあずさん。
緊急で全社員にお伝えしたいことがあるので集合、と言われて悪い予感しかしなかったら、10周年記念で会社を分けるという話からスタート。なぜw
毎回面倒ごとを引き受けては解決していくその姿は、もうポジティブさしか感じない、という5分間でした!
自分でやりたい方向に調整していくのすごいよなあ。
LT6: スタートアップで 開発速度を上げるためにやった事(kakakazuma20)
スタートアップ、限られたリソースで速度をあげるつらさ。 それを1年半頑張った結果を発表とのことで楽しみ。
iOSとAndroidの開発効率について、iOSで開発して有用な機能ならAndroidへ。その際の開発担当は同じ人間にする。なぜなら知見も仕様も把握していて、開発工数が減りバグが少なくなる。
UseCase層のコードはかなりの部分で使いまわせるそうです。なるほど! Swift/Kotlinで関数名、変数名も可能な限り同じにできるらしい。
次は採用の話。お試しで働いてもらう制度があるそうで、これは本当にいい取り組みだと思う。 僕も以前面接受けて内定いただいた会社さんで1日就業をしたのだけど、そのおかげで中の雰囲気やサポート体制、チームの状態、雰囲気、自分が働くことの想像、など、可能な限りの現実を体験できるんですよね。
当然こちらの技術力や人柄もわかるわけで、お互いにとっていいことしかない。
体験就業の場合に気をつけてることは、
- 基本リモートだけど週一でMTGしてご飯にいく
- コミュニケーション多くして好きになってもらう
- 強いコミットは求めない
- とはいえ期待値は伝える
- 成果じゃなく時間ベースの報酬
- 相手が業務中に返事が必要なコミュニケーションを求めない
- 相手が退職してないからかな?
- 自分たちで巻き取る覚悟をもつ
とのこと。すごく考えられていてルール化されていて、ちゃんと運用されて実績あげてるんだなあ、ということがわかる内容でした。
今後受け入れ側になった時、参考にせねばと思いました。
LT7: エンジニア、こわくない(sironekotoro)
エンジニア以外の立場から見たエンジニアについて、ということで。遭遇したエンジニアの第一印象「めっちゃ怖い」w
人によるしなんとも言えないけど、突き刺さるような雰囲気を纏ってる時って確かにあるある。僕もないとは言えない。 あーなんかこう、みんなの前にいる時は「いつでもウェルカム」という空気を出すよう心がけているのだけど、それ以上にSlackなどでフランクに冗談を交えながらも会話が毎日進んでいくような環境なら、怖いってこともかなり少なくなるんだろうなと思ったりしました。
で、エンジニア以外っていうけどこのかた、エンジニアを知るためにエンジニアリングを学んで知識水準を合わせて行ったってのが本当にすごい。尊敬します。
CSをやられているだけでも、お客さんのフロントに立ってくれているからこその部分も大きいのに、Linux勉強したりして、親しみを覚えていくのって本当にすごいです。
でも僕としては、できれば両方が歩み寄れればいいなって思います。
エンジニアに聞く前に共通言語を増やしてコミュニケーションを円滑にする。エンジニア側としても見習いたい。どっちも仲良くなればいいじゃないって思ったりする。 #kichijojipm
— まみー (@mamy1326) 2018年11月22日
あと、最初から優しいエンジニアもいたw とか、知識が上がると転職して行ったw とか、笑えないけど笑っちゃうところも素敵でした。
LT8: 隙間家具OSSのすすめ(fujiwara)
リアルfujiwaraさんを拝見するのは初めて。鎌倉から参戦とのこと。隙間家具OSSの話として、新しい技術を採用すると、技術の隙間がまだ埋まってないことがある。
だから自分で作るのだけど、それをOSSにしちゃいますよってお話でした。
隙間家具は不要になったらサクッと外せるように作る。運用改善して適度に汎用的にして、技術採用の本家が隙間を埋めたらサッと外せる粒度で作る。
実際に作った実例の解説もあったし、実際に数年動いていてその間は業務効率に貢献してたし、隙間家具がやっていたことは本家が埋めても似たような内容になるので適用しやすいんだろうなあ。
で、なぜOSSにするのか。これまた重要な話でした。
- ドキュメントを書く気になる
- READMEくらいは頑張れるモチベーションに
- 過度な社内事情の混入を防ぐ
- 責任分界点を見極め、将来外しやすくなる
- 設計が綺麗になる
- 社内の事情が入っていくと切り離せなくなったりしますよね
- 魔改造が増殖するのを防ぐ
- 独立したパッケージになってるのでそのまま使ってもらえる
あと、OSSを許可してくれる会社にも感謝っておっしゃってたかな。社外秘のないコードって実はたくさんあって、ツールとかはもっと公開しようよって思うことが過去に多かった。
なのですごくわかるなあ、いい文化が今後も広がってくれるといいなあ、と思いながら聞かせていただきました。
あと最後に、本家へのリクエスト大事だし、言えば対応してくれることもあるよ、とのことでした。
AWSのサービスの隙間があったら、要望を送ると優先的に作ってくれることもあるとのこと。 #kichijojipm
— まみー (@mamy1326) 2018年11月22日
全体の感想
尊敬、感謝、がすごく多かったなって思いました。 皆さんの技術力がすごいのは当然ながら、頑張って結果を出した内容だったり、寄り添って「人」を見たり、当たり前なのだけど続けることの大事さだったり、なんていうか、 働く人の人生を垣間見る イベントだったなって思います。
仕事は人生からも生活からも切り離せない。だからこそそこにいる人たちと頑張っていくために何をしているのか。 業界を世界を技術をよくしていくにはどうしたらいいのか。
そんなことを着実に、かつ楽しく、効率的に、でも人間らしく実践されている方達だったなあ、って思い返しています。
本当に楽しかった吉祥寺.pm、でもまだ終わらないんですよね。
トークの合間、休憩時間、撤収中、懇親会。
そこでの感想も次に書こうと思います。
というわけで次に続きます!