アジャイルサムライ読んだ感想とか

常識は10年経ってもそんなに変わらない

多くの凡人とは，怠惰であり，身勝手であり，そして不完全である．

だから予定は守らないし，期待を裏切るし，ふとした拍子に間違いを犯す．

人間とは不確かであるという常識は，10年前も今も変わっていない様子である．

おそらくは有史以来ずっと，人間は不確かな生き方をし続けてきたのであろう．

ときに不確かさは，人間にとって困った事象を引き起こす．

だから人間は何かしらのルールや規則，法，もしくは理念などで自己を律する必要がある．

それがどれだけ難しいことであっても，人である以上は避けられない問題だからだ．

さて，アジャイルサムライという本に記されていた「アジャイル」なるものもまた，人の不確かさに抗うための方法論である．

アジャイルとは，ソフトウェア開発におけるエンジニア――というよりは開発チーム全体の不確かさを律するための理念であり，原則である．

なぜそのような概念が登場したのかというと，ソフトウェア開発の現場においても，人間とは遅れ，誤り，反発しあうものだからである．

さて，僕もまたそういった類の凡人である．

予定を破り，期待を裏切り，間違いを犯したからこそ，ニートという醜態を晒している．

望む望まないに関わらず，凡人は不確かさに振り回される．

ならばアジャイルなる概念，理念，原則を学ぶということは，己の不確かさに抗う術を知ることにも繋がるのであろう．

僕は職業エンジニアではない．なればこそ，それを知るべきなのだ．

アジャイルってなんだよ

アジャイルでは，まず問題を細分化する．

そして解決するべき問題を選定する．

そして細分化され，選定された問題に対して個別に，実装とテスト，リリースを行い，フィードバックする．

これを解決するべき問題がなくなるまで繰り返す．

そうするとソフトウェアが完成する．

あまりにもざっくりとした理解だが，まぁおおよそこんな感じである．

凡人は不確かであるため，見積もりを誤るし，実装でバグを生むし，リリース時に問題を起こす．

それのリスクを0にすることは，不可能である．

しかしリスクというものにも大小が存在する．

計画の大幅な破綻や，運用中に起こり得る致命的なバグ，重要なデモで動かないリリース時の問題．

こうしたリスクは，極力避けなければならない．

ソフトウェア開発には，困ったトレードオフが存在する．

計画は早く立てれば立てるほど工数の管理がしやすいが，先行きが見えにくいため破綻しやすくなる．

ものが完成してくると先行きが見えやすくなるが，完成が近づいてから計画を立てるのでは遅すぎる．

計画は立てられなければならないし，進捗に併せて柔軟に変更されなければならない．

しかし顧客は「プロジェクトの計画は確実だ」と，なるべく早く説明されたいと思っている．

だから現場は不透明な計画を「完全な計画だ」と偽って説明しなければならなくなる．

しかしアジャイルでは，顧客に「完全な計画を立てるのは無理」と現実を伝える．

「見積もりはプロジェクトが進めば進むほど正確になる．今はざっくりとした計画しか立てられない」と．

その代わりに，細かくリリースを重ねることを顧客に約束する．

小さくても確かに動くものを定期的にリリースすることで，「なんだか完成が近づいてそう」という期待を抱かせる．

完成品を生み出すまでの過程で，とにかく顧客にもチームにもフィードバックを繰り返す．

アジャイルでは，とにかく物事を細かくし，大雑把に概要を掴み，実際に手を動かし，やった感想をフィードバックする．

細かくやってフィードバック，これを繰り返す．

アジャイルの実践とは，細分化と反復にほかならない．

問題を細分化する

凡人は，大きすぎる存在を正確に認識することができない．

遠くに見える富士の霊峰を絵として額縁に納めるように，夜空に浮かぶ月にうさぎが棲むと言い張るように，身近でないものの大きさを正確に認識することは，凡人にとって非常に困難な行いである．

ソフトウェア開発においても，身近でない物事を正確に認識することは，やはり凡人には難しい．

だからプロジェクト発足当初に立てた計画は，時間も，予算も，人員も，品質も，すべてが後になって破綻する．

だから，アジャイルでは最初に綿密で正確な計画を立てることを諦める．

その代わりに，身近なものを使って計画の輪郭を知ろうとする．

そのためには，細分化が必要になる．

