めんどくさく感じてるのはロイヤルティだけでなく任される「工程」の問題でもある

プログラミングをする人のイラスト(男性)
昨日書いた記事「フリーランスに求められるロイヤルティについて悩む」を読み返して思ったのは、確かにロイヤルティの問題もあるけど同時に工程の問題でもあるなということでした。そんなつもりはなかったたけどそうか上流工程も職責の範囲内か。。






職責を制限するためのフリーランス

なぜフリーランスで働いているか?という理由の1つとして「自分がやりたい仕事や出来る仕事に集中したいから」というものがあります。

1人のエンジニアとして会社に所属することには様々なメリットがあるんですけど、大企業で完全に分業されているならともかく中小企業でざっくり「担当」だと職責が曖昧になることがあります。個人的な経験でいうと、やりたくない「技術系」の仕事(酷いときはグラフィックデザインやPCメンテナンスも)がまとめて回されてくる、ざっくりした企画書だけでプロジェクトのリリースまで任される、外部委託のマネジメントをやらされる……など。

ステークホルダー全員から聞き取りをして立案してプレゼンして要件定義に落とし込んで、必要に応じて人員をアサインしてマネージメントして、進捗管理してっていう仕事が出来るか出来ないかで言えば出来るだろうけど、やりたいかどうかでいうと圧倒的にやりたくない。面倒だから。だからフリーランスのプログラマーやってるんです。報酬もSEではなくプログラマとしての報酬額だし(一般的に上流工程の方が高い)。

ただ契約内容を見直すと「ECサイトのバックエンド開発業務」なんですよね。上流工程って十分に開発業務と言えるのでは。。あれ?



「上流工程」は開発プロセスのどの工程なのか?

一般的に言って「上流工程」に分類される作業は「企画」「要件定義」「設計」ですよね。ISOで定められたプロセス・工程の定義としてはこうなっています。

ソフトウェアライフサイクルにおけるプロセス

  1. 企画
  2. 要件定義
  3. 開発
  4. 運用
  5. 保守

上流工程で言われる「要件定義」は恐らくここで言う要件定義プロセスのことではなく、開発プロセスに含まれる工程のことでしょう。

開発プロセスに含まれる工程

  1. システム要件定義
  2. システム設計
    1. システム方式設計
      …… システム要件を「ハードウェア」「ソフトウェア」「手作業」に振り分ける
    2. ソフトウェア要件定義
      …… ソフトウェアの要件(機能や性能)を決める。主にインターフェイスとデータ
    3. ソフトウェア方式設計
      …… ソフトウェア要件(機能や性能)をプログラムの単位まで分割する
    4. ソフトウェア詳細設計
      …… 「プログラムの単位まで分割された要件」をさらに「コーディンググが出来る単位」まで分割する
  3. プログラミング
  4. テスト
  5. ソフトウェア受け入れ


さてこの工程群のうち、上流はどこか?というと「システム要件定義」と「システム設計」ですよね。そこまでがシステムエンジニアのお仕事であり、プログラマのお仕事はプログラミング以降ということになります、、が、まあ現実にはそんな風にはなっていませんね。

分業がしっかりしている大企業ではそうなのかも知れませんが、僕がアサインされている企業規模だと外部設計(「システム要件定義」「システム方式設計」)までを上位の人間がやって、内部設計(「ソフトウェア要件定義」「ソフトウェア方式設計」)および「ソフトウェア詳細設計」以降はプログラマがやるという感じになっています(上流の人員に技術的知識が不足しているため)。


契約を見返しても「プログラミング(コーディング)業務」ではなく「開発業務」とあるだけなので、やはりこれ、職責に入るんでしょうね。そうなりますよね。そうなるのかー



どこまでが「自分の仕事」かを考えながら手を動かすのは大事

フリーランス特有なのかも知れませんが、契約の範囲を超える分の仕事はしなくて良い仕事です。サービスのつもりでやっても感謝されることはまずなくて、次のハードルが上がるだけです。ハードルは上がるけど報酬は上がらないので、やるだけ損です。


もちろん自分の契約範囲についてはしっかりこなす必要があります。

今僕が直面しているプロジェクトに関してざっくり言えば、システム要件を決めるような場所には参加する必要はありません。ロイヤルティの話でも書きましたが、企業としての経営戦略に関しては必要な部分を共有できていればいいのであってそれ以上は必要ありません。人付き合い的な意味で参加してもいいんですけどその場合はただの置物です。音声出力をオフにしてBGMに聞き流しながら他の作業やってるでしょう、たぶん。


一方で現場のミーティングには参加する必要があります。僕に必要なのはソフトウェア要件定義をするための情報を集めることなので、どんな機能が必要とされていて、どんなプログラムを用意すれば良いのかを決める、その工程のためにミーティングに参加して情報収集せざるを得ません。面倒ですけど、困るのは自分なので。



そのうちはっきりさせる必要があるかも

今はそういうことなので要件定義からきっちり入っていくのが必要なんですけど、しかし、人員が減り続けてどうもエンジニア1人1人に掛かる負荷が大きくなり始めているので、いずれきちんと話をする必要が出てくるかも知れません。まあ、職責とカネの話です。難しいですけどね。もっと金をくれといいたいんじゃなくて、その部分は他の出来る人を雇ってくれ、今の条件で良いから職責を絞ってくれといいたいんですけどなかなか伝わらないんですよねー。


仕事って形がありそうでないからなあ。難しいっすわ。