【研修レポ】DevOps体験!フェニックスプロジェクト研修参加レポート

公開日: 2024/02/13 @t_yama5k

普段プライベートで個人で勉強会に参加することがほとんどなのですが、業務として同僚とDevOpsシミュレーション研修に参加する機会があったので、レポートを書いてみます。

研修概要

フェニックスプロジェクト DevOpsシミュレーション研修｜研修・資格｜ITプレナーズ

部門間のコラボレーションを、ゲーム形式で楽しく実践的に学ぶ

崖っぷちなプロジェクトを社員一丸となって成功に導くことを通し、部門間コラボレーションを実践的に学べる体験型研修

参加動機

役職、役割の垣根を超え、目標に向かって業務をどうこなすかを考えることが度々あった。今回、知識としては知っていることを体験型の研修を通して実践的に学べる機会をいただけることになったことと、なにより会社の研修として同僚と参加できる機会であることが魅力的であったため参加することにした。

当日の様子

研修中にとっていたメモを参考に時系列に箇条書き
※研修のネタばれはなるべく避けているがこれから研修を受ける人は事前情報を入れないほうが学びが多いかもしれないことに注意されたし

前提

バックログカード
- 改修内容、障害内容などが記載されているカードを便宜上このように呼ぶことにする
- プロジェクト番号が採番されている
対応カード
- 各役割の作業内容を表すカード
- どの役割が実行可能であるか、工数がどれくらいかかるかなどの情報がある
情報シート
- 各役割がバック
  - アプリ関連だとバックログ完了に必要なインフラのバージョン情報が一覧として載っている
ITテストチームの役割
- 今回の私が担った役職
- 各バックログカードを完了させるに当たり、その対応カードが適切であるかをテストできる情報シートを所持
- ただし、テストには利用できるが、各バックログに対してどの対応カードを実行すれいいかがわかる情報ではない

研修の流れ

ラウンド0
- 研修では11の役割があり、空いている役割を自由に選択できるだが上長から役割の指名があり「ITテストチーム」となる
  - 工程の最後に関わる役職であり、ここに実務に近い人を配置しておけば大きくグダることはないだろうという判断だったらしい
- 説明もほどほどに早速ラウンド開始
- ラウンド1開始までに把握できたこと
  - 経営悪化によりCIOが首になりCISOが兼任することになった
    - CISO（Chief Information Security Officer）
    - 最高情報セキュリティ責任者と訳され、企業における情報セキュリティを統括する責任者
  - 社運をかけたプロジェクト、それが「フェニックスプロジェクト」
    - 売上、株価を上げる必要がある
      - ４ラウンドで目標の売上、株価へ到達させなければいけない
    - プロジェクトにはマイルストーンが設定されている
      - 法的に対応しないといけなかったり、社内システムのキャパオーバー対策など
        
        これもプロジェクトで達成すべき目標として組み込まれている
    - 参加者はそれぞれ役割を割り振られている
      - 自分の役割については簡単な説明資料をもらえる
      - 全員共通のルールブックが配布されるということはなく、他の人の役割などわからない
ラウンド1
- ビジネス部門のチームが売上目標や会社が抱える課題の情報を持っているようだったので現状共有
  - 主な開発ターゲットは２つ
    - 社外向け製品改修
    - 社内システム改修
  - 売上を上げるという面では製品開発を進めていきたいが、社内システム(給与関連など)をおろそかにすると売上減につながる？
    - この辺の見えないパラメータまで読みつつ経営側役割の人が優先順位付けをしていた
- ITテストチームとしての動き
  - テストを実施しようとするが、対応カードがなんのバックログに対して置かれているのかがわかるように置かれていないため検証そのものができなかった
    - 相手の作業が見えているが、見えているだけでまったく整理されていない状態となってしまっている状態
インターバル
- ラウンド1でほぼなにもしていなかった(できなかった/そもそも何すればいいのかがまだわからなかった)ため次ラウンドに向けて他参加者と作戦会議
  - 「実務でもテスト工程最後の方になったり、工数見直しが発生されちゃうと大変なんすよははは」と世間話
    - 参加者は全員同じ会社の人なのでそんな話もできるが、他の会社所属の方が混ざっていた場合はもうちょっと当たり障りのない話になっていたと思われる
    - ~~テスト工程って実際の業務でも最後の最後となると下手すると工数かけられないことも含め、そういうところまで再現してるのかよと思ってみたり~~
  - テストは実施しなくても作業はしっかり実施できる(とこの時点では思っていた)ので他の作業者よりも発言権が低めだなぁと感じていた
ラウンド2
- このラウンドでようやく開発サイドはバックログに対してどのアクションを実施すれば完了になるかの情報を持っていないことを認識した
  - ラウンド1でバックログに対してで手戻りが発生
    - バックログに対して関連しそうな対応カードで処理
      - 開発者の役割の人は、バックログに対してどの対応を
    - 手戻りが発生するとすべてやりなおしとなるので関連する全役割に影響がでてしまう
  - 作業が妥当であるかはテストチームが持つチェック表を利用する必要がある
  - 最後の最後にテストして間違っていても、間違っていることがわかるだけで修正がきかない(対応する時間がない)
- ITテストチームとしての動き
  - テストのやり方がわかったので他の役割がその作業を終えたところでテストを実施
    - 前述しているが、この時点でテスト失敗してもリカバリがきかない
    - 実際、テストに失敗した作業が想定通り手戻りになってしまった