何かを計画するとき，アジャイルでは解決するべき課題や達成するべき目標を，とにかく小さくする．

ひらすらに問題を小さくして，沢山並べる．

そうすると，比較的大きな問題と比較的小さな問題を，大雑把に分類分けすることができる．

小さな問題は，見るからに優しく，コストをかけずに解決できそうなものである．

逆に大きな問題は，見るからに困難であり，具体的にどういったコストがかかるか予想しにくいものである．

そこでアジャイルでは，見積もりの取りやすい小さな問題を使い，大きな問題がどれだけ大きいのかを相対的に測定する．

小さな問題10個分の大きさなら，そう定義する．

実際にはもっと大きいかもしれないし，実は小さいかもしれない．

しかし大切なのは，絶対値で大きさを表現せず，相対値でコストを測ることにある．

それがなんのメリットがあるのという話だが，良くある例えならいくつかある．

例えば，富士の大きさを表現するのは難しいが，東京ドーム何個分とかで表現すると東京の人にはそこそこわかりやすいというアレである．

それをソフトウェア開発の場でもやろう，という趣旨である．

問題を選定する

問題を細分化したら，次は解決すべき問題を選定する．

1つの問題を解決すると，ソフトウェアの機能が1つ完成する．

しかして，ソフトウェアの機能とはそのすべてが使われるわけではない．

誰も使わない，もしくはほとんど人が知りもしない，そんな無駄な機能というものは，どんなソフトウェアにも存在する．

そしてその逆に，そのソフトウェアを運用する上で誰もが使う，使わなければいけない機能も存在する．

その機能は需要が高く，その機能があるからこそそのソフトウェアが選ばれる．

そんな機能もまた，ソフトウェアには存在する．

そのためアジャイルでは，細分化した問題からどれを優先して解決するべきか，逆にどの問題は解決しなくても良いかという基準で，解決する問題を選定する．

プロダクトにおけるコアな問題については，優先して解決しなければならない．

ここでも，問題の選定はざっくりとした形で行う．

解決すべき問題，解決しない問題，余裕があれば解決する問題，この3分類に分ける．

そして解決すべき問題に対し，優先度を設定する．

どの順番で解決するかを決めれば，エンジニアたちは問題解決に取り組むことができる．

このようにして，アジャイルでは問題を選定する．

解決を反復する

問題を細分化し，選定したら，次は反復する．

細分化した問題に対し，解決方法を実装し，それが動くかテストし，それをリリースする．

そしてリリースしたら，解決に費やしたコストをフィードバックする．

これをすべての解決するべき問題に対して反復する．

エンジニアは，問題が細分化されているため，解決をすぐに実装できる．

テストも，問題の範囲が狭いため，簡単に行うことができる．

これを問題が解決するまで行う．

とある問題を解決するコードが完成したら，リリースする．

リリースは，実際に動かせるものであり，問題を解決できるものでなければならない．

機能単体をデモできる品質で，リリースする．

リリースしたら，解決に際してかかったコストをフィードバックする．

そして可能であればリリースを顧客に見せ，新たな問題発見や見積もりの変更をプロジェクトに適用する．

これを各問題に対して繰り返す．

やっている最中に，問題の大きさが変わってくる場合もあるし，問題を選定しなおす必要だって出てくる．

そうなったら，問題の見積もりをやり直し，再度選定する．

細かなリリースとフィードバックは，プロジェクトの先行きを透明にしてくれる．

解決にかかるコストが明らかになれば，他の問題に対しても幾分か正確に見積もりが取れるようになっていく．

実物として動くものを見れば，顧客の要求が具体化し，解決しなくていい問題が増えるかもしれないし，逆に解決が必要だった問題が浮き彫りにもなる．

すべての要求を含めた完璧な計画など存在しないが，プロジェクトを進める中で完璧な計画に近づけることができる．

そして今のリソースでどの程度まで問題を解決できるのかもまた，明らかにすることができる．

すべての要求を解決することはできないため，どこを妥協するのか，どこは譲れないのかを，顧客の期待と納得を踏まえて決定できる．

大雑把すぎない？

アジャイルの理想論としては，おおよそこんな感じである．

僕が適当にまとめた内容は，本が語る内容と比べて実際にはかなりの乖離がある．

なぜならば，アジャイルの根本的な発想は，コミュニケーションの改善にあるからだ．

人は不確かな生き物であり，プロジェクトに関わる凡人はすべて不確かな人間である．

