「開発」タグアーカイブ

基幹システムを自前開発した中小企業は、経営者のレベルが低い

投稿日時: 投稿者:

たいていの日本の中小企業は、ITの活用レベルが高くありません。これは世間で言われているとおりと、わたしも感じています。ただし、例外にも思えるような中小企業が時々見つかります。なかには、会社のコアとなる基幹システムを自前で構築してしまったという中小企業も存在しています。

大企業が完全内製で基幹システムを構築、という例はほとんどないと思われますが、中小企業の場合、事業規模があまり大きくないことも手伝い、実は自分で作ろうと思えばできてしまうという側面があります。そうかといって社内にスキルの高い技術者がいないと当然不可能ですが、たまたま1人くらい「できる人」が社内にいると、その人が根気強く取り組んで構築を果たしてしまう、ということが起こるわけです。

うらやましい会社だ、と思うでしょうか。ベンダーに頼んで作ってもらうよりコストもかからなくて素晴らしい、と感じるでしょうか。わたしが見る限りでは、そうした会社は「経営者に問題がある」おかげで、大きなリスクを抱えていることが多いと考えています。

経営者が自ら手掛けてシステムを作ってしまった、というなら結構です。しかし、技術者が独力で作ってしまった、という状態は、経営者の情報システムに対する知識や理解の欠如、関与しようとする意欲の低さ、会社にとっての情報システムの位置づけの設計不足、等々の欠陥によって引き起こされた結果なのです。

そのとき、その会社の経営者は、何らコントロールができていません。言い換えれば、放任です。情報システムに対する知見がないがために、自分がコントロールしなければならないという発想さえも浮かばないのだろうと思います。それが、事業運営に大きなリスクを抱えることにつながります。

では、基幹システムが事業の根幹をなすクリティカルなシステムであることを十分に理解する経営者ならば、どのようなことを発想できることが求められるのでしょうか。

いくつもありますが、長くなりますので、そのうちの数点を以下に書き連ねてみたいと思います。「自分はこんなことを考えるに及ばない」と思われるなら、少なくとも社内のIT担当者が「作っちゃいました」と言い出してこないような業務環境にするよう努めるべきでしょう。

●　中小企業の自前開発は、たいていは特定の技術者が単独あるいは少人数で進め、達成します。そしてそのシステムの仕様を設計した技術者はまともに形式知化せず、その構築ノウハウは属人化します。それは、会社にとって大いなるリスクです。一刻も早く、システムに関するノウハウや詳細仕様をドキュメントとして完全に網羅し、保守を長く継続できるような組織と仕組みを整備することを考える必要があります。

特に、開発した技術者が高齢であるほど、その技術者が会社を去るまでの時間の制約が厳しくなります。そして、そういう技術者に限って、言葉や図式による表現やわかりやすい説明が上手くなかったりすることが往々にしてあります。システムの仕様や、細かい（けれど重要な）属人的ノウハウを引き継ぐ時間が限られる可能性を、十分念頭に入れる必要があります。

このとき、多くの経営者は、「若い技術者を採用して、開発したベテランの下に付けよう」ということくらいは思いつきますが、その程度ではまったく十分ではありません。必要なことは、「属人化から脱却すること」です。単に若手を採用すればよいという考えは、属人化した「人」に新たに属人化させる「人」を付けているだけのことです。属人化の継承では意味がありません。「組織で実行するにはどうすればよいか」を考える必要があります。
●　中小企業の基幹システムの自前開発は、その多くが10年近くかけて少人数の特定の技術者だけで実行されます。それほどの時間をかけて技術者に業務遂行させることの是非を、本来ならまず経営判断すべきです。

