エンジニアのタスクは、分解して整理しよう
はじめまして、LIDDELL株式会社（以下、リデル）エンジニアの大塚です。
GWは楽しめましたか？
私はせっかくの機会だったので、友達と集まり上野にある国立科学博物館に行って、科学・歴史・地理に関する問題の原因推論と課題解決案を議論して楽しんでいました。
さて、今回のタイトルは、「エンジニアのタスクは、分解して整理しよう」です。
私がエンジニアとしての仕事を、どのようにタスクに分解して業務を進めているのかが参考になればと思います。結論から言うと、当たり前のことを当たり前にするだけなのですが..
今回紹介するタスク分割が上手くなると、タスク分割が必要な仕事をしている人はもちろん、エンジニアとして重要な、プログラミングのコンポーネント分割や関数分割、API分割も上手くなったりするので、ぜひ一読してみてください。
概要
結論の前に、タスク分割の前提とタスク分割の考え方をお伝えします。
読み飛ばしても、問題ありません。
前提として、リデルで行うエンジニアのタスクの傾向をお伝えします。
自社Productの中に仕事が存在します。
仕事は粒度によって、「Project」「親タスク」「 タスク」の3つに分けられます。
「親タスク」以下の粒度では、基本的に UI(フロントエンド) と API(バックエンド) 両方実装することが多いです。(実装以外の仕様などについては、共有認識のため、２人以上になります)
エンジニアのタスクは、Project(or 親タスク)を分割したサブタスク or タスクのどちらかです。
Aside: タスク分割の考え方
一般論として、タスク分割の考え方には以下２つのアプローチが存在します。
私の場合、Project(or 親タスク) をサブタスクに分割する時に使用しています。
トップダウン設計: 段階的に詳細にしていく設計技法である。最初にシステム全体を定式化し、その時点では個々の詳細には立ち入らない。その後、システムの個々の部分の設計を段階的に詳細化していく。
ボトムアップ設計: 最初にシステムを構成する個々の部品を細部まで設計する。そして部品群を組み合わせてより大きな部分を作っていく。
結論
ある粒度の大きさの仕事(Project or 親タスク)は、トップダウン設計で分解することで、タスクのゴールや共通認識を整理しております。
トップダウン設計の考え方から、プレフィックス「UI(フロントエンド)とAPI(バックエンド)」などに分割します。
サブタスクとしてタスクを分割して、タスクの分量や実装内容を整理します。
それぞれのサブタスクの input と output を定義し、相談します。
これらのサブタスクの実装完了が全てのタスクであると共通認識としてすり合わせます。
（この段階で、仕様の定義漏れやサブタスクの設定漏れがあったりするので、いつも助かっています！）
さいごに
今回は、タスクの分解方法の一例を紹介してみました。PCでプログラミングするのが仕事と認識されがちなエンジニアも、実は実装自体は仕事のほんの一部であり、実装前の準備がなんだかんだ大切であることをお伝えしてみました。
私自身、業務を進める上で固めていった今回のタスクの分解方法によって、何度も抜け漏れを事前に発見できましたし、副産物として、コンポーネントの分割や、API設計にも応用できとても役に立つテクニックだと思っております。
最後まで読んでいただきありがとうございました。
インフルエンサーマーケティングの
LIDDELL／リデル
サービスの詳細は…
様々な職種で一緒に働く仲間を募集しています。
この記事が気に入ったらサポートをしてみませんか？