パッケージか、スクラッチ開発か
こんばんは。
ボーっとしてたら、こんな時間になってました。ついつい楽をしようとする癖がついていて、仕事のことを考えていたのですが、どうしても「最も楽なやり方」ばかりイメージしちゃうんですよね。いやまぁ、本質的な部分を外さない範囲内でってことなんですけど。
さて。
ソフトウェア開発をする際、当たり前ですがその開発活動の全体像を見極め、プロジェクト計画を綿密に練り上げ、事前準備の不備・不足が無いことを確認したうえで着手する…と言うのが、ＩＴ業界…中でもＢ２Ｂでソフトウェアを作り上げる現場においては一般的な常識とされています。
それは、ウォーターフォールでも、アジャイルでも変わりません。
なぜなら、ソフトウェア開発では、先に契約によって予算や期限が設けられてしまう関係上、あらかじめ「何を作るか」「どう作るか」「何を納めるか」「どう検収するか」など、いわゆるゴールが決められてしまうからです。
もちろん、ソフトウェア開発に限らず、どのような業界であっても、ビッグプロジェクトになればなるほど、契約形態云々に関わらず綿密な計画を立案することでしょう。
そうしないと、失敗してから、大金を損失してからじゃ遅いですからね。
「計画」とは、"遠足のしおり"を作るようなものです。私は多くの人に常にそう言って聞かせています。
"遠足のしおり"
というフレーズは、あくまでも知らない人向けにわかりやすいように意訳したものですが、このフレーズの安易さだけを聞いて「この程度の説明なんて」「聞く必要も感じない」と思っている人がいれば、少々浅はかと言わざるを得ません。
"遠足のしおり"に書かれているような精密さを、仕事のプロジェクトに当てはめて同レベルの精度を誇る計画書を作成できるマネージャーと言うのは、実は社会全体を見渡しても、2%に満たないと言われているからです。
一般的にＩＴ企業でみかける「計画」は、実際に行わなければならないKeikakuの"K"…おっと、Planの"P"すらまともにできていない、初歩中の初歩「各知識エリアの目標値を設定する」程度で留めているにすぎません。目標値に到達するための『具体的な実現の仕方、行動の手順』や目標値を維持し続けるための『詳細なルールや手順の設定』などは都度ざっくりと決めてはいるのでしょうけど、計画時に戦略として立案しているプロジェクトなんて、殆ど無いはずです。
計画書（しおり）の神髄は
それを読めば、新人でも、ベテランでも、一様に同じ進め方ができる
ようになっていることにあります。その先に成功するかどうかは関係ありません。定期的な差異確認によって、行動を改めるか、計画を見直すかはあるにしても、基本的に見直されない限り、計画に準じて行動するのがチーム活動の基本です。
ですが、このＩＴ業界では開発の進め方ひとつとっても、未だに統一されていません。本当に計画実現性の高いレベルに到達するには、まだまだ長い時間がかかることでしょう。
ようやく本題
ところで、そんな計画段階では、たとえば
開発するにあたっての言語選定とその具体的根拠
や
開発モデルを採用するにあたって、
そのメリットとデメリットの分析結果と選定理由
なんてものも検討しなければなりません。お客さまがよほど指定しない限りは、必ず「好きだから」「慣れているから」ではなく、その選択をしたことがお客さまにとって有益である理由・根拠が示されなければなりません。
プログラム言語１つ変えただけで、潜在的な顧客要求の実現性がぐんと広がる可能性もありますし、開発モデル１つ変えただけで、リスクヘッジが有効にはたらき、見積金額に大きな差が出ることもしばしばです。
そう言ったことを"なんとなく"・"経験則から"でしか考えられないようでは、お客さまに対して不誠実極まりない対応となってしまい、おそらくは多くの企業の理念にも反する形となってしまうことでしょう。
そのような様々な検討のなかに
①パッケージソフトを導入するか
②フルスクラッチで構築して導入するか
という課題があります。
それぞれのメリット／デメリットの検討もさることながら、それ以前にお客さまの要望に対する適合条件に合致しているかどうかも非常に重要なファクターとなります。これを無視してとにかくパッケージを担ぐ…なんてことをしていると、どんどん顧客の信頼を失い、大きな機会損失を招くことにつながりかねません。
パッケージは、「多く売れること」を前提としていますので、ニッチな要件には対応できず、『社内都合 ＜＜＜ 標準化』とする企業に向いています。
フルスクラッチは、自社独自の都合をどうしても切り離すことができず、『社内都合 ＞＞＞ 標準化』する企業に向いています。
標準化の型にはめるのが、パッケージの強み
業務系システムや基幹系システムの多くに欧米の製品が多いのは、欧米が"自社の特殊性よりも、標準化を最優先とする"文化を持った国だから、という背景があります。
欧米、特にアメリカは転職率が常に20%以上あります。仮に100人の企業だとすると、毎年20人が新しい人に替わっていて定着していない…ということです。1000人の企業では200人が入れ替わっているってことですね。そのため、文化も根付かないなんてよく言いますよね。
社員たちも、就職を「会社に属する」のではなく、「自分のキャリアを活かす」と捉えているため、
「キャリアが活かせない」
「キャリアの成長が止まった」
等を理由により好条件の企業を探すためです。いわゆる、日本の"終身雇用"という概念が存在しません（最近、ちょっと見直されつつある…なんて話もありますが、どうなることやら）。
企業側もそれを十分に理解しているため、長く同じ人がいると思っていないので、属人的な業務のさせ方を絶対にしません。途中で転職されても、すぐに引き継げるように人に依存しないプロセスをカッチリと決めておくようにします。
結果的に、その会社独自のニッチで特殊性の強い文化や風土と言うものは、
どんどん削除されていくことになります。残していると、どこでもやっていける優秀な人材が入社しづらくなるからです。
その流れから、グローバルスタンダートな社風が強くなっていき、業務はすべて業界的にも標準化されたものとなっていきます。だからこそ、汎用的で多く売りたいパッケージが重宝されます。パッケージ製品の仕様は、原則としてグローバルスタンダードな仕様に基づいているからです。
よって、欧米ではパッケージ製品を開発しやすい土壌が構築されていくことになります。
日本企業は独自仕様がお好き
しかし、日本は全くの逆です。
日本は先ほども説明したように、近年まで"終身雇用"という概念がありましたし、未だにそう言った風土が根強く残っている企業も多いため、『社員』が定年まで末永く働き続けるものだ、という先入観から、誰かまかせの属人的な運用によって、その人固有のルールに基づいた
企業独自の文化、企業独自のルール・手順
を切り離すことができません。そうした、社会の変化にマッチングしない人材がどんどんとリストラの憂き目にあっているような現在でさえ、未だにできないでいます。
世の中がどうあれ「でも、うちは○○だから」と言う保守的な考え方が根底にあるのです。それが、もし社会悪だったとしても、よほど外部から叩かれでもしない限り、改善することは今後もずっとないのでしょう。
そうすると、社内に閉じた業務は、その会社特有のものとなっていきます。他社と比較することもありませんし、長く同じ人が残り続けるので、属人的に慣れさせることでパフォーマンスが安定しますし、入社して定年まで居るのであれば、次の引継ぎ等の問題は30年後だから、とりあえずそれまで放置してます。ですから、自社独自仕様、担当社員固有のワガママを言ったところで、さほど困らなかったわけです。
そんな中、もし「フルスクラッチで開発するよりも安価に提供できる！」をうたい文句に、パッケージ製品を推し進めようとしていたＩＴ企業があったら、思い起こしてみてください。一旦その思想で合意を取って開発が始まってみたものの、要件を固めていく過程で、お客さまから
「そうは言っても、○○ができないと困る」
「うちは××っていう業務があって」
と言った、パッケージでは実現できないような仕様や要件が次から次へとあらわれ、挙句の果てに
「じゃあ、△△と●●だけでいいや」
とか言われたり、他部門や全拠点に展開しようとしたけど頓挫したり、あるいはフルスクラッチで作った方が早かった…と言ったことはなかったでしょうか。
最適化を図りたければ、何が最適なのかを考える必要がある
パッケージを導入し、標準化に則したシステムのご提供は、たしかにメリットの大きい選択肢です。本来は、ガラパゴス化された独自仕様なんて破棄すべきです。「他社と差別化」と言えば聞こえはいいですが、他の優秀な人材採用などを行った時に、逆にパフォーマンスが下がる可能性もあります。だからこそ、標準化されたパッケージは、本来オススメしたいものではあります。
それに最初からパッケージ部分の品質が安定していますし、その品質も製造元によって責任をもって保証されています。造りとしても、ある程度最適化も図られていて、最初から性能の心配がないと言う点も大きいことでしょう。おそらくはフルスクラッチ開発よりも大幅に工数を抑えられますし、導入までの期間も短くなります。
その会社にとって、先ほどの記事にあったようないわゆる『ノンコア業務』と呼ばれる、法や規格などによってプロセスが整備されていて、どの企業でも大差がない領域の業務などには、非常に有効です。
しかし、『コア業務』と呼ばれる、その企業独特の仕組みによって同業他社と差別化を図れる業務に対しては、無理に標準化を押し付けるパッケージは致命的です。
この場合は、速やかにスクラッチ開発に移行しないと、無理にでも推し進めれば、お客さまの企業が持つ"強み"を丸ごと潰しかねません。それに、スイッチングコストをかけすぎると、今までの業務に慣れ親しんできたからこそのパフォーマンスを潰し、収益に大ダメージを与えることにもなりかねません。
システムが人間を従えるものであってはならないのです。あくまで人間の業務を支援し、効率的に進めさせてくれるものでなければなりません。
中でも欧米のパッケージを国内で利用する場合は、慎重に顧客の要求仕様を紐解いていく必要があるのです。
必要となってくるのはアーキテクトの存在
最近聞かなくなりましたが、ちょっと前までは、「SOA」と言う考え方がありました。SOAとは、サービス指向アーキテクチャ (Service-Oriented Architecture)の略で、業務上の一処理に相当するソフトウェアの機能をサービスと見立て、そのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指します。
１つのソフトウェアですべての業務を統合することを『全体統合』と呼ぶとすると、複数のシステムやソフトウェアを最適化するためにあえて分散し、
１つ１つのサービスと見立て連携させるのは『全体最適』と呼べるでしょう。
パッケージでできるところはパッケージにすることで、中長期的に「害」となるような独自仕様が組み込まれなくてもいいようにし、自社の強みを最大限活かせるような特殊性の高いところはスクラッチ開発によって実現するのが最も理想的なのです。
こうした検討によって、お客さまの要望全てを叶えるような取り組みを考える人材を、
アーキテクト（またはＩＴアーキテクト）
と言います。アーキテクトにも種類は様々で、
ハードウェアアーキテクト
ネットワークアーキテクト
ソフトウェアアーキテクト
など多種多様ですが、ＩＴアーキテクトは、この中ではソフトウェアアーキテクトに近いかあるいは同義と見ることができます。ＩＴアーキテクトのメインターゲットとなる「ソフトウェア・アーキテクチャ」の定義は
対象となるソフトウェアシステムの設計課題を反映した
ソフトウェアの構造を表現したもの
です。
「全体的な設計課題を反映したソフトウェアの構造を表現」するのであれば、全体的な設計そのものになりますが、もう少し具体的に表現してみると次のようなレイヤ構造となります。
これは、さまざまな視点からソフトウェア・アーキテクチャという構造を見たものです。上位方向は概念的、下位方向には具体的なソフトウェアの構造を表現するという意味を示しています。
このすべてを守備範囲とする人材が、ＩＴアーキテクトと呼ばれています。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。