学習を日常の開発に取り込むこと - Mitsuyuki.Shiiba
去年ぐらいから、学習を日常の開発に取り込むことについて考えている。学習は何か特別なことがあるときにだけ実行するものではなく、開発チームの中に常にあるべきものだという気がしているから。だけど、それを周りの色んな考えを持った人たちに伝えられるほどには整理できていない。ので考えている。 そんなときにRSGT2019に参加したのだけど、今落ち着いて思い返してみればChrisの基調講演がまさにそれだった。ので彼の「Learning to Experiment」を思い出しつつ、この辺を参考にしたりしながら自分の中で整理をすることにした。 www.agilealliance.org ## 変化のための実験 変化してなくてもしばらくはうまくいってるように見えるけど、気づいたときにはもう手遅れ。世界は変わり続けてるし、競合は変化に適応し続けてるから。 でも、緊急事態に陥ったときには、これまでのやり方を変えて
僕らのモブプログラミングは「全員でプログラミングをする」ということではなかった - Mitsuyuki.Shiiba
## 去年の夏ぐらいからサポートしているチーム で、それまでもちょこちょこモブプログラミングを試してはいたんだけど、3月からは思い切ってそれを基本として開発をするようにした。つまり、3月からは1日中モブプログラミングをするのを毎日やってる。 プログラミングだけじゃなくて、設計も、運用も、テストも、全部モブでやってるので、僕らはそれをモブワークと呼んでる。 ## やっていく中で学んだのは モブプログラミング（モブワーク）は「全員でプログラミングをする」ということではなくて「全員で考えて取り組む」というだけのことだった。 サービスにとってどう動くのが良いかを全員で考える。 目の前のプロジェクトのことだけではなく、少し先を見据えてメンバー間の知識やスキルの共有や、チームがまだ詳しくない分野の学習をすることも含めて、どこにトレードオフスライダーをセットするのが良いかを全員で考える。 ## 全員でプ
実験によってチームのやり方として定着してきたものを6個 - Mitsuyuki.Shiiba
この2ヶ月ぐらいサポートしてるチームで、実験を重ねる中でチームのやり方として定着してきたものがあるので、温かいうちに書いとく。6個ある。 背景 どういう背景かを簡単に： エンジニア4人とリーダー1人、プロデューサーが2人のチーム。全員家からリモートでつないでる。 サポートに入る前はチームは計画重視の指示型開発で全員別々の作業をアサインされて取り組んでいた そこに「自己組織化チームにしたいけどそういう経験者もいないしプロジェクトも忙しい中なのでサポートしてほしい」と声をかけてもらって参加 2週間くらい観察して色々周りを整えたあとにチームに入って、スクラムを導入して1週間スプリントを6回終えたところ 自分はリーダーの代わりに入らせてもらうことにした。まずはチームのやり方を色々変えてしまって、チームが落ち着いてきたら徐々にリーダーと一緒にそのリーダーならではの道を探して、最終的にはそのリーダーに
自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba
プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り
知識創造企業とアジャイル開発とスクラムと自分 - Mitsuyuki.Shiiba
気づかされる日々 最近は、海外出身の人たちと近い距離で仕事をしてて、文化の違いを感じて面白い。そういうところを気にするのか、そこは気にしないのか、とか学びながら、というか、日本人はあの部分は気にしないけど、そこは気にするってことか、みたいに、海外出身の人たちの文化を感じると同時に、日本の文化、それが当たり前すぎて気づくことが難しい部分、に気づかされるような日々を過ごしてた。 そんな中で、自分の中にこういう気持ちがあることにも目を向けさせられた。 スクラムとは違う何か この10年間、スクラムを勉強して、そこから得た学びを元に実践の中に取り入れたりしつつ開発をしてきたのだけど、自分の中では、そろそろいいんじゃないかという気がしているんだなって気づかされた。これまで、スクラムの考え方を基準にして、組織の形や自分の役割やチームのあり方を疑って、改善してこれたと思う。そして、もう十分「良い活動をでき
開発チームのふりかえり - Mitsuyuki.Shiiba
で、どんな話をしてるかなーって思ったけど、こんな感じかなーって思ったので書き出した。多いかな。 最初は事実。 やったこと 学んだこと 次は気持ち。プラスの方から始める。 良かったなって思ったこと 別に続けたいわけじゃないけど、良かったなってこと。トラブルをみんなでさっと解決できたの良かったなーとか。 ありがとうって思ったこと プラスの気持ちの右の方は、行動してみたいこと 続けたいなって思ったこと やめてみたいなと思うこと 次にマイナスの方。マイナスは、他人に対して向けない。場や状況それと自分自身に向ける。 もやっとしてること もやっとしてるけど、特に何もアクションを望んでるわけじゃなくて、ただもやっとしてるなってこと 自分自身に対してへこんだこと マイナスの側の右の方は、より良くするために行動してみたいこと 変えてみたいなと思うこと やめてみたいなと思うこと で、最後にそこから、チームのア
開発チームで、この人が居ないとだめだ！て状況 - Mitsuyuki.Shiiba
は過渡期としてはありなんだけど、そこで立ち止まってしまうと、良くなさそうだなぁって思う。 その本人が「自分が居ないとこのチームはダメだ」ってところに居場所を見つけて、心地良いと思いはじめたり。 さらに「自分はこんなに役に立ってるのに、どうしてメンバーは受け身なままで成長してくれないんだろう？」って上から見はじめたり。 そういう感じになると良くない。 チームの次のステップとしては、そういう状況を早く脱出して、誰もがそれをできるようになって、次のレベルの「それぞれが持ち味を発揮する」というところに行けると良いんだけど。 本人は、そこに行けない原因をメンバーのせいにして「自分は問題ないのにメンバーがいけてない」と思ってたりする。「自分は誰にも教わらずにできるようになったのに！」って。 最初はそういう風に「誰にも教わらずに色んな失敗を繰り返しながら知識を得る人」が必要なんだけど、そういう人が居る状
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
TDDはあんまり使わなくなったけど心の中にある - Mitsuyuki.Shiiba
今日は娘たちとコログ探しして楽しかった。 この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。 良い所がいっぱいある 見失わずに済む 僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。 余計なものを作らなくて済む 「必要なものはこれだよね？」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。 リファクタリングできる まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善
「スクラムの価値基準」にピンとこなくてウロウロしてきて、腑に落ちた。 - 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）・
モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba
devlove-kansai.doorkeeper.jp モブプログラミングやってきました！面白かったー。疲れたー。面白かったー。 モブプログラミングって？ チーム全員(プロダクトオーナー含む)が集まって、1人だけがコードを書いて、それがスクリーンに映しだされてて、その他の人みんなでやいやい言いながらものを作っていく。というスタイル。ルールは「ドライバー(コードを書いてる人)は、ナビゲーター(周りでやいやい言ってる人)に言われた通りにコードを書く。ドライバーが自分で考えてコードを書くのはダメ。」という感じ。 やってみた 7人ぐらいのチームで、プロダクトオーナーからのお題に対してTDDで実装をやってみた。2部制でやったのだけど、第1部はKotlin + IntelliJ IDEAでローマ数字の計算を。Kotlin全く知らないし、IntelliJも全然慣れてない。第2部はJavaで自動販売機を
isValidの書き方 - Mitsuyuki.Shiiba
きっかけ コードのネストを深くするな | anopara を読んで、 僕もネストは浅い方が好きだけどisValid…お前はダメだ。 - bufferings のコメント / はてなブックマーク って書いたら、@m_seki さんに"isValidダメなんだ。どう書けばいいの？"というツッコミを頂いたので。ちょい考えてみた。まぁ、元記事の主題とは関係ないところなので。ゆるりとね。 元々のんは、こんな感じ？ Groovyで書いてみた。 class Data { def Count def Error def Result } class Validator { boolean isValid(Data a) { if(a != null) { if(a.Count > 0) { if(a.Error == null) { if (a.Result != null) return true; }
node.js の logging library の winston のソースを読む - Mitsuyuki.Shiiba
node.js を使い始めて javascript かわいいなーと思い始めたこのごろ まだ javascript の扱い方から勉強してるんだけど そんなわけなのでソースを読んで勉強しようかなと winston を選んでみた winston は nodejitsu 社が作ってる Flatiron ってオープンソースフレームワークのモジュールの一つとして開発されてるす いくつか便利機能があるんすが query とか、例外ハンドリングとか、profiler とか そのへんは今回は触らずにロギング周りを見ていくす この記事は 東京Node学園祭2012 アドベントカレンダー の 26 日目の記事です。 ファイル lib の中身はシンプル ├── winston │ ├── common.js │ ├── config │ │ ├── cli-config.js │ │ ├─
チームづくり - Mitsuyuki.Shiiba
ちょい前に。「向きあう」って。エントリ書いたけど。 じゃ、それで、お前は何をしたのって話。 人に向き合わない あー。いや。メンバーとは向き合うんだけど。そゆことじゃなくて。 人に向かって仕事するわけじゃないよね。 サービスを作ろうとしてるんだから。向くならそっち。 なので、よりよいものを作るためにこうしたい！という喧嘩ならするけど。 僕たちはここまでやったから。あとはあなた達の仕事でしょ！とか。 これ、誰のボールです？とかは。どっか向こうの方でやっといてくれればいい。 向かい合わせで話をしないで。同じ方向を見ようよね。という話。 衝突は内側に チーム立ち上げの時に。普通だったら開発側のリーダーやる人と話をして。 ねぇ。ビジネスサイドの人の味方になってよ。んで。僕は開発チーム引っ張るから。 喧嘩は僕と君の間でしよう。そのほうが部署またいで喧嘩するより色々早い。 緩衝材になる 海外でアジャイル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
