Feedback Loop

Webサービス開発で新しい機能を実装するときの自分なりの流れを書いてみる。

まず最初はパソコンは不要で、紙とペンだけで作りたいものと向き合う。ノートに機能名を見出しとして大きく書き、その下に小さく要件を書き連ねる。例えばどこをクリックしたら何が起きるとか、画面にどういう要素があるかとか。画面を伴う開発の場合はラフな絵を最初に描いて、そこにあるボタンや要素について順に仕様を考えていくことが多い。ユーザーの状況によって表示が違ったり、何かのボタンを押したら要素が展開されるようなつくりもよくある。そういういろんなパターンをここで書き出しておく。

全体のイメージが沸いたら、次は実装のステップを書き出す。1, 2, 3...と数字を打ち、順番に何をやっていくかを書く。ここで書くのはユーザーの操作の順番（つまり仕様）ではなく自分がどういう順序で実装していくかを書く。例えばここの機能をコメントアウトするとこの要素が消えることを確認するとか、フォームにひとつ入力項目を追加するとか、データベースのマイグレーションをするとかとか。思い当たるすべてのことを書き出しつつ、それを今回の実装で重要な順に並べる。大体の機能は5ステップ、多くても7ステップくらいに収まる。それより超えてくると激ムズ機能なので、もう少し細かい粒度で考え直す。

例えば不具合修正の場合のステップは、その不具合が発生することの確認、原因調査としてソースコードを読む、保存されるデータ形式を理解する、不具合が出てない他の似た箇所のソースコードを読んで違いを比較する。アタリがついたら修正してみて一番主のパターンで解決されたか確認する。それができていれば細かい条件を網羅しながらサブのパターンで修正されたかを順に見ていく。最後にその関数を他で使っているところに思わぬ影響が出ていないかチェック。別の画面だったり機能が正しく動くことを確認する。こんな感じでステップを定義する。

昔はここでパソコンを開いてステップに従って実装を進めていたが、最近はこの段階ではまだ開かない。「難所」を書き出すようにしている。難所とは今回の実装で難しいポイントや、自分にとって学習が必要なポイントを指す。例えばGoogleアカウントでログインできるようにするとか、難しめのUIに挑戦するとか、そういうのを書く。書いたらその難所について先に調べる。良い時代なのでネットで調べればその実現方法や、その機能を実装した人のメモなどが見つかる。いくつか良さげなのをピックアップしたら読みながらメモしていく。動くサンプルコードが提供されている場合も少なくない。その場合はコードをザッと見つつ、やはり要点をメモしていく。

難所を乗り越えるイメージができたところで実装に入る。もう要件やステップ分解は済んでいるので、あとは上から順番に作業していくだけである。ここは考える脳みそはほとんどオフにして作業者に徹する。言われたことを完璧にこなせばOKというマインドに切り替えて、確認したり実装したりして進めていく。ひとつステップが完了するごとにその項目に打ち消し線を引いて終わった感を出していく。この進んでいく感じが個人的にたまらない。進めてると新しく問題や気になるポイントが思い浮かんだりするので、それもステップに追記していく。書き出したすべての項目に線が引かれたら完了の合図。最後に全体的にバグってないか、使い心地は良いかを確認して、問題なければ機能をリリースする。

自分なりの流れを決められるとリズムよく開発できる。難しい機能も分解すればひとつずつは超えていけるし、自分ひとりで乗り越えるのが難しい場合は知人に聞けばよい。その時もステップが分解されていればピンポイントで分からないことを相談しやすい。自分のできるところから作って難所を後回しにすることもできるがオススメしない。難所は自分にとって未知の領域なので、もしかしたら実現不可能かもしれない。その場合は他の解決方法を考える必要がある。不確実なものから先に取り組んだ方がよい。