仕事の進め方について

PG兼任のSIerとして、自分が意識していること、新人がプロジェクト参画するにあたって意識してほしいことを明文化。随時改善中。

意識すべきこと

論理性

論理的な意思決定を行い、その妥当性を説明できること。
論理的な経緯が見えない発言・行動については"なぜそうしたのか"と質問されることになる。失敗の原因が、論理的に説明可能かどうかで、その後の信頼性は大きく変わる。

• 意思決定のための仮説は適切か。
• 意思決定の思考プロセスを論理的に説明できるか。

× 手軽そうなので、Aの作業から実施しようと思います。
◯ 今月中に実施すべきタスクはA, B, Cがあります。
  Cはxxxの作業のクリティカルパスで、遅延した場合に影響があるため、Cから着手いたします。

QCD+S(品質、コスト、納期、作業範囲)

ビジネスとしての基本的な観点はQCDである。早く安く、品質が高いものを提供できる会社・人が重宝される。
S(cope)は、納期に近い考え方だが、時間軸の短縮は現場負荷が上がるが、作業範囲の短縮は現場の負荷を軽減する。アジャイル開発においては、スコープを柔軟に調整することで品質とコストを維持することが多い。

品質(Q)

プロジェクト全体の品質を高めることを考えているか。

• 品質に関わるリスクを認識し、報告できているか。
• 品質を改善するための提案が行えているか。
• 一度発生した問題を繰り返していないか。繰り返さないための施策を実施できているか。

効率性(C, D)

プロジェクト全体を効率よく進めることを考えているか。

• 自分の作業範囲だけではなく、プロジェクト全体を俯瞰し、クリティカルパスを理解しているか。
• 手戻りや遅延などのリスクを考慮し、適切なタイミングで報連相を実施できているか。
• 適切なタイミングで優先順位の変更を実施できているか。また変更したことを周囲に共有できているか。
• 効率よくプロジェクトを推進するための提案が行えているか。
• 一度発生した問題を繰り返していないか。繰り返さないための施策を実施できているか。

スコープ(S)

管理可能な作業範囲を意識できているか。

• 自分が正しく工数を見積もることができるスコープを理解しているか。
• 当初依頼された作業範囲で納期が間に合わない場合、雑な仕事をしたり、結果品質の低下につながる残業をするのではなく、優先順位を見直し、品質を下げずに作業範囲を縮小することを選択肢として検討しているか。(システム開発では、技術的負債を増やすような品質劣化は、結果的に効率性を悪化させる。)

目的意識の共有

いかに早く安く、品質が高くても、見当違いの成果に価値はない。プロジェクトレベルの目的意識共有には、インセプションデッキがおすすめ。

作業者として

タスクの目的と背景を理解し、成果物がその目的に対してどのように活用されるか整理した上でタスクを進めているか。

• 完了条件が明確化できているか。
• 不明点がある場合に、作業依頼者に確認した上で作業を進めているか。

作業依頼者として

依頼先作業者が、タスクの目的と背景を理解し、成果物がその目的に対してどのように活用されるか整理できているかどうか、確認しているか。

• 依頼先作業者が完了条件を明確化できているか確認しているか。

コミュニケーションについて

報連相

報連相の基本

• 見解+その根拠+次のアクション

× アプリで問題が起きているようです。
  (根拠のない意見)

◯ ユーザーからアプリにアクセスできないという連絡がきました。
  確認したところ、原因はアプリサーバのプロセスが落ちているからです。
  プロセスが落ちていることは、xxxという方法で確認しました。
  (事実の報告。原因調査については、根拠を説明し、見解が推測ではないことを示している。
   ただし、"プロセスが落ちている"という事実に対するアクションを報告していない。)

◎ ユーザーからアプリにアクセスできないという連絡がきました。
  確認したところ、原因はアプリサーバのプロセスが落ちているからです。
  プロセスが落ちていることは、xxxという方法で確認しました。
  しかし、プロセスが落ちた原因について自分では特定ができなかったので、xxxさんに相談する予定です。
  (根本的な原因まで深掘りし、今後のアクションまで示されている。)

コミュニケーションのコツ

• 一文で話す

  • 考えながら話してしまうと要点がぼけた説明になってしまう。はじめの一文に要点をまとめること。
  • 一文に対して、"だからなに?"、"つまり何が言いたいの?"といったツッコミが入らないか考える。

• 事実と意見を混同しない

  • 意見を話すときは、なぜその意見にいたったのか事実を根拠にして説明する。説明がない意見は事実と混同される。
  • 事実についても事実が報告者の誤認の可能性を疑われないように、複雑な事実やレビュアーとの信頼関係が薄い場合はエビデンスを利用して事実性を明確にする。
    

