テクノロジーから価値を生む と テクノロジーを消費する の違い
消費するだけになっていないだろうか?
世に存在する全てのアプリケーションは、誰かが投資をしているわけで、投資をする価値があると判断をされて構築をされている。
そのアプリケーションの構築を担う立場にある方々は、それが価値を生むために日々悩み苦しんでいると思う。そして、アプリケーションの実現にはテクノロジーの存在が不可欠である。
アプリケーションの構築を担っているのに、それと違う行動を結果的にとっているのでは? と思う場面が多く存在をしている。
- 値段しか見ない方 --- その方は、システムの多様な価値を判断できないのであろう。業務やユーザーの操作時間などを大幅に改善することの間接費用。不確定な将来に必要になるであろう機能の価値の判断などが一切できない。すぐ◎×を始める。
- モノの導入が全ての方 --- その方は、企業活動を支える仕組みは、誰かが既に作ってくれているはずで、それを買う事だけに価値を置いているのかもしれない。自社に適用させるカスタマイズは、あまり考慮しない。その結果生まれるのが、パッケージのカスタマイズ費用が巨額になっているプロジェクトとなる。そして同じく◎×を始める。
- 開発ツールやライブラリーを使うだけの方 --- 前述の延長線上にある。ソフトウェアエンジニアという肩書をもらっている方々でも、こうなってしまうっているかもしれない。既存のツール・フレームワークなどの利用・消費しかしていない。これはメーカーにいるとそうなりがち。画面で作業のできる範囲を超えだすと、「難しい」という反応が見えてくる。サンプルコードのビジネスへの適用ができない。これも同じく◎×を始める。
いずれもテクノロジーの消費者といえると思う。使う事に特化し、その上でのアプリケーション開発にあまり重きを置かない。
アプリケーション開発の進化
テクノロジーはパッケージ化・Cloud化された製品・サービスを指すだけではなく、それらを利用して開発されるアプリケーションそのものの一部分でもある。結果として、プログラミング言語のフレームワークも常に進化を続けている。
アプリケーションの肝は画面とデータといってもいいと思う。その画面とデータがある程度 (ここ大事) 決められるのであれば、ゼロからでも開発して作っていく時間は、この数年で劇的に向上している。
以下、必ずしもそれがベストという訳ではなく、あくまで例である。
PowerApp という主に既存のデータをもとに、画面を構築できるサービスもある。画像認識などの機械学習の機能もついている。プログラミング言語ではないが、これも一種のフレームワークといえる。
.NET を例にとると、PowerAppと同じように既存のデータなどをもとに、画面を構築できるフレームワークもある。MVCフレームワークがその代表といえる。データはモデルと表現され、そのモデルは、DBのテーブルなどをベースに作成されることもある。
コードレス という言葉も出始めている。例えば、Azure には Logic App というプログラミング言語はあまり扱わずに、アプリケーションのロジック・ワークフローだけ構築ができるサービスがある。
Java でも Spring Framework という似たようなフレームワークもある。
Web開発はデバイス側の高機能化に伴い、SPA (Single Page Application) が主流となりつつあり、MVC的なフレームワークは、API構築に留まるケースも増えてきている。
テクノロジーの消費者は、これらを使うだけになりがち。そのフレームワークの持っているツール群 (スキャフォールディング) などのできる範囲でしか、アプリケーションが組めない。画面上の操作と、定型的なコマンドでしか作業ができない。その本質を理解した上でのビジネス課題の最適な解決法を考えない事が多い。
テクノロジーから価値を生みだす場合は、その枠内に留まらないで考える事ができる。
例えば、プログラミング言語のフレームワークでは、データベースへのアクセスは隠ぺいされている事が多い。1 Class = 1 Tableの様に機械的にマッピングがされる。場合によっては、直接SQLステートメントを発行した方が良い場合もある。
テクノロジーの消費者になってしまうと、どうなるか?
例えば1画面に表示するデータが複数のテーブルから取得する必要があったとする。最適化したSQL文を書けば必要最小限のDBアクセスで済むものが、結果として何度もデータベースにアクセスをする事になる。実際に1つのAPIから10以上のDBへのクエリ発行をしているケースを何度も見ている。
また、DBの設計も重要となる。ER図からDBのテーブルを自動生成するツールも良くできている。しかし、効率的なクエリを書けば済むものを、大量の中間テーブルを大量に作ってしまうケースも何度も見ている。
テクノロジーから価値を生みだす場合は、フレームワークの出来る事を理解し、フレームワークの拡張性を検討するか、フレームワークを使わない選択肢を試行錯誤する。なぜなら、テクノロジーを使う事が目的ではないからである。
テクノロジーから価値を生みだすために
そのテクノロジーの生み出された背景、その概念を実はしっかりと理解する事が大事になる。この際、歴史的な経緯は理解を早めてくれる。例えば、.NET というテクノロジーは、その前のMicrosoftのコアテクノロジーであったCOMの反省から生み出されたものである。.NET Coreは、.NETの反省から生み出されたものである。
そして、その概念は、サンプルコードからは読み取れない。なぜなら、コードは実行するものであって、Why / What の説明はしてくれない。であれば、設計・開発した人の話は大変貴重であることがわかる。
そして、そのテクノロジー自身をとにかく使い倒してみる事。そのために時間をしっかりと確保する事が大事になる。
Share 時代の行動として、多くのテクノロジーを生み出している立場の方々は、フィードバックに重きを置いている。つまり、一緒に作っていく姿勢が強い。フィードバックには良し悪し双方が大事となる。
テクノロジーの消費者は、改善のための具体的な手段について考える事はあまりしない。言い方が悪いが、漠然とした文句しかいわない。
ここで、是非具体的にどうすれば良くなるのか?そして、それはなぜなのかを、テクノロジーを生んでいる立場の方々と一緒に考える場を利用してもらいたい。
- GitHub への Issue
- メーカーとの建設的なやり取り
など
これは、ユーザーではなく、パートナーとして一緒にモノを作り、世に価値を生みだしていくサイクルを作り出す可能性が高い。
私は、社内も含めて世に何らかの価値を生みだすためには、モノづくりの心が大事なのではないかと思う。そのためには、テクノロジーから価値を生みだす事に時間を使いたい。
日本のモノづくりの魂の例。これが、Agileやリーンの魂になっている事は忘れてはいけない。
この記事が気に入ったらサポートをしてみませんか？