技術的制約と文化的制約

前置き

ここでいう制約とは、TOC(制約理論)で言われている
物理制約・市場制約・方針制約とはちょっとだけ意味合いを変えて呼んでいる。

また、UAFのConstrainsには、自分たちでコントロールできる制約を定義するが、
その際に大事な思考プロセスとしてTOC思考プロセスが必須になってくる。

またDDDモデリングは、前提のスコープをイテレーションを回し終えた際に、
そもそもの前提のスコープはそれでよかったのか？を検討する。
前提のスコープを調整した際には、そのスコープでの新しい制約が必要となるため、

DDDとTOCはセットで使う

というのが私の考えである。

まずは簡単に上記の３種類の制約について触れる。

制約理論に出てくる３種類の制約

物理制約

物理的(ハード)な制約であり、設備や人的リソースの能力不足によって

生産能力　＜　市場からの要求

となっている状態。

たとえば、外部環境からは素早いデリバリーを求められているのにもかかわらず、
組織内のスキル不足によってそれができていないという時の制約である。

メリット

この制約自体を認知することが容易なのでとっかかりやすい。
それによって自分たちのスキルアップなどを通し容易に取っ払うことが可能。

デメリット

当初考えていた能力値の発揮できないことが当たり前

連携上のトラブルや遅延、設備や体調不良という人的リソースの故障によって、
理論上で考えた能力値を100%叩き出すなんてことは実際の本番環境では無理。

この物理制約を取っ払った所で根本原因の解決にはなかなかならない

理由は、この物理制約を生み出す根本理由が【方針制約】(文化)であることが大半だから。

物理制約の改善を継続的にやっていく中で、根本原因を生み出す方針制約を仮説ベースで見つけるというのが現実的。

市場制約

顧客や業界そのものという企業の外にある制約であり、自社ではコントロール不能なもの。

生産能力　＞　市場からの要求

となっている状態。
つまり無駄に作りすぎてしまっているがゆえに在庫などが発生してしまっている。

たとえばITの開発現場で言えば、不要な機能の開発などがこれに該当する。
そしてその不要なもののメンテにまたコストがかかってしまうなんて現象。

この市場制約も物理制約と同様に、【方針制約】が根本原因であることが多い。

方針制約

組織の中で定められたルールや慣習(文化)による制約。

たとえば昔は正しかったガバナンスやポリシー、評価制度がそのままでメンテされていないことによって、現在の行動などが抑制されたり、パフォーマンスが悪化している状況。

個人的には、ここがDXと名前だけがついて全くDXではない組織が認知できていない制約であると感じる。

また失敗の本質という書籍などでも語られているように、
日本が戦争で負けまくった理由は、物理制約ばかりを無くそうとし続けてしまい。
肝心なこの【前提のルールを変える】という思考がないことだとすら叫ばれている。

事例

コンテキストの境界位置や、他のコンテキストとのインタラクションモードが更新されたにもかかわらず、評価制度はなぜか以前のままとか。
境界の位置がずっと固定化されたままで、アクセス権限も以前のままとか。

背景が不透明で以前までのルールであるにもかかわらず、
「それが決まりだから」と思考停止して、ずっとそのままそのルールに縛られて素早いデリバリーができなくなっているとか。

メリット

ここをDDDモデリングなどを使い可視化して取っ払っていくことで、
その組織にとって絶大なインパクト、イノベーションが実現しやすい。

※　個人的には、DDDモデリングをせっかくするのなら、この方針制約を発見しなくてはせっかくのモデリングコストが勿体ないと感じています。

既存のあまりハード的には優秀とは言えない設備や人的リソースしかなくても、
ルール含めた概念上の仕組みを作ることで優位に立ちやすい。

デメリット

企業に蔓延した風土や歴史といった、その空間に【常識】として存在するため、
そもそも制約として認知するのが困難。
※　だからこそ6W2Hとかに分けたり、イベントストーミングといったモデリング手法で認知しやすくするのが大事。

組織の風土とかに起因するがために、組織内の反対勢力の人々などによって３種類の制約の中でもっとも取っ払うのが困難。

たとえば職能別に切り分けられた組織で、
その職能で個別最適を追えば評価されるという評価制度から、
全体最適になるような振る舞いをした者が評価されるといったように制度を変えようとしたら、そりゃ反発が来ますよね。

アジャイル文化の進まない現象

