kazokmr's Blog

試したこと、読んだこと、見たこと、聴いたことを書きたくなったら書くブログ

BDD in Action 2nd Edition 第6章を読んだ

BDD in Action 2nd Edition の第6章は、正しい要件を定義することの最終章として、前章で探索した主要な例を使って、フィーチャーのシナリオをGherkinフォーマットで書く方法を説明しています。

www.manning.com

前半は、Gherkinの主要なキーワードの用途や使い方の説明で、これはCucumberのチュートリアルなどでも学べる内容でした。 この中で知らなかったキーワードにはBackground があり、複数のScenarioの冗長性を排除することができます。

これは書籍に載っていたことではありませんが、キーワードにRuleExampleが追加されていました。 RuleFeatureの中で、Scenarioをグループ化できます。ExampleScnarioの別名なので、用途はScenarioと変わりません。

RuleExampleは、より実例マッピングに近い形式で表現できます。

章の後半では、優れたGherkinの書き方を紹介しています。

Gherkin を書く際に気を付けることとして以下のようなことが挙げられていました。どれもプログラミングの原則でよく言われていることと似ています。

  • シナリオでは宣言を書き、命令的な指示は書かない。(Howではなく、Whatを書く)
    操作することや入力する内容などを1つ1つ詳細に書くのではなく、シナリオで達成したい目的に対して何をしなければいけないかに着目して書くとよい。

  • 1つの関心事に着目してシナリオを書く。 特に初めはシンプルな関心事から初めて、徐々に複雑なシナリオを組み立てる。

  • シナリオの登場人物に個性を付ける(ペルソナを作る) ユーザーや管理者のような味気ない役割だけではなく、目標・能力・背景などを付けると良い。また初めからペルソナを詳細に書くことに時間を費やさずにシナリオを書きながら付け足すと良い。

  • シナリオには必要なことだけを書く。容易に想定できることは省略する。
    とあるフィーチャーのシナリオを書く時に、そのフィーチャー(画面)にたどり着くまでの汎用的で容易に想像がつく手順まで記述しない。特にGivenについてはシナリオを検証するために必要な前提条件だけを書く。

  • 既存のテストスクリプトやテストコードの手順をそのままシナリオとして書かない。
    これらは指示・命令的なステップが多いから。「比較する」や「確認する」が含まれているシナリオは大抵、テストスクリプトのような書き方になりがち。

  • 各シナリオは独立して実行できるようにする シナリオごとに必要な前提条件を宣言して独立して実行できるようにする。一連のシナリオの纏まりを順番に実行する必要がある構造にはしない。(あるシナリオが失敗したら、後続のシナリオが実行できないことが無いようにする。)

個人的には経験上、指示的な書き方になりがちなので、この辺を気をつけていきたい。

ここまでの章で、シナリオをまとめたFeatureファイルを成果物とした、要件定義の進め方を学んできました。これまで自分が行って来たやり方とは全然違っているので慣れるまでに時間がかかりそうだが、作るべきことにより着目して明確に分かりやすい書き方で整理できそうに思えました。

BDD in Action 2nd Edition 第5章

5章を読み終えましたので、学んだことをまとめてみます。

www.manning.com

5章は、BDDの活動サイクルの中の Illustrateフェーズでの作業として、3〜4章の Speculateフェーズで特定し、詳細化したフィーチャー、あるいはユーザーストーリーを明確にしていきます。

フィーチャーの内容を明確にするための手段は「例を使ったビジネス側との会話」です。

例を使って話し合う

  • 話し合いは、ユーザやステークホルダーも参加して、フィーチャーの受け入れ基準を理解し、定義し、合意していく。

  • 話し合いでは、良く適切な質問ができなかったり、脱線したりして、思うように進まずに長引くことがある。

  • フィーチャーに対して、ビジネス側の言葉を使った例で説明することで、話し合いが円滑に進む。

  • 例を使って話う会う時は反例も出すことで矛盾や誤解を知り、不確実なことを洗い出して明確にすることができる。

  • 例を使って理解したことを確認したり拡張したりするために追加の例を使う。

表を使って例を整理する

  • 表はインプットと期待する結果が簡単に説明できるような要件に適している、データ中心的なアプローチ

  • デシジョンテーブルを作るイメージ。だけどこの段階では網羅することよりも要件の理解を優先する

  • アプリケーションの振る舞いなどは表現できないので、実例マッピングやフィーチャーマッピングと組み合わせて使うのが良い。

