システム開発の勘どころ

ＣＥＯ上田

2020年11月19日

わたしはプログラミングをやったことがない。IT用語辞典など、必要に迫られて読むことは読むが、小難しいIT専門用語（特にアルファベット3文字にやたらと短縮したがる傾向）にはアレルギーがある。SEという人種は性格が悪いと心から思ってきたたちである。しかし、創業以来、ECを本業にする手前、システム開発とは切っても切れない関係にある。これまで何度もシステム投資に失敗してきた経験もある。そんなずぶの文系経営者によるシステム開発に対する勘どころをまとめてみたいと思う。

まずもって一番重要なのは、自分自身（経営トップ）が前線に立って意思決定をすることである。自社の事業において自分に勝る判断力を有する者はこの世にいない。そう強く自覚して戦いに挑む。基本的な仕様は細かなところまで絶対に自分が意思決定しなければならない。社員や取組先の担当者に任せてはいけない。そして、特に重要なことだが、「技術者」に方向性の判断をさせないこと、これは絶対である。私は過去、これでかなり痛い目を見た。

この文章は、そうした失敗からの教訓である。

開発実務のプロセスで最も気をもむのがSE（技術畑）との打合せである。これは私に限らずほとんどの文系経営者が同じ意見であろう。とにかく、腹立たしいことこの上ない。しかし、そのコミュニケーションの場においても、必勝の心構えがあることに気が付いた。それは、唯ひとつ、「自分がわからないことは必ず質問すること」である。しかも、わかるまでしつこく、それこそ自分が小学生に戻ったくらいのつもりで。「自分の頭」で、そして、「自分のことばで」理解できるまで質問を繰り返す。そして、何度も頭で反芻して理解する。もし、時間切れになって納得感が得られなかったら、その案件は意思決定してはならない。決して中期経営計画にシステム開発のスケジュールを合わせない。システム開発のスケジュール（すなわち自身の学習速度）に中期経営計画を合わせる。そう腹をくくるのである。

そのうえで技術的な課題を大きな絵の中に位置づける。すなわち、自社は何屋なのか。その図式の中にシステム課題を置いてあげるのである。「自社が何屋なのか」という問いは、自社の強みを問い返す質問である。何が収益の核になっているのかを改めて気づかせてくれる。そして、システムが具体的な顧客価値の「何をどれほど強化してくれるのか」を明確に知ることが肝要である。そこを妥協してはいけない。経営トップがシステム開発実務の前線に立つ意味はそこにこそあるといってもいい。

例えば、「業務の速度が速くなるはず」という一般的な意見なども、自社のどこがどれほど（時には何秒単位で）早くなるのかを試算すべし。携わる人が減らせるはずという一般的な見解も、「人数が半減する」などというあいまいな見解で満足するのではなく、業務プロセスのどこの部分がどう省略できるのか、その場合、組織構成はどうなるのか、顧客はどこをどのように喜んでくれるのか、というところまで詳細にイメージすべきである。

カギは一般論で満足しないということ。かならず自社の具体的な業務プロセスと顧客価値、そして、仕上がりのP／L、B／Sまでをイメージすることである。必要とあらば、現場の意見をみずから確認すべし。自身の中のあいまいさを廃除せよ、である。開発プロセスを、自分の手の内に収めることである。

もうひとつ大切なことがある。それは、開発までのプロセスよりも運用に入ってシステムの改修・拡張に入ったときの「運用体制を安定させられるか？」という点である。業界全体、社会全体における技術的な進歩にばかり目を奪われ、対応する人的リソースを確保することを疎かにすることが多いことを自覚するべきということである。特に外部ベンダーと話す際、先方の営業担当者は最新技術を売り込むことが多いが、果たして、それを導入したとして、恒久的に対応し続けられるのか。社内外問わず、人材は確保できるのか。この場合、「社員はすぐにやめてしまうもの」と考えるのが経営者の責任である。冷徹な目を必要とする。

最新の技術を使うのが事業で勝つコツではないことの方が多い。時代遅れの技術に感じても安定運用の体制を整備することで結果的に事業速度が上がるということは多いのである。アマゾンのクラウドサービスなどが典型であろう。コストが変動費化できていいという触れ込みだが、だいたいの中堅規模の事業会社は導入に失敗しているようだ。それはAWSの技術者が確保できないがため、である。提案した社外ベンダーのその担当者は永遠にわが社のために働くのか。社内に技術者を常時ひとり確保できるのか。そして、その技術者は経営陣の信用を得られるのか。この課題がクリアできないことが原因である。その失敗がとても多い。リソースの豊富な大企業ならいざ知らず、限られたリソースで対応せざるをえない中規模会社にとって信頼できる技術者の確保は至難の技である。ここは「デジタル概念的な正解」よりも「アナログ現実的な正解」をこそ取るべきポイントであろう。

運用体制の問題と密接に絡むが、開発言語やOS、サーバーの構成、そして、何をどこまで作りこむのか？というシステム品質の問題にどう対処すればいいのか、という問題もある。これをどう考えるのか。

よく技術者は「システムに出来ないことはない」という。しかし、これはあくまで技術的な観点だけでの話。頭の中での話である。実際は、ひとがやることなので、契約が切れたり、退社したり、やる気を失ったり、病気になったり、と様々な理由で「システムにもできないことがある」のである。そして、現実には、こちらの理由で頓挫する事例がとても多い。それを考えておくことがもうひとつの重要なポイントである。

ゆえにこの場合、技術者の意見は極力採用しないほうが賢明である。その人間がたとえ実現できたとしても、開発には何年もかかるのである。終わりまでその人間が責任を持つことなど決してないことを知らなければならない。最後まで責任を持つべきは自分であって他者ではないのである。それを忘れないこと。それを前提に技術的な水準を選択することが重要である。

アップルの成功はジョブズの構想力も当然あるが、最後までウォズニアックが伴走してくれていたこともまた大きいのである。技術的担当者が最後まで変わらないでいるかどうか。変わってしまう恐れがある場合、高度な最新技術は逆に足かせになることがある、それを忘れてはいけないのである。奇跡的な出会いは、やはり奇跡なのであって、誰にでも訪れるものではない。奇跡がなくても成功できる方法を考える。それも経営者の責任である。

21世紀のこの時代、システム開発に無縁である会社、経営者はもはやいない。どんなにアナログな業種・業態でも、競争のためにシステム投資は必須である。成功している会社は例外なく「ここをうまくこなしている」。

しかし、かならずしも最先端技術を導入しているということではない。流行の技術に堂々と背を向ける経営者も多いはずだ。要は、自社は何で勝つのか、技術は具体的にどこを優位にしてくれるのか、そして、その運用体制は恒久的に持ちうるのか、に真摯に答えることこそ肝要と心得ている。事業会社にとってIT技術の導入は結果であって目的ではない。見栄を張って、結果でしかないものを目的とはき違えることを戒める。それが技術的な課題を考える際の文系経営者としての勘どころなのではないか。そして、その間に、経営者みずからが真摯に新しい知識に向き合うこと。逃げることなく理解を繰り返すこと。そうすれば次第に、専門用語にもアレルギーを持たないようになれる。技術者とのコミュニケーションもコツがつかめるようになる。

これは、ずぶの文系経営者の１５年に及ぶシステム課題格闘日誌の結論である。まだまだ格闘は続くが、ひとまずここにまとめておきたいと思った。参考にしてもらえれば幸いである。