2024/02/12

アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないか

進化的アーキテクチャ」の本を読み直していたら、アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないかと気づいた。
ラフなメモ書き。

【1】以前に「進化的アーキテクチャ」の本を読んでいたが、その時はこの本の中身がさっぱり分からなかった。
マイクロサービス設計をコンポーネント分割、モジュール分割のように組み立てたい意図は分かるが、その設計方法や中身が雲のように意味不明だった。

そして、とある勉強会で「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を輪読していた。
この本はマイクロサービス設計の解説なのだが、その中に、アーキテクチャ量子、適応度関数という考え方が出てくる。

アーキテクチャ量子は、これ以上分割できないソフトウェアコンポーネント、みたいなイメージを持っている。
適応度関数は、アーキテクチャを診断するメトリクス、みたいなイメージを持っている。
しかし、ふわふわした抽象的概念であり、すぐに理解しづらい。

なぜ、アーキテクチャ量子、適応度関数のような概念がマイクロサービス設計で必要なのか?

【2】アーキテクチャ量子とは、高度な機能的凝集を持つ独立してデプロイ可能なコンポーネントと定義されている。
なぜ、わざわざ量子みたいな言葉を使う必要があるのか?

進化的アーキテクチャ」では、量子力学のアプローチを使って、モジュール性を説明しようとしている。
物理学では、自然界には4つの力、強い力、弱い力、電磁気力、重力がある。
この概念を流用して、アーキテクチャ量子の言葉の意図は、原子核のような小さな量子では、物理学が言う強い力が働いてバラすことができないこと、つまり、ソフトウェアのコードは組み立て部品のように再利用できる単位に分解できないことを意味しているのだろう。

すなわち、アーキテクチャ量子は再利用可能なソフトウェアコンポーネント、ソフトウェアモジュールの比喩として使っている。

なぜ、わざわざアーキテクチャ量子という新しい言葉を使う必要があるのか?

マイクロサービスはソフトウェアアーキテクチャも含めたレベルでソフトウェアの再利用を目指そうとしている。
つまり、アーキテクチャ量子の考え方を使って、従来からのソフトウェア工学の根本問題、ソフトウェアを再利用できる単位にどのように再構築するか、を考えようとしているのだろう。

アーキテクチャとは、ソフトウェアの中で最も不変な部分に相当するが、ソフトウェアの歴史ではアーキテクチャの範囲がどんどん変わってきている。
再利用の単位が、構造化プログラミング、オブジェクト指向、そしてマイクロサービスへ変遷してきている。
そういう歴史的経緯を踏まえて、アーキテクチャ量子という言葉を新たに用いて、現代風に理解しようとしているのだろう。

【3】アーキテクチャ量子に加えて、適応度関数とは、アーキテクチャが継続的に変化あるいは進化することでどれだけ目的の達成に近づいているか、を計算するための目的関数と定義されている。
なぜ、メトリクスと言わずに、わざわざ適応度関数のような言葉を使うのか?

物理学のアプローチでは、自然界の現象だけでなく、経済や人間の事象に対しても、数式で表現できるはずだ、という設計思想がずっとある。
アーキテクチャ量子のように、ソフトウェアコンポーネントに物理的アプローチを用いたならば、同様に再利用できる単位は何らかの数式で表現できるはずだろう。

その時に、アーキテクチャ量子の診断結果を計測するメトリクスを適応度関数と呼んでいるのではないだろうか。

進化的アーキテクチャ」では適応関数の事例がなくて、抽象的な説明ばかりでイメージづらいが、「ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス」では、適応度関数の具体例が掲載されていて、それでようやく理解できた。

適応度関数は、ユニットテストレベルならばカバレッジや静的コード解析が目標範囲内にあるか評価することに相当するし、統合テストレベルならば、パフォーマンスの計測やAPIテストで目標範囲内にあるか評価することに相当する。
E2Eテストレベルならば、UATで使われる正常業務パターンのスモークテストケース、ビジネス要件やマーケティング要件を評価するメトリクスがあるだろう。