仮に是と判断したとしても、10年経たないと完成しないようなシステムで事業に役立つのか、その認識を経営者が示さない限り、技術者は好きな方法で、適当なスケジュール感で、システム開発を進めるでしょう。技術者の優先度と、経営者の優先度は、何のすり合わせもしなければまったく違ったものであるのが常です。技術者が優先するのは、技術の追求、技術の都合、技術の制約、です。経営者が自分から考えを示さない限り、彼らは経営の優先事項には何の関心もありません。逆の立場で、経営者にはIT技術者の発想がしづらいのと、同様のことです。
●　自前でシステムを開発できる技術者でも、態度には決して出しませんが、万能ではありません。プログラム開発には長けているがネットワーク設計は知識が低い、システム設計は得意だが情報セキュリティ設計には疎い、等々、だれでも得意分野と不得意分野はハッキリしているのがフツウです。IT分野に関する、会社としての知見の甘さを的確に検知して補強する努力は、ITを操る以上は必ず要求されると心得るべきです。

それを怠り、「うちの技術者は基幹システムが作れたのだから他のことも何でもできている」などと考えているなら、自社のシステムに知らずのうちに大きな欠陥を抱えるリスクがあります。そのリスクを軽減するには、まず経営者自身が、ITの技術分野のポートフォリオについて知ることです（技術に詳しくなれという意味ではありません）。そのうえで、自社では疎い技術分野を認識し、知見を持つ人材を（採用、外部支援両面で）採り入れ、組織を強化する努力をすることです。
●　自前でシステムを構築するにも知識が必要ですが、自前で作ったシステムを運用保守していくにも（別の）知識が必要である、と発想できるかどうかが問われます。構築出来たら終わり、使えていれば問題なし、ではありません。自前でシステムを運用保守するのに相応な知識体系を構築して、人材の育成を組織として継続実施することが求められます。

ましてITは常に進化し、またその進化は速く、既存の技術が陳腐化する可能性も高いです。ベンダーに依存していればベンダーが実行するようなことを、自前で情報システムを作った以上は自前で実行する義務がある、と心得るのが肝要です。

自社のエンジニアは、会社の費用で外部に修行に出すべきです。社内だけで教育しようとすれば、知識に偏りや淀みが起きやすいものです。まして人材に乏しい中小企業ならなおさらでしょう。外部で学ばせ、その知見を社内に持ち込ませ、社内の古い知識や偏った理解をアップデートさせるように図ります。または、外部の有識者を定期的に呼び寄せて、様々なテーマでレクチャーしてもらうことも考えられるでしょう。

優秀な人材に単に依存するなら、属人化するだけです。一流のシステム運営能力を持ちたければ、会社が「組織として」努力しなければなりません。それをリードするのは、経営者自身です。

どんなやり方にも「向き不向き」がある

投稿日時: 投稿者:

先日耳にした話です。某官庁でシステム基盤の統括をしているという人物が、政府の情報システムのグランドデザインやそれに伴う業務変革について語っていました。そのなかで、次のような趣旨のことを述べていたのに、いささか驚きました。

もしかするとご本人はそういう趣旨で述べたつもりはないのかもしれませんが、少なくともわたしには、次のような発言内容だったと理解されました。

いま想定している情報システムの設計方針は、マイクロサービスによる疎結合、APIドリブンで設計、開発スタイルはアジャイル。なぜならば、それが「トレンド」だから。

専門知識のない方々には上記の言葉はピンとこないでしょうが、ひとまず放置して先をお読みください。

情報システムを設計したり構想したりするにあたって、設計者が取りうる考え方はいくつか存在します。

それらのアプローチには、時節柄と言っていいのかわかりませんが、話題によく上るものが確かにあります。そうしたものを「トレンド」と呼ぶのなら、トレンドはあるのでしょう。

ただし、これまでに登場したどのような設計アプローチにも、それを採用するにあたっての前提や条件があり、結果として向き不向きが存在するのが現実です。情報システム設計における万能アプローチともいえる決定版は、個人的にいろいろ勉強してきましたが残念ながらわたしは知りません。

よって、少なくともわたしの理解では、設計アプローチは「状況に対応して適切に選択するもの」なのであって、採用する方針は「何を実現したいのか」「アプリケーションをどう動かすべきなのか」というポリシーに従って決定されるものです。トレンドで選ぶものではありません。

