30 12月, 2020

整理したい私はITILをかぶる、PlantUMLへの愛

現在、ネクイノでエンジニアリングマネージャー、バックエンドエンジニア、インフラエンジニアを担当している私は、年の瀬を迎えて振り返り記事を書くことに決めました。この記事では、PlantUMLに絞り、振り返ることで気づいた問題点とその解決策を詳細に描写します。PlantUMLは私にとって全知全能のツールではありませんが、愛しているツールであり、これまでの8ヶ月間の成長を共有したいと思います。

thumbnail

PROBLEM

振り返ることで私が気づいた主な問題点は、開発チーム全体がまだ機能していないことでした。管理規程はあるものの、業務フローが明示化されておらず、誰が何を何の目的で業務を回しているか分からない状態でした。この可視化されていないプロセスが問題になるケースが増えてきました。

SOLUTION

この問題に対して、私は入社早々PlantUML¹を活用して業務フローの可視化を始めました。PlantUMLはオープンソースのUMLダイアグラム作成用のテキストベースの言語であり、シークエンス図、ユースケース図、アクティビティ図、クラス図などのダイアグラムをシンプルで直感的に書くことができます。

私がネクイノに入社してから使用し始めたのは、Emacsのorg-babelで実装された2014年頃であり、esa.ioやVS Codeなどで実装されてから爆発的に普及したと記憶しています。私がesa.ioでPlantUMLの実装を要望したのも良い思い出です。

やったこと

さて、私はネクイノに入社してすぐに既存システムの運用開発と情シス（業務運用）の部長職にアサインされました。外部パートナーが入るということで、開発フローが大きく変わる節目にありました。

開発フローを整備する

開発フローを整備するために、新しく入る外部パートナーがプロジェクトマネージャ、ブリッジエンジニア・コミュニケーター、モバイルエンジニア、バックエンドエンジニア、フロントエンジニア、品質チェックを含めて20名程の体制であることを把握しました。また、既存システムの運用開発ではプロダクトマネジャー、プロダクトオーナーが各開発者とともに企画策定を行うことが慣習として存在していました。そこで、私は企画から実装、レビュー、リリースまでの流れを整理しました。

skinparam handwritten true

|エピック(仕様策定)|
    start
    if (仕様策定) is (あり) then
        :To Do;
    else (なし)
    endif

|エピック(見積)|
    if (見積) is (あり) then
        :To Do;
    else (なし)
    endif

|エピック(実装)|
    :To Do;

|エピック(レビュー)|
    if (リリース承認) is (OK) then
    else (NG)
        |エピック(実装)|
            :To Do;
    endif

|エピック(リリース)|
    stop

開発の流れ

その結果、開発フローはJira上で大まかな流れとして、エピック(仕様策定)、エピック(見積)、エピック(実装)、エピック(レビュー)、エピック(リリース)という5つのステップに分かれました。このフローをPlantUMLを使って可視化しました。

skinparam handwritten true

actor 要求者 as Rq
actor "事業部\nPdM" as Pd
actor 分析 as An
actor デザイン as Ds
actor "開発\nPjM" as Pj
actor "開発\nアーキテクト" as Ac
actor "開発\n実装者" as Cd
actor "開発\nレビュー" as Rv

Rq -> Pd: 要求を上げる
activate Rq
activate Pd
Rq -> Rq: |開発Pj管理表|\n要求整理\n- 課題抽出\n- 完了定義\n- 優先順位付け
Rq -> Rq: |Jiraエピック|\n|分析/To Do|\n課題を策定