つまり、適応度関数はアーキテクチャが正常であるかを診断するメトリクスとして用いられる。

留意点は、適応度関数はケースバイケースとして色々実現されることだろう。
適応度関数は唯一の正解はなく、システムのアーキテクチャごとに設計されて実装される。
だから、GQMのように、メトリクスが使われる目的や意図が重要になってくる。

【4】アーキテクチャ量子に加えて、適応度関数のような概念を新規に作り出した意図には、物理学アプローチを用いて、マイクロサービス設計のような現代風アーキテクチャを理論化して整理したいことがあるのだろう。

再利用できる単位は、構造化プログラミングでは関数レベルだが、オブジェクト指向プログラミングでは、データと処理がカプセル化されたクラスレベルになった。
今では、マイクロサービスでは、処理を行うサービスとデータを保持するデータベースを一体化したドメインレベルで再利用しようとしている。
つまり、新しい酒は新しい革袋に入れるように、マイクロサービス設計には新しい概念を使うべき、という主張なのだろう。

すなわち、ソフトウェア工学に物理的アプローチを適用したい意図があり、それの一つの例が、アーキテクチャ量子や適応度関数になるのだろう。

そんなことを考えると、「進化的アーキテクチャ」「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」の著者は、量子力学などに詳しい物理学の専門家をバックグラウンドに持つソフトウェアアーキテクトなのだろうと推測する。

【5】物理学的なアプローチを自然科学のような自然現象だけでなく、経済現象やソフトウェア工学に適用しようという事例は20世紀後半からよく見られる。
物理学で量子力学や相対性理論が完成した後、物理学が解決すべき問題はかなりなくなってきたという話は昔から聞いていた。
だから、成功の歴史がある物理学のアプローチを使って、自然現象以外の問題に適用して、仕組みをモデル化し、問題を解決しようとする方向性はよく見られる。

たとえば、とある勉強会で、トランスフォーマーのニューラルネットワークの背後に重力の対称性である一般座標変換対称性があると言う話を聞いた。

Xユーザーのakipiiさん: 「トランスフォーマーのニューラルネットワークの背後に重力の対称性である一般座標変換対称性があると言う話を勉強会で聞いた。NNを物理で理解するのは面白いな。Unification of Symmetries Inside Neural Networks: Transformer, Feedforward and Neural ODE https://t.co/ooUEm9bLk1」 / X

この論文では、ニューラルネットワークの背後にゲージ対称性のような仕組みがあるのではと議論しているらしい。
この議論の中で、ある人が話されていた発言がすごく心に刺さった。

「人間が作り出したニューラルネットワークは人間が理解不能な状況になっている。
ニューラルネットワークで起きている座標的なもの、力学的なものを自然界に適用した物理学を使って、ニューラルネットワークの中を研究対象できるのではないか、と思える。
物理学者はこういうものが好き。物理学者は数学を作り出す。」

「ブラック・ショールズ方程式も物理学者が見つけた経済モデル。
自然ではないものに物理学的な思想、物理学的アプローチを適用したものだった。」

今のニューラルネットワークや大規模言語モデルでは、その原理や仕組みはまだ誰も分かっていないまま、Pythonで作られたNNやLLMのライブラリをいかに使って問題解決していくか、みたいなところに走っている気がして、違和感をずっと感じていた。
でも、今までの物理学の知見を使って、NNやLLMの原理を理解しようとする発想は面白いなと思う。

たとえば、経済現象でも、ブラック・ショールズ方程式のような経済学の理論も物理学者がブラウン運動の考え方を使っている。
このブラック・ショールズ方程式により、株式証券の無リスク・ポートフォリオが計算されて、現代の金融取引が成り立っているわけだ。

このように、今までに成功した歴史があり、たくさんの道具やツールが揃っている物理の手法を使うことで、経済現象やニューラルネットワークの仕組みを理解しようとしている。
物理学では現象を数式で説明するので、コンピュータに乗りやすいし、応用がききやすい。

その一連の流れに、ソフト工学に物理的アプローチを適用してみよう、という発想もあろうのだろう、と思っている。
そして、その物理的アプローチはわりと成功する可能性が高いのでは、と思ったりしている。

