システム設計には、自分の人生を生き抜くヒントが詰まっている。

はじめに

メーカでエンジニアとして働く私が、そのことに気づいたのは約５年前。仕事で成果が出せず、疲弊していたときのことでした。

私は会社に入社してから約10年間、システム開発のエンジニアとして、大規模なコンピュータシステムの開発に携わってきました。システム開発に関する業務を一通り経験し、リーダーとしてそれなりに成果を上げることができていました。

しかし、10年目を過ぎた頃、大きな壁にぶち当たります。

上司から新製品の開発を任され「やるぞ！」と意気込んだものの、この開発では自分が積み上げてきたシステム設計の経験は全く通用しませんでした。なんとか上司の期待に応えようと、寝る時間、休日の時間を削って働きました。

しかし、何をやってもうまくいきません。気持ちだけが空回して失敗ばかり。考えられないような凡ミスを連発。上司からは毎日のように叱責を受け、私は職場でどんどん孤立し干されるようになりました。遂には身体に変調を覚えるようになり、それまで出来ていた仕事もできなくなってしまいました。

「このままでは、僕は潰れてしまう。」

現状を変えるために、カウンセリングを受けたりビジネス書を読み漁ったり、悩み苦しむ日々が何ヶ月も続きました。そんな中、１冊の本と出会います。『嫌われる勇気』です。

『嫌われる勇気』では、アドラー心理学の考え方に基づいて「自分の人生を生きよ」というメッセージを私に投げ掛けてくれました。それまでの私は、他人の期待に応えようと、他人の目ばかり気にしていました。他人の期待に合わせようとするあまり、無理をして疲弊してしまっていたのです。

私は、他人の人生ではなく、自分の人生を生きるべきだったと気付いたのです。

そして、もう１つ別の気付きがありました。

「自分の人生を生きる」ために考えるべきことと、システムを設計するために考えるべきことは、本質的に同じだということです。

「システム設計には、自分の人生を生き抜くヒントが詰まっているんじゃないか？」

最初は気のせいかなと思いました。しかし、『嫌われる勇気』や多くのビジネス書で紹介されている考え方と、私が持っていたシステム設計の知識や経験を比較すればするほど、多くの類似点が見つかりました。そして、この気付きは確信へと変わりました。

この確信のもと、私は現状を変えるためにキャリアの再構築（リビルド）を決断。「自分がやりたいことができる」「自分の強みを活かせる」そして「多くの人が求めていることができる」そんな可能性が高そうな部署への異動願いを出しました。

そして、この決断は私の人生を変えます。

異動してから１年後、システム設計の技術力を認められ、社内の様々な開発プロジェクトから「参画してほしい。」と次々と声が掛かるようになりました。数年前に干されていた私が、売れっ子になったのです。

それまで１度も受賞したことがなかった社内表彰を３年間で４度受賞。目に見える形で変化が起こりました。

システム設計には、自分の人生を生き抜くヒントが詰まっています。今回、自分の人生を生き抜くための「教養」として、システム設計の考え方を整理しましたので紹介します。

１　システム設計が「教養」である理由

まず、システム設計が「教養」である理由についてお話します。

システム設計に関する知識は、エンジニアがシステム設計を行うためだけの専門知識ではありません。変化の激しい時代を生きる多くの人が、自分の人生を生き抜くためのヒントとなる「教養」であると言えます。

その理由は、システムがその目的を達成するためにも、私達が自分の人生を生きるためにも、「柔軟性」が必要だからです。

システムは”あるビジネス”を成功させることが目的です。そのため、ビジネス環境の変化に対応するために、システムは機能追加や性能向上などの変更を素早く行えること、つまり、「柔軟性」が必要となります。

私達が自分の人生を生きるためには、周囲に惑わされない「柔軟性」が必要となります。また、マズロー心理学で知られるマズローは、自己実現（自分しく生きていきたいという欲求）を達成した人物に共通する特徴の１つとして「柔軟性」を挙げています。

そして、システムについては「柔軟性」を備えるための体系的な考え方が確立されています。エンジニアは、意図をもって設計することでシステムに「柔軟性」を備えることができます。

しかし、自分自身に「柔軟性」を備えるための体系的な考え方は聞いたことがありません。

どのようにすれば自分自身に「柔軟性」を備えることができるのか？そのヒントが、システム設計にあります。システムを自分自身に置き換えて、システムに「柔軟性」を備えるための考え方を自分自身に適用し、自分自身を設計するのです。そうすれば、私達は「柔軟性」を身につけることができるといえます。

システム設計は、自分の人生を生き抜くためのヒントが詰まった「教養」であると考えることができます。

次からは、システムに「柔軟性」を備えるための設計の考え方を紹介し、そこから自分の人生を生き抜くためのヒントを探っていきます。

２　システム設計の全体構造を捉える。

まず、システム設計の全体像、つまり、どんな手順でシステム設計を進めるのか？からお話します。この記事で紹介するシステム設計の手順は、システムの全体構造の捉え方の１つである「エンタープライズアーキテクチャ」の考え方を基本にお話していきます。

エンタープライズアーキテクチャとは、ビジネスを行うシステムの全体構造を考え方の１つで、システムを効率よく設計するための指針となる考え方です。この考え方は、決して新しいものではありません。古典的で歴史ある考え方です。それ故に、システム設計の本質的な考え方を示していると言えます。