実例マッピング (Example Mapping)

  • フィーチャー(ストーリー)に紐づくビジネスルールや制約、そしてルールに対する例と反例のリストを特定していく。

  • 目的は、フィーチャーやルール(受け入れ基準)の共通理解を得ること

  • 挙げられたルール、または例の数が多いと、フィーチャーが大きいか、複雑なことを示していて分割した方が良いかもしれない。

  • 話し合いは一つのフィーチャー(ストーリー)に対して、25-30分のタイムボックスで行い、そのフィーチャーに集中する。

  • 話し合いの最後に「作業を始めるために十分な理解を得られたか?」「更に話し合う必要があるか?」を投票して決める。

  • 話し合いで回答できない例や質問は、別に記録しておいて、その話し合いではそれ以上議論しないようにする。

  • 例を追加していく時は「もしこうだった場合は?」「そのルールはいつもそうなのか?」「ルールが適用できない場合はあるか?」などの視点で質問すると良い。

フィーチャーマッピング

  • 大きく、不明確なフィーチャーに適している。

  • 実例マッピングと違う点は「例をステップ単位に分けて説明する」「ステップの最後に期待する結果となる結論(Consequence)を書く」などがある。

  • 実例マッピングが「ビジネスルールを基に例を挙げていく」ように進めるとしたら、フィーチャーマッピングはどちらかといえば「ストーリーから想定される例を上げていって、ビジネスルールや制約を特定する」ようなイメージに読み取れた。

  • フィーチャーマッピング自体は、大きなフィーチャー(あるいはエピック)をルールや制約単位に分割することも目的の一つのなので、その後実例マッピングを使って理解を深めていくと良さそう。

スリーアミーゴス

例を使った話し合いでは、テスター、プロダクトオーナー (ビジネスアナリスト)、開発の3つの役割を持ったメンバーがそれぞれの視点でルールや例を質問していくと良い。

  • テスターは、細部に注意を払い、検証することに着目して、エッジケースなど見落としがちなシナリオを指摘する

  • プロダクトオーナー は、ビジネス視点の妥当性や相対的な価値に着目して、シナリオを指摘する

  • 開発者は、技術的な検討事項を指摘する。

まとめ(感想)

  • 顧客と要件定義を行う時に、わからないことがあれば例を使って話し合うことがたまにあったが、それを意図的に利用して要件の理解を深めることが目的。

  • 付箋あるいはホワイトボードツールを使って、ルールと例を整理する。

  • ここで作ったルールや例のうち主要なものは、Gherkinのシナリオ(Given...When...Then)として使うことになる。だけどこの時点ではそれを意識して書く必要はない。実際このフェーズで上がった例のほとんどはシナリオとしては使わないらしい。

  • この5章は、初版には載っていなかった(あるいは前後の章の中で少し触れていた程度だった)が、2nd Editionになって、「フィーチャーやストーリーを定義する」と「Gherkinのためのシナリオファイルを書く」の間にこの章が作られたことを考えると、これまでフィーチャーからシナリオファイルに変換する作業が難しかったので、例を用いた様々なテクニックが使われるようになったのかなと推測した。

次の6章は、要件定義について解説した第2部の最後に当たり、成果物としていよいよシナリオを書いてFeatureファイルを完成させていくようなので楽しみ。

BDD in Action, Second Edition 第4章を読んだ

4章を読み終えたのでまとめ。*1

www.manning.com

さて4章は、3章で出てきたフィーチャーの詳細化の方法を説明しています。

3章で疑問に思ったフィーチャーの定義

3章でフィーチャーと特定された中には「これはフィーチャーなのか?」と思う物がありました。 kazokmr.hatenablog.com

この疑問について章の最初に触れており、フィーチャーに限らずこれらの概念として用いられる用語は、扱う方法論によって少しずつ定義が異なることがよくあり、混乱の基になっていると書かれていました。

そこでBDD(あるいは、この本)の中では、用語を次のように定義しています。

  • この本では、主にケイパビリティフィーチャーユーザーストーリー例(Example)の4つを用いて説明する。
  • ケイパビリティは、ユーザーやステークホルダーが「何かを行うための能力」を表し、ソフトウェアの実装に依存しない。
  • フィーチャー, エピック, ユーザーストーリーは、ケイパビリティをサポートするためのもの。 扱う規模が違うが概念はほぼ同じで「エピック => フィーチャー > ユーザーストーリー *2」となる。

フィーチャー

前章で利用したインパクマッピングにおいて、最後の成果物(Deliverable)をフィーチャーとします。 ちなみに、前段の影響(Impact)を、ケイパビリティとして扱います。

インパクマッピングから、フィーチャーを定義すると次のようになります。

Feature: "成果物(Deliverable) "
In order to "影響 (Impact)"
As a "関係者(Actors)"
I want to "成果物をビジネス用語で表す。"

起点となるGoalがここには現れませんが、「そのフィーチャー(Deliverable)は、ケイパビリティ(Impact)を関係者(Actors)に与えるために提供する。」と表現できるので、個人的にフィーチャーが考え易くなると感じました。

