PoohSunny's blog

生きるために食べるのか、食べるために生きるのか。

2018ふりかえり

総論

ふりかえってみると2018は沢山チャンスをいただけた一年でした。ありがとうございました。 言葉にすると当然なんですけど、目の前のことを頑張る、何かを変える、上手になる、結果を出すみたいなことをまずは頑張って、それを話す、フィードバックしてもらう、よりちゃんと理解する、次のアイデアが生まれる、みたいな好循環ができたな、と思います。

登壇

2月のデブサミがメインでした。

speakerdeck.com

幸い関心を持っていただいた方にリクエストしていただき、複数回再演させていただきました。感謝!

3回目のNTTデータアジャイルフォーラムでの再演スライドは別途上がっています。

タウンワークをドライブさせるためになんちゃってアジャイルをやめた話 - Speaker Deck

海外

アメリカ行ってきました。

クリスさんにはいろんなことを伺い、その時紹介してもらった彼のブログエントリーを翻訳しました。 poohsunny.hatenablog.com

Davidさんには今年のDevOpsDays Tokyoでお会いできるみたい!

Podcast

アメリカでの縁がきっかけでPodcastにも登場させていただきましたー。人生初なので楽しかった。

lean-agile.fm

出版

エキスパートが教えるSelenium最前線 (CodeZine Digital First)

エキスパートが教えるSelenium最前線 (CodeZine Digital First)

書きました!

お手伝い

レビューでお手伝いさせていただきました!

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Mackerelではじめるお手軽Webサービス監視 (技術書典シリーズ(NextPublishing))

Mackerelではじめるお手軽Webサービス監視 (技術書典シリーズ(NextPublishing))

雑誌

紙面には全く登場しなかったのですが、取材していただいて事例が出ています。

shop.nikkeibp.co.jp

プライベート

家を買ったり、子どもが小学校に入ったり、お仕事でいろんなこと任せてもらえるようになったり、手術したりといろんな意味でとても実り多い一年でした。ありがたや。

というわけで今年も実り多き一年にして行きます。

2019

昨年はお世話になりました。今年もよろしくお願いします。

年末年始

今年の年末年始はいろんな計画外に見舞われまして、家のトイレは詰まり、長男がインフルにかかり、年をまたいでそれが私にもうつり、と久々に家にこもりっきりでした(さらにこのブログを書いてる瞬間次男も発熱)。計画外でしたが、インフルについては予防接種のおかげで重症化せずにすみ、トイレについては昨年引っ越した結果トイレ二つあるのでクリティカルな問題は起きず、ということで、予期できるリスクにあらかじめ備えておくことと、予期できないリスクに負けないように大事なものを冗長化しておくことの重要さを再認識できました。

とはいえずっと寝ていたかというとそうではなく、長男と私は回復期にポケモンをやっておりました。長男がピカチュウ で私がイーブイで遊んでおりました。ポケモン久々でしたが、ストーリーがゲームボーイ版ベースだったので、自分としては懐かしさ、そして長男としては真新しさがあったのでよかったです。親子でゲームできるようになったのかと思うと考え深いですね。

そんな折、暇を持て余していた次男は嫁とせっせとレゴシティのPS4版 をやっており、気づけば全クリしていました。すげー。

2019のやっていき

今年のテーマは Make People Awesomeでいきます。Modern Agileの原則の一つですが、お正月にこの動画を見直していて、あー去年は大事にしていたはずなのに振り返ってみるとでもっとできたなと思ったので、改めて大事にしていければな、と。 何を成し遂げるかにこれを据えるモダンアジャイルほんと好きだなー。


YOW! 2017 Joshua Kerievsky - Modern Agile #YOW

年末年始は看病+自分が寝込んだわけですが、それに限らず自分のいろんな意味で人生のステージが上がってきたかな、という気がしています。自分よりも子どもだったり、自分より優先度が高いものが思い浮かんでくるようになったここ数年です。なのでまずは健康。後に引きずるようなムチャはしないよう心がけつつ、なるべくチャレンジして行きたいと思っています。

特に、昨年に引き続き今年もいろんなやっていきやのっていきがあると思うので、環境や時流をうまく味方につけて、自分をより伸ばしていけばな、と思っています。 登壇も頑張っていくぞ!