エンタープライズアーキテクチャの概要

まず、「エンタープライズアーキテクチャ」の概要として、次の３点をお話します。
　■エンタープライズアーキテクチャの４層構造
　■エンタープライズアーキテクチャの基本原則
　■エンタープライズアーキテクチャの効果

■エンタープライズアーキテクチャの４層構造
エンタープライズアーキテクチャでは、システムの全体構造を４種類のアーキテクチャが層状に積み重なった４層構造として捉えます。これらの４層のアーキテクチャは、上の層から順に「ビジネスアーキテクチャ」「データアーキテクチャ」「アプリケーションアーキテクチャ」「テクノロジーアーキテクチャ」と呼ばれています。

それぞれのアーキテクチャは、次のような意味があります。

(1)　ビジネスアーキテクチャ
ビジネスアーキテクチャは、ビジネスを成功に導くための、システムと利用者の「役割」とその関係です。ビジネスを成功に導くためには、システムと利用者（エンドユーザ、サポート窓口担当者、保守担当者、開発担当者など）が連携し協調する必要があります。これらの「役割」とその関係をビジネスアーキテクチャとして設計します。

(2)　データアーキテクチャ
データアーキテクチャは、利用者がそれぞれの役割を果たすために必要となるデータとその関係です。利用者がそれぞれの役割を果たすためには、システムは「データ」を収集して、利用者が必要とする「データ」を表示する必要があります。これらのシステムで扱う「データ」とその関係をデータアーキテクチャとして設計します。

(3)　アプリケーションアーキテクチャ
アプリケーションアーキテクチャは、利用者に表示するデータを作るための「演算処理」とその構成です。利用者に表示するデータを作るためには、システムが収集したデータを加工する演算処理が必要になります。これらのシステムで行う「演算処理」とその構成をアプリケーションアーキテクチャとして設計します。

(4)　テクノロジーアーキテクチャ
テクノロジーアーキテクチャは、「データ」を扱い「演算処理」を行うための「動作環境」です。「データ」を扱い「演算処理」を行うためには、システムが実体として動作するハードウェアやソフトウェアなどの環境が必要になります。これらのシステムが実際に動く「動作環境」をテクノロジーアーキテクチャとして設計します。

■エンタープライズアーキテクチャの基本原則
エンタープライズアーキテクチャの考え方には、設計の基本原則があります。それは、４層構造の上の層から順番に設計するというものです。

「ビジネスアーキテクチャ」「データアーキテクチャ」「アプリケーションアーキテクチャ」「テクノロジーアーキテクチャ」の順番で設計します。

ものすごく単純化すると、システム設計の順番は次のようになります。

(1)　ビジネスを成功に導くための、システムの「役割」を設計する。
(2)　システムが扱う「データ」を設計する。
(3)　システムが行う「演算処理」を設計する。
(4)　システムが動く「動作環境」を設計する。

システムの「役割」を設計し、「役割」をもとに「データ」を設計し、「データ」をもとに「演算処理」を設計し、「演算処理」をもとに「動作環境」を設計するということです。

システム設計では、このような設計における参照関係のことを「依存関係」と呼びます。この場合、「役割」をもとに「データ」を設計しているので、「データ」は「役割」に「依存している」と呼びます。

このように基本原則に従い設計することで、層と層の間の「依存関係」を上から下への一方方向にすることができます。

そして、「依存関係」を一方方向にすることで、ある層に変更を加えても、下の層にしか変更の影響がないという状態を保つことができます。

例えば、上から３つめの層の「演算処理」を変更した場合、１つ下の層の「動作環境」は「演算処理」に依存しているので変更の影響を受けます。しかし、１つ上の層の「データ」は「演算処理」に依存していないので変更の影響を受けません。

このように、変更を加えたときの影響範囲を限定するために、システムを「役割」「データ」「演算処理」「動作環境」の順番で設計し、４層構造の依存関係を上から下への一方方向にすることが基本原則となります。

実際のところ、この基本原則のとおりに設計を進めることは、なかなかに難しい作業です。エンジニアは、４層を行ったり来たり、進んでは戻ったりを繰り返しながら設計を進めることがほとんどです。ただ、最終的には依存関係が上から下に一方方向になるように、層と層の関係を整えていきます。

■エンタープライズアーキテクチャの効果
エンタープライズアーキテクチャの基本原則に従ってシステムを設計することの効果は、システムに「柔軟性」が備わることです。

その秘密は、４層構造の依存関係が上から下への一方方向であること隠されています。

実はこの４層は下から変化スピードの早い順に重なっています。一番下の「動作環境」は変化スピードが早く、一番上の「役割」は変化スピードが遅いという具合です。

特に「動作環境」は世の中の技術革新の影響を大きく受けます。コンピュータ機器のCPUやメモリ性能向上、ネットワーク通信の高速化など、システムにとって最適な「動作環境」は日進月歩で進化しています。世の中の技術革新に対応するためにはシステムの「動作環境」も頻繁に変更しなくてはいけません。

このとき、４層構造の依存関係が上から下への一方方向であることが効果を発揮します。

