ベンダーコントロールについて昨年度やっていていろいろ勉強になったのですが、そこで学んだことや大変だったことなど。
Contents
相手へのリスペクト
当たり前ですが、開発者へのリスペクトですかね。
ウォーターフォールタイプの開発だと設計(上流)→開発(下流)とわかれており、あくまで役割なのですが、上流=エライ、下流=エラくないみたいに思う方も一定数いるかとおもいます。
私はフェーズが分かれた工程をあまり経験していないのと自分が開発者のため、そんなことはありませんでしたが。
こういうのって態度に出ちゃうんですよね・・・営業とエンジニアなどでもわりとあるかもですが、別の職種の方をバカにするという方は一定数います。民族紛争みたいなものでしょうか・・汗
私は一応どれも経験してますので、それ相応の大変さはわかっているつもりですが・・汗
あと、特にプロジェクトが佳境に入ってきた場合に相手を思いやる気持ちが負荷を軽減させます。(正論をそのままいうような方は厳しいかと思います。)
コードレビュー、検収
コードレビューですが、明らかにルール違反のようなもの以外は基本仕様変更になってしまうので、コードにこだわりを持たせたい場合は難しくなります。
細かい命名などはその部分まで書いておくとか出ない限り、ほぼほぼ無理です。
ルールを作るにしてもなるべく単純で負荷の少ないルールを守ってもらうようにしましょう。そうじゃないと守られずにお互い疲弊します・・・
また検収の際はテストコードがあれば一番いいのですが、ないケースが多いかと思いますので、後述するテストデータを送ってそれが正常に動くことで担保するのが一番よいかと思います。
(ケースまで作ってもらうこともできますが、単純なホワイトボックステストになり、無駄なものも多数あることや、仕様はこちらが把握しているのでこちらで作ったほうが楽ではないかなと思います。)
密なコミュニケーション、レスは速く
困っていることはないか、わかりにくい点はないかなどをチャットで頻繁にきいていました。
黙々と進める方がやはり多く、あまり質問されないことが多かったですが・・・こういう心がけは大事ではないかと思います。
ミーティングなどもコミュニケーションコストが少ない場合はいいのですが、定例で開かれるとストレスを感じる方もいるので、そこは開発者とよく相談しておきましょう。
新規技術の洗い出し
見積もりが崩れる理由の一つとして新規の技術で調査するのに時間がかかったりとかですかね・・この点設計書が曖昧だったりする場合、さらっと書かれると設計側が開発側に責任を押し付けることになり、疲弊します。
ベンダー側もこの点はしっかり見ておかないと、いらぬところで時間を食ってしまうので、新規技術調査に関する事項があるかどうかをしらべておきましょう。
設計側は無理に押し付けないようにしましょう。(あるいはしっかりしらべておきましょう。)
ドキュメントのわかりやすさ(少なさ)
ウォーターフォールの場合、
- APIのIF
- シーケンス図
- テーブル定義書
ぐらいならまだいいのですが(これらは最低限必要だと思うので)、
- ログ
- 環境変数値ドキュメント
- (シーケンス図と重複している)詳細設計書
- プログラムパス集
- コード規約集
などまであるとどうしても実装時に見落としがどうしても発生します。(最悪なのが同じ情報が複数のドキュメントにあることです。)
なるべく少なくして開発者側の負担を減らすようにしましょう。
責任分界点、ルールの把握
準委任だと時間契約なので、この点気にしなくていいのですが、請負の場合、仕様変更か実装漏れなのかでいろいろ揉めることが多いかと思います。(前者はお金が発生し、後者はお金が発生しないので。)
私の場合、きつかったのが自分で一切変更できないことでした。
私がなおすことができてしまうとそのせいでバグが出た場合にベンダー側の責任になってしまうことをふせぐためです。・・・
そのため、単純な文言変更や条件分岐を１行加える場合でも、お願いをしなければならずこれがものすごいストレスでした。(自分でやったほうが明らかに速いことも多々あったため。)
開発フェーズでも当たり前ですけど、設計変更が頻繁に発生するんですよね・・
しかもコードのサンプルを渡してこの通りに書いてください、という場合でも当然料金を請求されます。(テストなどがやり直しになるため。)
しかも、自分が担当になった後でそのことを知らされてたので、なおさらきつかったですね・・・
ただ結合試験段階ではさすがにすぐなおしてデプロイする必要があったので、自分で対応することができ、ある意味で楽になりましたが・・・
このように仕様変更と実装漏れをどこで分けるのか、軽微な対応などを設計側で吸収することができるか、など責任やルールの所在をしっかりしておくことが必要かと思います。
また一般的には開発をお願いしている場合、
- 結合試験時の障害調査
- ステージング環境以降へのデプロイ作業
などは開発と違い、対応してくれないことが多いかと思いますので(あるいは別料金になるかと思いますので)これらを開発に組み込んでおかないようにしましょう。
ちなみにコードレビューをしたいので、Gitに1日1回あげてくださいといったら１ヶ月で1日分ぐらいの工数を請求されました・・・(それまではAPIが完成するまであがってこなかったので。)
これには流石にびっくりしましたが、開発の常識が違うと契約書に書いていないこと以外は別料金になったりするので、注意しておきましょう。
開発者のサポート
新規の技術調査もそうですが、一番助かるのがテストデータのサポート。インとアウトの明確な定義ではないでしょうか。
このデータをいれて、この値がでればOKです。といえば開発者側はものすごい楽です。
特に緊急時にはこの作業のほうが開発より圧倒的に時間がかかるので、仕様を理解している分、活きたデータを送ってあげる必要があるかと思います。
規約違反などはいちいち指摘するとこちらも大変ですので、ツールを入れてもらい、自動検知してあげたほうが楽です。(あるいはCIにチェックさせるなど)
