見出し画像

basal.って何してる会社?

こんにちは。Co-Liftのミドリです。

Co-Liftって何してる会社?』では、Co-Liftのコンサルティングサービスについて書きました。今回はもう一つの柱であるシステム開発サービスについて、知っていただければと思います。

2. ソフトウェア開発サービス

前回も軽く触れましたが、システム開発サービスは100%子会社の株式会社Basal(ベイサルと読みます)と協働して行っています。

画像5

「Basal」は”基本的な”とか”根本的な”という意味で、現状の技術やトレンドといった表層的な模倣ではなく、コンピュータ・サイエンスへの根本的な原理原則への深い理解に基づいてソフトウェアを開発していくという思いを込めています。

技術は日進月歩で進化し続けており、その技術進化は非連続的です。現在の技術や流行している技術の表層的なスキルやノウハウを追いかけるだけでは、その技術が廃れてしまった時に使いものにならなくなります。そうならないために、Basalでは技術の基底にある原理原則を体系的に理解することに重きを置いています。

画像7

我々のお客様が、こうした原理・原則に直接的に触れることはまずありませんが、システム開発を行う際には、必ず原理・原則に基づいた議論が社内で行われてから着手しています。

カンタに「具体例を教えてくれ」と言ったら。

画像8

原理原則的なそもそも論で社内議論が白熱しがちで面倒な時も(多々)ありますが、これがお客様に提供する我々のバリューの源泉なので、欠かせないものです。


全員フルスタック・エンジニア

これはよく驚かれることなのですが、Basalに所属するエンジニアは全員フルスタック・エンジニアです。「よくそこまでハイレベルな人材を集められますね」「どうやって採用しているのですか?」とお褒めの言葉を頂くこともあります。

フルスタックエンジニアとは?
設計、サーバサイド(バックエンド)の開発、フロントエンドの開発(WEB、ネイティブアプリ)、IaaS上でのインフラ構築、システム運用等、ソフトウェア開発で必要な工程をEnd-to-Endで1人で遂行出来るエンジニア

マーケターで例えるならば、オンライン広告にもオフライン広告にも精通し、戦略立案から運用までをこなし、さらにはオウンドメディア構築、SNS戦略立案、CRM、SEOまで出来る人って感じでしょうか。

家庭で例えるならば、洗濯も掃除も買い出しも料理も、子供のオムツ替えも風呂上がりのスキンケアも寝かしつけもできる人材といったところでしょうか。

ん・・・?世の中の主婦・主夫ってすごくない・・・?
もっと称賛されても良くない?


さて、本題に戻りましょう。

先程の「どうやって採用しているの?」という質問の答えですが、
弊社の場合はというと、(もう流れでお分かりですね)

スーパーCTO Adamが探してきてくれます。

画像3

Adam
ティーンエイジャーの頃にプログラミングを始める。
その頃から人間よりもコンピュータとの会話量の方が多く、スキルを得る代わりに人として大事な何かを失う(本人談)。
Phillip MorrisとGeneral Motorsなどでキャリアを積んだのちに楽天に参画。そこでカンタやサダカネと出会う。好きな色は白。


Adamは、実務レベルでのエンジニアリングは勿論のこと、何よりも”美しい”システムアーキテクチャを描く才能が突出しています。


美しいシステムアーキテクチャって?

「”美しい”って何ぞ?」と思われる方もいるでしょう。私がそうでした。

Adam本人に聞いたところ。

画像8

Adam「端的に言うと、最高のシステムは柔軟性があり、コードを変更するのではなく、コードを追加することで新しい状況に対応することができます。副作用の心配も最小限に抑えられています。また、理解しやすく、推論しやすいのです。」

ミドリ「なるほど!(やっべえわっかんねえ)」

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

ミドリ「教えてカンタ!」

カンタ「要は、変化への適応力が高いってことだよね」

画像9

ミドリ「・・・な・・・るほど(ぐぬぬぬ)」

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

埒があかないので、独自に例を考えてみることにしました。

部屋のレイアウトで考えるとわかりやすいかもしれません。


”美しくない”とは

分かりますでしょうか。
散らかるおもちゃ。存在感がありながらも全く調和することのない長座布団。ソファに積まれた前日の洗濯物。片付けるのが面倒になって行き場を失ったおしり拭きのケース。中途半端に開けられたカーテン。子持ち家庭が首がもげるほど頷くであろうタイルマットの存在感。

画像4

これぞ”美しくない”です。

色の統一感がない。物の居場所が決まっていないから、どこに何があるのか分からない。継ぎ足しに継ぎ足しを重ねることで、最初は片付けられていた部屋もこのようになっていきます。さらに、真ん中に鎮座するモンスターのおかげで、一瞬で部屋は壊滅状態になります。


