課題管理について考えることがあります。
自分の場合は、課題と認識した時にどのくらいで終わらすのかということを考えるのですがそれ自体がダメ、ナンセンスなんだということに最近気づきました。
ナンセンスな理由
課題管理について課題と認識した時にその自分の尺度で納めた場合に起こりうるトラブル。
1.いつまでに終わらせるのかを考えるフェーズ
2.いつまでに終わっていれば理想かを考えるのフェーズ
3.いつまでなら判断ができるフェーズ
この課題の締め切りを考えることができればいいと思っております。
- すぐに終わる課題と終わらない課題のバランスが悪い
- たくさん終わったように見えても、軽いものだけで実際にはあまり進捗していない
- 粒度が大きすぎる課題で終わりが見えない。焦りも出てくる。
最終ゴール地点をどこに置くのかによる
具体的に最終ゴール地点を決めた時にどこに置くのかというところは明確にしておこう。
課題管理を完了管理にする。
これを決めるのは難しいですね。
プロジェクトリーダーさんの場合、特にここを考えなくてはならない。
判断は誰なのか、最終決定は誰なのか。
なるべくストレスがないように進めていくことが良い。
1.いつまでになら判断ができることがポイント
2.いつまでたっても終わらないということを避けるためにココぞという時のポイント
いつまでになら判断ができることがポイント
いつまでなら判断できるのかということが判断される方にわかるようにすることが重要で最終的に報告を最終決定者に連絡することが重要だということ（周知）
定例会が開かれるとしたらその時に決めておくこと、進めておくこと、いつまでにというのがわかればその会議がスムーズに遂行されていきます。間に合わない場合は、増員することも検討したりも上司上司できますからね
いつまでたっても終わらないということを避けるためにココぞという時のポイント
いつまでたっても終わらないというのはダラダラしていることと同じになってしまうので。
ココぞという時は、締切日を設けることが良いでしょう。
課題がどれくらいあるのか、その課題がどのくらいの量があるのかいつまでに判断が欲しいのかというところまで明確になっているといいとかそういう決め事みたいなのは、プロジェクト毎チーム毎に決めておく必要があるのいかなって思います。
具体例
原因を具体的に考えてみると、以下ではないかと思います。
課題登録時に課題のゴールの定義が不十分な場合
登録する課題が「完了」になる状態がどのようになった時、詳細にしっかりと書いているか、そして、その状態が重いか軽いか検討が不十分なときに、課題の単位のばらつきが多くなるのではないと思います。
例: ライブラリを組み込む
例を挙げてみたいと思います。例えば、次の課題を考えてみます。
表題: Aのフレームワークを組み込む
詳細: 表題の通り
このゴールは「Aのフレームワーク」が組み込まれている状態であることです。しかし、この組み込み、軽いですか？重いですか？やることは何がありますか？上記の記述からは経験者しか想像つかないのでは無いでしょうから。経験者でも思い違いがあるかもしれません。この思い違いがトラブルの元ですので、その辺りも含めて、改善する方法があればもっと素敵だと思います。
もう少し、「完了状態」を詳しく書いてみます。
表題: Aのフレームワークを組み込む
詳細: 具体的に何をしないといけないのかリストアップする
- Aのフレームワークを組み込むため、プロジェクトの設定を変更する
- Aのフレームワークとのリンクを追加する。
- Aのフレームワークはビルド済みのバイナリとヘッダファイルで提供されているため、それぞれプロジェクト内のフォルダに配置する。
- Aのフレームワークは、アプリからは必要な機能でAPIを呼び出す。
- Aのフレームワークの初期化処理と解放処理はそれぞれ、アプリの初期化処理と終了処理にAPIの呼び出しを追加する。
- Aのフレームワークを入れた時のテスト期間は上記の個数で判断するしかないですがココまで具体的にアップしているといいですね。
- Aのフレームワークを入れた時の手順書、導入するための手順これまで何をしたのかをリストアップして手順書を作っておくと引き継ぎの際に楽ですね。
このように書くとこの課題が完了状態、つまり、フレームワークが組み込まれた状態がどの状態かが定義されます。以下を満たしたときです。
- プロジェクト内のフレームワークにバイナリが配置されている。
- プロジェクト内のヘッダフォルダにヘッダファイルが配置されている。
- アプリの初期化処理にフレームワークの初期化処理が追加されている。
- アプリの終了処理にフレームワークの終了処理が追加されている。
- 利用する機能からライブラリのAPIを呼んでいる。
- フレームワークを入れた時のテストする。
- フレームワークを入れた時の手順書作成する。
ここまでなると、課題の重さが見積もれます。この課題が重いかどうかは「5. 利用する機能からフレームワークのAPIを呼んでいる」をどのように見積もるかになります。これが単純に呼べば動くものなら、問題ありません。しかし、呼ぶために、準備処理が必要、専用の画面を実装する必要があるなどが予想される場合には、この課題から分割する必要があるでしょう。「Aのフレームワークを組み込む」は1から4までを満たすところまで。5については、必要に応じて更に複数の課題に分割するなど、別の課題として登録していきます。
このように視覚化されると、経験者による思い違いもある程度、防止できると思われます。
いかがでしたか？
頭で分かっていても、改めて課題管理に詳細を定義するという作業はプロジェクト管理する上では必要なことなのかもしれません。課題の重さを自然と見積もっていることが多いのですが、書いてみることで視覚的に見ると課題の単位のばらつきに気が付くことがわかると思います。特に課題が書く前に見積もったよりも、重い場合に気が付きやすくなります。
それと、何をしたかが記録に残るので、手順書を残しながらするのもお勧めします。
コードの変更履歴を追うよりも、課題管理の進捗状況だけで、問題が起きたときや調査のときに役に立ちますね。
関連記事
【About】(http://qiita.com/sunstripe) - サンストライプ
制作チーム：サンストライプ
(月１WEBコンテンツをリリースして便利な世の中を作っていくぞ！！ボランティアプログラマー/デザイナー/イラストレーター/その他クリエイター声優募集中！!)
地域情報 THEメディア
THE メディア 地域活性化をテーマに様々なリリース情報も含め、記事をお届けしてます！！
https://the.themedia.jp/
ゼロからはじめる演劇ワークショップ
多様化の時代に向けて他者理解を鍛える
プログラミングワークショップ・ウェブ塾の開講！！！
様々なテーマでプログラミングに囚われずに取り組んでいきます。
詳しくはこちら ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
プログラミングサロン 月１だけのプログラミング学習塾
協力応援 / 支援者の集い
チーム：サンストライプ
プログラミングラボ
一緒にポートフォリオを作りませんか？現場の体験やそれぞれの立場から年齢関係なく作品を作りたい方々と一緒にチームを作って、作品を作っています。現場に行きたい人には、職場紹介や職場の体験や悩み相談なども受けております。
様々な職種からプログラミングの知識を得たい、デザインの知識を得たい、データーベースの知識を得たいという人が集まっております。
週１のミーティングにそれぞれの近況と作業報告して、たまにリモート飲み会などをしております！！
興味がある方は、DMに話しかけてみてください。
トラストヒューマン
http://trusthuman.co.jp/
私たちは何よりも信頼､人と考えてます｡
｢コンサルティング｣と｢クリエイティブ｣の両角度から｢人材戦略パートナー｣としてトータル的にサポートします！！
キャリア教育事業
広域学習支援プラットフォーム『のびのび日和』
https://slc-lab.amebaownd.com/