アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
気まぐれ上司 - Mitsuyuki.Shiiba
金曜日の夜は、娘の習い事のお迎えに行って、二人で自転車で帰ってくる。いつも決まった道を通って帰ってる。 でも、昨日は少し違った。お迎えに行った帰り道、娘がいつもの道を行こうとするので、とめた。「今日は、そっちじゃなくてこっちの道で帰るよ」 「あ、そうなんだ」というので「うん」って言って二人でそっちの道を帰る。しばらくぼーっとしたあとに「なんでだと思う？」と聞いてみる「なぞなぞ？」「ううん」 娘は少し考えてみて「んー、なんで？気分？」「ううん、今日は習い事短くて帰ってくるの早かったでしょう？」「うん」「だからだよ」 「あーあっちの道は今の時間はまだ人がたくさんいるからか」「そうそう、あっちの方が近いんだけどね」「そっか、なるほどね」 といいつつ、もう別のことを考えてそうだったので、今日にはもう忘れてるだろうな。 しばらくぼーっとしてるときに考えたのは、これって上司が気まぐれに見えてしまうのと
これからは git restore を使ってみようかな - Mitsuyuki.Shiiba
Gitの基本的な使い方のおさらいをチームのLearning Sessionでやろうかなと思ってドキュメントを眺めてたら、あれ？こんなんあったっけ？と思うコマンドがあった。 git restore と git switch Git 2.23で導入されたみたい。去年の夏か。 https://github.blog/2019-08-16-highlights-from-git-2-23/ まだExperimentalみたいだけど、面白そうなので触ってみた。今日は git restore の話。git switch はまた気が向いたら。 https://git-scm.com/docs/git-restore ## リストアの前にWorking Treeとかの話をざっくり GitにはWorking TreeとStaging AreaとGit Directoryという3つの場所がある。 file.t
知らない技術は怖い - Mitsuyuki.Shiiba
AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう？ 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか？
同じものを見てもらおう。弱さも見せよう。 - Mitsuyuki.Shiiba
とあるチームのリーダー的な人たちから「ちょっと相談したいことがあるんですけどいいですか？」って言われて「はいー。暇ですよ」って話を聞いた。 ## 相談 「実は、進捗が遅れているので、どうしたらいいかと思いまして」 うん。 「リカバリーするために、こういう風に動いてもらえないか？とメンバーに提案しようかなと思うんですけど、本当にこれでいいのか迷ってて・・・どう思いますか？」 ## うーん まず、分かってると思うけど、頑張りによるリカバリーは、ないよね。だって、今まででもチームは手を抜かずに全力で一番良いと思う方法でやってるもんね。 だから、リカバリーとして考えられるのは2つ： スコープを削る もうちょっと良いやり方がないか実験してみる 今提案しようとしてるのは、後者ってことよね。それは悪くないと思うし、メンバーも従ってくれるとは思うよ。でも ## それよりも そもそも「メンバーが自分たちと同
#devkan で喋りましたー「新しいメンバーがチームにやってきた時に行うこと」 - Mitsuyuki.Shiiba
devlove-kansai.doorkeeper.jp 「新しいメンバーがチームにやってきた時に行うこと」ってテーマで準備してたら「ペアプロかモブプロやっといたら良さそう」になってしまって「それもなぁ・・・」ってなってたら「そもそもみんなどういうことで困ってるんだろう？」と疑問に思ったので、みんなに教えてもらうことにしました。 出来上がりはこちら。 DevKanのみんなすごい。やっとむさん直伝のサイレントグルーピング？ってのでみんながもくもくとグルーピングしてくれた！ ドキュメントがないとか、放置されるとか、聞きにくいとかで困った経験があって、だからドキュメントを整備したり、聞きやすい環境を作ったりしといてあげたら良さそうだねーってなって。まぁペアプロとかモブプロとかやってたらドキュメント読んどいて、もなくていいよねーって話。 コミュニケーションの部分の参考までに、自分の考えを共有した。
2時間スプリントでソロ、ペア、モブ、学習セッションを実験した - Mitsuyuki.Shiiba
忘れる前に走り書き的にメモ。 ## Day0 実験の場をゲット！ とあるチームのテックリードから「助けて欲しい」という相談があった。話を聞くと、プロジェクトが遅れている状況で、まだ大きく分けて3つの技術的課題が残ってて、でも、チームはその技術にあまり詳しくないので先が見えなくて不安。ということみたい。 チームの構成は、プロダクトオーナー、テックリード、エンジニア2人の4人チーム。開発手法にはスクラムを採用してる。スプリント期間は2週間。 「いいよー。水曜から金曜の3日間だけなら手伝えるし、それで不安は解決できると思う。スプリントはその間は止めようかな」と言いながら、折角だから実験させてもらおうかなと思い、条件を出した。「この3日間は全員がこの課題解決を最優先すること」それから「僕の好きにやらせてもらうねー」。 実験してみたかったのは、別々に作業するのと一緒に作業するのとではどっちがどうなん
学習を日常の開発に取り込むこと - Mitsuyuki.Shiiba
去年ぐらいから、学習を日常の開発に取り込むことについて考えている。学習は何か特別なことがあるときにだけ実行するものではなく、開発チームの中に常にあるべきものだという気がしているから。だけど、それを周りの色んな考えを持った人たちに伝えられるほどには整理できていない。ので考えている。 そんなときにRSGT2019に参加したのだけど、今落ち着いて思い返してみればChrisの基調講演がまさにそれだった。ので彼の「Learning to Experiment」を思い出しつつ、この辺を参考にしたりしながら自分の中で整理をすることにした。 www.agilealliance.org ## 変化のための実験 変化してなくてもしばらくはうまくいってるように見えるけど、気づいたときにはもう手遅れ。世界は変わり続けてるし、競合は変化に適応し続けてるから。 でも、緊急事態に陥ったときには、これまでのやり方を変えて
サービスエンジニアとサービス開発と3年後 - Mitsuyuki.Shiiba
最近何人かからキャリアパスの相談を受けてて、話をしているうちに自分の考えが少し整理できた気がするので忘れる前にメモ。雑記。 ## サービスエンジニア 僕の今いる部署に求められてるエンジニアは、技術をコアにしたエンジニアじゃなくて、サービスをコアにしたエンジニアだと思ってる。図の左側。技術を突き詰めて「この技術で何ができるか」というよりも、サービスのことを考えて「このサービスのためにあの技術が使えないか」という感じ。 ## アプリ開発とサービス開発 Webアプリの開発経験が10年以上あります、って人よりも、新卒の2,3年目の人の方が頼りになったりして、どういうところなんだろうなぁ？って思ってたんだけど。アプリ開発スキル、と、サービス開発スキル、が別のスキルってことなのかもしれない。 サービスを開発するときは、アプリの機能を実装するだけじゃなくて、全体のアーキテクチャ、インフラ、ビジネス側の運
たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ
組織を改善するときは足すより引く感じで - Mitsuyuki.Shiiba
僕は数年前に改善グループってのを立ち上げて、部内の他のグループに行ってそこの改善を手伝うみたいな活動をしてる。開発の進め方の改善をしたり、アーキテクチャーの改善をしたり、他のグループの人どうしをつないだり、とか。そういう感じのこと。 そしたら、この前「うちの部署の改善活動の参考にしたいから、意見交換しようー」って、他の部署の人が話をしに来てくれて、そのおかげでぼやーっと感覚でやってた自分の頭の中が少し言葉にできたのでメモ。 良くないの こういうのは良くないよねーって話をしたのが。 上からの指示で改善活動をさせられてるけど意味分からん。 みたいなの。 良くないの２ でも、こういうのも良くないよねーって話をしたのが。トップダウンじゃうまくいかないから現場を中心にしよう！ってことで 「ぜひ自分たちで問題と思ってるところを出して、それを改善する方法を考えて、実施してください！」みたいなの。 結局そ
開発チームで、この人が居ないとだめだ！て状況 - Mitsuyuki.Shiiba
は過渡期としてはありなんだけど、そこで立ち止まってしまうと、良くなさそうだなぁって思う。 その本人が「自分が居ないとこのチームはダメだ」ってところに居場所を見つけて、心地良いと思いはじめたり。 さらに「自分はこんなに役に立ってるのに、どうしてメンバーは受け身なままで成長してくれないんだろう？」って上から見はじめたり。 そういう感じになると良くない。 チームの次のステップとしては、そういう状況を早く脱出して、誰もがそれをできるようになって、次のレベルの「それぞれが持ち味を発揮する」というところに行けると良いんだけど。 本人は、そこに行けない原因をメンバーのせいにして「自分は問題ないのにメンバーがいけてない」と思ってたりする。「自分は誰にも教わらずにできるようになったのに！」って。 最初はそういう風に「誰にも教わらずに色んな失敗を繰り返しながら知識を得る人」が必要なんだけど、そういう人が居る状
k8sでロギングってどんなやり方があるんかな？ - Mitsuyuki.Shiiba
と思ってここを読んでみたら面白かった。 kubernetes.io 理解したことをざっくりと書くと コンテナレベルからクラスタレベルへ Dockerからログを出力したとして、コンテナがクラッシュしたりノードが落ちたりしたときでもログは見られるようにしときたいよね。だから、ログの保存先は別にしといて、コンテナとかノードとかとは違うライフサイクルで管理したい。てのがクラスタレベルロギングって呼ばれてるコンセプト。 クラスタレベルロギングの前に基本とノードレベルの紹介から。 k8sのロギングの基本 コンテナから stdout とか stderr に出しとくと kubectl logs で見られる。 ノードレベルのロギング (Image from https://kubernetes.io/docs/concepts/cluster-administration/logging/ ) コンテナから
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba
devlove-kansai.doorkeeper.jp モブプログラミングやってきました！面白かったー。疲れたー。面白かったー。 モブプログラミングって？ チーム全員(プロダクトオーナー含む)が集まって、1人だけがコードを書いて、それがスクリーンに映しだされてて、その他の人みんなでやいやい言いながらものを作っていく。というスタイル。ルールは「ドライバー(コードを書いてる人)は、ナビゲーター(周りでやいやい言ってる人)に言われた通りにコードを書く。ドライバーが自分で考えてコードを書くのはダメ。」という感じ。 やってみた 7人ぐらいのチームで、プロダクトオーナーからのお題に対してTDDで実装をやってみた。2部制でやったのだけど、第1部はKotlin + IntelliJ IDEAでローマ数字の計算を。Kotlin全く知らないし、IntelliJも全然慣れてない。第2部はJavaで自動販売機を
Headless ChromeをDockerに入れてGebで遊んでみた - Mitsuyuki.Shiiba
昨日書いたんだけど、Kafkaを触ろうと思ってるんだよ？でも、触ろう触ろうと思ってると、違うものが目に入ってくるのであった。ということで Headless Chromeで遊んでみた Kafka一切関係なく、この記事を見かけたから。 Getting Started with Headless Chrome | Web | Google Developers この辺のこともあるので、ちょっと見とこうかなって。 Phantom.jsのメンテナー、プロジェクトの将来に疑問を呈し、その座を降りる ただ、今手元にある環境でごにょごにょするのもなんか嫌だなぁ・・・って思ったので、無駄にDockerに詰め込んでGebで遊んでみた。そして、そのせいで疲れた(ヽ´ω`) できあがったものは これ。 https://github.com/bufferings/sandbox-gebheadlesschr
#jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀｀)∩ - Mitsuyuki.Shiiba
楽しかった！ DDD & Microservices with Spring Cloud 前半がこれまで僕が経験してきたDDD 後半がこれからのために素振りしておきたいこと これまで僕が経験してきたDDD 最近、組織について考えるようになってきたのもあって「境界づけられたコンテキスト」が一番大切だなって実感してる。全てを一度に相手にするのではなく、切り取られた世界を作って、その中で適用していく。その切り取られた世界の間の関係性もデザインしていく。そうすることで複雑さを手に負える大きさでコントロールできる。 DDDを知った当初は、エンジニアとしてEntityやValueObjectのところが面白いなーって思ってゴニョゴニョコード書いてたりしてたんだけど、しばらくして「もっと良いコード書くためにはその土台となるチームづくりをしなきゃ！」と思ってスクラムを導入してたんだけど、しばらくして「チーム
もっと瞬殺で作るMesos + Marathon + Dockerクラスタ環境 on Azure - Mitsuyuki.Shiiba
この牛尾さんの記事からまだ1年半くらいしか経ってないのに、もうほんとに色々と変化の流れが速すぎて、僕はもう少し枯れたところでどんぐり拾いみたいなのするのが好きなのに、どうしてこうなった感。 qiita.com 僕のこの記事自体ももう来年には古くなってるんだろうな。あ、なので、2016年10月現在の情報ですので注意してくださいー。 Microservicesの素振り環境 Microservicesって仕事でいきなり「やってみたい！」って言って導入できるようなもんじゃないなって思って。技術力も運用力も組織力も、色んなもののレベルが高くないとひどく失敗してしまいそうだなって。とはいっても、結構色んな問題を解決してくれる一面もありそうだから、まずはどんなものなのか、技術的に少し体験しておきたい。というのが動機。 Javaが好きなので、Spring Cloudで作ったアプリをDockerに入れて、複
エンタープライズエンジニア - Mitsuyuki.Shiiba
「エンタープライズエンジニア」って聞くと「社畜エンジニア？」とか「Excel方眼紙が得意そう？」って思ったりするのかな？これは、去年僕のチームにOJT(On the Job Training)に来てたカナダ出身の海外新卒のメンバーが言った言葉で、すごく印象に残ってる。 彼のコメントは「OJTの前は『エンジニアになりたい』と思ってたけど今は『エンタープライズエンジニアになりたい』と思ってる」ってことだった。つまり、エンジニアとして技術力を発揮するだけじゃなくて、それが会社に、ビジネスに、そして社会に貢献していけることにつながっているエンジニアになりたいってコメント。ちょっとスマートすぎて「あぁ僕はこういう世代と競い合っていかなきゃいけないんだなぁ」って思い知らされたのであった。 で、ぼんやり考えてた↓こういうことも、彼の言う「エンタープライズエンジニア」だなって思ったのでメモ。 この前、色々
自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba
プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