顧客は思いつく要求をすべて解決させようとするくせに，重要な要求を忘れて(ときには知らないで)いたりする．

プログラマは実装しかしたがらないくせに，バグは作るし要求通りの解決を提供しない．

後になってテストをすると大量のバグが発生するし，リリース当日にはなぜか本番環境でシステムが動かない．

人間は不確かであるため，定期的に動くものリリースし，定期的にフィードバックをして，自らの軌道を修正し続ける必要がある．

そのためには，人とのコミュニケーションを通じて，チームのあり方を現実に適応させ続けなければならない．

顧客は実際のリリースを見なければ実感がわかないし，プログラマは顧客の要求を直接聞かなきゃ何が最善の実装なのか知りもしないし，テスターは何をテストするのかが明確じゃなきゃテストが書けないし，本番環境で試そうにもリリースがなければ試しようがない．

だから，アジャイルではコミュニケーションを改善する．

そのために細分化し，選定し，反復する．

具体的な手法とかテクニックとかは本に書いてある．

どう優先度を決めるのだとか，どうやってテストするのだとか，どうやって連絡を取り合うのだとか．

僕はそれを転記するほどの気力はないため，こんな感じに大雑把にまとめた具合である．

この本，お前の役に立つの？

僕はITエンジニアではないため，今すぐこの本で得た学びをすべて実践する機会はない．

だが，教訓として得られたものを実生活に取り入れることは，十分に可能であると思う．

「イケてないゲームサイトを作る」という今の目標も，とりあえずがむしゃらにやれることをやっていこうと考えて始めたものだ．

しかし勉強を始めると，他にも必要な物事が次から次へと出てくる．

年収2000万のエンジニア集団が作るような，超イケてるWEBサービスが作りたいわけではないが，そこを目指せと様々な情報たちが僕に語りかけてくる．

僕は僕の目標を達成するために必要な課題を細分化して選定する前に，このプロジェクトを走り始めてしまった．

今の僕は，自分の要求を細分化し，何をすべきか，何をすべきでないか，いつまでに成し遂げたいか，そういったことを明確にしないまま，闇雲に勉強をしている．

きっと，勉強をしているという自分に酔っている．

僕は勉強というものに没頭できているとは感じているが，一方で本当に目標を達成できるのかという焦りも感じていた．

何をするにも，先行きが見えないからだ．

先週の自分はWEBサービスを作る上で必要な技術調査をしただけで，実際に自分の目標が達成できる気になっていた．

しかし実際は，フィードバックがないから段々とモチベーションが下がり，目標を見失い，迷走し始めている自分がいる．

アジャイルサムライでは，チーム開発としてアジャイルという理念，原則が存在すると紹介している．

対話を通じ，ものを動かし，強調して，変化に対応することが，アジャイルの基礎であると．

僕はチームではない．

しかしチームでなくとも，僕が僕と対話し，僕がものを作って動かし，僕の要求に強調し，変化していく僕に僕が対応していけば，アジャイルな開発ができるはずだ．

そのためには，まず実践から入らなければならないだろう．

自分の要求を書き出し，細分化し，選定し，作り，反復する．

それを試すのは，そう難しいことではないと思う．

幸い，ざっくりとどうやるかについては本に大体書いてある．

とりあえず，インセプションデッキなるものを，まずは作ってみようと思う．

それで合わない，無理だと思ったら，そこで止めればいい．

顧客は僕で，出資者も僕で，作るのも僕だ．

一人でアジャイルしてたって，誰が迷惑を被るものか．

さて，この本の内容が真に僕に資するものなのかについては，実際にアジャイルをやってみないとわからないのである．

まぁ面白そうだなとは思うので，やってみようと思う．

そう，まずはやるんだ．

そうと決まれば，明日はアジャイル的なやり方でインセプションデッキを作ってみようと思う．

上手くいくかはわからないが，闇雲にやるよりは進展があるだろう．

なので明日は，そのインセプションデッキとやらについてブログに書くことになると思う．

「上手くいかなくてもそのことを正直に出資者と顧客に語れ」と本にも書いてあったので，とりあえずやってみる．

僕の出資者は両親とか友人とかで，顧客は僕なので，まぁ正直に無様を晒してやろうと思う．

僕は不確かな生き方しかできないが，それでも確かに生きていると，証明してやるのだ．