Value Object(値オブジェクト)は3種類あった

Value Object(値オブジェクト) の意義と使い所がわからなかった。そこで調べてみたらなんと3種類あった。面白かったのでその調査過程を紹介する。

なお、現在では DDD の意味での Value Object がメインであること、またこれは自転車置き場の議論であり、DDD Quickly の Value Object の章を読む方が有意義であることを先に記しておく。

1. Data Transfer Object

1つ目は、Data Transfer Object(DTO)の意味だ。これは PoEAA に少しだけだけ出てくる。かつてのJava界隈の一部では(?)DTOのことを Value Object と呼んでいた。だが、現代では Value Object と DTO は別物として定着している。PoEAA は2000年代前半に出版され、著者が序文で90年代の開発経験をまとめたと書いてるため、これは20年以上前の話だ。このため、このことはすぐ忘れてもいい。

まあ、DTO にはメソッドがなくプロパティという値だけが格納されている。それを Value Object と呼びたくなる気持ちもわかる。

2. Value Object パターン

2つ目は PoEAA で Value Object パターンと紹介されているものだ。これはオブジェクトのプロパティの値が意図せず上書きされてしまうのを回避するために考案されたパターンと理解している。その特徴は不変(イミュータブル)であること、int や number 型ではなく独自のクラスを定義していること、Value Object 同士の比較ができること、ハッシュ化できることだ。ただ、自分は PoEAA だけではよくわからなかった。

Value Object パターンは、ケント・ベックのテスト駆動開発実装パターン という本にも登場する。後者ではお金を Value Object として扱うサンプルを紹介している。ドルを扱うために Dollar クラスを作ってみよう。コードは TypeScript で書き直している。

// マーカーインターフェース
interface Money {
  getValue(): this
}

class Dollar implements Money {
  constructor(private readonly value: number) {}

  getValue() {
    return this.value
  }

  // 最初から引数 other の型を Dollar とすれば条件分岐は不要
  // だが、説明のためにあえて広い Money 型にしている
  equals(other: Money) {
		if (instanceof other !== 'Dollar') {
      throw new InvalidArgsException('Variable other is not Dollar.')
    }

    return this.value === other.getValue()
  }
}

Dollar クラスに setter はない。もし異なる値が必要なら新しい Dollar クラスを作成する。

const dollar = new Dollar(100)
dollar.setValue(200) // これはできない

// 不変にしておくと、値が後から上書きされる心配がない
const dollar100 = new Dollar(100)
const dollar200 = new Dollar(200)

// クラスは同じでも値は同じではない
dollar100.equals(dollar200) // false

ドルの Value Object 同士を計算するなら Transaction クラスを作ろう。これも例として本に掲載されている。

class Transaction {
  constructor(
    private readonly a: Dollar,
    private readonly b: Dollar
  ) {}

  add() {
    const sum = a.getValue() + b.getValue()
    return new Dollar(sum)
  }
}

$100 + 100 yen という式を書けばバグになることは間違いない。Dollar クラスを作ることで、Dollar と Yen を誤って足し算することを避けられる。Transaction クラスで型エラーを出すからだ。

// Value Object
const dollar = new Dollar(100)
const yen = new Yen(100)

// 型エラーになる
new Transaction(dollar, yen)

しかし、int や number のようなプリミティブ型なら計算できてしまう。

// プリミティブ型
const dollar: number = 100
const yen: number = 100

// 計算できてしまう
dollar + yen

バグの原因になること間違いなしだ。

ここから、Value Object パターンの本質は「不変性」と「計算可能性」だと理解した。計算可能性とは、同じクラスの値同士を計算できるという意味と、違うクラスの値は計算できないようにするという意味だ。クラスは単位と読み替えても良い。

Value Object パターンは数値に単位を与える。ドルと円を計算できないようにするのと同様に、「3時間 - 8人」のような単位の異なる値を計算できないようにする役割も担うものだと理解している。

https://twitter.com/Panda_Program/status/1528786123304345600?s=20

3. DDD の Value Object

3つ目は、DDD の Value Object だ。2との違いは2点ある。

