スケジュールってどうやって立ててますか？

こんばんは！株式会社スマレジ、開発部のmasaです。

更新が空いてしまい申し訳ないです！今年は更新間隔が少し開いてしまうかもしれません。

GWは皆さんどんなふうに過ごされましたか？ masaは振替で出勤している日も何日か会ったのですが、最終日に葛城山に登ってきました。（登山いく暇があるならブログ更新しろよ！ってツッコミはなしでお願いします汗）この山、山頂につつじ園があることで有名なのですがmasaが登った時は8分咲きぐらいでした。それでも、山の一部が真っ赤に染まったように見えて圧巻でした！

葛城山の詳しい情報はyamapから！↓

yamap.com

さて、今日はスケジューリングのお話です。

スケジュールの立て方

SaaSはサービスの性質上、定期的にマイナーアップデート + バグ修正のメンテナンスアップデートをして、何年かに一回メジャーアップデートをする形になることが多いかと思うんですが、今回はマイナーアップデートのバージョンアップをするときのスケジュールのお話です。

なお、ここではQAスケジュールなどの調整など、他部署・他チームが関係する部分の話は割愛しています。ご了承ください。

メイン機能の工数を出す

スマレジ POSの場合そのアップデートの性質にもよるのですが、大体マイナーアップデートは目玉になる機能の追加（最近だと、削除済み取引閲覧機能とかがそれ）があって、そこが一番工数が大きくなるので、その部分の工数出しからやっていきます。

メイン機能の規模にもよりますが、基本的には設計(SIerでいうところのUI/SS工程くらいまでの作業）をこの段階で行います。そう聞くと、「要件定義段階である程度工数出さないの？」とSIerの方は思われるかもしれないんですが、ざっくりとは出してます。（ここでの工数出しや要件期日の調整は開発部幹部+営業で調整することが多いです。）

ただスマレジPOSの場合、すでにたくさん要望をいただいていて、かつ要望自体の精査がPJ開始前に進んでいることが多いので、要件を固める作業はそこまで大きくなくて、要件はある程度決まった状態で開発部でのバージョン作業が開始することが多いです。

そのため開発部での設計のお仕事は既存機能に違和感なく要件を満たす機能をデザインするところがメインになります。

メイン機能の実装・テスト工数算出

メイン機能の実装・テスト工数の算出は設計をFixさせてから算出します。実装工数が予め入れられているので設計が膨らんだのに工数調整できず実装工程で炎上・・・みたいなことが前職のSIerだとよくあったんですが、それはほぼないです。（優先度の高い法令対応などが差込タスクが入ったりすると、他のPJ工数が圧迫されることはありますが・・・。特に税法系の対応はもうちょっと公知と施行の間隔を開けて欲しい。多分他のレジ会社も同じこと思ってるはず。）

お客様に出す設計書を作ると言うわけではないので、SIerの方が想像しているエクセルの設計書よりもかなり簡素です。要はメンバーが共通認識を取れる精度で作るのが大事なので、記載の粒度なども自分たちで自由に決められます。このあたりがSaaSの強いところだと個人的に思っています。

masaがやるときは、

タスクの洗い出し
- スプレッドシートに書き出していきます。ある程度出したら用件の依頼者（営業さんとか）に共有して機能レベルで漏れがないかを確認していきます。
ガントチャートにタスクを書いていく
- masaがよく使っているテンプレートです。スプシのガントチャートだと大体これがデフォルトなんかなと思ってます。
- ここの「タスクのタイトル」に洗い出したタスクを転記していきます。
- タスク間の依存度が高い時はアローダイヤグラムを書くこともあります。
  - products.sint.co.jp
タスクの詳細（UI/SS)を詰めていく
- いわゆる設計作業です。どうやって実現するのかを文書にしていきます。
工数を入れていく。
- ガントチャートのテンプレートをちょっといじって工数を入れるようにしています。単位は人時です。
- リリース日から逆算して工数入れる方が、精度が高くなる気がしています。特に後半になればなるほど、他部署（営業・QAチーム・インフラチームなど）との調整が必要な分、工数がある程度決まってくるので。
開始日と終了日を入れる
- 入れた工数をもとに開始日と終了日を入れていきます。
- masaの場合、工数をマシマシで最初出すので、大体そのままだとはまってくれないので、工数を調整しつつ入れていきます。
メンバーに共有
- 自分以外にもメンバーに手伝ってもらう場合や、バージョン作業全体のスケジューリングの時はこの段階でメンバーに共有します。
- この時チーム内で設計レビューをやることが多いです。
設計レビュー
- 上司による設計レビューです。機能のインパクトに応じて営業やCSが入る場合もあります。
設計書をチケットに変換
- レビューが通ればガントチャートをもとにredmineにチケットを作っていきます。
- まず中身なしでタイトルと期日と工数だけ入れて起票。中身はそのあとで書いていく or 設計書のリンクを乗っけて終わりにする時もあります。