アクセスありがとうございます!次は「とあるエンジニアのエソラゴト」で検索して頂けると嬉しいです!

【チーム・ジャーニー】SIerが試行錯誤しながら、アジャイル開発に挑戦した3ヶ月間のノウハウ

はじめに

実は3ヶ月くらい前から、試験的にアジャイル開発をやっています。

キッカケは本当に、鶴の一声。

偉い人:「アジャイル開発をやることになったから」

もちろん、それまでにアジャイル開発という言葉は聞いたことはありましたが、自分自身よく知りませんし、社内に有識者もいません。

そんな誰にも頼れない中で、試行錯誤しながらSIerでもアジャイル開発が出来るのか、実験をしていますので、今回はその話を共有したいと思います。

ちなみにアジャイル開発については、以下の書籍が凄く勉強になりました。

内容(「BOOK」データベースより)
現場のストーリーから、考え方とプラクティスを一緒に学べる。単一チーム、複数チームなど、様々なチーム・マネジメントの問題を扱う。日本の現場を前提にしているので、実践しやすい。アジャイルをこれから始める人だけでなく、もっとうまく実践したい人にも最適。

著者略歴 (「BOOK著者紹介情報」より)
市谷/聡啓

サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自身の会社を立ち上げる(本データはこの書籍が刊行された当時に掲載されていたものです)

引用元:Amazon

とても良い本なので、是非読んで頂けたらと思います。

参考になっているのが、この本は現場で起こっている現象に名前を付けてくれています。

名前があることで、チームメンバーで議論がしやすくなりました。

また実際の開発プロセスを題材にストーリー形式で話が進んでいき、「前にこの問題は起こった」とか、「まだ起こっていないけど起こりそう」とか、ケーススタディ的な側面も持ちます。

先に問題と対策を知っていることで、現実に問題が起こっても、上手く対処出来る可能性が上がると思います。

アジャイル前のチームの状況

まずは、アジャイル開発を実施前のチームの状況は以下のような感じ。

  • チームメンバーは6名。
  • それぞれがアプリ開発とかインフラ構築とか色んな案件を複数持っている。
  • 同じチームだけど、他のメンバーがやっている案件の内容についてはよく知らない。
  • レビューはもちろん行っているが、成果物が出来た後なので、戻りも多い。
  • 基本、チームプレイと言うよりも、個人プレイ。
  • 特定の人に業務負荷がかかっている。

特に課題を持っていたのが、「個人プレイ」と「業務の平準化が出来ていない」こと。

同じチームなのにそれぞれが個人商店となって、仕事進めていた。

そうなると、情報が出てこなくなるし、品質も下がっていくし、何よりも心が荒んできていた。

アジャイル開発導入(〜1ヶ月)

アジャイルについて知るため、外部研修を受けた

アジャイル開発をやろうとしても、そもそもやり方が分からない。

僕たち
 PBLっ何だ?SBLって何だ?

アジャイル開発はみんな初心者だったので、そんな状態から始まりました。

手っ取り早くアジャイルの基本用語と考え方を押さえるために、外部研修に行き、この時にPBLやSBL、スプリントといった基本的な用語と考え方については大体理解が出来ました。

最後に講師の方がこう言ったのが印象的だった。

講師
アジャイル開発は基本的な考え方を理解するのは簡単だが、実践するのは非常に難しい
僕たち
そうなんだー

この時は実に無邪気だった…

カンバン方式を採用したら、タスクの進捗度合いが見える化した

現場に戻り、早速アジャイル開発をやり始めた。

まずやり始めたのは、以下の通り。

  1. カンバン方式を実践するため、壁に「TODO」、「DOING」、「DONE」と書いた紙を貼って、枠線で囲った。
  2. チームメンバー個々人が持っている案件をPBLとして付箋に書き出した。
  3. PBLに紐づく作業内容をSBLとして付箋に書き出した。
  4. SBLをカンバンのTODOのところに貼った。
  5. 日々の進捗管理をするために、バーンダウンチャートを用意して、スプリント中のSBLの消化具合を管理した。

まず、ここまでで目に見えた効果については、「個人が抱えている作業量と進捗具合が一目瞭然になったこと」です。

各個人が抱えているタスクが付箋となって、壁に貼られました。

その付箋がタスクの進捗具合によって壁の中で移動していくので、どのタスクが良い調子で進んでいて、どのタスクの進捗が上手く進んでいないのかが、物理的に確認出来るようになりました。

その結果、チーム内で終わっていないタスクがあったら皆で協力して、助けようという雰囲気が出来てきました。

これまではチームとは呼んでいたものの、ただ同じ場所にいるグループでした。

しかし、各個人が抱えているタスク量と進捗度合いが見える化したことで、個人商店から、協力し合えるチームに少しずつ変わってきた気がしました。

  • 壁を利用してカンバン方式を実践することで、タスクの見える化が物理的に出来る。
  • わざわざファイルの中身を見に行かなくても、チラチラとタスクの動向が見えるので、周りの支援が受けやすい。

