2018ふりかえり
総論
ふりかえってみると2018は沢山チャンスをいただけた一年でした。ありがとうございました。 言葉にすると当然なんですけど、目の前のことを頑張る、何かを変える、上手になる、結果を出すみたいなことをまずは頑張って、それを話す、フィードバックしてもらう、よりちゃんと理解する、次のアイデアが生まれる、みたいな好循環ができたな、と思います。
登壇
2月のデブサミがメインでした。
幸い関心を持っていただいた方にリクエストしていただき、複数回再演させていただきました。感謝!
- カンバンによるムダのカイゼンの事例 - DevLOVE関西 | Doorkeeper
- アジャイルな組織って?サービスとチームづくりに最適な開発手法の選び方 #GWD_Nulab | ヌーラボ
- NTTデータアジャイルフォーラムに弊社メンバーが登壇しました。~タウンワークをドライブさせるためになんちゃってアジャイルをやめた話 [プロダクトエンジニアリング部 高橋陽太郎]|ニュース|株式会社リクルートテクノロジーズ
3回目のNTTデータアジャイルフォーラムでの再演スライドは別途上がっています。
タウンワークをドライブさせるためになんちゃってアジャイルをやめた話 - Speaker Deck
海外
アメリカ行ってきました。
Had great time to talk with/ @ChristophLucian . Thank you very much :) pic.twitter.com/qc6XniXmKg
— Yotaro TAKAHASHI (@PoohSunny) August 7, 2018
クリスさんにはいろんなことを伺い、その時紹介してもらった彼のブログエントリーを翻訳しました。 poohsunny.hatenablog.com
Davidさんには今年のDevOpsDays Tokyoでお会いできるみたい!.@ToBeAgile Thank you for your autograph!!! #Agile2018 pic.twitter.com/k6t8RqGMR9
— Yotaro TAKAHASHI (@PoohSunny) August 8, 2018
#DevOpsDaysTokyo 2019、本日より準備がスタート致しました!
— DevOpsDays TOKYO (@DevOpsDaysTokyo) October 23, 2018
開催は4/9(火)4/10(水)の二日間、会場は今年と同じく大崎ブライトコアホールです。
英語キーノートスピーカーはジーン・キム氏とデイヴィッド・バーンスタイン氏にご登壇頂きます。
ウェブサイトは近日中に公開致します。ご期待下さい! pic.twitter.com/Bb5QYXJNWT
Podcast
アメリカでの縁がきっかけでPodcastにも登場させていただきましたー。人生初なので楽しかった。
出版
エキスパートが教えるSelenium最前線 (CodeZine Digital First)
- 作者: 戸田広,島根義和,高橋陽太郎,沖田邦夫,松尾和昭,宮田淳平
- 出版社/メーカー: 翔泳社
- 発売日: 2018/05/15
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
書きました!
お手伝い
レビューでお手伝いさせていただきました!
Effective DevOps ―4本柱による持続可能な組織文化の育て方
- 作者: Jennifer Davis,Ryn Daniels,吉羽龍太郎,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/03/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
監訳者の @ryuzee さんから献本いただきました!! ありがとうございます!!!!
— Yotaro TAKAHASHI (@PoohSunny) March 19, 2018
翻訳レビューで少し携わらせていただきましたが、物理的にも論理的にも厚みのある本なのでみんな読んでモノにしちゃいましょう!! pic.twitter.com/04LYLlk9ng
Mackerelではじめるお手軽Webサービス監視 (技術書典シリーズ(NextPublishing))
- 作者: 大中浩行
- 出版社/メーカー: インプレスR&D
- 発売日: 2018/06/15
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
“id:a-know / id:swimming_pooh / @yenjoj には、レビューで本書の記述の改善に大いに協力いただきました” わーい光栄です! / 「Mackerelではじめるお手軽Webサービス監視」を出版します。 https://t.co/G5MpH7UwRR
— Yotaro TAKAHASHI (@PoohSunny) June 16, 2018
雑誌
紙面には全く登場しなかったのですが、取材していただいて事例が出ています。
プライベート
家を買ったり、子どもが小学校に入ったり、お仕事でいろんなこと任せてもらえるようになったり、手術したりといろんな意味でとても実り多い一年でした。ありがたや。
というわけで今年も実り多き一年にして行きます。
2019
昨年はお世話になりました。今年もよろしくお願いします。
年末年始
今年の年末年始はいろんな計画外に見舞われまして、家のトイレは詰まり、長男がインフルにかかり、年をまたいでそれが私にもうつり、と久々に家にこもりっきりでした(さらにこのブログを書いてる瞬間次男も発熱)。計画外でしたが、インフルについては予防接種のおかげで重症化せずにすみ、トイレについては昨年引っ越した結果トイレ二つあるのでクリティカルな問題は起きず、ということで、予期できるリスクにあらかじめ備えておくことと、予期できないリスクに負けないように大事なものを冗長化しておくことの重要さを再認識できました。
とはいえずっと寝ていたかというとそうではなく、長男と私は回復期にポケモンをやっておりました。長男がピカチュウ で私がイーブイで遊んでおりました。ポケモン久々でしたが、ストーリーがゲームボーイ版ベースだったので、自分としては懐かしさ、そして長男としては真新しさがあったのでよかったです。親子でゲームできるようになったのかと思うと考え深いですね。
そんな折、暇を持て余していた次男は嫁とせっせとレゴシティのPS4版 をやっており、気づけば全クリしていました。すげー。
2019のやっていき
今年のテーマは Make People Awesomeでいきます。Modern Agileの原則の一つですが、お正月にこの動画を見直していて、あー去年は大事にしていたはずなのに振り返ってみるとでもっとできたなと思ったので、改めて大事にしていければな、と。 何を成し遂げるかにこれを据えるモダンアジャイルほんと好きだなー。
YOW! 2017 Joshua Kerievsky - Modern Agile #YOW
年末年始は看病+自分が寝込んだわけですが、それに限らず自分のいろんな意味で人生のステージが上がってきたかな、という気がしています。自分よりも子どもだったり、自分より優先度が高いものが思い浮かんでくるようになったここ数年です。なのでまずは健康。後に引きずるようなムチャはしないよう心がけつつ、なるべくチャレンジして行きたいと思っています。
特に、昨年に引き続き今年もいろんなやっていきやのっていきがあると思うので、環境や時流をうまく味方につけて、自分をより伸ばしていけばな、と思っています。 登壇も頑張っていくぞ!
というわけで今年もよろしくお願いします。
【翻訳】ソフトウェア見積もりのパラドックス
はじめに
このエントリーは、Chris Lucianさんの Software Estimation Paradoxを許可を得て翻訳したものです。また、 Recruit Engineers Advent Calendar 2018 の20日目のエントリーでした。盛大に遅れましたごめんなさい。 誤訳等の指摘歓迎です。
ソフトウェア見積もりのパラドックス
人は以前に何度も完了したものの見積もりは上手にできる。
ソフトウェア開発者は、繰り返せるものや、時間のかかることは自動化する。
上手に見積れるものは、以前になんども繰り返して、自動化していないものである。
なぜソフトウェア開発者は、以前になんども繰り返したことを自動化しなかったのだろうか?
見積もりはムダだろうか?
ソフトウェア見積もりのパラドックスからすると、簡単に自動化できたソフトウェアは自動化できたかもしれない、といえます。また、見積もりが締め切りになってしまう環境下では、作りこまれるムダの量が増加するとも言えるでしょう。これはリーンソフトウェア開発の中核的なコンセプトに本質的に反しています。
どうやってムダを減らす?
ムダを減らすには、インセンティブの構造を変える必要があります。良い設計、継続的デリバリー、継続的インテグレーション、垂直的な区切り、遅延コストに基づく小さな機能の優先順位づけを組み込むことで、価値を素早く実現し、劇的にムダを減らすことができるようになり始めます。
次に何をすべきか?
※元記事からそのまま転載しています。そのうち訳します。
もし、次にやるべき機能を全てやろうとしていたら、継続的デリバリーと、垂直的なスライスを利用することで、その機能の遅延コストに基づいて機能を選ぶことが可能になります。機能を選んだ後は、今までに利用したことがない技術を含んでいたり、未知の設計を選択した機能を検証します。我々はこれを「既知の未知(known unknowns)」と呼びます。従来の見積もりのプロセスでは、これらの見積もりをするための調査期間を設けていただろうということに注意してください。もし、既知の未知が見つかった場合は、もし、既知の未知が見つかった場合は、コンセプトの証明のために時間をとるか、現状の我々の知識ではその機能の作成は不可能だと結論づけます。ひとたび、全ての既知の道がなくなったら、新たな未知の未知が見つかるまで機能のデプロイを進めます。もし何か未知の未知が見つかった場合は、再びその未知が消えるまでコンセプトの証明を行います。この時点で、デプロイし、次の機能に取り掛かります。このプロセスを、基本となる開発プロセスに組み込みむことで、コードはより高品質であることを維持し、途中でも効果を出し続けられるようになるでしょう。
※元記事からそのまま転載しています。そのうち訳します。
どうやって安全にムダを削減する?
この方向性をサポートするプロセスや技術はたくさんあります。下記のプロセスをゆっくりと組み込めば、徐々に変化していくことに気づき始めるでしょう。
- アジャイルなふりかえり
- ラーニングセッション
- カンバン
- WIP制限1
- ユニットテスト
- 超最小のMVP
- 継続的インテグレーション
- Zaroboogz1
- 自動化された受入テスト
- 継続的デリバリー
- 遅延コストに基づいたイテレーション
フィードバックがありますか? コメントでディスカッションに参加してください! そしてtwitterの #NoEstimates ハッシュタグもチェックしてください。
-
[訳注]すいませんこれ何かわかっておらず質問中です。わかる人いらしたら教えてください。↩