| | コメント (0)

2024/01/02

マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか

マイクロサービスの設計は理解できていなかったし、今も理解が中途半端。
理解できたことだけをメモする。
ラフなメモ書き。

【1】「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を友人と輪読しているが、まだ理解できたという気がしない。
今までのオンプレ環境で業務系Webシステムの設計や開発をしてきた経験、Java+Oracle+Linuxでベタに開発した経験をベースに理解しようとしていた。

そういう観点で読むと、「8章 再利用パターン」が一番理解しやすい。
なぜならば、コンポーネントやサービスの再利用性は、オンプレ環境のWebシステムであれ、クラウド環境のマイクロサービスであっても、同様の観点が通じるからだ。
たとえば、バージョニング戦略は、まさにソフトウェア構成管理と同じ。
後方互換性を見極める、Javaの非推奨(deprecated)のアノテーションのように廃止されたAPIは使わない、枯れた最新バージョンを使う、定期的にパッチ収集とパッチ適用の運用ルールを定める、とか、どこでも同じ。

しかし、マイクロサービスの本質はそういう所ではないはず。

【2】マイクロサービスを僕が理解できない原因は2つあると思っている。
まず、マイクロサービスを実装したモデルを考えようとすると、AWSサービスを使った実装を考えることが普通。
しかし、AWSサービスに特化しすぎると、AWSはサービスが多すぎて、どの場面にどのサービスを使うと良いのか分からなくて、混乱してしまい、何が重要なのか分からなくなる。

他方、AWSサービスのような具体的なサービスを外して、抽象的なマイクロサービス設計技法を考えると、逆に具体的なイメージが思い浮かばず、ふわふわした議論になってしまう。
オンプレ環境の経験を元に比較理解しようとするだけで、その本質までたどり着けない。

マイクロサービスの直感的イメージは、一昔前のSOAPでやり取りするWebサービスとほぼ同じと思っている。
現在なら、SaaSはほとんどがマイクロサービスで実装されているのではないだろうか。
たとえば、検索サービス、顧客サービス、商品サービス、在庫サービスなど、リソースやイベントの単位で区切られたドメインをマイクロサービスへ分割し、それらの間はRESTでデータをやり取りし協調しながら1つのユースケースを実現しているイメージ。
だから、マイクロサービスだからといって、そんなに難しかったり、高尚な概念でもないはず。

では、現代のクラウド上のマイクロサービス設計では、かつてのオンプレ環境のWebサービスと何が異なるのか?
ここさえ抑えれば理解できる、と思える本質的内容は何なのか?

【3】「絵で見てわかるマイクロサービスの仕組み」を読みながら、理解したことを書いておく。
今の自分のレベルではこれくらい噛み砕いたレベルでないと理解しにくかった。

絵で見てわかるマイクロサービスの仕組み」で自分に響いた内容は3つ。

【4】1つ目は、マイクロサービスは、数秒後から数時間後に動機が取れていればいいとする結果整合性が許容できる場面で活用すべき。
つまり、マイクロサービスではACID特性を厳格に守るのは難しいし、そういう場面では有効とは言えない。

よって、マイクロサービスが使えるユースケースは、業務が並列処理で動作しても良いケース、頻度は少ないが一時的にアクセス数や負荷がかかる時にCPUやメモリを動的に増やすスケールアップやサーバ台数を動的に増やすスケールアウトするケースなどだろう。
すなわち、性能要件を動的に拡張したいケースが当てはまるのではないか。
AWSやAzureのようなクラウドであれば、そういう拡張は、クラウド基盤が提供するマネージドサービスで簡単に実現できる。

一方、デメリットは、ACID特性ではなく結果整合性でしか担保しないので、基幹系システムでは難しいかもしれない。
たとえば、あるマイクロサービスで障害が起きてデータの不整合が発生した時、ロールバックをDBMSやフレームワークではなく、自分たちで作り込む必要があるかもしれない。
絵で見てわかるマイクロサービスの仕組み」では、異常系処理やロールバック処理を補償トランザクションで実現する方法が紹介されていた。
この辺りは実際の実装方法がよく分かっていないが、結局、自分たちでフレームワークを組み込んでいるのと同じような印象を受ける。