また、3章および元々のインパクマッピングでは「影響をHow、成果物をWhat」と説明しているが、フィーチャーを定義するときは「影響をWhat、成果物をHow」と表している。 これについては、目標を機転に成果物を特定していく時と、特定した成果物を表現する時の違いと考えればそれほど違和感を持たなかった。*3

フィーチャーとユーザーストーリーの違い

BDDでは通常、ユーザーストーリーは、フィーチャーを小さく分割して定義していくそうです。*4

ユーザーストーリーがフィーチャーと大きく異なる異なるのは「それ単独でリリースする価値があるかどうか?」と言う点であると説明されていました。*5

ユーザーストーリーの主な概念は(目的?)は次のようになります。

  • フィーチャ-における1つの事象、1つの側面を切り取ったもの
  • ステークホルダーとの会話をより良く進め易く、また、開発し易い大きさにしたもの
  • 1回のイテレーションでリリースできるサイズにしたもの

フィーチャーについてより深く考えていく過程で、思いついた具体的な状況や例を一つ一つをユーザーストーリーとすると作りやすいと感じました。

Real Options と Deliberate Discovery

訳すと「現実的な選択」と「意図的な発見」となるかなと思います。

ステークホルダーの目標を達成するためのケイパビリティに役立つと考えるソリューション、つまりフィーチャーを検討する中で不確実なことが出てきます。それらは大抵、自分たちの無知や誤解から生じます。このような不確実性に向き合って要件に対する共通理解を得るために、この2つの原則について説明しています。

Real Options (現実的な選択)

不確実性が原因で、最適だと考えるフィーチャーが思いつかない、あるいは確信が持てない場合に用いる代替案や保険的なフィーチャーを考えておく事を指します。

この目的は「決断を可能な限り先延ばしにする事」にあり、最適なフィーチャーを考える時間を確保することにあります。 そのためにReal Optionにはいくつかのルールがあります

  • Real Optionにも価値を持つ必要がある。
  • Real Optionに期限を設ける。
  • 何事もすぐに決断をしない。
  • でも、最適なフィーチャーである確信が持ったら、期限を待たずに実装する。
Deliberate Discovery (意図的な発見)

最適なフィーチャーを特定するために、無知なことを学んだり、誤解を無くして共通認識を持つ事を積極的に進める考え方で、不確実なことはプロジェクトのリスクになるので、早く解消する事を目的とします。

本に書いてあった説明だと、例えばバックログリファインメントで、どのフィーチャーから取り上げていくかを考えたときに、「最適な方法が明確なもの」よりも「不確実性というリスクを持つもの」から優先して取り掛かることで、プロジェクト全体の明確さを底上げした方がいいとありました。実際にはバランスが重要ではありますが。

この2つの原則を併用して、不確実性を取り除いた最適なフィーチャーを積極的に特定していくと良さそうです。

感想

これまでは最初から、断片的なユーザーストーリーを作ろうとして、ストーリーが上手く定義できなかったり整理できないことが多かったので、「ケイパビリティ -> フィーチャー > ユーザーストーリー」と順番に思考していくと作りやすそうだと感じだので、チャレンジしていきたい。

(おまけ) describe と illustrate

どちらも 「説明する」 と言う意味だが、この章では主にDescribeを使っていて、次の章からはIllustrateフェーズと呼ぶように後者が話の中心になる事を明示していたので、この意味の本質的な違いを調べてみました。

describe
  • 「詳細化する」と言う意味もある。
  • 大きなフィーチャーを小さく分割していき、ユーザーストーリーに分割していく流れは、まさに詳細化だと感じました。
illustrate
  • 「解説する」「例となる」と言う意味合いが強い。
  • 明確にするようなハッキリとさせる様子があると感じました。
  • 次章で紹介する例(example)などは正に、この意味合いになると思います。

*1:ちなみにこれを書いている時点で、次の5章までしか公開されていない。

*2:実際には、フィーチャーとユーザーストーリーには大きな性質の違いがあるのですが、それは後述します。

*3:後者において成果物を実装するコードと捉えればHowと言えるし、そのフィーチャーの目的と捉えれば影響すなわちケイパビリティをWhatと表現することはそれほどおかしくは無いと思う。

*4:他の方法には、大きなテーマからユーザーストーリーを考え出す方法があり、どちらから言えば自分はこの考え方だった。

*5:ちなみにビジネス価値はシステムが対象としている業界によって変わるので、ある場合はユーザーストーリーと定義された物が、違う状況ではフィーチャーとして価値が出せることもあります。

BDD in Action Second Edtion の3章を読んだ感想

