受託開発でのプロダクティビティエンジニアに挑戦してみた
昨年夏頃から長期的なプロジェクトにアサインされ、そこでプロダクティビティエンジニアを意識して動いてみました。クライアント、他社さんなど社内外でのやり取りが多い中で、受託開発でプロダクティビティエンジニアとしてどう取り組んでみたか書いてみます。
プロダクティビティエンジニアとは
上記のブログで注目され、「方向>開発フロー>スキル」という順番での考え方をするエンジニアがプロダクティビティエンジニアになります。
エンジニアが効率的に実装できる環境を整えるエンジニア、と私は捉えています。
目指した背景
私のここ最近の意識として以下の2つがあります。
- プロジェクトを効率的にまわして利益を出す
- エンジニアが成長できる機会を作る
今までだとサーバサイドやフロントエンドのエンジニアとして実装がメインでした。ただ、実装フェーズ時には、
- すでに方向や開発フローがほぼ固まっている
- 上記を方針変更するのはコストがかかる
- 自分の気になる技術を試しづらい
などからプロジェクトの効率化、エンジニアの成長の機会を増やすという実現をするには手が出しにくい状況でした。
その中で先ほどのブログを拝見し、またここ最近は業務的にも実装だけではなく要件定義や仕様調整をする事が増えてきたため、良い機会なのでプロダクティビティエンジニアを目指してみたという背景になります。
クライアント・他社との調整
今回のプロジェクトの座組は以下になります。受託開発の中では関わる会社さんが多く、特に技術面でのやり取りが多い座組でした。
- クライアント
- 私の会社:サーバサイド・フロントエンド
- A社:インフラ
- B社:デザイン・フロントエンド
- C社:API提供
私が行った事は以下になります。
- 要件定義フェーズから打ち合わせに参加
- どういう事をやりたいかクライアントとの共有
- 上記に対する技術的な判断やより良い方向の提案(主にコストや実装し易さの面で
- ここはこの会社さんにお願いした方がよいなどのタスク調整
- 他社とのAPI設計やデザインマージを考慮したHTMLの対応依頼などの調整
毎週定例という形で打ち合わせに参加していたため、コミュニケーションコストはそれなりにかかっています。ただ、要件定義や仕様調整 = 方向を決める段階で技術的な判断やタスク調整をする事で、その後のフロー検討や実装に生き、その後の無駄な調整コストを省く事が出来ました。ここにコストをかけたのは総合的に良かったと思います、クライアントからも評価頂けました。
また、色んな会社さんと関わると「こういうやり方もあるんだ。」と自分の考えにないやり方(方針、技術どちらも)に遭遇する事もたまにあり、開発フローの選択肢が広がったのは大きな収穫でした。
プロジェクトマネジャー(PM)・ディレクター(DR)との役割
エンジニアはPMやDRとの仕様調整をする機会はよくあると思いますが、なるべく実装に集中できる環境を実装を担当するエンジニアに提供したかったため、調整事項は私がなるべく受ける形で対応しました。
ここ最近、要件定義からエンジニアが参加するならPM、DRいらなくね?という話をたまに聞きます。これはプロジェクトによりけりかなと私は思います。
例えばキャンペーンサイトなどの1〜2ヶ月程度で終わるプロジェクトの場合、関わるメンバーが少ないため、こういう場合は下手にメンバー間のコミュニケーションコストを増やすよりも、自分で要件定義から実装まで一通り関わった方がコスト割けるので効率的だなと思います。(その代わり自分への責任やタスク量は必然的に多くなりますが
今回の場合、長期的なプロジェクト、関わる会社やメンバーが多かったため、明確に境界を設けたわけではないですが、以下のような担当になってたかなと思います。
- 自分(エンジニア)
- PM、DR
- クライアント・他社との仕様調整
- エンジニアとの仕様調整(主に私と
境界分けてしまうと変に意識してしまうため、ある程度緩く境界をもっておのおの調整するスタイルはやりやすさと効率さを感じました。また、人に依存してしまうという事も緩くする事で緩和できたかなと思います、特定の人への依存化はリスクが大きくプロジェクトとして一番やってはいけない事なので。
クライアントの要望と実装難易度とのバランス
今回、1つの反省点としてクライアントの要望を聞きすぎたために、一部機能で実装の難易度、処理の負荷が高い点がありました。
- CMSで登録してサイト側に表示する機能
- 必須ではなくかつチェックボックスを多用する複雑なフォーム項目がいくつもあった
- この時点でDB設計が難しいものになる気配は感じた
- 取得する際も各項目に対して複数の条件を指定せざる得なくなった
- LEFT JOIN多用とWHERE句がカオスになる気配は感じた
その結果、
SELECT * FROM table_1 LEFT JOIN table_2 ON table_1.id = table_2.id ・ ・ // 5回ぐらいLEFT JOINした・・・ ・ WHERE table_1.name = "test" AND table_2.age BETWEEN 1 AND 10 AND ・ ・ // WHEREが数十個できた・・・ ・
私がこのSQLを作った時は人生で一番最悪になるSQL作ったと思いました。(汗
例えば必須項目にする、チェックボックスではなくラジオボタンにする、項目の組み合わせ条件をある程度絞るなどの仕様で調整していれば、もっとより良い実装には出来たと思います。
クライアントの要望と実装難易度はたまに反する場合があり、こういった場合はきちんと設計や実装を考慮して早めの方向転換、代替案を調整すべきだったというのが一番の反省点です。(クライアントの要望聞くと喜んでくれるので何とも悩ましいですが
テスト品質
プロジェクトによってはテスト品質報告書なるものを提出する場合があります。今回のプロジェクトでも提出しましたが、そこで課題が1つありました。フロントエンドのテスト品質についてです。
サーバサイドの場合は今まで以下の方針をテスト品質としていました。
- サーバサイド処理全体のコード量算出
- テストコード全体のコード量とテストケース数算出
- 上記算出値からテスト密度を算出しそれをテスト品質とした
今回の場合、フロントエンドの処理が大半を占めていましたが、
といった経緯もあり何をもって品質とすべきかと頭を悩ませました。
今回の場合は以下の方針で行い、テスト密度が低い部分は人によるテストで補っているという形で報告しました。
- JSファイル全体のコード量算出
- 主な処理がAPI通信だったのでAPI通信1つに対し以下のテストケースを算出
- 正常系処理テスト1つ
- 常系処理テスト3つ(レスポンスなし、404、500)
- コードとしてはないが実装段階でエンジニアが行っていると想定した
- 上記算出値からテスト密度を算出しそれをテスト品質とした
これでなんとか通りましたが、フロントエンドがメインになるのは要件定義フェーズで分かっていたため、早めの段階からテストフレームワークを導入していれば、実装とテスト両方の品質、作業効率がより良いものになったなと思いました。そして、ここはまさにプロダクティビティエンジニアがやるべき事だと感じました。
査定評価がしづらい
話は変わって思いっきりお金の話になりますが、査定も1つ課題かなと思います。
私は一応開発部エンジニアなので査定基準としては以下になります。
- エンジニアスキル
- サーバサイド
- フロントエンド
- インフラ etc
- プロジェクト貢献度
- その他
ただ、プロダクティビティエンジニアの場合、技術よりも方向や開発フローがメインになるため、エンジニアスキルが評価の軸になると査定ではなかなか評価が上がらない可能性があります。
イメージ的にはエンジニアとPM、DRの中間に近いポジションではあるので、それに対する評価基準をどうするかというのは今後議論が必要な点と感じました。(お金はたくさん欲しいので
まとめ
今回、プロダクティビティエンジニアを意識して取り組んでみました。私が行った事がプロダクティビティエンジニアになるのかというのは、正直やってみて何とも分からなかった、というのが正直な所です。最近になって出てきた職種ですし、言語化するのもなかなか難しいため、しばらくは手探り状態な感じで引き続き精進したいと考えてます。
ただ、今までとの一番の違いとしては、クライアント、他社さん、PM、DR、エンジニアと今回は多くの人との調整やコミュニケーションがありました。その中で自分にない考えややり方が数多くあり、そこは収穫でモチベーションにもつながりました。
そして何より皆で一丸となってものを作っている感覚を感じ、リリース時の達成感は今までで一番強かったです。
もしプロダクティビティエンジニアに興味がある方がこの記事を読んで参考になれれば幸いです。