『Adaptive Code』の感想その1

はいどーもこんにちは、ニートです。
本日は『Adaptive Code』の感想を書いていきたいと思います。
この本はしっかりと読んでいきたいので、何回かにわけて感想記事もあげていこうと思いますよ。

アジャイルとウォーターフォール

「アジャイル」とか「ウォーターフォール」という言葉はよく聞いていましたが、意味はよくわかっていませんでした。
本書によればこんな感じらしいです。

・ウォーターフォールプロセス:各フェーズ(要求・設計・実装・テスト……などなど)が完了したあとは変更がいっさい発生しないことを前提になっている。
・アジャイル:変更されることが前提と言うより、むしろ変更を歓迎する。

ユーザーストーリー

本書によれば「ユーザーストーリーは、スクラムでの作業の主なターゲット」です。
全然意味がわかりませんね。
例えばあなたは今、テキストエディタを作成しているとします。
とあるバージョンの新しいフィーチャーとして、テキストのUndo機能を実装することが決まったとします。
そのときユーザーストーリーは例えば以下のようになります。
「テキストエディタに間違った文字を打ったユーザーとして、間違った文字を元に戻したい。それは間違った文字を手動で削除せずとも、元の状態に復元できるようにするためだ」
つまりユーザーストーリーは開発者目線の「本当に実装したいこと」とユーザー目線の「その機能が実装されるとユーザーは何が嬉しいのか」を結びつけているわけですね。
この考え方はなるほどなあと思いましたよ。
僕も今度からユーザーストーリーを意識して機能を実装していきたいと思います。

不具合

あまり本題と関係のないことですが、ソフトウェアの見た目に関する不具合について書かれている項目がありました。
そこには「ソフトウェアの使用には影響を与えない」としつつも、「ユーザーがソフトウェアに期待するものに「見た目」も含まれることを覚えておくことが重要」と前置きしつつ以下のような書かれてありました。
「ユーザーインタフェイスがうまく設計されておらず、動かないボタンやロードされない画像が含まれていた場合、ユーザーはソフトウェアの内部の動作も信用しなくなります」
これはまさにその通りでしょう。
実際、僕がソフトウェアを使用する際も、まずどこに着目するかと言えば見た目です。
いくら機能がよくても、見た目が古臭いと「えー。このソフトウェア大丈夫かなあ」と思ってしまいます。
あとこの「見た目」には「操作性」も含まれているのではないかなーと思いました。
例えば多くのユーザーはCtlr+Zが「元に戻す」コマンドだと思っていると思いますが、この期待が裏切られたとき「操作性が悪いなあ」と感じるでしょう。
最悪の場合は「このプログラム大丈夫かー?」と思ってしまいます。

完成の定義

ここで言う完成とはユーザーストーリーのことです。
この「ユーザーストーリーが本当に完成しているのであれば、警告も条件も必要もないはず」と書かれてあります。
警告や条件とは「完成しているが、まだ○○してないない」や「完成しているが、ただし○○はまだ修正しなければならない」などといったことです。
つまり何かしらの注意書きが必要な「完成したユーザーストーリー」は「未完成のユーザーストーリー」であり、実のところ本当は完成していないのです。
こんなただし書きがつく原因の多くは「完成の定義」が曖昧だからです。言い換えれば、完成の定義がはっきりしていれば「まだこのユーザーストーリーは未完成です」と言い切ることができるはずです。
これには僕も思い当たることがあったので、今度から気をつけようと思いましたよ。

非現実的な目標

目標は大事ですよね。
目標がなければ五里霧中になり、どこを目指して進めばよいのかわからなくなります。
逆に目標があれば、俄然やる気が出てくるものです。
ですがあまりにも非現実的な目標は、人間のやる気を出させるどころか、むしろ士気を低下させるかもしれません。
そのことについて本書は以下のように説明しています。
「非現実的な目標を立てて失敗するよりも、達成可能な目標を立てて、期待どおりかそれ以上の成果を上げるほうが利口です」
まさにこれはその通りだと思います。
例えば僕が月収100万を一年以内に目指す、という無茶な目標を立てるよりは、とりあえず仕事を見つけて社会人を名乗れるようにする、という目標の方がやる気が出るというものです。