group 仕様策定
    alt 案件種類判定フェーズ
        Rq -> Rq: 案件種類判定\n-> PdM案件
        Pd -> An: 分析依頼
        activate An
    else 課題分析フェーズ
        An ---> Pd: 分析結果
        deactivate An
        Rq <-> Pd: 詳細確認\n(省略あり)
        deactivate Rq
    else 要求仕様(完了定義)確定フェーズ
        Pd -> Ds: |Jiraエピック|\n|仕様策定/To Do|\n完了定義確認
        activate Ds
        Pd -> Pj: |Jiraエピック|\n|仕様策定/To Do|\n完了定義確認
        activate Pj
    else 要求仕様確定フェーズ
        Ds ---> Pd: |figma|\nワイヤーフレーム作成
        Pj -> Pj: |Jiraエピック|\n|仕様策定/進行中|\n完了定義策定
        Pd <-> Pj: |Jiraエピック|\n|実装/To Do|\n- 週次MTGで関係者とともに\n  認識合わせを行う\n- 合意後計画に積む
    else 実装計画・見積フェーズ
        Pj -> Ac: |Jiraエピック|\n|実装,見積/To Do|\n|Jiraｽﾄｰﾘｰ|\n|To Do|\n|esa,miro|\n策定依頼\n- アーキテクチャ\n- 実装計画\n- 工数見積
        activate Ac
        Ac -> Rv
        activate Rv
        Ac ---> Pj
        deactivate Ac
        Pd <-> Pj: |Jiraエピック|\n|実装/To Do|\n|Jiraｽﾄｰﾘｰ|\n|To Do|\n- 見積工数をもとに優先順位付\n- 実装依頼
    end
end

Pj -> Cd: |Jiraエピック|\n|実装/進行中|\n|Jiraｽﾄｰﾘｰ|\n|進行中|\n実装依頼
activate Cd
Cd <-> Rv: |GitHub|\n実装
Cd <-> Rv: |Jiraｽﾄｰﾘｰ|\n|レビュー中|\n|GitHub||n品質確認\nコードレビュー
Cd -> Cd: |Jiraｽﾄｰﾘｰ|\n|完了|\n|GitHub|
deactivate Cd

group スプリント
    Rv -> Pj: |Jiraエピック|\n|実装/レビュー中|\nレビュー依頼
    Pd <-> Pj
    deactivate Pd
    Pj -> Rv: |Jiraエピック|\n|実装/完了|\nデプロイ依頼
end

Rv -> Rv: デプロイ
deactivate Rv
deactivate Pj

要望フローを整備する

また、要望フローについても同様に整備しました。機能要望、バグ報告、改善要望がSlackチャンネルに散在しており、チケット化されないケースがあったため、GoogleフォームとJira連携を行い、要望の集約とトリアージを行いました²。プロダクトマネジャーの体制が整備された後も、バグ報告や改善要望は要所要所で利用され、トリアージが定期的に活用されるようになりました。

skinparam handwritten true

|Googleフォーム|
    start

|Slack|
    :起票の連絡;

|Jira|
    if (緊急度) is (緊急,高) then
        :label 実装;
        |Slack|
            :一時対応;
            stop
    else
        |Jira|
        if (緊急度) is (中) then
            |Jira|
                :label 実装;
                :現象確認;
            |週次定例|
                :計画の議題にのる;
                stop
        else (低)
            |Jira|
                :label トリアージ;
            |週次定例|
                :ﾄﾘｱｰｼﾞの議題にのる;
                stop
        endif
    endif

デプロイフローを整備する

開発が進んでいくと、今度は開発環境が足りなくなりました。当時はステージング環境と本番環境しかなく、かつ、ステージング環境がテスト環境兼デモ環境の役割を呈しており、ステージング環境おテストで不具合を起こすとデモに影響が出るという状態が続いておりました。また、外部パートナーが開発するに当たり繊細なステージング環境を使うのが難しいため進捗に影響が出始めておりました。

急を要する事態のためAWS CDKでステージング環境とは別に結合環境を用意し³、デプロイフローを整備しました。

skinparam handwritten true

actor 実装者 as Cd
actor レビュアー as Rv
collections GitHub as G
control CircleCI as C
collections ECR as R
participant "ECS(Fargate)" as F

