S部

超高速開発ツールを導入するだけで、その問題を本当に解決できますか?

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

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

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

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

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


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

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

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


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

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

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

https://www.x-rad.jp/faq/

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

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

https://www.imkk.jp/blog/overview-rapid-development-tool.html http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400358/ http://itpro.nikkeibp.co.jp/article/Watcher/20120316/386842/

このお話の前提

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

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

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

twitter.com

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

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

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

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

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

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

おそらく、多くの場合はどれも実現できないのではないでしょうか。システム部門の生産性が上がっても、それだけで売上が上がったりコストが下がることは、非常に稀です。システム部門の生産性の向上は、その先にある"もっと本当に必要なコト"のための手段のハズです。

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

diamond.jp


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

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

分解した結果、次の2つにわけられますが、どちらが本当の目的でしょうか。

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

どちらが本当の目的でしょうか。それによって、取るべき手段や気をつけるべきことが変わってくるはずです。

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

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

作りたいアプリケーションや機能のバックログが山ほどあって、それを常に消化しきれてなくて、要望を挙げている部門には我慢してもらっている。けど人は増やせない・・・というようなケースは、これにあてはまるかと思います。このような場合、超高速開発ツールの導入によって短期的には多くのアプリケーションや、多くの機能を作り出すことができるでしょう。

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

逓減ならまだマシで、場合によってはマイナスになることもあるかもしれません。(優先度の低いモノを作った結果、手間ばかりかかってロクに使われてない・渋々使ってるけど誰も得しない なんてケースがあることは、想像に難くないと思います。)

また、高速開発ツールによって短期に大量に開発できることを知った人たちは、これまで以上に、不用意で浅はかな企画をシステム部門に持ち込んでくるかもしれません。システム開発の実施可否の判断をこれまで以上に慎重にしないと、ムダなもの・害のあるものを、超高速に作ってしまうことになりかねません。

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

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

私の場合、超高速開発ツールによって、同じ規模のシステム開発を別のツールで開発した場合に比べて、工数を1/3程度に抑えられるようになりました。(測定方法や導入企業によって数値はマチマチだと思います)

ただし、新規開発の工数は、既存システムの保守を含めたシステム部門全体の2割程度です。全体で見ると7%程度しか工数削減に寄与していません。

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

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

コレは、生産性と混同して語らないように注意が必要です。ビジネスのスピードに追随する とか、変化に対応する とか、さまざまな理由でシステムのリリースまでのリードタイムを短くするために導入する というケースも多いと思います。私の場合、まさにココを目的にしていましたが、やはりこれにも十分な注意が必要です。

専任でやらないと、劇的なリードタイム短縮は望めない。

圧倒的な開発のスピードを目の当たりにすると、マネージャーはつい、並行して他の業務も与えたくなってしまいます。当たり前すぎる話ですが、同じ開発者が2つの開発案件を並行して進めれば、リードタイムは2倍(普通はスイッチングタイムや管理コストのせいでそれ以上)掛かります。従来より生産性は上がっているので満足してしまいそうになりますが、この場合生産性向上が目的ではなかった ということに、注意が必要です。

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

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

短いイテレーションの中で、多くのユーザーストーリーが実現されます。何を作るか(何を実現したいか)を、速く・たくさん具体化していく必要があります。Scramでいうスプリント・レビューの、1回あたりの分量が非常に多くなるので、ビジネス側の担当者の高い力量が求められます。この点に不安がある場合は、ビジネス側の担当者をうまくサポートする仕組み・体制づくりに気を配る必要があります。

・・・ところで、本当にリードタイムを短くする必要があるの?

環境の変化が激しいとか、ビジネスの変化のスピードが速くなっているとか、それに追随するためにITやIT部門は進化すべきとか、各種メディアを見ればそんな論調が多く出回っています。大勢はその通りでしょうし、リードタイムが短縮できるなら、それ自体は明らかに良いことと言えます。

ところで、私やあなたの周りの環境は、本当にその通りでしょうか?これまであなたの会社が新しい商品・サービスを提供する際に、ITがボトルネックになったことがあったでしょうか?この先、そのようなことが起こり得るでしょうか?それは、超高速開発ツールによって解消されるのでしょうか?

問題はシステム開発のリードタイムではないかもしれません。それは、担当者個人の能力の問題だったり、組織の判断のスピードだったり、企業風土とかいう得体の知れないモノかもしれません。せっかく超高速開発ツールでリードタイムを劇的に短くしても、他の問題のせいで、結局リリースが遅れてしまう・・・という事にもなりかねません。

つまり・・・

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

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

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

関連する記事

www.cycle-g.info

www.cycle-g.info