超高速開発ツールが『効く』課題と『効かない』課題

[2017-05-18 全面的に記事を更新しました。]

数年前に超高速開発ツールを導入したところ、システム開発のスピードが以前とは比較にならないほど速くなりました。ときどき、超高速開発ツールを使わない、従来通りの開発プロジェクトのヘルプに入ったときなんかは、そのスピード感にもどかしさを感じるほどです。

一方で、ここ数年、超高速開発のプロジェクトを運営したり、超高速開発ツールで開発したシステムの保守をした結果、無邪気に褒めちぎるようなツールでないことも分かりました。数年利用して確信したのは『超高速開発ツールは、決して銀の弾丸にはなり得ない』という事です。

この記事では、超高速開発ツールの導入を検討している方に向けて『超高速開発ツールを導入する目的と注意すべきこと』について、私自身や、私の身の回りで起きた失敗を交えて、ご紹介したいと思います。

願わくばこの記事が、これから超高速開発ツールの導入に成功する方にとって、少しでも参考・気づきになれればと、期待しています。


なお、ここで想定している”超高速開発ツール”とは、Wagby、Genexus、Outsystems、WebPerformer等の、何らかの定義を設定することで、UIを伴うアプリケーションを自動生成するツールを指しています。

ETL等のバッチ処理に特化したツールや、テスト自動化やドキュメント生成自動化ツールなど、システム開発の特定の工程・特定の作業を自動化するツールを想定したものではありません。

また、私自身は仕事でWagbyを使っていますが、特定のツールに偏った話にならないように注意して書くつもりです。