また、アジャイルプロセスに適用できない組織でも同様のメカニズムです。
単なる反復型でないアジャイルでは、１回イテレーションを回し終えたら、
その中での発見などをもとに、前提スコープの調整を行います、

スコープの調整を行うということは、前回までのスプリント期間中の常識は、
今のスプリント期間中でも適用されるとは限らないということ。
これに対応できないとアジャイルが浸透しているとは言えないです。

アジャイルで進めたい、でもルールを変えたくないという案件に遭遇したことがありますが、どっちかしかありえません。
これは集団でも個人でも言えることではないでしょうか？
素早く環境に合わせて変化するためには、我々の常識や価値観を変えるしかありません。

そのためにモデリングなどを通して、自分たちの置いている前提スコープを可視化し、
ラテラル思考などと組み合わせて　より良いスコープに再調整したら、
その範囲での文化に価値観をアップデートし続けなくてはいけません。

DDDモデリング　で可視化
ラテラル思考　で前提範囲の再調整
制約理論を使って方針制約を１つずつ打破

このようにすべてを組み合わせて用いることで、
アジャイル文化が浸透していると言えて、イノベーションが起こりやすくなると感じています。

それでは次に制約の中で変数扱いが可能なものとそうでないものとに分けて考える思考について触れていく。

変数扱いできる制約と定数の制約

制約には大きく分けて２種類ある。
自分たちの組織内の制約と、その外側にある法律などといった制約である。

前者は自分たちで何とかコントロールできる【変数】である。
しかし後者は外部を巻き込んでじゃないと変更できない自分達ではコントロールできない【定数】である。
わたしがUAFを使用する際には、Constrains(制約列)には　前者しか定義しないようにしている。なぜなら変数と定数を明確に分離をしたいからである。

定数にいくらコストをかけたところで不確実性は高く無駄に終わるので、
もっとも費用対効果の高いと思われる変数であるConstrainにのみ選択集中するのである。

模式図でいうと丁度以下のようなイメージである。

さらにいうと、この変数扱いできる制約には、２種類のものがある。
大きく分けて、技術的制約と文化的制約である。

技術的制約

１つは技術的な制約。既存の技術だけでは難しいという制約条件。
もしも法律上無理とかではない、自分たちがその制約を取っ払えるような
新規技術を開発さえできれば、障壁となる制約を無くせる　という意味での制約。
技術戦略はまさにこれをWhyとして考えられている。

この制約条件を１度の開発で取っ払えない場合には、
ちょっとずつ開発しながらどう制約を取り除くか？
という何通りかある戦略的なロードマップを作成する。
それがどんな技術を開発すべきなのか？という道しるべとなる。

開発者たちがおもに注目しがちなのは、どっちかというとこの技術的制約の方であると感じている。
しかしながら、開発は基本的に環境負荷をかけてしまう。
環境負荷を最小限にしつつ、より便利な環境にするためには、この技術的制約だけしか考えないのはアンチパターンであると感じる。

具体例

システムの性能を磨く

パフォーマンスが足りていないとかいう場合に、より素早さを発揮できるようにするケース

新しいシステムを開発する

非機能面などで古いシステムでは対処できない場合に、再度１からシステム構築するケース

ヒトを教育する

ある意味１つ目のシステムの性能を磨くと同一とも言えますが、
新人さんとかでスキルが足りない場合なんかに、育成でどうにかしようとするケース

環境リスク緩和

昨今のプロダクトに求められている利用者視点の品質副特性である。
企業によっては、使用電力量や水の使用量などまでホームページに載せている。

人間の活動によって排出される温室効果ガスの割合は以下のようになっている。
ものを開発しまくったことで、一気に温室効果ガスが増える過程の動画もあったので、
興味ある方はそちらも参照ください。

活動内容	排出される温室効果ガスの量
ものを開発する	31%
電気を使用する	27%
ものを育てる	19%
移動する	16%
冷やしたり温めたる	7%

ちなみにある案件で、炭素排出量削減というものが目的の１つとして掲げられていたものの、情報システムを開発するのが目的となっていて、ちょこっとだけ省エネアプリを導入されていたビジネスがあった。
省エネアプリで削減できるのは、上の表を見ればわずかであることは自明である。

対して、ボトルネックである開発しない選択肢を選べば30％以上も削減可能。

すなわち、地球の将来への社会的なインパクトとして「環境問題にもメスを入れていますよ」とアピールしたければ、

