ＩＴ企業に求められているのは「解決」

だと思うんです。私見ですが。

いきなり何言いだすんだ、と思うでしょうか。でも、以前もお話ししたように、そもそも「仕事」ってのは「指示」「依頼」「命令」などによって目の前に与えられた課題や問題を解決することのはずです。

で、そもそもＩＴなんてのが発展していなかった当時は人の手で行われていたことを、ＩＴの発展に伴い、ＩＴ化していくことで、「ヒト」が行っていた業務を肩代わりさせ

　・効率化
　・ミス撲滅

をしようと言うのが、ユーザーがＩＴを活用しようと言う目的です。言い方を変えると、

　ユーザーの現状に対する「困った」を確認し、
　ＩＴを駆使してユーザーが求める理想的な解決を提供する

のがＩＴの存在意義だと思うんです。

にもかかわらず、なぜかＩＴ企業の中では「技術、技術」と目先の技術にばかり傾注しようとしてしまう…モノづくりが楽しいのはわかるんですけど、もうちょっとビジネスの観点を持ってもいいんじゃないかな？と常々モヤモヤしています。

ＩＴ業界の「上中下」

ですから、私の中ではＩＴ業界の「上中下」を、次のように定義しています。

そのままＶ字モデルあたりを活用した時の担当の違いのようにも見えますね。中と下は同じかもしれません。

目先の技術はシステム開発において、ただの実現手段でしかありません。実現手段の手札が増えればそれだけ色々な解決方法を提案することができるかもしれませんが、それでも「技術だけ」で問題が解決することは絶対にありません。いわゆる「プログラマー」の域から出ないからです。

中の開発は、一般的にシステムエンジニア（通称、ＳＥ）やプロジェクトマネージャーが担う領域です。システム開発は通常、プロジェクトと言う単位で運営され、開発が終わり、納品すればプロジェクトは解散します。ですから、プロジェクトと言う単位を正しく推進し、ユーザーが望むものを作り上げ、納品する…この一連の流れにおいて、

　・実現手段の構築や設計、時には実装を行うものを「エンジニア」
　・それらの開発が順調に進むよう監視し、調整するのが「マネージャー」

というわけです。ですが、開発しただけでユーザーは満足するかどうか、問題が解決するかどうかは別問題です。たとえば、「納期遅延を起こした」「品質が悪い」「利用者からクレームを受けた」なんてものは解決できた、開発できたとは言わないからです。むしろ、

　「ユーザーが必ず納得する」ようなプロジェクト運営になっているか？

と言う観点が必要なはずです。ですが、残念ながらそんな考え方でマネジメントやエンジニアリングに従事している人はごく僅かなのではないでしょうか。

そこで重要になってくるのが、「中」と「下」を踏襲しながら「上」の視座に立って活動できる人材です。むしろ、どんな形であれ、解決さえしてくれればユーザーは喜びませんか？

ユーザーは解決のために、

　「絶対にシステムが必要」
　「最新技術のものでなければならない」

と言っているわけではありません。あくまで

　「限られた予算と期限の中で、問題を解決してほしい」

と言っているだけなのです。そのうえで、ＩＴ企業側の都合として、

　「極力コストを抑えたい」
　　　├ = トラブルを起こしてほしくない
　　　└ = 余計な人件費をかけてほしくない

と言ったニーズがあるので、そちらも叶えなければならないわけです。

solutionを究極化したい

私は、solution を担当する一人として、ユーザーのニーズ、そしてＩＴ企業のニーズをそれぞれ満たす、ただ満たすだけでなく

　・安定して満たす
　・常に限界利益が最大値となるよう満たす

ようにしたいわけです。

しかも、優秀な人材ばかりのメガベンチャーみたいな組織ではなく、旧態依然としたチーム、人材もピンキリで凸凹しているチーム、そんな組織でも未だに法定労働時間で終われない（残業ばかりの）ような、苦労しているエンジニアを減らし、誰もが安定した仕事量の中で、きちんとニーズを満たせるようなしくみ（開発モデル）をつくりあげたいのです。