インターバル、昼食
- 手戻りの発生を抑える方法を考えつつ、昼食
ラウンド3
- 別に机を移動してはいけないというルールも床を使ってはいけないというルールも設定されていないと講師からのアドバイス
  - 床にバックログを並べる作戦を開始
- ITテストチームとしての動き
  - テストを最後の工程に持ってきてもいいことはあまりないのは現実世界でもシミュレーションでも同じことなので、皆にテスト方法を布教を開始
    - 床に並べたバックログ全てにに作業のテストに必要な情報を付箋にメモ
    - アクションカードを持つ作業者は当てはまりそうなカードを並べた後、自分でテストを実施、テストNGの場合はカードを当てはめ直して再実施
    - プランニングの時点で作業の妥当性まで確認できるようになった
      - 全ラウンドで手戻りになった作業もこのラウンドでは完了できた
- ラウンド中の差し込みバックログ(障害発生など)も、床に置かれた瞬間に即対応可能となった
ラウンド4
- ラウンド3の時点で自分の立ち回りは大分カイゼンされたので、全ラウンドと同様に立ち回る
  - バックログカードが設置されたらテストに必要な情報をふせんに書き出し横に設置
  - 対応カードが設置済みの場合テスト、問題なければOKのふせんを設置
懇親会
- 直人さんより役職指名についてのこぼれ話
  - 役職指名についての経緯
    - 以下２役職で
      - ラウンドごとの対応バックログ選定など最初の工程
      - バックログ完了の最後の工程
  - 最初と最後を実務に近い人がやれば大きくグダらない
- ITプレナーズの社長さん?も来沖されていたのでここで合流されていた
  - 研修後の経過報告会の定期開催や研修事例として取り上げたいみたいなお話をいただく
  - 社内で研修成果が認められ、上記がうまく次は他拠点の方も交えての開催などもできそうな感じ

やったこと/やれたこと

自分の役割(ITテストチーム)として、ラウンド3でテスト方法を広めることで手戻りがなくすことができた
- ラウンド3以降は差し込みバックログに対する対応の所要時間が短くなったことは講師からも良かったポイントとして言及いただいた
カイゼン案をいろいろと提案できた
- 元々各種開発技法の知識があったことと、(面識がない人のほうが多いものの)すべて会社の人だったので喋りやすい環境であったことが大きい
インターバルや昼食時間で普段接点のない人と喋ることができた

わかったこと

「わからないことがわからない」というのは大変まずい状況である
- 情報が乏しい、格差があるといった場合にこれが発生してしまう
- ラウンド1の時点でまずは各々何ができそうで、なにがわからないなど役割そのものの共有を行えるとよかったかもしれない
可視化は大事だが工夫も必要
- ラウンド３以降フロアを全面に利用し扱える、確認できる情報が大幅アップ
- ふせんなどを利用したアナログなやり方ではバックログの優先順位付けなどは気軽にできないためどこかで限界がくる
  - 実務ではデジタルなツールに登場いただくことになる
    - どうしてもバックログに紐づく情報が多くなる
    - ツールの利用方法含めこの辺りの試行錯誤はどこも悩んでいる様子がうかがえる

つぎにやること

参加レポートは社内にしっかり展開する
- 久々の社内で参加者を募っての研修ということだったので次に繋げていきたい
- 参加できなかった人にも興味をもってもらう
  - 他拠点の人まで巻き込んで開催も有り得そう
自分の今の業務には直結しないがDevOps、スクラムには興味が出てきたので、関連書籍を読む、資格取得を通じた知識の習得などを計画してみる
- 来期の個人目標に組み込むなど

研修全体の感想

実際の業務を落とし込んだ形でシミュレーションゲームとして構築されていたのは面白かった
- ラウンド中に障害が発生して対応しないといけないバックログが増える
- ラウンド中のアクションとしてCEO(講師が担当)を説得しないといけない
振り返りが重視されている。まずは一度やってみてからのやってみてからの学習とカイゼンも研修内容として設定されている様子であった
- 詳細なルール説明なしにラウンドが開始され最初はうまくいかない
  - 十分な情報がなく時間もない中でも進み続けないといけないのも実務あるある
  - 振り返りの時間も無限ではないからこそ
- こういった構造上事前知識がなくても参加可能であるし、知識があるなら実践の場として活用ができる
すべての情報を皆で共有し議論することが必ずしも正しいとは限らない
- 情報すべてが共有されると風通しのいい組織となるが、時間も工数も限られている場合はそうは言ってられないよね
  - 小学校の学級会とか全員参加型の直接民主主義だとどこかで限界がくる、的なことか
- 今回特に印象的だったのは、バックログで明らかに不要と判断されたものはその存在ごと握りつぶされていた?らしいこと
  - 皆がシミュレーションのルールの把握と並行して作業をこなすなか情報量を減らし選択の余地をいたずらに広げないようにしたということか
    - ワートリの将棋の人を思い出した(伝わるひといるといいが)
  - 時間も工数も有限だからこそ、時にはそのような動きを"上"がすることもあるかもしれない、ということにはあるていど納得ができる
    - とはいっても自分のやることは納得した取り組みたいと常日頃考えているので、このバランスが大変そう
バックログという言葉に耳慣れていない人についてはこの機会に調べてみると相互理解が進みそう
- 自分含め、バックログのタイトルと通し番号で紐づけて各作業を把握するという動きが序盤できていなかったので
  - どんなカードがあるかやその説明もあまりなかったため、序盤ルールの把握に手間取ったというのは大いに関係しているとは思う
  - バックログを起点にすれば情報の集約がスムーズになったはず