本稿では、2022年12月現在において現在進行系で取り組んでいる
人事給与システムの公共機関向け共済サブシステムにおける
共済短期拡大の法改正対応での「エフェクチュエーション」の活用についてシェアする。
※ 共済：公共機関における社会保険のこと
筆者紹介
筆者は、新卒10年目のアプリエンジニアである。
配属後は、社会保険サブシステム、共済サブシステムといった
法定サブシステムの機能企画・機能開発を中心に、
複数の大規模な法改正対応に開発者として関わってきた。
こういった法改正対応への経験を積んだ開発者が、
共済短期拡大の法改正対応を効果的に行おうと模索して出会った
「エフェクチュエーション」を活用した事例について以下で語る。
「エフェクチュエーション」とは
「エフェクチュエーション」とは、起業家の行動特性から発見された、
不確実な状況下で、手持ちの手段から意味のある結果を
生み出すメカニズムを示した理論である。
この「エフェクチュエーション」の実践は、ざっくりというと
5つの原則、すなわち、
- 手中の鳥（手持ちの手段でやりましょう）
- 許容可能な損失（許容可能な損失の範囲内でやりましょう）
- クレイジーキルト（仲間をつくりましょう）
- レモネード（偶然をテコにしましょう）
- 飛行機のパイロット（コントロール可能な活動に集中しましょう）
の原則を意識して行動しよう、というものである。
「エフェクチュエーション」を詳しく知りたい場合は、
以下解説が優れているので、参考にしてもらいたい。
法改正対応は不確実性の乗りこなしがカギ
法改正対応とは、法改正によって生まれる新しい業務に、
法施行日にあわせてシステムで実施できるようにすることである。
読者によっては、法改正対応は、法に書いてある内容をシステムに落とし込むだけと思うかもしれない。
しかし、
- 施行日後の初業務タイミングまでには、「何らかの形」で、
システムで業務をできるようにする必要がある。 - 法改正後の新しい業務がどうなるかは、誰も答えをもっていない。
ユーザーに聞いてわかるものではない。 - 業務のシステム化は、運用指針やシステム連携仕様よりも高い解像度が必要である。
しかし、運用指針やシステム連携仕様でさえも法改正数ヶ月前に発表されていたらいい方で、
法改正直前に決まることすらある。 - 運用指針やシステム連携仕様が、法改正後に変わることも時々ある。
と、施行日後の初業務タイミングにシステムを稼働させるには、
不確実性をいかに乗りこなすかがキーとなる。
以下では、この「エフェクチュエーション」の原則をもとに、
不確実性をいかに乗りこなそうとしたかを示す。
手中の鳥：まずは手持ちの業務要件の高い解像度をテコに仮説立て
共済短期拡大の法改正対応に挑むときに第一に取り組んだのは、
すなわち手持ちでわかっている業務要件から法改正後にどう変わるかの仮説を立てることである。
業務のシステム化に必要な解像度を得られるのを待って機能開発をしたら、
施行日後の初業務タイミングにシステムを稼働させることは到底実現できない。
そのため、まずは「法改正内容」という粗い解像度の情報を、
「手持ちでわかっている既存業務要件」という高い解像度の情報を組み合わせ、
システム化できる水準の高い解像度で、「法改正後のシステム業務像(仮)」を描き切ることをした。
クレイジーキルト：社内コンサルタントを仲間にして仮説の確度上げ
仮説を立てた後は、社内コンサルタントを仲間に巻き込むことに取り組んだ。
共済組合の運用指針やシステム連携仕様は、
お客さまから情報提供いただいてはじめて入手できる。
このお客さまの情報提供を引き出すには、お客さまと日々やりとりをする
社内コンサルタントの協力が不可欠となる。
この社内コンサルタントの協力を借りることができたら、
- 共済組合の運用指針やシステム連携仕様の情報提供依頼
- お客さまの先にいる共済組合への疑義照会依頼
をし、得た資料・回答をもとに「法改正後のシステム業務像(仮)」の答え合わせを何度も何度も行い、
「法改正後のシステム業務像」の確度をシステム開発に耐えられる水準に高めていった。
飛行機のパイロット：コントロールできないポイントは深追いしない
社内コンサルタントの協力により、法改正後のシステム業務像の確度をあげ、
その業務像をもとにシステム設計を進めていったが、
一時期システム設計の進捗がスローダウンした時期があった。
この原因は、未決定のシステム連携仕様のシステム設計をどうするかを、
起こりうるパターンすべてについて検討していたためであった。
そのパターンには、設計をかなり工夫しないと実現できないパターンが含まれており、
その工夫についてもあれこれと思索していた。
つまり、コントロールできないポイントまで深追いしていたのであった。
この深追いに気づいた後、
- 確度が高い要件は、優先的に設計する。
- 確度が低い要件は、許容可能な代替運用手段が取れるのであれば、
深追いせず、業務確度があがるまで保留する。
と確度が高い要件に集中するようにし、システム設計の進捗をあげることができた。
許容可能な損失：「負担可能な損失」を出し合う
仲間に巻き込んだ社内コンサルタントとは、最初は情報提供中心での協力関係であったが、
システム開発が評価検証段階に進んだ段階になると、
どう法改正後のシステムを複数の団体に一斉導入するかを議論する関係へと深化した。
というのも、「法改正後のシステム業務像(仮)」の仮説検証の結果、
法改正対応のために設定の大規模変更が必要であることがわかり、
ユーザーの設定の大規模変更をリードするにも社内コンサルタントの力を借りることも
不可欠となることもわかってきたからである。
このことから、共済短期拡大の法改正対応への問題意識が高いメンバーを中心に、
仮説検証してきた「法改正後のシステム業務像」をたたき台に、
どう設定の大規模変更をするのか、議論してきた。
この議論の結果、設定変更の方針がある程度固まったので、
複数の団体に一斉に伝えるために設定手順書を書く段階になった。
しかし、この段階時点では私自身が開発案件から手を離せない状況であった。
このため、設定手順書を書くのに工数を費やすことは、
開発中の案件を最悪出荷できない状況を招くため、許容可能な損失を超過していた。
この状況は、社内コンサルタントの一人が果敢にも手を挙げ、
開発内デモの資料・動画をもとに設定手順書を書き上げたことにより、打破された。
私自身も、設定手順書のレビューという許容可能な損失の範囲で
この果敢なる社内コンサルタントの設定手順書作成を支援した。
この結果、複数の団体での一斉利用に耐えうる設定手順書をお客さまに届けることができ、
法改正後のシステム業務の構築活動を推進することができた。
レモネード：「異変」を拾い上げ、軌道修正
社内コンサルタントを仲間に巻き込み、法改正後のシステム業務像の確度を高め、
法改正対応モジュールをつくりあげ、ユーザーに届けた後は、
「異変」の拾い上げに注視した。
「異変」というのは、例えば、未知の運用指針にもとづいて
「どうやったらできるのか」を模索していている状況を指す。
こういった「異変」は、現場コンサルタントが気づかずにいることがしばしばあるため、
拾い上げないと検知できず、検知のタイミングによっては手遅れになることもある。
この拾い上げのために、社内コンサルタントのSlackでの業務やりとりをつぶさに観察し、
「異変」を感じたら、背後にある運用指針の情報提供を即座に依頼してきた。
確度が高い運用指針を入手できたら、
その指針をもとに「法改正後のシステム業務像」を軌道修正し、
反復性の高い指針であればプログラムを追加修正してきた。
この結果、「異変」を法改正対応の精度向上のテコとすることができた。
まとめ
本稿では、筆者が現在進行系で取り組んでいる共済短期拡大の法改正対応という
不確実性をうまく乗りこなすことが求められる活動を題材に、
エフェクチュエーションの原則をどう活かして不確実性をコントロールし、
よき成果を生み出そうとしていくかを示した。
筆者自身ももっとよき不確実性の海の乗りこなし方を日々模索する身ではあるものも、
本稿が不確実性と立ち向かいながらシステム開発をするヒトのヒントになれば幸いである。