プロジェクトの停滞

「最初はいいペースで進んでたのに、なんか最近全然進まないんだよな~」みたいなことは、ゲーム開発者に限らず、何かを創作したことがある人なら恐らく一度くらいは経験があると思います。
これは多くの場合、マラソンに例えることができるでしょう。
つまり「後先を考えず最初に無茶なペースで走り、のちのち疲れがたまってペースが落ちてきた」といったよく聞く話です。
もっと一般的な言葉で言い表すなら「計画を立てずに物事を進めたため、のちのち負債を抱えることになった」ということでしょう。
この一般的な現象について、本書では以下のように触れられています。
「開発チームがフィーチャーを予定よりも早く完成させることができたのは、それら(注*ユニットテストや階層化などのベストプラクティスのこと)を無視したからです。しかし、整理されずに放置されたコードベースが増えるに従い、作業が大きく遅れ始め、やがてフィーチャーが1つも完成しなくなってしまったのです」
これは本当によくある話だなあと思いました。
僕も設計などをあまり考えずに「それいけ、エイヤー!」でコードを組むことが多いので、これはちょっと反省する必要があると思いましたよ。

Adaptiveなコード

プロジェクトの途中で何か変更が起きることは一般的です。
変更に対して適応力があれば――最小の労力で修正や拡張が可能であれば――そのプロジェクトは顧客(あるいは自分)の要望に素早く対応できるでしょう。
その方法論として、以下のようなものが紹介されていました。

・抽象化する
・抽象化しすぎない
・コンパイラが解析できるコードではなく、人間が理解できるコードを書く
・メソッド・クラス・モジュールを含めたすべての部分で、1つの責務に焦点を合わせる
・テスト容易性の確保(スカイフックをクレーンに置き換える)

各項目についてはこの後の章で触れられるのかなーと思います。

カンバン

カンバンとは要はGitHubのProjects機能のことかなーと思いました。
本文中ではカスタマイズ可能なカンバンボードツールとしてTrelloというものが紹介されていました。
あとでちょっと利用しみようかなと思います(記事も書くかも)。

さて本書では「カンバンを使うとプロセスの不備が浮き彫りになることがよくあります」と書かれています。
このことを説明するために、プログラム中で例外が発生したときに握りつぶすのか、それとも目に見えてはっきりとわかるようにするのかの例が挙げられています。
僕は断然「エラーはエラーとして即わかるようにプログラムを落とす」方が好きなのですが、本書でもこちらの方針が勧められています。
カンバンも同様で「あなたのプロジェクトは現在こんな問題がありますよー」ということを例外エラーのように報告(と言うか目に見えてわかるようにする)ものです。
ただ使いこなすのは難しそうだなあ……というのが正直な感想でしょうか。

参加していたプロジェクトでは

僕が参加していたプロジェクトはウォーターフォール型の開発プロセスを取っていました。
理由は恐らく、以下のようなものがあると思います。

1.ウォーターフォール型の方が直感的に理解しやすい
2.設計もコーディングも僕が一人でやる
3.プロジェクトの規模が小さい(一ヶ月で完成する見込みのものばかり)

補足しておくと、1は単なる僕の感想です。
2はそのままの意味で、僕より経験豊富な方が「こうした方がいいんじゃない?」とか「こうするのオススメだよ」みたいなアドバイスは投げていましたが、基本的には実作業(設計からUML作成からコーディングからUnityでの実装まで)は全部僕がやりました。
3についてもそのままです。プロジェクトの規模が小さく、変更される可能性もほぼなかったと思います。
今後チーム開発する機会があるのかどうか謎ですが、どういう開発フローを取るのかも注目していきたいですね。

終わりに

『Adaptive Code』はかなり楽しみにしていた本なので、詳細に読んでいきたいと思っています。
というわけで本日は第一部(一章と二章)の感想記事を書きました。
第二部はちょっと長めなのでわけて感想記事を書くかもしれませんが、ボチボチ書いていこうと思いますよ。

フォローする