うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

なんちゃってアジャイルから、4年間アジャイル開発していたら15minスプリントになった件 #RSGT2019

概要

  • とりあえず次の動画をみてほしい。
  • ちまたのアジャイル開発チームはスプリントが1週間だが、私のチームは15minで回している。
  • 学生や新卒に1日スプリントを教えている。彼らは5日程度で1日スプリントをマスターする。
  • 15minスプリントを含んだプラクティスについてスライドにしてほしい、聞きたいという人は RSGT2019の公募にlikeしてほしい。かりにlikeはなくても、RSGT2019に参加しよう。

セッション confengine.com

チケットはこちらから!11/16から販売だそうで。 Regional Scrum Gathering® Tokyo 2019

www.youtube.com

背景

このチームが今までどんなふうに開発を経てきたのかはだいたい次のスライドにまとまっています。 簡単に言うと、なんちゃってアジャイルをやっていて残業と改善が低いチームだった。そんなチームがちゃんと開発しよう、アジャイルに向き合おうって変わって4年もたった今の話。 開発対象はWebAPI、フレームワーク、ライブラリ、プラットフォームなどいわゆる基盤的なもの。なので、このチームを基盤チームと呼んでいる。そして受託開発です。

スプリント期間の変遷

2015年当時の多くの他のチームと同樣にこのチームも例外なく、1週間スプリントが最も短いと考え、2週間スプリントや1週間スプリントを実践していました。 だが、それはPOすくなくとも、チーム内でのフィードバックが遅いと気づきました。 そして、2016年には1日スプリントになりました。

この根底にあるのは、スプリント期間とビジネス的なリリースは必ずしも一致している必要はないということです。もちろん、リリースをあと伸ばしにしていいとかそういう意味ではなく。 自分のチームの仕事は受託開発だったので、もともとスプリント期間とリリース期間は一緒じゃなかったし、国内外の知見を聞いても一致している必要はないと聞いて自信をもってそう踏み切れました。 スプリント計画の内容が達成できているかどうかをPOに確認してもらう期間というだけ。

そうして、2017年にはさらに1時間スプリントになりました。これはこれでなかなか大変で、1日スプリントと同じような質のマネジメントしかできなくて苦しんだりいろいろありました。が、2017年10月にはだいぶ使いこなしていた記憶があります。

そうこうしているうちにいろんな課題を乗り越え、基盤チーム全員で「レッツゴーデベロッパー 平成ジェネレーションズ FINAL」という素晴らしい勉強会への登壇機会をもらいました。これは単純にチーム開発を参加者としてみようというものです。

connpass.com

ここで、基盤チームは30minスプリントを実践してみたのですが、軽々と出来てしまい、チーム内で「30minスプリント余裕すぎるwww」という話になり、現場に戻ってしばらくしてから、「よし15minスプリントやってみようぜ」となったのでした。

そして、現在15minスプリントをやっているのですが、大きな問題はなくて非常に開発しやすい状態を保てています。

1日スプリントの頃からそうですが、基盤チームは能動的に時間管理できないので、基本的には学校のチャイムというか、タイマーを使っていて、それによってスプリント期間の開始と終了、スクラムイベントの実施をしています。 これを聞くと、トイレ休憩とかちょっとした休憩はないの?とか思われるかもしれませんが、明示的に休憩の時間もあるので、そこに合わせつつ、まぁ自由にとるという感じです。

RSGT2019

ということで、こういった話、つまり15minスプリントの詳細や、スクラムチームとしての全体像、そしてプラクティスとしてどのように抽出されているのか?などをRegional Scrum Gathering Tokyo 2019 というイベントで話そうと公募を出しています。

講演として聞きたい人、スライドにしてほしい人はlikeをしてください!講演とかいいんだけど、聞いてみたいっていう人はRSGT2019に参加して直接僕を捕まえて聞いてください。Scrumというトピックでギャざりましょう。

セッション confengine.com

チケットはこちらから!11/16から販売だそうで。 Regional Scrum Gathering® Tokyo 2019

念の為言っておくと、私はRSGTの運営でもなんでもないんだけど、みんなとScrumとかチーム開発とかについていろいろ意見交換したいんだけなんだ>< そのための最高の場所がRSGTだと思っている。的な。

参考書籍

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

生命の現象

生命の現象

生物系の参考書籍追記

生物模倣――自然界に学ぶイノベーションの現場から

生物模倣――自然界に学ぶイノベーションの現場から