group レビュー
    Cd -> G: プッシュ/PR
    activate Cd
    activate G
    Rv -> G: FDBK
    activate Rv
    Cd -> G: FDBK対応
    Rv -> G: LGTM
    deactivate Rv
end

group 結合確認
    Cd -> C: |手動承認|\n結合環境にデプロイ
    C <-> G
    C -> C: |CDK|\nDockerイメージビルド
    C -> R: |CDK|\nDockerイメージプッシュ
    activate R
    C -> F: |CDK|\nタスク定義をサービスに適用
    activate F
    F <-> R
    deactivate R
    Cd -> F: 動作確認
    deactivate F
end

group ステージング確認
    Cd -> G: masterマージ
    Cd -> C: |手動承認|
    activate C
    C <-> G
    deactivate G
    C -> C: Dockerイメージビルド
    C -> R: Dockerイメージプッシュ
    activate R
    Cd -> C: ログからイメージタグを取得
    deactivate C
    Cd -> R: イメージタグからイメージURIを取得
    Cd -> F: - タスク定義にイメージURIを適用\n- 当該クラスタを更新
    activate F
    F <-> R
    Cd -> F: 動作確認
    deactivate F
end

group 本番確認
    Cd -> R: 最新masterイメージタグからイメージURIを取得
    Cd -> F: - タスク定義にイメージURIを適用\n- 当該クラスタを更新
    activate F
    F <-> R
    deactivate R
    Cd -> F: 動作確認
    deactivate F
    deactivate Cd
end

障害対応フローを整備する

さて、運用開発が順調に進んでいくと、今度は障害が頻繁に起きていることに気づきました。いいえ、薄々気づいていたのですが多忙にかまけて蓋をしておりました。ここに関しては本腰を入れてAWSサポートプランをビジネスに変更し原因を突き止めました。協力いただいた各位には感謝です。

また、今まで見過ごされていたGoogle Workspace等の業務運用のシステムも含め障害報告の体制を敷くとともに、監視体制も強化しました。

skinparam handwritten true

box 障害チャンネル
    actor ビジネス as B
endbox
actor "窓口\nアナウンス" as A
box 開発チャンネル
    actor 障害通知 as N
    actor 調査 as R
    actor 修正 as M
    actor デプロイ as D
endbox

group 初回レポート
    N -> N: 障害通知
    activate N
    A -> N: 障害有無確認\n...(1)
    activate A
    deactivate N
    A -> B: 障害レポート\n...(2)
    A -> R: 調査依頼\n...(3)
    activate R
    A -> M: 修正依頼
    activate M
    A -> D: デプロイ依頼
    activate D
end

group 途中経過レポート
    A <-> R: 確認
    A <-> M: 確認
    A -> B: 障害レポート\n...(4)
end

group 終了レポート
    R <-> M
    deactivate R
    M <-> D
    deactivate M
    D -> D
    D -> A
    deactivate D
    A -> B: 障害レポート\n...(5)
    A -> N: 感謝
    A -> R: 感謝
    A -> M: 感謝
    A -> D: 感謝
    deactivate A
end

業務フローを整理する

まだまだあります。業務内容に関しては詳細は書けませんが、部内の業務から他部署の業務まで安全に生産性を高めるため整理を行いました。まだまだ行います。

リモート飲みのフローを整備する

いよいよ疲れてきたのでお酒が飲みたくなりました。飲み会フローを作ってみましたが思いの外手間がかかることが分かりあまり活用できておりません。その代わり社内でオンラインシャッフルランチという制度ができました。

skinparam handwritten true

actor "所属チーム\n(他部署含む)" as T
actor 外注 as P
actor 幹事 as M
actor 経理 as A
collections お店 as S

group 調達
    T <-> S: 発注・発送
    activate T
    P -> M: 調達依頼
    activate P
    activate M
    M -> S: 発注
    S ---> P: 発送
    S ---> M: 発送
