kazasikiがプログラミングするブログ

プログラミングとかコンピュータとかWebとか

非エンジニアがエンジニアの作業品質を管理するためにするべきたった1つのこと

非エンジニアがエンジニアの作業品質を管理するためにするべきことを書きます。

前置き

今回の記事は珍しく非エンジニア向けの記事です。例えば、エンジニアに作業を依頼するもしくは発注する企画職の人を想定しています。
エンジニアの人も知っておいたほうが良いと思います。なぜなら作業品質を依頼者に示すことはお互いが安心して開発をすすめるのに必須の要素だからです。
以下の文章では、非エンジニア側の人間を依頼者と記述します。基本的にコードは全く読めない人間を想定します。

依頼者目線で作業を分解する

作業を細かく分けるのは誰でもやると思います。ただ、このとき注意することが1つ有ります。依頼者が作業の完了を確認できる単位に分解することです。 例えば、DBを構築することは作業の単位になりません。エンジニアではない依頼者は作業の結果を確認できないからです。簡易的だとしても入力フォームを作り、入力結果を表示するところまでセットで1単位としましょう。作業の分割を依頼者による確認方法とセットで必ず考えましょう。

メリット

このように作業を分解することのメリットはいくつか有ります。
まず、進捗が依頼者の目でも確認できます。絶対にエンジニアの自己申告を信用してはいけません。
次に、依頼者が早い段階で品質を確認できます。早い段階で動かせる物を用意してもらえれば依頼者でもバグに気づくことが出来ます。テストは開発の終盤にまとめて行うことが多いですが、進捗の途中であってもバグがない状態を維持するようにお願いしましょう。バグを多く作る作業者になにか対策を施すこともできます。この判断が早めに出来るのは大きなメリットです。

デメリット

もちろんデメリットもあります。それは依頼者が作業の完了を確認できる単位エンジニアが最も効率的に作業できる単位と一致しないことです。
ただ、これは信頼関係を構築できてないエンジニアと協業するためには必要なコストです。許容しましょう。
また、依頼者にも確認するコストがかかりますが、これはそもそも必要なものでしょう。途中経過を見れたにも関わらず確認を怠った人に、最終結果に文句をつける権利はありません。

まとめ

以上に述べた作業の分解手法は、ストーリーポイントと言われる手法の一部分だけ抜き出したもので、どちらかというとアジャイル開発でよくつかわれるアプローチです。
また、エンジニアと依頼者に信頼関係があればこのようなテクニックは不要だと思えるかもしれません。が、私はそんなに贅沢が言える環境ではないので こういったテクニックが必要なのです。 ¯\_(ツ)_/¯