ユーザーのニーズを満たすための取り組みは、ユーザーの性質にもよるのでここで具体的には言いませんが、それもパターン化すればある程度の対策はしくみ化できます。年間、数多くの開発プロジェクトが立ち上がっているようなＩＴ企業であれば、そのデータを蓄積すれば容易に対策を検討できるでしょう。

問題なのは後者ですが、ＩＴ業界にいらっしゃるみなさんは、この限界利益が最大値になる（する）ための開発方法を常に意識していますでしょうか？

限界利益を上げると言うことは、要するに

　・３Ｍ（ダラリ）を根絶する
　・一人ひとりの生産性を向上する、向上する施策をとる
　・ミスや漏れによる手戻りコストを根絶する

と言うことです。そのための努力をすると言うことです。これはユーザーにとっても、ＩＴ企業にとっても、ものすごく重要な視点です。ユーザーにとっては、無駄なコストをかけなくて済むわけですから、限られた予算内でできることが増えるかもしれないわけです。当然、顧客満足度の向上に貢献できることでしょう。営業力の強化にもつながります。

これってＩＴ企業にとってもものすごく大事な考え方ですよね。

限界利益率がしくみによって向上できれば、常に安定して高い利益維持が可能となるわけです。さきほどの「顧客満足度」向上による営業力が強化されれば、多少の不景気などまったく気にならなくなります。

不景気によって、ＩＴ投資が冷え込んだところで、ＩＴの仕事がなくなることはありません。ただ単に減るだけです。それでもＩＴ企業数自体は変わらないわけですから、少ないエサの取り合いになって、１社ごとの売上や利益に影響が出やすくなる…と言うのでしょうが、競争力自体が強化されていれば、同業他社なんて意に介することがなくなります。世の中の仕事量が減ったところで、その減った仕事を依頼してくれるユーザーに「おたくの会社に開発をお願いしたい」と言わせればいいだけです。

不景気になって仕事が減ると言うのは、実はユーザーにとって、自分の会社の評価（満足度）は高くないと言うことを表しているにすぎません。景気が良くて、評価の高い会社では仕事があふれて請けられないから、仕方なく自分たちのところに仕事が来ている…と言う状態であれば、不景気になって仕事が減っても文句は言えませんよね。

　・安定して成功させる
　・「限界利益」を最大化する
　・ついでに「顧客満足」も最大化する

私は、これさえしていれば、一生仕事に困らないと思っていますし、同業種内でナンバーワンになるのも難しくないと思っています。むしろ、オンリーワンを目指す方が難しい…。

で、作っちゃいました。

いくつかの条件を満たす必要はありますが、私はこれらを「しくみ」によってある程度体系化しました。

基本的なコンセプトは、既存の開発手法をベースにアレンジを加えるものです。これは、ウォーターフォールでも、スパイラルでも、プロトタイピングでも、もちろんアジャイルでも、Ｖ字モデルをベースにしているものであれば、どれでもテーラリング可能です。

ですので、すでに企業内で体系化された開発モデルがあっても、それを白紙に戻す必要はなく、そこにテーラリングをおこない、少々改造するだけで導入可能です。

ただ、効果を出すための条件は

　①開発体系がある程度決まっている
　②決める部署や人物の協力が得られる
　③ソフトウェア品質を専門としている部署や人物の協力が得られる
　④プロジェクトマネージャーの理解を得られる

です。厳密には、開発モデルとマネジメントモデルの集合体なので、四角四面に言われた通りだけのことをすればいいものではありませんから、それぞれの役割ごとに求められる活動にも影響が出てきます。ですから、それら関係者の協力が必要不可欠になってくるのです。

①が結構面倒なのですが、こんなの普通は大手SIerにしかありませんよね。通常は、プロジェクトの中で決めていて、マネージャーやエンジニアが知恵を持ち寄って、独自様式の成果物を用意しようとします。もちろん、それらごとに適用するのは難しくないのですが、都度適用させようとすると、それなりの冗長コストが発生しかねません。理想は、企業として開発体系がある程度確立されている方が、何かと効率的だと思います。

②③④すべてを満たすのもそこそこ面倒です。

②は一般的に「生産管理」や「生産技術」なんて部署が担っていると思います。部署がなく、プロジェクトごとに決めているのであれば、リーダーやマネージャーと言うことになるでしょうか。

