日記
転職に苦戦しています。
元COBOLERでも入れる、素敵なスクラム開発を採用している企業様はありませんでしょうか。
本題
先日、知人の方に誘われて、スクラムの無料講習に行ってまいりました。
Odd-e Training
「ザ・ウォーターフォール」みたいな職場なので流行りのアジャイル？スクラム？、短期間でリリースしてくやつ？みたいな感覚で受講しました。
講習内容は自体は、スクラムとは？から始まり、スクラム開発を行う上での要素や全体の流れを学びました。
受講後は以下のような感想を受けました。
ここでは、雑記となってしまいますが、印象に残ったこと・思ったことをメモがてら書いていこうと思います。
そもそもアジャイルってなんだっけ、ってことなんですが、これは
よりよい開発をしていく状態
を指すみたいです。
(肝心の部分なんですが、メモが汚くって少し間違っているかもしれない！)
ですので、アジャイルをやるみたいな表現は間違っていて、正確にはアジャイルを目指す、アジャイルになるみたいな表現が正しいみたいです。
知っている人には常識なのかもしれませんが、知らなかった私にとっては、衝撃でした。
一方、スクラムですが、これは
現状を認識するためのフレームワーク
を指します。
なので、スクラムやると生産性や品質があがるとか、プロジェクトの炎上が防げるとかいろいろと思うことあったのですが、結果的にそうなるかも、というだけであって、スクラムの目的はそこではないということです。
あくまでも、現状を認識するため、の手法です。
これには、驚かされましたが、一方でなるほどなぁと考えさせられたりもしました。
私たちが抱える課題
システム開発の難しさって、目に見えない部分っていうのが非常に大きいと思います。
顧客が、本当に欲しかったものは動かしてみないとわからない。
開発に必要な工数も、現時点のチームメンバーの力量にもよるし、実装方法にもよるし、よくわからない。
性能要求も実装が全て終わってからでないと、本当に達成できるのかわからない。
といろいろとあるのですが、ようはやってみなきゃわからないんですね。
なので、現状を認識する、つまりやってみることによって、自分たちが今開発した場合にどれくらい工数がかかるのか、顧客が必要そうなものをいつ・どれくらいに実装できるのか、そもそも顧客がほしいものこれなのか、ということを把握していくわけです。
で、スクラム開発ってどうやるの
すみません、これに至っては、こちらの講習の事前資料として掲載されている、下記pdfファイルを読んでいただいた方が正確です。
興味のある方はぜひご一読を。
https://www.pastoraldog.com/THESCRUMPRIMER_ja.pdf
課題
ここでは、スクラムを導入するにあたって感じた課題を書きます。
そもそもスクラムの理解が誤っていたらご指摘いただければと思います。
チーム作り
スクラムの重要なエッセンスに、「透明性・検証・適合」というものがあります。
透明性は、前述のとおり「現状を認識する」という意味での透明性になります。
一方、検証・適合というものは、スクラムのスプリント(1〜4週間)を通して、都度振り返りを行い改善していこうぜ、という考え方です。
なので、スクラムにおけるチームというものは、ただの開発チームではなくRPGでいうパーティーみたいなものじゃないかという印象を受けました。
チームとしても成長していきますし、メンバーそれぞれを成長を促していきます。
とはいえ、現状のシステム開発の大半は、いろんなパードナー会社から人を集め、プロジェクトが終わったら解散し、残ったメンバーもジョブローテーションという名のもと、どこかに行ってしまいます。
短期間でチームをつくっていくという技術そのものは必要ですが、長期的にチームを組んでいくというのは業界構造そのものをかえないと難しかったりするのかなぁと思いました。
プロダクトオーナーの存在
私の理解では、スクラムにおける「現状を認識する」対象には顧客も含まれると思っています。
実際に動く製品を触ってみて、顧客が欲しいものを顧客自身が認識していくからです。
前述のpdfファイルを見ますと、スクラムにおいては、プロダクトオーナー = 顧客となることも当然あるみたいです。
プロダクトオーナーは、要求事項を出して、スプリント内で実装すべき機能の優先順位をつけたり、スプリントで開発された製品に対して検査を行ったりします。
このやり方は、プロダクトオーナー(=顧客自身)がこういった形でチームと一丸になって、開発をしていくという姿は理想的なのですが、なかなか難しいのかなって思ってしまいます。
スクラムどうこうではなく、要求もあいまいなまま丸投げしてくる発注側や、顧客が忙しくてシステム側と話す時間を取れない、もしくはそれを考えるのが君たちの仕事だ！みたいな方もたくさんいるのかな、と思います。
これに関しては、ウォーターフォールだろうが、なんだろうが顧客自身も開発に参加してもらわないといいものはできないっていうのが当たり前になってかないと、なかなか変わらないのかなって思っちゃいました。
まとめ
スクラムをやれば、（当たり前だけれども）なんでも解決するっていうものじゃない。
でも、スクラムの現状を認識する、という点にはシステム開発に関わらず、全てに領域に当てはまることだなぁと思う。
（これもシステム開発っていえばそうだけれども）ウォーターフォールの要件定義書を書く、というフェーズ部分だけを切り出しても、期間を短く切って成果物を都度出して、顧客を巻き込んで確認していく、って当たり前のことなんだけれどもできてないことって多いですよね。
今回学んだことを実践できる場が私にはあるのか微妙なんですが、ぜひやってみたいなと思いました。
なので私に仕事をください！