【5】2つ目は、コンテナオーケストレーションは、複数コンテナをクラウド基盤のAPIやマネージドサービスで制御する設計思想であること。

絵で見てわかるマイクロサービスの仕組み」では、コンテナ<Pod<ノードの順でグループ化されていた。
すると、複数のコンテナを手動で管理するのは面倒だし、ミスも多くなる。
また、頻度は少ないがアクセス数が一時的に増える場合にスケールアウトするようにコンテナを動的に増やす場合、コンテナのIPアドレスは一時的に付与されるので、管理する手法も特有の考え方が必要になるだろう。
よって、複数のコンテナをAPI経由のプログラムで一括管理したくなる。

そこで、コンテナオーケストレーションという概念で包括的に管理する。
絵で見てわかるマイクロサービスの仕組み」では、コンテナオーケストレーションを適用するユースケースとして、
・コンテナの作成とデプロイ
・負荷に応じたスケールアウトやスケールダウンやロードバランシング
・ホストやコンテナのヘルスチェック
があげられてたい。
つまり、動的にコンテナを作成しデプロイして、負荷に応じてスケールアウト・ダウンし、負荷分散させる。
また、コンテナのヘルスチェックのように、サーバー監視の管理サービスも実現してくれる。

コンテナオーケストレーションの実装例としてKubernetesがあげられている。
Kubernetesの優れた汎用的な機能のおかげで、AWSでもAzureでも一般的なクラウドにもコンテナ群をそのまま移行できる、という発想なのだろう。
コンテナの実装は、yamlやJasonなどでドメイン特化言語のように記載されて実現されるのだろう。
それゆえに、yamlなどのドメイン特化言語で、マイクロサービスのコンテナ群を全て実装すれば、検証環境であれ本番環境であれすぐにクラウド上に実装できるはず。

ではそれで全ての問題が解決するのか?
変化の早いビジネス環境において、マイクロサービスを組み合わせることで即座に稼働しやすいだろうが、複雑性は増すだろう。
数多くのコンテナを協調させながら稼働させるには、コンテナの中身を記載したyamlは相当複雑になるだろう。
一昔前に、Antでビルド&デプロイのタスクを書いていた時、宣言的に書いて楽だなと思っていたのに、環境が増えるごとにIF文がAntタスクに紛れ込んでどんどん複雑化したような経験を思い出す。
たぶん、それに似たような事象がKubernetesでも起きるのではないか、と思ったりする。

【6】3つ目は、サーバレスアプリケーションはBPMNのようなワークフローに並列処理を組み合わせたワークロードみたいなものではないか、と思う。

絵で見てわかるマイクロサービスの仕組み」では、サーバレスアプリケーションの基本アーキテクチャは、BaaSとFaaSの2種類があげられている。
BaaSは外部サードパーティのサービスを使うパターン。
FaaSはビジネスロジックをイベントドリブンで実装するパターン。

BaaSはたとえば、Googleアカウント認証やTwitter認証などの外部認証サービス、PayPalのような外部決済サービスがあげられるだろう。
外部サードパーティサービスの方がセキュリティ要件も性能要件もいいならば、そちらのサービスを利用することで、ユーザの利便性も増すだろう。
他方、ユーザ認証やクレジットカード情報を自社システムに持たないデメリットがあるので、顧客情報をより包括的に収集できないデメリットもあるだろう。

FaaSは、BPMNのようなワークフローに並列処理を組み合わせたワークフローに思える。
マイクロサービスをつないで、イベント駆動でマイクロサービスをキックし、一連の業務が流れる感じ。
その場合、並列処理で動くので、商品を購買している間に、検索したり、在庫に問い合わせたりして並列で動かすケースもあるだろう。

サーバーレスアプリケーションはFaaSを想起させる。
AWSならLambdaになるのだろう。
メリットは、アプリケーション開発者はアプリ層のマイクロサービスの実装だけに特化すれば良く、インフラ基盤は考えなくてもクラウド基盤がマネージドサービス等で勝手に管理してくれる、そういうイメージなのだろう。