それは数値型以外も受け付けること。例えば User ID や文字列であるメールアドレスも DDD では Value Object とするそうだ。ここでは「計算可能性」の概念はなくなり、値の不変性のみが強調されている。

また、ドメイン話。Value Object はソフトウェアの中核を成すドメインオブジェクトと分類されている(以前書いたこちらの記事の図を参照)。しかし、2で紹介した PoEAA や テスト駆動開発といった本では、ドメインに関する言及はない。

自転車置き場の議論であることは認識する必要がある

個人的には以上のような理解をしている。Value Object を自分は理解していないという出発点から PoEAA を読んで理解しようと考えたのだが、なんだかややこしい。

普通 Value Object といえば3の意味だ。DDDの考案者である Eric Evans がこの実装パターンを Value Object と呼ばなければ混乱は生まれなかったのではと恨み言の一つでも言いたくなる。

元同僚でとても優秀なエンジニアが「Value Object の議論は自転車置き場の議論だよ」と話していてまさにその通りだなと思った。ただ、知っておくと面白い。

枝葉末節の議論は学者に任せて、自分たちは綺麗な動作するコードを書き、ユーザーに価値のあるソフトウェアを届けるという目標を忘れなければそれでいい。

というようなことを調べたり考えたりツイートしていた。しかし、全く同じ時期にかとじゅん(@j5ik2o)さん が「メモ:値オブジェクトの定義と差異について」という、Value Object の解説をしたこれ以上ないくらいの記事を公開されたため、本記事の下書きをお蔵入りにしていたのだった。

屋上屋を架すような内容ではあるが、最近また Value Object が話題になっているようなので清書して記事を公開することにする。

essay
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

アジャイル開発宣言の訳を見直す

アジャイル開発の手法はよく取り沙汰される。スクラムやエクストリームプログラミング(XP)がそれだ。

しかし、チームでスクラムガイドやXP本を読んでも、アジャイルソフトウェア開発宣言にまで立ち返ることは現場の開発者はあまりしないのではないか。

「アジャイルについてよく知らない」と優秀なソフトウェアエンジニアの友人が言っていた。彼は誰もが知っているIT企業に勤めており、現場ではリーダーを任されている。アジャイルの精神が当たり前になったので、あえて読まれないのだろうか。

せっかくなので、アジャイル宣言の全文を記載する。原文も訳文もとても短い。

私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

