概要
Webエンジニアの業務では、SEの業務領域である要件定義や設計、時にはマーケティングや予算管理等のスキルが求められることもあります。
特に自社開発となると、営業やマーケターといった非エンジニアとコミュニケーションを取りながら、システムの設計や実装を進めるケースが多いでしょう。
その際、新米Webエンジニアへ繰り返し伝えることが特に多い3つの紹介です。
組織や社風にもよるので一概にどんな環境でも共通するものではありませんが、参考までに。
（どちらかというと社内向けの備忘の側面が強いです）
1. 言われた通り作らない
結果的に、言われた通りのものを作ることはもちろんあります。
が、最初から言われるがままに実装するのは避けるべきです。
システムはあくまでも目的を果たすための手段に過ぎません。
依頼者が考える目的と解決策が、エンジニア視点だと異なることも多くあります。
そもそものやり方を変えたり既存ツールで解決できたり、全く別のアプローチを取ることで、提案された解決策以上の効果を生むこともあります。
エンジニアはシステムを作るプロフェッショナルですので、システム設計や技術領域を知っていないと出てこない解決策を考えついてこそプロフェッショナル足り得ます。
もしこれを考えず、言われたものだけ作っていた場合、思考停止に陥りクリエイティブな発想力が身に付きませんし、当初の想定以上の価値は生まれません。
つまり期待未満か期待通りのアウトプットしか期待できなくなります。
2. これってできますか？にYes/Noだけで答えない
これってできますか？
は単純にcan?cannot?の質問ではなく、「できるならその対応をお願いします」の前フリ質問であることが多いです。
そのため、簡単に「できる」と答えると代替案を考えるまでもなく、本来手段であるはずのシステムが固定化されて、実行に移る可能性があります。
1の「言われた通りに作らない」に通ずるところがあるのですが、必ず「なぜその質問をするのか？何を成し遂げたいのか？」目的を確認した上で、目的を達成するためのアプローチを選択するステップを踏みましょう。
エンジニアと非エンジニアにおける言葉のすれ違いはよく起きるので、以下togetterが結構面白いです。
3. 期日と要件の決まっている案件に対し、思考停止で無茶をしてでも間に合わせようとしない
「いつまでにこれを作る」というissueに対して、責任感が強いがゆえに、残業してでも間に合わせようと限界以上の働きをしてしまうことがあります。
こういう事態は往々にしてQCDSのバランスが崩壊していることが多いです。
そういった事態は関係者内でQCDSという概念が知られていない、あるいは意識できていないために起きます。
- Quality(品質)
- Cost(コスト)
- Delivery(納期)
- Scope(範囲)
- ※ SはServiceだったりFだったりもする
QCDSはトレードオフの関係にあります。
「最高品質のものをコストを全くかけず、最速で全部やる」＝QCDS全てMax
というのは夢物語です。
高品質と短納期であればその分コストは増します。
例えば
- 郵便で速達を頼むとQualityは維持したままDeliveryを短くするので、Cost(速達料金)が増します。
- ファストフードはCostを抑えて提供スピード(Delivery)も抑えるので、時間をかけてゆっくり作る高級レストランよりQualityは落ちます。
つまり
- 不具合を軽微に抑える「高いQuality」
- 期日をしっかり切った「厳密なDelivery」
- 要件を全て満たす、「広範囲のScope」
と、最初からQCDSのうち3つが固定された案件は必然的にCostしか可変要素がなく、結果として人員追加投下や残業でカバーせざるを得なくなります。
あるいはそのCostをMax投下したとしても間に合わず、
- 重大な不具合を起こすQualityの低下
- 期日が守れないDeliveryの未達
- 必要な機能が揃わないScopeの未達
にも繋がることがあります。
そのためにはQCDSの概念をエンジニアだけでなく関係者全員が理解しておくこと、理解した上で無闇にDeliveryを固定しないことを浸透させていく必要があります。