【schoo】「新人エンジニアが知っておきたいアジャイル開発」を受講した
倉貫さんの２回目の授業で2014年1月27日に公開されている。 受講したので授業の内容や所感をまとめてみた。
授業の概要
「ウェブサービスやアプリの開発に携わる新人エンジニアの方を対象」としているが、アジャイル開発に興味のあるソフトウェアエンジニアにとって非常にわかりやすく、その概要や事例を学べると思った。
また講師の倉貫さんが代表のSonicGardenさんは100%アジャイル開発を行っており、実例や質疑応答での実体験からの回答は非常に参考になった。
なぜ今アジャイル開発なのか
以下のようなポイントが挙げられていた。
- ソフトウェアをインターネット上で直接届けられるようになったことにより、「スピード重視」、「フィードバック」、「スモールスタート」、「スケールアウト」などの特徴を持ち始めたため。
- アジャイル開発の効果としては、「リスクを初期に下げる」、「可視性は常に高く保つ」、「変化コストを一定に保つ」がある。
アジャイルはウォーターフォールなどとの対比で”開発工程”の議論になりがちだけど、結局はアジャイル開発に合う”ビジネスモデル”が前提となる。”ビジネスモデル”に合った手段としてアジャイルが選定されるのであって、作るものが決まりきっているのにアジャイルで開発しても効果が薄いケースが多いのではと思う。 倉貫さんの「いらないものを見つけるために繰り返す」という話も非常に興味深かった。
アジャイル開発の事例に学ぶ
株式会社AsMamaさんの子育てシェアサービスの事例が紹介された。なにを作るのかではなく、なんのために作るのかをしっかり話す。これは、エンジニアのモチベーションだけでなく、別の提案ができないからとのこと。 ”事業の目的を共有する”ことを大切にしているとのことだった。 また具体的な開発、運用の説明もあった。
エンジニアに求められる姿勢
以下のようなポイントが挙げられた。
完成から持続へ
ソフトウェアについて、買った時点で最高品質の「Point of Sales」ではなく、サービス業の使う時点を最高品質にする”Point of Use”があある。”Point of Use”で大切なことは継続性と保守性であり、完成ではなく持続を目指すというのがアジャイル開発で求められる考え方。
当事者意識
”そもそも”から考える癖をつける。解決方法ではなく問題を話しましょうということ。 言われたことを作るだけでは、言われたものを作るだけのエンジニアになってしまう。
保守性を重視する
DRY(Don't Repeat Yourself)。コピペしない。
単位を小さくする
仕事をする単位をいろんな側面で小さくするのが大切。
なるべく作らない
YAGNI(You Aren't Gonna to Need It.)。先に予測して作らない。役に立たない可能性もある。 予測して作って、その予測が当たったら気分が良いが、外れる場合ものあるのでしないほうがよい。
守備範囲を広げる
なるべく分業しないで、自分でできることをたくさん増やしたほうが、効率的でスピード感も出る。 できるだけ兼務していく。
質疑応答
授業の後半では、受講者からの質問があった。気になったものを抜粋。
お客様から意見を引き出すために、工夫していることはありますか？
どういう機能がほしいというのを気軽に話せるようにする。エンジニアから作らない提案をしていくことにより、お客様が思いつきでもどんどん言ってもらえる。アジャイル開発はどういうところから始め、どうやって範囲を広げれば良いか？
”ふりかえり”をしてみて、自分たちのやり方がまずいところがないかコンセンサスを取るのが良いのではないか。いきなりアジャイルを提案しても難しい。
レポート課題
「授業の感想」と「ソフトウェア開発で学びたいテーマ」というレポート課題が出された。
授業を受けてみて思ったこと
「なぜ今アジャイル開発なのか」では、昔ながらの開発とアジャイルの効果が高いWebサービスとの違いがわかりやすく説明されていた。ソフトウェアのもつ特徴が違うため、効果的な開発工程も違ってくるというところがポイントだと感じた。また、単に開発工程ではなくビジネスモデルを含めての理解が必要だと思う。
「アジャイル開発の事例に学ぶ」では、具体例をもとに具体的な開発・運用プロセスを紹介され、アジャイル開発がイメージしやすかった。「エンジニアに求められる姿勢」では、ビジネスモデル、開発・運用プロセスに加えて必要な、エンジニアの心構えが紹介されていた。ここでも、昔ながらの開発との対比もあり違いがわかりやすかった。
【schoo】「どうすれば小さなチームでも大きな成果を出せるのか」を受講した
2013年3月21日に公開されている録画授業だけど、改めて受講したみた。 （schoo無料会員でも一定条件内で録画授業が見れるようです）
はじめに
「小さなチームが大企業に勝つには、機敏であること・同じルールで戦わない」そのためには、開発の無駄を無くすという話から始まった。 これは自分もよく思うところだけど、小さなチームあっても下請けなどで経験してきた大企業のやり方を踏襲するケースも多々あるのではと思う。 小さいチーム（企業）が、大企業と同じやり方で勝てるわけはない。
そもそもソフトウェアの価値とは何か
価値発生のタイミング
ソフトウェアを使って、売り上げを上げたり、コストカットできてから価値が生まれる。ソフトウェアがあるだけでは、価値はない。 ものを作れば、それ自体に価値があるという前提は、問題があると常々感じていたが改めて再認識した。 ここを間違えると、役に立つかどうか考えずに作ることがゴールになってしまいがちだ。
価値は相手によって変わる
「品質」は提供する相手によって品質が変わるという話。
「プログラムの正しさ ＜ 仕様の正しさ ＜ ビジネスの正しさ」という順になる。
ビジネスの正しさをあまり考えずに、仕様を考えると目的が達成できないものが出来上がる。
開発の無駄を無くすための３つのポイントについて
単位を小さくする
SonicGardenさんでは「小口化」と呼んでいるらしい。小口化することで、いろんなことが習慣になるとのこと。 具体的には、コードレビューを１週間単位から１日単位に、１日単位から１時間単位に...小さいサイクルであれば習慣化しやすい。 また、リリースも小さな単位で行うことで、迅速にリリースできるが、単位が大きいとリリースが遅れる。
優先順位を決める
やってはいけないことを素晴らしい効率で行うことほど無駄なことはない ドラッカー
これは本当に共感しかない。目的に向けてやらなければいけないものをリストアップしていくと全てが必要そうで、全てやりたくなるが、 リソースは限られているわけで、一気に全部はできない。 では、優先順位をどうつけていくかが授業で言及されている。 例えば、”そのビジネスで売りたいものはなにか”など、ビジネスを理解することが重要とのこと。 システムを顧客提案するときに、すぐに”便利そうだから”、”あれば良さそうだから”ということに目が行きがちだと思うが、 ビジネスを理解しなければ、何が重要なのか、必要なのかが判断できない。 それと授業でも触れられていたが、優先順位の低いものはそのうちやらなくても良くなることが多いと思う。
なるべく作らない
なるべく作らないことが、保守作業を軽減させる。 「作ること自体に価値はない」という話も出た。 SESだと作ることに対価が払われるため、これに慣れてしまうと作ることに価値を見出してしまいがち、 サービスやパッケージ開発でも同じ思考に陥いるとかなり良くないことが起きる。
また、開発してソースコードを増やしていくと、あたかも資産が増えるように錯覚してしまう。
機能やソースコードは資産ではない。負債である。
ここをしっかり理解し、作るべきことにコストをかけるという考え方だ。
そのためにこれから考えるべきことは
- 自己組織化
- ビジネスモデル
- カルチャー
「仕組み」と「気持ち」の両方を考える必要があるとのこと。
質疑応答
授業の後半では、受講者からの質問があった。
ユーザーストーリーの書き方
「操作をして一周回る」「インプットして最終的にフィードバックが返ってきて完結する」「完成しているかどうか判定しやすいもの」「ユーザーにとって意味がある単位」がポイントとのこと。コードレビューを小口化、習慣化するポイント
リリース前にチェックしているかが重要。SonicGardenさんでは、長いコードは週に一回やっている。成果を出せるカルチャーを作る方法
SonicGardenさんでは、”ふりかえり”によりカルチャーを作っている。
レポート課題
無駄のない開発をするための「そのためにこれから考えるべきこと」について、自分たちのチームで取り組むにはどうすればよいか。というレポート課題が出された。
- 自己組織化
- ビジネスモデル
- カルチャー
授業を受けてみて思ったこと
正直、３年前の授業とは思えず、今日初めて公開された授業だとしてなんも不思議ではない。つまり、非常に本質的な内容なんだと感じた。
この未来のこどもたちへ
娘の幼稚園の運動会、たくさんの子どもたちを見たときに思った。
もし、この中に「プログラマーになりたい！」と、思う子が出てきたとき、その子が大人になったときに、どんな社会が待っているんだろうか。いや、その業種の先輩として、どんな社会を作っておく事が出来るんだろうか。その子が地元で働ける状況になっているのだろうか。
そうなっておらず、首都圏に行くんだろうか。
大企業に就職しても、プログラミングでは無くマネージネント寄りの仕事や雑用的な仕事をすることになって いつの間にか「もの作り」ではない、他のことに追われる日々になっていないだろうか。
一生プログラマーとしてやっていけて、ちゃんと評価される。その中でイキイキと仕事をしている、そんな君たちを見てみたい。
そのためにはビジネスモデルであったり、働き方に変革が必要なことはわかる。
そして今、これから自分が何ができるだろうか。
人は変化していかなければならない。自らを再生させていかなければならない。
このブログ名『Reinvent Yourself』は、「The Daily Drucker」の1月25日のタイトルです。
そこに書かれている内容としては
・今日の社会と組織では、ますます多くの人が技能ではなく知識によって働く
・知識は変化し自らを急速に陳腐化させる
・新しい欲求、能力、世界観をもち、自らを再生させていかなければいけない
と、ざっくりこんな感じの内容で、内容的にすごく刺さったのでブログ名にしてみた。
単に知識をつけていくということでなく、「新しい欲求、能力、世界観」をもち「再生」する。
正直これを実現するのは簡単ではないな...と思った。
ただ、自分がこれからやろうとしていることにとても関係があるので、実践していきたい。
