アジャイルを経験したSIerのお話

今回の内容はアジャイル（スクラム）開発の個人的な経験談です。
スクラム自体のやり方やウォーターフォールとの比較などは書いてありませんので、あしからず。

アジャイルを経験したSIerは、フリーランスになる決心をする

2019/4/8現在、「とあるフリーランスエンジニアができるまで」としてブログを書かせてもらっていますが、今回はスクラム案件で得たものを中心にお話しします。

話の時系列は「独立直前」です。（メインが終わっていないのに外伝とか・・・）

ソフトウェア開発には色々なやり方がある

一口にソフトウェア開発といっても様々な開発手法が巷には溢れています。

代表格はウォーターフォール（以後WF）とアジャイル、プロトタイピング。
各々の手法によるメリットデメリットにつきましては、他の方が詳細に比較しているため、ここでは省略させていただきますね。

2019年現在、この手の記事はネットや書籍等で飽和状態です。
ですので、今回は私個人が経験した事を例にして、6年前(2013)に初めて触れたスクラムが、現在の自分にどう影響しているのかを残しておこうと思います。

学んだこと

• ・新しいバスに乗ってもらうには乗っている姿を見せ続けること
• ・どんなコネクションでもないがしろにはしない
• ・良いと思われる仕組みでも改善して続ける
• ・否定的な意見を分析すると改善策につながる
• ・納得できない人にやってもらうには、お願いに変換すると確率が上がる
• ・人間的に好きになってもらうより優先すべきことがある

スクラムとの出会い

2013年、未経験から始めたSIerも何とかやってきましたが、このままでいいのか？感は一向に拭えずただ生き延びてきた自分にその後の人生が変わる出会いがあります。

• ・やる気に満ち溢れているPM
• ・同じ転職組のフリーランスエンジニア
• ・自由が利く開発環境

当時の自分は意識の低いSIer。アジャイル開発という言葉すら知りませんでした。
そもそも孫、ひ孫請け案件ばかりの状況下では開発スタイルを提案するなんていう選択肢は持っていません。

それまではWFだけが開発手法だと思い込んでいましたし、そのやり方に疑問をもったことはありませんでした。

そんなSIerがアジャイル（スクラム）というモノに触れてしまうのです。
※「とあるフリーランスエンジニアができるまで」と合わせて読んでいただくと背景がわかりやすいかと思いますので、そちらもよろしくお願いします。

スクラム開発の一例(2013～2015)

参考書籍は？

• ・SCRUM BOOT CAMP THE BOOK
• ・アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
• ・アジャイルサムライ−達人開発者への道

一番読み返したのは「SCRUM BOOT CAMP THE BOOK」ですね。
今更本書の説明はしませんが良本です。

当時の状況は？

当時のSIer案件はWF一択であり、開発手法から選定するなど無駄な取り組みなわけです。周りからは当然懐疑的な視線を浴びますｗ

また、参画した部署もバックエンド。ひとつのミスが数百万人に影響してしまうので、とにかく安全であることが全てでした。

そんな中にあっても素晴らしい人材は居るもので、自分を採用してくれたPMはとにかく凄かったですね。

できるPMって本当に居た（プロダクトオーナー）

新しい何かを始めるには、それを支援してくれる人達は必須です。

自分にとっての支援者の一人がPMでした。
当時自分は34歳。PMの彼は31くらいでしょうか。

一言で彼を表現するなら「コミュニケーションの申し子」ｗ

彼自身はエンジニア経由でPMになったのではないので、開発は基本一任してくれました。そうゆう経歴のひとは他にもたくさん居ますが、投げっぱなしではないのです。

任せたらちゃんと一任してくれますし、責任も折半してくれていました。

管理者経験ある方ならわかると思いますが、簡単そうで意外とできないことなんですよね100％お任せって。自分の評価に繋がるわけですから人によっては口や手を出してしまいますし、それがチームの邪魔になっていることすら理解できないのです。

要所要所で方向確認やステークホルダーへの根回しなど行いチームが開発に集中できるように動いてくれる、プロダクトオーナーとしてほぼ完璧な存在です。

彼はどんな職種でも成功するメンタリティーを備えていました。
（現在は別の仕事で大活躍しています）

こうゆう人と一緒に仕事ができることはそう多くはありませんので、縁というのは大切にしていきたいですね。

メンバーとして取り組んだこと

3人の少数チームでメンバー構成は

• ・フリーランスエンジニア（スクラムマスター）
• ・上位会社のエンジニア（20代）
• ・自分（30代）

ここでは様々な事を経験し吸収していきます。

• ・スタンディングでのデイリースクラムの有効性
• ・アイスブレイクの必要性
• ・リファクタリングの重要性
• ・ペアプロの重要性
• ・バスの載せ方
• ・モチベーター意識
• ・ファシリテーション
• ・ゴール設定の重要性

などなどキリがないほどインプットしていきました。

メンバー個人としては、開発に集中できる環境が初めてだったし、タスクの粒度も細かくして話し合えばやることが明確になり、手が止まるということが少ないと感じました。

アナログでやることで椅子に座ったままよりもリアクションしやすく、達成感や充実感も得やすかったと思います。

マスターとして取り組んだこと

メンバーとして半年ほどスクラムを経験したあとはスクラムマスターとしてチーム運用を期待されます。

その前に妨害

