プリントシール機のソフトウェア開発を行っております高松です。
本記事では、プリントシール機の開発において、
ソフトウェア開発のソフトチーム（=エンジニアチーム）リーダーとして、実際に意識してみたことを紹介していきます。
チーム運営として何かしらの参考になれば幸いです🌞
- はじめに ～開発体制について～
- 意識したこと①「商品コンセプトに全員で向き合う場をつくる」
- 意識したこと②「定例で設計検討をソフトメンバー全員で行う」
- 意識したこと③「能動的に動く（待たないソフトウェア開発）」
- おわりに
はじめに ～開発体制について～
まず、プリントシール機を開発するソフトチームについてですが、
人数は開発ボリュームによってブレはあるのですが基本的には少人数構成となっています。
具体的に説明すると、プリントシール機のソフトウェア開発として、担当を大きくわけると
「ゲーム」、「落書き」、「画像処理」の3つで構成されています。
※工数確保が難しい時期などは、サポートメンバーからのヘルプを受けて進めています。
新機種においてはゲーム面だけでなくハードウェア面においても新規要素が多い傾向にあり、
検証、実装、テスト工数を考慮すると、人数構成は少なめになっているかと思います。
ただ、それを理由に商品のクオリティは諦めたくありません。
限られた条件下で高クオリティの商品を作り上げるために
2023年春の新機種 IDOLY studio、2024年春の新機種piemoのソフトウェア開発にて、
特に意識しました3項目を、以下で詳しく説明していきます！
意識したこと①「商品コンセプトに全員で向き合う場をつくる」
すべての商品に対してコンセプトシートという、その商品が目指す姿などが示された商品開発の柱となる資料があります。
もともとは、資料に対しては各々が任意のタイミングで目を通したり、説明を受けるだけがほとんどでした。
そんな中、デザインチームがコンセプトシートを元に、デザインコンセプトを決めて開発に取り組んでいることを知り、
「なぜソフトチームはやらなかったんだろう、ソフトチームもコンセプトシートを読んで何を頑張るのか初めに考えるのもよいのでは！」と考え、最初の取り組みとして「ソフトチーム全員でコンセプトシートの読み合わせをする場」を設けました。
デザインチームとソフトチームで商品に対する関わり方は異なるため、読み合わせた結果の帰着点は見つけきれていません。
…が、これからつくる商品が目指す姿について対話することで、商品開発チームへの帰属意識が高まり、
また、商品開発の柱を理解することで、ブレづらい開発につながるといったメリットは感じています。
意識したこと②「定例で設計検討をソフトメンバー全員で行う」
コンセプトについて理解したあとに行うのがどう実現するかの検討です。
コンセプトシートには、目指す姿をかなえるために搭載したいウリ機能についてある程度書かれています。
その内容からソフトチームがやることを抽出し、優先順位をたてて検討作業を進めていきます。
例）IDOLY studio ：撮影クリエイトコンテンツ、女神フィルター
piemo ：全身撮影、全身レタッチ、背景選択
ポイントとしては「定例であること」と、「ソフトメンバー全員で行うこと」の2点です。
a) 定例であることの目的、効果
下記があると考えています。
- 検討したい内容が発生したときに整合の場の予定をおさえる手間を削減
- 個々の宿題がある場合、定例の場が納期になるため、アレどうなった？を軽減
- 習慣づけることで設計を当たり前化する（あわよくば設計力向上）
特に1点目は大きく、時間が足りなくなった場合に来週話しましょう、ができたり
今週はこの件を話して、来週はこの件を話しましょう、など次回予告も可能となり計画性が上がりました。
b) ソフトメンバー全員で行うことの目的、効果
下記があると考えています。
- 「この機能は○○担当だけと思ったら△△担当にも影響した」など、影響範囲の見積もりミスによるロス対策
- 担当を超えた技術知見共有とそれによる工数削減（ゲーム画面にいれる機能だけど過去に落書きでこういう風に実装していたから参考になるかも！など）
- 全員で検討することで、全員が機能に対してすこしずつ責任をもつこととなり、「この新機能は○○さん担当なので○○さん以外よく知らない」といった属人化現象をなくす
自分の頭の中ではやはり限界があるため、チームワーク力を用いて開発力向上に繋げます！
最終形態として、定期的に全員で協力する流れに慣れ、
各人が気兼ねなく開発メンバーに相談できるようになれば 最強のチーム になると考えています！
補足ですが、開発が進むと設計検討する内容はなくなっていきます。
その際は ゲーム性に関するブラッシュアップや課題解決に向けたブレストを行う場にしたり、会議をなくし実装時間に割り当てています。
意識したこと③「能動的に動く（待たないソフトウェア開発）」
開発期間が限られていることから、新規要素や難しい要素については早くに仕様を確定できるようにし、
後半はブラッシュアップや商品リリースに向けたその他の必要な機能に集中する期間に当てたいと考えています。
なので、とにかくスピードが勝負と考えています。
待っている時間をできるだけなくすために、ガンガン要求仕様についてソフトメンバーから企画メンバーに聞いていきます。
聞く際のポイントとしては、仕様は減ることよりも増えることのほうがインパクトが大きいので
最初の段階で聞く場合にはMAXの仕様でヒアリングを行います。
それでも途中で新要素が生まれることもありますが、できてきたからこそ見えることもあるので前向きにとらえます。
（ここの考え方は人それぞれで特に正解はありません。）
また、要求に対してソフト側で都合がいい仕様があれば逆提案もガンガン行います。
機能の目的を理解していれば、また、理解した複数人で対話した結論であれば、ローリスクハイリターンな提案もできるのかなと考えています。
おわりに
少人数で新機種のソフトウェア開発を乗り切るために心がけたことを記載しました。
こちらの方法でIDOLY studioやpiemoは安定したソフトウェア開発をすすめることができました。
ただ、ここまで書いてではあるのですが、自分的には「こうしたら必ず失敗する」はあっても
「こうしたら必ずうまく行く！」といったものがあるのか、まだつかめていません。
上記方法がうまく実行できた要因として、例えば下記の環境も影響していると感じています。
- 経験値の高いソフトメンバーが多く、ソフトウェア開発のスタイルも一致した。（スピード実装タイプ）
- 本当に少人数だった（人数が増えると逆に全員で検討する難易度が上がると感じています）
- ソフトウェア開発スケジュールにある程度のバッファがあった
- ソフトメンバーだけでなく、商品開発チーム全体としてのチームワーク力が高かった
環境というものは変化していくものなので、現状にあわせて良い方法をアップデートできたらなと思います。
最後までお読みいただきありがとうございました！
