問題と課題と作業

「"問題" と "課題" と "作業" の違い」について、アプリケーション開発の現場を想定してその違いと分解時のポイントについてまとめます。

"問題" と "課題" と "作業" の違い

"問題" と "課題" と "作業" はそれぞれ以下のような違いがあります。

    問題
    「あるべき姿」と「現状」のギャップ
    課題
    問題に対する解決方法。
    現状とあるべき姿を近づけるための方法。
    作業
    課題を達成するためのステップ。

問題と課題は表裏一体の関係で、課題と作業は大項目と小項目の関係にあります。

課題解決の進め方

問題が上がった後はそれを解決していく必要があります。 その課題解決には王道があり、以下のようなステップを踏むことが多いです。

  1. 現状調査
    （必要な情報の収集）
  2. 対応の検討
    （解決方針決め）
  3. 対応の計画
    （解決方針にしたがって対応するために必要なタスクを洗い出し）
  4. 対応の実施
    （洗い出されたタスクを実施）

いきなり解決方針を考えようとしても難しい場合もあります。 なぜ解決方針が決められないのか？…それは何かしらの情報が足りないはずなので、何があれば判断できるかを考えてそれらを集めるようにします。 それまでは思い切って「判断しない」というのも判断です。

解決方針の種類

問題を解決する方針の考え方はリスク対応と同じで良いかと思います。 そのリスク対応の考え方は以下のような４つがあります。

  • 回避　：　問題が「なかったことになるよう」にする対応。
  • 軽減　：　問題が「解決されるよう」にする対応。
  • 転嫁　：　お金で解決。
  • 受容　：　何もしない。

例えば、アプリケーション開発において障害が発生したときの対応を考えると次のようになります。 「回避」はその障害が発生するケースを通らないように修正します。 「軽減」はその障害自体を解消させます。 「転嫁」はその障害によって損害が発生する場合を想定して保険を掛けます。 「受容」は何もしません。

 

コメント

コメントを投稿

このブログの人気の投稿

進捗遅延 の 原因 と 対策

今回は「進捗遅延の原因と対策」についてまとめていきたいと思います。 「計画は正しい」ことを前提として、遅延原因をベースにその対策はどんなものが考えられるか、以下では具体例を出して見ていきます。 実務上は以下の内容が参考になるかと思います。 スキルミスマッチ 追加タスク発生 他チームタスク未完成 非効率なプロセス 非効率な環境 非効率なメンバー 投入工数不足 スキルミスマッチ アサインしたメンバーのスキルとタスク難易度が一致しないことに起因する遅延。 基本的な対応はフォローを入れて過勤務対応になりますが、これで対応しきれなければメンバーチェンジも考えます。 報告例 「初参画のため立ち上げに（予定以上に）時間がかかっている」 「見積もりが甘かった（思った生産性が出ていない）」 「（担当者スキルに対して）タスク難易度が高かったため」 「品質が悪く手戻りが発生している」 「レビューに時間がかかっている（指摘が多く発生して収束しない）」 対策例 1か月以内に解消が見込める場合 フォローメンバーをつける。 作業内容に関するガイダンスの実施する。 着手前にレビュアーないし詳しいメンバーに修正箇所の説明を行うようにする。 上記作業は追加作業なので過勤務対応とする（＝フォローするメンバーの行うタスクに対する投入工数が減ることがないようにする）。 1か月以上かかるタスクの場合 担当者を変更する。 追加タスク発生 計画時には見えていなかった課題が発見されたことによる追加作業（タスク）が発生したことに起因する遅延。 追加タスクによる遅延は様々な形の "遅延" で表れてくるため、報告も様々になります。 報告例 「他の優先度が高いタスク（課題、レビュー）を対応していた」 「原因不明のエラーが発生した」 「見積もりが甘かった（タスクの漏れがあった）」 「仕様未確定な箇所が見つかった」 「仕様変更が発生した」 「手戻りが発生した」 「残レビューのみです（＝レビュー実施ができていない＝他タスク（課...
続きを読む

進捗会議 の アジェンダ