なお、”超高速開発”に関する(おそらく)唯一のコミュニティである超高速開発コミュニティ(https://www.x-rad.jp/)では、超高速開発ツールを次のように定義しています。

Q1. 超高速開発ツールの定義は?

A1. 従来型のスクラッチ開発に比較し、少なくとも3倍から10倍という生産性を提供できる、具体的なツールとします。

FAQ | 超高速開発コミュニティ
Q1. 超高速開発ツールの定義は? A1. 従来型のスクラッチ開発に比較し、少なくとも3倍から10倍という生産性を提供できる、具体的なツールとします。 Q2. 発足の経緯は? A2. 2013年4月16日に開催された「ユーザー事例に学ぶ超高速開発ツール」(主催:ICT経営パートナーズ協会。現在の正式名称は、一般社団法

私は、この定義が『超高速開発 または超高速開発ツールとは何か?』を表現するのに適しているとは思いませんが、いま確認できる最も中立・公的な情報はコレだけのように思います。

その他の”超高速開発”の定義に関する記事はこちら。

超高速開発ツールとは?5分で理解できる、概要から課題まで
超高速開発ツールの概要やメリットデメリット、そして同ソリューションが持つ課題をまとめていきます。さまざまな方に理解して頂けるように、わかりやすく解説しているので是非参考にしてみてください。
みずほもすなる「超高速開発」
 ユーザーは予想以上に広がっている――。3年ぶりに「超高速開発」について取材を重ね、記者は素直にそう感じた。超高速開発とは、プログラムを100%自動生成するツールを用いて開発スピードを飛躍的に高める開発手法だ。
あなたの知らない超高速開発
 あなたが携わるシステム開発プロジェクトで、開発速度が10倍速くなったらどう思うだろうか。「すぐに使ってもらえるので嬉しい」と思うか、「人月で見積もっており売り上げが減るので嬉しくない」と思うか。いずれにしろ、その後にこう思うことだろう。「そもそも10倍なんてできるわけないじゃないか」。だが、実際にできているユーザー企

この話の前提

この手の記事は、発言者がどんなポジションで語っているのか明らかでないと、誤解が生まれたり、文脈が把握しづらいと思います。という訳で、簡単な自己紹介を記載します。

※本筋に影響のない程度に、若干のフェイクを入れています。

  • 業種…やや固めの業種(非IT)
  • 社風…やや固めの社風
  • 従業員数…1000以上 2000人以下
  • 所属…情報システム部門
  • 普段の主な仕事…システムの企画・開発・保守、社外のITベンダーとのアレコレ、上司から命令された雑用、上司の上司から命令された雑用

何に期待して導入するの?

前置きが長くなってしまいましたが、『高速開発ツールに何を期待して導入するのか?』、また、『その問題は高速開発ツールで本当に解決できるのか?』を考えてみたいと思います。

『生産性の向上』って言うけど、本当の目的は何だっけ?

生産性の向上というキーワードは、組織の中で働いていればよく耳にすると思います。超高速開発ツールという単語から受ける印象と相性がとても良いので、思わず生産性の向上を導入の目的にしてしまいそうになりますが、これにはちょっと注意が必要です。

私の経験上、システム部門で実施する様々な施策のうち、システム開発の生産性向上が本当の目的だったことは稀です。

耳障りの良い言葉ですが、『システム開発の生産性が向上』したら、その結果、何が良くなるのでしょうか。売上が上がるでしょうか。コストが下がるでしょうか。(あるいは、役員に褒められる?)

おそらく多くの場合、どれも実現できないのではないでしょうか。

システム部門の生産性が上がっても、それだけで売上が上がったりコストが下がることは、非常に稀です。システム部門の生産性の向上は、その先にある”もっと本当に必要なコト“のための手段のハズです。

『生産性があがるのは良いことなんだから、それで良いじゃないか。』という反論もあるかもしれません。ここで言いたいのは『生産性があがるのは意味がない』というコトではなくて、『もっと、本当に必要なコトに焦点を当てたほうが良い』というコトです。システム部門の生産性向上は、それだけで終わってしまったら、ただの自己満足です。

『手段の目的化』 ~社員全員が見失った「本来の目的」~
ビジネスの現場には多くの『落とし穴』が潜んでいる。その1つが『手段の目的化』だ。本来の「目的」を見失い、「目先の行動」に埋没してしまうビジネスマンが非常に多い。

超高速開発ツールを導入する多くの場合、社内の業務用システムの開発として利用されることが多いかと思います。ここで語られる生産性は、資本や生産額を指標にしたものではなく、暗黙的に物的労働生産性のことを指しているでしょう。

物的労働生産性 = 生産量 / 労働力の投入量

分解すると次の2つに分けることができますが、果たしてどちらが本当の目的でしょうか。

  1. 同じ工数で、より多くの機能を作る。
  2. より少ない工数で、今まで通りの機能を作る。

目的によって、取るべき手段や気を付けるべきことは変わってくるはずです。

生産量(アウトプット)を増やしたい?

おなじ労働力(工数)で、より多くの生産量(より多くのシステム・機能)を得たい場合、何に気をつけるべきでしょうか。

作りたいアプリケーションや機能のバックログが山程あって、それを常に消化しきれてなくて、要望を挙げている部門には我慢してもらっている。けど人は増やせない・・・というようなケースは、これにあてはまるかと思います。

このような場合、超高速開発ツールの導入によって、短期的には多くのアプリケーションや、多くの機能を作り出すことができるでしょう。

ただしこの場合『たいして重要じゃない、優先度の低い要望が実現されているに過ぎないかもしれない。』ということに注意が必要です。高速開発ツールによってどんどん開発しても、その結果得られる収穫は逓減しているかもしれません。

逓減ならまだマシで、場合によってはマイナスになることもあるかもしれません。

優先度の低いモノを量産した結果、手間ばかり掛かってロクに使われてない・使ってるけど誰も得しない・・・なんてケースが起こりうることは、想像に難くないと思います。

また、高速開発ツールによって短期に大量に開発できることを知った人たちは、これまで以上に、不用意で浅はかな企画をシステム部門に持ち込んでくるかもしれません。

システム開発の実施可否の判断をこれまで以上に慎重にしないと、ムダなもの・害のあるものを、超高速に作ってしまうことになりかねません。

労働力の投入量(工数)を抑えたい?

通常、一般の企業の情報システム部門では、多くの工数が既存のシステムの保守に費やされていると思います。超高速開発ツールを導入しても、これらの既存システムが消えてなくなる訳ではないので、既存システムの保守工数は、そのまま掛かり続けます。

私が所属している組織の場合、超高速開発ツールによって、システム開発の工数を1/3程度に抑えられるようになりました。(測定方法や導入企業の状況によって、この数値はマチマチだと思います)

ただし、新規開発の工数は、既存システムの保守を含めたシステム部門全体の2割程度です。

全体で見ると7%程度しか工数削減に寄与していません。

それでも十分大きいといえるかもしれませんが、7%の工数削減を目的にするなら、既存システムの保守作業の見直しや、あるいは価値の低い作業をやめてしまう・・・など、超高速開発ツールの導入よりも即効性のある選択肢もありえます。これを踏まえて検討したほうが良いでしょう。

新規開発するシステムのリードタイムを短くしたい?

コレは、生産性と混同して語らないように注意が必要です。

『ビジネスのスピードに追随する』とか『変化スピーディーに対応する』とか、さまざまな理由で、システムのリリースまでのリードタイムを短くするために導入するというケースも多いと思います。

私の場合、まさにココを目的にしていましたが、やはりこれにも十分な注意が必要です。

注意1: 専任の担当者を置かないと、劇的なリードタイム短縮は望めない。

圧倒的な開発のスピードを目の当たりにすると、マネージャーはつい、並行して他の業務も与えたくなってしまいます。

当たり前過ぎる話ですが、同じ開発者が2つの開発案件を並行して進めれば、リードタイムは2倍(普通はスイッチングタイムや管理コストのせいでそれ以上)掛かります。

従来より生産性は上がっているので、つい満足してしまいそうになりますが、生産性向上が目的ではなかったということに、注意が必要です。

注意2: 逆転するボトルネックに、ビジネス部門はついてこれる?

アジャイル開発と組み合わせて導入する企業も多いかと思いますが、超高速開発ツールとの組み合わせによってビジネス部門側の負担が大きくなることにも注意が必要です。

短いイテレーションの中で、多くのユーザーストーリーが実現されます。何を作るか・何を実現したいかを、速く・たくさん具体化していく必要があります。

Scramでいうスプリント・レビューでは、1回あたりに消化するストーリーの分量が非常に多くなるのでビジネス側の担当者の高い力量が求められます。この点に不安がある場合は、ビジネス側の担当者をうまくサポートする仕組み・体制づくりに気を配る必要があります。

『高速に開発できるから手戻りコストが小さい』という発想は、改善を繰り返すための裏付けとしては有効ですが、『企画やプランニングの甘え』に繋がらないよう、注意が必要です。

注意3: ところで、本当に『開発の』リードタイムを短くする必要があるの?

『環境の変化が激しい』とか、『ビジネスの変化のスピードが速くなっている』とか、『追随するためにITやIT部門は進化すべき』とか、各種メディアを見ればそんな論調が多く出回っています。

大筋ではその通りなのでしょうし、リードタイムが短縮できるなら、それ自体には明らかに良いことと言えるでしょう。

ところで、私やあなたの周りの環境は、本当にその通りでしょうか?

これまであなたの会社が新しい商品・サービスを提供する際に、ITがボトルネックになったことがあったでしょうか?この先、そのようなことが起こり得るでしょうか?

なにより、それは、超高速開発ツールによって解消されるのでしょうか?

問題の原因は、システム開発のリードタイムではないかもしれません。

担当者個人の能力の問題だったり、組織の判断のスピードだったり、企業風土とかいう得体の知れないモノが原因かもしれません。

せっかく超高速開発ツールでリードタイムを劇的に短くしても、他の問題のせいで、結局リリースが遅れてしまう・・・という事にもなりかねません。

システム開発は、最初の計画とズレることが多いので、つい悪者にされてしまいがちですが、『ビジネス上の企画の実現や、変化をもたらす』うえで、本当に『システムの開発工程がボトルネックになっているのか』、慎重に見極めるべきです。

つまり・・・

  • 目的をしっかりと見定める。
  • 超高速開発ツールは、どの程度その目的に寄与するのか、きちんと評価する。
  • 超高速開発ツールでは解決できない問題は、ツール導入とは別にちゃんとケアする。
  • 導入したことで生まれる変化が、悪影響を及ぼさないように、ちゃんとケアする。

といったところでしょうか。

超高速開発ツール自体は圧倒的に開発のスピードを高めるものなので、どんどんいろんな会社・個人で利用していってほしいと思います。その結果、導入に成功した話や、技術的なtipsを多くの人とたくさん共有できたら良いですね。

関連する記事

 

コメント

Recommended
Recommended
今回は、前回作成した…