BDD in Action Second Editionの3章を読み終わりましたので、この章の感想を記録しておきます。

www.manning.com

第3章は、Specurate(推測)フェーズとして、プロジェクトの最上位のコンセプトとなるビジョンをスタートに、ビジネスゴール, ケイパビリティ ,フィーチャー と順番に特定する方法を説明しています。

BDDのためというよりは、問題の解決方法を仮定するまでの考え方と色々なテクニックを紹介しています。

また章を通して「コミュニケーションを重ねること」と「解決方法を仮定して証明すること」の重要性を説いているようにも感じました。

ビジョン

ビジョンステートメントを作る。本の中では「キャズム」の著者が提唱し「アジャイル サムライ」のエレベーターピッチの書き方でも採用されているテンプレートを使っている。

ビジネスゴール

ビジョンに基づいて、達成したい事と達成する事で得られる利益を定義する。SMARTを活用した明確な目標を立てる。要求されたことの本質的なゴールを特定するために、その要求が「ビジョンにとってなぜ有益なのか?」を明らかにするためには、なぜなぜ分析を使っている。これについては「ザ・ゴール」を読むとよりわかりやすそう。

インパクマッピング

「ゴール -> 関係者(アクター) -> インパクト(影響/効果) -> 成果物」と関係性を定義することで、必要なケイパビリティあるいはフィーチャーを特定していく。

  • ゴール: ペインポイントとして、現在抱えている問題を解決する方法を定義する。 (もちろんSMARTやなぜなぜ分析も使って洗練させると良いと思う。)
  • 関係者: ゴールに関係するステークホルダーやユーザーを定義する。直接的/間接的を問わず、ゴールに対して恩恵を受ける人を考える。
  • インパクト: 関係者がそのように振る舞うことで、ゴールが達成できると仮定する行動を書く。
  • 成果物: その行動を起こすための「何か」を仮定する。ソフトウェアやツールで実現することにこだわる必要な無い。

インパクマッピングは、仮定の検証を繰り返す事でアップデートしていく。なので検証で判断するための測定基準も考える。

パイレートキャンバス

インパクマッピング、パイレートメトリクス、そして制約理論*1を組み合わせて、幅探索アプローチで(TODO: フィーチャーやケイパビリティ)を特定するやり方。

パイレーツメトリクスはAARRR*2と呼ばれる、Aqcuition(獲得)、Activation(活性化)、Retention(保持)、Referral(紹介)、Return(利益)の5つの視点で測定基準で分析を行うこと。本の中ではこれらの測定基準を使って、ToCにおけるボトルネック、つまり制約を特定していく。

パイレートキャンバスはこれを応用して、この5つの視点ごとに業務の制約とその制約を測る指標を考える。その後にこの制約と指標を目標にして、インパクマッピングと同じように関係者やインパクト、成果物を特定する。この成果物をエピックになる。

インパクマッピングとパイレートキャンパスの使い分け

明確で優先するべき目標が定まっているかどうかがポイントと感じた。目標に対する関係者・インパクト・成果物を特定するプロセスはどちらも同じなので、インパクマッピングはどのみち使っていくことになる。

パイレートキャンパスは目標を考えることから始めるので、多くの目標が生まれ、それぞれに対するインパクトや成果物を順番に特定する幅優先アプローチとなる。この方法は労力や時間は掛かるが、幅広いアイデアが生まれる可能性が高く、どの目標から優先して取り掛かるべきかが把握しやすいことが特徴。

パイレートキャンバスを使って、ペインポイントとなる潜在的な制約(ボトルネック)を特定し、それを向上させるためのケイパビリティ(エピック)について、ソフトウェアによる解決方法に拘らずに話し合って見つけていくやりとりは、劇中作とは言え興味深く読むことができました。

感想

相手の要望を初めから、ソフトウェアで解決する方法から考えたり、相手からも「ソフトウェアをこうして欲しい。」といった感じで要求されることが多いかった。これはつまり、Featureの要望や検討をしていると言うことになるのだが、正しいフィーチャーを特定するためには、まず「何ができるようになると嬉しいのか」といったケイパビリティを特定するプロセスが重要でした。

この章ではプロジェクトや企業のビジョンから、フィーチャーを特定するまでの説明だったが、ゴールとケイパビリティの特定に重点が置かれているように感じた。フィーチャーについては大枠を掴んだだけといった感じだったので、次章以降でこの荒削りなフィーチャーを洗練する方法を説明していくと思います。

英語の表現を日本語で表すのが難しい言葉が多くなってきた。そのまま英語で表現した方が意味がより理解できる気がする。この章は特にそれを感じた。

*1:ゴールドラット氏が著書「ザ・ゴール」で提唱した、Theory of Constrains。ちなみにこれを知るために「ザ・ゴール」と「ザ・ゴール2」のコミック版を買って読みました。