アジャイル開発導入(1ヶ月〜2ヶ月)

複数人で一つの案件を専任する

アジャイル開発から一ヶ月経ち、2週間のスプリントを2回実施した後。

僕たち
次のスプリントは、チーム全員で一つの案件をやってみないか?

という話がチームMTの中で起きました。

これまでは、一人か二人くらいで案件を捌いていたが、それをチーム全員で一つの案件に専任しようという提案で、現状、SBLが各個人に紐付いていました。

しかし、「本来はSBLは優先度順に並べた一本の線になっていて、タスクが終わった人から優先度順にタスクを消化していくのが、正しい姿だ」ということを知った結果でした。

複数人で同じ案件をすることで、「開発スピードが上がるし、品質も上がりそうだね」ということで、採用となった。

チームの仲は深まり、メンバーのことをよく知れた

チームの全員で一つの案件、つまりはPBLをやってみることになり、感覚としては非常に楽しかった。

具体的に以下のようなことをやった。

  • ペアプロ
  • モブプロ

設計でもコーディングでも一人で行うのではなく、一つのPCをモニターとして、複数人で作業をすることにした。

これにより、レビュー段階で各個人が作った成果物を見るのではなく、各個人の成果物を作るまでの「考え方」や「やり方」を学ぶことが出来た。

今後、引き継ぎをする際にはペアプロやモブプロを行うことが有効なんじゃないかとまで思った。

これまで同じ現場にいながら、少しずつ協力関係にはなっていたものの、近い距離感で仕事をしたことがなかった。

でも、このスプリントが終わった頃には、各個人の表に出てなかった「強み」や「弱み」を把握することが出来た。

コーディングが得意でPoc(概念実証)をさせたら、凄く良いものを作る人がいたり、皆が話していた内容を書き留めて良い感じのドキュメントを仕上げてくれる人がいたり…

このスプリントでチームに足りないものが分かり、自分の役割を形成するのに何をやったら良いのかを実感することが出来た。

それよりも何よりも、チームメンバーのことがとても好きになり、チームの仲が深まった気がした。

  • 一つの案件をチーム全員でやってみることは、チームメンバーの理解、関係形成の中で非常に有効だと感じた。
  • チーム理解が深まったら、「自分に何が出来るかを自問自答」し、何か役割を果たす必要がある。

だがしかし…工数は跳ね上がる

「そりゃそうなるやろ」というツッコミを受けそうだが、何でもペアプロ、モブプロといった感じで、今まで個人でやっていた作業も複数人でやったため、計画段階よりも、工数が大きく跳ね上がった。

一回のスプリントの中で、思ったよりも成果物が上がらなかったのだ。

偉い人からは少しお叱りを受けた。

次は前みたいに個人商店にはならないにしても、ある程度タスクをふるいにかけて、個人でやる作業と複数人でやる作業を分けることにした。

  • 何でもかんでもペアプロ、モブプロするともの凄く工数がかかるので、タスクの選別が必要。
  • 特に技術的にハマったりすると、すぐに工数が溶けていくので、ある程度皆で考えて、分からなければ外部にサポートを依頼したり、思い切った割り切りが必要。
  • 不確実性の高いタスクや、大勢のメンバーがよく知らないタスクがペアプロ、モブプロに向いていると感じた。(しかし使って良い時間は事前に決めておく)

アジャイル開発導入(2ヶ月〜3ヶ月)

チームとして機能しつつ、成果物も上げる

上記の命題を持って始まった3ヶ月目だった。

2ヶ月目のアジャイル開発の内容を振り返り、以下のことを実施した。

  • 一本化していたSBLの線を複数の線に戻した。
  • チームメンバーを最小3人になるように割って、SBLに対応した。
  • ある程度、設計内容が形になったら、チーム皆で集まり、意見を出し合った。
  • その際、ドキュメント化するよりも前に、ホワイトボードに書いて、意見をもらうようにした。
  • 一つのSBLにかけても良い時間を2時間と決めて、それを超えたらアラートを上げる。

とりあえず、タスクを消化していくことを優先とした施策であった。

タスクの決定については、リーダーが一人で決めるとかではなく、開発者全員で話し合ってタスクの内容と人数を決めていった。

最初は全然上手くタスクの割り出しや人数配置が出来なかったが、失敗を重ねていくうちに、「このタスクはやばそうだね、前の実績でいうとこれくらいかな?」という共通認識がチームの中で生まれていった。

前回のスプリントでチーム理解と関係構築が出来ていたため、タスク消化に対する緊張感を感じながらも、チームの雰囲気は良好なままスプリントは経過していった。

特に、前回はチームメンバー全員でタスクを行っていたため、上手くタスクが進まないと、タスクへの関与度が低くなり「消える時間帯」が発生するメンバーがいた。