というわけで今年もよろしくお願いします。

【翻訳】ソフトウェア見積もりのパラドックス

はじめに

このエントリーは、Chris Lucianさんの Software Estimation Paradoxを許可を得て翻訳したものです。また、 Recruit Engineers Advent Calendar 201820日目のエントリーでした。盛大に遅れましたごめんなさい。 誤訳等の指摘歓迎です。

ソフトウェア見積もりのパラドックス

人は以前に何度も完了したものの見積もりは上手にできる。

ソフトウェア開発者は、繰り返せるものや、時間のかかることは自動化する。

上手に見積れるものは、以前になんども繰り返して、自動化していないものである。

なぜソフトウェア開発者は、以前になんども繰り返したことを自動化しなかったのだろうか?

見積もりはムダだろうか?

ソフトウェア見積もりのパラドックスからすると、簡単に自動化できたソフトウェアは自動化できたかもしれない、といえます。また、見積もりが締め切りになってしまう環境下では、作りこまれるムダの量が増加するとも言えるでしょう。これはリーンソフトウェア開発の中核的なコンセプトに本質的に反しています。

どうやってムダを減らす?

ムダを減らすには、インセンティブの構造を変える必要があります。良い設計、継続的デリバリー、継続的インテグレーション、垂直的な区切り、遅延コストに基づく小さな機能の優先順位づけを組み込むことで、価値を素早く実現し、劇的にムダを減らすことができるようになり始めます。

次に何をすべきか?

https://3.bp.blogspot.com/-bfIoJ9XBPV0/W1dY8p-U7xI/AAAAAAAAceY/SLsqCYUxzEgcunubQiNKeN7YVRbbtm_hQCLcBGAs/s1600/HowToPrioritizeSoftwareDevelopment.PNG

元記事からそのまま転載しています。そのうち訳します。

もし、次にやるべき機能を全てやろうとしていたら、継続的デリバリーと、垂直的なスライスを利用することで、その機能の遅延コストに基づいて機能を選ぶことが可能になります。機能を選んだ後は、今までに利用したことがない技術を含んでいたり、未知の設計を選択した機能を検証します。我々はこれを「既知の未知(known unknowns)」と呼びます。従来の見積もりのプロセスでは、これらの見積もりをするための調査期間を設けていただろうということに注意してください。もし、既知の未知が見つかった場合は、もし、既知の未知が見つかった場合は、コンセプトの証明のために時間をとるか、現状の我々の知識ではその機能の作成は不可能だと結論づけます。ひとたび、全ての既知の道がなくなったら、新たな未知の未知が見つかるまで機能のデプロイを進めます。もし何か未知の未知が見つかった場合は、再びその未知が消えるまでコンセプトの証明を行います。この時点で、デプロイし、次の機能に取り掛かります。このプロセスを、基本となる開発プロセスに組み込みむことで、コードはより高品質であることを維持し、途中でも効果を出し続けられるようになるでしょう。

https://2.bp.blogspot.com/-Sl0JIHmxrGU/W1dbdNb-MUI/AAAAAAAAcek/Y0YKSaeI63U4y6HlD9FVSrgbyku0rPWZgCLcBGAs/s1600/TheCoreDevelopmentProcess.PNG

元記事からそのまま転載しています。そのうち訳します。

どうやって安全にムダを削減する?

この方向性をサポートするプロセスや技術はたくさんあります。下記のプロセスをゆっくりと組み込めば、徐々に変化していくことに気づき始めるでしょう。

  1. アジャイルなふりかえり
  2. ラーニングセッション
  3. カンバン
  4. WIP制限1
  5. ユニットテスト
  6. 超最小のMVP
  7. 継続的インテグレーション
  8. Zaroboogz1
  9. 自動化された受入テスト
  10. 継続的デリバリー
  11. 遅延コストに基づいたイテレーション

フィードバックがありますか? コメントでディスカッションに参加してください! そしてtwitterの #NoEstimates ハッシュタグもチェックしてください。


  1. [訳注]すいませんこれ何かわかっておらず質問中です。わかる人いらしたら教えてください。