さった8月に、東京・大阪・沖縄でそれぞれ「第二回Wagbyユーザー会」が開催されました。のべ48名の参加者との交流を通して一つの気付きがあったので、ここにまとめたいと思います。
企業におけるIT部門の地位が凋落しているという話は良く耳にします。
最近は凋落どころか、邪魔者扱いという指摘さえ目にすることもあります。
「うるさいだけのIT部門は、もう終わり！」
http://itpro.nikkeibp.co.jp/article/Watcher/20120821/417002/?ST=ittrend&P=1
私が先日参加したシステム・イニシアティブ研究会で発表されていた兵庫県西宮市の元・情報システム部担当は、講演をとおして如何に自分たちの地位を向上させるかに腐心したか、を語られました。実際、聞くも涙という話でした。
http://system-initiative.com/wp/?p=1854
なぜIT部門はこうも邪険にされるのか。これは経営層からみてコスト部門であり、売上に貢献していないと見なされているため、と考えられます。
- コストがかかる割に、現場からは「使えないシステムを押し付けられた」という不満の声が多く、感謝されていない。
- 経営陣にとってITコストの算出根拠がよくわかっていない。
- エンジニアのスキル測定が困難で、組織への貢献度が見えない。
- エンジニアの人事ローテーションができない。十何年も（何十年も）プログラミングに携わった人ほど配置転換が困難になる。
つまりIT部門の努力が、経営陣（を含む社内の他の部門）から理解されていません。これはITの第一線に携わっている方にとって非常に悔しく、またストレスの要因にもなっています。しかしこれをもって、単純に「我々を理解してほしい」というだけでは改善されないことも経験済みです。ここでは、さらに考察を続けます。
努力の見える化の指標に、ずれがあることが問題
IT部門の立場から、自らの奮闘を見える化するために思いつきそうなアイデアを列挙してみましょう。
- 安い給料で働いており、コストをできるだけ抑えている。
- 常に相見積をとって、外注費を抑えている。オフショア開発も利用している。
- これだけのプログラムを（行数や、本数を具体的に示して）つくってきた。
- これだけの不具合を修正した。
- これだけの機能追加を行った。
- 外注費を浮かすために、無料ソフトを地道に探している。
- エンジニアのスキルが高いことを示すために、資格試験取得を励行している。
いずれも真摯な対応です。もちろん、ここにあげた以上の見える化努力を行っているところもあるでしょう。
しかし結論からいうと、これらはすべて経営陣に、そして利用者部門に届いていません。彼らが欲する指標は、別にあるのです。
そしてIT部門に在籍する人達は、その"ずれ"をすでに認識しているはずです。認識していますが、その要求は"無理・無茶"という常識の壁の前で、なかったことにしています。
経営陣が、そして利用者部門が、かねてより IT 部門に欲しているもの。それは「開発スピード」です。
経営環境が常に変わる中、経営判断にスピードが求められていることは十分、認知されています。この要求にIT部門の開発が追いついていないのです。よって経営判断の変更にITが活用できない。仕方なく現場はExcelなどのツールで自衛せざるをえない。IT部門からのアウトプットは信頼できるものであり、本来はもっと活用したいが、常に後手に回っており "残念な" 状態にある...。
IT部門がプログラムを作成することは当たり前。それも安く、高品質であることも当たり前。その上で現場が感動し、経営陣に「役に立つシステムをありがとう」と言わしめる、たった一つの指標。それが開発スピードの向上です。
経営陣と利用部門が感動する開発スピードは、今の10倍
IT部門が経営陣と利用部門に「開発スピードを10倍にする」という約束を掲げ、それを実践すること。これがIT部門の地位向上に直結します。そしてそれ以外の（先に示した）努力は、残念ながら感覚的に理解してもらえません。
開発スピード10倍を「見える化」する方法は、いろいろあります。例えば次のようなものです。
- 利用部門からの要望を定期的にヒアリングし、毎週一回のリリースを掲げる。
- どのような要望があるかを共有し、ヒアリングから実現までの期間を公開する。その期間を見える化し、アピールする。
もちろん、開発スピード向上のためにコスト高になることはあるでしょう。しかし、仮に開発スピードが10倍になるなら、開発費（原価）が2倍になっても十分、お得です。経営陣はその判断をむしろ合理的と評価するでしょう。
ここまでわかっていてもなお、IT部門が開発スピードの向上に踏み切れない理由は何か。ここに双方の本質的な溝があるはずです。
プログラム言語ではなく、現場の業務用語でシステムを語る
すでに市場には、BRMS (Business Rule Management System) や自動生成ツールなど、ノンプログラミングで開発生産性を飛躍的に向上させるツールが登場しています。これらのツールに共通していることは、プログラム言語の抽象度をさらに一段高めて、業務に特化した言語 (DSL; Domain Specific Language) でシステムを表現することです。
これは多くのプログラマにとって、開発方法の大転換になります。「（これまでのような）プログラムを書かない開発」という時代の到来です。*1
皮肉なことに、ノンプログラミングツールに可能性を見出しているのはIT部門ではなく現業部門です。今回のWagbyユーザー会では、現場主導または現場を密に巻き込んだ事例発表が相次ぎました。ここで開発されたシステムは、まさに自分の業務に特化したものばかりで、決して汎用パッケージでは実現できません。かといって、仮に開発をIT部門に依頼すると、半年から一年待たされたあげく、変更要求を容易に受け付けてもらえないという不安（不満）を抱えていました。これこそが、IT部門が乗り越えないといけない壁だと改めて痛感しました。
「IT部門を、より現場に近づけて、組織の中で役に立っていると思えるような位置づけにしたい。」
このゴールに異論を挟む人は少ないでしょう。そうしなければ、現行システムの保守終了とともにIT部門の大幅なリストラが現実化してしまいます。しかし現場に近づけるという言葉には、開発スピードを上げるという具体策を込める必要があります。これまで無理だと避けていた「開発スピードの劇的な向上」にいよいよ目を向けなければ、現場とIT部門・経営陣との乖離は広がる一方です。
開発スピードの向上はすべての問題をカバーするわけではないが、それでも変化を印象づけられる
もちろん開発スピードの向上だけで、システム開発の課題が一気に解決されるわけではありません。しかし少なくとも「何度も作り直しができる」「変更要求を迅速に受け入れてもらえる」というメリットは大きく、これまで現場が感じていた多くの不満を解消できるだけのパワーを秘めています。私がこう言い切れるのは、Wagbyユーザー会で実際に利用者から「開発スピードの向上は大いに有効」という、生の声を伺ったためです。
私が業務システム開発分野に従事して20年になります。いろいろ悩んだ末に、ようやくこの視点がIT部門への信頼を取り戻す鍵になると実感しました。開発スピードの改善は必ず、組織の活性化に貢献します。
*1:軽量プログラミング言語を駆使して従来のようにプログラムを書くことで高速開発を実現するというアプローチもあります。汎用言語は何でも書けますが、業務特化型言語は表現できないものは実現しないという割り切りがあります。それでも私は業務特化型言語によるノンプログラミング開発の方に可能性を感じています。その理由の一つは「プログラムを書かなければ、引き継ぎが行いやすい」ためです。プログラムを書くほどに複雑化し、ブラックボックスになり、保守もできず引き継ぎもできないという事例を何度も目にしてきました。この負の連鎖を断ち切るためには、ノンプログラミング開発の発想は有効です。