今回は「進捗会議のアジェンダ」についてまとめていきたいと思います。 アジェンダの必要性 進捗会議に限らず、会議前にアジェンダを作ることで「会議の目的を共有して無駄をなくす」ことができるようになります。 アジェンダ作成するのも時間がかかりますが…アジェンダなしで会議を始めてしまうと「参加人数×会議が延びた時間」のコストがかかってしまいます。 面倒ではあるのですが、プロジェクト全体を考えるとアジェンダは作っておくべきな気がします。 進捗会議のアジェンダ 以下に記載している項目は進捗管理する上で確認すべき内容の一覧ですが、開発規模や開発フェーズによってアジェンダの内容は変わると思います。 「進捗」「品質」「課題」は進捗確認という意味で確認すべきポイントですが、これらは状況によってそれぞれ別会議を設けることがあるようです。 連絡事項の共有 進捗確認 品質確認 課題棚卸 依頼事項の確認 以下では上記項目のそれぞれについて具体的な内容を見ていきます。 連絡事項の共有 主に、以下のような「外から入ってくる情報」を共有します。 また「チームへ向けた注意喚起、改善依頼」などもここで行います。 マイルストーン プロジェクト全体にかかわるアナウンス 他チームからの依頼事項 メンバーに向けた注意喚起 進捗確認 進捗会議のメインはこの項目だと思います。 計画されたガントチャート（現場では "WBS" と呼ばれることが多い？）に対して実績を確認し、遅延原因を特定、遅延対策を検討、その場で適用可能な対策であれば対策実施の依頼まで行います。 ガントチャート 品質確認 「品質レポート」とまとめてしまいましたが…設計フェーズであればレビュー指摘件数やレビュー指摘内容について確認します。 テストフェーズであれば一般的によく聞く信頼度成長曲線や機能別、要件別、混入工程別の障害件数などを確認します。 進捗確認と同じですが、状況確認したうえで、障害が多発している箇所もしくはまったく出ていない箇所について、その原因分析、改善対策の検討、改善対策の実施依頼まで行います。 品質レポート 品質の分析について細かく行い始めるとこれだけでかなり時間がかかること...
続きを読む

はじめに

初回投稿なので、今回はこのブログを始めるにあたってどんなことを記載していくか…についてまとめておきたいと思います。 一言でいえば初心表明ですね。 いずれの項目も今までに書籍や勉強会で学んだ内容を踏まえて吐き出していきたいと考えています。 プロジェクト管理 一言で「プロジェクト管理」といってもその内容は多岐にわたります。 PMBOKで言えばスケジュール、スコープ、コスト、品質、人的資源、コミュニケーション、リスク、調達、ステークホルダー…など。 PMBOK とはいえ、机上の話だけでは面白くないので、もう少し実務よりな内容で記事を書けたらいいな、と考えています。 進捗定例（定例の運営、報告） WBS作成 問題解決 ロジカルシンキング プロジェクト管理の問題解決にも関係しますが、 「漏れダブり」なく考えられることは大切なことかと思っています。 ロジカルシンキングに関しては、一般的な話の組み立て方の考え方を中心に記事を書いていきたいと思います。 時間管理 最近は「業務効率化」などで話題ですね。 「業務効率化」と「時間管理」は密接な関係にある気がしています。 「効率化（＝生産性をあげる）」には自分の時間をいかにコントロールして生産性をあげるかを考える必要があると思っています。 書籍などから学んだこともそうですが、普段生活していて思いついた効率化があれば記事にしていきたいと思います。 クレーム対応 社外の人（お客様筆頭に協力会社など含む）を相手にするときだけでなく、社内でもチーム跨げば社外も同然なので、これも必要な知識な気がします。 数冊読んだ感じだと何かしらの法則はありそうなので、そこを記事にまとめていきたいと思います。 メンバー育成 プロジェクト管理に関連しますが、チームメンバーも集まりたては各人スキルいろいろなので、そこをそろえるためにも育てなければいけないと思っています。 世の中にはだいたい "基本" と呼ばれるものがあるんですね。 教育に関しても実際に書籍で学習したこと、それを適用してみてどうだったか、などを記事にしていきたいと思います。 今回は「このブログで書きたいこと」についてまとめました。ポイントは以下の通りです。 プロジェクト管理 ロジカルシ...
続きを読む