難しい・・・アジャイル開発
バスでの移動中に気になった話題があったので雑話
どんな話？
システム開発の手法のひとつで、ちょっと前から「効率的で／要件変更も楽々で／失敗も少ない 開発手法」らしいと聞いていた「アジャイル開発」のはなし。
そもそも書いているひとは誰？
この記事を書いている人はITシステム部門で仕事をしています。
が・・・プログラミングができるわけでもなく、設計書を書くわけでもない、「ユーザー企業の立場でITベンダーにシステム開発を発注する」仕事をしています。
被害妄想かもしれませんが・・・ベンダーからは「クレーマー」のように思われ、社内の事業部門からは「業務もわからん・システムも作れん邪魔もの」と思われているヤツです。
気になったこと
Togetterの記事で「ウォータフォールは一切メリットがない」という話題を見つけて「いやいや、それは言い過ぎでしょ」と思いつつ、なぜ日本にアジャイルが根付かないのか思いを馳せていました。
気になる方は上のリンクからご参照してみてください。
なぜ「アジャイル」が根付かないのか？
端的に言えば「当社のようなシステム開発を委託するだけのユーザー企業」が日本企業の大多数を占めているからだろうなってはなしに帰結しそうです。
わたしが思う、アジャイルが根付かない理由は大きく３つ。
ひとつは「システム開発の内製化」、ひとつは「無形固定資産の登録」、ひとつは「社員の異動」（というか、古い企業にありがちな”ゼネラリスト”信奉）
１．システム開発の内製化
これは上記の記事でも言われていることですが、アジャイルが根付いている（らしい）アメリカではシステム開発の自社内製化率が高く（コア事業では50%超）、委託契約に縛られないチームが柔軟に構築可能になっています。
日本の場合は内製化率が20%程度らしく、かつ大規模な開発はITベンダーに委託するのが常になっています。
この「委託契約」というのはアジャイルの思想と大きく乖離があると思います。
最近は請負ではなく準委任での契約が主になってはいますが、それでも発注先と発注元の関係では暗黙的に「完全な」成果物が求められ、契約どおりの「リリース」を要求されます。
そうじゃないと検収ができないですからね。
アジャイルの場合、何が成果物になって、どの状態でリリースして、何をもって検収するのか・・・。
この辺を詰め切らないとアジャイルのプロジェクトがスタートできないし、この辺の形式と実績がウォータフォールモデルだとすでに固まっているんですよね。
特に大規模開発の場合は、ユーザー企業として社内の決定を通す際に、IT統制の観点からも効果も含めた「結果」を確実に説明可能な状態にする必要があり・・・そうこうするうちにアジャイルの思想からどんどん離れていきます。
２．無形固定資産の登録
システム開発して「事業に供する」状態になったら固定資産として登録して減価償却をしないといけませんね（これをしないと脱税ですので）
アジャイルでは当然リリース間隔が短くなるわけで、そのたびに資産登録をしなくてはならないはず・・・
っと思ったのですが、この問題は企業形態に依らずアジャイル開発を行う企業すべてに当てはまるので、もしかすると回避策があるのかも？
まあ、大概の企業には固定資産システムがあるでしょうから、そこに登録するだけの話ではあるので、回避もなにも面倒くさがらずやればいいじゃんという話なのかもしれませんね。
３．社員の異動（ゼネラリスト信奉）
これは古いユーザー企業ならではなのかもしれませんが、人材育成において自社の事業を統括的に考える能力をもつ「ゼネラリスト」を育成することが優先されています。
そのため異動も頻繁に実施され、とても「スペシャリスト」を育てられる状態にはなっていません。
当然ゼネラリスト育成はデメリットだけではないのでしょうが、「１．システム開発の内製化」に必要な人材を社内で確保することが難しい状況にあります。
反省
やれない理由を考えるのはダメ思考ですね・・・
アジャイルのメリットをしっかり理解して、メリットを享受できるような仕組みを作り出していくことを考えていきたいです。
この記事が気に入ったらサポートをしてみませんか？