”美しい”とは

システム・アーキテクチャ的にいう”美しい”とは、視覚的な美しさ(シンプルさ、統一感)というよりは、変化への適応力が高いということではないかと考えています。

またお部屋で例えるならば、「ライフステージに合わせて変更しやすいお部屋」がイメージに近いでしょうか。

結婚した時、赤ちゃんが生まれた時、子供が成長した時、再び夫婦だけになる時。

いずれも必要となる家具やレイアウトは異なると思います。過度に、一時のライフステージに合わせすぎた住まいづくりは、時の経過とともに住みづらくなることも。

子供が生まれて、ちょっと気合い入れて、備え付けの滑り台をつけてみたけど、子供が大きくなると無用の産物になる、、、みたいな。


システム・アーキテクチャも同様です。

ビジネスのステージの変化や外部環境の変化に伴って、求められる機能や性能は絶えず変化し続けます。ある時点でのビジネスの要件に適応し過ぎたシステムを構築してしまうと、こういった変化に対してとても脆弱になってしまいます。

システム開発にBiz側として携わったことがあると、ちょっとした改修の依頼をしたつもりなのにコスト・期間ともに膨大な見積もりが返ってきたという経験はないでしょうか。

あるいは、見積もりすら出てこないで、「そもそも無理!」と完全拒絶されることもあるかもしれません。

これは、Bizの要件が悪いわけでも、Devが仕事したくないわけでもありません。拡張性が低く、理解がしづらい複雑なシステムやデータベースが組まれていると、往々にして起こりえる事態なのです。


”2+2”を計算するシステムが欲しいという要望に、どう応えるべきか

”美しい”アーキテクチャについて、少し極端な例を示してみましょう。

クライアント(もしくは自社のBizサイド)から、
「2+2を計算するシステムを作って欲しい」と言われたとしましょう。

画像8

以下のどちらが美しいシステムと言えるでしょうか。

①  2+2を計算するシステム
② 2つの数字の和を計算するシステム

クライアントの要件に完璧に沿っていて、簡単に素早く実装出来るのは①でしょう。

では、クライアントが突然「やはり2+2ではなく、3+2も計算したい」と言ってきたらどうなるでしょうか。もしくは「2×3を計算したい」と言われたら?

①で作り込んでしまった場合、
「3+2の計算」をするためには、「3+2」のシステムを新しく構築するか、「2+2」のシステムのコードをイチから書き直す必要があります。

しかし、②で作っておけば、コードを変更しなくても「3+2」が計算できますし、「2×3」も2を3回足すというように②を再利用することでクイックにシステムを拡張することが可能になります。

このように、将来の変更にたいしてしなやかに対応出来るように作るということが、新規事業開発のような変化し続けることを前提としたシステム開発ではとても重要になってきます。

「2+2を計算するシステムを作る」ことは現実のプロジェクトではありませんが、クライアントの要望に対して①のようなシステム作りをしているケースは、本当に数多く散見されますし、これは「作る側」だけの問題ではなく、様々な制約があるとしても「依頼する側」の問題でもあります。


現時点で考えられうる最高に美しいシステム・アーキテクチャを

①のような悲劇を生まないためには、クライアントやBizの真の要求が何であるかを正しく理解し、将来的な拡張も視野に入れた上で、システム開発を行う必要があります。

Co-Liftおよびbasalでは、クライアントから「Aの仕様で開発して欲しい」と要件が出た場合でも、将来的な拡張性や保守性を考えたらBの方が良いと判断できる場合は、きちんとその旨をご説明することにしています。

短期的な期間や工数、合意形成のためのコミュニケーション・コストを考えると、当然ながら、クライアントの言う通りのまま作り上げた方が合理的に見えます。(実際こうした説得には多くの時間やコミュニケーション上のコンフリクトを生みます)

しかし、それではクライアントの本質的な価値を創造することにはなりません。一度作って「はい終わり」とせずに、中長期的な開発パートナーとして、プロダクトの生み出す価値に責任を持って取り組んでいきたいと考えているからです。

画像2

ちなみにBasalのエンジニアは Non-Japaneseが多いですが、クライアントが日本語の場合は日本語対応です。ご安心ください。


次回予告『デジタルプロダクト開発に終わりはあるのか?』

今回は、Adamを中心としたBasalエンジニアの特徴について、お話しいたしました。次回も、システム開発に関連した話をしたいと思います。

今回もお読みいただきまして、どうもありがとうございました!


Co-Lift/basalへのお問い合わせはこちら


いいなと思ったら応援しよう!