見積りのための「スパイク」 - ESM アジャイル事業部開発者ブログ

こんにちは。@junk0612です。今回は、普段の仕事の中でぶつかった疑問を解決した話をお送りします。

解決したかった問題

今関わっているプロジェクトでは、実際のエンドユーザーとは別にお客様の社内の方が使う画面で RailsAdmin を使っています。これまで RailsAdmin 上での画像のアップロードを取り扱ったことがありませんでしたが、新しく機能追加をするにあたって RailsAdmin から画像をアップロードできるようにするのが一番良さそうだという話になりました。

画像のアップロードに関しては CarrierWave を使っていて、RailsAdmin と CarrierWave の組み合わせを意外と誰も試したことがなかったため、見積りにあたって「できる方法があるのか、かかる手間はどれくらいか」を知りたいという要求が生まれ、その調査を僕が担当することになりました。

まずは調査結果

できます。それも簡単です。

たとえば作成画面なら、config/initializers/rails_admin.rb に

config.model(Model) do
  create do
    field :image, :carrierwave
  end
end

と書くだけです (真ん中の行に :carrierwave というタイプを指定するのがミソ)。これで画像のアップロードフォーム付きの作成画面ができあがります。

ずいぶん簡単ですが、これは RailsAdmin 内に RailsAdmin::Config::Fields::Types::Carrierwave というクラスが存在しているためです (参考)。つまり RailsAdmin は CarrierWave に対応済みだった、ということになります。

「スパイク」とは

上記のような、「機能開発とは別の、技術的検証や調査のためのタスク」を「スパイク」と呼びます。スパイクは、チームがきちんとした根拠を持って見積りや技術的な決定をするために必要なタスクです。

『アジャイルな見積りと計画づくり』p.170 には以下のように書かれています。

スパイクとはイテレーション計画に含めるタスクの一種で、何らかの知見を得たり、疑問を解消することを目的に取り組む作業のことだ。(中略) チームは修正の影響範囲を十分に見極めることができなかったので、タスクを2つに分けたのである。1つはスパイクで、もう1つは大雑把な見積りを入れたプレースホルダー的なタスクである。スパイクを実施すれば2つ目のタスクへの見通しが得られるので、このタスクをより正確に見積もれるようになるのだ。

見積り時にあるタスクの実現方法がわからない場合、その方法の調査にかかる時間も予測できないということはままあります (実際に、今回の問題は調べれば簡単にわかることでしたが、少なくとも見積りのときは誰も知らなかったことです)。そういうとき、何もかもがあやふやなまま決め打ちで見積るしかないこともありますが、スパイクしてみるというのは一つの強力な選択肢です。実際にきちんとしたものを作ってみなくても、少し時間をかけて調査すれば、様々な情報が得られます。得られた情報を元にすれば、見積りの確度はぐっと上がりますし、なにより決定に対して自信が持てます¹。

スパイクは実装方法の道のりをすべて明らかにするのが目的ではありません。そうできれば見積りの確度は最も高まるでしょうが、実際に実装するわけではないし、もしかしたらその見積り結果を元に実装しないという結論に至るかもしれないからです。時間がかかりすぎては元も子もないので、ある程度の時間を区切って調査し、ここまではわかったというところで再度見積る、というのが効果的な利用方法だと思います。

ちなみに、「調べても何もわからなかった」というのも一つの情報です。これは「簡単にはわからなかった == 実装でも調査から始めなければならず、時間がかかりそう」という推測ができるからです。↩