自然をまねる、世界が変わる: バイオミミクリーが起こすイノベーション

自然をまねる、世界が変わる: バイオミミクリーが起こすイノベーション

アルゼンチンアリ: 史上最強の侵略的外来種

アルゼンチンアリ: 史上最強の侵略的外来種

「それ、何か言っているようで何も言っていないですよね」って思う

f:id:kyon_mm:20181015081356j:plain

何かの解説、会話、ドキュメントでたまに「それ、何か言っているようで何も言っていないですよね」と指摘することがある。

  1. 情報量が増えていない
  2. 抽象化しすぎて本題からズレている

自分がよく見るのは上の2パターンがある。

1. 情報量が増えていない

具体的にはトートロジーになっている。関係ないことをそれっぽく言っている(文章や会話の隙間をただ埋めているだけ)。

2. 抽象化しすぎて本題からズレている

具体的には対象範囲や主語が大きくなりすぎて、本来のトピックについて具体的な話がない。

1はどうでもいいとして、2が需要がある場合もわかる。 でも、2については全体の中で「一度振り返ってみるとこういう目的なのですよ。そのうえでもとのトピックに戻ると、具体的には〜」みたいな話としてちょっと立ち止まって見る程度の話だと思うんですよね。トピックに戻ってからも延々と抽象的な話をするのは、そもそも元のトピックいらないじゃんっていうね。まぁそういうネタならいいんですけど。

理科系の作文技術(リフロー版) (中公新書)

理科系の作文技術(リフロー版) (中公新書)

"エンジニアが使うべき便利な windows アプリ一覧" がほしい

誰かが書き始めると、他の人も書いてくれることを祈ってこのエントリを書いている。できるだけ、組織全体で使うツール(チャットツールとか)は選ばないようにした。

RapidEE

www.rapidee.com

Windowsの“環境変数”をGUIで編集できるソフト。各環境変数とその値をツリー形式でわかりやすく表示できるのが特長で、変数や値はツリーの右クリックメニューから追加・削除することが可能。また、値にパスを指定する場合はダイアログを使ってフォルダを選択できるので、編集作業の多くをマウス操作だけで完結でき、編集ミスを起こしにくい。また、無効なパスを赤文字で強調表示する機能を備えているので、入力ミスを一目で見つけることができて便利。過去に指定したパスがソフトのアンインストールなどで無効になった場合にも強調表示されるので、ときどき本ソフトで環境変数を調べれば、無効な値がないか確認できる。そのほか、設定した環境変数をREGファイルとしてバックアップしておくことも可能だ。

cmder

cmder.net

コンソールエミュレータ。最初からフォントがそこそこ設定されているし、便利。

7-zip

sevenzip.osdn.jp

解凍、圧縮アプリケーション。いろんな形式に対応しているのと、パスワードなどもかけられる。エクスプローラ上でのコンテキストメニューとも統合できるので便利。

clibor

www.amunsnet.com

クリップボード履歴管理。数回前にコピーしたテキストをいつでもペーストできるようになる。便利。自分は、Ctrlを2回連続で叩くとペースト対象を選ぶポップアップがでるようにしている。

Chrome, Firefox

www.google.com

www.mozilla.org

Webブラウザ。普段遣いするのはどちらでもいいと思う。WebGUIアプリケーションを開発するなら、結局両方入れることになると思う。

Mate Translate

www.matetranslate.com

翻訳アプリケーション。Chrome, Firefox拡張もあるし、デスクトップアプリケーション、モバイルアプリもある。 Firefox拡張として入れている場合には、英単語を選択すると、日本語翻訳がポップアップされる感じ。

WinMerge

WinMerge 日本語版

ファイル同士やディレクトリ同士を比較して、ファイルのどの行が違うかが見えるようになる。差分がある行をどちらかにコピーすることもできる。他のDIFFツールやマージツールでもいいんですけど、WinMergeが一番楽な気がする。

そしてこれジオシティーズなので、大丈夫なのかが不安です。

Git

git-scm.com

ファイルのバージョン管理ツール。チームで利用するツールなんですけど、Gitは一人でも使えるので、ぜひ入れておいたほうがいい。

Everything

「Everything」高速なファイル検索ソフト - 窓の杜

爆速ファイル名、パス名検索。インクリメンタルサーチに対応しているし便利。

Process Explorer などsysinternals系

technet.microsoft.com

