読者です 読者をやめる 読者になる 読者になる

Tbpgr Blog

Ruby プログラマ tbpgr(てぃーびー) のブログ

エンジニア立ち居振舞い: 課題解決フローと継続的改善

f:id:tbpg:20161112232940p:plain

id:hitode909 さんのお題にのった投稿の数々が興味深く、
自分ものってみることにしました。

お題「エンジニア立ち居振舞い」

blog.sushi.money

課題解決フローと継続的改善

(ソフトウェア)エンジニアとしての業務は基本的に何かの課題を解決することです。

また、ソフトウェア開発の業務は自動化、効率化の範囲を広げやすい仕事なので、
そのことについて意識しながら作業しています。

以下に自分が課題と向き合う際に普段行っている手順をまとめてみます。

1. コンテキストを把握する

その業務のコンテキストを把握します。

  • 目的は?
  • 前提条件は?
  • 期日は?
  • その領域に詳しい人物はだれか?
  • その課題が発生している根本的な要因は何か?
  • etc

2. 外部記憶の準備をする

タスクに取り掛かる際にMarkdownのファイルを作成して作業に関わる情報を記録できるようにします。
基本は自分用のメモですが、必要な情報がでてきたら esa や Qiita などに共有します。

これがあることで、今やっていることに関する情報が階層だって見やすくまとまった状態で作業ができます。
細かなところで以下のような利点があると考えています

  • 物忘れ対策
  • 調査タスクなどの際、調べた量が増えてきた場合に同じようなことを調べないようになる
  • 人に相談する際にそのまま自分のコンテキストを見せることができる
  • 割り込みタスクからの復帰コストが低い

3. 影響範囲を考える

  • 例えばシステム内における影響範囲はどの程度か?
  • 例えば組織内における影響範囲はどの程度か?
  • 単発なのか?今後も発生するのか?

4. 解法案を検討する

  • パワープレイで解決するか?
  • 個人の中で効率よく解決する方法を見つけるか?
  • チームに共有できるレベルで効率的な解放を見つけるか?
  • 長期的に効率化するか?
    • ありもののツールを使うか?
    • 新たなツールを作るか?

1のコンテキストと3の影響範囲の内容を元にこれらを検討します。
必要であれば調査をしたり、知見を持っていそうな人物に話しかけたりします。

この際に有用な情報を提供してくれたサイトがあれば、業務後にブックマークをしたり
スターをつけたり、ストックしたりして感謝の念を送ります。

5. 作業計画を立てる

解法案の調査・検討の結果選んだ選択肢を使った課題解決に関する作業計画を立てます。
できるだけ小さい粒度にして、一定数(具体的なところは決めていない)以上のステップがあるようなら
自作のCLIツールでそのステップをTODO化します。

6. 粛々と実施する

各ステップに着手します。
ポモドーロ・テクニックを使って休憩を挟みながら行います。

作業中は思考の過程をSlackの分報に垂れ流します。
リモート勤務の際は特に意識して多めに垂れ流します。

7. 完了

各ステップを終え、対象タスクを終えます。

8. 共有する

以下のような情報があれば共有します

  • 複数回作業が発生しそうな場合の作業手順
  • メンバーに共有することでメリットが発生しそうな知見
  • 再度作業が発生しそうで自分が忘れてしまいそうな知見

9. 成長した自分を元にした新規のタスクを作成する

作業の経過で得た知識を元に、新たに

  • 改善できそうな点
  • 問題点
  • 質問

などが発生することがあります。
タスク化する価値がありそうならタスク化します。

まとめ

自分が普段どんなことを考えながら仕事を進めているか振り返るよい機会になりました。