skillup

技術ブログ

プロジェクト管理

ベンダーコントロールについて

投稿日:2022年12月19日 更新日:

ベンダーコントロールについて昨年度やっていていろいろ勉強になったのですが、そこで学んだことや大変だったことなど。

相手へのリスペクト

当たり前ですが、開発者へのリスペクトですかね。

ウォーターフォールタイプの開発だと設計(上流)→開発(下流)とわかれており、あくまで役割なのですが、上流=エライ、下流=エラくないみたいに思う方も一定数いるかとおもいます。

私はフェーズが分かれた工程をあまり経験していないのと自分が開発者のため、そんなことはありませんでしたが。

こういうのって態度に出ちゃうんですよね・・・営業とエンジニアなどでもわりとあるかもですが、別の職種の方をバカにするという方は一定数います。民族紛争みたいなものでしょうか・・汗

私は一応どれも経験してますので、それ相応の大変さはわかっているつもりですが・・汗

あと、特にプロジェクトが佳境に入ってきた場合に相手を思いやる気持ちが負荷を軽減させます。(正論をそのままいうような方は厳しいかと思います。)

コードレビュー、検収

コードレビューですが、明らかにルール違反のようなもの以外は基本仕様変更になってしまうので、コードにこだわりを持たせたい場合は難しくなります。

細かい命名などはその部分まで書いておくとか出ない限り、ほぼほぼ無理です。

ルールを作るにしてもなるべく単純で負荷の少ないルールを守ってもらうようにしましょう。そうじゃないと守られずにお互い疲弊します・・・

また検収の際はテストコードがあれば一番いいのですが、ないケースが多いかと思いますので、後述するテストデータを送ってそれが正常に動くことで担保するのが一番よいかと思います。

(ケースまで作ってもらうこともできますが、単純なホワイトボックステストになり、無駄なものも多数あることや、仕様はこちらが把握しているのでこちらで作ったほうが楽ではないかなと思います。)

密なコミュニケーション、レスは速く

困っていることはないか、わかりにくい点はないかなどをチャットで頻繁にきいていました。

黙々と進める方がやはり多く、あまり質問されないことが多かったですが・・・こういう心がけは大事ではないかと思います。

ミーティングなどもコミュニケーションコストが少ない場合はいいのですが、定例で開かれるとストレスを感じる方もいるので、そこは開発者とよく相談しておきましょう。

新規技術の洗い出し

見積もりが崩れる理由の一つとして新規の技術で調査するのに時間がかかったりとかですかね・・この点設計書が曖昧だったりする場合、さらっと書かれると設計側が開発側に責任を押し付けることになり、疲弊します。

ベンダー側もこの点はしっかり見ておかないと、いらぬところで時間を食ってしまうので、新規技術調査に関する事項があるかどうかをしらべておきましょう。

設計側は無理に押し付けないようにしましょう。(あるいはしっかりしらべておきましょう。)

ドキュメントのわかりやすさ(少なさ)

ウォーターフォールの場合、

  • APIのIF
  • シーケンス図
  • テーブル定義書

ぐらいならまだいいのですが(これらは最低限必要だと思うので)、

  • ログ
  • 環境変数値ドキュメント
  • (シーケンス図と重複している)詳細設計書
  • プログラムパス集
  • コード規約集

などまであるとどうしても実装時に見落としがどうしても発生します。(最悪なのが同じ情報が複数のドキュメントにあることです。)

なるべく少なくして開発者側の負担を減らすようにしましょう。

責任分界点、ルールの把握

準委任だと時間契約なので、この点気にしなくていいのですが、請負の場合、仕様変更か実装漏れなのかでいろいろ揉めることが多いかと思います。(前者はお金が発生し、後者はお金が発生しないので。)

私の場合、きつかったのが自分で一切変更できないことでした。

私がなおすことができてしまうとそのせいでバグが出た場合にベンダー側の責任になってしまうことをふせぐためです。・・・

そのため、単純な文言変更や条件分岐を1行加える場合でも、お願いをしなければならずこれがものすごいストレスでした。(自分でやったほうが明らかに速いことも多々あったため。)

開発フェーズでも当たり前ですけど、設計変更が頻繁に発生するんですよね・・

しかもコードのサンプルを渡してこの通りに書いてください、という場合でも当然料金を請求されます。(テストなどがやり直しになるため。)

しかも、自分が担当になった後でそのことを知らされてたので、なおさらきつかったですね・・・

ただ結合試験段階ではさすがにすぐなおしてデプロイする必要があったので、自分で対応することができ、ある意味で楽になりましたが・・・

このように仕様変更と実装漏れをどこで分けるのか、軽微な対応などを設計側で吸収することができるか、など責任やルールの所在をしっかりしておくことが必要かと思います。

また一般的には開発をお願いしている場合、

  • 結合試験時の障害調査
  • ステージング環境以降へのデプロイ作業

などは開発と違い、対応してくれないことが多いかと思いますので(あるいは別料金になるかと思いますので)これらを開発に組み込んでおかないようにしましょう。

ちなみにコードレビューをしたいので、Gitに1日1回あげてくださいといったら1ヶ月で1日分ぐらいの工数を請求されました・・・(それまではAPIが完成するまであがってこなかったので。)

これには流石にびっくりしましたが、開発の常識が違うと契約書に書いていないこと以外は別料金になったりするので、注意しておきましょう。

開発者のサポート

新規の技術調査もそうですが、一番助かるのがテストデータのサポート。インとアウトの明確な定義ではないでしょうか。

このデータをいれて、この値がでればOKです。といえば開発者側はものすごい楽です。

特に緊急時にはこの作業のほうが開発より圧倒的に時間がかかるので、仕様を理解している分、活きたデータを送ってあげる必要があるかと思います。

規約違反などはいちいち指摘するとこちらも大変ですので、ツールを入れてもらい、自動検知してあげたほうが楽です。(あるいはCIにチェックさせるなど)

-プロジェクト管理
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

使える設計書作成に関して

私自身、この仕事を7〜8年やっておりますが、設計書作成については常に悩まされておりました。 設計書のメリット・デメリットとしては以下のようなものですかね。 メリット メンバー間での仕様の認識を統一でき …

no image

プロジェクトごとのフェーズでやっておいたほうが良いと思うこと

またプロジェクトの途中ではありますが、自分の中で要件定義〜外部結合の始まりまでのフェーズを経験して思ったことなど Contents1 全般2 要件定義3 基本設計4 詳細設計5 製造6 単体テスト〜内 …

no image

文化づくりについて(チームビルディングに関して)

プロジェクトやチームの文化づくりについて。 エンジニアに限らず塾運営スタッフ時代から感じていたことなどを。 全く同じ仕事をしていても職場の文化というのは全く違うもので、ある場所で当たり前なことが別の場 …

no image

アジャイル開発について

エンジニアとして仕事をしてから7〜8年立ちましたが、その間9割近くはいわゆるアジャイル開発でやってきたと思っていました。今は比較的大規模な開発をしておりますので、ウォータフォールですが・・・ が、先日 …

no image

ブランチ構成について

gitのブランチ構成などについて少しまとめてみようと思います。 Contents1 ブランチ一覧1.1 feature1.2 develop1.3 staging1.4 production2 ブラン …

アーカイブ