Webサービス事業会社でも、開発フローは存在しその流れに沿ってプログラミングや、テストが行われます。
諸事情で、最近開発フローや、開発プロセスについて考えることが多く考えた結果を備忘録としたまとめます。

何故ソフトウェア開発に開発フロー、開発プロセスが必要か？

個人的には、以下の理由から必要性を感じています。

  • できない人対策
    仕事の進め方がわからない、良くない仕事の進め方をする人達向けの進め方のガイドラインとなります。

  • できる人同士でも、流派の違いにより衝突が起こる可能性がある
    できる人をルールで縛りすぎるのは、パフォーマンスを落とす要因になりますが、できる人達の間での最低限どのルールは必要に思います。

企業規模により求められる開発フロー、開発プロセスのイメージ

企業規模により、必要な開発フロー、開発プロセスは違って来るかと思います。

  • 個人
    個人の開発の場合は、開発フロー、開発プロセスは個人の脳内にあれば良いので特に文書化の必要性特にありません。

  • スタートアップ
    勤めたことがないので、雰囲気が分かりませんが、チームでの作業になるため、最低限のルールは必要になるかと思います。
    とりあえず進めてみて、走りながら作っていく形になるのかもしれません。

  • 新興市場上場企業
    企業規模が大きくなってルールの重要性が増します。
    スタートアップに比べると、重めの開発プロセス、開発フローになるかと思います。

  • 東証一部上場企業
    所謂、大企業になると更に重い開発プロセス、開発フローになるかと思います。
    過去の経験だと、重すぎて意味があるのか個人的には腹落ちできなかったプロセスもありました。

チームが開発フロー、開発プロセスに及ぼす影響

チームを分けると開発フロー、開発プロセスに違いが生まれます。
PMBOKでマトリックス型組織、機能型組織、プロジェクト型組織などの説明がありますが、職種別組織を作ると、開発フロー、開発プロセスが統一される傾向があり、プロダクトや、プロジェクト単位に組織を作ると、プロダクトごとに開発フロー、開発プロセスが、最適化されていくように思います。

開発フロー、開発プロセスで個人的に意識していること

個人的に開発フロー、開発プロセスの作成、変更時に意識していることを記載します。
毎回しっかり実施できているかというとそういう訳でもなく、忘れることもあります。

ドキュメントのユースケースが想定出来ているか？

冷静な目でドキュメントを見てみると、どのような使い方をするものなのかわからない場合があります。
使い方がわからないドキュメントは、いっそ作らない方が作業の削減になります。
ただ、開発プロセス上はいらない雰囲気が漂っていても、内部統制の観点で必要なものであったりするので本当に不要かは多角的に確認する必要があります。

ドキュメント同士の繋がりが出来ているか？

上流工程で作ったドキュメントが下流工程に繋がっていないケースがあります。
下流工程のタイミングで、以下を確認するようにしています。

  • 上流ドキュメントと下流ドキュメントの繋がりの説明を求める。
  • 下流ドキュメント作成に上流ドキュメントは役に立ったのか？

効果測定の観点が設計時に盛り込まれているか？

これは何故なのか理由がわからないのですが、毎回漏れていきます。
効果測定のために必要な考慮が行われているかを確認します。
URL 設計重要です。

詳細設計の段階で、実装スケジュールが意識できているか？

詳細設計フェーズで Class 図を作ると、依存関係が可視化されるため、Class の実装順序がわかります。
Class 図を書いていなくても、イメージができていれば、実装フェーズで作業が滞るリスクを回避できます。

実装担当者がコーディングガイドラインを理解しているか？

人員の入れ替えが発生する場合、コーディングガイドラインの情報が失伝するケースがあります。
定期的に、確認し理解していないようであれば、再度説明してINPUTし直します。

単体テストの実施結果をINPUTに結合テストケースを改善しているか？

単体テスト結果から学習した結果を結合テストケースとして反英しているかを確認します。
単体テスト実施担当と、結合テストケースの作成者が異なる場合は、ちゃんとコミュニケーションをとって、情報を共有してもらいます。

テスト消化が、テストの主眼になっていないか？

テストケースの消化がテストの目的になっている場合があります。
テストの目的はバグを発見することです。

結合テストケース作成中に、設計バグを検知したか？

結合テストケース作生中に、設計バグを検知しているかどうかで、結合テストケース作成プロセスが正しく機能しているかの確認ができます。
検知数が少ない場合は、良い設計、もしくはテストケース作成者と、設計担当者のコミュニケーション が上手くいっていない可能生があります。

プロセスメンター大事

開発プロセスの最適化手法 | オブジェクトの広場 に記載のあるプロセスメンターの役割は、重要に思います。
プロセスの定義を行っても、定義された<wbr>作業を<wbr>良いやり方で<wbr>進められない ことは多くあります。
このような状況を是正するのが、プロセスメンターで、上手く進められない開発者の行動に助言をしたり、実際にやって見せる人に思います。
Webサービス事業会社だと、テックリード、エンジニアマネージャーの立場の人間が実施する領域なのかもしれません。

変更に手間がかかる開発プロセス、開発フローは不要かも

開発プロセス、開発フローは変更することを前提に、変行の承認プロセスはできるだけ軽くするべきで、
チームごとにテーラリングする余地は残しておくべきです。

参考

以下、記事作成時に参考にした文書です。

コメント

カテゴリー

最近の投稿