例えば、冒頭の引用にある「マイクロサービス」について考えてみます。簡単に言いますとこれは、他とは完全に独立した小さな機能を「サービス」という単位にしてまとめ、それらの小さな「サービス」をたくさん配置して、その「サービス」の間を通信で連携させることで一定の目的を果たそうとする、情報システム設計の考え方のことを指します。

この考え方では、ひとつの単位を占めるサービス（機能）は小さいので、入れ替えることが容易です。作り替えようとした時でも、個々のサービスは独立しているので、他への影響範囲を小さく抑制することができます。新しく追加しようとするときも、他のサービスに影響を与えずに開発して、あとから通信で連携すればいいので、柔軟にシステムを拡張したり改善したりできるのです。

ただし、難点はたくさんあります。大雑把な説明をしますと、「独立した小さな機能」というのは理想的ですが、これを実際につくるのは案外難しいのです。「独立した」とはつまり、他のサービスからは完全に切り離されていなければならないのですが、一切の相互干渉がないように完全に切り離す設計をするのが難題なのです。

それが的確にできないままにマイクロサービス化していくと、重複した機能やデータを持つ複数のサービスが知らぬ間に出来上がり、それが増殖していくことになります。次の難点は、増殖しやすい分運用管理がしにくくなりやすいこと、さらには、増殖するたびに通信のパスが増殖すること、です。無秩序に拡大してしまうことも考えられ、全体としては、品質要求が高いシステムにはあまり向いていない作りになりやすい特徴があります。

もうひとつ、冒頭の引用にある「アジャイル」についてはどうでしょうか。

これは、情報システムの開発手法の一形態です。ざっくり言えば、予め要求を決められないシステムに対して、まずは大事そうなところから小さく作ってみて、それをどんどん改善しながら大きくしていこう、というようなシステム開発のしかたのことを言います。

世の中には、どういうものが欲しいのか？と言われても、ざっくりとした要望以外に何も細かく決められないことがたくさんあります。そうした場合であっても無理やり要求を固めようとするのは、現実的ではありません。アジャイル開発は、そうした状況に対応できるシステム開発のやり方です。

ただし、ご多分に漏れず万能ではありません。要求を固めずに開発を進める以上、始めからパーフェクトな機能が揃ったシステムは、当然完成できません。アジャイルでつくるシステムは、始めはいまいちですが、だんだんと良くなっていきます。つまり、システム完成当初から一定の品質以上の動きをしてもらわないと困るようなシステムの開発には、向いていないのです。そういうシステムは、やはり設計の時点で要求を固める努力が必要になります。

2020年10月のコラムでわたしは、国のシステムは超巨大で一筋縄ではいかない旨を記しています。どの領域でどのような設計思想を採用し、どのようなアプローチで最適化していくのかは、本当に大変な作業だろうと想像します。少なくとも、そうした方針を「トレンド」で選定すれば解決するような話ではないと思います。

デジタル庁は発足当初から、ITスキルの高い外部人材を大々的に募集し、働き方も柔軟に対応できるようにしたことで、多様なスキルを持つ優秀な人材が多く集まってきていると聞きます。それは大変喜ばしいことですが、昔の某プロ野球チームのように4番バッターばかり集まってきてはいないでしょうか。みんなトップ人材、みんなリーダー格、みんなその筋ではスゴイ人、では、船頭多くして船山に上る、ということになります。まあ、わたしにとっては要らぬ心配なのですが。

「アプリは自社で内製」がフツウになる時代

投稿日時: 投稿者:

近年は、アプリケーションを内製開発する企業がずいぶん増えてきたように感じています。

背景には、ノーコード／ローコード開発ツールのようなプログラミングを簡易化するソリューションの充実、SaaSやPaaSの機能充実化などがあります。コードが書けなくても、専門知識があまりなくても、パーツを組み合わせるような形で処理を組み、データの器を用意することで、簡易で単純なものであれば、動くアプリケーションが短時間のうちに完成してしまうようになっています。

