生産性はアーキテクチャで決まる

はじめに

こんにちは。はちぽちです。
人事評価制度設計についてはかなり書いたので、今回は角度を変えて話していきます。
評価制度の話は、従業員のキャリアアップやモチベーションアップに貢献し、生産性が上がるという論理展開でした。

今回は、生産性を上げるための業務設計について書きます。

アーキテクチャとは

日本語にすると、「構造」です。
わざわざカタカナにしたのは、キャッチ―だからです。笑

すごくふわっとした言葉なので、いくつか具体例を挙げます。

・ホールディングスのグループ見取り図
・企業の組織図
・製造工場のレイアウト
・小売店舗のレイアウト
・ITシステムの構成

ざっくり並べましたが、従業員個々の力でどうにかるものではなく、基本的には経営判断が必要なレイヤーかと思います。
僕はIT業界の人間で、製造や小売りだと「動線を組みなおしましょう」くらいしか言えないので、ITシステム構成について詳しく書いていきます。

生産性を上げるシステムアーキテクチャ

先に断っておくと、大規模システムの全体最適化ではありません。
それは、システムの前に部署統廃合や人事異動が絡む話になるからです。
ここでは、「個々のシステムはどのようなアーキテクチャにすればSEのパフォーマンスが上がるか」に焦点を当てていきます。

結論から言うと、
・複雑性が低いシステムは、強力なフレームワークを使いましょう。
・Webフレームワークで対応しにくいシステムは、マイクロサービスアーキテクチャで対応しましょう。

生産性より優先するものがある場合は、この限りではありません。

大切なのはバックエンド

フロントは、JSPなど一部のFWを除いて基本的にアーキテクチャの影響を受けません。
また、モバイルアプリが特にわかりやすいですが、利用目的と使うべき技術がほぼ決まっています。
生産性は、個々の技量が占める要素が大きいでしょう。
一方のバックエンドは、アーキテクチャの影響をダイレクトに受ける部分です。

複雑性が低く、強力なFWで対応可能なものは、以下のメリットがあります。
　・画面設計ができれば、バックエンドまでだいたい見通せる。
　　つまり、設計に細かく時間を使わずに済む。
　・FWの補正が強いので、テスト工数を圧縮できる。

マイクロサービスは、以下のメリットがあります。
　・機能ごとに完結しているため、改修コストが低い。
　　もちろん、改修に至るまでの調査コストも低い。
　・インプットとアウトプットの定義があればいい。
　　つまり、こちらも設計にかかる時間が少ない。

現在日本国内で主流のJavaで作ったシステムは、至る所に共通化されたクラスメソッドがあるため、改修が発生するたびに影響調査をする必要があります。
また、そういった複雑なシステムを維持するためには、膨大な量の設計書を作成し、しっかりメンテする必要があります。
システム間の連携に詳しい人がどうしても必要になるので、属人化もしやすいです。

まとめ

具体的な話ができるのがITシステムだったので、ちょっと専門用語多めで解説してしまいました。
ただ言いたいことは、複雑怪奇な構造にするのではなく、なるべく簡素に保つ構造を用意するのが大切ということです。

変化に強いアーキテクチャを、心がけていきましょう！