他方、開発時のデバッグや障害時の復旧はかなり面倒になることが想像される。
複数のマイクロサービスを通したシステム全体テストをやるには、ローカルPCでは無理で、クラウド上に本番同等の検証環境が必要になるだろう。
その分コストも増える。
また、イベントドリブンで連なる一連のマイクロサービスのうち、途中のマイクロサービスで障害が発生して、データの同期が取れなくなった場合、データのロールバック処理は複雑になるだろう。
本来は、データ復旧や障害復旧もクラウド基盤が勝手に自動で上手くやって欲しいが、手作業で設計して入り組んだ複雑なワークフローになっていると難しいだろう。

そんなことを考えると、全てがバラ色の世界ではないだろうと思う。

【7】マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか?

違いの一つは、マイクロサービス設計では、インフラ基盤をクラウドのマネージドサービスで自動化したり、APIで監視サービスやコンテナオーケストレーションを実装できる点にあるだろう。

つまり、従来のオンプレ環境のインフラ基盤は、アプリ開発者の手によって操作できるようになった点が違いになるだろう。
アプリ層からインフラ層まで全て、アプリ開発者がコントロールできるようになったこと。
そんな開発者はフルスタックエンジニアと呼ばれるのだろう。
また、DevOpsとは、そういうフルスタックエンジニアがアプリ層からインフラ層までコントロールして、開発も運用も一体化するプロセスを指すのだろう。

| | コメント (0)

2023/12/24

チケットはデータでとプロセスの二面性を持つ #redmine

Redmineのチケットとは一体何だろうか?

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

その他にも、Redmineでは、課題チケットという一つのインシデントという情報(データ)として意味を持たせていたのに、課題を解決する対策の作業手順(プロセス)もチケットとして登録される、というケースがよくある。

つまり、チケットは、ナレッジとして蓄積されるデータのケースと、作業手順として進捗管理されてステータス管理されるプロセスのケースの2つの性質を持つ。

たとえば、課題、障害、問い合わせのようなインシデントは、都度発生したタイミングでチケット登録される。
それらチケットには、当初のインシデントの内容だけでなく、調査結果や作業ログ、解決策や再発防止策も記録される。
最終的には、解決策や再発防止策は、ナレッジとして蓄積される。

チケット管理システムが持つ検索機能によって、それらナレッジはいつでも取り出すことができる。
つまり、チケット管理システムはナレッジデータベースの側面も持つ。

一方、作業チケットは、何らかの目的に対していくつかの作業手順に分解されてチケット登録される。
一般には、親子チケットで管理されるだろう。
作業チケットは作業手順の一部であるから、作業の順序が重要になる。
チケット管理システムでは、作業の順序はガントチャートのような進捗管理機能として実現されているだろう。

つまり、チケット管理システムは、作業手順というプロセスを管理する仕組みが必要なので、必然的にチケットの先行後続関係を表現したり、クリティカルパスを表現したり、作業チケットのステータスを管理する機能が必要になる。
一般にチケット管理システムでは、進捗管理機能はチケット集計機能の一部として実現されるので、今までに知られているプロジェクト管理システムとして普遍化されるだろう。

そんなことを考えると、チケット管理システムでは、チケットはデータであったりプロセスだったりするし、ストック型プロセスで使われるときもあればフロー型プロセスで使われるときもある。

そういう二面性をあえてチケットに持たせることで、より柔軟にプロジェクト管理しやすくする仕組みを持たせているわけだ。


| | コメント (0)

2023/12/17

PMO観点でRedmineの使い方とは何だろうか

PMO観点でRedmineの使い方とは何だろうか。
以下は経験を元に、アイデアや妄想をラフなメモ書き。

【参考】
PMO観点でRedmineの使い方とは何か: プログラマの思索

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ! Madosan's View

PMOの役割は、プロジェクトマネージャのサポート役から、プロジェクト管理支援のための事務局、そして、最終的にはシステム監査やIT統制と連動してプロジェクトを第三者的に監査する立場まである。
そういうPMOの立場では、Redmineをどのように使いたいのか?