end

group 開催
    T -> T: なにか
    P -> P: なにか
    deactivate P
    M -> M: なにか
end

group 経費申請
    T -> A: 申請
    deactivate T
    activate A
    M -> A: 申請
    deactivate M
    deactivate A
end

分かったこと

はい、こうして振り返ると入社時に感じていた雑然さは業務フローが明確でない状態のことでした。開発者なら分かると思いますが、企画段階で思い描く構成図は実装する段になるとあまり意味をなさず、結局は頭の中はシークエンス図でいっぱいになります。それと同じで、登場人物、登場人物間のメッセージ、メッセージの大枠が関係者に共有されていないと、いくらリソースが投下されても不安定で生産性に伸び悩むのです。つまり、雑然とした環境を整理すると言うことはシークエンス図を書くことに他なりません。

しかしながら、当該環境一つ一つを俯瞰的に見るとITILプラクティスそのものであることにも気づきます。

ITILとはITサービスマネジメントのベストプラクティスフレームワークのこと。何らかの高い技術を持っていても、投資対効果を考えていなければ赤字になりビジネスと成り立ちませんし、顧客のことを考えずに作ったものに価値はありませんし、サービスの評価を落とすことになります。このようなことを防ぐには顧客目線やビジネス的な観点が必要で、そのノウハウがまとまったものがITILです。

今回対応したプラクティス

今回の振り返りでは具体的に次のプラクティスをなぞっておりました。

振り返り	ITILプラクティス
開発フローを整備する	継続的サービス改善
要望フローを整備する	要求管理、問題管理
デプロイフローを整備する	リリース管理及び展開管理
障害対応フローを整備する	インシデント管理
業務フローを整理する	CMMI
リモート飲みのフローを整備する	組織変更管理

CMMIと組織変更管理が分かりづらいの少し補足します。

CMMIとは能力成熟度モデル統合のことで、業務フローを評価し5段階で成熟度レベルを出す手法です。現状はレベル1-2（初期段階）のものがほとんどなのでまずはPlantUMLを使い共通認識を作るところから始めました。
組織変更管理とは経営学で言うところのチェンジマネジメントに当たります。ここでは各種フローを整備しメンバー全員に落とし込むことを目指します。『Fearless Change』では今回のリモート飲み以外にも多くのパターンランゲージが紹介されています。

WRAPUP

次にすること

ネクストアクションですが、採用フローを考えています。

（読者の皆様はどんなシークエンス図を思い浮かべましたか?）

というわけで、ネクイノはPlantUMLを愛している開発者を募集中です。

PR: ネクイノとは

「世界中の医療空間と体験を再定義する」をミッションに、人々と医療の間にICTのチカラで橋をかける遠隔医療ソリューションを手掛けている会社です。医療というと高齢の患者さんをイメージされるかもしれませんが、我らがターゲットとしているのは現役世代の方。病気を治療するというより、現役世代がQOLを高めるためのサポートを目的としています。

メインサービスは、女性に特化したピルのオンライン診療アプリ「スマルナ」。ピルを飲まれている人だけでなく、受診や服用に抵抗がある方にも気軽に利用していただけたらと思いサービス提供しています。診察室の手前に助産師と薬剤師を配置した相談室を設ける等、受診のハードルを下げる工夫をそこかしこに施しているのが特徴です。

様々なメディカルコミュニケーションを行っています
- 専門家相談
- カスタマーサポート
- ユーザーコミュニティ

妻からは「10年前にサービスがあったら良かったのに」とお墨付きをいただいており、興味をもった方は詳しくはこちらをご覧下さい。 https://smaluna.com/

[B! plantuml] nabinnoのブックマーク ↩
https://github.com/nabinno/google-forms-to-jira-slack ↩
CDKはaws-rails-provisionerを参考に ecs_patterns.ApplicationLoadBalancedFargateService を実装しました ↩