③はＱＡ部門、いわゆる「品質保証」「品質管理」と言われる部署ですね。大抵の場合は、プロジェクトごとにそうした専属の担当者がつくことは無いと思うので、いない場合はおそらく満たすのが難しくなります。属人的な品質観点しか持てないようでは、「しくみ」を運用することが困難になるからです。

④は「開発部署」の課長以上（できれば部長の方が…）でもいいと思います。おそらくはもう技術的な話についてこれず、ふんぞり返っているだけ…と言う人もいるかもしれませんが、真摯に協力していただけるのであれば問題ありません。

と言うか、②③はともかく、④についてはプロジェクトチームにトップダウンで取り掛かってもらうよう、あるいは滞っているようなら指導してあげられるようにしてほしいので、どちらかと言うとしくみを「理解」してほしいんですよね。

これらの条件が満たせられれば、私が構築したしくみによって、安定的にニーズを満たし続け、大きな失敗なんて発生することなく、限界利益を追求できる体制が作り上げられます。

問題はこの作り上げた『しくみ』をどうするか

一番の理想は、どこかの企業に属して、経営層に近い権限（できればＣＱＯの役職）をもらって、トップダウンに近い形で企業内活動を徹底させていく方法です。今在籍している企業にいて部長やっていてわかりましたが、

　・他部署の同列の人に話持って行っても、聞く耳持たれない
　　（出世競争とかなんか考えてて、協力したくないんだろうな…）
　・上司（経営層）が理解についてこれないと、会社の事業にならない

と言う問題があります。せめてかなり位の高い執行役くらいの権限を貰わないと、上も横も足枷になるようでは、浸透させられません。きちんと権限をいただければ、１年で試行し、３年で効果がそれなりに目に見えて、４～５年で計画比から損失していた額の８～９割は利益改善させられると思います（いやまぁ、プロジェクトが抱える問題次第ですけども。「開発の進め方」に問題があるなら、８～９割も夢じゃないはずです）。元々、既存の開発モデルに少々手を加えるだけで済むので、変化点が少ない分、馴染むまでにはそれほど時間がかからないしくみなのです。

大手SIerで採用されたりなんかするのが一番理想かもしれません。

私自身の栄達がどうこうよりも、やはり年間の受注数/受注規模が桁違いなので、この「しくみ」を導入することで、苦行のようなデスマーチから解放されるエンジニアや外注まで好影響が出るのかと思うと、ｗｋｗｋします。二次請け、三次請けまで考えれば、どれほど多くの人たちがトラブルプロジェクトに悩まされずに済むことでしょう。

企業としても、そういった開発モデルが功を奏し、ニュースリリースなどで大々的に取り上げてみれば、投資家の動きも活発になるかと思います。また、他の競合SIerとの差別化も図れて、競争力の強化に紐づくことでしょう。受注や売上にも大きく貢献するはずです。

２つ目の案としては、その「しくみ」を買ってもらう方法です。知財とまでは言いませんが、本歌取りした開発モデルで、おそらく似たようなことを実施する個人はいても、企業は存在しないと思います（いたら、利益率が高すぎて、急速に成長しているでしょうから）。

利益率を、プロジェクト計画比で見た場合、おそらく10%近い損失が出ている企業が多いのではないでしょうか。利益を数値で見るとプラスになっていても、それは計画損失を差し引いたうえでのプラスなので、無駄な計画損失を出さなければ、倍近い利益改善が見込める企業も多いと思います。

しかも、それが開発プロジェクトの流れが変わらない限り、永続的に効果をもたらすのですから、それなりの価値はあるのではないでしょうか。

３つ目の案は、私自身が起業し、その会社の開発モデルとして１からはじめる…と言う方法です。もちろん、その案もありなのですが、私自身、人脈もなく、１人経営を始めたところで、開発プロジェクトが立ち上がるわけでもありません。企業に社員が増えてきて、この「しくみ」が導入され、功を奏するまでに何年かかるのかわかりません。

一番楽なんでしょうけど、一番先行きが見えない案…と言ったところでしょうか。

来年３月には、今の会社も辞めたいと思っていますし、その先を考えるとどーしたもんか悩むところです。