PMOとしては、プロジェクトが火だるまになる前に事前に状況をキャッチし、プロジェクトのQCDをコントロールできる状態で維持し続けたい。
結局、Redmineからリスクを早めに検知したい。
ではそのリスクはどこから現れるのか?

PMOはプロジェクトの受注段階からリリース完了まで関わることができる前提とする。
そうであれば、受注前のプロジェクト計画を精査して、そこからRedmineにどこまで詳細化できているか、が一つのポイント。
すぐに思いつくのは、スケジュールや工数の観点で、チケット化されているかどうか。

当初計画でどこまでタスクを詳細化してカバーできているか、WBSの粒度はどうなのか。
当初の要員計画からタスクがチケット化されて作業負荷も吟味されて現実的なスケジュールになっているか。
当初計画した工数やマスタスケジュールを元に、マイルストーン単位に無駄なくタスクが落とし込まれているか。

だが実際はすぐにチケット化されているわけではない。
マスタスケジュールのマイルストーン単位に区切られて、直近のマイルストーンまでのタスクを詳細化していくのが現実的だろう。
その単位でチケットに整合性があるのか。
また、Wikiに必要な情報が掲載されているか、も必要な観点だろう。

そして、プロジェクト実行フェーズでは、プロジェクトの活発度合いより不吉な匂いが出ていないか、が一つの目安になるだろう。
チケットの更新頻度、コメントに前兆がないか。
チケットが活発すぎているのか、忙しすぎて逆にチケットに反映漏れが出ていないか。

特に、チケットの種類ごとに内容を見ておきたい。
課題チケットで案件を妨害するような支障は出ていないか。
障害チケットに品質悪化を示す兆候はないか。

プロジェクト計画時点で、システムのアーキテクチャの課題、プロジェクトの目的となる解決した課題と機能要件の実現性、非機能要件のリスクは普通洗い出しているはず。
特に、レスポンス、スループット、ネットワーク通信などの非機能要件とか。
それを念頭に置いて、どこでリスクが出そうなのか、考えていくべき。
特に昨今は、スクラッチ開発よりも、パッケージ製品の導入やカスタマイズ、他社のSaaSや外部システムと連携するアーキテクチャが多いので、開発リスクは以前よりも大きいと感じる。
そういうリスクがチケットに現れていないか、も一つの観点になりうる。

案件の実行中に、定期的にふりかえりをやっていればいいが、実際は忙しくてそれどころではないだろう。
日々の開発の中で小さな課題を一つずつ潰していく。
その活動の履歴がチケットの更新履歴に出てくるはず。

チケットの消化度合い、消化速度、残チケット数も一つのポイント。
当初計画されたチケット枚数から、さらに課題や障害によりチケット枚数が増えたとしても、案件をコントロールできて入れば、チームが消化できる範囲内に収まるはず。
残りの期間とチームの消化速度(実際はベロシティのようなもの)から、バーンダウンチャートで着地点が見えるはず。
それがコントロールできない場合、チームは混乱しているだろう。
特にテスト工程では、障害チケットの解決をどこまでコントロールできるか、が鍵を握る。

PMOは第三者観点の役割なので、プロジェクトを実行するチームを支援するがチームと一体化しない。
第三者の立場で、気づきをフィードバックし、マイルストーンでの上役への報告を支援し、最後のリリースで出荷可能な品質なのか判断を下す。
だからPMOはプロジェクトから見ると余計なお世話の役割であり、嫌われやすい。
しかし、PMOがしっかりしているからこそ、プロジェクトの暴走を早めにキャッチして防ぐこともできる。
この辺りの駆け引きの中で仕事している感じ。

PMO観点でRedmineの使い方はもう少し色々考えてみたい。

| | コメント (0)

2023/12/10

「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみを読んだ。

【0】リモートワーク主体の組織運営をどうやってやるか、PDCAで整理した本と思う。
とは言っても、リモートワーク普及に奇策はない。

