プログラミングにおいて大切な 'スパイクを打つ'とは？

求められるライブ設計力！

私が勤めているソニックガーデンでは、ライブ設計力というものが求められます。 というのも、お客さんの要望を聞いている間に、ある程度自分の中でデータの構成を考えて、 ミーティング中に実装で必要な情報が揃っているのかを常に考えなければなりません。

ソニックガーデンでは、受託開発で 要件定義をしない ことを実践しています。毎週ミーティングをして、 その週に必要な開発だけを実装します 。そのため、

要望を聞く
↓
一度会社に戻ってタスクの見積もりを出す
↓
これでよいか顧客先に尋ねる

という流れを同じミーティング内でおこない、その場で設計ができていないといけません。

なぜ、この方法でうまくいくのか気になった人は弊社代表倉貫の著書に詳しく書かれていますのでご一読下さい。

「納品」をなくせばうまくいくソフトウェア業界の"常識"を変えるビジネスモデル

私は修行中の身で、技術的にも知らないことが多いです、そんな状態ではその場で構築していくライブ設計は難しいです。 ではどうやってライブ設計力を鍛えていくのかというと、そこで スパイク の登場です。

スパイクを打つとは

スパイクはアジャイル開発や XP（エクストリームプログラミング）の用語なんですが、 もともとはロッククライミングの時に打ち付ける Spike（命綱を止めておくために岩に埋め込む金属）が由来だそうです。 ロッククライミングではスパイクを打つことでリスクを減らし、プログラミングでは技術的判断の見積もりのリスクを減らしてくれます。

プログラミングにおいて スパイクを打つ とは、簡単に説明するなら

タスク全工程の分からない（曖昧な）部分を無くしてから実装に取り掛かる

ただ、それだけです。

スパイクを打つ流れ

スパイクを打つ際の流れを図にしてみました。それぞれを順に見ていきます。

(1)タスクのゴールを決める

最初にタスクのゴールを決めます。これは、以前の記事 認識合わせで注意したいこと(チケット管理のタスク編) で書いた、 チケット（タスク）作成者が何を実現しようとしているのかを理解する 必要があります。 このチケットで最終的に実現したいことができるようになるには？ を考えてゴールを決めます。

(2)タスクを分割

ゴールを決定したら次に、ゴールまでの実装を考えてみます。その中で　自分の触ったことのない技術だったり、実装方法が分からない 部分が存在するはずです、 その際は、 技術調査をおこない、簡単なサンプルプロジェクト等を作ったりして、実際に動くことを確認してみます。

この時に、 Qiita や StackOverflow にコードが載っていたからこれでいいやで終わらせると後で痛い目に会うかもしれません。 実際に動かしてみたり、自分の達成したい実装に変えた時にもちゃんと動くことを確認しないと調査は終わった という状況にしてはいけません。

調査を終えると、今まで 大きかったタスクも、何をすればいいのか明確になり、分割することが可能になる ので、 よりタスクを細かくして Unknown の部分がなくなるまでタスクをバラしていきます。 ロッククライミングで例えるならスパイクの打ち忘れは死をまねきます。 そんな、意気込みでタスクを分割するといいです。 目安としては、 ソニックガーデンでは実装するコードが思い描けている状態まで落としていきます。

この部分は、時間に追われていたりすると面倒な作業ですが、行き当たりばったりで実装していると、 途中で実装方法が無理だと気づいて大きな手戻りが発生する場合があるので、このような事態も防ぎたい です。

(3)コードのみの状態

この状態までなったら、コードの状態までタスクが分かれているので、実装するだけです。 しかも、他のメリットとして、細かくタスクが分かれている&疑問点が 1 つもない状態なので、 精度の高い全体の見積もりが可能です。 余談ですが、とあるソニックガーデンの岡山県に住むプログラマはコードまで頭の中でできているので、 実装中は喋りながらでもプログラミングができるらしいです。すごいですね。

スパイクをしっかり打っていくと

こういった、スパイクを毎回しっかり打っていくと、最初のうちは調査や実際に動くのか確認する作業に時間を取られていきますが、 徐々に大きなタスクのままでも実装できて、技術調査やタスクバラシの時間が減っていきます。 すると、最初の目的であったライブ設計力が身に付いていて、お客さんとの要望を聞いている最中に設計ができ、 足りない情報や必要のない部分に気づくこともできるようになってきます。