sysinternalsはいろんなツールがありますが、とりあえずProcess Explorerは入れておきたい。タスクマネージャーでは出来ないことができます。(Windows10くらいからリソースマネージャーが高機能になってきているからどんどん不要な場面が増えてきて入るものの) 他には、caps lockをctrlにするツールとかもsysinternalsの1つにあります。

Crystal Disk Info

crystalmark.info

HDDとかSSDの状態のレポーティングツール。できればハードウェア障害は早めに予見したい。

ここで触れていないけど、実質必須になりそうなもの

  • テキストエディタIDE => 好きなものにしたらいいとおもう。
  • チャットツール => 組織に合わせましょう。
  • ファイル共有 => 組織に合わせましょう。
  • 各種テストツール => もうあげたらキリがない。(これは別立てがいい気がする)

Windows Sysinternals徹底解説 改訂新版 マイクロソフト関連書

Windows Sysinternals徹底解説 改訂新版 マイクロソフト関連書

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

「開発現場で役立たせるための設計原則とパターン」をオススメできない理由

「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である

このエントリーは 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く に対する返答です。 件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。

私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。 そして発表者様のエントリーを読んでも私の感想は変わりませんでした。

まず、件のスライドにおける設計原則の解説自体には問題はなく、サンプルコード付きで解説していることは素晴らしいです。

問題は、設計原則の適用対象が生存期間が短いものになっていることです。これは、ここ20年ではもはや定説とされている「要件はよく変わる」「機能はよく変わる」という問題をそのまま受け継いでいます。つまり、この設計は要件変更に非常に弱い作りです。 ただ、要件変更に弱くてもコストがペイする(ROIが企業としては問題ない)場合もあると思います。私はそのような場面についてはあまり興味はありません。 私が興味があるのは、「変更につよい」とうたう設計とはなにか?という話です。

一応、記事中でも次のような説明があります

「問題によって適切な構造は変わる」

ただ、この文言が出てくるのはずいぶんと後半です。2/3はこれに反したような内容をつらつらと書いています。 仮にこの文言が最も主張したい内容だったとして、つまりそれはどのように実践するのか?についてはまるで解決方法が提示されていません。 これでは「この発表では考慮していませんが、考慮すべき大切なことがあります。(どうやるかは提示しない)」という発表になっています。なんの発表だったんだ。。。

発表の中にでてきた、コメントがどうこうとか、通知がどうこうとかってあきらかに機能の話で、その機能を構造化しても結局変更されるので弱いんですよ。もちろん設計は必要なんですけど、もっと重要な設計が先にあるということです。

まずは普遍的なモノゴトを対象に吟味して設計し、機能の設計はもっと力を抜いて設計したほうが良いです。

よく変更されるような振る舞いについては簡単に書き換えられるようになっているほうが楽だし、そのときに「この機能はこんなに重要だ!」という思い込みによる具象化と抽象化をするのは、いわゆる早すぎる最適化と同じ問題を抱えています。

私のバイアスの話

私はアジャイル開発やメッセージベースオブジェクト指向が好きです。ここの共通テーマは「決定を遅延しながら機能するネットワークを常に作り続ける」ことだと思っています。 そして共通する課題意識が構造というのは人間が計画駆動で生活したいというためのフォースが働いているものであり、私はそれをもっと使いこなす必要があると考えています。(言い過ぎかもしれないけど、構造を決定する必要はほぼないと私は考えている節がある) 少なくともIT業界でアジャイル開発の根本的な概念は広まっていて、要件はよく変わるし、見通せるものではないのだから、常に変化に対応しようとする話があります。 よって、私はこの考え方に反しているとさきの記事を見て思ったのです。(記事の中で「常に考えよう」という姿勢はあるんですけど、対象があまりにも狭いという話です。)

おまけ

では、私は実践できているのか?というと、幾分かは出来ていると考えています。まだ道半ばです。 その道半ばですが、何を考えてソフトウェア開発をしているのか?どのように要件を考えたり、設計をしているのか?というチャレンジの話を今度発表しようと考えています。 公募制なので通るかわかりませんが。公募が通らなかった場合は別の機会に発表しようと思いますので、聞きたい人はお気軽にコメントなりTwitterなり教えてください。

confengine.com

関連書籍

生命の現象

生命の現象

生物模倣――自然界に学ぶイノベーションの現場から

生物模倣――自然界に学ぶイノベーションの現場から

ScalaMatsuri 2018トレーニングデイの感想。またはチュートリアルがひどかった件

ScalaMatsuri2018というScala言語のカンファレンスに参加してきました。といっても3日間のうちの1日目(というか0日目みたいな位置づけ)のトレーニングデイというものだけですが。 最近Scalaを使っているし、Scalaユーザーにいくつか聞けたらなぁーとかちょっと勉強したいなーって感じで。

2018.scalamatsuri.org

運営の方はおそらく大変だったと思いますがいろいろ対応してくださって助かりました。 ただ、自分が参加したチュートリアルセッションはひどかったです。自分もハンズオンで教えることがあり、失敗を幾度かしてフィードバックをもらっては改善してきました。ので、今回は私がフィードバックをする番だと思いましたので、このエントリにさせていただきます。

  • トラックとかモチベーションについて
  • Scala入門ハンズオンのタイムライン
  • Implicit入門
  • CTO座談会
  • まとめ
続きを読む

Java/Groovyでうるう秒を扱う方法

Java言語でうるう秒を扱う方法を調べたのでまとめておきます。Twitterで質問したらたくさんのリプライ、エアリプがありそれらをもとに調べることで達成できました。ありがとうございました。

概要

  1. Java標準APIOracle実装ではうるう秒を扱えない。Calendar, Dateなどの旧型のAPI、ZonedDateTimeなどのDate and Time APIどちらも。
  2. ThreeTen-Extra というライブラリを使うとうるう秒を扱える。

うるう秒を扱えるということに対して期待していること

4年に1度だけ2/29があるうるう年のように、2年から5年に1度くらいの間隔で世界中の時計が1秒だけ増えることがあります。これをうるう秒と言っています。最近だと日本時間で2017/1/1 08:59:59 のつぎが 2017/1/1 08:59:60 となりました。普段はない60秒があり、1分間が61秒になりました。 これはいつ挿入されるかは規則はいまのところありません。(どれくらい前に告知されるのかは決まっていないのかな?)

で、システムにおいてうるう秒においても 08:59:60 のように時刻を正確に記録できるのかが気になりました。

というのも例えば、UNIXTIMEはうるう秒を丸めるという仕様になっています。

具体的には次のような形になります。

  • 東京の時刻
    • UNIXTIME
  • 2012-07-01T08:59:59+09:00[Asia/Tokyo]
    • 1341100799
  • 2012-07-01T08:59:60+09:00[Asia/Tokyo] <= うるう秒挿入
    • 1341100799 <= 1秒前と同じ
  • 2012-07-01T09:00:00+09:00[Asia/Tokyo]
    • 1341100800

ということで、UNIXTIMEを使うとうるう秒時点の扱いを気をつけなければいけません。(保存にしろ、描画にしろ)

ので、流れとして

  1. 「2012-07-01T08:59:60+09:00[Asia/Tokyo]」という時刻を表現できるようにするにはどうしたらいいのだろうか?という視点で調べました。
  2. このシステムはうるう秒が来ても正確に動作するシステムであるといえるようにしたい。
  3. となると、うるう秒を発生させるテストを書かなければいけない。
  4. (例えば)Javaうるう秒を任意に起こすことはできるのか?

という形です。

そこで、「2012-07-01T08:59:59+09:00[Asia/Tokyo]」のオブジェクトを生成し、1秒すすめたときに「2012-07-01T08:59:60+09:00[Asia/Tokyo]」が生成できるのか?ということを調べました。

Java標準のAPIだとどうなるのか

Java標準の時間を扱うクラスというとJava7まではjava.util.Calendar、java.util.Dateを使い、Java8からはDate and Time APIである java.time.ZonedDateTime などを使います。

JavaDocにはOS依存だよーとか、Java実装依存だよーとか書かれていたので、次のような環境で試しました。

ですがいずれの場合でも、「2012-07-01T08:59:59+09:00[Asia/Tokyo]」のオブジェクトを生成し、1秒すすめたときには 60秒にならず09:00:00になってしまいました。

Calendarの場合

def c = Calendar.getInstance(TimeZone.getTimeZone("Asia/Tokyo"))
// 59秒を生成
c.set(1900 + 112, 6, 1, 8, 59, 59)
// うるう秒にすすめる
c.add(Calendar.SECOND, 1)

// fail
assert c.getTime().toString() == "Sun Jul 01 08:59:60 JST 2012"

// うるう秒で生成
def d = new Date(112, 6, 1, 8, 59, 60)
// fail
assert d.toString() == "Sun Jul 01 08:59:60 JST 2012"

ZonedDateTimeの場合

