先日3月21日に、スクー（ http://schoo.jp/ ）という、ウェブ上で様々な授業が受けられるサービスにて、ひとつ講義を受け持って授業をしてきました。
「どうすれば小さなチームでも大きな成果を出せるのか 〜 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ」というテーマで授業をしてきました。
オンラインで生放送の授業をするという初めての経験で緊張しましたが、質疑応答で沢山質問も頂けたので、とても良かったです。オンラインの方が、質疑応答で質問が出やすいような気がしますね。
この記事では、その授業での内容や、スライドと質疑応答について書きました。
目次
授業内容の紹介
大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。
ウェブサービスを実現するソフトウェアを開発するにあたって、最も大切なことは「保守性」です。
リリースして終わりではなく、リリースしてからは、新しい機能を追加していくことや、ユーザからの反応にあわせて機能を改修していくことなど、ソフトウェアをずっと直していくことになります。そのソフトウェアの「直しやすさ」が「保守性」と呼ばれます。
少ない人数のチームで、いかにコストをかけずに、効率的に、しかも保守性の高いソフトウェアを開発するにはどうすればいいか。
今回の授業では、私たちの会社ソニックガーデンで行っているソフトウェア開発の方法と、使っているツールについて紹介します。
その方法は、一般的にはアジャイルやリーンと呼ばれるようなやり方に近いかもしれません。それよりも、より本質的で、実際に現場で実践していることをもとに紹介したいと思います。
対象者は、チームでソフトウェア開発をしているエンジニアやディレクターになります。この授業を受けることで、ビジネス要件に応えるためのチームでのソフトウェア開発の肝を学ぶことができます。
授業で使った資料
質疑応答
オンラインでも回答した質問もあるのですが、ちょっとわかりにくかったかな、と思う所もあるので、補足を含めて回答を残しておきます。
【質問】ユーザーストーリーの具体的な事例若しくは要件を教えて下さい。
ユーザーストーリーは、ユーザにとって意味のあるものにします。内部的に改修するものはストーリーにはなりません。もう一つのポイントは、その一つ一つのユーザーストーリーが完成したかどうか判定できるようなものになっている必要があります。「○○できるようになること」というようなストーリーになります。
【質問】データ変更してもすぐ対応できるようにするためには、具体的にはどのような仕組みを設計やアーキテクチャ、もしくはプロセスに取り込むことが肝なのでしょうか？
ソースコードをDRYに保つ、ということを重視しています。DRYというのは、”Don’t Repeat Yourself”という言葉の頭文字で、ソースコード中に重複するコードを無いようにするという考えかたです。完璧にDRYなコードにさえなっていれば、何か変更があったとしても一カ所を変えるだけで済みます。
また、DRYなコードにするために、社内でコードレビューを実施します。コードレビューを通じて、DRYではないコードを駆逐していきます。
【質問】コードレビューを小口化・習慣化するポイントが知りたいです。
そのコードレビューの目的によります。社内でのコンセンサスをとったり、プログラミングのレベル感を高めるような教育の目的があるようなコードレビューは、時間をたっぷりとってディスカッションをすることが大事です。それは、定期的に開催を予定するしかありません。
リリースする前の品質チェックが目的であれば、コードレビューは時間をかける必要はないため、githubなどのオンラインでコードレビューできる機能を使うことで簡略化します。
【質問】請負契約で多重構造化されている日本のSI業界で、今回の話を適用するためには、どのように契約形態・業界構造を変化させていく必要があるのでしょうか？
はい、既存の一括請負という機能一覧で契約する方法では、難しいでしょう。たとえ出来たとしても気持ちでやっているだけなので、長続きしないでしょう。
受託開発で、今回のような目的から考え、無駄をなくしていく開発をするためには、新しい契約のビジネスモデルが必要になります。ソニックガーデンでは、「納品のない受託開発」という名前で、月額定額の受託開発のビジネスモデルをつくり、その中で実現しています。
【質問】自己組織化したい。でも自分からそれを言い出すのは・・・。そのためには「カルチャー」が大事だということだと思います。私のようないちプログラマでも、成果を出せる「カルチャー」を作っていく方法はありますか？
自分からカルチャーや自己組織化を言い出すのは確かに難しいでしょう。私は「カルチャー」というのは、何かお題目やルールみたいな目に見えるものがある訳ではなく、その集団にいるひとり一人の考えを集めたとしたら、カルチャーと呼べるのではないか、と考えています。つまり、カルチャーをどうこうしようと考えるのではなく、ひとりひとりの考えを変えていくしかありません。
しかし、人の考えを変えていくのは難しいことです。自らを省みないで変わろうとする人は少ないでしょう。そこで、私がお勧めするのは「ふりかえり」という手法です。週に１度でいいので、仕事の中身の話をするのではなく、仕事の進め方について話をします。そして、どうすれば翌週はもっと上手に仕事が出来るかを、メンバーと話し合うのです。
そうした「ふりかえり」を続けていくことで、徐々に参加者の意識が変わっていくという経験を何度もしました。ぜひ身近なまわりから「ふりかえり」を試してみて下さい。
【質問】無駄をなくすためには、リーダーが確固たる信念を持って、組織の動きにブレを作らないようにするべきだと思いますが、その信念すらも短いスパンで考えなおすべきなのでしょうか。
信念は必要だと思います。どんな信念なのかによりますが、自分のミッションに従う信念であれば、変える必要はないでしょう。軸のブレているリーダーには誰もついてきません。
ただし、変えるべき柔軟さは持ち合わせていなければいけません。リーダーのアイデアであったとしても、メンバーから「目的は？」と問われて答えられなければ、そのアイデアは却下すべきです。つまり、目的のために無駄をなくすためには、リーダー自身も、その目的に沿わないことはしてはいけないし、誰からのアイデアであっても受け入れるべきなのです。そこに必要なのは柔軟さです。
【質問】ユーザーストーリーはプロダクトオーナーが書くんでしょうか？プロダクトオーナーが書き方に困ったとき、どんなアドバイスをすればよいでしょうか？
ユーザーストーリーは、プロダクトオーナーが書くこともあれば、プログラマが書くこともあります。どちらが書いても構いません。なぜならば、ユーザーストーリーは、プロダクトオーナーとプログラマの、１週間単位での約束なので、お互いに理解している必要があり、お互いに納得がいっていれば、どちらが書いても良いのです。
プロダクトオーナーとプログラマは、一方的な関係ではない、ということです。プロダクトオーナーが仕様を考えるときも、プログラマに相談しながら考える方が無駄がありません。プログラマから見て実は簡単なことを大変だと思ってしまうかもしれないし、その逆もあります。そこで話し合いさえすれば、お互いに無駄のないユーザーストーリーが出来上がります。
【質問】週に一度のリリースというスパンの短さだと、ちょっとした滞りがスケジュールに影響を及ぼしそうですが、進捗管理等はどのように工夫されているのでしょうか？リカバリはどのように行っているのでしょうか？
「スコープ」と「納期」と「コスト」の３つのパラメータのうち、「コスト」を固定するのが小さなチームの戦い方だと話しました。そうなると「納期」が決まってしまえば、調整出来るのは「スコープ」だけです。なので、間に合わなければ、機能を減らしてリリースすれば良いのです。リカバリなんてする必要はありません。
一部でもリリースすることで、フィードバックが得られれば、それによって、その次にしようと考えていたユーザストーリーの内容が変わってくることもあります。そうなると、間違いなく機能一覧を揃えてリリースすることに、どこまで意味があるというのでしょうか。
【質問】ビジネスモデルについても、プロダクトオーナー、開発者両方が考えることがあるんでしょうか？
はい、考えることはあると思います。少なくともビジネスモデルについて理解をしていなければ、何を作ることでどう効果があるのかわかりません。なので、ビジネスモデルについては考えられるようになると良いでしょう。そういうエンジニアは、本当の意味での生産性の高さを発揮出来るはずです。
【質問】小さな開発で短い周期でまわして行くと、クライアントの担当者のタスク(打ち合わせやメール等)が増えませんか？
はい、増えます。それまでは、一度に沢山の要件を決めて、どかっと渡していたものが、小刻みにやっていくことで、大変になるでしょう。しかし、本当に良いものを作りたいと思うのであれば、そういう協力は必要不可欠だと考えます。
ただ、打ち合わせといったまとまった時間のかかることや、電話、チャットといった割り込みの入るようなものは使いません。そういう点でメールは、自分のタイミングで返信できるというメリットがあるので便利です。ソニックガーデンでは、メール相当のツールとして、非同期に返信ができるyouRoomを使っています。
【質問】倉貫さんが説明された方法でチームでプログラム開発をしたご経験の中で、非常に効果的に仕事ができた事例の共通点、その逆に非常に無駄の多い事例の共通点を教えて下さい。
効果的に仕事が出来た事例の共通点は、価値観の近い人たちで集まって仕事が出来たということ点です。じっくりと育てたチームでの仕事はうまくいきます。
逆に無駄の多い事例の共通点は、やたらと人がたくさん入れたプロジェクトや、急遽に人を追加するようなプロジェクトですね。人が多いと、仕事の為の仕事を考えて、無駄なことを始めます。
【質問】従来にないとても効率的なやり方ですが、新しいやり方なだけに、受け入れられない人もいそうです。納得した人だけが、プロジェクトに参加しているのでしょうか？
はい、そうあるのが理想的だと思います。そういう理想的な状態をつくるために、ソニックガーデンでは、採用に気をつけていて、カルチャーにあう人だけを採用しています。
【質問】長期間に渡って開発を続けていくと、途中で人が変わる事が多いと思います。そのようなとき、チームの成果はどのようにして維持（または回復）すればよいのでしょうか？
チームの半数ほどの人数が一度に入れ替わるのだとすると、もはや難しいでしょう。人が入れ替わってしまっても、もしチームにカルチャーがあれば、それを伝えていくことで維持できるかもしれません。カルチャーをもっていることが大事です。
もっとも前向きにできるリスク対策は、人が辞めたりしないような良い会社をつくる、ということだと思います。
【質問】開発に際してドキュメントの作成は行われているのでしょうか。
場合によるでしょうが、ソニックガーデンではドキュメントは作りません。ホワイトボードで書いたメモは記録として残しますが、それ以外は残りません。
プログラマで考えると、すべてのワークフローをひとりのプログラマが全て担当することで、引き継ぎに必要なドキュメントはいらなくなります。
プログラマとプロダクトオーナーの間での約束は、ドキュメントにするのではなく、PivotalTrackerのユーザーストーリーという形で残します。
そのため形式的なドキュメントの作成は行っていません。
【質問】SonicGardenのビジネスモデルは倉貫さんの思考成長が前提となっていて、他の会社で本当にコピーできるビジネスモデルなのか疑わしいのですが、倉貫さんを複製することは可能でしょうか？
複製はできないですし、複製する必要はないと思います。
皆さんは皆さんの文脈と状況の中で、どうすれば目的を達成できるのか、そこを追求していくことの方が重要です。世の中に誰一人として同じ人生を歩むことはないのですから。
