NOT A HOTELの情シスチームのAgileな仕事の進め方
この記事は、NOT A HOTELのソフトウェア開発連載「Inside the SOFTWARE TEAM」の企画で書いています。
はじめに
こんにちは、こんばんは、おはようございます、おやすみなさい、NOT A HOTEL の@kajinari です。
今年からNOT A HOTELのCorporate ITチームは3人体制になりました。これにより「個」の力から「チーム」として価値を提供し続けることが求められるようになりました。チームとして価値を提供するために、仕事の進め方をアップデートする必要がありました。
今日は私たちのチームが「コト」にどう対峙し、ルールを減らし、判定基準を明確にし、合意のコストを下げることで「1週間で小さく価値を届ける」仕事の進め方を実現したかを紹介します。
この記事は、同じような課題を抱えるチームに向けて、私たちが実際に使っている仕組みと考え方を共有するために書きました。参考になれば幸いです。
運用タスクとプロジェクトタスク
私たちの業務は、ヘルプデスク業務と改善系のプロジェクトに大きく分けられます。
それぞれの内容は以下の通りです。
運用タスク（ヘルプデスク）
アカウント発行、権限変更、PC等の不調など、問い合わせ全般を取り扱います
平均すると毎日5件以上の問い合わせに対応しています
多くの業務を自動化していますが、問い合わせや質問への対応は依然として必要です
改善系のタスク
より良い環境を目指す改善プロジェクトです
新しいSaaS導入の検討や運用設計などを行います
自動化の推進やセキュリティ対策の強化なども含まれます
運用タスクは「Jira Service Management」で管理
Jira Service Management との連携
運用タスクの管理には Jira Service Management を採用しています。主に Slack と連携させることで、問い合わせから対応完了までをシームレスに進められる仕組みを構築しました。
問い合わせの様子
Slack側
専用のSlackチャンネルに投稿された問い合わせメッセージを自動起票しています。
余談ですが再招待方法も自動化（セルフサービス化）する方法を検討したいと思っています。
Jira側
問い合わせはQueue管理されています。
Slackのチャンネルを遡って探すなど必要なくなります。
Slack との連携による効率化
Slack の専用チャンネルから直接チケットを起票できます。
問い合わせ内容が自動的に Jira のチケットとして記録されます。
チケットのステータス変更や更新情報が Slack に通知されます。
依頼者は Slack 上で進捗を確認でき、追加の情報提供もスムーズです。
主な運用フロー
依頼者が Slack で問い合わせ → 自動的にチケット化。
担当者がアサインされ、Slack と Jira 両方で状況を追跡。
作業完了後、依頼者に Slack で通知が届き、確認・承認を依頼。
この仕組みにより、問い合わせの取りこぼしを防ぎ、対応履歴を一元管理しながら、コミュニケーションの場は普段使っている Slack に保つことができています。
プロジェクトタスクは「Notion」で管理されています。
Notionのボードでタスク管理しています。
いわゆる「カンバン」形式です。
カンバンは、作業の流れを可視化し、進行中のタスクを管理するためのツールです。タスクをカンバンボードで管理することで、チーム全体の状況を一目で把握できます。
Notionでのタスク管理ついては、こちらのBlogでも解説しているので合わせてご確認下さい。
私たちのボードの設定方法と、各ステータスの意味について紹介させていただきます！
ステータスの意味
タスクの書き方
背景を書く
このタスクが必要になった背景を書きます
受入条件を書く
ユーザーストーリーやタスクが「完了した」と見なされるための明確な条件です。これによりチームメンバー全員が共通認識を持ち、品質を確保します。
チームで受入条件を設定することで、担当者の思い込みを排除することができます！
期待される成果を書く
Amazonでは「Working Backwards」という手法を採用しており、新しいプロジェクトや製品開発を始める際に、まず顧客向けのプレスリリース(Press Release)とFAQから書き始めるそうです。
タスクに「期待される成果」を明記することで、似たような考え方を取り入れています。完了時にどんな状態になっているべきかを先に定義することで、作業の方向性がブレにくくなります。
優先度について
一番上にあるものが優先順位高いようにしてます。
毎週定例MTGで今週取り組むべきタスクについて会話して決まる。
プロジェクト化する必要がある場合
最低2ヶ月以上かかるタスクがある場合に、タスクを分解し依存関係を整理するときに使います
私たちはフォーカス案件と呼んでいます。
フォーカス案件のサブタスクは、Sprint タスクと同等に扱いますが、大きな価値をもたらすので、タスクを計画する時には優先的に取り組むようにしています。
計画の仕方について
毎週のイテレーションでSprint Goalを決めます。その週達成すべき最も重要なことは何か？という観点でゴールを決めています。
そのゴール及びその週取り組むべきタスクを計画するためのミーティングとして、毎週「Sprint Review & Planning Meeting」を実施しています。 このMeetingでは、チームの成果を共有し、次のSprintの計画を行います。
実施している項目毎に解説させていただきます。
レビュー
その週のSprintで完了したタスクをチームに共有して、タスクの完了確認を行います。
その週の成果をステークホルダーにレビューして、完了させる。
完了したタスクにフィードバックがあれば、Sprint Backlogに追加して改善します。
新しく作成されたチケットの共有
新しく作成されたチケットをチームで共有して、認識をそろえる。
新しく依頼されたチケットについて会話を行い、今求められていることを確認します。
フォーカス案件の確認
スケジュールの調整が必要なものがないか確認する。
その他、フォーカス案件が達成するためにサブタスクのヌケモレが無いかを確認する。
プランニング
フォーカス案件が達成できるように、その週優先して取り組むべきタスクを決める。
その他、依頼されたタスクで優先順位が高いタスクをプランニングを行う。
そのSprint Goalを作成する
Sprint Goalから今週実施すべき目標を設定し、その小さな目標を積み上げてフォーカスを達成するという設計になっています。
このイテレーションを1週間と設定しています。小さく計画し、実行し、振り返りを行い継続的な価値提供を実施しています。
FAQ：ヘルプデスクで工数圧迫されない？
そうだと思います。
年間通してヘルプデスク工数は見通しが立つ（平均するとある程度の見立てが立つ）ので、それを踏まえてプランニングしています。
イテレーションの中での相談事項は、Daily Meetingで決める
毎朝の朝会で, その日達成事項、共有事項、相談事項を会話します。
達成事項は、Sprint Goal から逆算して、必要なタスクを定義します。
Sprint Goalを達成するために、逆算して必要なタスクを定義するようにしましょう。
共有事項は、Sprint Taskが完了した後に、チームに共有必要なことを共有します。
相談事項は、Sprint Task の完了のために必要な方針のすり合わせや、チームで事前に合意することを相談します。
毎日、タッチポイントを設けることで、必要以上の待ちを発生させない仕組みづくりです。
毎朝のDaily Meetingで確認と調整を繰り返して行きましょう
終わりに
Corporate ITチームの仕事とプロジェクトの進め方について解説しました。
待ち時間を最小化し、1週間で小さく価値を届ける。ルールは過剰にせずに、合意基準を明確に。合意→実行→ふりかえりを高頻度で回す。
待ち時間を最小化し、1週間で小さく価値を届ける運用に変えました。
ルールは少なく、判定基準は明確に。
最も大きな価値にフォーカスして、価値を提供することにこだわって運用設計されています。
「合意→実行→ふりかえり」を毎週まわし、成果と学びを積み上げています。
フォーカス案件を中心にプランニングされていることがわかると思います。ITチームは差し込みが会社の全方位からやってきます。だからこそフォーカスする案件は何か？を常に意識し続けることが重要なんです。 それは価値提供をブレずにやり続けるために文字通りフォーカスすることが大事だからです。
このように軽い仕組みを高頻度で回すことが、結局いちばん強い。ルールを磨くのではなく、合意を早く・小さく・何度も重ねる。チームの学習速度が、提供価値の速度になります。
なぜこのやり方をしているのか？その背景も共有しているため、チーム規範が整い、継続的に価値提供できるようになります。
仕事の進め方は、チームとして前もって合意しておくことがとても重要です。参考になればぜひ感想を教えて下さい！
現在、NOT A HOTELのSoftwareチームでは採用強化中です。
カジュアル面談も受け付けておりますので、お気軽にご連絡ください。https://redirect.notahotel.com/software-jobs
