ゴミ箱センサーとアジャイル開発
はじめに
株式会社DELTA エンジニアの長田(おさだ)です。
現在、オフィスでゴミ箱センサーを制作していて『これがアジャイル開発なのか』という腹落ち とともに今後の開発の参考にできそうだな。と感じることがあったので経緯を記事にしたいと思います。
今回は主に開発スタイルを主軸に書きたいと思います。本文中にも出てきますが、Raspberry Pi Picoと超音波センサーを使用したセンサーを作成しましたが、技術に関する内容は別にまとめたいと思っています。
SEVENRICH GROUP
株式会社DELTAは、ベンチャースタートアップなどの成長企業向けに、ソフトウェア・プロダクト開発や技術選定支援などの技術支援事業を提供しています。また、成長企業向けに様々な事業支援を提供するSEVENRICH GROUPに属して、グループ内の事業会社や、出資先の支援もおこなっています。
SEVENRICH GROUPとは?
昨年 SEVENRICH GROUP は渋谷の桜丘に移転して、今は新しいオフィスです。
SEVENRICH GROUPが、“熱狂・競争・コラボレーション”をコンセプトに掲げた新オフィスへ移転しました!
中が見えないゴミ箱
移転の際にソファやテーブル・冷蔵庫等も検討に検討を重ねて準備をしたと伺っています。
そんなオフィスの家具ですが、ゴミ箱の外側から中のゴミが見えない形状になっています。
そのため、内側に設置してあるゴミ箱からゴミが溢れても気が付かず。どんどんゴミを捨ててしまうという状況です。賀来賢人似のイケメンさんがゴミ箱警察として、たまにチェックしていますが溢れてしまうことがあります。
ゴミ箱センサー開発
現時点での成果物は『超音波センサーで距離を計測、計測結果によってLED点灯』する。という機能に絞ったものになっています。
ゴミ箱にセンサーを設置したら便利そう。と思いたって制作に着手(2023/01/20頃)したときは『ゴミがMAXラインを超えたらRaspberry PiでSlack通知』する機能を考えていましたが、私にとっては色々と難しい部分も多く道半ばです。
大反響
そんな機能を絞った状態でも実際にゴミ箱へ設置してみると社内から想定以上の反響があり、これってアジャイル開発に通ずるのでは?となりました。(社内全体へのつぶやきが投稿できるSlackチャンネルで、つぶやきに対するスタンプを45個もらいました。普段はだいたい20前後が多い)
具体的な課題(2023/02/06)
反響はあったのですが、課題山積です。
- コードの取り回しが汚い
- 全ての回路をハンダ付けしてしまったのでプログラム書き換え時に全てゴミ箱から外す必要がある
- ゴミ箱の傾斜によってセンサー位置が安定しない(センサー位置を決めきれていなかった)
- ゴミの量によってLEDを消灯→緑→黄色→赤と変えたい
- ゴミ箱は何個もあるけど、全てに設置するのか
コードが丸出しでせっかくのゴミ箱のデザインが台無しです
現状では赤く光るだけになっています
そのほか開発時の困った点
-
Raspberry Piが分からない
いくつかのモデルがあり、Wi-Fi機能付きや大きさ。picoに至っては言語がMicroPythonになっていたりと、何を選択してどの記事を参考にすれば良いのか分からず色々と手探りでした。
まずはチーム内の山田さんにModel B+やzeroをお借りして初期制作を開始、実用化にはモデルをpicoに変更して制作。となっています。 -
Raspberry Piがない
新しいモデルはどこも完売していて、Amazonさんでもプレミア価格になっています。
この辺りの調査段階から先行きも心配になりSlack通知面倒そうだな。となっていました。 -
パーツを揃えるのに時間がかかる
当然、電子工作のパーツがコンビニで買えるわけもなく。近所にもそのような店舗がないため、ネット注文になるのですが「何が足りない?」「どの規格が必要?」「これも必要だった」といった感じで時間がかかりました。
といった具合でした。
アジャイル開発
アジャイル開発とは?
アジャイル開発の説明については割愛しますが、下記のリンクを載せておきます。
開発はスケートボードから
課題山積の成果物ではありつつも反響をいただけたのはスケードボードを作ることができた結果だと考えています。
最も重要な課題を見極めて、それを解決する機能を提供することで、機能が小さく不足していてもユーザーからの反響を得ることができる。ということを体験できました。
課題は解決されるけど、それ以外が不便という状態がスケートボードなんですね。
出典:Making sense of MVP (Minimum Viable Product) - and why I prefer Earliest Testable/Usable/Lovable
まとめ
今回はソースコードの修正以外にもパーツの準備や配線と基盤を収納するケースの作成にも時間を費やしていたので 『ゴミが溢れる』ことを最重要な課題と仮定して、『ゴミが溢れたのが分かる』という機能だけに絞って提供しました。(ゴミ箱の外観維持や機能の拡張性は対応できていません)
例えば、外観を綺麗にするためにパーツを選んで、追加注文して、制作、となるとあっという間に5日程度は溶けてしまいます。
これから外観の調整や拡張性向上・便利機能追加が完了するたびに評価してもらいながら車まで仕上げていく。そのような過程がアジャイル開発になっていくものなんだと考えています。
アジャイル開発を意識してみて
-
対話をしてもすれ違うことはある
今回は運良く反響が得られたので、良い成功体験になりました。
ですが今回のように「社内の便利アイテム」ではなく業務上の利害関係がある場合、『反響=良い評価』とは限りません。まずは評価指標について対話することが重要です。 -
ちゃんと動くものを
個人で制作している社内の便利アイテムなので、今はドキュメントは作成していません。ですが、もしアサインされるようなことがあればドキュメントも作成します。 -
協調とは、利害の対立する者同士が穏やかに相互間の問題を解決しようとすること
逆に機能が刺さらず反響がなかった場合(協調できていなかった場合)
価値と解決する機能の仮説が外れることもあります。その場合には改めて対話から課題の精査と解決できる機能を再検討する必要があります。 -
変化への対応は宣言に定義されている
最初期の機能は評価されたものの、開発が進むにつれて求められているものが変わっていく場合。
原因は色々と想像できますが、最初期の課題が解決されたために他の課題が目に付くようになり、迷走してしまう姿が思い浮かびます。
評価が得られなくなってきた場合には、評価が得られていたときの課題と機能を振り返って軌道修正(または課題を再認識させて軌道修正しない)をする必要や、なぜ課題が変わったのかを調査する必要があります。
とはいえ、まだ走り始めたばかりのため、どのように着地するのか見えていません。機会があれば、この後日談も記事にしたいと思います。
開発の現場ではありふれた話なのかもしれませんが、アジャイル開発について腹落ちしたので記事にさせていただきました。
We're Hiring!
最後までお読みくださり、ありがとうございます。
現在 株式会社DELTA では様々な形で一緒に働く仲間を募集中です。
そんな方はぜひこちらから、お気軽にご連絡ください!
Discussion