アプリケーション開発の敷居が下がったことで、モノによっては、現場の業務部門の人でも欲しいアプリケーションを自作できるような状況になっています。そうであるなら、外部のベンダーに頼んで何カ月もかかるよりもはるかにメリットがあるということで、ソフトウェアを内製する企業が増えているわけです。

かつてEUC（End User Computing）という概念が流行しました。そのときと同じような雰囲気があります。EUCはその後廃れましたが、なぜ衰退したかというと、各所であまりにも好き勝手にプログラムが作られて、会社としてそれらの管理が行き届かなくなり、作ったものを誰もメンテナンスできなくなった、ということが要因のひとつでした。エクセルのマクロにも、同じような話があることは有名です。

今回の内製化の動きでも、同じような事態に陥る企業はおそらくあるでしょう。ただし、過去の反省を踏まえて、制作したアプリをうまく管理する仕組みを導入したり、またはそれを意識したガバナンス体制を敷くなど、工夫する企業も多くあります。

さらには、アプリと共に使えるセンサーやモジュール、はてはロボットまでも、割と手軽に手が届く状況も生まれています。価格も比較的低下し、またインタフェースが標準化されてきたことで、アプリとの連携も随分しやすくなりました。一昔前までは大企業がおカネを相当かけてやっていたようなことが、それこそ個人レベルでも実行可能な状況なのです。

うまく内製してアプリを使いこなしている企業を見ていると、そうして自在に開発すること自体が、対応力・スピード・柔軟性などといった競争力に直結するようになってきていると感じます。こうした状況が定着すれば、そのうちに、どんな着想を得られるかというアイデアの勝負になっていくかもしれません。または、どのベンダーのプラットフォームを選んで開発しているか、という点で差がつくような事態も、生まれるかもしれません。

ただし、当然ながらうまい話ばかりとは言えません。ノンプログラミングで開発できるようなツールは、複雑で高度な処理の構築はあまり得意とはしていません。部署内の単純作業のような、小さく閉じる領域なら向いている傾向なのが現状です。また、ツールによって得意分野が異なる傾向もあり、選定のしかたも重要になります。

目利き力は要求されるものの、試すだけなのであれば、資金的なハードルもかなり低くなっています。できる人がいないと嘆くより早く、どんどんやってみることができる企業のほうが先に進む。そんな時代になっていることを、経営者の方々には十分認識していただきたいと思います。

成果を問わずに成果を目指す「胆力」（後）

投稿日時: 投稿者:

先月のコラムから、AI（人工知能）の採用・導入について述べています。今回はその後編です。

先月は、AIには「使えるデータ」が必要である、そして、AIによるアウトプットの精度を高めるのは案外大変なことである、ということをお話ししました。つまり、AIには「モデル」と呼ばれる分析のシナリオが必要で、その構築にはおよそ試行錯誤を伴う、つまり時間がかかり、それほど簡単ではありません。

例をひとつ挙げてみます。Googleの音声AIであるGoogleアシスタントには、日英翻訳の機能が付いています。「英語の通訳して」などと命令して、日本語でAIに話しかけると英語にしてくれる、というものです（逆もできます）。

ある記者氏が、翻訳を実際に試した内容を記事にしていました。それによれば、こんな結果だったそうです。

（原文のまま引用）
日）シティーハンターの新作映画はコラボするキャッツアイの長女のを誰が演じるのかと思ったら戸田恵子が次女とのダブルキャストでびっくり
英）City Hunter’s new movie collaborates When thinking who will play the eldest daughter of Cat’s Eye Toda Keiko is surprised at double cast with the second daughter

この記者氏は「意味はおよそ通じる」などと評価していますが、とんでもありません。元の日本語はFacebookの投稿らしいのですが、日本語のむちゃくちゃさ加減を飛び越えて英語はぐちゃぐちゃです。戸田恵子さんがびっくりしたことになってしまっています。

