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