開発を最小限にし、仕組みをつくることで快適さを手に入れる。

ことを考えなくてはいけない。
そこで次の文化的制約の必要性が出てくる。

文化的制約

２つ目に文化的制約。これは正式名称として上記の方針制約そのものである。

正直いってDXが進まないですとか、技術的負債が一向になくならずに再発しまくるのはこれが要因であると確信しています。
またなんだかんだいってここがもっとも難易度高いと感じます。
それゆえに技術的制約を取っ払う方が、思考的にもストレスないなどの理由で技術的制約を排除する選択肢が選ばれがちな印象を受けます。

結論から話すと、この制約は単なるシステムを開発するということでは、
【絶対に】取っ払うことができません。

そして、技術的負債に立ち向かう勇敢な技術者たちは、
確かに様々な著名人の影響もあって、昨今増えてきていると感じますが、
どんなに技術的負債を解消しても根本の解決にはなりません、

理由は、

【文化的負債】　が原因となって、技術的負債が起こるから

です。

上の市場制約とか方針制約を見てもらえればお分かりかと思います。
方針制約である文化的負債に向き合うことなく、技術負債の解消やイノベーションは絶対に不可能です。

ルールを変えてはいけないという固定観念

与えられた前提の枠の中で統制を取られた言動をするのが得意なのは日本人の特性らしい。

でもその与えられた前提の枠である【常識】に対して、疑問を抱く人は少ない。
それは私たちが昔の学校教育とか集団行動の中で、「みんなと同じ」であることを強制、
刷り込まれているからではないでしょうか？

「それがルールなんだから守らないとダメ」確かにそうですね。
でもちょっと考えてみてください。
そのルールができた背景を理解することなく、頭でっかちにルールを守ることが目的になっていませんか？

【一度定義したルールを変えてはいけないルール】なんてどこに存在しますか？
同じです。
私たちは学校生活だけでなく、社会人になった後も、

【ルールは自分なんかが変えてはいけないもの】

というバイアスに縛られてしまっています。これが脱皮するのに一番の足かせなのに。

集団がつくる文化【常識】

自分たちが集団で行動しているうちに無意識のうちに風土を作り出す。

たとえばテストをしない文化の人々の空間では、「テストとか考えなくていいから！」
というスタンスの人々で形成されているであろう。
その人々によって
「テストなんてなくていい。非機能面なんて考えなくていい。」という文化が蔓延してしまい、それによって新しくそこに入ってくる人もその文化に染まってしまい、という負の循環に陥ります。

その文化に対して「おかしいですよ」という者。特に何色にも染まっていない人がそんなことを言うようものなら叩かれたりもします。

そしてその者は泣く泣くその文化に染まるしかなくなり、いつの間にかその人自身も新しく来る【変革のキーとなり得る】人に対して、その古き今となっては悪しき文化を強要するようになる。

この悪しき文化にテコ入れをすることなく、技術の開発だけしていても【絶対に】DXなんて実現できないとわかっていても。
(それでもその悪しき文化に染まらないという選択をする人は、かなりズレた人です。ちなみに私もそのうちの１人ですwww。)

こんな現象は皆さんも一度は体験したことあるのでは？

環境負荷軽減などが徐々にサービス品質として義務付けられてくるであろう昨今で、
モノを開発すること前提なのは超危ない思想である。
極力技術を開発することなく、既存のリソース(モノ・ヒト)で目的を実現するためには、
どんなバイアスを取っ払えばいいか？を継続的に考える必要がある。

制約に合わせてアーキテクチャを調整

先程の人の育成という事例。
あれは言ってしまえば物理制約であり技術制約と捉えた上での改善内容でしたね。

でも本当にそれしか選択肢はないのでしょうか？
スキル不足だと人は「育成」という選択肢だけでどうにかしようとしていないでしょうか？
その育成が逆にその人の尖った部分を削ぎ落していることにも気づかずに。

それなのに「最近の若いもんは自分で考えようとしない」？
え？　当たり前よね？
だってそう言っている人自身が、目の前の可能性を秘めた人の強みを
表面上の【育成】という合っていない戦術によって削ぎ落しているんだから。

「なんでシステムのトレードオフ分析は行うのに、人が育つという環境づくりのトレードオフ考察はしないの？」って思いませんか？

育成以外の選択肢を考えた上で、それでも全体的なコストを考えると育成の方がより良い解決策であると比較検討しましたか？と問いたいです。

