読んだ : RESTful Web Services with Dropwizard / Alexandros Dallas 著
Dropwizard に関わる仕事をしているので読んでみました。
RESTful Web Services with Dropwizard
- 作者: Alexandros Dallas
- 出版社/メーカー: Packt Publishing
- 発売日: 2014/02/19
- メディア: Kindle版
- この商品を含むブログを見る
Dropwizard について
Dropwizard は Java の web アプリケーションフレームワークです。 基本的には既存ライブラリの組み合わせで web アプリケーションを構築するというもので、Dropwizard 固有の仕組みはさほど多くありません。 (例えば Web リクエストを受け取るのは Jersey で、DB アクセスには Hibernate か jDBI が使われる。)
特に Java EE 系の知識を持っている人であれば、とっつきやすい感じです。
本書について
本書は、Dropwizard を使って web アプリケーションを構築するための方法を説明するものです。 プロジェクトの準備や、HTTP リクエストを受けるエンドポイントの記述、DB アクセス、ユーザー認証、HTML を返す View テンプレートについてなど、基本的な要素について、サンプルコードを交えながら仕組みが解説されます。
Java EE などについてある程度わかっている人が読むと Dropwizard の公式ドキュメントを読むのと大差ないと思いますが、初心者の人が読むと結構わかりやすいんじゃないかなと思います。 (ある程度わかってる人にとっても、Dropwizard についてざっと知ることができて良いかもしれませんが、そういう使い方だとちょっと値段は高めに感じる気がします。)
本書での学び
参考のリンクとしては現時点での最新バージョンのドキュメントへのリンクです。 閲覧時の最新バージョンのドキュメントは各自探してください。
- Dropwizard では、maven-shade プラグイン を使って、単体で web アプリケーションとして実行可能な JAR ファイル (uber-jar) を作る。
- Hibernate Validator によるアプリケーション設定のバリデーションが可能。
- jDBI で DB から取得した結果をオブジェクトにマップする方法として、
@MapResultAsBean
アノテーションを使うという方法もある。- 参考 : MapResultAsBean (jDBI 2.48.2 API)
- とはいえ公式的なドキュメントは何もなく、ドキュメント化されていない挙動に依存することになるので不安。 (JDBI の機能の多くがドキュメント化されてないのでまあこれに限った話ではないのだけど。)
- HTTP リクエストパラメータのバリデーション周り。
- JAX-RS のリソースメソッドのパラメータのバリデーションを明示的に実行することも可能。 (
@Valid
アノテーションでのバリデーション実行しか知らなかった。) - 複数フィールドにまたがるバリデーション。
- 参考 : Dropwizard Validation | Dropwizard
- JAX-RS のリソースメソッドのパラメータのバリデーションを明示的に実行することも可能。 (
- Dropwizard には HTTP クライアント用モジュールも含まれている。
- 認証周り。
- Basic 認証用のクラスが用意されている。
- オプションの認証も可能。 (認証されたユーザーの場合はそのユーザー専用のコンテンツを表示し、さもなければ一般ユーザー向けのコンテンツを表示する、みたいな。)
CachingAuthenticator
によるキャッシング。- 参考 : Dropwizard Authentication | Dropwizard
- Fixtures for Easy Software Testing (FEST) というプロジェクトがある。 TestNG や JUnit と一緒に使える。 ソフトウェアテストを書きやすくするライブラリ。
感想
Dropwizard をそこそこ使ってて公式ドキュメントも (全部ではないけど) 読んでいたので、本書での学びはあんまりなかったです。 とはいえ上に書いたように新たに知れたこともいくつかあったので読んでよかったです。 (そんなに時間もかけずにざっと読めましたし。)
とはいえ紙の本だと 30 ドル以上するので、ちょっと高い感じはしますね。
読んだ : Kotlin スタートブック ― 新しい Android プログラミング / 長澤 太郎 著
Kotlin エバンジェリスト (JetBrains 黙認) であり、日本 Kotlin ユーザグループ代表であるたろーさん (長澤 太郎) によって書かれた書籍 『Kotlin スタートブック ― 新しい Android プログラミング』 (赤べこ本) を読みました!!
Kotlinスタートブック -新しいAndroidプログラミング
- 作者: 長澤太郎
- 出版社/メーカー: リックテレコム
- 発売日: 2016/07/13
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
本書を読む前から、公式のリファレンスやチュートリアルなどの気になる箇所を見てはいて Kotlin についてはなんとなく理解はしていたのですが、ところどころ知識が欠けている部分もあったので、本書によってそういった知識の欠落を埋めることができました。
どんな本か?
内容については著者のたろーさんが紹介されています。
導入としてまず 1 部があり、2 部で Kotlin の文法や機能の詳細が解説されます。 3 部にて、Android アプリ開発で Kotlin をどのように活用できるかが説明されます。 対象読者は 「Java および Android 開発経験者」 と書かれていますが、2 部までなら Android アプリ開発については知らなくても問題なく読み進められます。 「Android アプリ開発で Kotlin を使うために読む本」 というわけではなく、「Kotlin を使い始めるときに読む本」 かつ 「Android 開発に Kotlin を活用するためにどうすればいいかが書かれている本」 という感じです。
全体としては易し目の説明でスクリーンショットも多用されているのでプログラム開発の初心者でも読みやすい本だと思います。 一方で、説明する内容についてきちんと節が分かれていて飛ばし気味に読むこともやりやすいので、ソフトウェア開発についてある程度経験がある人が Kotlin の導入のために読むというのにも適しています。
感想
Kotlin を Java の代わりとして使い始めるのは結構簡単で、いくつかある Java との違い (各種文法の違いや 「==
演算子は同一性検査ではない」 みたいな違い) をおさえさえすれば導入できます。 逆に導入するのが簡単なせいで、「ちゃんと Kotlin 特有の機能や文法を学ぶ」 機会を設けず、必要に応じて公式リファレンスを参照している、という人も多いのではないでしょうか。 私もまさにそんな感じだったので、今回本書を読んで Kotlin 特有の機能、文法を学べたのは非常に良かったです。
内容的には深く突っ込んでいくという感じではないので、本書を読みつつ気になったところは公式リファレンスを参照する、みたいに読み進めていくといい気がします。 公式リファレンスとは違った視点での説明されている項目もあったりするので、両方参照することで理解が深まったりもすると思います。 公式リファレンスには書かれていない 『!!
演算子の代わりに requireNotNull
メソッドを使うと良い』 というような記述があるのも本書の良いところですね。
まさに 「これから Kotlin を使っていこうと思っている人のための Kotlin 入門本」 として、以下のような人にオススメできる書籍でした。
- Kotlin を使ってみてるけどまだ Kotlin 全体についてちゃんとは学んでいない。
- まだ Kotlin を使ってみてないけどこれから使ってみようかと思っている。
第 3 部の内容 (Kotlin で Android アプリ開発) について、ほとんど知っているものだったので自分にとってはあまり意味はなかったのですが、Kotlin を使った Android アプリ開発がどんな感じか全然知らない人にとってはそれらも役立つと思います。
読書メモ
自分にとって気になった箇所と、それに関連する公式リファレンスへのリンク。
require
メソッド で満たすべき条件を記述できる。 (P31)- string template と raw string 50
List
型の値がイミューダブルとはかぎらない。List
型のサブクラスにImmutableList
があるので、ImmutableList
オブジェクトがList
型として渡される可能性がある。 (P54)List
以外のコレクションクラスも同様。
Range
のin
演算子で、値が範囲に含まれているかどうか調べられる。 (P55)- イテレータに何らかのインターフェイスを実装する必要はない。 規定のメソッドさえオペレータとして定義されていれば良い。 (P63)
- 可変長引数は
vararg
修飾子で宣言。 配列を渡すときには spread 演算子 (*
; アスタリスク) で展開。 (P73) - 末尾再起呼び出し最適化に
tailrec
修飾子。 (P76) - ローカル関数、関数定義の中に関数を定義できる。 (P77)
- インライン関数の引数としてインライン関数外で呼ばれうるラムダを受け取る場合は
noinline
修飾子を付ける。 (P94)- 修飾子を何もつけないと、インライン関数の実行コンテキストでの実行しかできない。 インライン関数の引数のラムダもインライン展開されるため。
- スタックトレースの内容に影響を受けるような関数も
noinline
にすることを検討すると良いとのこと。 - 参考 : Inline Functions - Kotlin Programming Language
- インライン関数の引数として別の実行コンテキストでインライン化されて実行されるラムダを受け取る場合は
crossinline
修飾子を付ける。 (P94)- これにより、非ローカルリターンが使えないことを呼び出し側に伝える。
- 参考 : Inline Functions - Kotlin Programming Language
- インライン展開されるラムダ式では非ローカルリターンが使える。 (P95)
- ラムダ式から脱出する場合はラベルへのリターン。 (P96)
- Kotlin にはラムダ式以外に無名関数もある。 ラムダと違い
return
で無名関数から脱出する。 (P97) - ラムダ式と無名関数をあわせて関数リテラルという。 (P97)
- 公開範囲は public と internal (同一モジュール内) と private と protected (Java とは違って同一パッケージからは見えない)。 (P138)
- 使用場所変位指定による型投影。 使用側で
in
またはout
修飾子を指定する。 (P163) - クラス宣言における型パラメータが共変の場合は
out
修飾子を、反変の場合はin
修飾子で宣言。 宣言場所変位指定。 (P165) - 型引数について何もわからない場合でもそのジェネリック型を使いたい場合にはスター投影。 (P167)
- インライン関数の型パラメータを具象型パラメータ (reified type parameter) にすることで実行時にその型を扱えるようになる。 (P168)
!!
演算子の代わりにrequireNotNull
メソッドを使うことで意図をメッセージで表現できる。 (P180)- 安全キャスト
as?
を使うと、キャストできないときはnull
になる。 (P183) - 参照の等価性と構造の等価性。 (P190)
- 言葉遣いが 「同一性」 と 「等価性 (同値性)」 じゃないんだなー、という部分がちょっと驚き。
- 参考 : Equality - Kotlin Programming Language
infix
キーワードのついた 1 引数のメソッドを中置表記で呼び出せる。 (P192)- 範囲を作る
..
も中置表記。 - 参考 : Functions - Kotlin Programming Language
- 範囲を作る
- 分解宣言 (destructuring declaration) には
operator
つきのcomponentN
メソッドが必要。 (P194)- データクラスは componentN も自動生成してくれる。 (P197)
- 参考 : Destructuring Declarations - Kotlin Programming Language
- 内部クラスには
inner
修飾子を付ける。 (P199) try
は式。 (P211)- レシーバ付き関数リテラルの型
A.(B)->C
は(A, B)->C
のサブタイプ。 (P214)
『Web API: The Good Parts』 を読んだ
- 作者: 水野貴明
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/11/21
- メディア: 大型本
- この商品を含むブログ (6件) を見る
同僚から借りて読みました。 全体としては Web API の設計に少しでも携わる人間ならとりあえず読んでおいたらいいんじゃないかなーという感じです。 薄いし。
本書を読んだからと言って最高の Web API の設計ができるようになるとは思わないですが、Web API の設計をする際に知っておくべきことが一通りまとまっていて良い感じだと思いました。
学びメモ
知らなかったことや、なんとなく知ってたけど改めて調べたことなどまとめておきます。
RFC 5861 での Cache-Control
ヘッダの拡張
RFC 5861 にて、Cache-Control
ヘッダの 2 つの拡張が定義されています。
stale-while-revalidate
ディレクティブ : プロキシサーバー上でmax-age
を超えてキャッシュが切れた後も、(裏側で非同期にキャッシュの検証を行いつつ) キャッシュ済みの古いレスポンスデータを返しても良い時間を指定できる。stale-if-error
ディレクティブ : オリジンサーバーへのリクエストに失敗する場合に、キャッシュ済みの古いレスポンスデータを返してもよい時間を指定できる。
RFC 5861 の現在の state は “Informational” らしいのでどれぐらいサポートされてるのかわからないですが、「プロキシサーバー上でキャッシュが無効になったあとも、裏でキャッシュ更新しつつユーザーからのリクエストに対してはレスポンスを返してほしい」 って状況はあるので、こういうのが既存のプロキシサーバーなどでサポートされてるとアプリケーション開発時に便利に使えそうです。
本書の 4.3.6 節 「Cache-Control ヘッダ」 に記述されています。
独自のメディアタイプを作る
メディアタイプの登録プロセスの効率と柔軟性を増やすために、サブタイプのいくつかの登録 『木』 (registration “trees”) が RFC 6838 にて定義されています。 それぞれの木には facet *1 が定義されているので、新たに作る独自のメディアタイプの用途に応じて登録木を選択し、それに応じた facet を付けることになります。 (登録木によっては登録作業なども必要。)
- Standards Tree : IETF 標準に関連付けられるなどした、標準のメディアタイプのための木。 Facet はない。
- Vendor Tree : 公に使用可能な製品に結びつけられたメディアタイプのための木。 Facet は “vnd.”。 (例 : “application/vnd.ms-excel”)
- Personal or Vanity Tree : 実験的に作られたり、商業的に流通しない製品の一部だったりするメディアタイプのための木。 Facet は “prs.”。
- Unregistered x. Tree : 私的に、ローカルな環境でのみ使われるメディアタイプのための木。 Facet は “x.”。
Web API で使用されるメディアタイプを新たに独自に定義する場合は、vendor tree か personal or vanity tree のどちらかになるでしょう。
本書の 4.4.3 節 「自分でメディアタイプを定義する場合」 に書かれています。
CORS 周り
XMLHttpRequest
*2 には同一生成元ポリシー (Same Origin Policy) が適用されるため、通常は生成元の異なる URL に XMLHttpRequest
でリクエストを投げることができません。 異なる生成元へのリクエストが可能になるように考えられた仕様として CORS (Cross-Origin Resource Sharing) があります。
それ自体は知ってたのですが、
- CORS でプリフライトリクエストが投げられる条件 (
POST
メソッドでもプリフライトリクエストするとは限らない、みたいな話を聞いたことはあったけど、詳しくは知らなかった)、とか Cookie
やAuthentication
などのヘッダで認証情報をやり取りする場合は、サーバー側はAccess-Control-Allow-Credentials
ヘッダを返す必要があり、クライアント側はXMLHttpRequest#withCredentials
というプロパティをtrue
にしないといけない
など知らなかったので、いろいろあるなーと思いました。
ちなみに最近は CORS (や他の仕様) を置き換えるものとして Fetch Standard が作られてるみたいですね。
本書の 4.5 節 「同一生成元ポリシーとクロスオリジンリソース共有」 に書かれています。
セキュリティ周りの話
X-Content-Type-Options
ヘッダ
IE (どのバージョンまで? 11 も?) には Content-Type
ヘッダの値を無視してレスポンス内容のデータ形式を推定する Content Sniffing という機能があり、JSON として解釈されるべきコンテンツが HTML として解釈されて XSS 脆弱性になる、という問題があります。
IE 8 以降の場合は、サーバーがレスポンスとして次のレスポンスヘッダを返すことで Content Sniffing を無効にできます。 さらに、Firefox や Chrome、IE 9 以降では、このヘッダを付けることで JSON ハイジャック *3 (後述) の危険性を減らすことができるそうです。 (JSON を返すときは常に付けましょう。)
X-Content-Type-Options: nosniff
詳細は次のページに書かれています。
本書では、6.3.1 節 「XSS」 に書かれています。
JSON ハイジャック
JSON 形式のレスポンスを JavaScript としてブラウザに解釈させることで、別オリジンのサーバーから配信される JSON の内容を悪意ある第三者の web ページが読みだすことができてしまう、という脆弱性。 例えば、悪意ある第三者の web ページが Array
オブジェクトのコンストラクタを書き換えたうえで、配列を返す JSON ファイルを script
要素で読み込むと、JSON の中身が書き換えられた Array
オブジェクトのコンストラクタに渡されてデータが読まれる、という感じです。 (これは Firefox 2 系で発生していた脆弱性で、最近のブラウザは対策済みらしいです。)
サーバー側の対策として、以下のものがあります。
script
要素では読み込めないようにする :script
要素で読み込まれた場合には送られないヘッダフィールド (X-Requested-With
ヘッダなど) を必須にする。- JSON のレスポンスをブラウザが JS として認識しないようにする :
Content-Type: application/json
にすることはもちろん、X-Content-Type-Options: nosniff
を付ける。 - JSON のレスポンスを JS として解釈不可能にする (あるいは JS として実行されてもデータが読まれないようにする) : レスポンスの先頭に
while (true);
を付けるとか。
本書では、6.3;3 節 「JSON ハイジャック」 に書かれています。
セキュリティ周りの各種ヘッダ
X-XSS-Protection
レスポンスヘッダ : XSS を発生させそうなパターンがレスポンスに含まれている場合に、ブラウザがレスポンスをブロックする機能を有効にしたり無効にしたりできるヘッダフィールドぽい。 この機能は Chrome と Safari、IE (8 以降) がサポートしてるぽい?- ちゃんとしたドキュメントはあんまり見当たらない。
- XSS ブロックの機能はデフォルトで有効っぽい *4 から、サーバーサイドでは基本的には付けなくてもよさそう?
- 参考 : IE8 Security Part IV: The XSS Filter | IEBlog
Strict-Transport-Security
レスポンスヘッダ : ブラウザからのアクセスを HTTPS に限定させる。- http でリクエストされたときに https にリダイレクトする、という挙動だと、最初の http でのアクセスが中間者攻撃で書き換えられる恐れがある → 以前にこのヘッダが送られてきていたら、ブラウザは最初から https でアクセスする。
- RFC : RFC 6797 - HTTP Strict Transport Security (HSTS)
- 参考 : HTTP Strict Transport Security - Security | MDN
Public-Key-Pins
レスポンスヘッダ : ブラウザに暗号公開鍵とドメイン (?) を結び付けさせる → ブラウザは将来に証明書が偽造された場合に検知できるようになる。- 攻撃者により認証局が危殆化した場合に中間者攻撃されるのを防げる。
- RFC : RFC 7469 - Public Key Pinning Extension for HTTP
- 参考 : Public Key Pinning - Web security | MDN
本書の 6.5 節 「セキュリティ関係の HTTP ヘッダ」 に書かれています。
ブラウザがレスポンス内容を UTF-7 と誤認することによる XSS の成立
XSS 対策として 「<」 という文字列をエスケープするなどの方法がありますが、ブラウザにレスポンス内容の文字エンコーディングを UTF-7 だと誤認させることで、「<」 のエスケープをしていても 「<script>」 という文字列をそのままブラウザに食わせることができる、という攻撃があるとのことです。
UTF-7 では、「<」 という文字は ASCII の 「+ADw-」 として表現されるためです。 「+Adw-script+AD4-」 という文字列を UTF-7 としてブラウザに解釈させれば 「<script>」 とみなされるので、「<」 という文字のエスケープをしていてもそれをすり抜けて XSS ができることがあるようです。 (古いブラウザの脆弱性。)
最近のブラウザだと問題ないようですが、念のため対策するのであれば 「+」 をエスケープすると良いようです。
- 参考 : 第1回 UTF-7によるクロスサイトスクリプティング攻撃[前編]:本当は怖い文字コードの話|gihyo.jp … 技術評論社
- 参考 : UTF-7でXSSを発生させる10の方法 - 葉っぱ日記
本書の 6.3.1 節 「XSS」 に書かれています。
ステータスコード 429 Too Many Request
レートリミットに達した場合に返すためのステータスコードとして 429 Too Many Request が定義されているとのこと。 初めて知りました。
ヘッダフィールドの値として使用できる時刻の形式は決められてる?
本書には以下のように書かれていて、X-Rate-Limit-Reset
のようなヘッダフィールドの値として Unix タイムスタンプを使うことは問題がある、といってるんですけど実際どうなんでしょうね。 (本書 195 ページ。)
HTTP ヘッダに Unix タイムスタンプを入れるのは、実は問題があるのです。 というのは、RFC 7231 の HTTP 1.1 仕様によればヘッダに入れてよい時間の形式は以下の 3 種類に限定されているからです
多分根拠は RFC 7231 の以下の箇所だと思うんですけど、これって別にあらゆるヘッダフィールドの値として使われる時刻の形式について言っているのではなくて、HTTP-date
について言ってるだけな気もします。 わかんないですけど。
A recipient that parses a timestamp value in an HTTP header field MUST accept all three HTTP-date formats. When a sender generates a header field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format.
RFC 7231 (section 7.1.1.1 Date/Time Formats)
読んだ: Java エンジニア養成読本
2014 年 12 月に発売された 『Java エンジニア養成読本 [現場で役立つ最新知識、満載!]』 を読みました。 これだけを読んで Java がわかるわけではないけど、歴史から Java EE、周辺技術に至るまで説明されていて、Java 初心者が全体を俯瞰するのに良さそうだと思いました!
内容紹介
本書は、複数の著者による共著になっています。
まず、巻頭記事がきしださんによる 「誰も教えてくれない Java の世界」。 Java の歴史や、Java のエディション (Java SE、EE、ME について)、JDK や JRE、JCP、JSR の紹介や各種 IDE や有名なフレームワークの紹介など、Java を使い始めてみたけど世界観がよくわからない、という人に役立つ情報が凝縮されています。 「お前に Sun が救えるか」 といったネタも紹介されています。
続く特集 1 が irof さんによる 「Java 入門」。 もちろん Java の構文の細かいところまでは説明されていませんが、クラス定義についてや例外処理、標準ライブラリについてのプラクティスなどが紹介されています。
特集 2 は bitter_fox さんによる 「Java SE 8 時代のデータ処理入門」。 Java SE 8 で導入されたラムダ式や Stream API について説明されます。 私もここら辺のことはまだ詳しくは知らなかったのでためになりました。
特集 3 はキクタローさんによる 「現場で役立つ Java EE」。 Java 初心者にとっては Java EE とは何者なのか良くわからない存在だと思いますが、この特集を読むことでなんとなく何者であるかはわかると思います。 Java EE と一口に言ってもその技術要素は多岐に渡りますが、この特集では Servlet や JSF、JAX-RS、JPA、CDI、EJB といったわりと良く使われる技術要素について主に説明されます。 私も JSF や EJB については詳しくなかったので、本書を読んで勉強になりました。
特集 4 は渡辺さんによる 「現場で役立つチーム開発入門」。 Git や Maven、JUnit によるテストや Jenkins といった、開発現場で良く使われている周辺技術が説明されます。
最後に 「イマドキの Java 受託開発の現場で求められる知識」 というタイトルで、提案や設計について、「web 開発の現場では Java の知識だけでなく、HTML や CSS、JS の知識なども必要である」 みたいな話や、テストやデプロイについて説明されます。
感想
Java 初心者が Java を使った web アプリケーション開発について学ぶのにちょうど良い書籍になっていると思います。 もちろん、前半は web アプリケーション開発とは関係なく Java について学べますし、Java を使うなら (web アプリケーション開発をするつもりがなくても) 読むと良いでしょう。
文体がいいのか構成がいいのかムックという本の形態が良いのかわかりませんが、技術書としては読みやすかったです。
既に Java について深い造詣があるならこの本を読む必要はないと思います *1 が、これから Java を使っていきたい人や最近 Java を学び始めた人は、この本を早い段階で呼んでおくと後々の学習が捗ると思います。 Java の良書はいろいろありますが、重量級なものも多いですので、まずは軽く本書から読んでみる、というのをオススメします。
あなたと Java エンジニア養成読本、今すぐ購入!
Kindle 版もあるようですよ!
Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)
- 作者: きしだなおき,のざきひろふみ,吉田真也,菊田洋一,渡辺修司,伊賀敏樹
- 出版社/メーカー: 技術評論社
- 発売日: 2014/11/11
- メディア: 大型本
- この商品を含むブログ (6件) を見る
- 作者: きしだなおき,のざきひろふみ,吉田真也,菊田洋一,渡辺修司,伊賀敏樹
- 出版社/メーカー: 技術評論社
- 発売日: 2014/12/11
- メディア: Kindle版
- この商品を含むブログを見る
関連エントリ
著者
読んだ: アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
開発手法としてスクラムを取り入れているチームに所属しているが、アジャイルやスクラムといった手法についてあまり知識を持っていないソフトウェアエンジニア、という立場で本書を読んだ。 本書のカバー袖には 『企業の経営層に向けてソフトウェア開発手法の 「アジャイル」 とその手法の一つである 「スクラム」 を体系的に解説する』 とあるのだが、経営層に限らず、アジャイル的な開発手法を採用して開発プロセスを改善していこうとする人であれば、誰にとっても有益だと思う。
アジャイル開発については、ウォーターフォールとの比較として 「小さなサイクルを回して変化に柔軟に対応しながら開発を進める」 という程度の理解しかなかったので、本書を読んで 「人が知識を運ぶ」 とか 「人と人のコミュニケーションで知識を伝える」、「顧客と協調して開発を進める」 といった、どちらかというと社会的な活動やその意義についての部分が非常に参考になった。
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 12回
- この商品を含むブログ (18件) を見る
本書は 3 部構成になっている。 第 1 部 「アジャイル開発とは何か、スクラムとは何か」 では、ソフトウェア開発手法であるアジャイル開発について、どういうものなのか、なぜそれが必要とされたのか、といったことが説明される。 そして、アジャイル開発の枠組として、スクラムについても詳しく説明される。
アジャイル開発については、「ウォーターフォールのように要件定義や設計、実装という各作業で開発プロセスを分断するのではなく、小さなサイクルを回して完成を目指す」 (すなわち、包括的なドキュメントより動くソフトウェアを重視し、計画に従うだけでなく変化に柔軟に対応していくことを重視する) というものだと思っていたのだけれど、それだけでなく、「個人と対話」 や 「顧客との協調」 といったことにも価値を置く価値観が根底にある、ということを知れたのが良かった。 この価値観は、「アジャイル宣言」 に述べられている。
また、朝会 (デイリースクラム) やプランニングポーカー、アジャイル開発の各種プラクティスについても説明される。 プラクティスとしてはアジャイルの右翼 (開発環境) に属するものと左翼 (チーム環境) に属するものがあり、それらをうまく組み合わせてアジャイル開発の目的である 「ビジネス価値」、「顧客満足」、「市場創造」 といったことを達成する。 ここら辺のプラクティスについては、軽く紹介されるだけという感じなので、実際に現場で実践するのであれば詳細は別の書籍などで学ぶと良いと思う。 次のようなスライドもある。
2 部では、実際にアジャイル開発を導入した国内の 3 社 (リクルート、楽天、富士通) の事例が紹介される。
3 部では、現在のアジャイル開発では明示的に言及されないような、企業経営とリーダーシップの側面から、アジャイル開発の考察がなされる。
個人的に気になった内容
アジャイルの各種プラクティス
プランニングポーカーは 1 回やったことがあるけど、ちゃんとしたやり方を知らなかったので 「なるほどー」 という感じで読んだ。 他のプラクティスについては大体知ってたけれど、いくつか新しい発見があった。
- プランニングポーカー
- 最初にベースラインを決める。 メンバー全員が知っているあまり大きくないタスクを選ぶ。 → こないだプランニングポーカーやったとき、最初のタスクは適当に数字を出してて 「こんなんでいいのかなー」 と思ったりしてた。
- 見解は一番大きい数字と小さい数字の人が言う。 → 数字が合わなかったら全員が言うものだと思ってたけど、確かにそれだと時間かかりすぎるし、最大と最小の人が言えば良さそう。
- 3 回で切り上げ。 → まあそんなものか。
- 朝会でプロジェクトの外部の人の発言するタイミングを制限する。 → 外部の人が、自分がリスクを取るわけでもないのに気軽に口出しする、というのを防ぐ意味。
- プロジェクト内の人をブタ、外部の人をニワトリと呼ぶことがある話。 ハムエッグを作るのにブタは自分を生命をかけるが、ニワトリは自身の生命に関わらない貢献の仕方をする。
- ブタとニワトリの話、会社の人もしてた。
- タスクかんばんのタスクは 2、3 時間程度で終わる粒度が良い。
- 今のプロジェクトでもタスク粒度には悩んでる。
- タスクが動くことで進捗状況の共有。 さらに達成感にもつながる。 1 日で動くようなタスク粒度にすべきとのこと。
- バーンダウンチャート
- 進捗状況の確認のための質問は 「完了までにあと何ポイント (理想時間) 必要か」 にする。 「何パーセント完了したか」 や 「残り何パーセントか」 ではない。
- 作業が進むにつれて、見積もりよりも実際に必要な作業が多いことがわかったりするので、残り作業時間を把握すべき。
- スプリントで完了できたポイント数をベロシティとして、スプリントあたりに進めることができるタスク量の目安とする。
- 工数をポイントで見積もった場合に、実時間とどう変換するのがいいんだろうなーと思っていたけれど、実時間と変換するよりはスプリントあたりに進めることができるポイント数を把握してれば良い、という感じか。
- スプリントの成果物はリリース判断可能なもの。
- ユーザーストーリーには詳細な仕様は書かない。
- ペアプログラミング
- 15 分おきにぐらいでペアを交代する。 開発のメリハリやリズム。 → 15 分がいいのかどうかわからないけど、まあそれぐらいかなーという気はする。
- リスクが大きい作業や、クリエイティブな作業はペアで行った方が効率的。 → 設計とかも、設計をきっちり書いてレビューしてもらって大きな直しが発生する、というような状況になるぐらいなら最初からペアでやった方が良さそう。
事例
各社、それぞれ課題があったり良い取り組むをしていたりして興味深い。 他社がやってるからといって表面的に真似ても意味はないけど、どういう考えで各取り組みをしたのかが書かれているので、そこら辺がだいぶ参考になる。
リクルート
- バーンダウンチャートに上限線を引く。
- 予めバッファを持たせて、上限線を引いておく。 実績線が上限線を超えそうになったら要件の調整を行う。
- 上限線を引いておくことで、要件の調整に対して事業部側の理解を得やすい。
- 出世魚型のドキュメント。
- ドキュメントは開発フェーズをまたいで使いまわし、更新していく。
- ドキュメント作成の工数削減と、ドキュメントが分散して齟齬が発生することを防ぐ。
- 言葉で聞いたら、さもありなん、という気はするけど、実際のところドキュメントどうするかって結構難しい問題ではある。
- 最初はワンチームマインドの醸成に苦戦した。
- 見積もりのずれに対する認識。 事業部側は見積もりは初期から変わらないという認識。
- 意識の変革と共有。 地道な啓蒙や説得。
- 会議からの持ち帰りの禁止。
- 「持ち帰って検討」 が開発スピードを遅らせる。
- 持ち帰って 100 % の精度で回答するのではなく、80 % の精度でいいのでその場で回答する。
- 残り 20 % に起因する手戻りが発生しても、お互いに怒らないように。
- 精度を求めすぎて時間がかかる、というのは避けるように自分も意識してはいるけど、それでも時間をかけて検討することは結構多いので、もうちょっとスピード重視に振ってもいいかもなーとか思ったり。
アジャイル開発とスクラム
アジャイル開発で重要そうなトピック。
- 多層学習と多能力学習。
- 個人、チーム、部、会社、という様々な層で学習が起こる。
- チーム内にエンジニアやデザイナ、営業、といった様々な専門スキルを持つ人間がいるので、自分の専門外のことも学習する。
- 暗黙知と形式知、両方の形式が重要。
- 実践知リーダー。
- PDCA (計画、実行、検査、適応) サイクルの前に共同化。
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 12回
- この商品を含むブログ (18件) を見る
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/06/20
- メディア: Kindle版
- この商品を含むブログを見る