*2:これが海賊の雄叫びのようなことがパイレーツメトリクスの語源みたい

BDD in Action Second Edition の第2章の感想

第2章を読み終えました。この章から構成が初版と変わってきているなと感じました。*1

www.manning.com

この章ではプロジェクトのライフサイクル全体におけるBDDの使い方を理解する目的で、架空のプロジェクトを舞台にして話が進んでいきました。

また後半は実際にCucumberを使って、featureとグルーコード(Definition step)を起点に、テストしながらプロダクションコードを書き進めます。

実践部分は、掲載されているコードが間違っていたり(古い?)、所々説明が端折られていたので、実際に全部のテストを通すためには自分で考えながら進める必要がありました。 *2

英語を訳しながら進めたことや前述の様なこともあってか、BDDスタイルの書き方を やらされた感が強くあったり、スッキリしないところもあったので、これはまた自分なりにやり直してみたいと思います。

その他、この章で感じたこと

  • Cucumberの使い方ではなく、BDDの考え方を学ぶストーリーだったのが良かった。(とはいえ、DefinitionStepクラスのテストを通すためにはCucumberの初歩の使い方は知らないと詰まりそうですが。)

  • DefinitionStepを起点にコードを実装し始めるときは、Then -> When -> Given の順番に実装していくと良い。GivenとWhenは、前提と入力の位置付けなので、そこはリテラルな値やモック的なメソッドを仮実装したものを利用して、まずはThenを実証できる様にして置いた方が、組み立てやすいからと理解しました。

  • コードを実装していく所は基本的にTDDで進めるのですが、実装クラスに対応した「実装クラス名 + Test」の様なクラスを用意するのではなくストーリーレベルでテストクラスを作ったり、テストメソッドの中でWhenやThenの考え方を取り入れるなどBDDスタイルなテストコードの書き方も取り入れて、使い分けるのも良いと思う。

  • 真の要件を見つける時に利用していた、インパクマッピングも初めて知りましたが、Why->Who/Whose->How->What の流れで分解するやり方は問題の解決策を考えやすい方法だと感じましたし、本文を見ていて自分がWhatだと思っていたことはHowの段階であり、さらに分解して具体的にする必要があるんだと気付けました。

  • シナリオの記法は目的に応じて使い分けると良い。例えば、「ビジネスの目的のためにユーザーにさせたいシナリオなら、"Given ... When ... Then"」「ユーザーの目的のために達成したいシナリオなら、"As a … I want … so … that"」 と言った感じに分けて使うと良い。

  • 開発チームやテスターといったプロジェクト側のチームが「本当の要件を発見すること」を強調していて、顧客側から「こう言う問題をこう解決したい」の様に、要件だけでなく解決方法も指示されたことも多かったので、まずはそもそも問題の本質を自分達も一緒になって改めて考えることを気をつけないと再認識しました。

実体験で、本章の様な顧客との会話のやりとりは要件定義ミーティングでも頻繁にあったのですが、この様なミーティングは、毎週または隔週の数時間だけと限られていたので、正しい要件を見つけるには時間が全然足らなかった。さらには、実装する機能のボリュームはやたらと多かったので、こんな進め方だとそりゃ上手くいかないよな。と再認識した。

この辺の要件定義の進め方や正しい要件の見つけ方は、BDDの学習を通して、身に付けていきたいです。

*1:初版を読んだわけではなくて、目次のセクションや本文をざっと見たときの印象ですが。

*2:著者の方がGithubに最終形となるコードを上げているので、それも参考にしました。

BDD in Action 2nd Edition の 第1章を読んだ感想

これは、BDD in Action Second Edition の 第1章 "Building software that makes a difference" までを読み終えた感想文です。 www.manning.com

第1章は最初の導入部分として、BDDが生まれた背景、概要、原則について書かれています。*1 BDDというと専用フレームワークを使ったプラクティスの話が多く、この本も読み進めてするとCucumberを使った実践例が出てきますが、この1章では「なぜこのようなプラクティスを使うのか」と言ったBDDの概念や背景が中心になっているので、BDDのことをより深く知るための基礎が理解できたと思います。*2

この中で特に印象に残ったことをいくつか取り上げてみます。

BDDの原則

1.3.3 の BDD principle and practices は、1章の中でも特にボリュームがあり、内容的にもここで書かれていることがこの章で最も説明したいことだったのかなと思います。

BDDの活動の流れと成果の具体例は以下のようになります。