基本原則に従って設計されたシステムの場合、「動作環境」に変更を加えても他の層への影響がないため、変化に素早く対応することができるのです。

逆に、基本原則に従わずに設計されたシステムの場合、「動作環境」の変更が「データ」や「演算処理」の層に影響する可能性があるため、影響箇所を特定して再設計を行う必要があります。そのため、変更作業に時間と労力がかかるため、変化に素早く対応することができません。更に、時間と労力がかかる変更を頻繁に行うことで、エンジニアが疲弊してしまうという弊害も起こり得ます。世の中の技術革新が進めば進むほどその恩恵を受けるどころか、システムは変化に対応できず、時代に取り残されてしまうのです。

このように、エンタープライズアーキテクチャの基本原則に従うことで、変化に素早く対応できる「柔軟性」を備えたシステムを構築することができるのです。

自分の人生を生き抜く基本原則

エンタープライズアーキテクチャの基本原則から、自分の人生を生き抜く基本原則を探っていきましょう。

システム設計の基本原則に従うと、自分の人生も、次のように「役割」「データ」「演算処理」「動作環境」の順番で設計を進めるべきと解釈できます。

(1)　自分の人生を生きるために、自分の「役割」を設計する。
(2)　役割を果たすために、自分が扱う「データ」（表現する「データ」や学ぶべき「データ」）を設計する。
(3)　表現するデータを作るために、自分が行う「演算処理」（思考方法など）を設計する。
(4)　自分が動く「動作環境」（会社・職場など）を設計する。

過去の私は、この基本原則に反した考え方で自分の人生を設計していました。「職場のために頑張らないといけない。期待に応えなくちゃいけない。それが自分の役割だ。」とサラリーマンの鑑のように考え、行動していました。「動作環境」である職場で求められることを、自分の「役割」としていたのです。この場合、「役割」が「動作環境」に依存していることになるので、４層構造の依存関係は下から上になっています。

そのため、「動作環境」である職場の上司の考え（ときには機嫌）が変わる度に、自分の「データ」や「演算処理」を再設計しなければならず、変化に対応しきれずに疲弊してしまったのです。職場に合わせようとし過ぎて、空回りして、勝手に疲れてしまったわけです。

自分の人生を生きるためには、システム設計と同じように、自分の人生を「役割」「データ」「演算処理」「動作環境」の順番で設計し依存関係を上から下にすることが基本原則であると言えます。

この基本原則は、私が疲弊しそこから復調できた経験から、真理ではないかと思っています。また、私の周りにいる「芯の強い人」や「しなやかな人」は、この原則に従って人生を設計されているような言動をされているようにも感じます。

次からは、「役割」「データ」「演算処理」「動作環境」のそれぞれについて、設計の考え方を紹介していきます。

３　「役割」を設計する。　

ここでは、システムの「役割」を設計する考え方を紹介し、そこから自分の人生を生き抜くヒントとして、自分の「役割」を設計する考え方を探っていきます。

システムの「役割」を設計する。

システムの「役割」を設計するときは、システムの強みを最大限に活かして、社会の課題を解決することを考えます。

システムは”あるビジネス”を成功させるために存在しています。そのため、「役割」の設計では「ビジネスの成功とは何か？」また、そのために「システムは何ができるか？」を考えていきます。

このとき、考え方のポイントは次の２つです。
　■社会の課題を解決するという役割を設計する。
　■システムの強みを最大限に活かす。

■社会の課題を解決するという役割を設計する。
「ビジネスの成功とは何か？」を考えます。ビジネスの成功の定義は、会社や組織によってそれぞれかと思われます。しかし、ビジネスの成功は、社会の困りごとを解決することになしにあり得ません。そのため、エンジニアはマーケターやクライアントと協調し、社会の困りごと、つまり、社会の課題を理解し、その課題を解決するような「役割」をシステムに持たせなければいけません。社会の課題を解決しない「役割」を持たせても、ビジネスの成功には１ミリも繋がりません。ビジネスにおいて解決しようとしている社会の課題を正しく定義することが、全てのスタートです。

■システムの強みを最大限に活かす。
「システムは何ができるか？」を考えます。社会の課題を解決する「役割」を設計するとき、エンジニアは暗黙のうちにシステムの強みを最大限に活かすことを考えています。システムの強みとは、情報を高速で伝達したり、定形作業を高速で行えることです。その結果、人間を時間と場所の制約から開放することができます。この暗黙の前提をもとに、利用者がやったほうがいい臨機応変な対応が求められる「役割」は利用者に、システムがやったほうがいい「役割」はシステムに割り当てます。利用者とシステムが協調して、社会の課題を解決できるように、システムの強みを最大限に活かせるように「役割」を設計します。

システム設計では、システムの強みを最大限に活かして、社会の課題を解決する「役割」を設計します。

自分の「役割」を設計する。

システム設計の考え方に従って、自分の「役割」を設計する考え方を探っていきます。

システム設計の考え方に従うと、自分の人生を生きるためには、自分の強みを最大限に活かし、社会の課題を解決するべきと解釈できます。

そして、このときの考え方のポイントは次の２つと言えるでしょう。
　■社会の課題を解決するという役割を設計する。
　■自分の強みを最大限に活かす。