私の最大の主張

QAは文化に対しても行うべきもの

大きな組織だとしても、衰えを知らない組織は数少なくても存在します。
私の認知する限りのその数社に共通してみられる特性として、
行動指針やLeadership Principlesなどのその企業の大切にしている方針、
つまりは【文化】に対しても、システムアーキテクチャのメンテように運用されている。
という特徴がありました。

ある組織では、Leadership Principlesをそれぞれ完全に粒度を揃え、
関心の分離などの設計思想を間違いなくこの文化にも適用していると思えるほどでした。
各プリンシプルが単一の目的になるように切り分けられていたのです。

それぞれの独立した行動指針、それらが集合となり、その組織全体の文化を形成している。
その時に行動指針AとBが、
・ほぼ毎回同じタイミングで変更されたり
あるいは
・何年たっても毎回両方まとまって再利用され続けたり

といった特徴があるのなら、行動指針AとBはむしろ分けず１つにまとめてしまった方がいいかもしれない。

こんな風にSOLID原則やコンポーネント原則を文化にも適用することで、
さらに文化を低コストでメンテしやすくすることが大事だと案件でも痛感しました。

ただ１つちょっと悔しいのは、この文化に対してメンテ性といった品質の考え方を適用しようなんて考え付いたのは、私が最初だ！　これが芸術だー！って心の中で騒いでた思っていた矢先に、AWSとかのLeadership Principlesを見た際には、Ω＼ζ°)ﾁｰﾝとなりました(苦笑

コンテキスト図はスナップショット

一度描いたコンテキスト図は単なるその時点でのスナップショットに過ぎない。
ただし、短いスプリントを回している最中にスコープ調整(要件の追加など)をしてしまうと
複雑化してしまうために、「その期間内においてはこの境界と仮定して進める」という
仮説ベースで演繹的に進めるというものがスクラムプロセスになる。

たとえばドメインモデル図を描く際に、いきなり全体を描くのではなく、
まずは全体を俯瞰したコンテキストマップを描く。
その際に「ここがマクロな境界であろう。なぜなら～」と仮説ベースで境界を引く。

その境界内で概念モデリングを進めていくことになるが、
その際に必ず意識したいのは

さっき引いた前提の境界の位置は今の時点での仮定に過ぎない。
今から行うモデリング活動(実験)の中で判明したことを判断材料として、
前提の境界の枠が変わるのか？　それとも変えなくていいのか？
境界の向こうと共に検証しなくてはいけない。

ということ。
もしもその検証で境界の向こうと同じ概念のモノが発見されたら、
直ちに前提の境界位置を修正する。

逆に同じ境界内であろうと思っていた概念が実はそうではないということが判明したりもする。
それはユビキタス言語を決めている最中に定性的に明らかになる。

ドメインエキスパート「その概念の名前は○○です。なぜなら～～」
開発者「いえいえ、～～という理由で▽▽です。」
といった感じに、命名の背景を述べて議論しても名前が全然そろわないような概念は、
同じ境界内にある構成要素と思っていたけども、実は違う境界内の概念である可能性が高いです。
それも検証時に仮定で置いた境界の向こうのチームとすぐに共有することで、
大幅な手戻りや概念の重複といったことを防ぐことにも繋がります。

技術制約と文化制約どちらも扱えるようにする

常に文化的制約を取っ払えばいいというものでもない。
その組織のカラーが、環境リスク緩和に貢献するスタイルではないのなら別に開発をするのでもいい。

戦略的に技術的制約、文化的制約、どちらを取っ払う方が、より費用対効果が大きいかで判断する。
理論に従えば、文化的制約が技術制約を生み出していると言えるかもしれないが、
いきなり根本の文化的制約を取っ払うことがどうしても困難な時には、
一旦、物理制約である技術的制約を取っ払う方向性も検討してみる。

キーは文化的制約

技術的制約は開発するのが好きな人々など大衆にとって、【つくっている】という実感を得られるので、手っ取り早く取り掛かれる制約である。

しかしながら、モノに溢れかえっている状況では、最良な選択をするのに時間がかかる。
どんなにリソースが豊富でなくても、目的を達成したいという時にはやはり文化を変えるしかない。

そのバイアスを視える化するためにモデリングで自分たちのバイアスを可視化する手助けをしていることになる。

よって、これは個人の主観にはなるが、
DDDと制約理論は必ずセットで使うのが、アジャイル改善には必須である。