技術ブログの立ち上げにあたり ～ラキール/LaKeel DXの目指すもの～
はじめに
はじめまして。株式会社ラキールで製品開発の管掌をしている川上です。
私は、大学を卒業後、IT業界にずっと身を置いてきたじき55歳になる男です。学年的には福山雅治の1つ上になります。（桑田・清原世代とも言いますが･･･）
その殆どを所謂SIなどの企業系システム開発に従事し、20代はプログラマーを、30代からプロジェクトマネージャを、40代はマネジメントと経験し、今に至ります。
こう書くと、ステレオタイプの社会人の様ですが、社会人２年目にいきなりバブルが弾けて一生続くと思っていたメインフレームの仕事がなくなったり、初めての参画案件の大トラブルで、週末も含めて毎日片道2時間近くかけて現場に通いつめたり（自分達の担当以外だったので、当時は、なんで俺が！？と思いながらでした）、飛行機乗るのも初めてで英会話もできないのに3か月程度Bostonでソフトウェアの日本語化したり、中国子会社の立ち上げでしばらく北京に行ってみたり、あるお客様の基幹システムのリプレイス開発のため2年程度平日を会社で生活していたり、その間に家に空き巣が入りプレイ中のドラクエのデータが保存されたメモリごとゲーム筐体を盗まれたり、と結構色々と経験させてもらった人生を送ってきました。
今回技術ブログを始めるにあたり、ラキールがなぜクラウドを選択して、LaKeel DX という製品やサービスの開発を始めたのかをお伝えしたいと思います。また、その取り組みを通じて、何を目指そうとしているのかも併せてお伝えできればと思います。
是非とも、ラキール並びに、LaKeel DX という製品に興味を持っていただけると嬉しいです。
※ 以下、あくまで私の実体験を元にしていますので、活動の場の異なる方に別のご意見がある点は承知しております。ご了承下さい。
クラウドに取り組むまでの経緯・背景
まず、現在の取組みを実施するに至るきっかけや背景について書きたいと思います。その為に、これまでのIT業界の変遷について、私なりに思う処を中心に書いていきます。
背景１： 利用技術の変遷
まず、挙げられるのは、技術の移り変わりや新技術の登場サイクルが、年々に短くなっている点です。その一方、過去のものも残り続けており、新旧技術（それを採用したシステム）が常に混在している状態かと思います。
私が生まれた1960年代は、所謂IT業（情報サービス産業）が誕生し、メインフレームを使った計算サービスがビジネス化され、社会人になるまでの20年間は、メインフレームを使った基幹システムの構築（ソフトウェア開発）が主流になった時代と思います。
そして、私が社会人になった80年代後半から90年代初頭に、所謂バブル経済がはじけ、コストダウンのためにダウンサイジングと称して UNIX（今の Linux の原型）を使ったシステム開発が主流となった印象です。
同時に、90年には Winodws 3.1 が、その後 Windows 95、Windows NT とリリースされる中で Windows PC が B2B にも使われ始め、クライアント・サーバ型のシステム／リッチクライアント・アプリケーションが主流になっていったかと記憶しています。
90年代後半からは、インターネットが普及し、2000年代からブラウザをクライアントとして利用するシン・クライアント（新ではなく”Thin”です）が主流になり、CGI や Java、Web サーバやアプリケーション・サーバをバックエンドにもつアーキテクチャが登場しています。
そして、2010年からスマホが登場し、いよいよ皆さんにもなじみ深い GAFA（GAFAM）の時代になっています。更に、現在では、AI や Web3 なども登場、といった状況かと認識しています。
背景２： 日本のIT市場の特性
もう１点あるのが、日本のIT市場の特性というか特異性です。
それは、世界ではパッケージ中心のシステム導入が多いのに対して、日本ではSI（受託開発）が中心でシステムが構築・導入されるケースが多い点です。
また、2017時点のデータですが、IT人材の約7割がユーザ企業に所属しているアメリカに対して、日本では7割 がITベンダー企業に所属しており、真逆の構造になっているそうです。
つまり、これまで海外のユーザ企業は、パッケージを利用しつつ、自力で IT 活用に注力し、自社の競争力の強化や差別化を図ってきたのに対して、日本のユーザ企業は自社で使うシステムの殆どを外部企業に依存している状態だった、と言えるのではないでしょうか。
それが故に、日本では、効果の判り易い業務効率化やコスト削減に主眼を置いた IT 投資が中心となり、業務を深く理解しないと実現の難しい競争力強化を目的とした IT 投資が難しかった背景があったのではないかと、想像します。
といった環境で長年システム開発に携わってきた私は、ある時から以下のような危機感を感じ始めました。
クラウドに取り組むきっかけとなった危機感
危機感１： 日本の社会環境
まず、日本は1997年以降の少子高齢化傾向に加え、人口も減少傾向にあるのは周知の事実で、皆さんもご存じかと思います。
これに加え昨今では、DX投資や2025年の崖の解消などもあり、IT業界は元より、どの業界でも人材を奪い合う状況になっています。
かくいう私も何度か転職をしてきていますので、転職自体をどうこう言うつもりはありませんが、人口の件を踏まえると、人材の獲得活動が激化するのは想像に難くないですよね。
危機感２： 求められるものの多さ
昔はメインフレームという１つの環境で足りていたものが、ネットワークやスマートフォンに代表される新たな環境・新技術が生まれ、知らないといけない事が年々増えています。
それに加え、短納期化や低予算化など、仕事をする条件としては、年々厳しくなっている実感があります。
危機感３： 繰り返されるシステムリプレイス
かなりの時間と手間、大変な思いをして作ったシステムですが、それが支える顧客企業を取り巻くビジネス環境も日々変化していますので、作ってすぐに機能拡張や機能変更が発生したり、5年～10年前後でその時の最新技術でシステムをリプレイスする、といった経験をお持ちの業界の方も多いかと思います。
また、大変な思いをするのか！！と思う一方、このお金があればユーザ企業にとっても別の取り組みができたのではないか、と感じる様になりました。
危機感４： なくならない各種トラブル
私の若いころは、『動かないコンピュータ』という日経の記事をみては、みんな大変だなぁなどと、どこか傍観している自分がいましたが、年末のATMトラブルとか、システム統合の失敗とか、システム導入に関する訴訟とか、今ではすっかり他人事ではなくなりました。
システム開発・導入・運用・保守といった全てのタスクは、基本ハンドメイドですし、その規模が大きくなればなるほど、やることも・関係者も増えるので、トラブルの発生するリスクも指数関数的に増加します。
なので、今の構造のまま仕事をしている限り、多分トラブル事は無くならない気がします。
危機感５： 人月商売からの脱却
昨今では、下請け構造の問題が指摘されたりもしていますが、個人的には上記のような危機感により、これまでの人の数に依ったビジネスモデルや仕事の進め方に限界を強く感じる今日この頃です。
一方で、SI 型のシステム開発はなくならないと考えています。SI 型と書くと誤解を招く可能性もありますので、正確に書くと・・・パッケージで全て賄える訳ではないですし、その企業の武器である独自領域については、寧ろパッケージとは相容れない場合が殆どだと思います。従い、独自の作りこみは必ず必要になる、という意味です。
それの実現に、社外のリソースを使った形がSI型ですし、近年は社内リソースを使う内製化が叫ばれていますね。
ですので、これら（人の数に依存しないようにする点と人が対応せざるを得ない点）の両立をどう実現するか？を考える必要があります。
ということで、するべきことは多いのに、それをする人が減っている。なおかつ、トラブル対応に伴い疲弊しやすい環境にある、という人に優しくない環境を自分達で作り出してはいないか。
モノ作りをしたくてこの業界で働くことを選択した自分ですが、苦労して作った割に、手段を変えて似たようなものを作り直すという行為を繰り返している気がして、創造性をあまり感じなくなった。
等々、いつしか危機感や閉塞感の様なものを感じるようになる一方で、どうせ大変な思いをするなら、後につながるような取り組みはできないだろうか？といった事を考える様になりました。
課題解決とLaKeel DX
という事で、自分なりに各課題への対策を考えてみました。
何事もそうだと思いますが、課題が発生した時にそれを解決するには、極力シンプルに考えた方が良いかと思っていますので、各対策も結構シンプルです。
少子高齢化・人の流動性に対する対策
私一人が頑張れば人口が増えるわけでもありません。何よりもパートナーが必要ですし、仮にそれができても社会が変わるのは20年も先のお話ですし。
この課題は、つまり労働力が減るという事なので、少ない労働力（工数）で仕事ができる状態にすれば良いわけです。また、関係する人が少なくなると、トラブルの発生リスクの低減にもつながるというメリットもあります。
で、少ない工数で、これまでやってきたことに対応する方法なのですが．．．後述の『トラブルへの対策』でも言及していますが、それは不可能です。
なので、ちょっとルールというか視点を変えて、すべき事を減らすことができないか？という方向で考えました。
正確には、ハンドメイドする部分を削減する、という感じでしょうか。
トラブルへの対策
トラブルには多種多様のモノがあるので、一概には言えませんが、Q/C/Dの内、C/Dは『短納期化・低予算化への対策』でも触れていますので、ここではQ（品質）について言及します。
品質を上げるにはどうすれば良いでしょう？
品質の高い優秀なメンバーを揃えれば品質はあがるでしょうし、結果品質リスクは下がると思います。ですが、人がやる事ですので、絶対的な品質が確保できる保証はありませんし、そもそも優秀な人だけでプロジェクト体制を組閣できないケースが多いのが実態ではないでしょうか。（あ、ラキールには優秀が豊富に揃ってますよ！）
従い、この場合、人に換わり品質の高い何か（モノ）で補う、人が介在する割合を減らす、という対策になろうかと思います。
新技術への対策＆繰り返しへの対策
これらの課題は、結果的に同じ課題として認識しています。
まず新技術ですが、次々と新しい技術が出てくる点に対しては、キャッチアップするのに大変な思いを抱く方も一定数いると思いますが、この業界にいる人であれば基本的にはワクワクする方が沢山いらっしゃると思います。
で、普通は新しい技術の方が便利だったり、優れている場合が殆どですので、それをシステムに取り込み、これまでできなかったことを実現したいと考える事自体は普通のことですよね。皆さんも、実生活で新製品が出たら、これまで使っていたものを買い替えたり、ソフトウェアならアップデートしますよね。
これまでは、システムを大きな一つの塊として（モノリシック構造で）構築していたので、新技術を導入する場合にも、刷新するにも all or nothing 的なアプローチをしてきた訳ですが、今後はそれが必要な部分のみに限定して開発し更新していくというアプローチを採る、という対策になるかと思います。
そうすることで、同じことの繰り返しにも終止符が打たれるのではないかと。
今風にいうと、SDGs（持続可能な取り組み／開発目標）というやつでしょうか。
短納期化への対策＆低予算化への対策
これらの課題は、本質的には同じ課題と捉えています。
作業時間を短縮するには個人個人のパフォーマンスを上げれば良い訳ですが、そう簡単には上がりませんし、人には限界があるので、本質的な解決を図るにも限界があります。従い、すべき量を減らすという対策になるかと思います。
また、低予算化を実現するには、コストを占める大部分である人（人件費）や人が動く部分を減らせば良いと思いますので、ここでもすべき量を減らすという対策になろうかと思います。
という事で、私の殆どの危機感への対策は人がすべき量を減らすということに帰結しています。それに加え『必要な部分だけに限定して』実装を切り替えていく仕組みの採用という感じでしょうか。
では、それをどうやればよいだろう、という事を悶々と考えている頃、ちょうど新しい取り組みをしていこう！という動きがあり、本当にたまたまですが、クラウドを見る様になり、そこでマイクロサービス技術に出会いました。
それにより、ソフトウェアの部品化への取り組みを本格的に推進する様になり、ソフトウェア部品を組合わせてシステムを構築するためのプラットフォームとして LaKeel DX という製品を作るに至った、という流れになります。
ソフトウェアの部品化
LaKeel DX で行っている部品化はマイクロサービス技術をベースとしており、画面側はマイクロフロントエンドアーキテクチャを採用し画面部品化し、ビジネスロジック側をサービス部品化し、それぞれの組合せでシステムを構築する事を実現しています。
参考までに、LaKee DXのイメージ図を添付しておきます。
部品が蓄積されればされるほど、ハンドメイドで作る量は削減されますし、実績のある部品を使う事で品質リスクの低減を図ることも可能になります。
また、要件や機能の追加・変更をする際も、不足している部品の作成／部品の入れ替え／部品の拡張と影響範囲を限定しつつ柔軟な対応が可能になりますし、Web APIさえあれば、新技術を取り込むことも可能になりますので、作り直しの必要性も大幅に低減することができるはずです。
その結果として、大きなシステムを作っていた状態から小さい部品を作る状態に変化していけば、その分 IT 投資効率も向上しますし、システム構築時のトラブルリスクも少なるはずです。
勿論、部品間での通信が多くなることで発生する障害、これまで全体で1つのDBを共有していたものが分割されることでトランザクションの考え方を見直す必要があったり、結果整合性など考え方を変える部分等々、技術的な難易度が高くなる部分もあります。
ですが、そういった事は、これまで新技術が登場するたびに繰り返して進歩してきていますし、まぁなんとかなるかと。（壁を突破するときはしんどいですが。笑）
なぜクラウドなのか？具体的にどのような取り組みをしているのか？どんな技術を採用しているのか？何が大変なのか？など、今後このブログ内でプロダクト開発本部のメンバーに紹介して貰いますので、是非、ご期待ください！
さいごに
ラキール及び LaKeel DX の取組みは、ソフトウェア開発における変革（恰好よく、今風に表現すると、ソフトウェア開発の DX ）の実現を目指しています。
これらの取組みは、当初、ラキール自身が提供するソフトウェア開発で利用する想定でしたが、ソフトウェアを提供する場合だけにとどまらず、利用する企業の側にこそメリットが多くあるのではないか、と考えて外販をするに至っています。
ソフトウェアの部品化については、否定的な意見をお持ちの方も多いと思います。
ですが、今やっている事が本当にベストなのかを追求し、常に変化していく姿勢は、ラキールの DNA でもありますし、長年この業界に身を置く立場として、手段たる技術だけでなく、やり方・考え方にもどんどん変革・改善を図るべきだと考えています。（図るべき時期に来ていると考えています。）
それがソフトウェアの部品化により、実現できる可能性があると信じています。
また、そうした日々の積み重ねが、これまでとは違った未来を作ることにつながると信じて、皆さんと共に仕事をしていければ幸せだと思います。
まぁ、色々と大変な事も多いですし、どうせ苦労するなら、次につながる大変さにしたいですよね！！！皆さん