当のGoogleアシスタントは、米国の調査会社によるAIアシスタント比較調査で、Siri、Alexa、Cortanaという有名どころの競合を押さえてトップのIQだと評価されています。それでも、複雑な口語体の文章になるとこのくらいのレベル感だということです。精度を高めることがどのくらい大変か、想像していただけるでしょうか。

この問題もまた脇において、仮に、業務で使えるほどに精度の高いモデルが構築できたとしましょう。しかしそれでも、精度100%（つまり、間違いがゼロ）というのは至難の業です。100%ではないということは、AIが想定外の挙動を示すこともあり得ることになります。そうなると、絶対に間違ってはいけない業務システムにAIを適用するのは、普通の感覚なら怖いと感じるはずです。

そこにも折り合いをつけてシステム化し、運用するとしたらどうでしょう。問題は終わりません。先に申し上げたように、AIはデータを食べて動いています。運用中に異常なデータが入り込もうものなら、一発でアウトです。異常なデータが投入されないように日常的にケアすることが必要です。

それを人力や自動でうまく仕組み化できたとしても、実はAIは、正常運用しているうちにモデルの精度が劣化していくことがあります。精度の劣化を検知してモデルを改修する、という活動も必要になるのです。

ひどい話ばかりで、やりたくなくなってしまったでしょうか？しかし、考えてみてください。

ここまで説明したことを理解したうえでAIに取り組み、時間をかけてモデルの精度を向上させ、その成果として盤石なシステムを作り上げたとしたら、どうでしょう。それは、相当レベルの高いノウハウです。出来ないからといって取り組んでいなかった他社は、もうその企業に追随不可能でしょう。覆すことができないアドバンテージになる可能性が高いと思われます。

それに気付いている会社が、成果はそこそこでも今のうちからコツコツ積み上げようとしている。それが実際の姿なのです。

AIの採用や導入には経営者の「胆力」が必要である、と申し上げているのは、これが理由です。

取り組むとしたら、マスコミによるセンセーショナルな見出しに惑わされて飛びつかず、成果を長い目で見られるか自問してください。限定された用途範囲で軽い責任しか負わないようなものから始めてみて、徐々にレベルを高めていくようなシナリオが描けるなら、取り組み方としては理想的かもしれません。

　

成果を問わずに成果を目指す「胆力」（前）

投稿日時: 投稿者:

新聞に「AI（人工知能）」の話が頻繁に出ているのを見るにつけ、それとなく焦りを感じている経営者の方がいるかもしれません。

金融機関や製造業を筆頭に多くの大手企業がAIを活用した仕組みを開発し、話題になっています。それに伴って、その開発を支援するベンチャー企業もちらほら名前が目に付くような印象です。適用分野はなかなか多彩で、事務処理の分野から、建設や農業、水産業といった分野にまで広がりを見せています。

マネして追随したくなりますか？うまく行ったら「先端を行く企業」と称賛されるかもしれませんね。ただ、AIの採用や導入には経営者の「胆力」が必要であることを、ぜひ知っていただきたいと思います。

AIの開発に利用できるソフトウェアやクラウドサービスは、急速に充実してきています。技術力のある人がその気になれば、無料でも結構なレベルまで試作することも可能です。少し投資ができるなら、AIを得意にしているベンチャーやベンダーなどと組んで、何らかの実証システムを組むことも難しくはないでしょう。

ただし、AIの開発に一番必要なものは、システムではなく、データです。しかも「使えるデータ」が必要なのです。

およそいま手元にあるデータというのは、AI向けに利用したい目的とは異なる目的でデータ化されています。ありものをそのままAIに食べさせても、実は満足には使えません。

例えば、オークションサイトには品物の写真が大量に存在します。この品物がブランド物である場合に、本物か偽物かを判定したくなるとしましょう。写真がたくさんあるのだからAIに判定をやらせればラクではないか、と思うのがフツウの考え方です。しかし、いまサイト向けに持っている画像を真偽の判定に使おうとすると、画質や撮影の角度などが問題になってうまく行かない、ということが起こるのです。

