システム開発で思うところ

Java EEを主にシステム開発をしながら思うところをツラツラを綴る

スクラム冬の陣2017 みんなで学ぶスクラム に行ってきました

postudy.doorkeeper.jp

これまでJava界隈のセミナー(主にJJUG関係)に行っていましたが、今回は開発手法に関する勉強会に行ってきました。

一人開発の私にアジャイルとかスクラムとか関係は無いのかもしれませんが、以前、開発プロセスの仕事をしていたこともあり、こういう情報は聞くだけでも十分面白いですね。

改めて感想の分量とお話の面白さは比例しないことを先に断った上でツラツラと書いていきたいと思います。

20分でスクラム入門 ステップ・バイ・ステップ

スクラムのイロハのお話。資料をパブリックドメインと明言していただけると社内で勉強会をしようと思う人たちにとって使いやすいので良いですね。

Scrumを使うと本当に成長できるの?

外的動機付けがクリエイティブな仕事の生産性を下げるというのは興味深かったです。クリエイティブな仕事については、芸術家に1億出すから感動する作品を作れって言っても「金額の問題じゃない、才能とインスピレーションの問題だ!」という話だと思っていたので。必ずしもそうではないんですね。まぁ、芸術家の制作物に対して「生産性」というのも変な話かもしれませんが。。
研究者にとって一番の報酬は、生活に苦労することなく一番好きな研究を死ぬまで続けられることだ、という話をどこかで聞いた記憶がありますが、つまりはそういうことなんでしょうね。それは理解できる気がします。

多様な働き方をするチームでスクラムを実践してみた

開発業務以外でのスクラム適用のお話。
業務改善手法として活用した、ということで良いのかな?以前、WEB-DBPressで知った業務フロー改善ツールのマジカの記事を思い出しつつ、話を聞きました*1
間接部門といわれる人たちの生産性や成果については定量化が難しいと言われますが、こうやって見えるようにするだけでも随分と変わるだろうなぁ、と思います。
スクラムの導入ハードルを考えたら、営利活動に直接影響のない間接部門から適用をして、会社として有効性を立証してから開発部門に展開をする、というのも良いアプローチなのかもしれないと思いました。開発部門展開前に自社にスクラムマスターになる人がいるというのもメリットの1つなように思いますね。

お悩み解決!持ってて損しない道具箱

モデリングのお話。
事前に資料を見てしまっていたこともあり、ちょっと休憩モードになってしまった。。 モデリングトレーニングは、能力ではなく技術なので、やればやるほどスキルアップするというのは実感があるので納得するところ。言いたい事は理解できるので駄目というわけではないですが、鉛筆のモデリングは製造系システムの人だったらピンとくるかもしれないけど、ちょっと私にはモデリングのためのモデリング、みたいな気がしてしっくりこなかったかな。個人的には、こちらの書籍にあるような結果に対して、その背景となる構造をモデリングする、というのが、しっくりくるかな。

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

導入に困っているあなたに贈る スクラム導入コミュニケーション術

【Scrumを使うと本当に成長できるの?】と同じく、スクラム導入にむけた障害解消ノウハウのお話(もっと良い表現が思いつかない。。)
どちらも「こんなにスクラムは良いのだから採用しましょう!」というアプローチではないことが良いと思った。ちょっとずれた表現になるとは思うけど「良い商品が売れるのではなくて、売れる商品が良い商品」という感じ(いや違うなぁ)。何かを推進したい場合は、自分の正しさのみを正義にしてもダメだよ(これもちょっと違うなぁ)。
いずれにしても、この知見は、実際にスクラムを運用する際にも活用できるメンタリティだと思います。

組織”規模毎”のアジャイル開発アプローチ事例~成功・失敗・ピボット・トライ~

スクラムマネージャーの話。 手の届く範囲のスクラムマネージャーから、全社統轄のスクラムマネージャーになった際に同じ手法のままでは駄目だったという話。全社で約50%の適用(アーリーマジョリティ)な状態になってからのサポート指針の見直しについては、数値的考察であったことも含めて、とても興味深かったです。事例としては、部門別に見てスクラムの占拠率が低いところに重点的にサポートをして定着を図るという話でした。キャズム理論の話も少しされていましたが、スクラムの適用そのものを戦略とした場合、ランチェスター戦略的アプローチも検討してみてはどうかな?と、知ったかで思ったりもしました。いずれにしても導入がゴールではなく、花と同じようにきちんと水や肥料を与えないと枯れてしまうというのは世の常だな、と思いました。企業規模も鑑みると、たぶん、スクラムマネージャーマネージメントが必要な気がします。

産業機器B2Bビジネスへのスクラム手法の有効活用

