アジャイル開発研修・読後レポート(今後のアジャイル開発の方針・抱負)

アジャイル開発研修が始まって、ちょうど1ヶ月半。これまでに開発したシステムは、「社内経理システム」と「メール通知系アプリ」の2つです。その開発過程では、アジャイル開発に関わることから、APIやプラグインの使い方までさまざまなことを学んできましたが、同時にいくつかの課題も感じてきました。それらは、



・変化に適応するための姿勢や具体的な方法を身につけること

・ユーザーが求めているものを提供するための具体的なやり方を習得すること

・フィードバックする習慣を定着させること



です。そこで、今回の読後レポート(『アジャイルプラクティス』,Venkat Subramaniam and Andy Hunt著, 角谷信太郎・木下史彦監訳)では、これらの課題を踏まえた上での感じたことや学んだこと、そして今後のアジャイル開発の方針・抱負をまとめたいと思います。内容は以下の通りです。



1. アジャイルさを育む

1-1. 時が来たら習慣を捨てる

1-2. 変化についていく

2. ユーザーが求めるものを提供する

2-1. 短いイテレーションでインクリメンタルにリリースする

2-2. 開発者は、ビジネスの観点から顧客と接する

3. アジャイルなフィードバック

3-1. 作る前から使う

3-2. ありのままの進捗を計測する



1. アジャイルを育む


1-1. 時が来たら習慣を捨てる

(7 時が来たら習慣を捨てる p.36参照)
古い習慣を捨てるための最初の一歩は、自分のやり方が時代遅れだということに気づくことだ。


(7 時が来たら習慣を捨てる p.36参照)
といっても、習慣をひとつ残らず捨てろといっているわけじゃない。(中略)古い知識は状況に合わせて使おう。古い知識が適用できるときは、古い知識を再構成して再利用するんだ。

私は最近、ある習慣を捨てようと努力しています。その習慣とは、「何か考え事をする際、一人で長時間考え込んでしまう」というものです。私自身、考えを巡らすことが好きなので、長時間考え込んでしまうことがこれまでによくありました。しかし、ビジネスの世界ではスピードが重視されるので、長時間考え込むことはあまりよくありません。そこで、この習慣を変え、「ある程度考えても答えが見つからない場合は、他の人に相談してみる」という習慣をつけようとしています。ただ、「考えを巡らすことが好き」という長所は活かしていきたいと思うので、短時間で考えて結論までたどり着くための『考え方フレームワーク』といったものも同時に身につけていっています。



この体験の中で、私は以下の2点を意識しました。
・自分自身の習慣の問題点に気づくために、まずは、その習慣の結果発生している問題に気づく
・現在の習慣の良い部分だけを残し、再利用する

まだこの習慣の定着は出来ていませんが、今後も自分の習慣を見直す努力をし続けていきたいです。



1-2. 変化についていく

本書に掲載されていた、「変化についていく方法」の内、気になったものを挙げておきます。

(5 変化に付いていく p.30参照)
・イテレーティブかつインクリメンタルに学習する
・最新の話題を収集する
・地元のユーザーグループに参加する
・ワークショップやカンファレンスに参加する

まず1つ目の項目、「イテレーティブ(反復)かつインクリメンタル(積み重ね)に学習する」ですが、本書には『日々の変化についていくためには、毎日短時間でもよいので学習時間をとって学習するのがよい』とあります。仕事の合間や、電車に乗っている時などの、隙間の時間を有効活用していきたいです。
2つ目の項目、「最新の話題を収集する」ですが、私の今の主な情報収集源は、本ブログのリンク集に載せてある各サイトです。これら以外にも、幅広い情報収集を効率的に行なっていきたいです。
3つ目、4つ目の項目ですが、近々、RubyRailsの勉強会に参加しようと考えています。業界の情報や専門知識の習得、さらにはさまざまな方との交流も深めてきたいと思っています。



2. ユーザーが求めるものを提供する

2-1. 短いイテレーションでインクリメンタルにリリースする

(17 短いイテレーションでインクリメンタルにリリースする p.73参照)
アプリケーションを早めにユーザの元に届けると、うれしいことがある。(中略)ユーザが本当に必要としているものが何で、次に何を作ればよいかを、ユーザからのフィードバックによって学べる。それから、以前は重要だと思っていた機能が、今となっては実はそうでもないことに気づけることもあるだろう。

この1ヶ月半の研修では、社内経理システムを今月前半にリリースしたばかりで、まだユーザからのフィードバックは得られていません。しかし、このインクリメント内での複数回のイテレーションではプロダクトオーナーから多くのフィードバックを得ることができました。その結果、システム要件やデザインなどの細かな修正が可能となり、スピーディーにプロダクトオーナーが求めるものに近づけることができました。
今後は、ユーザからのフィードバックも受けて、よりよりシステムにバージョンアップさせていきたいです。

2-2. 開発者は、ビジネスの観点から顧客と接する

(10 顧客に決断してもらう p.48参照)
(開発者が)顧客と話すにあたっては、考えられる選択肢を準備しておくこと。長所と短所を提示し、想定されるコストやメリットを伝えよう。ビジネスの観点からだ。技術的な観点からではない。それぞれの選択肢のトレードオフと、スケジュールや予算に与える影響について話し合おう。

これは、まさに私自身の理想とする開発者の姿です。今は技術的な勉強をするので必死ですが、ビジネスの観点から捉えることも意識して開発に取り組んでいきたいと思います。



3. アジャイルなフィードバック

3-1. 作る前から使う

(20 作る前から使う p.86参照)
僕ら(システム開発者)の場合は、自分の作ったインターフェイスをみんなに使わせる前に、自分で実際に使ってみる必要があるんだ。むしろ、インターフェイスを設計するには、実装に取り掛かる前から使ってみなければならない。

上記のことは、テスト駆動開発(TDD)を行うことで達成されます。テスト駆動開発を行う意義に関してとても参考になる箇所があったので、以下に引用しておきます。

(20 作る前から使う p.86参照)
テストを先に書くことで、実装者としての視点ではなく、利用者としての視点でコードに接するようになる。(中略)設計したインターフェイスは自分自身で使わなければならないわけだから、それが使いやすくて一貫性のあるものになっているかどうかも自分自身で確認することになる。
それに加えて、コードよりも先にテストを書く事で、設計から余計な複雑さを排除して、処理の本質に集中できるようになる。

これまで、テストコードに関する認識は「動くコードを保証するもの」であるという認識が強かったのですが、本書から別の視点を得ることができました。「テストを先に書くこと」に積極的にチャレンジしていってみようと思います。



3-2. ありのままの進捗を計測する

(23 ありのままの進捗を計測する p.97参照)
時間というものは、いつもあっという間に過ぎ去るものだが、素晴らしいフィードバックも与えてくれる。スケジュールどおりに進んでいるかを判断したければ、実際にかかった時間と、事前に見積もった時間とを突き合わせるのが一番だ。

スケジュール通りに進められるようになる、つまり見積もりの精度を高めることは、今私が抱えている課題の1つ、「ユーザーが求めるものを提供する」にもつながる大きな課題です。
現時点での見積もりの精度ですが、一度実装したことのあるタスクに関しては精度を高められてきていますが、初めて取り組むようなタスクに関しては見積もりとは大きく異なる工数がかかってしまっています。このあたりをどうすれば高められるのか、今後も考えていきたいと思います。