ビジネスのゴール -> Feature -> Examples -> Executable specification -> Low-level specifications -> Application code

  • Featureは、ビジネスのゴールを達成するための機能であり、ユーザーストーリーなどで説明します。

  • Examplesは、機能の使い方に関する具体的な例で、Gherkin形式(Given ... When ... Then...)で書かれたシナリオになります。

  • Executable specificationは、受け入れテストでシナリオに従って機能が正しく動作することを検証可能にしたもので、いわゆるテストコードになります。

  • Low-level specificationは、シナリオを元に必要なコンポーネントの仕様で、ユニットテストのテスト仕様書やテストコードを指します。

  • Application codeは、機能として動作するコードで、例えばテストコードを使ってTDDなどで開発したプロダクションコードを指します。

これらの活動や成果に対するプラクティスやルールを、本の中で述べています。特に参考になった内容の幾つかを意訳すると以下のようになります。

  • ビジネスを理解する学習曲線は、初期に大部分のことを理解できるような対数的ではならないし、ましてや線形的に伸びるものでもない。時間と共に伸びたり停滞したりを繰り返しながら成長するので、要件の定義はプロジェクトの終盤まで繰り返し少しずつ行う。

  • ビジネスユーザー側の代弁者としてユーザーアナリストが要件を聞いて、開発者やテスターに伝えるのではなく、3者がプロジェクトの初期段階から協力しあい、ステークホルダーやエンドユーザーも一緒に話し合って、ビジネスのゴールやFeature、Examplesを作っていく。

  • ビジネス側は作って欲しい機能について、問題解決方法だけを提示して開発チームに作らせがちだが、開発チームと必要なことについて話し合うことや、開発チームの専門的な設計知識の恩恵を受けられるようにする。

  • テスターはExamplesを考えるときに、コーナーケース や エッジケースを思いつき、ユーザーに質問することができ、有益な例を追加することができるので、プロジェクトの初期から参加することは非常に価値があることである。

  • 自動化したテストを書くのではなく、"実行可能な仕様書" を書くようにする。同様にBDDにおけるユニットテストは、ただ単にクラスファイルやメソッド、ファンクションをテストするということではなく、コードの目的やコードをどのように使うかの例に従って動作することを検証する。

これらのプラクティスは、以前から様々な所で聞いたことがありましたが、BDDにおけるプラクティスの目的をベースにより深く理解することができました。

BDD以外の技術やプラクティスとの関連性

読んでいて「ここはあの技術のことだな」ってわかることや、実際に本の中で言及しているモノあり、BDDの概念と目的の元、多くのプラクティスを取り入れていると思いました。

BDDはTDDの実践例として考案されたのが始まりで今では別のプラクティスとして捉えられている。とはいえBDDがTDDに置き換わるプラクティスということではなく、TDDはコードの品質にフォーカスし、BDDはプロダクトの品質にフォーカスしているので両方を使い分けることが重要です。

また、ビジネスで使われる用語や語彙を使ってExamplesを作るプラクティスなどは、同時期に考案されたDDDのユビキタス言語と共通する物がありました。

そのほかにもビジネスアナリスト、開発者、テスターの三者が協力して、ビジネス側のステークホルダーやエンドユーザーと一緒にFeatureやExamples を作るのは、ユーザーストーリーマッピングスリーアミーゴスの考え方と一致します。

もちろん、これらの根底にはアジャイルやイテレーティブな開発手法が関わっています。

2nd edition では、DevOpsやScaled AgileにおけるBDDの実践方法についても書かれる予定になっています。


次の第2章では、要件分析から自動化されたユニットテスト、受け入れテスト、機能的なテストカバレッジレポートと言ったプロジェクトの全体的な活動を通して、BDDのより実践的な例を説明するようなので、また読み終えた後にナレッジの整理のためにまとめたいと思います。*3

*1:この Second Editionは、MEAP という執筆中の内容が読めるプログラムであり完成版では無いのですが、1章は初版から図は差し替えられていますが、文章はほとんど同じでした。

*2:私自身はBDDを業務で実践したことはなく、概要を聞きかじったり、CucumberのHPのチュートリアルに触れたことがある程度です。

*3:ちなみに自分の裏のテーマとして英語の技術書を(ツールを利用しつつも)自分で翻訳しながら読み進めているので、読むペースがかなり遅いです。この1章も外出自粛のGW期間中だったからまとまって読みことができました。これを仕事の中でも進められるといいのですが、今のところはそういう訳には行かないので2章を読み終えるのにも1ヶ月以上かかりそうです。幸いにも(?)この本自体も現時点でまだ4章までしか公開されていませんが。

なぜ「Javaが有償化する」と誤解されてしまうのか考えてみる

追記:対象としているJavaエンジニアの範囲を大袈裟にしすぎたかなと感じましたので、その辺を修正しました。

なぜ書いたのか

