無邪気さからの脱却とは
私のこれまでのキャリアを踏まえた課題感（というには軽すぎる気もするが）は、事業会社で業務システムのエンジニアリングに携わる一部の人々に見られる エンジニアリングに対する無邪気さ からの脱却にあるということに気付いた。
この無邪気さとは、技術がもたらす長期的な影響に対する無頓着さ・無自覚さであり、その主たる要因は 構造的な学ぶ機会のなさ にあると考えている。
エンジニア全般からすれば、自らの時間を使って学びを深める人はそう多くない。
だが、技術を追及する組織では、業務時間を使って学ぶ機会が与えられることもあれば、自らのタスクを行うために学ばざるを得ない場面も少なくないだろう。
ところが、いわゆる「業務SE」と呼ばれるロールにおいては、業務部門の要求を要件に落とし込んだ後、その設計・実装を「開発チーム」に委ねてしまう ことが多いのではないだろうか。その後は、要件と機能のトレーサビリティは確認するものの、どのようにシステムが作られているかを確認する機会は持たない。
この体制（≒構造）では、業務SEは自ら手を動かして設計・実装する機会を得られないばかりか、業務システムの品質、特に「保守性」という将来のビジネスアジリティに対する当事者意識を持つ機会をも失う ことになりはしないか。
これこそが「構造的な学ぶ機会のなさ」であり、その当然の帰結として業務システムは偶有的な複雑性にまみれ、調査するにも改修するにも時間がかかるやっかいな業務システム になっていく。
その状況を前にしても業務SEは「複雑なんですよね」と他人事で語るかもしれない。
なぜなら、ソフトウェアエンジニアリングが何を目的とし、何を解決する専門性であるかを学ぶ機会を得られなかったから。あるいは、機会があっても気づきには至らなかったから。
こうした状況に対して我々が問うべきは、事業会社の業務システムエンジニアが持つべきプロフェッショナリズムとは何か であり、その問いによって、学習習慣が身に付いていない人たち、あるいは自らが負った負債に無責任な人たち、いわば「無邪気な人たち」が気づきを得て、その行動を変容させることこそが必要 なのではないか。
この課題に対して必要なのは、必ずしも卓越した技能ではない。
業務SE個々人が、担当するシステムの品質に責任を持つべきは自身であることに気づき、品質とは何かを学び、より良い構造と現実解とのギャップを負債と認知し、負うべきとそうでないものを見分け、戦略的に負債を負うことで、ビジネス価値提供にレバレッジを掛けられる状況に至ろうとするマインドセットだ。
そしてこのマインドセットを実践に移すためには、現場の要求と事業戦略との間にある 意味の構造を把握 し、理想と現実のギャップをチーム共通のメンタルモデルとする ケイパビリティ、つまりモデリングこそが重要な構成要素となるだろう。