Reinvent Yourself

技術メモや日々思っていることなど

【schoo】「どうすれば小さなチームでも大きな成果を出せるのか」を受講した

2013年3月21日に公開されている録画授業だけど、改めて受講したみた。 (schoo無料会員でも一定条件内で録画授業が見れるようです)

はじめに

「小さなチームが大企業に勝つには、機敏であること・同じルールで戦わない」そのためには、開発の無駄を無くすという話から始まった。 これは自分もよく思うところだけど、小さなチームあっても下請けなどで経験してきた大企業のやり方を踏襲するケースも多々あるのではと思う。 小さいチーム(企業)が、大企業と同じやり方で勝てるわけはない。

そもそもソフトウェアの価値とは何か

価値発生のタイミング

ソフトウェアを使って、売り上げを上げたり、コストカットできてから価値が生まれる。ソフトウェアがあるだけでは、価値はない。 ものを作れば、それ自体に価値があるという前提は、問題があると常々感じていたが改めて再認識した。 ここを間違えると、役に立つかどうか考えずに作ることがゴールになってしまいがちだ。

価値は相手によって変わる

「品質」は提供する相手によって品質が変わるという話。
「プログラムの正しさ < 仕様の正しさ < ビジネスの正しさ」という順になる。 ビジネスの正しさをあまり考えずに、仕様を考えると目的が達成できないものが出来上がる。

開発の無駄を無くすための3つのポイントについて

単位を小さくする

SonicGardenさんでは「小口化」と呼んでいるらしい。小口化することで、いろんなことが習慣になるとのこと。 具体的には、コードレビューを1週間単位から1日単位に、1日単位から1時間単位に...小さいサイクルであれば習慣化しやすい。 また、リリースも小さな単位で行うことで、迅速にリリースできるが、単位が大きいとリリースが遅れる。

優先順位を決める

やってはいけないことを素晴らしい効率で行うことほど無駄なことはない ドラッカー

これは本当に共感しかない。目的に向けてやらなければいけないものをリストアップしていくと全てが必要そうで、全てやりたくなるが、 リソースは限られているわけで、一気に全部はできない。 では、優先順位をどうつけていくかが授業で言及されている。 例えば、”そのビジネスで売りたいものはなにか”など、ビジネスを理解することが重要とのこと。 システムを顧客提案するときに、すぐに”便利そうだから”、”あれば良さそうだから”ということに目が行きがちだと思うが、 ビジネスを理解しなければ、何が重要なのか、必要なのかが判断できない。 それと授業でも触れられていたが、優先順位の低いものはそのうちやらなくても良くなることが多いと思う。

なるべく作らない

なるべく作らないことが、保守作業を軽減させる。 「作ること自体に価値はない」という話も出た。 SESだと作ることに対価が払われるため、これに慣れてしまうと作ることに価値を見出してしまいがち、 サービスやパッケージ開発でも同じ思考に陥いるとかなり良くないことが起きる。

また、開発してソースコードを増やしていくと、あたかも資産が増えるように錯覚してしまう。

機能やソースコードは資産ではない。負債である。

ここをしっかり理解し、作るべきことにコストをかけるという考え方だ。

そのためにこれから考えるべきことは

  • 自己組織化
  • ビジネスモデル
  • カルチャー

「仕組み」と「気持ち」の両方を考える必要があるとのこと。

質疑応答

授業の後半では、受講者からの質問があった。

  • ユーザーストーリーの書き方
    「操作をして一周回る」「インプットして最終的にフィードバックが返ってきて完結する」「完成しているかどうか判定しやすいもの」「ユーザーにとって意味がある単位」がポイントとのこと。

  • コードレビューを小口化、習慣化するポイント
    リリース前にチェックしているかが重要。SonicGardenさんでは、長いコードは週に一回やっている。

  • 成果を出せるカルチャーを作る方法
    SonicGardenさんでは、”ふりかえり”によりカルチャーを作っている。

レポート課題

無駄のない開発をするための「そのためにこれから考えるべきこと」について、自分たちのチームで取り組むにはどうすればよいか。というレポート課題が出された。

  • 自己組織化
  • ビジネスモデル
  • カルチャー

授業を受けてみて思ったこと

正直、3年前の授業とは思えず、今日初めて公開された授業だとしてなんも不思議ではない。つまり、非常に本質的な内容なんだと感じた。