AIにはデータが不可欠です。しかも、ただのデータではダメで、「使えるデータ」でなければいけません。用意するのは、他ならぬ自社自身です。「使えるデータ」を揃えられるようにするのが、まず大変なのです。

仮に使えるデータが集められたとしても、それだけでAIによるアウトプットの精度が保証されるわけではありません。それはまた別の問題になります。

少々乱暴に説明してしまえば、AIには「モデル」と呼ばれる分析のシナリオを組み込む必要があります。「モデル」がAIの実体、と言ってもいいかもしれません。

このモデル構築、少ない要素で簡単に筋書きを見出せるような分析テーマであれば、それほど苦労しないかもしれません。一方で、判断が感覚的であいまいなテーマであるほど、モデル構築の難易度が上がります。

AIにやらせたいことは説明が簡単でないことなのが通常です。従って判定したい現象をモデル化するには、試行錯誤が必要、つまり、時間がかかります。そんなに簡単にアウトプットの精度は上がりません。

…と、ここで例を挙げて説明するつもりのところなのですが、以降の文章が長くなってしまいましたので、続きは来月にします。もしよろしければお待ちください。

さすが銀行のビッグプロジェクトはすごい、と思ってはいけない

投稿日時: 投稿者:

先日、みずほ銀行のシステム統合プロジェクトの工期が約1年延期されることが発表になりました。

同行の勘定系システムは稼働からすでに25年以上が経過しているなど、かなり老朽化・複雑化しているとのことで、さまざまな事情とリスクを勘案した結果だろうと推察します。

マスコミは同行のシステム統合事例を「史上最大規模、世界でも類を見ないシステムプロジェクト」として取り上げるきらいがありますが、わたしはこの事例は、多くの企業が手本とすべきものではないと考えています。

この事例のような大規模システム全面刷新、いわゆる「ビッグバン導入」は、本来避けるべき方法です。莫大な労力と費用を投じた挙句に頓挫するリスクが非常に高いやりかたです。難易度が非常に高いぶん、成功すれば大々的に取り上げられて一様にほめられるでしょうが、正しい努力だとは思えません。同行にとっては、残念ながらこれしか選択肢がないのだろうと、わたしは見ています。

システム開発プロジェクトの理想の姿は、小さく実施することです。プロジェクトの最大の目標は、「つつがなく完了する」こと。そうだとしたら、もし元のシステム構想が大規模であれば、それをできるだけ小さく分割してコントロールを容易にし、リスクを下げて実行できるようにしたほうがよいのは当然です。さらには、開発規模が小さくなればパートナーに選定できるベンダーの幅も広がり、コスト削減の可能性も大きくなります。

大規模なものを大規模なまま実施するということはつまり、ユーザー企業が、いかに分割すればよいのかにアタマを使っていないということです。そして大規模にすればするほど、いわゆるITゼネコンでなければ受注できないようなシロモノになり、コストは半端な規模では済まなくなります。

ビッグバン導入は、百害あって、成功すれば一利に加えてマスコミに取り上げられてほめてもらえる特典くらいあり、失敗や頓挫をすれば百害に加えて会社が傾くほどの損害まで被るかもしれません。経営者はこのことを直感では感じていることが多いのですが、IT担当が出してくる計画にロジカルに反論する力がないのが実情でしょう。

そうした計画しか出せない諸悪の根源は、ビッグバン導入以外に選択肢がなくなってしまうほどに、企業内のリーダー層が、システムのつくりの問題に見て見ぬふりをしてきたことなのかもしれません。それは、経営者の責任でもあります。経営者にはこの点に、まずは目を向けていただきたいと感じています。

「高速でつくる」前に、やるべきこと

投稿日時: 投稿者:

