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

実は3ヶ月くらい前から、試験的にアジャイル開発をやっています。キッカケは本当に、鶴の一声で「アジャイル開発をすることになったから」と言われました。

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

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

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

特に参考になっているのが、この本は現場で起こっている現象に名前を付けてくれています。名前があることで、チームメンバーで議論が容易になりました。

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

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

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

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

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

同じチームなのにそれぞれが個人商店となって、仕事進めていた。そうなると、情報が出てこなくなるし、品質も下がっていくし、何よりも心が荒んできていた。

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

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

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

「 PBLっ何だ？SBLって何だ？」と、アジャイル開発はみんな初心者だったので、そんな状態から始まりました。

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

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

「アジャイル開発は、基本的な考え方を理解するのは簡単だが、実践するのは非常に難しい」と。この言葉は心に強く残り、後で実感することになります。

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

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

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

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

各個人が抱えているタスクが付箋となって、壁に貼られました。その付箋がタスクの進捗に応じて、壁の中で移動するので、どのタスクが順調で、どのタスクの進捗が不調なのかが、物理的に確認出来るようになりました。

その結果、チーム内で未完了のタスクがあったら、「皆で協力して、助けよう」という雰囲気ができませした。た。

これまではチームとは呼んでいたものの、ただ同じ場所にいるグループでした。しかし、各個人が抱えているタスク量と進捗が見える化したことで、個人商店から、協力し合えるチームに少しずつ変わりました。

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

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

アジャイル開発から一ヶ月経ち、2週間のスプリントを2回実施した後に、「次のスプリントは、チーム全員で一つの案件をやってみないか？」という話がチームMTの中で起きました。

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

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

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

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

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

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

• ペアプロ
• モブプロ

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

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

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

これまで同じ現場にいながら、少しずつ協力関係にはなっていたものの、近い距離感で仕事をしたことがなかった。でも、このスプリントが終わった頃には、各個人の見えなかった「強み」や「弱み」を把握することが出来た。

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

このスプリントでチームに足りないものが分かり、自分の役割を形成するのに何をやったら良いのかを実感することが出来た。それよりも何よりも、チームメンバーのことがとても好きになり、チームの仲が深まった気がした。

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

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

一回のスプリントの中で、思ったよりも成果物が上がらなかったのだ。偉い人からは少しお叱りを受けた。

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

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

「チームとして機能しつつ、成果物も上げる」という、命題を持って始まった3ヶ月目だった。

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

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

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

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

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

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

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

その結果、今回のスプリントはタスク消化率も以前と比べて改善し、計画通りにSBLを消化することが出来た。これがチームの小さな自信に繋がった。

2020/03/14 追記

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

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

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

これは、例えば同じタスクしていて、技術課題が発生した場合、6人で調査をしますが、解決しないと「6人もいるので、誰かが解決するだろう」と思ったり、技術調査の中でも役割分担が上手く出来なかったりして、フルパワーが出せない状態になった人がいました。多分、大人数のため心理作用が働いたり、上手く分担が出来なくて、人数の割に結果が伴わないということだと思います。 そのため、タスクや時間経過によって人数配置を柔軟に切り替えていく必要があると感じました。

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

チームには段階が必要

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

具体的には、「チームとして何を優先するか」を意識しながら、チームの在りたい方向性を見定めて、実践していくことだと理解した。書籍では「○○ファースト」という呼び方で紹介されている。

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

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

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

これからの課題

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

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

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

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

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

最後に

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

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

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

特にアジャイル開発は文化だと思います。なので、アジャイルを理解することは簡単だけど、実践することは難しいのです。

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

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

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

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

メンバーのことを知ることで、「このチームの中で自分に何が出来るか？」と考え始めることが出来ました。そんな姿を見て、「あいつは頑張っているな、自分も頑張ろう」と思えて、信頼関係が深くなったと思います。

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

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

その他、アジャイル開発の関連記事は以下