× アプリが表示できません。サーバーが落ちているので、サーバーを再起動します。
  ("アプリが表示できない"ことは事実かもしれないが、
   "サーバーが落ちている"ことは短絡的な推測に基づく意見かもしれない。)
◯ アプリが表示できません。サーバーが落ちていると推測されるので疎通確認をしたところ、
  サーバーから応答がありませんでした。再起動します。

• 質問を理解して、質問に回答する
  • 結論をまず話す。結論とは、クローズドクエスチョンならyes/no、オープンクエスチョンなら5W1Hをまず回答する。
  • 提出前に、相手の質問を読み直し、質問に答えているか確認する。

質問: この仕事は期日内に終わりますか?(Yes or Noを期待)

× この後やることは、AとBとCがあって、Aは着手済みで、BとCはまだ未着手ですが、プロジェクト外でDもやらなければならず・・・・
  (期日内に終わるのかどうかがわからない。)
○ すみません。期日内に終わらない可能性が高いです。Aは着手済みなのですが、B, Cが未着手でxxx人日かかる見込みです。 

• 文脈に依存した説明をしない。トーンセッティングする。
  • 客観的にそれだけで理解できるローコンテクストな文章を書いているか確認する。
  • こそあど言葉や、ミスリーディングな言葉、曖昧な定義の言葉は避けましょう。

× そういえばこの前のお客様の話ですが、・・・
○ A社様のXプロジェクトの件で相談させてください。・・・

• 質問は一問一答の質問を行う
  • 一問多答の質問は、回答者が質問者の意図がわからず何を答えればよいか回答に困る。
  • オープンクエスチョンは心理的負担が高く、クローズドクエスチョンの方が負担が低いことを意識しよう。

× このタスクがよくわかりません。教えてください。
　(質問の意図が不明。何を答えればよいかわからない)
◯ このタスクの目的について確認させてください。xxxという認識でよろしいでしょうか。
  ("タスクの目的について確認する"という会話の目的をトーンセッティングし、
　　Yes/Noで答えられる質問をしている。)

コミュニケーションの媒体を積極的に使い分ける

• チャット: 簡潔に返事がほしい
• 電話: 緊急、もしくは複雑な事象を説明したい
• ビデオ会議: 電話より、さらに複雑な事象を説明したい
• メール: エビデンスを残したい。情報を整理して残したい場合。お客様との文書のやりとり。

タスクの進め方

タスクの進め方

• タスクを理解する
  • タスクの完了条件を決定するためにタスクの背景や目的を理解する
  • タスクの完了条件を決定する
  • タスクの完了条件が間違っていないか指示者に確認する
• タスクの工数を見積もる
  • タスクの完了条件達成までのステップを整理する(タスクを効率的に完了するための方針決定、タスクの分解)
  • 各ステップの工数を見積もる
  • 作成したステップ(方針)と工数の見積もりについて、レビューを受ける

タスクの要件定義

• 背景

ユーザーからのリクエストで、xxxが不便だと言われた

• 目的・課題
  • 目的は"課題"を解決すること、であることが多い

xxxのユーサビリティを向上すること

• 方針・今後のアクション
  • 目的・課題を達成するために選択肢を検討し、その時点で最良のものを選ぶこと
  • 人に説明する場合は、いくつかの選択肢を考慮した結果選んだことを伝えるために、なぜ選択肢を切ったのかも説明すること
  • また効果測定ができるように検証方法を検討しておくこと

ユーサビリティの定義はxxxであるとする。xxxを向上するために考えられるアクションは以下の通りである。
xxxという理由から、今回は1の施策を実施する。
検証はxxxの観点で、xxxを計測する。
1.xxx
  Pros: xxx
  Cons: xxx
2.xxx
  Pros: xxx
  Cons: xxx
3.xxx
  Pros: xxx
  Cons: xxx

その他

どれだけ働けばよいか

• 自分が見積もり約束した作業の納期(コミット)は絶対に守ろう。
• どうしても守れない場合は、早めに遅延リスクがあることを先輩に相談して、対策をたてよう。
  • 報連相が行われていない場合は、自業自得となり残業もやむなしとされるかもしれない。
• 最終的には、契約期間におけるアウトプットの総量が、お客様もしくは先輩の期待値を超えていれば、プロジェクトに継続雇用される。

自己研鑽の時間がない

• 自己研鑽することは、アウトプットの量を質的にも量的にも増やす。
• 自己研鑽の時間が0の状態が長期化した時点で危険信号
  • アウトプットの総量が期待値を超えなければ黄色信号だが、アウトプットを残業で増やそうとすると、効率化を検討する時間もなくなり負のサイクルに陥る可能性が高いので赤信号。身体を潰す前に誰かに相談しよう。