タイトルの件ですが、有識者の方々が様々な媒体や場所で発信をされているおかげで、以前に比べて少なくなったと感じてはいるものの、まだ時々誤解を持たれているJavaが有償化する」と呟かれているエンジニアの方もたまに見かけます。

Oracle JDK 8およびOpenJDK 11、それぞれ最後の無償アップデートがリリースされ、これから有償または無償のLTSでアップデートを受け続けるか、OpenJDK 12に移行するのかといった選択を決めていく状況になる時にまだこのような誤解を持ったままでいいのかなと感じました。

そこで自分の経験を基に誤解をする側の立場になって、なぜ「Javaが有償化する」という誤解が生まれたのかを考察してみようと思いました。

尚、この内容は個人の見解で、間違った認識な所もあると思います。 また無駄に問題提起をしている箇所もあると思いますので、ご意見・ご感想を頂けるのもありがたいですが、スルーしてもらった方が良いかもしれません。

前提と仮定

考察に入る前に自分が認識は以下の通りです。これが間違っていたらご指摘ください。

  • JavaソースコードはOpenJDKプロジェクトがベースで誰でも使える。
  • OracleのHPからダウンロードしているJDKはこのソースコードから生成したもの
  • Javaの新バージョンリリースから半年間は、Oracleが生成したのと同じJDKここから無償で入手できる
  • 半年より先は、"新バージョンのJDKを入手する"、"Oracleから有償のLTSを受けてJDKをアップデートする"、"Oracle以外のベンダーの無償または有償のJDKを入手する"などの大きく3つの選択肢がある。
  • 有償になったのはOracleが生成したJDKの利用も含むサポート
  • Javaソースコードは今も昔も無料で使えて、誰でもJDKを作れる。
  • だからJavaは有償化なんてしていない

さて誤解のポイントは、下から3つ目の
"有償になったのはOracleが生成したJDKの利用も含むサポート"
な訳ですが、これがなぜJavaが有償化と捉えられるのか3つの視点で考えてみました。

  1. Javaを使うときにJDKはどうやって入手するか
  2. Javaは誰のものと考えているか
  3. どこのライセンスが変わったのか

前置きが長くなってしまいました。

JDKはどこから入手するか?

これはほとんどが「OracleのHP」からダウンロードしていたのでは無いかと思っています。エンジニアの大多数が使っているであろうWindowsなら尚更です。
OSがLinux系やMacであれば、yumとかapt、brewなどを使うことでそこまでダウンロードサイトを意識することは少ないのかもしれませんが、Windowsだとそのようなパッケージ管理ソフトも無いので、Oracleダウンロードサイトからの入手も多くなると思います。

じゃあ、今まで無償でダウンロードできていたページで「これからはダウンロードしたければ、Oracleの有償サポートに入ってね」となると、Javaが有償化したと思われるのは仕方が無いと感じます。

個人的には、Oralce JDKjdk.java.netからダウンロードできるJDKが、Oracleが生成したものなのですから、最初の半年間だけでも両方ともOracleのHPから直接ダウンロードできればわかりやすいのかなと思いました。

Javaは誰のものか?

こう聞かれた時に多分「Oracleのもの」って答える人が多く、もう少し付け加えると「JavaOracleが開発してオープンソースで提供している、無料で使えるプログラミング言語」のような認識ではないかと思います。

なので、OracleのHPからダウンロードできるJDKを"Javaの正規品"のように考えていて、OpenJDKに至っては"OracleJavaをコピーして無償で提供している派生品"くらいに考えているエンジニアは少なくないと思っています。少なくとも昔の私はそう考えていました。

こうなると、"JavaOracleのもの" > "Javaを使いたければOracleから入手する" > "Oracleから入手するには有償サポートに入らなければならない" > "Javaが有償化したと思い込む" といった誤った認識の連鎖が生まれてしまうのは容易に想像できてしまいます。

まぁこれらは全て間違った考えなので正していくしか方法は無いのですが、効果的に知らしめる方法が必要だと思います。

JVM言語には関係ないのか?

ScalaやKotlinを使えば有償にならない」のようなニュアンスのことを話される方をたまに見かけるのですが、 少なくとも書いたコードをコンパイルして実行するにはJVMは必要なので、JDKを入手することになります。
(Scalaのダウンロードページは「はじめにJava 8 JDKをインストールしてね。ダウンロードはここだよ」って感じでOracleのHPへのリンクがありますし。)

で「"JVM言語なら関係ない"と言うエンジニアはどこからJDKを入手しているのか?」と言う疑問が出てくるわけですが、これは当人に聞かないとわからず小心者の私にはできないため、私はScalaやKotlinを職場で使ったことが無いので憶測で考えてしまったのですが、入手先どうこうよりそもそも以下のような認識なのかな?と感じました。

  • Java言語を使うことだけが有償で、JVMを使うことは無償のまま(だからOracle JDKも使える)
  • JVMはダウンロード済みJDKを使うだけだから関係ない。(JDKのバージョンアップを考慮していない。)