機器製造でのスクラムというのは初めて聞いたので面白かったというか意外でした。恣意的なマネージメント力とか開発部門による営業力強化みたいな抽象的な指針ではなく「スクラム」というツールの介在が、物を作る情熱と専門性へのプライドのバランスを取ったのかな?と思いました。制約があるから発想が生まれるという話を聞いたことがありますが、スクラムというツールが程よい制約・ルールになったのかもしれませんね。

エンタープライズアジャイルの可能性と実現への提言

約2年間の知見の集約と提言のお話。
ちょっと文章で表現するのは難しいので、上述のリンクから資料をみていただくのが一番よろしいかと。。 という前提を置いたうえで、スライドでポイントしておきたいところのメモです。
「うちでもアジャイル開発やってみましたアンチパターン」と、アジャイルの適用ターゲットになる「ポストERPとしての次世代手組み」の【手組み2.0の領域】の要素群のところ。
あと、経営層向けには「ROIを考えるための要素」のところ。定量的にアジャイル開発でリリースした方が収益化を考えても良いよ、という論理的な説明になっています。
アジャイル開発導入の課題」も体制など具体的な数値の話があるので目を通しておきたいところです。

客先常駐案件でスクラムを導入したスクラムマスターの話

運用保守フェーズにスクラムを適用したお話。
大規模な段階的イテレーションで無ければ、確かに運用保守フェーズにスクラムは適用しやすいように思います*2。むしろ、開発の基本基盤や実現性の担保がある程度とれている運用保守フェーズこそ、お試しアジャイル導入には有効な気がします。

ベトナムでのアジャイルオフショア開発への挑戦

現地駐在でのオフショア開発でのアジャイル適用のお話。

  • どんな人も達成感を味わうことは喜びである
  • 理解が出来ても実践できないことはある、ということを謙虚に受け止めよう
  • スクラムの効果はメンバーとの物理的な距離の近さに比例する

なんたって”DevQA” アジャイル開発とQAの合体が改善を生む

開発プロセスにかかわっていた時に、BDD駆動開発に興味を持ちました。そのプロジェクトに参画した工程がシステムテストだったということもあり、TDDというよりもBDDの方がしっくりとくる感じでした。その時「基本設計工程が終わったら、そこからテスト計画を並行して行い、開発と並行もしくは先んじてあるべき状態を検証すれば品質は良くなるのではないだろうか?」と考えていました。その解として私にはBDDがしっくり来たわけです。
ですが、私ごときが思うくらいですから、多くの知見において、それはすでに実践されていると思いましたし、そうだとして何故上手くいっていないのだろうか?とも思っていました。また設計要件が満たされることを保証すること=機能が充足している・品質が良い、というのにも疑問がありました。なぜなら、ITやST工程になって発生する「仕様漏れ」「検討漏れ」といった上流工程*3起因のバグは取り残されてしまうからです。むしろ、そういうバグは質が悪く致命的なものになるケースになりやすいです。つまり本来解消しておきたい致命的な仕様漏れは上流工程関係者だけでは解消できないという開発プロセスとして構造的な問題があると感じていました。
アジャイルがその解なのかなぁ、と思うところもありましたが、顧客の事業計画上、そういう形式での予算構成では無く、理想と現実の差を感じつつ、ウォーターフォールの範疇で出来うることを考える日々でした。
おそらく、その解に近いアプローチが、この"DevQA"なように思います。アジャイルの方がより参加者にとって適用しやすいというところはあるかもしれませんが、このアプローチは開発手法の大小に関係ないように思います。他の方のお話も十分に面白いものでしたが、このお話を聞けただけでも参加させていただいた価値があるくらい面白かったです。

全体を通じて

皆さんの話に共通して感じたのは、スクラムアジャイルが素晴らしいということではなく、チーム全員が参加して作り出す仕事は面白い、ということでしょうか。スクラムは、その手法としてプロセスそのものに、その考慮を生き渡らせているので有効ですよ、というところでしょうか。 PMOが流行ったときに、現場側で感じた「高みの見物の寸評者」感よりも、スクラムの方が運用プロセスにマネージャーの参加を促す仕組みが組み込まれている感じを受けました*4

さいごに

初めて参加したアジャイル勉強会でしたが、色々と得るものが多かったように思います。一人開発で何を生かすのか?というのはありますが、明日への活力的なものを共有できたというだけでも十分な効用だと思います。

*1:マジカはフローそのものの話なので、プロセスであるアジャイルとはレイヤーが違いますけどね

*2:大規模な段階的イテレーションをしている時点を運用保守フェースといって良いのか?というのは置いておいて

*3:この言い方はあまり好きではないですが

*4:誤解無く言うと正しいPMOも血の通った価値あるものです。ただ何故か知識優先というか、あたまでっかちというか、そういう印象が強かったというだけです