旧来型SIerでアジャイル（スクラム）が上手く行かない５つの理由

私自身はスクラム開発はやったことがなく、机上で勉強しただけなのですが、そんな私が自分が現在参画しているSIer案件では絶対採用できないなぁなんて思ったのですが、ぜひ識者にアドバイスをいただきたく、その理由を並べておくことにする。

anond.hatelabo.jp

１．メンバーの契約形態が無理

ｎ次下請けで会社が違う人が集まって開発を行っているようなところではそもそも無理。請負契約はもちろんのこと準委任契約でも指示系統が法律的にＮＧ。というか合法に回避できる方法があったら教えて欲しい。個人的に一番の壁だと思った。同じ会社の社員でチームを組むしかないのではという認識である。

２．お客様との一括請負契約の時点で無理

ＰＯにリリース範囲を決めることができる権限がない時点で無理。大企業や国家システムの開発ともなると大々的にリリース日が宣言されていたり、法律でリリース日が決まっていたりするので、そこに大線表のゴールが定まっている。そんなのアジャイル使う意味全くないし、ウォーターフォールでやれよとしか思わない。スコープと納期に自由度を持たない案件では無理。

３．メンバーのスキルが低過ぎる

これは私の持論であるが、品質について小規模開発は人に依存し、大規模開発はプロセスに依存すると思っている。大規模SI開発現場は、低単金・低スキルメンバーを集めても一定以上の品質を作るためのプロセス（と有識者の多少の犠牲）で成立しているのだ。しかし、スクラムでチームメンバーの条件である「すべての作業ができること」を満たせる要員なんていない。雑な発注をプロセスに落とし込む上流の人と、定められたプロセスを効率的かつ高品質に実施する下流の人で分業していたものが、全員が考えて全員で作業しろとか無理にもほどがある。そもそものスクラム発端の会社名を見て、あーこれは優秀な会社の優秀なメンバーがチームとして最大化させるための手法であって、優秀でない人の集まりには適さないんだなぁって強く思った。

４．ウォーターフォール開発前提の管理

これは弊社の話だが、社内の管理（事前審査、週次進捗報告、品質管理など）がウォーターフォール開発前提に作られており、結局はスクラムをウォーターフォールに翻訳して報告する必要があり、管理者の負荷が非常に高くなる。こういった進捗報告などの雑務を減らすことがスクラムの利点にもかかわらず、進捗をしないといった形にはできず、結局は効率的にならない。

５．リモートワークとの相性が悪い

これも弊社の問題だが、弊社はリモートワークに舵を切ったのだが、これがスクラムとの相性が悪い。チームが集まって情報をオープンにしてやることで効果が発揮できる印象だが、デイリースクラムすらskypeやZoomでやるの、うまく意思疎通できないのよね…
　
　
　
自社開発のウェブサービスとかには非常に有用だと思うが、納期が先行して決まっていて大規模開発を行うといった案件では、ほぼほぼ無理なんじゃないかというのが勉強した際の印象だ。だからといってシステム屋でないお客様側に「私が主導するからスクラム開発やろう」なんて言ってくる人は微粒子レベルも存在しないだろう。そんなわけで私個人としては部下の教育をアジャイルでやっている程度で、実際の開発には使えていないのが現状である。実践を経験してみたいという想いが強い今日この頃である。

良い開発手法で、良い人生を。
流行っているからとアジャイル（スクラム）を使うのではなく、案件ごとに良い手法を選択するために知識（メリット・デメリット）をつけておきたい。