はじめに

2023年春から2024年初旬にかけて、enPiTの一環として行われた大学の授業プログラムに参加し、無事修了致しました。
当記事はそのまとめ課題であり、本授業の振り返りとなります。

アジャイルの精神に則って、等記事は徐々に発展してゆきます。

2024/1/24 : とりあえず型を作りました。
2024/2/10 : 締切が明日であることに気づき、とりあえず大体の構成を決めました。
2024/2/11 : 締切に間に合わせるために爆速で書きました。しかし、事前説明とかに時間を使いすぎたことと、予想外に書きたいことが膨らみすぎてまとまらずとりあえずやけっぱち。もう少し書き足す予定です。
2024/2/12 : 当編集履歴を追加。

enPiTと当プログラムについて

enPiTとは、"Education Network for Practical Information Technologies(成長分野を支える情報技術人材の育成拠点の形成)"の略で、元々は文部省がはじめたようです。
詳しい説明は、当プログラム同期の仲間達が作り上げた素晴らしいwebサイトがあるので、そちらに説明を任せます。
要するにIT人材育成の取り組みです。

当プログラムは、enPiTの中でもBizSysD(Business System Design)という区分です。
PBL(Project Based Learning, 課題解決型学習) といって、実用化を意識したアジャイル形式でのプロダクト開発を行います。
横文字が多くてわかりにくい訳ですが、つまるところ、"1年かけて行われるチーム開発の実践型訓練授業"といったところでしょう。

アジャイルとスクラムについて

アジャイルを知らない方でもこの記事をスムーズに読むために、当プログラムで行った開発手法であるアジャイル、及びスクラムについて先にご説明します。
"アジャイルとはなにか"はとても哲学的な問ですから、ここで書くことはあくまで当記事執筆時の私の理解であり、さらにそれを噛み砕いたものであると認識してください。
本当に理解するには実際に体験してみるのが一番です。

アジャイル開発

実用上は、常にプロダクトの価値を最大限にするような形で、方向修正をしながら徐々にプロダクトを大きくしていく開発手法です。
対象的な手法として、 ウォータフォール開発 があります。
ウォーターフォール開発では、はじめにプロダクトの完成形を定め、それに向かって開発を進めます。
アジャイル開発では、はじめの段階でプロダクトの完成形がわからないという欠点はあるものの、細かい方向修正やトラブルへの柔軟な対応が可能であり、また、常に価値の検証をしながら開発することができます。
プロダクトを創造するウォーターフォール開発に対して、プロダクトを育ててゆくのがアジャイル開発です。
アジャイルソフトウェア開発宣言

スクラム

アジャイル開発の具体的なフローを定義するもののうち、一番主要なものがスクラムです。
スクラムではまず PBL(Produce Back Log) を定めます。
PBLは、 PBI(PBL Item) から構成されるのですが、これが最も重要で、 プロダクトの価値の単位 です。
例えばプロダクトがQiitaなら、"記事を書いて投稿できる"、"いいねができる"、"限定公開記事がかける"といったPBIが考えられるでしょう。
その集合がPBLです。

その後開発が始まります。
開発は、 スプリント と呼ばれる通常1~4週間ほどのサイクルの繰り返しで構成されます。
スプリントは スプリントプランニング から始まり、そのスプリントでどのPBIを達成するかを確認した後、具体的なタスク分割や計画を行います。
スプリントプランニングののち実際に開発を行い、それが終わると次は スプリントレビュー です。
ここではプロダクトのステークホルダーを集め、そのスプリントで達成したリリースに関してレビューを行います。
最後に、スプリントレビューの結果を踏まえてPBLを見直し、スプリントの振り返りと今後の方向修正をする プリントレトロスペクティブ を行います。
このスプリント(プランニング、開発、レビュー、レトロスペクティブ)を繰り返し、プロダクトの理想の価値を追求しながらプロダクトを育ててゆくのがスクラムの真髄です。

役割

スクラムは4~10人程度で実施するのが理想とされますが、そのメンバーには各々役割があります。

PO(Product Owner) はプロダクトの所有者のようなものです。
POは常に、誰よりもプロダクトのことを大切に考え、プロダクトが解決せんとする課題と一番真剣に向き合います。
スプリントを主導してゆくのがPOであり、最終的な意思決定をするのもPOです。