ビジネスの変化は速い。それなのに、情報システムがビジネスの変化のニーズに対応できないのでは困る。だから、情報システムもまた、速くつくれなければならない。

まったく、そのとおりだと思います。実際、情報システムが足かせになることで、新しいビジネスの取組みに支障をきたしたり、競合に比べて満足のいくものにならなかったりすることが起こっています。それに対して、その場しのぎの対応でお茶を濁している例も少なくありません。経営者の立場になれば、これだけカネ掛けて何のための IT か、という話になってきます。

こんな風潮のなか、システムやアプリケーションの高速開発を実現する手法がいろいろと提案されています。中でも代表的なのは「アジャイル開発」でしょう。

ご存じないかたのために端的に説明すれば、アジャイル開発とは、従来のように厳密にすべてを設計することなく、まずはプログラムをつくって動かすことを優先し、さらにそれを少しずつ改良していくことでシステムを仕上げていく開発手法のことです。ウォーターフォールと呼ばれる従来型の開発手法に比べ、システムに対する要件が後からでも取り込みやすく、設計のドキュメントをつくる工数を少なく済ませることが大きな特徴になっています。ちなみに、英単語である「アジャイル（agile）」には、「迅速な」「敏捷な」といった意味があります。

確かにこれは有力な開発手法で、広義に捉えれば、こうした「作っては直す」開発手法は以前からいくつか提案されてきてもいます。それほどに、柔軟性のある開発手法には以前からニーズがあるわけです。

一方、なかには近視眼な人がIT業界にもいて、「もうアジャイルじゃなきゃ無理でしょ？」とまで云う声も聞こえてきます。先日も、そんな発言をする人に出会いました。

現在使える「速くつくる手法」をうまく適用できれば、これまで何カ月、何年とかかると言われてきた情報システムが、数週間ないしは1～2か月でできてしまうことが実際に起こります。ただしそれは、「速くつくる基盤」があってのことです。これを忘れてはなりません。ドライバーが車をカローラから F1 カーに乗り換えるかように速くなるわけではないのです。

ここでいう「基盤」には、ふたつの意味があります。それは、システムを開発する技術環境の基盤という意味と、その基盤を活用できる組織のガバナンスや体制の基盤という意味です。これらをそろえて初めて、本当の意味で「速くつくる」ことができるようになります。

特に前者の「システムを開発する基盤」は、いったん整備されれば、その柔軟性がビジネスの柔軟性そのものになると言っても過言ではありません。そのため、ことこの基盤を整備しようと思えば、関係者間で共有されたビジネスの目的や今後の戦略などのもとに綿密に企画設計し、構築することが要求されるのです。

どうも先ほどのような近視眼な人たちは、この点をすっかり忘れてしまっているか、ここもアジャイル開発できると思っているか、どちらかのように思えてなりません。

またアジャイル開発では、ITの関係者も、そのシステムにかかる業務の関係者も、一堂に会したプロジェクトチームによって開発を推進していくことが特徴になっています。プロジェクト期間中は毎日同じ部屋で仕事をするようにすることもよくあります。なぜそうするのかといえば、チームとして一体となることで関係者間のカベをなくし、意思決定のスピードを上げるためです。開発は速くできるポテンシャルがあるのに決めるのが遅いのでは、何のためのアジャイルか、ということになるからです。

さらに言えば、そうしたチームづくりは規模が小さければハードルはあまり高くありませんが、全社レベルのシステムならどうでしょうか。グローバルなシステムならどうでしょうか。関係者が増えるほど、距離が離れるほど、意思の疎通は難しくなっていきます。それを克服するような組織体制ができていなければやはり、何のためのアジャイルか、ということになるのです。

情報システムにもっとスピードが欲しいと考えておられる経営者や経営幹部の方々には、自社の情報システムがこうした「速くつくる基盤」を実現できているのか、まず確認されることをお薦めします。もしできていないなら、「速くつくる」前に、そのための基盤整備に投資を行う必要があるということです。

システムは、技術者やベンダーに任せていればできるものではありません。