タスク整理する時は「懸念点」「課題」「リスク」を一緒に考えよう #PlantUML

この記事の目的

昔自分が作成したタスク管理フォーマットをもとに、
開発タスクの「懸念点」「課題」「リスク」の整理方法を共有するために書きました。
着手前の不安な点を洗い出して、不確実性に立ち向かっていきましょう。
最後に、タスク管理フォーマットのマークダウン全文を記載しています。

開発タスクを整理するときの誰かのTipsになれば幸いです。

懸念点

調査しなければ実現できるかわからないUIや、性能面に関する不安事項を懸念点として洗い出します。
あらかじめチームメンバに共有して、スケジュールの揺れがどれくらい発生しそうか握っておきましょう。
（自分はこのタスクに対してこんなに不安を抱えてます！という意思表示でもOKです）

<sample>
### 懸念点
<!-- 現時点での懸念点（気がかりなこと）があれば、なるべく具体的に記載する -->
<!-- 結果によっては仕様の変更や、スケジュールの遅延が発生しそうな項目は懸念点 -->
- [ ] UISliderでXD通りのUIが実装できるかどうか不明
    * スライダーの線色（緑）
    * インジケーターの大きさ（●）
    * 25%間隔でインジケーター配置

課題

予めわかっている制限事項や、着手中に判明した制限などを記載します。
解決方法も併せて記載して、チームメンバと共有します。

<sample>
### 課題
<!-- 対策も出来れば記載する（⇒） -->
- [ ] データ数がＸ件を超えると、画面に表示されない
⇒仕様的にX件を超えることはないので、受容する。
⇒対策する場合の工数はＸ日。
- [ ] API実行タイミングの仕様が決まっていない
⇒開発チームで検討する。

リスク

ITIL4の考えを取り入れて、
「損害や損失を引き起こす、または達成目標の実現をより困難にする可能性のあるイベント」
を記載します。
ここで思いついたリスクは、別途リスク管理表に転記するのがいいでしょう。
先ほどの課題もそうですが、リスクに対しては
「回避」「転嫁」「軽減」「受容」という4つの考え方があると覚えておくと対応策を考えるときの思考の幅が広がります。

<sample>
### リスク
<!-- (ITIL4)損害や損失を引き起こす、または達成目標の実現をより困難にする可能性のあるイベント -->
<!-- もし起こった場合にプロジェクト目標に対して影響を与えるであろう「不確かな事象」 -->
<!-- このリスクを「回避」「転嫁」「軽減」「受容」するかまで記載すること -->
* リリース後に最新OSが発表されると、この機能が使えなくなる
    （現iOSバージョン（ver.X)でサポート打ち切りのライブラリを使用している）
    [回避]
    新しいライブラリを選定しなおして、実装する。
    想定工数はＸ日。
    **二次リスク**
        ●●の機能改修も必要※上記工数に含まれる。
    [受容]
    社用端末でしかこのアプリは利用されない。
    社用端末のOSバージョンは現在ver.Xで、アップデートされることはない。

タスク管理フォーマット

フォーマットの特徴

1つのファイルで下記要素を満たせるようなフォーマット
・タスクに対する付帯作業を洗い出すことができる。
・スケジュールをPlantUMLで作成することで、スケジュールが可視化できる
・懸念点や課題、またリスクに対してITIL4の考えをもとに対策を考えられる

使い道

振られたタスクのブレークダウン
JIRAなどのタスク管理ツールを更新する前の思考整理
誰かにタスクを振った時、着手前にこのフォーマットに沿って作業を細分化してもらい、タスクとスケジュールの認識合わせを行う

フォーマット

タスクXXX.md

## 作業洗い出し
<!-- コメントアウト：Ctrl+K→Ctrl+C -->
<!-- コメントアウト解除：Ctrl+K→Ctrl+U -->
<!-- プレビュー表示Ctrl*K→Vでプレビュー表示 -->
<!-- 出力：プレビュー画面で右クリック→Chrome＞PDF
    ※F1→Markdown PDFだとplantumlの箇所が出力されないので注意 -->

### タスク画面イメージ
<!-- 画面イメージがあれば添付する -->
<img src="./sample.jpg" height="500">

### task
<!-- タスクをなるべく細かく記載する -->
- [ ] 付帯作業
    - [ ] アイコン用意
    - [ ] XX資料作成
- [ ] UI実装
    - [ ] test
    - [ ] test2
- [ ] API連携
    - [ ] XXAPI実行
- [ ] ロジック
    - [ ] test

### ガントチャート
<!-- 参考：https://plantuml.com/ja/gantt-diagram -->
````plantuml
@startgantt
language ja

Project starts the 2021/10/13
saturday are closed
sunday are closed
[UI実装] lasts 1 day
[API連携] lasts 3 days and starts 2021-10-14
' [API連携]と[ロジックを並行して進めることを表現
[ロジック] lasts 4 days and starts 2021-10-15
[test] lasts 2 days

' スケジュール
' ある工程が終わった後に、着手することを表現
[ロジック] -> [test]
@endgantt

### 懸念点
<!-- 現時点での懸念点（気がかりなこと）があれば、なるべく具体的に記載する -->
<!-- 結果によっては仕様の変更や、スケジュールの遅延が発生しそうな項目は懸念点 -->
- [ ] UISliderでXD通りのUIが実装できるかどうか不明
    * スライダーの線色（緑）
    * インジケーターの大きさ（●）
    * 25%間隔でインジケーター配置

### 課題
<!-- 対策も出来れば記載する（⇒） -->
- [ ] データ数がＸ件を超えると、画面に表示されない
⇒仕様的にX件を超えることはないので、受容する。
⇒対策する場合の工数はＸ日。
- [ ] API実行タイミングの仕様が決まっていない
⇒開発チームで検討する。

### リスク
<!-- (ITIL4)損害や損失を引き起こす、または達成目標の実現をより困難にする可能性のあるイベント -->
<!-- もし起こった場合にプロジェクト目標に対して影響を与えるであろう「不確かな事象」 -->
<!-- このリスクを「回避」「転嫁」「軽減」「受容」するかまで記載すること -->
* リリース後に最新OSが発表されると、この機能が使えなくなる
    （現iOSバージョン（ver.X)でサポート打ち切りのライブラリを使用している）
    [回避]
    新しいライブラリを選定しなおして、実装する。
    想定工数はＸ日。
    **二次リスク**
        ●●の機能改修も必要※上記工数に含まれる。
    [受容]
    社用端末でしかこのアプリは利用されない。
    社用端末のOSバージョンは現在ver.Xで、アップデートされることはない。

ガントチャート部分

上記フォーマットのガントチャートはこのように表示されます。

注意点

*マークダウンがコードとして出力されるように、「```」で囲っています。
運用するときは、「```」を削除してmdで保存してください。
ガントチャートを記載している「````plantuml」「````」は消してはダメです。