ScM(スクラムマスター) はスクラムチームのマネージャーのようなものです。
ScMはチームがスクラムを遂行するための理想的な環境を整えます。
スクラムとチームを良くするためなら、重要な意思決定から雑用まであらゆることを行います。
チームが立ち行かなくなっているときに軌道修正を図るのもScMの役割です。
スクラムに対して一番の理解を要されるがScMです。

開発者 はその名の通り開発を行いますが、リーダーに従う部下ではありません。
スクラムには上下関係はありません。
開発者であってもスクラムを理解し、POと一緒にプロダクトの価値を考えて頭を悩ませ、意見や不満があれば表明する義務があります。
専門家ならではの視点でプロダクトの価値最大化を図るのが開発者の役割です。

今回のプログラムでは、人数が少ないこともあり、全員が開発者で、PO及びScMは開発者を兼任しました。
また、スプリントは通常は1~4週間と言われますが、当プログラムでは1日1スプリントです。

1年間の軌跡

ここでは、一年間の出来事や成果物に沿って学習成果を記してゆきます。

4~7月事前学習

はじめの数ヶ月間は、簡単なグループワーク演習や、アジャイル・スクラムの概念・フローの基礎学習をはさみつつ、各々が自由に決めた自主学習を行います。
自主学習にて私が挑戦したのはchromeの拡張機能開発です。
具体的には、scrapboxという情報集約のためのwebアプリにてMarkdown記法をサポートする為のもの。
当時まだweb技術に触れたことがなかったどころかまともな開発をしたこともなかった私にはこの課題は大きすぎ、残念ながらリリースまでには至りませんでした。
しかしここでJavaScriptをはじめとした各種技術や、webフロントの様々な概念・インフラについて学ぶこととなります。

7月チーム"爆音マスターズ" プロダクト"おみせきめーる"

事前学習期間のあとは、1巡目のチーム開発が始まります。
7月の前半にテーマとチーム決定をしたらテーマを深掘りする期間があり、その後"夏合宿"と呼ばれる、6日間の集中開発期間を迎えます。
夏合宿は、1日が8:40開始18:00修了で、実際に泊まったりはしません。
我々は4人チーム"爆音マスターズ"で、おみせきめーるをつくりました。

おみせきめーる

おみせきめーる は
出先など知らない場所で食事するお店を決めるのが手間であるという課題 を解決する
その場で今すぐお店を決めたいグループ 向けのWebアプリ
1つの端末で全員の意見を反映した条件指定を行い、その結果に基づいてちょうどいい店を推定して、1つ店を提示すること によって
なんか違うなと感じないお店の手早い提案 を実現

簡単に言うと、グループで飲食店を探そうというときに、メンバー条件を指定し、最適なお店を最速で一つ提示してくれるというプロダクトです。

運用費等の関係上残念ながら現在はサービス終了しています。

チーム

私 PO
MRI氏 ScM
MTN氏
ISGR氏

私以外全員が院生(マスター)、MRI氏の趣味がK-popを爆音で聞くことだったので、チーム名"爆音マスターズ"です。
開発技術力としては、ISGR氏が強く、MTN氏がそれに続き、私とMRI氏は素人といった感じ。

学び

テーマ決定から深掘りまでは、はじめてのアジャイルとプロダクト計画手順に慣れないながらも順調に方針を定めていくことができました。
夏合宿1日目、React.jsを使用する事が決定し、MTN氏主導で環境構築、deployまで完了。
ここで、プロダクトとしての第一の価値"プロダクト名がわかる"PBIを達成、リリースします。
ここからは怒涛の5日間です。

スプリントを回していく中で、常にプロダクトを活用してもらえるようにしようと意識しました。
"おみせきめーる"は飲食店推薦アプリなので、毎日のお昼休み時間に他の参加者や運営チームに利用してもらい、レビューを受け、これを基準に開発を進めるといった形です。
この方針を特に押していたのはMTN氏です。
このときは私はこの方針に懐疑的で、昼休みを意識するせいで余計に開発時間がかかり、プロダクトの最終的な理想形になかなか近づかないことに苛立っていました。
しかし、これは根本的に間違っていたようです。
そもそも、プロダクトの最終的な理想形というもの自体がフィクションであり、己の頭の中で作り上げた妄想にすぎません。
それをフィードバックにより矯正し軌道修正を行いながらプロダクトを良くしてゆくのがアジャイルでありスクラムです。
チームで理想形を共有し、外部からの刺激(フィードバック)によってそれを練り直してこそチーム開発の真価が発揮されるのだと今ならわかります。

とはいえ夏合宿は6日間しかありません。
チーム開発の質と開発スピードのトレードオフ構造は常に付きまとう問題です。
ここで問題となったのが、私とMRI氏の技術不足です。
はじめはペアプロを実施して技術事項を共有し、コードが属人化してしまうことを防いでいました。
しかし、これではどうしても2人が足を引っ張るような構図ができあがってしまいます。
後半からは役割分担を設ける体制に分け、結果的に生産性を高めることに繋がりました。
私とMRI氏もできることだけをこなします。
思えば組織というのは多様な人が短所を補い合う事ができるというのがメリットの一つです。
チーム開発においても、徹底的に役割分担をすべし、ただし各々がやっていることの把握・共有は徹底し、また技術事項においても負の遺産を作り出してしまうことは避ける、これが正しいあり方だろうと学ぶこととなりました。

6日目は、夏合宿の成果を発表する日です。
プレゼンテーションの後、デモ発表を行います。
短い期間でもなんとか自分たちのテーマを形にすることができ、胸を張ってそれを紹介し、晴れ晴れとした気分でenPiTの前半を終えました。

出会ってからわずか1ヶ月間、日数にして10日ほどしか会っていない爆音マスターズの3人とは、色々な壁を我武者羅に乗り越えてゆく中で、なんとも言い難い絆を築くことができました。
休み時間中に、MRI氏が気分転換にと持ってきたボールで遊んでいたら学内の池に落としてしまったのを大変微笑ましく思い出します。
チーム開発のなんたるかを学び、技術以上に大きな財産を獲得してenPiTは後半戦へ続きます。

10~1月チーム"雑談推奨審議会" プロダクト"e-talk support"

夏合宿で1回目のプロダクト開発を終え、しばしの休暇期間を経たのち2回目のプロダクト開発が始まります。
ペースとしては、週に2日、1日3時間弱です。
つまり1スプリントが3時間弱、とても短いです。
ここからは一部が抜ける関係上チームを再編成し、夏までに作ったものを引き続き継続する継続組と、新規テーマでいちからはじめる新規組に別れます。
爆音マスターズは、私以外の3人全員夏までの履修だったためここでお別れ。
1人抜けたチームに入れ替わりで入れてもらい、完全に新しい課題で再出発です。
5人チーム"雑談推奨審議会"で、e-talk supportをつくりました。

e-talk support

e-talk support は
雑談が苦手だという課題 を解決したい
オンラインで会話する人向け のWebアプリ
事前に話題の種を共有 することで
参加者がネタ切れすることなく安心して会話に望める

e-talk supportは、オンラインでの懇親会や、新歓といった雑談の場を想定してあります。
そういったオンラインMTGのホストが"メンバールーム"を作成して、事前にそのURLを参加者に共有します。
各参加者はメンバールームに集い、プロフィールカードの共有を行います。
それぞれのプロフィールカードの項目には"きになるボタン"があって、それを押すことで他の参加者のプロフィールで気になる項目にリアクションできます。
皆がどういったことに興味があるかを知ることで、オンライン雑談の場で気まずい沈黙を作ること無く、会話を広げることができるというわけです。

チーム

KSM氏 PO
MTD氏 ScM(新)
私 ScM(旧)
TIYK氏
MKY氏

"雑談が苦手"という課題を解決するための"雑談推奨審議会"です。
開発技術力としては、全員素人なのですが、私とTIYK氏は辛うじて経験ありという感じでした。

学び

前半にチームマネジメントの大切さを身に沁みて感じた私は、ScMに立候補し意気揚々でした。
e-talk supportはおみせきめーると同じReact.jsを用いており、他に経験者もいなかったもので、私がテックリード的な立ち位置とScMを兼任する状態が暫く続きます。
はじめはチームの話し合いでホストのような立ち位置になれるよう努めたり、カンバンを如何にうまく使うかを考えたり、チームの心理的安全性を上げるために休み時間を有効活用しようとしたりご飯に誘ったりと色んな試行錯誤をしました。
しかしこの両立はなかなかうまく行かず、段々と息切れを自覚するようになります。
12月の頭頃だった気がしますが、この日もいまいちスクラムを改善できず、なんとか役割分担を済ませたあと各々が作業を始めました、私が開発で頭を悩ませていたところ、先に作業を終えたチームメンバーが次に何をすべきかと問いかけてきました。
私は中途半端に立ち回ったばかりに、実質的なリーダーのようになってしまっていたのでした。
開発に集中すべきなのにチームの方向性も同時に決めなければならない、どうして良いか分からず文字通り頭を抱えてしまいました。
どうすべきか途方に暮れた末至った解決策は、ScMを移譲するということでした。
これはMTD氏が快く引き受けてくれました。
また、このときにPO・ScMの役割やスクラムの手法について再確認する時間を設けました。

チーム再編を期に、色々なことがうまくいくようになりました。
新ScMのMTD氏はカンバンを一新して使いやすくしてくれたり、話し合いが脇道にそれたり煮詰まったときに指摘してくれるように。
チームの対外的なこともPOのKSM氏が引き受けてくれるようになり、私はTIYK氏、MKY氏と共に開発に集中できる様になりました。

1/19にいよいよenPiTプログラム最後となる成果発表会を迎えました。
じつは同じプログラムを琉球大学でも行っていて、そちらと合同での発表会です。
発表時間は僅か5分ですが、万全な準備と役割分担により我々の成果を最大限に表明することができました。
ブースを作って自由に廻ってきた観覧車にデモをする時間もあり、そこではさり気なくe-talk supportを活用したデモを行いました。
成果発表会では、教員の評価及び参加者全体による投票によって、18チームの中から最優秀賞と優秀賞が6チーム選ばれます。
我々雑談推奨審議会は光栄なことに優秀賞を頂き、達成感に満たされてこのプログラムを終えることができました。

全体をふりかえって

一年間を通して様々なことを経験しました。
しかし、アジャイルによるチーム開発において、真に重要なことは常に以下の2つだと思います。

プロダクトの価値を一番に考える
常に現状を疑い、変化し続ける
1つ目が目的で、2つ目がそれを達成する為の手段です。

"プロダクトの価値を一番に考える"は、言葉どおりです。
フィードバックを大切にする、PBIベースで開発を進める、プロダクトは常に最新の状態を保つ、こういった営為は、全てプロダクトの価値を最大化せんがためにあります。
プロダクト開発なんだから当たり前なわけですが、開発に集中していると案外見失いがちです。
開発がうまく立ち行かないとき、それは方向性が明確でないからかもしれません。
こういったときに、目的を明確にすることさえできれば、解決策は自ずと見えてくることでしょう。

"常に現状を疑い、変化し続ける"は、アジャイルの真髄です。
スプリント毎にPBLを見直す、役割分担を見直す、意見を臆さず表明する、といったことは、全てがアジャイルプロセスの改善に繋がります。
プロダクトを長期に渡って制作するに当たって、変化の時期、安定した時期と両方生まれることでしょう。
しかし、現状を疑い、"プロダクトの価値を一番に考える"ための改善策がどこかに無いかということは、常に考えてゆく必要があります。

今後の話

雑談推奨審議会で函館遠征にゆくことになりました。
はこだて未来大学で開催されるenPiT2 BizSysD 分野ワークショップ 2024にて、enPiTでの成果発表を行います。
只今発表を練っている真っ最中です。
まだ見ぬ猛者たちとの出会いに刺激を受けることを想像すると胸が高鳴りますね。
北海道、寒いだろうな。

おわりに

勢いで参加を決めたenPiTプログラム、ここまで実りある経験を得られるとは思っても見ませんでした。
チームで、プロダクトを作る というのがどういうことかを理解し、様々な新しい価値観を得ることとなりました。
このような素晴らしい場を提供してくださったkwgt先生をはじめ、先生方や講師の皆さん、メンターの皆さん、同期のみんな、そして何より私とチームを組んでくれた7人に多大なる感謝を申し上げます。
本当にありがとうございます!