元々チームリーダー候補として参画していますので予定通りだったのですが、元請けは納得していなかったようで、一悶着ありますｗ

半年前にひ孫請けで参画。当時からリーダー候補として採用されたのですが、元請けからしたら、自社の社員からリーダーにしたいのですよ。単価が全く違いますからねｗ
そこでMTGを行うわけですが、こっちには知らせずに元請けの社長が登場（初見ｗ）。そして何故か自分も強制参加させられます...。

※元請け社長＝A、元請け営業＝B、お客様（最高責任者の部長とPM）、自分の計5名

A「新しいWebチームを作るにあたりご提案させてください」
B「チームリーダーとして責任を果たすにはウチの社員の方が連携しやすいので、是非○○さんもしくは△△さんでお願いします」
部長「・・・」(チラッ)
PM「・・・」(チラッ) 自分「・・・」（何故見る）
A「開発の安全性やスピードを考えたら、ウチの人間にやらせた方がいいですよね？」
B「○○さんや△△さんもWeb開発の経験があるので、大丈夫です」
PM「Webチームは試験的にアジャイル開発でやっていきたのですが、その二人できます？」
A,B「・・・」
A「経験はないですが、リーダーとしてはウチの人間の方が・・・」
部長「彼はどう思ってるの？」「半年別部署まで行って経験させてきたけど」(チラッ)
自分「スクラムでやらせてもらえれば、次の開発は2か月で終わらせることが出来ますし、Aさんのところの新人も受け入れて教育します」（大風呂敷を広げる）
部長「じゃあお願い」
PM「ですよねｗ」「このMTGする必要ありました？」
A,B「・・・いや、彼はひ孫だし・・・」（チラッ）
自分（だから、なぜ見る）

======= その後 ===========

自分とBさん + 元請け現場リーダー（Cさん）の3人でMTG
B「という訳で、彼にリーダーやってもらうことになりました」
C「最初からそういう契約でしょ？なんでかき回すの？」
B「社長が・・・」
C（自分へ）「すいません。変なことに巻き込んでしまって・・・」
自分「いや、色々見れて勉強になりましたｗ」「ですが、ご相談させてください。現場の連携が不安であるなら、間の１社いらないですよね・・・」

ここで自分は現在のひ孫から孫に繰り上がる契約を取り付けます（笑）

条件としては、元請け新人を受け入れて教育することと、開発期限は厳守すること。

スクラムマスターのスタート

さてやっとスタートです。このブログもここからがスタートなのです。

最初の仕事はとにかく新チームでスクラムを回してみることでした。 （長くなるので箇条書きで進めます）

チームメンバー。入れ替わりで常時３～５名（２ｗスクラム）

• ・ベテランエンジニア（C,C++メインでJava未経験。50代♂）
• ・開発未経験エンジニア　2名（他チームでテスターなど。20代♀）
• ・前のチームメンバー（20代♀）
• ・前のスクラムマスター（サポートのみ。40代♂）
• ・自分（30代♂）
• ・ベテランエンジニア（自社では取締役。40代♂）
• ・優秀エンジニア（20代♂）

不安要素

• ・ベテランさんがスクラムでやってくれるかどうか？
• ・新人がいきなりスクラムでやれるかどうか？
• ・自分がスクラムマスターできるかどうか？

成功したこと

• ・ベテランさんの拒絶は想定内、色々な役割を与えた結果バスに乗ってもらえた
• ・ゴールまでの道筋を明確に伝えることで、新人でも手詰まることがなく進めた
• ・定時帰りでも遅れずにリリースできた
• ・朝会、振り返り会などMTG司会を順番制にしたら、全員が責任をもって開発できた
• ・メンバーが代わってもWebチームとしての文化を残せた
• ・PMの作業負担を減らし、チームに関わってもらう時間をふやした
• ・別チームもスクラムでやりだした

失敗や布教不足だったこと

• ・一部では定時帰りとスクラムを結び付けて広められなかった （チーム運用改善の結果ではなく、見積が多すぎたと判断されることが多い）
• ・「結局人でしょ？」と言われることが多い（でもそれはWFでも同じなのにね）
• ・スクラムだと疲れるメンバーも存在する（ただコーディングしたいエンジニアに多い）

まとめ

本当はスクラムマスターでの経験をたくさん書きたかったのですが、ごめんなさい文才がなくただ長いだけの内容になってしまいました。

自分のスクラムマスターとして成功したかどうかは、その時のメンバーが現在どうなっているか？だと思いますが・・・どうなんでしょうねｗ

Twitterでもつぶやきましたが、メンバーから言われて嬉しかったのは

• ・スクラムマスターって自分でも出来そう（何かを広めるには必要な感覚ですよね）
• ・えっ、そのまま使うんですか？（資料やコードの精度が上がりました）
• ・このリーダー大丈夫？（メンバーの責任感向上ｗ）
• ・他のチームより笑顔が多くて前より楽しかった（大事）
• ・気が付いたらWebアプリが完成してた（迷う時間が少なかったのかな？）
• ・朝会の「今日の一言」が地味にネタ切れで辛かったので、趣味の話になりがちでした（アイスブレイクの一環で日直さんは一言いうのですが、こちらの意図としてはその人が何に興味をもっているなどを引き出すことでした）

ですかね。主に送別会で言われたことなので、どこまで本気か定かではないですが。

それと自分の送別会の時はたくさんの人が参加（PMの力）してくれたのも嬉しかったなぁ。