しかし、3人が基本の人数となったため、消える時間帯が発生することなく、前よりも皆パフォーマンスが良くなったと思う。

その結果、今回のスプリントはタスク消化率も以前と比べて改善し、計画通りにSBLを消化することが出来た。

これがチームの小さな自信に繋がった。

  • 普段は優秀なエンジニアでも、大勢のメンバーが一つのタスクに群がると、タスクへの関与度が低くなり、パフォーマンスが下がることが分かった。
  • タスクの内容と人数配置は皆で話し合って決めた。皆で決めることで納得感が得られた。
  • ある程度、チームが良い雰囲気になったら、タスク消化を優先した動き方をするのが効果的だった。

2020/03/14 追記

Twitterにて以下のご質問を頂きました。

「普段は優秀なエンジニアでも、大勢のメンバーが一つのタスクに群がると、タスクへの関与度が低くなり、パフォーマンスが下がることが分かった。」とはどういうことですか?

これは、例えば同じタスクしていて、技術課題が発生した場合について。

6人で調査はするのですが、解決しないと「6人もいるので、誰かが解決するだろう」と思ったり、技術調査の中でも役割分担が上手く出来なかったりして、フルパワーが出せない状態になった人がいました。

多分、大人数のため心理作用が働いたり、上手く分担が出来なくて、人数の割に結果が伴わなかったということだと思います。

そのため、タスクや時間経過によって人数配置を柔軟に切り替えていく必要があると感じました。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで」を元に、これまでの三ヶ月を振り返る

チームには段階が必要

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで」を読んで、「チームには段階を付けてデザインすることが必要であること」を学んだ。

具体的には、「チームとして何を優先するか」を意識しながら、チームの在りたい方向性を見定めて、実践していくことだと理解した。

書籍では「○○ファースト」という呼び方で紹介されている。

結果的に、以下のような感じとなっていた。

時間軸ファースト(優先事項)やったこと効果
1ヶ月目までアジャイル開発のやり方を理解するカンバン方式タスクの見える化
2ヶ月目までチーム理解と関係構築ペアプロ、モブプロチームメンバーのやり方と考え方を学習した。
チームの皆が好きになって、仲良くなった
3ヶ月目までタスク消化少数チーム化と効率化今までの良いところを維持しながら、タスク消化率が上がった

チームの目的に合わせて、柔軟に頭を切り替えて、チームの形も変えていくことが大切であると感じた。

これからの課題

毎週一回、KPTと呼ばれるフレームワークを使いながら、チームの振り返りを行っている。

内容はこの一週間で「良かったこと(Keep)」、「問題(Problem)」を振り返り、そこから次の一週間に向けた「挑戦(Try)」を洗い出していく作業である。

アジャイル開発が3ヶ月経過すると、何となくチーム内にマンネリ化の雰囲気が出てきた。

そのため、問題点が出にくくなり、次のアクションが出てこなかったり、あまり費用対効果が見込めないようなどっちでも良い挑戦となってしまっている。

アジャイル開発をやる意味は、「柔軟な改善活動をプロセスとして埋め込むこと」にあると思っているので、非常に課題であると思っている。

最後に

今回は、私が経験した3ヶ月間のアジャイル開発の道のりを紹介させて頂きました。

アジャイル開発は決して、銀の弾丸ではありません。

ウォーターフォール・モデルから、アジャイル開発に移行して、すぐに結果が出るものではないです。

特にアジャイル開発は文化だと思います。

なので、アジャイルを理解することは簡単だけど、実践することは難しいのです。

大きくチームや組織のあり方を柔軟に変えていかないと、コミュニケーションコストばかりかかり、アジャイルの効果を得にくいような気がしました。

しかし、チーム形成の面でも、メンバー育成の面でも、タスク消化の面でも一定の効果はこれまでの3ヶ月で確認が出来たと思っています。

特にチーム形成においては以下のように、この3ヶ月で目に見える効果を発揮できました。

  • メンバーの理解が進んで、得意・不得意を知った
  • お互いのことが好きになって、信頼関係を築けた

メンバーのことを知ることで、「このチームの中で自分に何が出来るか?」と考え始めることが出来ました。

メンバーお互いのそんな姿を見て、「あいつは頑張っているな、自分も頑張ろう」と思えて、信頼関係が深くなったと思います。

その結果、このチームは自分の居場所だなと思うことが出来ました。

まだまだ私はアジャイル開発をしていくので、フィードバックをこれからもしていきたいと思っています。

続きの話は以下からどうぞ!

関連記事

はじめに 〜アジャイルとは変化に対応する文化形成〜 「SIerでもアジャイル開発がやってみたい」ということで、アジャイル開発を始めてから4ヶ月が経ちました。 アジャイル開発を実際に行い、試行錯誤した結果、「アジャイル開発とはた[…]

ここまでお読み頂き、ありがとうございました!

最新情報をチェックしよう!