■社会の課題を解決するという役割を設計する。
システムと同じように、自分の「役割」も社会の課題を解決することであると言えます。社会の困りごとはないか？その困りごとを解決するために自分はどんな「役割」を果たせるのか？を考える訳です。そして、その「役割」は、会社や職場で一方的に与えられたものではなく、社会を構成する１人の人間としての「役割」です。この考え方は、『嫌われる勇気』で紹介されているアドラー心理学の「共同体感覚」とも通じる考え方です。「共同体感覚」には「より大きな共同体の声を聴け」という原則があり、会社や職場などの小さい共同体ではなく、地域や社会のようなより大きな共同体に判断の軸を置くというものです。自分の「役割」は社会の課題を解決することであるという考え方は、この「共同体感覚」とほぼ同義ではないかと考えています。私達は、普段から社会の一員として社会の動向に関心を寄せ、社会における自分の「役割」を考え続ける必要があると言えます。

■自分の強みを最大限に活かす。
ただ、社会を構成する１人の人間としての「役割」を設計すると言われても、多くの人にとっては唐突な問い掛けではないでしょうか？直ぐに、具体的な「役割」をすぐに設計する難しいと思われます。この難しさは、自分の強みを理解できていないことから生じるのではないかと考えられます。システム設計の場合、エンジニアは暗黙のうちにシステムの強みを理解し、「役割」を割り当てることができました。逆に言うと、強みが理解できていないと「役割」を割り当てることはできません。これは、普段の日常生活においても同じでしょう。
ということは、私達は、まず自分の強みを言葉にできるレベルまで理解する必要があるということです。自分の強みがわかれば、自ずと社会における自分の「役割」が見えてくるはずです。私自身、思い悩んでいたころに、自分と向き合う時間をとり、「お前は何者だ？」とノートに書きなぐりながら問い続けました。誰も答えを教えてくれません。めちゃめちゃ面倒な作業です。でも、そんな中で、自分の性格や趣味、趣向、価値観、頑張れる仕事／頑張れない仕事、すべて、自分の強みの源泉であることが分かりました。そのことが分かっただけでも「自分は自分でいていいんだ」と、自分を受け入れることができたと思っています。
自分と向き合い、自分の強みを分析する。この面倒な作業から逃げてはいけないと言えます。

自分の強みを理解し、その強みを最大限に活かして社会の課題を解決しようと考えることが、自分の人生を生き抜くヒントと言えます。

４　「データ」を設計する。

ここでは、システムが扱う「データ」を設計する考え方を紹介し、そこから自分の人生を生き抜くヒントとして、自分が扱う「データ」を設計する考え方を探っていきます。

システムが扱う「データ」を設計する。

システムが扱う「データ」を設計するときは、利用者を理解し、利用者の役に立つデータのみを扱うことを考えます。

システムは利用者にデータを表示することで、初めてその「役割」を果たします。利用者はシステムの画面などに表示される「データ」を介してのみシステムと対話するため、表示される「データ」がシステムの存在価値そのものになります。

「データ」の設計では、利用者に「どんなデータを表示するのか？」また、そのために「どんなデータを収集するのか？」を考えていきます。

このときの考え方のポイントは次の２つです。
　■利用者を理解し、表示するデータとその利用目的を整理する。
　■必要なデータのみを収集する。

■利用者を理解し、表示するデータとその利用目的を整理する。
「どんなデータを表示するのか？」を考えます。システムは利用者にデータを表示することで、初めてその「役割」を果たします。表示するデータを設計するときは、利用者を理解し、確実に利用者の役に立つデータを設計する必要があります。そして、利用者の理解とは「どんな人が、どんな状況で、どんな目的（意思決定）のために」システムにアクセスするのかを分析し理解することです。利用者を観察したりヒアリングしたり、システムを試作して反応を確かめ、仮説・検証を繰り返します。そして、利用者の意思決定プロセスを言葉にできるレベルまで理解することを目指します。ハーバード・ビジネススクールのクリステンセン教授の名著『ジョブ理論』にて紹介されている「顧客のジョブを完全に理解するには、ある特定の状況で顧客がなし遂げようとしている進歩を、機能的、社会的、感情的側面も含めて理解し、さらに顧客が引き換えにしてもいいと考えているものを理解しなければならない。」という考えは、システム設計においても同じです。
利用者の理解をもとに、必要なデータを抽出して、データの利用目的を整理します。「このデータはこの利用目的で使われる。あのデータはあの利用目的で使われる。」１つづつ整理していきます。そして、データの利用目的の単位で、そのデータを構成するデータセットを設計します。１つの利用目的に対して、１セットのデータセットを設計するイメージです。このようにデータの利用目的を整理し、システムの「役割」と対応づいた複数のデータセットを設計します。

■必要なデータのみを収集する。
「どんなデータを収集するのか？」を考えます。利用者に表示するデータを設計したあとは、その表示データを生成するために、システムが収集するデータを設計します。収集するデータは、表示するデータから逆算して必要最低限のデータのみになるように設計します。あれもこれもと収集するのではなく、真に必要なデータのみを収集するイメージです。ただ、実際のところ、このような設計になっていないケースは少なくありません。「将来、必要になるかもしれない」という理由で、表示するデータとは関係のないデータをなんの意図もなく収集しているケースがあります。これは、何もいいことがありません。余計な開発工数がかかり、余計なデータ管理コストがかかります。「将来、必要になるかもしれない」と不安であるならば、「とりあえずデータを収集する」という設計にするのではなく、その不安を取り除くことを考えるべきでしょう。何の意図もなく、闇雲にデータを収集するのはコストパフォーマンスが悪くするだけです。システムの「役割」と対応づいた必要最低限のデータのみを収集するようにします。

システム設計では、利用者を理解し、利用者の役に立つ「データ」のみを扱うように設計します。

自分が扱う「データ」を設計する。

システム設計の考え方に従って、自分が扱う「データ」を設計する考え方を探っていきます。

システム設計の考え方に従うと、自分の人生を生きるためには、表現するデータを模索して、表現に必要なデータ（知識、スキル）のみを学ぶべきと解釈できます。

そして、このときの考え方のポイントは次の２つと言えるでしょう。
　■表現するデータを模索し、その目的を整理する。
　■必要なデータ（知識、スキル）のみを学ぶ。

■表現するデータを模索し、その目的を整理する。
システムが利用者にデータを表示することで、初めてその「役割」を果たせるように、私達も社会に対して何らかのデータを表現することで、初めてその「役割」を果たせるといえます。作家であれば文章、WEBエンジニアであればWEBページ、スポーツ選手であればそのプレーが、その人のデータ表現といえます。発言や行動などの表現されているデータが、その人であるともいえるでしょう。そして、私達はその表現をもってして、社会の課題を解決することを考えないといけません。どんなデータを表現することが社会の課題を解決するのか？検討が付かないかもしれません。でも、ここはシステム設計と同じアプローチで模索するしかないのだと思います。「どんな状況のどんな人を幸せにする」表現なのか？社会の反応を確かめ、仮説・検証を繰り返すというアプローチです。私の場合、このnote投稿も仮説・検証の一環です。挑戦し失敗し、時には恥をかくこともあるでしょう。でも、どんな時にどんなデータをどんな意図で表現すればよかったのかを、焦らず考えて改善を繰り返していく。ここで大切なのは「次も頑張ろう。」というプラス思考ではなく、論理的思考だといえます。自分が表現するデータとその目的を言葉にできるレベルまで分析して理解するということを愚直に繰り返す必要があるでしょう。

■必要なデータ（知識、スキル）のみを学ぶ。
そして、自分が表現したいデータとその目的が整理できてきたら、システムと同じように、そのデータから逆算して、必要最低限のデータ（知識、スキル）のみを学ぶようにします。例えば、本を読むときも闇雲に流行りの本を読むのではなく、自分が表現したいデータのネタを探すという意図をもって本を読む。会社で仕事をするときも漫然とこなすのではなく、自分が表現したいデータを作るスキルを身につけるという意図をもって仕事をするというものです。逆に、自分の表現につながらない、本や仕事に時間を費やすことは、自分の命の時間の使い方として、コストパフォーマンスが悪いといえます。ベストセラー『エッセンシャル思考』で紹介されている「99%の無駄を捨て、1%に集中する。」という考え方と同じです。
また、自分が表現したいデータを整理できていれば、一見、自分の表現につながらなさそうな活動の中に自分の表現につながる要素を見つけることもできます。例えば、私の場合、会社からTOEIC受験という自分の表現につながらない課題を課せられ、ただただ苦痛でした。しかし、英語は日本語のように曖昧な表現が許されない言語体系であるため、論理的思考の訓練になるという話を聞き、英語学習を論理的思考の訓練の場と意味変換することで、前向きに取り組むことができました。TOEICの点数はそこそこだったものの、英語を勉強することで、論理的思考力だけでなく日本語の文章力も上げることができたという実感があります。
自分の表現につながるデータ（知識、スキル）を意図をもって学習することが、自分の人生を生きることにつながっていくと言えます。

表現するデータを模索して、表現に必要なデータ（知識、スキル）のみを学ぼうと考えることが、自分の人生を生き抜くヒントと言えます。

５　「演算処理」を設計する。

ここでは、システムが行う「演算処理」を設計する考え方を紹介し、そこから自分の人生を生き抜くヒントとして、自分が行う「演算処理」を設計する考え方を探っていきます。

システムが行う「演算処理」を設計する。

システムが行う「演算処理」を設計するときは、アップデートすることを見越して、データの利用目的ごとにシンプルな演算を行うことを考えていきます。

システムは、収集した「データ」から利用者に表示する「データ」を作り出すための「演算処理」を行います。このとき、表示する「データ」が利用者の役に立ち続けるためにも、アップデートすることを見越しておきます。

「演算処理」の設計では「どんな単位でどんな演算をするのか？」「何を根拠にアップデートするのか？」を考えます。

このときの考え方のポイントは次の２つです。
　■データの利用目的ごとにシンプルな演算を行う。
　■事実をもとにアップデートできるようにする。

■データの利用目的ごとにシンプルな演算を行う。
「どんな単位でどんな演算をするのか？」を考えます。「データ」の設計では、データの利用目的の単位でデータを構成するデータセットを整理しました。「演算処理」の設計においても、データの利用目的の単位で演算を行うように設計します。１つの利用目的に対して、１つの演算をおこなうようにするイメージです。「この演算はこの目的のために行う。あの演算はあの目的のために行う」という具合に、１つの演算が担う範囲を限定します。
さらに、１つの演算では、とにかくシンプルな演算処理を行うようにします。演算処理に入力された１つのデータセットのみから答を出力するようにし、複数のデータを参照するような複雑な処理は行わないように、とにかくシンプルな演算処理になるように設計します（専門的には「ステートレス」と呼ばれる演算を心がけます）。
データの利用目的ごとにシンプルな演算を行うようにすることで、演算処理の変更をより簡単に安全に行うことができます。もし、利用者に表示しているデータが、あまり役に立っていないことが分かった場合であっても、少ない時間と労力で、「データ」と「演算処理」をアップデートすることができるようになります。この特性はシステムの「柔軟性」に他なりません。
システム設計の基本原則に従った上で、データの利用目的ごとにシンプルな演算を行うようにすることで、システムをより柔軟にすることができます。

■事実をもとにアップデートできるようにする。
「何を根拠にアップデートするのか？」を考えます。「演算処理」をアップデートするタイミングは、利用者に表示しているデータがあまり役に立っていないことが分かった場合です。この状態を放置することは、システムが「役割」を果たすことを放棄することになります。そのため、エンジニアは利用者の操作履歴である操作ログを分析して演算方法の変更を検討したり、収集したデータを分析して演算精度を上げるためにパラメータの調整を検討します。
どちらの場合も、操作ログや収集したデータなど、システムに蓄積される「事実」を根拠にして「演算処理」をアップデートすることを考えます。逆に言うと、「演算処理」をアップデートするためには、システムに蓄積される「事実」が必要不可欠です。「事実」をもとに「演算処理」をアップデートできるように設計します。

システム設計では、アップデートすることを見越して、データの目的ごとに単純な「演算処理」を設計します。

自分が行う「演算処理」を設計する。

システム設計の考え方に従って、自分が行う「演算処理」を設計する考え方を探っていきます。

システム設計の考え方に従うと、自分の人生を生きるためには、アップデートすることを見越して、データの目的ごとにゼロベースで思考することを考えるべきと解釈できます。

そして、このときの考え方のポイントは次の２つと言えるでしょう。
　■データの目的ごとにゼロベースで思考する。
　■事実をもとにアップデートできるようにする。

■データの目的ごとにゼロベースで思考する。
システムが「この演算はこの目的のために行う。あの演算はあの目的のために行う」という具合に、１つの演算が担う範囲を限定するように、私達も「演算処理」（思考）する場合、その思考している目的を限定して考えることが重要であると言えます。ある事柄に対して、いま思考している目的はなんなのか？また、その思考を行うことは自分の「役割」とどんな関係があるのか？を見極めなければいけないと言えます。そして、見極めた結果、自分の「役割」となんら関係のない事柄に対して思考しているのであれば、それは時間の無駄と言えるでしょう。この考え方は『嫌われる勇気』で紹介されているアドラー心理学の「課題の分離」とよく似た考え方です。ある課題に対して、それは自分の課題なのか、他人の課題なのかを分離して考えることが重要であると説かれています。
さらに、私達もシステムが行っているようなシンプルな演算（思考）を行うのがよいと考えることができます。システムでは、最新のデータのみから答を導出するというシンプルな演算をおこなうことで柔軟性を高めていました。言い換えると、私達は目の前にあるデータに対してゼロベースで思考することが柔軟性につながるのだと言えます。無邪気な目で物事を捉え、偏見や先入観を排除して思考する。安易な一般化やレッテル貼りを行ってはいけないといえます。
データの目的ごとにゼロベースで思考することで、私達の柔軟性は高まるのだと言えます。

■事実をもとに思考をアップデートする。
システムが事実を根拠に「演算処理」をアップデートするように、私達の思考も事実を根拠にアップデートしていかないといけないと言えます。自分の思い込みや恐れ、何の事実にも基づかない他人のアドバイスを根拠にしてはいけません。ベストセラー『ファクトフルネス』でも述べられているように、事実をもとに、物事を正しく捉えなければいけません。
そして、システムと同じように、私達もどんどんアップデートを繰り返していけばいいのです。最新の事実をもとに、自分の「演算処理」をアップデートすることで、「役割」を果たしている自分に近づくのです。また、アップデートにおいて、過去の自分の発言と整合を取る必要もありません。自分の「演算処理」がアップデートされた結果、発言の内容が変わったとしても、その事実に対して「ブレている」と考えるのは他人の課題であって、自分の課題ではありません。認識できている事実が変われば、思考過程が変わるのは当然と言えます。別人になっていく自分にワクワクしながら、どんどん思考をアップデートしていきましょう。

アップデートすることを見越して、データの目的ごとにゼロベースで思考することが、自分の人生を生き抜くヒントといえます。

６　「動作環境」を設計する。

ここでは、システムが動く「動作環境」を設計する考え方を紹介し、そこから自分の人生を生き抜くヒントとして、自分が動く「動作環境」を設計する考え方を探っていきます。

システムが動く「動作環境」を設計する。

システムが動く「動作環境」を設計するときは、世の中の技術レベルの制約を理解し、その時代における最適なシステム構成となるように設計します。

ここまで、システムの「データ」「演算処理」を設計してきました。しかし、これだけでは「絵に描いた餅」に過ぎません。利用者が求めているのは、実体のある「餅」です。システムが実体を持ち、利用者に不都合が生じないように動作して初めて、利用者の役に立ちます。

「動作環境」の設計では「現状、どんな制約があるのか？」「その制約は将来なくなるのか？」を考えていきます。

システムが動く「動作環境」を設計するときのポイントは次の２つです。
　■制約を理解し最適な選択をする。
　■制約が緩和されることを見越しておく。

■制約を理解し最適な選択をする。
「現状、どんな制約があるのか？」を考えます。システムの「データ」「演算処理」の設計にて、システムがデータを収集・演算・表示するという「データの流れ」を設計しました。「動作環境」の設計では、この「データの流れ」に滞りが起きないように、システムを構成する最適なコンピュータ機器やネットワーク構成などを決めます。この時に理解しないといけないのは、コンピュータ機器の性能やネットワークの通信速度など、その時代の技術レベルの制約です。なぜなら、この制約が「データの流れ」を滞らせる要因となるからです。
例えば、利用者のスマートフォンに動画を表示するシステムの場合、その動画ファイルはスマートフォンに保存されていたほうが快適に表示することができます。しかし、そのようにしてしまうと利用者のスマートフォンのハードディスクの容量が制約となり、スマートフォンの性能によって表示できる動画の数が限定されるという不都合が生じます。その対策として、必要なタイミングで動画ファイルをダウンロードするようにすると、今度はネットワークの通信速度が制約となり、ダウンロードに時間がかかるという不都合が生じます。「さてどうするか？」エンジニアは、その時代の技術レベルの制約を理解し、試行錯誤して最適な「動作環境」を設計します。また、一部のデータについては、「設計したけれど実装はしない」と諦めざるを得ないものは諦めることになります。
しかし、「制約は創造性の母」という言葉があるように、様々な制約の中で「さて、どうするか？」と考え、試行錯誤することがイノベーションにつながります。例えば、先程の例では、動画ファイルを小さいデータに分割して利用者に送信するストリーミングと呼ばれる技術が誕生しました。その時代の制約を理解し、その中で最適な解を見つけることが重要になります。

■制約が緩和されることを見越しておく。
「その制約は将来なくなるのか？」を考えます。その時代の制約のために、システムが扱うデータの量や種類について、諦めざるを得ないものは諦めていました。このとき、どんな制約によってどんなことを諦めているかを整理しておくことは大切です。なぜなら、世の中の技術革新は日進月歩。コンピュータ機器の性能や、ネットワークの通信速度は向上するからです。近年、スマートフォンの性能はどんどん向上し、ネットワークの通信規格は４Gから５Gに進化、よりデータ量の大きい綺麗な動画をよりリアルタイムで送受信可能になりました。時代の流れとともに、「データの流れ」を滞らせていた要因になっていた制約が緩和され、諦めていたことが実現できるようになります。エンジニアは世の中の技術革新の動向に目を配り、緩和された制約を見定め、待ち構えていたかのように「動作環境」を最適なものにどんどん乗り換えていくことを検討します。その結果、システムは進化し続けることができます。
そして、この進化を可能にするのが、これまで説明してきた「役割」「データ」「演算処理」「動作環境」の４層の依存関係を上から下の一方方向にするという設計です。エンジニアは、世の中の技術革新が起こる中で、この依存関係を維持し続けることが求められます。しかし、この依存関係を維持し続けることはなかなかに困難です。なぜなら、最新技術は華やかに登場し、目の前の問題を一気に解決する魔法の杖のように現れるからです。AIやブロックチェーンなど、流行りの技術はエンジニアにとってはものすごい誘惑となります。「なんか良さそう。カッコよさそう。」と思ってしまうからです。このとき、最新技術を使うことが目的になってしまうと、「動作環境」に依存した「データ」や「演算処理」が生まれてしまいます。４層の依存関係の整合性が崩れ、システムの「柔軟性」に綻びを生むことになります。その結果、システムが進化し続けることが困難になってしまう可能性もあります。世の中の技術革新は、システムの制約を緩和するものであるという観点を忘れてはいけません。

システム設計では、世の中の技術レベルの制約を理解し、その時代における最適な「動作環境」を設計します。

自分が動く「動作環境」を設計する。

システム設計の考え方に従って、自分が動く「動作環境」を設計する考え方を探っていきます。

システム設計の考え方に従うと、自分の人生を生きるためには、会社や職場の制約を理解し、最適な環境に身を置くことを考えるべきと解釈できます。

そして、このときの考え方のポイントは次の２つと言えるでしょう。
　■制約を理解し最適な選択をする。
　■制約が緩和され、活躍できる場所を探し続ける。

■制約を理解し最適な選択をする。
システム設計では、データの流れを滞りなく実現できる「動作環境」を設計しました。同じように、私達も、学びたいデータを学び、思考して表現するという「データの流れ」を滞りなく実現できる環境として、会社や職場を選ばないといけないと言えそうです。その会社や職場に身を置くだけで、学びたいデータを学べ、自分の思考をアップデートし、「役割」を果たしている自分に近づけるという環境が理想だと思います。
私の場合、過去の職場が理想的ではないことに気づくまで10年程かかりました。その職場では、与えられた仕事の中で、それなりに試行錯誤して自分の技術力を高めることができていまいた。特許も複数取得して、売上にも貢献できました。エンジアにとっては理想的な環境に思えました。しかし、その職場で学んだ多くが、特定のシステムの特化した技術であったり、その職場のルールに従った仕事の進め方であったり、その職場でしか使えないスキルがほとんどだったのです。「もし、僕が試行錯誤して獲得した技術をセミナーで発表するとしたら何人ぐらい人があつまるだろうか？」と考えたとき「たぶん、誰も来ないな・・・」と青ざめたのです。私は、置かれた環境の中で最善を尽くし、思考をアップデートしていたものの、その方向は社会の課題を解決できる自分には向かっていなかったのです。
これは明らかに設計ミスでした。もっと早く気付けばよかったと悔やみました。でも、当時の私は、自分の人生を生きるということに、真剣に向き合っていなかったので仕方がありません。それも含めて人生なんでしょう。
職場で最善を尽くし、自分の思考をアップデートできたとしても、そのアップデートの方向は、職場の業務内容の制約を受けます。まるで”見えざるレール”のようです。職場の制約を理解し、「役割」を果たしている自分に近づける環境を選ぶとこが大切です。

■制約が緩和されることを見越しておく。
システムの「動作環境」の制約は緩和されるのと同じように、私達の環境の制約も緩和されていきます。しかし、この緩和は職場に存在する”見えざるレール”がなくなるのではく、自分の思考をアップデートするための「データの流れ」のスピートが早くなっていくと捉えたほうがいいでしょう。
私の場合、職場選びの設計ミスに気付き、「役割」を果たしている自分に近づける職場に身を置くことに成功できました。新しい職場で思考のアップデートを繰り返すなかで「データの流れ」のスピートが早くなっていることを実感しています。システムの場合、世の中の技術革新によって制約が緩和され、より多くのデータを扱えるようになります。しかし、私達の場合は、自らのアップデートによって職場の制約が緩和され、より多くのデータを扱えるようになります。単純に昇進によって、権限の範囲が広がるということもあるでしょう。ただ、私の経験では、昇進など伴わなくても、自らをアップデートし続けることで、周囲の目が変わり、勝手に「データ」が集まってくるようになります。自分が扱うデータの量や種類が、勝手に増えていきます。
この時、データの増加に比例する形で、自らをアップデート頻度を上げるという正のスパイラルを作るためにも、「役割」「データ」「演算処理」「動作環境」の４層の依存関係を上から下の一方方向にするという設計が大切だと思います。データの量や種類が増えるということは、それらを全て真に受けていては自分自身がパンクしてしまう可能性があります。全て真に受けて、趣味の時間や家族との大切な時間を犠牲にしては本末転倒です。なりたい自分に向かうために、今の自分に必要なデータを厳選を学び、確実にアップデートしていくという考え方が重要だと思います。
扱うデータが増えてきたら、正のスパイラルへの吉兆です。「役割」を果たしている未来の自分を想像しながら、ニヤニヤしましょう。未来は設計で明るくなる！

会社や職場の制約を理解し、自分にとって最適な環境を考えることが、自分の人生を生き抜くヒントといえます。

あとがき

このような長文を最後まで読んでいただきありがとうございました。

私は、エンジニアとして働く中で、疲弊しそこから復調できたことをきかっけに「エンジニアが活き活き働く世界を作ること」という社会の課題に気付きました。

日本の産業は米中勢におされ、人口先細りの中で一人一人の生産性を上げていかないといけません。でも、私は疲弊し、それまで出来ていた仕事ができなくなってしまいました。

でも、これは、私だけに起こる問題なんでしょうか？

いや、そんなことはない。

「僕と同じように、本来の力を発揮できていないエンジニアが他にもたくさんいるんじゃないか？」
「人材不足を嘆くよりも、現役で働いているエンジニアがもっとイキイキと働く世界を作ることの方が大切なんじゃないか？」

そう思うようになりました。

では、私はどうして疲弊してしまったのか？

数年前の自分を振り返り、自問したところ一つの答に行き着きました。私が疲弊した原因は私自身にありました。私は「職場の期待に応えることしか頭になく、誰かの役に立つシステムを開発することは考えていなかった。」のです。私は、エンジニアとして社会人としてシンプルの未熟だったのです。

当時の私は、システム設計とは何か？など分かっていなかった。自分の人生にも向き合っていなかった。与えられた環境で、他人の人生を生き、また、他人にも「僕の人生を生きてほしい」と期待していた。そして、そんな自分に疑問すら感じなかった。

この記事は、そんな過去の自分に対して「エンジニアとして、社会人として、これぐらいの『教養』は知っておこうな。」という想いを込めて執筆しました。

この記事が、過去の自分だけでなく、あなたにとっても自分の人生を生き抜くためのヒントになれば、これほど嬉しいことはありません。

また、エンジニア向けの内容をこちらの目次に沿って投稿しています。具体例を補足しつつ投稿しているので、是非、アクセスしてみてください。

今回の記事が「面白かった！」という方はフォローまたはスキしてもらえると嬉しいです。Twitterで共有ツイート頂ければソッコーでRTします。

参考文献

システム設計の専門書

ビジネス書