要するに「都合の良い解釈をしてしまっているだけなでは?」と考えられますが、そこを辿ると、今回の有償の対象が"Javaソースコード"だと認識してしまっているのでは無いかとも考えられました。

私自身の経験も含めてオープン"ソース"と言う言葉から、ライセンスの対象になるのはソースコードだけだと考えてしまうことがあります。
つまり、実際は『OracleのHPからダウンロードできる、Oracleが生成したJDKがライセンスを変更した』が正しいのですが、それを『Javaソースコード自体のライセンスが変更になった』と誤解していることも考えられるわけです。

JVM言語を例にして憶測で話してしまいましたが、考察したかったのは"Javaソースコード"のライセンスの誤認識だったわけです。

誤解を無くすためにするべきこと

冒頭にも書いた通りJava界隈の有識者の方々は毎日のように正しい情報を発信したり、誤った発信をしている人には指摘をしているのを見かけますが、それだけでは足りないと感じています。
それは、このような発信を受け取っているJavaエンジニアの数はそれほど多く無いと思っているからです。

例えば前職ではJavaを使っていたエンジニアは社内に数十人はいたと思うのですが、私以外にJJUGなどのイベントに参加している人は知らなかったです。
ここから考えられることとして、正しい情報を受け取っている人の背後には、正しい情報を知らないエンジニアが大勢いると言うことなのです。正しい情報を得ずに仕事で使っているエンジニアは自分が思っている以上にいると言うことです。 (もちろんこのような会社ばかりだとは思いませんが、実はJavaのことよく知らずに使っているJavaエンジニアの数は想像以上に多いとも思っています。)

なので自分達が得た正しい情報を身近な組織やチームに発信をすることが大事なのではないでしょうか?

  • 少なくとも開発チームのテックリーダーは、正しい情報を取得することを心がける。
  • 正しい情報を持っている人は、少なくとも社内やチーム内にその情報を発信する。
  • 自分たちのプロダクトのJDKの選択を社外にアウトプットする

今回このブログを書こうと思った理由もそんな所で、既に今回の変更の詳細については昨年の時点で社内Wikiでは発信していていたのですが「自分や組織が理解出来ていれば良い」だと誤解は解消されないからと感じたからでした。

じゃあ自分の組織はどうしているか?

今の会社はリセラーで直接の開発はしていませんが、販売しているメーカーからは、Oracle JDK(有償)とAdoptOpenJDK(無償)の2種類を動作サポートとするようです。 また製品の既存バージョンに対しては引き続きJava 8のみをサポートし、次の新バージョンからJava 11も動作サポートするようです。すなわちJava 8または11のLTSを対象にして製品開発が進められていくと考えられます。

まとめ

今回のJavaのリリース方針とサポートプランの変更は、Javaエンジニアの半数ひょっとするかなりの人数が誤った情報を信じ、正しい情報は自分自身で取りに行かないといけない状況になってしまっていると感じています。 なので情報を得た人達が積極的に正しい情報を発信したり、誤解に気づけたなら誤解した理由を発信することも大事だと思いますので、このブログを見て共感いただけたなら社内にも社外にもどんどん発信してもらえればいいなと思います。

(追記) こちらの記事を読んでコメントを下さった @yamadamn さんからこんな返事を頂きました。

確かにきしださんやViViさんが仰るように「全て理解しているけど、これまで考えなくて良かったことを検討・対応・調整しなければいけなくなった」といった業務としてのコストが掛かることで"実質有償化"と捉えている方もいそうですね。
逆にOpenJDKの選択肢が増えたことで、どれを選べばいいかを考える必要もありますので。

参考

この話を読んでも理解できないことは以下です。
私のこの記事を読んでも、以下のような実際にこれからもJavaを使っていくために必要な情報の答えは得られないと思いますので、こちらのリンクなどをご覧いただければと思います。

Oracle Java SE Supportロードマップ | Oracle 日本

Java SE 一般的なFAQ | Oracle 日本

JDK:新しいリリースモデル解説 @ 富山 BuriKaigi 2019

JDK、Oracle JDK、OpenJDK、Java SEってなに? - Qiita

Javaは今も無償です - Google ドキュメント

JDKの長期商用サポート(LTS)の提供ベンダー比較(無償利用についても言及あり) - Qiita

Javaはオラクルのもの?」、「いいえ、これからもJavaコミュニティのものです!」――Javaエバンジェリスト寺田佳央氏が、Javaの現在、未来を語る | Oracle 日本