「アジャイルソフトウェア開発宣言」(https://agilemanifesto.org/iso/ja/manifesto.html

別の翻訳について

そんなことを思っていたある日、Twitter のタイムラインで、日本語だと原文のニュアンスが失われているのではないかと指摘するツイートを見かけた(*1)。

増田さんのツイート

確かに定訳というものはあれど翻訳は自由だ。自分で訳出してもいいだろう。そこまでするのでなければ定訳に対して注をつけてもいい。

そこでアジャイル宣言を自分も翻訳してみようと考えてみた。同じことを既にいろんな人がやっていることと思う。ただし、原文はシンプルなのでアレンジの幅は狭い。そこで日本語らしくなるように副詞を追加してみた。

ただし、原文のニュアンスから外れないように、アジャイル宣言の背後にある原則「アジャイルソフトウェア開発宣言の読みとき方」(IPA) を参照している。

なお、書いているのは「XよりもYを」が四行続く部分だ。

マイルドな翻訳

プロセスやツールよりも、個々人と相互交流を
網羅的なドキュメントよりも、ちゃんと動くソフトウェアを
契約交渉より、顧客と一緒になって働くことを
計画に従うよりも、変化に柔軟に対応することを

1行目はコミュニケーション、2行目は成果物は使えるソフトウェアとすること、3行目は協働を指している。

3行目について、元の翻訳では Customer collaboration が「顧客との協調」とされている。collaboration の動詞の collaborate は col-labor-ate に分解できる。col(com)が「共に」、labor が「労働」なので「お客さんと一緒に働く」というニュアンスが伝わる訳良い。

4行目はいわゆるウォーターフォールのことを指しているのだろう。実際、「アジャイル宣言の背後にある原則」では「開発の後期であっても変更を歓迎する」とか「変化を味方につけて顧客の競争優位に役立てる」と書いている。

超訳

数年ほど前、難解でとっつきにくい古典からそのエッセンスを抜き出して読者の理解を促すことに重点を置く「超訳本」が多数出版されていた(超訳 論語など)。

自分も真似をしてみて、もっと砕けたいわゆる会社文体の超訳も用意してみた。ただ、こちらはあまり参考にならないかもしれない。

手順や仕事のための道具よりも、個々別々の人同士が密に連携することを
あらゆる仕様が記された重厚な文書よりも、ちゃんと動いて役に立つソフトウェアを
バチバチの契約交渉よりも、お客様と共に汗を流すことを
事前の精密な段取りよりも、未知の変化を味方につけることを

もちろん、左と右のどちらにも価値はある。

まとめ

なお、アジャイル開発宣言は、IPA の資料の4ページ目「『アジャイルソフトウェア開発宣言』に対する誤解と真意」と一緒に読むとさらに多くのことを理解できるだろう。

アジャイルソフトウェア開発宣言で伝えようとしていることは、まずマインドセットがあって、そのうえで「プロセスやツール、ドキュメント、契約、計画」を考えるべきである、ということなのです。このマインドセットは、「個人と対話、動くソフトウェア、顧客との協調、変化への対応」として簡潔に表現されていますが、後述の「原則」を踏まえてもう少し具体的に表すと、次のようなことを示しています。

• 「対面コミュニケーション」 個人同士の対話を通じて相互理解を深めることで、よりよいチームが作られる。

• 「実働検証」 動くソフトウェアを使って繰り返し素早く仮説検証をし、その結果から学ぶことがよりよい成果を生み出す。

• 「顧客とのWin-Win関係」 お互いの立場を超えて協働することにより、よりよい成果と仕事のやり方を作ることができる。

• 「変化を味方に」 顧客のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉える。

IPA 「アジャイルソフトウェア開発宣言の読みとき方」 2020年2月

アジャイルソフトウェア開発宣言の読み合わせをチームでするときは、ぜひこの資料を使って補足すると誤解は減るだろう。もしも「アジャイル開発だからドキュメントは書かないのだ」という主張を聞いたら、「それはアジャイルの精神に背いている」とキッパリ否定してほしい。

1: https://twitter.com/masuda220/status/1555126706486226944

essay
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

読書のコスパとROIについて考えてみた

エンジニアとして今の自分を形成した本を5冊紹介する という記事を書いた時に読書のコスパとROIについて考えてみた。

コストパフォーマンス

コスパに関しては、古典と言われいてる本を1冊読めば、内容を薄めた凡百の本に無駄にお金を費やさずに済む。同じパフォーマンスを得られるならコストが安い方が良いというのがコスパだと自分は理解している。

例えば、同じような内容の本を3000円ではなく1000円で買えるとコスパが良い。また、新品ではなく中古で安く買った場合、それもコスパが良い方を選ぶという合理的な行動だろう。

ROI(投資対効果)

一方ROI(投資対効果)に関してはもう少し踏み込まなければならない。パフォーマンスではなくてリソースとリターンを定義する必要があるからだ。

まずリソースについて。読書のリソースとは金銭と時間だ。読書というものは金銭というリソース以上に、時間という有限なリソースをある注ぎ込む行為だ。例えば本の値段を1冊3000円、エンジニアの副業の時給も同じ3000円とすると(これ以上の値段の求人もある)、金銭的なリターンはすぐに得られる。

しかし1冊の本を読み通そうとすると何十時間もかかる。仮に1冊読み終わるのに20時間かかるとすると(読書にかかる時間を測ったことはないのでこれでも少ないかもしれない)、20(h) * 3000 (yen/h) = 60,000 (yen) かかることになる。

ここでは Time is Money という言葉から時間をお金という尺度に揃えてみた。時間とお金という異なる単位を統一して考えるとわかりやすいのでこの考え方を採用した。

つまり、値段が3000円で、読むのに20時間かかる本に対して、あなたは実質的に63,000円支払っていることになる。そして、同様の本を5冊読んだら 63,000 * 5 = 315,000円 が費やしたリソースになる。

結果、本を5冊読んだ後に30万円以上の昇給が見込めたらリターンの方が大きく、それ以下なら投資した費用を回収できていないことになる。

もちろん普段はここまで考えているわけではない。というより、手の内を明かすとこれらは今ここで思いついた話だ。 読書のROIについて書くために考えてみたのだが、なかなか面白いと思ったので書き残すことにした。

昇給だけが読書の目的ではない

当たり前の話だが、本を読んだだけでは昇給しない。本を読んでその内容を実践し、良いエンジニアだと評価され、その上で会社の給与テーブルと向き合って、給与更改の時期まで働く必要がある。その上で実際に昇給した額を知ることだ。それがおかしいと思えば転職市場に自分の価値を問わねばならない。

読書を投資と考えると長期的な視点が必要だ。昇給というリターンを得るまでには時間がかかる。すぐに結果が出るギャンブルではないのだ。

一方、金銭ではなく時間のリターンについて考えると、1週間後にコーディングのスピードが上がればそれはすぐに手に入るリターンと言える。設計やコーディングの方法論で迷うことがなくなり、テストをしっかり書いてバグを事前に見つけることで本番エラーの修正にかかる時間を削減し、リファクタリングを適切に行い機能追加にかかる時間を削減できたら、それは立派な時間的リターンである。

さらに「あの人はクリーンなコードを書く人だ」とか「学ぶことが多く一緒に働いていて楽しい」と思って貰って人間関係が良好になれば、それは何事にも代え難い。上記では単位を統一するためにお金という尺度を使っただけだ。

読書を昇給の要素に還元してはいけない。読書を昇給の手段とせず、それ自体を楽しむという目的としなければならない。そうでなければ、楽しい読書は続かない。

booksessay
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

エンジニアとして今の自分を形成した本5冊

エンジニアとして働くにあたって自分が大きく影響を受けた本を考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。

  • Clean Coder(クリーンコーダー)
  • Team Geek
  • Clean Architecture(クリーンアーキテクチャ)
  • テスト駆動開発
  • LeanとDevOpsの科学

この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している(かつての自分がそうだった)。

特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験がある人が読んで、本に書いてあることを実践すると自分の成長を実感するだろう。

「Clean Coder」、「Team Geek」はともにエンジニアとしてのマインドセットの本。「Clean Architecture」「テスト駆動開発」は、コーディングの原則と実践の本。「LeanとDevOpsの科学」はチームを超えた組織としてアウトプットを最大化するための本だ。

それぞれについて簡単に紹介していく。

Clean Coder(クリーンコーダー)

Clean Coder(クリーンコーダー)

クリーンアーキテクチャで有名なボブおじさんの本。

「仕事でコードを書いたなら、あなたはもうプロフェッショナルである」としてエンジニアの職人魂を軽快な語り口で解説した本。プロならTDDやデザインパターンを知ってて当たり前でしょ?と目線を上げてくれる。

「達成できない期限は約束しない」とか「見積もりは確率の3点見積もりをする」とか「自分が発言しない会議はそっと退席しよう」とも書かれてる。

Clean Coder で Craftmanship について書かれているので、個人的には今年に邦訳が発売される予定の Clean Craftmanship との違いが気になる。出版されたらそちらも読んでみたい。

Team Geek

Team Geek

HRT(謙虚・信頼・尊敬)の標語で有名。Google勤務の著者がチームで働くために重要なソフトスキルを教えてくれる本。

「コードはあなたではない。レビューで指摘されても落ち込まないように」「チーム文化はパンの酵母のようなもの。悪い文化(酵母)が入ってくるとすぐに壊れるので、大切に育てよう」など有用なアドバイスがたくさんある。

いいなと思ったのは、採用の際にカルチャーマッチを重視するという話だ。「スキルがずば抜けているが、人当たりがよくなくチーム開発に向かないエンジニアを採用すべきか」という問いにこの本ははっきり No と答えている。

スキルは習得できるが、壊れた文化を立て直すには骨が折れるからだそうだ。ここで文化が壊れるというのは、「人間関係がギスギスする」「自慢しあって褒め合わない」「人に攻撃的な態度を取る」「嫌なヤツが褒められて昇進する」とか、端的に書くとこんな職場で働きたくないと誰もが思う状況を指す。

この本から「組織カルチャー」や謙虚さ、尊敬と信頼(時にはハンロンの剃刀を持たないといけない)の重要さを知ることができた。

人を排除するのではなく、態度・振る舞いを排除するという話もためになる。嫌なことをする人を別のチームに追いやるのではなく、率直に(時にはマネージャーを通じて)「その行為はやめてください」と伝えようということだ。その人も嫌がらせをしようと思ってやってるわけではなく、単に自分の行為が人に与える印象に気づいていない可能性があるためだ。この辺りは HRT の T、信頼が鍵になる。

Clean Architecture(クリーンアーキテクチャ)

Clean Architecture

クリーンアーキテクチャ本。同心円の図も大切だが、それよりも手続型/オブジェクト指向型/関数型言語のそれぞれの意義と差異や、OOPで有用なSOLID原則を簡潔にまとめているのが重要。

方針と詳細を分けて、インターフェースに依存せよ力説している。方針は抽象、詳細は具体(具象)であり、インターフェースは抽象的な方針。この辺りがわかると OOP のポリモーフィズムや Dependency Injection(依存性注入)/ Dependency Inversion(依存性逆転)について語れる。

著者のボブおじさんはプログラミング歴50年以上で経験が豊富。昔のプログラミング経験の話も面白い。フロッピーディスクとか出てくる。彼はかの有名なアジャイルマニフェスト(アジャイルソフトウェア開発宣言)の署名者の一人。上記で挙げた Clean Coder もボブおじさんの著書。

テスト駆動開発

テスト駆動開発

TDD本。実装を書いてからテストを書いても通ることわかってるから意味ないよなって思っていた時に出会った。テストを先に実装を後に書くのが目から鱗。第3部にはテストあるあるが全部書いてるので、TDDを実践している今も読み返す度に学びがある。

以前、TDDの勉強会(TDDBC)に参加して感銘を受け、学んだことを忘れないように TDDの実践方法をブログに書いたら、TDD特集で Software Designに寄稿することになった ので個人的には思い入れが強い本。

TDD で注意すべきことは、TDD で書くテストは testing というよりは checking なので本番でバグが出ないわけではないことだ。テスト技法というより設計技法なのである。

TDD/ATDD/BDD などをまとめて Example-Guided Test と呼ぶ向きもあり、言い得て妙だ。エッジケースや仕様の考慮漏れなど入力値の例が足りなければバグる可能性がある。しかし、TDD で書くテストは CIでの自動テストやリファクタリングの強力な基礎になる。ただ、このテストはソフトウェアをバグから守る鉄壁の守護神ではないという点だけ覚えていてほしい。

著者の Kent Beck もアジャイルマニフェストの署名者の一人でXP(エクストリーム・プログラミング)の考案者。ちなみに、上記とは別のTDD勉強会で Kent Beck とペアプロをしたことがある人とペアプロをしたことがある人とペアプロをしたことがあるので自分の Kent Beck数は3。

LeanとDevOpsの科学

LeanとDevOpsの科学

アクセラレイト本。先人たちが「こうすれば開発はうまくいく」としてきたプラクティスや組織カルチャーの有用性を、大小様々な会社で統計学的に調査。結果、ハイパフォーマンスなプラクティスとそれらの関係性を洗い出して紹介した実用的な本。

書籍が出版された後に、ハイパフォーマーよりもパフォーマンスがいいエリートという区分が設けられた。上位プレーヤーはさらにパフォーマンスが高くなり、それ以外のプレーヤーとの差は年々広がるばかりとのことだ。

実はGoogle Cloudのドキュメントから無料で似たような内容を読むことができるが、個人的には本の方が頭に入りやすいので書籍をオススメした。

これらの本の内容はソフトウェア開発における発展的な取り組みの基礎になる

Clean Coder はプロとしての誇りについて、Team Geek はチームでうまくやろうという話をしてくれる。Clean Architecture で OOP の勘所を掴んだ後は、TDD で実装していく。コードを書いたらCD/CIを整備して、デプロイ回数を増やしてハイパフォーマーを目指しつつ、運用も人に投げずにやっていく(DevOps)。それぞれ異なるテーマであるようでいて、互いに重なる部分はかなり大きい。

ここで紹介した本を読み込むと「心理的安全性」「ペアプログラミング・モブプログラミング」「オブジェクト指向プログラミング(OOP)」「SOLID原則」「TDD」「ユニットテスト」「継続的デプロイ(CD)」「DevOps」などのキーワードについて語れるようになる。

さらに、アジャイル開発の流派であるXP(エクストリーム・プログラミング)やスクラム、Go や TypeScript など OOP 以外の言語での開発でも底通する普遍的な原則、受け入れテストやシステムテストなどユニットテスト以外の様々な種類のテスト、CD/CIや本番でのモニタリングといった発展的な内容に踏み込む足がかりとなる。読書のROI がとても良い本たちだ。

ちなみに、エンジニア向けに「10冊選んでくれ」と言われたら以下の5冊を追加する。

ソフトウェア開発以外の本をと言われたら、この5冊を挙げる。

これらの書籍についてもいつか詳しく紹介するかもしれない。

変更

(7/24) ソフトウェア開発以外の本のうち 武器としての交渉思考 を「失敗学のすすめ」に変更。

booksessay
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

スクラムイベントの名前を英単語の語源から覚える

スクラムイベントの名前、覚えにくいと感じていませんか?

レビューやデイリーならまだしも、バックログ、インクリメント、レトロスペクティブ、リファインメントなど普段目にしない単語が並んでいる上に長くて覚えにくいですよね。

そんな時は元になる英単語の語源を知ると簡単に覚えられます!

スクラムイベントの英単語

スクラムイベントのループ

バックログ は、背後にあるログですね。ログ(log)は、丸太という意味と記録という意味があります。なぜ同じ単語で丸太と記録なのかというと、昔は木にナイフで印をつけたんですね。無人島で流木にナイフで「今日は漂流してから何日目…」と1日ごとに線を一本ずつ入れていくイメージです。なので、バックログは「後ろにある記録」です。会社の作業机の後ろにホワイトボードがあって、そこに付箋(記録、アイテム)がたくさん貼られているところを考えると覚えられますね。

インクリメント は、増加分です。英語だと increment ですが、増加するという英単語の increase に音と綴りが近いのでこれで覚えられますね。スプリントの成果物というよりは、「アイテムを一つずつプロダクトに付け足していく」というイメージです。付け足していったもの(追加分)をレビューしてもらうわけですね。

レトロスペクティブ は、retro と spective に分解すれば簡単です。retro は「過去の、古めかしい」という意味で日本語でも使いますね。spective は「perspective(見方)」「speculate(熟考する)」という単語と同じ語源で「(じっくり)見る」という意味があります。これで「過去を見る」、つまり「回顧する」「振り返る」という意味です。spec 部分の単語に馴染みがなければ、respect(尊敬する)で覚えましょう。re-spect で「再び見る」なので、スゲェ!と二度見するイメージですね。

リファインメント は実は文字通りです。日本語だと洗練すると訳されますが、re-fine-ment で「再び(re)よくする(fine)こと(ment)」です。すでにいいものをさらに良くするという点で、改良、改善という訳語の方が近いですね。refinementはお堅い単語で、似た意味の improvement の方が日常的によく使われます。

また、スプリントは sprint ですね。sprint は「spring(春、泉、バネ)」と綴りが似てますね。spring はなぜこんなに訳語を持っているのか。それは、根底にあるイメージが共通しているからです。春は大地から植物が芽吹くイメージ、泉も地面から水が噴き出すイメージ(しかも hot spring で温泉ですね)、また、バネは机の上でググッと押さえつけられた後にビヨーンと宙に跳ねるイメージです。sprint は同じようなイメージで、脇目を振らない瞬発力を持ってやるという感じです。

まとめ

スクラムイベントの名前は馴染みない英単語なので嫌厭されがちですが、ちゃんと考えると意味は至極単純です。記録して、計画して、瞬発力を持ってバッとと実行して、増えたものを見てもらって、振り返りをして改善する。日本語にするとこれだけですね。以上スクラムの英単語講座でした。

scrumessay
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer