支えたかもしれないし支えていないかもしれません
この記事は 公立はこだて未来大学 Advent Calendar 2024 Part2 18日目の記事 兼 力強くブログを108記事アウトプットする日の 20241229 の Yourein 1記事目です。本当はアイドルとの直メの話を書きたかったのですが…
一応下にアイドルとの直メの伏線回収も兼ねて少し書こうと思います。
CHAIN
アイドルマスター シャイニーカラーズ Song for Prismというゲームを知っていますか?
当然ご存知ですよね。説明の手間が省けてありがたいです。
CHAINって、あるじゃないですか。
実在性を、感じたくて。
それで、俺…
(適当に画像回転したら壊れてておもろい)
迷子コンパス
っていうのを作ってたんですよね。
作ったものは迷子コンパスという、目的地までの距離と方角がウェアラブルデバイスに出現するというアプリケーションです。それだけではなく、周辺の同じアプリケーションを使っている人が投稿したスポットがウェアラブルデバイスに表示されるというものです。
図5を赤い矢印が目的地の方向、そして矢印を選択すると距離がでます。現在は目的地ではないおすすめされたスポットを選択しているので、その距離とどんなおすすめスポットかの文章や画像が表示されるものになっています。
まあコンパスです。
説明が面倒だったので引用してきましたよ。
公立はこだて未来大学のプロジェクト学習 (正式名称はシステム情報科学実習)というやつでこういうもんを作りまして、その話を書こうと思います。ちなみにサーバーサイドとフロントエンドのrepoがありますが、フロントエンド側はpublicなのでリンクを貼っておきますね。
開発体制の話
スマートフォンとスマートウォッチが連携するタイプのアプリになっていまして、2つのアプリを作成する必要があります。で、開発を始める前は「まあ適当に3人くらいで作るんだろうな」と思っていたんですが、結果として自分含めて6人で作ることになりました。
…いや多くね？
そう、人が多いのです。じゃあその6人(5人)を誰が動かすのかというと、それが自分です。どうなってるんだまじで
その5人がどんな感じなのかと言うと、2人くらいはAndroidアプリをいじったことがあって、3人は(ほぼ)未経験という感じでした。一応Googleの提供しているcodelabとかやってもらってましたが、あれで学習してうまくOnboardingできた人を見たことがないので多分意味なかったと思います。
じゃあ実際どういう風に自分が動いていたのかと言うと、フロントエンド側のメンターとして動きながら自分の開発タスクを片付け、全体の進捗管理をしながらバックエンド側の開発チームとの窓口になる(例えばAPI仕様を決めるとか、詳細なインターフェースの要件を決めるとか)という動き方をしていました。ん、これテックリードってよりかはプロマネか？
実際の開発の進め方としてはゆるいスクラムのような感じで、1週間に1回、10分くらいを使って各自のタスクを確認数時間を設けました。
スクラムといえば、HAKODATE DEEP WESTというチームはガチガチのスクラムを組んで動いていて、毎日デイリースクラムをやってたみたいで、Agile Japan 2024にも登壇していたらしいです
さっき初めて登壇資料を見たんですが、確かに自分も「あそこのチームは授業時間外もコミットしててすげー」と思っていました。と言っても自分の知り合いが「今日はなにもしてませんでした」と報告するとこを無限回見ましたが。
自分のチームでこういうスクラムをやらなかったのは、タスクに対するイテレーションの回りづらさが理由でした。例えば、XやYoutubeのタイムラインのような一番下まで到達したら追加でページングが発生して新たな要素がUIに追加されるという画面を一つ作るために、大抵は1〜1.5日くらいの見積もりをするかなと思います。(APIを叩くコードとか、データはすでに揃ってる前提でUIだけ作ることを考えたらですが)
しかし、こういう画面仕様は初心者からするとどういう方針で進めればよいのか、UIをどのように構築すれば良いのか、データをどうやってUI層に持ってくれば良いのかなど、悩むところが多いです。したがって、タスク完了までかかる時間はある程度の経験者と初心者の間で指数時間レベルで離れ、タスクが蒸発してしまうことも可能性として考えられます。そう考えると、デイリースクラムのような毎日それぞれがある程度のコミットメントをし、次にやるタスクを自分でアサインし…というタスクレベルでの細かなイテレーションをどんどん回していく進め方をするのはあまりにも無謀な考えと言えるでしょう。そういう理由から、このチームではデイリースクラムを採用するのを取りやめました。まあ、あと、採用したところで授業時間外にコミットメントしてくるやつなんていないだろうし、デイリーで進捗共有しても僕が「じゃあ各自進捗共有お願いします………えっと、誰もない感じでいいですかね？それなら今日も解散にしますけど」と毎日発言することになるだろうなという考えもありました。
とはいえ、タスク管理自体は結構ちゃんとやっていて、Github Projectsを用いてフロントエンドとバックエンド両方のタスクをタスクカンバンにし、各自のタスクは見れるようになってはいました。
ウィークリーの進捗共有のときは個人ごとのタスクが見れるように組んだタスクボードを見ながら「完了したタスクはこれで〜」みたいなことをやっていく感じだったわけですね。
で、Github Projectsってタスク管理の外部連携がめっちゃ弱いんですよね。Notionとかだと、結構外部連携が強くていろいろできるイメージがありますが、 Github Projectsはまじでなにもできないので、自分でGithub Projectsに新規タスクが生えたらSlackに通知してくるようなBotを作成して運用していました。
その話は適当に下のスライドでも見てね
開発の進め方
最終的なコミットグラフはこんな感じになりましたね。
実際に開発を始めたのが10月の第一週くらいでして、自分がその周辺で鬼のように基礎工事をしているのがわかりますね
アプリの構成はゴリゴリにモダンな形になっていてマルチモジュール構成です。単にモダンにしたかったというよりも、スマホ側とウォッチ側で同じリソースを参照するような場面が多く、いい感じにモジュールを分けたほうが合理的かなと思っていました。実際チームメンバーにマルチモジュールの話とかほとんどしてないのであんまりわかってなかっただろうなと思いますが。
最終的には1人1画面くらいは作ってもらった気がするのですが、このときの開発の流れは、基本的には自分がタスクを人に振り、PRを出してもらって自分がレビューを挟み、開発ブランチにマージするという流れでした。まあ普通のやつですね。
タスクの割り振りも基本的に自分で、「うーんこれくらいのタスクだったらリードタイムがこれくらいに収まるかな〜」というタスクを人に投げるという感じでした。 経験者二人には結構重めのタスクを投げることが多く、経験がない人にはとりあえず小さな画面パーツを作ってもらって少しずつ進めていくという形を取りました。
技術習得を自走するための力を吸い取りたかったという話
技術力がないんです。思いつきでモノを作るので、その場限りの技術力しかない。地に足のつけた技術習得がしてみたかったんですよね。今回の技術リーダーは、それを実現させてくれたと言っても過言ではなく、現在未踏で行っているプロジェクトにもとんでもなく加速をもたらしました。ありがとうございます
それは良かった。パン屋さんには超絶重いタスクを投げたので、なにか得られたものがあったのか心配だったのですがまあ本人が良いと思っているなら良かったです。
コードレビューの話
コードレビューをね。全部やってたんですよ。フロントエンド側のね。
まあそれはいろいろな味を持ったコードを見ましたが、みんなそこそこ方向性は悪くないコードをPRにしてくれていたので良かったと思います。
が、それはそれとしてフォーマットがやばかったので、途中でgradleの警告とslack-compose-lintsを入れました。人間がいちいちフォーマットを確認したり、「あ、ViewModelを末端のComposableに渡すのはやめてね〜」とコメントするのは不毛なので。
本当はktlintとかもセットアップしたかったんですが、あまり手が回らずできませんでした。
自分のやったこと
まあいろいろやりました。実はDIが動いてて、Android StudioからBuild Variantを切り替えるだけで本番サーバーにつながるアプリとモックデータが注入されるアプリの2つをビルドすることができます。そういうのを作ったので、Repository層のinterfaceなどの定義は大体自分がやりました。あとモジュール作る作業とか。いい忘れてたかもしれませんが、MVVMです。
実は自分はプロジェクトリーダーではなくて、リーダーはさっきからちょくちょく記事を引用しているパン屋さんなんですよね。自分は技術方面や開発のスケジュールに関して責任を持っているという感じです。
で、そのパン屋さんからちょくちょく過労を心配されましたが、別にタスク量的な話をするとめちゃくちゃ多いわけではなかったと思います。もちろんレビュー + メンタリング + 自分の実装という感じではありましたが、そもそもこのアプリを基礎工事をしたのは自分なので、大抵のことはわかります。「〇〇って色の定義がないんだけど…」みたいなことを言われたら、「ああ××のモジュールがimportされてないからimportして」くらいはコードを見なくても言えますし、メンバーが引っかかるところといえば大抵初心者が引っかかる穴にまんまと引っかかったくらいだったのでそこまでメンタリングの難易度は高くなかったですね。
あと、その関連で言うとメンバーがそこそこ自力で走ってくれたのもあります。多分自分がレビューしたコードの何割かはChatGPTが書いたコードだったと思うのですが、ある程度は自分でコード読んでくれてましたし。
そもそも、自分もB1の頃にJetpack Composeを初めて書きましたが、ほんとに何もわからないんですよね。State hoistingって何とか。ViewModelって何みたいな。remember { mutableStateOf() } って何みたいな。その状態からよく今の状態になったなと思いますが、最初は本当に何もわからない状態が長く、メンバーもそういう状態だったと思います。その状態でよく走ろうとしてくれたなと、個人的には評価しています。
なんか超上から目線で気持ち悪いですね。そろそろやめましょうか。
反省
自分が結構とんちんかんなことを言った場面が多くてなんだかな〜っていうのが多かったんですよね。「よくよく考えたらこの指摘のまま進めたら実装キツイわ。ごめん」みたいな。
あとmodule構成もあんまり良くなかったんですよね。module構成と言うか、ナビゲーションの置き方みたいな。
Navigationをするモジュールって基本的にすべてのfeatureモジュールに依存することになりますが、なぜか開発を始めた当時、Navigation用のコードとNavHostを別モジュールに置くということをしてしまって(してしまってというか、人に聞かれて、「まあいいんじゃない？」って言っただけなんですが)、Navigationモジュールとappモジュール(Androidのプロジェクトを作ったら自動でできるあのコード郡)がすべてのfeatureモジュールに依存するという構成になってしまいました。本当はappモジュールがNavigationモジュールに依存して、Navigationモジュールがfeatureモジュールに依存するという構成になるのがいいかなと思っているのですが、これはいまだに直していません。
あといろいろ細かい反省点ありますが、ここでは省くことにします。
今後
知りません。
まあどうせ継続開発しないだろうし別に放っておいていいか。
迷いのデザインって来年どうなるんですかね。まあ来年には消えてるんじゃないかなと思うんですけど。