咳チームは便利 #FM719 - Mitsuyuki.Shiiba
楽しかった みわさんに声をかけていただいて、咳さんとみわさんと僕の3人で Discord で公開おしゃべりをして楽しかった。このお二人を独占しておしゃべりできるなんてとても贅沢だなぁ。 お知らせです!!@bufferings @m_seki @miwa719 の三人でおしゃべりすることになりました。聴きたい方がいましたら、当日このツイートにURLをメンションするので見てくださいね。 日時：10月14日(木) 21:00-22:00 場所：Discord 内容：咳チームがやらないこと、他— miwa (@miwa719) October 7, 2021 テーマ 咳チームはとても興味深い。とても自然体で、僕の中ではひとつの理想のカタチ。その咳チームは、僕だったら大切にしてるようなことをやってなかったりする。こういうの↓ 楽しいとか仲良くとかコミュニケーションとかどうでもいい— seki at
そのふりかえりの改善策って実現可能なのかな？ - Mitsuyuki.Shiiba
大変だったプロジェクトの反省会みたいな振り返りとかで、うまくいかなかったことだけを並べて「反省しています！次からはそうならないように、これこれといった対応をしていきたいと思います。」みたいなのをたまに見る。 そういうときに感じるのは「良かったところを知りたいなー」ってのと「そもそもその改善策って、実現可能なのかな？」ってこと。 ## 信頼していること そもそも僕は、全員が全力でプロジェクトを成功させようとしていたこと、良いものを作ろうとしていたことを信頼している。誰も手を抜いていたわけじゃない。 だから、たくさんの良かったことをまず知りたい。この判断は良かったよね。とか、ここは大変だったけどなんとかなったね。とか。 ## 課題 そのうえで、思った通りに進まなかったということなので、課題を出していく。例えば、Bが思っていた以上に難しかった。とか。 ## それって改善になる？ さて。その課題に
RTCN2017・1時間スプリント・手触り・知識の共有 - Mitsuyuki.Shiiba
今年初開催となる名古屋支社の楽天テクノロジーカンファレンスに行ってきた！面白かったー！今、帰りの新幹線。僕は何かあったときに助けてねってくらいでいたんだけど、何もすることなかったし、みんな楽しんでたし、ピザとチョコとビールとチョコおいしかったし最高だったなー！スタッフのみんなも、来てくださったみなさんも、素敵でした！お疲れ様でした！ さて。そんな中、「名古屋に行くよー！」って言ってたら、なんと、きょんさんが遊びに来てくれて。しかも僕の相談に乗ってくれたのでした。幸せすぎた。ので、そのおすそ分け。 僕の相談？ こんな話: どんな風に開発してる？ どこまで自動化してる？ TDDやってる？ 知識の共有をどんな風にしてる？ ドキュメントは書いてる？ どんな風に開発してる？ スクラムって最大30日で1スプリントとかいうよね。僕のチームはそれよりは短くて10営業日で1スプリントが多いかな。でも、まだ慣
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
「スクラムの価値基準」にピンとこなくてウロウロしてきて、腑に落ちた。 - Mitsuyuki.Shiiba
スクラムガイド2016年版 RSGTの発表のことを色々考えてたら、そもそもスクラムって何だっけー？って思ってしまって、スクラムガイドを読もうとしたら、あれ？2016年版ってのがある http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf さらーっと読みながら、あれー？スクラムの価値基準とかあったっけなー？全然覚えてなかったー。って思ってたら、スクラムガイドの最後に「2016年版ではスクラムの価値基準が追加されたんだよ！」って書いてあって。おー！そーなのかー！って思った。 スクラムの価値基準 Commitment, Courage, Focus, Openness, Respectの5つ。実際にはこんな風に書かれてる: スクラムチームが、確約（commitment）・勇気（courage）・
「スクラムでは割り込みはできません！」って言わなくていいような仕組み - Mitsuyuki.Shiiba
昨日は、娘達とクッキーを作ってて、余った白身でラングドシャクッキーを作って美味しかった。ども。椎葉です。 F-team, L-team 牛尾さんの記事にF-team、L-teamってあるんだけど、これ、今僕のいるチームでやってることだー。って思った。Microsoftさんの最先端のチームと同じ思想に辿り着いてたってことで、なんか嬉しいなー。 simplearchitect.hatenablog.com Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。 だいたいは同じなんだけど、ちょっと違う部分があるのでそれをメモしておく。以前からの流れでOps TeamとDev Teamって呼んでるんだけど、今流行りのDevOpsとは関係ないので注意ね。 Ops Team
「こんな感じの機能ってどれくらいの期間があればできる？」 - Mitsuyuki.Shiiba
って、ふわっと聞かれることって結構あるんだけど。そういうときに、どうしてるっけなぁ？って。 あるかなぁって思うのは 「まずは詳細を決めてくださいよ。そうじゃないと見積ることができません。」かなぁ。でも、それは言わないなぁ。 じゃあ、どう言うっけなぁ？ って思ってたら、今日「こういう実装ならこれくらいの期間でできますよ。もっとリッチにしたいんだったら、もっとかかると思うから相談ね。」って言ってたや。 意見を求められたときに 情報がそろっていないから相手が情報を出してくるのを待つ、ってのはなんか面倒くさくて、相手に何かを出してもらうより先に僕が今できることをしたい。 おまけ 「100%確実とは言えませんけど」みたいな枕詞も、なんか面倒くさいから言わない。「うん、できるよ」って言い切ってしまって、内心ドキドキしてて、でも、できなかったことがあんまりないから、そこにもなんかトリックがありそうだな。
全力で効率の良くないチームをつくる - Mitsuyuki.Shiiba
というのが、最近の僕の好み。 効率の良いチーム 効率の良いチームは、みんなすごく効率良く仕事を頑張ってて。システムも効率良く既存のリソースを使ったりしてて、開発もすごいスピードで進んでいる。 なんだけど、最短の道を選び続けていて、どんどん選択肢がなくなっていって、動きが鈍くなってく。 そうすると、どうするか？「このままじゃダメだ！もっと効率良くやらなきゃ！」ってなって、最後には、頑張り続けて疲れた人が離れていく。そんな感じがする。 効率の良くないチーム きょろきょろしたり、うろうろしてみたりして、選択肢を広げておく。ペアワークとか。暗黙知の共有とか。形式知化とか。新しい技術へのトライとか。そういう、一見、遠回りに見える道の方が、実は近い。という感じがする。リファクタリングとかもそうかな。 遠回りに見える道を選ぶのには、勇気が要るのだけどね。だって、最短に見える道を選んだのにうまくいかなかっ
「それぞれの現場におけるチームづくりの試行錯誤」で色んなことを考えてきました #devkan - Mitsuyuki.Shiiba
今も色々考え中。 devlove-kansai.doorkeeper.jp 岩切さん！ とてかでご一緒させていただいた岩切さんが応援に来てくれました。(∩´∀｀)∩ﾜｰｲ 意外にも初めてのDevLove関西だったんだってー！デブサミ関西行きたいなー！ そして、なんと「ルビィのぼうけん」を会場の方にじゃんけん大会でプレゼントしてくれました！ありがとうございます！ books.rakuten.co.jp 僕も持ってて、娘と読んでて、最初は「少し娘には難しいかな？」と思ったんですけど、全然楽しく一緒に読みながら遊んでます。面白い！たしかに、プログラミングに繋がる感じだなぁって思います。また、その辺色々楽しんだら書こうと思います。 自然とそうなる開発チームをつくるいとなむ 僕は4月の「とちぎテストの会議04」の再演です。娘たちかわいいよ、ってお話です（違う。岩切さんも仰ってましたけど、とてかのとき
DDDの僕の中の印象を絵にするとこんな感じ - Mitsuyuki.Shiiba
Transaction Scriptの方が早いし、分けたりしなくていいのでシンプル。 DDDは関心を分離するのが大変。だけど、分けることができたら、ビジネスの関心事がくっきり浮き上がってくる感じがする。でも、それを理解するのも維持するのもチーム内で共通の認識を持ってないとすぐに、左の方みたいになりそう。 そういう印象。 IDDDの人が新しく入門用？みたいなのを出さはったので読もうとしてるところ。 www.safaribooksonline.com 今週もがんばろー
Domain Driven Design ってこんな感じかなー？ - Mitsuyuki.Shiiba
(追記 20150830) 読んでるときにノートにメモしたやつをマインドマップに起こしておきました。後の自分のために。 DDD20150830.pdf - Google ドライブ ////// Domain Driven Design を読み終わりました。疲れた。books.rakuten.co.jp 数年かけて 数年前に買って、ちょっとは読んでたんだけど。そのときは、EntityやValueObject、Repositoryなどが印象に残ってて。それは今考えるとDDDの中のMODEL-DRIVEN DESIGNの構成要素であって、本質ではなかったんだなぁ。と気づきました。 それにしても、ユビキタス言語さん。 これまでずっと、喋るときは日本語で、コード書くときは英語なので、知らず知らずのうちに、そういうもんだと思ってたんだけど。試しに英語で色々やってみたら、喋ってる言葉がそのままクラス名や
とりあえずDockerの何が良いの？1分で教えてよ！ - Mitsuyuki.Shiiba
遂にちゃんとDockerの勉強を始めた。"Using Docker"という本を読んでる。 www.safaribooksonline.com Safari Books OnlineでいくつかDocker関係の本をあさってみて、この本が一番良さそうだと思ったので読み始めたとこ。 玉川さんが翻訳されるそうなので、細かいニュアンスはそちらが出たら確認しようと思ってる。(おい 今しかできない 今日は、まだDockerについて全然詳しくない今だから感じてるDockerのいいなぁって思うところを書き残しておこうと思う。使い慣れてしまう頃にはもう今の感覚はなくなってると思うので。 ゴールは、誰かあんまり調べる気はない人に「Dockerの何が良いの？」って聞かれたときに「色々あるけど、これかな」って手っ取り早く伝えられたらいいかなってとこ。 とりあえずDockerの何が良いの？1分で教えてよ！ アプリのコ
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
できる人と、足せるけど引けない人と、目に見えないもの。 - Mitsuyuki.Shiiba
できる人、足せるけど引けない人、になってしまうと、気づいたら年老いてるんじゃないかなって印象ある。 気を抜くとそっちに流れていきそうになってる自分がいるので、気をつけようと思います。 できる人 自分が知ってるやり方でできる場合に、新しいやり方を知ろうとしない人。新しく高速道路ができて、そっちを使えば1時間で行けるのに、過去に通ったことがある山道(3時間かかる)以外使おうとしない人。「え？だって、こっちで行けるでしょ？なんでもかんでも新しければいいってワケじゃないよ！」って。 足せるけど引けない人 今までやってきたやり方、たとえばチェックリストとかを、足すことはできるんだけど、引くことができない人。日に日にチェック項目は増えていくんだけど、もう既に要らなくなったチェックや、新しく足されたチェック項目によって過去の10個分のチェックはカバーできてたりするんだけど。消すの怖い。 失敗しない でも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
