Yuigo・ん・・・湿っぽい

モルック、システムエンジニア、その他趣味。大学生のころから使っているので、昔の記事は恥ずかしいし今の思想とは異なっていることが多いです。

アジャイル初見(某所研修メモ)

サムネ

photo by pexels

アジャイルとはなんたるか、という研修を某所で受けてきたので、ざっくりとメモ書きを残しておく。

目次

前提

本記事の内容について

以下では断定形で書いてある箇所が複数あるが、講義の内容と配布資料をもとにしているため、真意については各自で確認する必要がある。

私の開発経験値

未経験からスタートして2年目、アジャイル開発はおろかウォーターフォール(と厳密に言えるのかは不明)開発の現場に半年くらいいた程度。現在は言ってしまうとがっつり開発現場というところには居ないので、開発プロセスに対する知見は無いに等しいのではないか。

強いていえば最近『カイゼン・ジャーニー』を読んだので、なんとなくの雰囲気はあんな感じかなあ、という印象はある、そんな程度。

アジャイルとは言っても

今回の研修では特にスクラムについての解説が主だった。とはいっても、講師の「スクラム自体の中身はそんなに語れる内容がない」という持論から、スクラムとはということに費やされた時間は全体の半分もなく、アジャイルウォーターフォールの違い、アジャイルを実際に適用するためにはどうするか、ということに関して多くの時間が使われていた。

参考

アジャイル型開発におけるプラクティス活用リファレンスガイド

IPAが発行している資料。(リンク

講座内容

アジャイルがどうとかスクラムがどうとかいう内容に関してはここで書く必要もあまりないかな(むしろここで書くとなると間違いないように丁寧に書かなければならない)と思うので、講座の中でこれはと思ったものを中心に書くことにする。

アジャイルの12原則

参考・解説リンク

アジャイル宣言の背後にある原則 - アジャイルソフトウェア開発宣言

アジャイルソフトウェアの12の原則 - ライトパスのブログ

12原則のうち一部について。

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

一般的には4週間単位で分割する。このとき、イテレーション感覚は反復型開発とはことなり必ず一定にしなければならない。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

クライアントも同じ場にいることが理想的。いちいちドキュメントを作ってお伺い、丁寧なメールをしたためる、という時間ロスを防ぐことができるし、共に課題を解決する、という方向性を意識付けることもできる。同じ現場にいることが難しい場合は、チケット管理ツールやチャットツールを駆使する。

動くソフトウェアこそが進捗の最も重要な尺度です。

書くべきドキュメントと書かないドキュメントを決めることによってプロダクトそのものに集中する。システム全体に関わるER図などは書くべきだが、各機能ごとのドキュメントはプロダクトとの乖離のおそれなどもあることから、書く必要がないとしている。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

ウォーターフォールでは期限を絶対に守らなければならないという制約から、品質に対しての妥協や諦めをしなければならないケースがあるが、アジャイルでは妥協せず開発を継続することが可能になる。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

クライアントや開発チームを管理する経営層からの要求をそのまま受け入れるのではなく、あくまで課題を解決することを第一とするため、開発チームの一人ひとりが広い視点を持つ必要がある。同時に、プロダクトの関係者は「開発チームが言われるがままの存在ではない」ということを理解していなければならない。

なぜウォーターフォールからアジャイルに移行しないのか

IPAソフトウェア開発データ白書2016-2017によると、国内のシステム開発のうち依然として約97%がウォーターフォール開発である。これだけアジャイルという言葉が出回っているのに?アンケートのとり方にも影響されているかもしれないが、圧倒的な数字であることは確か。

ではなぜアジャイルが使われていないのか、ということになるが、大元の原因としては契約形態が変わらないことにある、というのが講師の主張だった。現状の契約形態では、完成したらそれで終わり(本当は終わらないけど)、「〇〇アプリを作る」という目標は達成されても、「〇〇という課題を解決する」というそもそもの目的が達成されているかに関しては不明なままになってしまう。

このような状態を解消し、そもそもの課題を解決すること、そして後述するアジャイル開発の特性をクライアントや開発チームなどステークホルダー全体が理解しない限り浸透しづらい状況はそのままである。

この他、アジャイルが導入されない理由として、以下のような原因が挙げられる。

  • 開発者のみが導入しても、関わる人々全体が同意しないと意味がない
    • なかなか同意を貰うのが難しい、提案コストが高い
  • アジャイルがプロジェクトの進め方に対して言及しているものである、ということがあまり理解されていない
  • 顧客の理解や協力が得られない
    • 後述するが、クライアントができるだけ近くにいる、ドキュメント納品義務がない、その他契約形態を大きく変えないといけないことを理解してもらうためのコストが高い
  • 商習慣が合わない

ウォーターフォールアジャイルは並列ではない?

ウォーターフォールアジャイルは開発手法として並列に比較されているが、実のところはそうではないのではないか。ウォーターフォールは「作る対象」に対してどのようにアプローチするかを整理したのものであるが、アジャイルは「作る側の人々(プロダクトに関わる人々?)」がどのように振る舞うかを整理した成果であることから、比較する際には注意が必要である。

ウォーターフォールとの比較

そもそも「適応型」のアジャイルと「計画重視」のウォーターフォールでは全く異なるものと言えるため、アジャイルに移行、ということになれば、全く異なる考え方や概念を叩き込む必要があり、さらに、開発チーム以外も思考のリフレッシュが必要である。

計画を重視するウォーターフォールは、ともすると開発現場にはなかなか優しくない考え方であるとも言われる。そもそも計画が正確であったのか、ということにかかわらず、定時されたそれは絶対に守らなければならない、ということである。また、開発中に発生した想定外の事象に対しても、計画の偉大さの前では開発現場がこれの影響を吸収しなければならない、という面を持っているのがウォーターフォールである。

反復型開発との比較

  • 期間を細かく分け、それぞれソフトウェアをリリースする点では同じだが、アジャイルに比べて反復型は1期間が比較的長い。
  • 反復型では分析・評価の段階が1機関の最後に用意されているが、アジャイルでは常に分析・評価の目線が入っている。
    • 開発が一段落、終わったあとに振り返り会を開いても実感が湧かなかったり次に活かそうという気概になりにくい。それどころか「なんで今さら言うの」という雰囲気になりかねないが、これは人の問題ではなくプロセス構成の問題もあるようだ。

アジャイル開発プロセスとプラクティスの関係

カイゼン・ジャーニー』ではピンチの度に新しいプラクティスによって問題を解決していたが、プロセスとはどのように関わるのかというと、単純には、

アジャイル開発プロセスはいくつかのプラクティスを含んだ手法

という認識で問題ないようだ。プロセスは例えば、

といったものがあり、この内一つのプロセスを選択し、これに合うプラクティスを選定する、といった順番を踏んでいるようである。

ただ、必ずこのプラクティスを選択しなければならない、というわけでもなく、現場現場によって異なる特別な状況に合わせて柔軟に対処する、というそもそものアジャイル思考に則るほうが優先される。

ラクティスの分類

カテゴリによる分類

ラクティスは大きく3つに分類される。サブカテゴリも含めると以下のように分けることができる。

  • プロセス・プロダクト
    • プロセス
    • プロダクト
    • フィードバック
  • 技術・ツール
    • 設計開発
    • 障害対応
    • 利用ツール
  • チーム運営・組織・チーム環境

ラクティスの使い方による分類

一口にプラクティスと言っても、それを実際にどう使うのか、で性格はことなり、これに関してはカテゴリとはまた別の分け方をすることができる。これは自己流だが、だいたい以下のようになるのではないか。

  • ワークショップ形式
  • 開発作業の進め方
  • 環境の整備
  • ロジカルシンキングを助ける方法やツール
  • 抽象的概念(哲学?)

スクラム

開発プロセスの一つである「スクラム」について。国内で適用されているアジャイルの中でも、スクラムの適用率は高いらしい。

柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと

自己組織化

組織が1つの人格であるかのような状態を理想とし、そのためにチームは常にコミュニケーションを確保しなければならない。ここでの「チーム」は、開発チームだけではなく、クライアントや全ての関係者を含めたものを示す。これを見たすために、スクラムにおける役割をそれぞれが果たすこと、的確なプラクティスを選別し実施する。

全てのメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ること

現在の流行としてはどんどんリモートワークを!という流れになっている(下請けはまだまだ関係なさそうだけど)が、その場合でも、この原則に反しないことを意識する必要がある。

スクラムにおける役割

チーム

各メンバーが協力し、全体として同じゴールを目指す。

メンバーの数は5~9人、MAXでも10人といったところが限度。それぞれはトップダウンで役割を与えられるのではなく、自らがチーム内の管理を行う(プロダクトバックログやカンバンなどを用いる)。

プロダクトオーナー(PO)

プロダクトの総責任者。顧客の意思の代表としての役割を担うため、クライアントが担うことが理想だが、チームメンバーがクライアントの立場にたって務めることもある。

主な役割として、顧客の要望であるユーザストーリーをプロダクトバックログ(PBL)に優先順位をつけて反映、管理する。

スクラムマスター(SM)

スクラムが開発において正しく適用されていることを保証する。プロジェクト自体の責任者とは異なるため注意が必要。主に外的要因を軽減する(スクラムもといアジャイル理論をステークホルダーに説明し、調整する)ことがタスクとなる。外部から呼ぶことも。

バックログ

プロダクトバックログ

製品に必要な要素を項目に起こした一覧。「機能一覧」に近い。各項目はチームによって相対的な難易度(コスト、工数として数値化したもの)をつけ、POが顧客視点からの価値を見積もり、これらの結果を突き合わせる。

プロダクトバックログはユーザストーリー形式が用いられることが多い。

スプリントバックログ

1単位のスプリント期間文を抜き出したチームとしてのタスクリスト。これの消化率を計測することで、ベロシティ(開発作業の生産性やスピード)の推移やスクラムに問題が発生していないかを観察することができる。

スプリントバックログはチームとしての仕事であり、これが遅れていると判断された場合は、チームメンバーの稼働率を調整するなどして対処するため、「あの人は定時で帰るけど私は残業続き」ということは自ずと発生せず、全員の可動が平坦化されるようになる。

日々のスプリントバックログの消化のために、デイリースクラムが利用される。

フェーズ

スクラムでは以下のようなフェーズを繰り返すことで進んでいく。

  • 計画ミーティング
  • スプリント
  • スプリントレビュー
  • ふりかえり
計画ミーティング

POが今回のスプリントで実現したいプロダクトバックログ候補を提示し、チームのベロシティや状況から見積もり、消化するプロダクトバックログを決定する。

スプリント

コーディング、テスト、ドキュメンテーションを行う。

スプリントレビュー

成果物のレビューを行う。ここで顧客や営業、マーケティングに関わる人間が参加することもある。

ふりかえり

スプリントゴールの達成度、ベロシティの計測、発生した問題と改善策などを話し合いまとめる。

その他の内容

タスクの分割方法

タスク(スプリントバックログ)は、1日以下の単位で分割することが望ましい。これは、デイリースクラムやカンバンを有効化するための条件ともなる(長過ぎると管理や計測が不可能になる)。また、細かく分割することによって他のメンバーがどのようなタスクに携わっているのかということが明確になる効果もある。

ここでの1日とは、具体的には「6~7時間」を示す。定時の7.5~8時間ではギリギリであり、ほかの作業を加味するとオーバーしてしまうのでこの範囲に収める必要がある。デイリースクラムでは、その日のスプリントバックログの合計時間と実際に消化したタスクの合計時間を照らし合わせてベロシティを評価することができる。

感想

以下は研修を経て考えたことをこれまた雑多に。

ファシリテーターとしての経験を活かせるかもしれない

システム開発に関してはもちろん未経験だが、学生時代はファシリテーションを勉強し、実際にワークショップをやってみたりしたこともあった。スキルとしては以下の経験がある。

  • ファシリテーショングラフィック(ホワイトボードと模造紙を使い倒すタイプ)
  • チームビルディング(アイスブレイクくらいだけど)
  • ワークショップ運営

これらのスキルを活用する機会はそうそうないだろうな、と思っていたが、アジャイルではワークショップやゲーム形式のプラクティスも用意されているため、そういったものの運営や進行であればこなすことができる。

ゲーム形式でミーティングや会議をすることはとても効果があり、その最たるものが「上下関係や知識の有無による影響力の差を埋めることができる」点にあると思う。普段とは異なる役割になりきることの効果はやってみれば実感できるはず。

あとは「ゲームに集中することによって問題解決そのものを一旦忘れることができる」とも考えているが、これに関しては社会人はそうは行かないかな、とも思う。

ファシリテーショングラフィックに関してはすぐにでも使えるものではある。まずはプロッキーペンの使い方から啓蒙していきたい。

「飲み込んで」でもプラクティスを試す

おそらく多くの人はこれらの効果を認識こそしているのだろうけれど、実際にやるには腰が上がらない、という感覚なのではないかと思う(自分含め)。この問題は、アジャイルにしてしまえば「アジャイルだからやる」という理由を作ることができるから便利だなと感じた。

あとは「こっ恥ずかしい」という理由もありそう。本当にゲーム形式でワイワイやっていいの?という引け目みたいなものも含めて、ゲームの一員になりきって取り組むことに関する疑念を振り払う必要がある。

あるラジオ番組では突然始まるコントに対応することを「(仕方なく)飲み込む」と言っているが、効果を実感するまではこっ恥ずかしさ他を飲み込む必要があるだろう。

多くのことに関して「現状を変えない」ことに固執してしまいがちだが、この呪いをどうにか解かなければならない。

カイゼン・ジャーニー』を読み直す道筋ができた

カイゼン・ジャーニー』はとりあえず巷でよく目にするから、という理由で流し読みをしたのだが、今回の研修によってスクラム理論という視点から読み直すための準備ができたと感じている。

そして、特に印象に残っている「組織を越境する」というフレーズの主観的な重要性が高まったように感じている。作中では「そもそもの課題」を解決するという視点から、要求されたアプリケーションの制作をする・しないということに関して開発チームが意見する、というシーンがあったが、視野の広さを要求される現場はハイカロリーではあるがモチベーションも高く保てる気がする。

どうしたらアジャイルの現場に潜り込めるか

スクラムの要求するメンバーの条件として、研修では「十分な経験を持っていること」という説明がされていたが、それでは私のような人間はどうやったら潜り込むことができるのだろうか。まあウルトラCを目指す実力はないので地道に頑張りましょう。