非機能要求の認識ずれ
ざっくりとした仕様をもとに業務委託，特に準委任契約を実施する場合，ざっくりとした振舞仕様を作製する段階で，自社側は関係者とレビューを通して認識合わせが出来ていますが，委託側は振舞仕様を依頼されても，振舞仕様以外のことは推測でしか分かりません．
むしろ振舞仕様は分かりやすく，相手も不足に気付いて確認してくれる可能性が高いので，非機能要件こそ明記すべきなのです．
準委任なので，ざっくりとした説明で開発を進めてもらい，都度相談という形を取っていると，技術選定が概ね済んだ後に非機能要件を満たせないことが判明した場合に大きな影響が出ます．
- 言語・技術・アーキテクチャ
- 応答性
- セキュリティ
今回問題になったのが応答性ですが，非機能要件一覧表はIPAが出していますから，それをもとにざっくり記載して依頼するのがお互いにとってストレスなく進められるでしょう．
こういう存在にさっさと気付いておくべきだったのだ・・．
表示要件は明確に定義する
UI表示，特にパフォーマンスの制約を受ける場合は，表示要件を明確に定義しておかないと確認のやりとりが多くなります．
- Zoom out時の画像つぶれ問題
表示系で避けては通れないのがZoom out時の画像つぶれ問題です．このための対策として以下のような仕様を策定します．
1. Zoom outレベルを制限する
2. Zoom out時に表示を縮退する
1.であればここで終わりです．
しかし，1.にパフォーマンス面で問題がある場合には結局どこかで2を検討する必要があります．縮退する場合，ある閾値Xを超えた場合に表示をある程度まとめる，という仕様を取ることが多いでしょう．
パフォーマンス制約
- ある閾値を表示状況によらない固定値Xとするか表示状況による可変値Xにするか
閾値をズームレベルとします．ズームアウトするにつれて表示数は増えるので負荷が増大します．最大負荷を想定して，最小ズームアウトを固定値Xとするか，表示数に応じて閾値を変更する可変値Xとするか，の2通りが考えられます．
この仕様決定自体は要件により決まります．顧客がズームイン，ズームアウトした場合に挙動が固定ズームレベルで変化することを望むのか，フルスペックの動作を可能な限り継続したいのか，です．ソフトウェアの目的に依りますので，これを明確にしておく必要があります．
また，可変値とする方が要求レベルとしては高く，工数が多くかかることが想定されます．MVP（Minimal Viable Product）という視点からは，開発高速化のためにまずは固定値から始めることを選択，提案することが可能です．
画像つぶれの制約
こちらはズームレベルに対して固定値Xを設定し，対策できます．ある閾値以降はグルーピングした情報を表示というのを都度繰り返します．
ただ最も厄介なのはZoomレベルって，実際の表示ではどの大きさなの？というお話です．
ピクセル単位で指定することができますが，ピクセル単位の場合はディスプレイの画素数・インチ数で実際の表示長が異なります．また，Windows自体にも拡大・縮小の表示機能があるので，ますます訳が分からなくなります．
- ピクセルで指定する
- 表示ディスプレイ環境の画素数，インチ数，環境表示倍率を指定して，ピクセルで指定する
- 環境によらない表示単位を使用して定義する
ピクセルだけで指定するのは，表示確認に時間を要するのでお薦めしません．定義は明確ですが，見た目が思ったようにならない可能性があります．
以下が分かりやすかったですが，
Android では dp
Web ApplicationではCSSピクセル
を使用することでデバイスごとの差分を吸収でき，統一した表示長にできます．
なぜ外注で速度が上がらないのか
外注管理者に決定権がない
外注管理者に決定権がない場合、意思決定が必然として遅くなります。
- Case A: 外注先からの問い合わせ⇒外注管理者⇒決定権者
外注管理者から決定権者に問い合わせが必要なため、外注管理者が即断できる状況よりも時間がかかります。
- Case B: 外注先からの問い合わせ⇒外注管理者⇒X⇒決定権者
さらに悪いケースの場合、外注管理者が若手で決定権者の間にもう一人レビュワーを挟まなくてはいけないケースです。外注管理者はXに相談してから、決定権者に相談するというフローになるため、Case Aの倍の意思決定の時間がかかります。
Case A : 外注先からの問い合わせ⇒外注管理者⇒決定権者 のあるべき発注体制
まだこの体制には外注できる見込みがあります。このケースにおいては、外注先に発注すべき種類としては以下があります。
- 仕様まで完成した段階で外注先に発注する
狙いは新規の方針決定が必要な新規問い合わせを最小化することです。また、仕様まで完成している場合、抜け漏れ等の新規仕様は既存の仕様からソフトウェアの一貫性を考慮すれば、妥当な使用が得られ、決定権者への確認も最小限にすることが可能です。なお、本来であれば、そういった妥当だと判断される場合の仕様については、外注管理者に決定権が委ねられているべきです。
- 仕様まで完成していない段階で外注することは避けるべき
準委任契約の場合にあり得ますが、大雑把な仕様が決まった段階でプロトタイプ制作を外注先に依頼する場合です。Case Aの場合にこのような状況は避けるべきです。結局ToBeの形が定まっていないのにプロトタイプの制作を依頼したとしても、詳細仕様について新規問い合わせが乱発し、その結果として外注管理者がボトルネックとなって速度は上がりません。せいぜい細かい部分の動作確認を外部に委託できるメリットだけで、速度としては1.1倍程度にしかならないです。
Case B : 外注先からの問い合わせ⇒外注管理者⇒X⇒決定権者
これは外注として出すべきでない業務です。完全内製での対応を検討するべきです。このような業務を速度改善目的で出すのは誤りです。外注管理者の工数はXと決定権者の調整に消えます。
外注管理者が外注内容について十分な知識を有していない
外注管理者が外注内容について知識を有していない場合、 意思決定が必然として遅くなります。懸念事項としては”外注管理者に決定権がない”場合と同様です。
”外注管理者に決定権がない” は有識者に問い合わせる、あるいは、コードを追ってキャッチアップするというフェーズが必要です。新規問い合わせへの返答速度低下につながり、外注管理者がボトルネックとなって速度はあがりません。
そもそも新規問い合わせが詳述している事項そのものを理解する所から始まるので、外注管理者自身が担当するよりも時間がかかる可能性があります
外注管理者の教育期間を設ける
外注管理者が外注内容について理解する期間を、外注前に設けるべきです。外注管理者が仕様に関する説明を求められた場合には妥当な説明をできるだけの能力（仕様自体・周辺知識・仕様決定背景）を身に着けておかなければ、開発速度は上がりません。
外注管理者に対して外注内容よりも優先度の高い他のタスクをアサインしない
こういった期間を設ける余裕がなく、外注管理者が知識がない状態で外注に挑むのであれば、外注管理者に対して外注よりも優先度の高い他のタスクをアサインすべきではありません。知識のキャッチアップは新規問い合わせ毎に必要な工数の大小が分かれ、事前に評価することが不可能です。
一方で、外注している以上、外注管理者の手が空くことはありますので、そういった隙間時間を埋める目的で他タスクをアサインすることは許容されます。ただし、そのタスクが外注に対して優先度が高いものである場合には、外注キャッチアップが遅れ、ズルズルと尾を引いて外注自体の遅滞に繋がります。
外注先に対する教育期間が足りない
外注先のキャッチアップ期間が考慮されておらず、スケジュールに影響を与えます。既存業務ソフトウェアの改修を依頼する場合、勿論ですが既存業務ソフトウェアへのキャッチアップ期間が必要です。
一方で、外注先への教育が目的で、仕様を殆ど詰め切った段階で仕様書の作成を依頼する場合がありますが、その際には以下の注意が必要です
不要なドキュメンテーションを依頼している
外注先の既存仕様への教育を目的としてドキュメンテーションを依頼するのは避けるべきです。ドキュメンテーション自体には謂わぬとしれた慣習が存在し、外注先がそれに沿ったドキュメントを出してくる可能性はゼロです。
結果として本仕様の理解とは関係がないドキュメンテーション体裁のレビューという地獄絵図に陥ります。
必要な部分は外注管理者が埋め、確実に誰がやっても同じ慣習で仕上がるという粒度まで落とし込めた時点で、残りの部分を依頼する形が理想です。
外注管理者が上記事項を認識していない
そもそもマネージャーが個々人の全てのタスクを管理することは不可能です。こうした前提の下であれば、外注管理をアサインされた外注管理者は上記事項を満たした状況が整っているか自身で確認すべきです。体制が整っていない場合にはマネージャーに必要な対策を依頼するべきです。
ここで何とかなるという風に言われても頑なに拒絶するべきですし、結果として遅れは自身の責任になるので、予めマネージャーと認識を合わせておくことが肝要です
コミュニケーション頻度を上げる
チャットでのコミュニケーションではなく，オフライン・オンライン（リモート会議）での会議を積極的に設けることで，お互いの認識齟齬をなくし，スムーズな開発につながります．
特に外注先というのは会社を跨ぐので，コミュニケーションが悪くなりがちです．一方で，詳細仕様には見えない決定背景が大量に盛り込まれています．結果として，実装中に発生した違和感に対して，”これは違和感のある実装だが，決定背景が分からないため，仕様として定義されている通りに実装しよう”という意識づけになります．
これは好ましい状態とは言えません．仕様はいくら突き詰めて決定したとしても，実装を行ってから初めて分かる抜け漏れ仕様は存在します．仕様決定者と実装者が別れている場合，実装者は少なくとも仕様の決定背景を把握し，違和感を覚えたら仕様決定者と協議することがプロジェクトの成功につながります．
これを防止するためには，
– 仕様決定者が実装者に決定背景を共有する場を設ける
– 仕様決定者と実装者は定期的にミーティングを実施し，実装時に感じた問題意識を協議する
という必要があります．
上記例は仕様⇔実装の担当者が別の場合ですが，どのレイヤーで区切っても同様のことが言えます．要は下流の担当者が当事者意識を持てない状況で仕事を任すことは，問題の発見を遅らせ，プロジェクトの成功につながりません．
定期的なミーティング頻度がどれくらいか，というのは毎日15分程度，ショートミーティングで取っておくのがいいでしょう．本ミーティングでは，問題意識の共有にとどめ，仕様修正を実施するかどうかは別途ミーティングを設定します．
仕様通りにしか作成してくれないと嘆く前に
上記の章と関連します．
なぜ仕様通りにしか作成してくれないのでしょう？
発注者としては，仕様に問題があれば指摘が実施され，適切な対応がなされることを期待します．これは今までの内製のみで開発していたチームが陥る初めの落とし穴です．チーム内であれば，チーム員は勿論当事者意識を持って，また，仕様背景も十分に把握しているので，問題を問題を認識でき，距離感も近いので指摘が実施されます．
一方で，外注においては，特に準委任契約の場合，成果は強制されません．別に仕様通りに作成するだけでお金は支払われるわけです．勿論，発注者は仕様通りに作成することだけを期待していないので，次期契約には響くものの，そのプロジェクト期間に限ればそれに尽きます．
ただ，この状態はお互いにとってアンハッピーな状態です．発注者は言うまでもなく，実装者も主体性がない状態で作業している訳で，モチベーションがあがる訳がありません．
そのため，何とか当事者意識を持って主体的に対応してもらえるような体制を作り上げることが何より重要です．そのための方策として，上記で挙げたコミュニケーション頻度の増加があり，その他にも様々な手段が考案できるはずです．
コミュニケーション頻度の増加
ペアプロミング
問題指摘ごとの報奨，
等です．
あなたのプロジェクトにあった，主体性意識の向上対策を打ち出し，PDCAを回すことが重要です．
全てチャットで済まそうとするな
仕事の作業効率を落とす方法は，全ての連絡をメール・チャットで済ますことだそうです．会議を一切禁止にするだけで，仕事は一切回らなくなります．
これが現実です．記録に残したい気持ちも分かりますが，積極的に会議を実施すべきです．
