【基本のき】ロックインが怖い
更新日: 2022年3月28日
「システムの一部または全部を別の ○○○ に変えることができないため、困ったことになる状態」を指します。
例えば……
という懸念があるなら、それは避けたいなぁと考えるのが普通です。
しかし過剰に不安視すると、何もかも手作りでないと安心できないという内製原理主義？になってしまい、今度は時間もお金もかかってしまいます。
そして、実はロックイン状態というのは、 問題が発生しない限りは楽ちん なのです！
ということで、 バランスの良いロックイン状態 というものがあればいいのかもしれません。
考えてみると、OSやデータベース、クラウド環境の選択も、すでに特定の何かにロックインされているといえます。にもかかわらず、これが問題になることはありません。
これらの技術はネット上で多くのノウハウを検索し、無償で学ぶことができます。
ではオープンソースのソフトウェアはどうでしょうか？
ロックイン問題の本質がだんだんわかってきました。自分のレベルで理解でき、修正できる範囲というものがあって、それを超える部分は誰かにお願いしないといけない。ということは自分が手を出せる範囲はどこか、という見極めが大切になりそうです。
どうひっくり返しても自分にはできないし、そもそもやるべきではない分野は自分以外の誰かにお願いしても良い ということです。
具体的にはインフラ部分、つまりアプリケーションを構成する基盤（ハードウェア、ネットワーク構成、OSやデータベース）です。
つまり「コモディティ化されていない」分野で、かつ「自社の優位性」に直結するもの が、もっともロックインされてはいけないものです。
それはずばり「自社固有の業務アプリケーション」です。
この視点であらためてロックインの問題を考えてみましょう。
自社の業務アプリケーションの中身がブラックボックスで、開発も特定のベンダー（開発会社）しかできない状態だったとします。
実は多くの場合、こうしたケースでは開発会社そのものではなく、そこで働いている特定の人（ここでは C さんと呼びます）にロックインされています。
業務アプリケーションより下の部分、いわゆるコモディティ化された技術で構成された部分は、別の技術者が代替することができます。
あなたにとって譲れないもの、それはその業務アプリケーションの中身、つまり「設計書と、その設計書にそって作られたプログラムコード」です。
ところで、これまでの開発ツールは設計書に沿ってプログラムコードを書くことを支援するものでした。
しかし、多くのノーコード・ローコード開発ツールは「設計書」だけを扱います。ツールがその設計書を解釈して、プログラムコードを補うのです。
そしてノーコード・ローコード開発ツールが普及するということは、これらが特別な存在ではなく、ハードウェアやOSのようにコモディティ化されることになります。これが「誰でも開発できる時代」を支える基盤になっていきます。
では、これらのツールがコモディディ化されていく、という流れの中で、ロックインを捉えてみると……
プログラムコードについては考慮する必要がなくなります。
ということで、最初のロックイン問題は次のように変わりました。
「そのツールは、私が理解できる範囲で、業務要件を満たす設計書を書けるようになっているか。」
ここで大切なことをお伝えします。
具体的には、設計書の書き方はツールごとにまったく違います。
まとめます。
ところが設計書に書ける範囲や、書き方そのものはツールによってバラバラです。そして設計書は、ツール間で引っ越すことができません。
つまりその設計書がどこまで自分にとってわかりやすいか、そして変な制約がないか、表現できる限界はどこかを学ぶことが大切なのです。
ツールによって、設計書というものの考え方（思想）が違います。「ロックイン」とは
適当にやっておいて、というだけで済むなら、ハッピーです。
ある程度はお任せで楽できるのですが、ここだけはロックインされないように自分で汗をかきます、ということです。
しかし、そんなことは本当に可能なのでしょうか？
ロックインが問題にならないケース
また、 その技術を扱えるエンジニア層が厚い ということも重要です。
つまり、汎用性がある（公開されている情報が多い）技術を使えばロックインされにくい ということです。
はい、これならロックインとは無縁でしょう。ただし何かあったときに、そのソースコードを読んで自分で修正できるか、という問題はあります。
オープンソースであっても、他人がつくったソフトウェアの中身を理解するのは、それなりに時間がかかるものです。
これらは自社特注である必要はありません。
他社が使っている技術を真似たとしても「自社の優位性」に影響のない、「コモディティ化された」分野だからです。
ロックインされてはいけないもの
……はい、完全にロックインされていますね。
ただ、そうであってもその開発会社と信頼関係があって、リーズナブルな価格で開発や保守を行っているなら問題はないのでは？と思うかもしれません。
その C さんが退職したり、何らかの事情で業務に関わることができなくなったときに問題が表面化します。
このあとの保守が継続できなくなれば、その業務アプリケーションは詰み、です。
競争も働くため、条件のよいところを選ぶこともできるでしょう。しかし業務アプリケーション本体の引き継ぎは困難を極めます。
つまりロックインが問題になるのは、業務アプリケーションの中身がブラックボックス化されているとき です。
コモディティ化された開発ツール
残るのは「設計書」です。ここをしっかりと押さえていれば、ブラックボックスを回避できる、つまりロックインからサヨナラできます！
それは設計書の「書き方」はコモディティ化されていない ということです。
あるツールXで書いた設計書を、ツールYで実行させることはできません。プログラム言語の種類が異なれば書き方が異なるように、設計書の書き方もまた多種多様なのです。
まとめ
ロックインされてはならないのは業務アプリケーションの「設計書」にあたる部分 です。
ツールを選ぶこととは、あなたがもっとも共感できる設計書の書き方を選ぶこと です。是非ともその視点で、ツールを選んでください。