ITコーディネータの吉田聖書です。
7payのセキュリティ事故については
関心をもって経過を見守っていますが、
そんな中、SNSを見ていたら
事故の原因が「ウォーターフォール」だ
と断言している記事が目に飛び込んできました。
7payがウォーターフォール型開発を行った
という発表があったでしょうか。
私が調べた範囲では
見つけることができませんでした。
もし私が見落としているだけなら
その発表記事を教えていただきたいですが、
もしそのような発表がないとしたら
7payとは無関係な言いがかりですし、
他所の事故にかこつけて
ウォーターフォール型開発を罵るための
読むに値しない記事であり、
もし言いがかりでないとしたら、
誰かが守秘義務を犯していると考えられます。
件の記事で
ネットでも指摘されていたのが、
ウォーターフォール型開発＝商習慣
という間違った前提で
議論が展開されていた点です。
ウォーターフォール型開発というのは
システム開発を設計・実装・テスト
という工程に区切って
原理的には、次の工程に進んだら
前の工程に戻らないという
考え方の開発手法です。
IT業界の悪しき商習慣といえば
ベンダ丸投げ体制、かつ
多重下請け構造が連想されますが、
この上意下達の開発体制と
ウォーターフォール型開発は無関係です。
ただ、無関係とは言いつつ
工程によって責任分界点が明確になるため
ウォーターフォール型開発は
この商習慣との相性が良い
という側面も確かにあります。
とはいえ、
相性が良いだけであってイコールではなく、
両者は区別して論じられるべきだということは
明確にしておきたいところです。
さて、
ではウォーターフォール型開発が
事故の原因となりうるのでしょうか。
仮に原理主義的なウォーターフォール
の考え方で開発をしていたらあるかもしれません。
原理主義的なウォーターフォールとは
手戻りを「本当に」認めないということです。
設計工程が完了してしまうと、
設計上の欠陥を修正するプロセスがありません。
テスト工程では、
設計通りに実現されているかどうかが
唯一絶対の合格基準になります。
でも、そんなやり方をしていたら
実際には困ることになります。
設計上の欠陥とは設計工程における失敗であり、
人間には失敗がつきものだからです。
失敗を許さないという精神論では
失敗を防ぐことはできません。
ですから失敗は起こるものという前提の下、
実際のウォーターフォール型開発では
変更管理という考え方で
上流工程の成果物の変更を認めています。
確かにウォーターフォール型開発には
上記のような構造上の欠陥があります。
だからといって、アジャイル型開発の方が
優れているかというと
必ずしもそうとは限りません。
まず、アジャイル型開発の場合、
計画とフィードバックのサイクルが
ウォーターフォール型開発よりも
短周期になりますし、
より緻密なコミュニケーションが
必要になりますので、
エネルギーが必要な割には
大規模な開発には向きません。
また、アジャイル型開発では
最初に完成形を定義しないため、
委託する場合は準委任契約となり、
成果物の完成を条件とする請負契約では
外部のベンダに丸投げすることができません。
丸投げできないということは
自社主導で開発を進めなければならず、
それなりに社内の人的リソースが
必要になることを意味します。
ウォーターフォール型開発が
事故の原因となりうるか
というところに話を戻すと、
私は開発手法が決定的な原因に
なることはないと考えています。
むしろこれはマネジメントの問題であり、
いかなる開発手法を採用しようとも
その運用がうまくいっていなければ
今回のような事故は起こり得るでしょう。
マネジメントの責任を
開発手法のせいにしてはいけません。
今回の不正利用の仕組みは単純なもので、
開発関係者であれば
気付いていた可能性があります。
もしそうだとしたら、
その指摘をどのように吸い上げ、
どのように取り扱ったのか
非常に興味があります。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。