// 59秒を生成
def zdt59 = ZonedDateTime.parse("2012-07-01T08:59:59+09:00[Asia/Tokyo]")

// うるう秒にすすめる
// fail
assert zdt59.plusSeconds(1).toString() == "2012-07-01T08:59:60+09:00[Asia/Tokyo]"

ちなみにZonedDateTimeのparseメソッドはそもそも60秒をパースできませんし、Instantのparseメソッドは60秒をパースしても0秒に丸めてしまいます。

ThreeTen-Extraを使うとどうなるのか

ThreeTen-Extraというライブラリを使うとこれが実は出来ます!(なんだってー!なんのためのJSR310だっt

  1. Stephen Colebourneが「Joda-Time」をつくる
  2. JSR-310としてJoda-Timeのように便利にしようとDate and Time APIが取り込まれる
  3. Stephen ColebourneがJSR-310の拡張ライブラリ「ThreeTen-Extra」をつくる

もう、Stephen Colebourneに足向けて寝られないですね。

UtcInstantというクラスを使うとうるう秒を保持した計算ができるようになっています。なのでタイムゾーンなしの文字である「2012-06-30T23:59:59.000Z」を渡して1秒足してみて60秒になれば成功です。

import java.time.Duration

import org.threeten.extra.scale.UtcInstant

def ui = UtcInstant.parse("2012-06-30T23:59:59.000Z")
def ui2 = ui.plus(Duration.ofSeconds(1)

// success
assert ui2.toString() == "2012-06-30T23:59:60Z"

ということでうるう秒を鑑みて時刻を考えるなら、UtcInstantとして常に計算し、日付、タイムゾーンは別で管理しておくという戦略をとればよさそうです。

ちなみにUtcInstantでは日付はMJD(修正ユリウス日)が使われています。のでだいたい5桁くらいで収まる範囲です。

ただしこれがバグっぽいAPIがある

UtcInstantにはisLeapSecond()というメソッドがあるのですが、これがうるう秒ちょうどになった瞬間はまだうるう秒じゃないという判定をしてしまっているように見えます。

  • 08:59:59.999
  • 08:59:60.000 <= うるう秒 <= ここでisLeapSecondがfalseになってしまう。
  • 08:59:60.001 <= うるう秒 <= ここはtrueを返してくれる
  • ...
  • 09:00:00.000

まだThreeTen-Extraの仕様を読み切ってないのですが、仕様が僕のおもっているとおりならこれはtrueを返すべきところなので、まずかったらIssueをあげようかなーと。

そのほかの話

ここまでで、Javaうるう秒を扱うという方法がわかったわけですが、システム全体で考えるといろいろと面倒です。 まず、Windowsうるう秒をサポートしていません。

次に、Linuxではうるう秒については60秒になった瞬間に59秒をやり直します。(60秒から0秒のあいだまでもう一度59秒になります)

そして、NTPサーバがどのように返答するか次第でOSの挙動は変わります。

ちなみに、GoogleなんかではLeap Smearingといって、うるう秒の1秒を(うるう秒前後の)20時間かけてちょっとずつ時計の進みを遅くすることで60秒という1秒間を分散させています。こうすることで、NTPサーバに問い合わせても60秒という時間が指定されません。つまり、ある20時間だけほんの少しずつだけ時計が遅く進んでいるのです。

クラウドを使っている場合にはインフラのNTPまでを統一するのは難しいので、要件に応じてどこを何に統一するのか考える必要があります。

最後に

情報収集につきあってくださった id:megascus さん、エアリプしてくれた khasunuma さんありがとうございました。めっちゃ勉強になりました。 そしてコードを簡単に共有できるWandbox最高でした。Groovyの最新版うごかしてくれてありがとう。(もう少し言えば、@Grabが動くようになっているともっともっと嬉しいんだなー。)

参考

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Effective Java (3rd Edition)

Effective Java (3rd Edition)

Scrumのカンファレンスに参加してきた #RSGT2018

Scrumのカンファレンス(ギャザリング)に参加してきました。

2018.scrumgatheringtokyo.org

なぜ参加しているのか、今回どんなイベントだったのか、僕にとって何がよかったのか。を書こうと思います。 日本でアジャイルに興味がある方ならぜひ参加してみるといいと思います。

  • なぜ参加しているのか
    • 自分がなぜRSGTで発表するのか
  • どんなイベントだったのか
  • 僕にとって何がよかったのか
    • 参加してよかった3つのこと
  • まとめ
続きを読む