【1】Planでは、ガイドラインを定めて形式知化する。
リモート責任者など組織体制も整備する。
経営層が率先してリモートで働く。
利用するツールは絞り込む。

他にもいくつか施策はあるが、割りと形式知化を重視している点が印象に残った。
リモートだからこそ、対面でのやり取りがないので、どうしてもローコンテキストな対話にならざるを得ないだろうから。

コミュニケーションルールも定める。
非公開情報ではSAFEアプローチを取る。
Sensitiveなのか、Accurateなのか、Financialなのか、Effectなのか、の判断基準を定めて、情報を公開しても良いのか判断する。

【2】Doでは、従業員の動機づけ要因、衛生要因を整備する。
リモートに合った組織文化が根付くように実行する。
心理的安全性を重視する。
人材戦略、つまり従業員の動機づけ要因では、ダイバーシティ、インクルージョン、ビロンギングを重視する。

ダイバーシティは、人種や性別、年齢、宗教、性的指向などの多様性を認めること。
インクルージョンは、マイノリティもマジョリティもすべての従業員が活躍できる状態を目指すこと。
ビロンギングは、自分の居場所はここである、という感覚。
帰属意識みたいなものかな。
一昔前の日本の会社の愛社精神みたいなもの。
今風ならエンゲージメントかな。

面白い点は、ビロンギングを重視していること。
従業員の流動性が高くても、帰属意識を重視しているのはなぜか。
たぶん、マズローの欲求5段解説で考えれば、帰属欲求が満たさなければ、承認欲求や自己実現を満たす欲求に達しないからだろう。

他にも、イテレーション、透明性も重視している。
この辺りはアジャイル開発の文化に近いので理解しやすい。

コンディショニングを実現する章は衛生要因の話だろう。
長期休暇制度、人間関係の構築、運動の推奨。

【3】CheckとActoinでは、KPIを用いた評価制度を作り、イテレーションごとにフィードバックを回していく。

SMARTな目標を定めて成果を評価する。
GitLabで活躍できる能力や意欲があるのに、マネジメントの問題で活かしきれない状況を避けるために支援する。
マネージャはメンバーを支援する。

優れたマネージャのコンピテンシーは事前に把握しておく。
感情的知性(EQ)、コーチング、衝突の解決、フィードバック文化の体現、高業績チームの構築。

Actionでは、メンバーに精神的成長と技術的成長を促す。
技術的成長を促すには、現状のスキルレベルと目指すスキルレベルの可視化が不可欠。
しかし、日本企業はスキルマップが画一的だったりそもそもなかったり、メンバーのスキル保有を把握していない。

能力開発のプロセスでは、コルブの経験学習モデルが有効。
具体的経験→内省的観察→抽象的概念化→積極的実践のサイクルを回して、能力を高めていく。
日本と海外の差は、抽象的概念化と積極的実践の部分だろう。

抽象的概念化では、普通の業務では既に他の人や過去の人が既に実践しているから、ノウハウや問題解決の手順は既に知られている。
しかし日本ではわりと形式知化されていないので、一人で暗中模索して試行錯誤しながら解決策を導く手間がかかる。
海外では形式知化されたマニュアルや書籍、トレーニングが充実しており、それらを通じて先人が得た整理された知識まで早期に到達することができる。

積極的実践では、せっかく研修したのに、研修に対して意味がないと感じたりネガティブな印象を持ったりする。
座学の場合は特にそうだろう。
だから、研修を実務に適用し、研修転移を進めるために、マネージャや周囲が定期的にコミットメントしたりフィードバックするのが大事になる。
GitLabでは、個人開発計画を作成し、メンバーのキャリア開発について議論しているという。

【4】そんな話を読むと、GitLabではリモートワークを単に活用しているだけでなく、包括的にメンバーの意識付けからスキルアップまで組織的に考えていることが分かる。
おそらく長年の試行錯誤を経て、3000ページにのぼるGitLabのガイドラインにまとめられたのだろう。

また、この本では、既に知られているビジネスやマネジメントのフレームワークがふんだんに使われていて、情報が整理されて理解しやすいと感じた。


| | コメント (0)

«『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost