「アジャイル開発とスクラム」より良いモノを最短で作るには。テレワーク or 出社、生産性が高いのはどっち？
2020年に始まったコロナ禍以来、テレワークやリモート飲み会があっという間に普通のことに。それから約3年、会社に戻るのかこのままテレワークで働くのか、さまざまな職場で議論がされているみたい。
ポイントのひとつが、どっちの働き方がより「生産性が上がるのか」。会社は社員に出社してほしいけど、多くの人たちがテレワークに慣れてしまった今、「なぜ出社しなければならないの？テレワークでもできるのに」と言われてしまう。以前のように「業務命令」で社員を従わせる手法はもう流行らない。会社と社員の関係も変化しているように感じます。
そんな時、手に取った本「アジャイル開発とスクラム（翔泳社）」は、「協調的ソフトウェア開発」について書かれた本。だけど、どうすれば生産性が上がるのか、多くのヒントを与えてくれる本。
その考え方は、顧客もリーダーもメンバーも全員が一つのチームを結成して同じゴールを目指すというもの。メンバーは業務命令ではなく自分たちで決めながら柔軟に動き、完璧ではなくても、迅速にソフトウェアの一部を開発して全員と共有。顧客のフィードバックを受けながら成長させていく。その結果、協調的なコミュニケーションが発生し、チームのモーチベーションが上がり、生産性が大幅にアップしたという。
圧倒的なスピードを支えているのは密度の濃い、リアルな会話。本当に！？
急速な変化が同時に進行している職場
「ソフトウェア開発」ではないけど、会社がまったく新しいシステムを導入したり、ウェブサイトやSNSを始めたり、評価や給与の仕組みが変わったり、外国人をはじめとする多様なバックグラウンドを持つ人たちと一緒に仕事をするようになったり、職場でいろんな変化が急速に、同時に進行していることってありますよね。うちの職場もそうなんです。
前例のない案件を、立場の違うさまざまな人たちが関わって、無駄なく最短で実現するにはどうしたらいいのか。意外にも、アジャイル開発の根っこにあるのは「合宿」の思想。
いろんな背景を持った人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこから初めて、１つの共通理解が生み出される。
アジャイル開発とスクラム・P286
最先端のソフトウェア開発手法なのに、アジャイルって意外とアナログ？一体どういうこと？
アジャイルとウォーターフォール
アジャイル開発は、それ以前に主流だったウォーターフォールと呼ばれるソフトウェア開発手法が行き詰まったところから発想されたと言います。
従来は、作るソフトウェアについての要求を事前にすべて収集・把握し、それを分析・設計・実装し、最後に全体テストをする、といういわゆる「ウォーターフォール」手法で進められてきた。基本的に各工程間の後戻りを許さず、ドキュメントで工程間を伝達する手法だ。
アジャイル開発とスクラム・P7
しかし1990年代ごろから、徐々にインターネットやクラウドが普及しはじめ、ウォーターフォール型ではビジネスの変化の速さについていけなくなってしまいます。
ウォーターフォールでは（中略）、プロジェクトの最後にようやく動くものができあがるため、顧客やユーザーは最後まで動くものが見えない。紙に書かれた文書で仕様を理解しなければならず、誤解も生じやすい。さらに、要求を出してから実際に使えるようになるまで長い時間がかかるため、そもそもの要求がソフトウェアの完成時点で古くなってしまうことさえある。
アジャイル開発とスクラム・P30
さらに、ウォーターフォールの開発体制は、プロジェクト管理、製品管理、開発、ドキュメントなどなど専門ごとに細分化されていました。ソフトウェアの複雑化・巨大化とともに組織も急速に大きくなっていきますが、問題は解決されないどころか、かえって頻発するように。ソフトウェア開発のスピードは落ち、現場には不満が鬱積していったと言います。なにか、人ごととは思えない状況ですよね。
アジャイル開発は現場のモーチベーションをアップする！？
これに対しアジャイル開発では、分析、設計、実装、テストを短い期間で並列に行い、それを繰り返す。顧客にとって価値の高い機能から開発し、短い間隔で動くソフトウェアを完成させる。文書や報告ではなく、動くソフトウェアを一定間隔で作り、それを成長させるのだ。開発を通して顧客やユーザーの意見をフィードバックしながら進める。途中で修正が入るのは普通だし、昨日の優先順位も途中で変更される。
（中略）手順としてのアジャイルはこのような繰り返し型に特徴があるが、実際には、協調とコミュニケーションスタイル、顧客と開発チームのゴールの共有関係、柔軟な計画変更の考え方、現場の開発者のモーチベーションなど、その価値観が従来手法と大きく違っている。
アジャイル開発とスクラム・P30、P32
決まったことを決まった通りにやるのではなく、常に「何がベストか」を顧客も開発者も、全員で考えながら柔軟に優先順位やスケジュールを変更することができる。確かにとっても良さそう。「お客さまは神様」ではなく、「お客さまも仲間」。なんともフラットな組織。
工程を追って順に仕事を進めるやり方（編集部注：ウォーターフォール）は、仕事を渡す側と受ける側の間に敵対関係を生み出す傾向にある。「仕様に書かれていないことをやってほしいと言うのです」「簡単に気を変えないでほしい」「自分にコントロールできないことに対して、私は責任が持てません」などなど。（中略）その結果できた製品は、作った現場開発者の創造性、スキル、そして情熱を表現したものにはならないのだ。人はロボットではない。だから、人にロボットのように働くことを求めるプロセスは、介在する人々を不幸にする結果になる。
アジャイル開発とスクラム・P48
仕事を渡す側（顧客）と受ける側（開発者）が協調関係となり、同じゴールに向かって進んでいく。そこには人間らしい仕事の楽しみがあるらしい。そのチームが「スクラム」。アジャイル開発を実践するプロジェクトチームです。
顧客もチームの一員。決定は上司ではなく、メンバーが自分たちで決める
スクラムは非常に薄い「マネジメントの枠組み」といわれる。決められているのは、チーム全体が協調するためのコミュニケーションのルールだ。（中略）スクラムで決められている役割は、「プロダクトオーナー」「開発者」「スクラムマスター」の3種類のみである。これら全体を、「スクラムチーム」と呼び、3つの責任が協調することで、大きな効果が得られる。
アジャイル開発とスクラム・P53
プロダクトオーナーは、何を開発するか決める人。ソフトウェアに実装する機能の優先順位もプロダクトオーナーが決めます。この役割は、顧客（ユーザー企業）が果たすことが推奨されています。
「開発者」は文字通り実際の開発に携わる、異なる専門知識を持った人たち。そして、「スクラムマスター」はスクラムチームの全員が協力しあえるように奉仕するリーダーだそう。メンバーの悩みを聞き相談に乗ったり、外部の横やりに対して交渉したり、メンバーが動きやすいように環境整備をしたりする。中間管理職的な役割を想像するけど、スクラムマスターは指揮命令しない。
開発のやり方に関する決定はスクラムマスターではなく、チームが行う。スクラムマスターが細かい指示を出すのではなく、自分たちで決めながら動く自己管理型のチームを作ることが生産性を上げる鍵だ。
アジャイル開発とスクラム・P56
顧客との契約形態も、新しい責任と役割に基づいて準委任契約が推奨されています（従来は請負契約が多かった）。単なる現場の手法だけじゃなく、会社としての姿勢も徹底してる。
スクラムチームはテレワーク？出社？
自己管理型で生産性が爆上がる「スクラムチーム」。彼らはどんな働き方をしているんだろう。協調的コミュニケーションって実際どうやっているの？
- スクラムチーム結成時に「プロジェクトの目的や目標、スケジュール、役割などの大切な情報を全員で確認・腹落ちするためのシンプルなドキュメント」を作る。理想はチーム全員で集まって項目をその場で埋め、議論すること（アジャイル開発とスクラム・P70、P72)）
- 従来の「要求仕様書」を置き換える「ユーザーストーリー」、つまりユーザーの言葉で書かれた機能の説明を書く。ユーザーストーリーはアナログを重視し、紙のカードに書いて会話によって伝えることが推奨される。（アジャイル開発とスクラム・P72)
- 開発者が全員の活動状況を共有するミーティグを毎朝15分行う（デイリースクラム）。現在の状況を示す資料や書き物が貼られた壁の前で、短時間で立ったまま行うことを習慣化するため、スタンドアップミーティングとも呼ばれる。（アジャイル開発とスクラム・P74）
などなど、他にもいろんなやり方があるみたいだけど、重要な分岐点は全部リアルで集まることが推奨されています。
顧客から見て価値がない無駄なドキュメントを排除し、密度の濃い「場」を使ったコミュニケーションこそが、アジャイル開発の圧倒的なスピードを支えている。（中略）ソフトウェアのツールを使った「デジタル」と、壁とポストイットなどの「アナログ」は、その利用のバランスを現場で考える必要がある。ただし、ぜひ一度はアナログで試したい。会話の量が増え、チームに活気が出ることが実感できる。
アジャイル開発とスクラム・P94
リアルなコミュニケーションが生産性を高める
アジャイル開発を実践する「スクラムチーム」。その本質は、柔軟で率直で自由。その関係は協調。これは、ソフトウェア開発だけでなく、いろんな職場、いろんな業務で参考になりそうな気がしました。
今までのように上司の指示を待って、指示通りに動くやり方じゃない。自分たちで決めて、仲間と協調し、要所要所でリアルにコミュニケーションして、無駄なく最短で目的を達成する。そこには、上司・部下、顧客・請負、若手・シニア、といったような従来の決めつけから解放された新しい仕事の楽しさが提示されているように思います。
テレワークか出社か。今、いろんな職場で議論されているこの問題。さあさあ、どうする！？
