金融決済システム、モード1保守における”アジャイル”的組織論の実践

筆者は金融決済システムの保守開発、すなわちホスト系モード1ビジネスの真っ只中に18年身を置いている者です。

モード1ビジネスの保守については、今後も「安定稼働最優先」という御旗を降ろすことはありません。とはいえお客様のいわゆるアジャイルへの関心については、無視できないものとなっています。
しかしスピード化の”犠牲”となって安定稼働が疎かになるのは本末転倒。でもこのままだと、現在のスタイルに古さ感じて、お客様に愛想をつかされるかもしれない。。

そんなループ思考に陥っていたときに、筆者はある方向性で進めてみることにしました。
「ハード面・フロー面など時間がかかる外的変化を待つのではなく、まず自分達が変化して備えよう」

アジャイルソフトウェア開発は、「アジャイルソフトウェア開発宣言（Manifesto for Agile Software Development：アジャイルマニフェスト）」^（※1）という文書が公開されてから、世界中のソフトウェア開発者達に支持され世の中に広まっていきました。
※1：従来型のソフトウェア開発のやり方とは異なる手法を実践していた17名の開発者が議論を行い2001年に公開されたもの

以下に引用する『アジャイルソフトウェア開発宣言』『アジャイル宣言の背後にある原則』の内容からわかるようにアジャイルとは単なる手法論ではなく、”在り方”だといわれています。

まず、『アジャイルソフトウェア開発宣言』の以下の一文についてですが、現在進行形で記載されているという点から、アジャイルは現状でも発展中であることを強く示唆しています。
「私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。」

次に、『アジャイル宣言の背後にある原則』を眺め見ると、以下分類ができます。

以下の図は、モード1・モード2の一般認識を端的に表現しているものになります。

筆者が長年従事しているビジネス「SoR＆モード1保守」は、ウォーターフォール型ビジネスが適しているという状況です。ここについてモード2に移行・変更するということは、難しい状況にあります。理由は繰り返しになりますが、「安定稼働最優先」としているからです。
その結果、現在安定稼働しているシステムにおいて、手法としてのアジャイル型に簡単に移行できないというのが定説です。

では我々モード１保守は、全くアジャイル化できないということでしょうか？
筆者そんなことはないと考えていました。先章でも触れたとおり、アジャイル宣言は成果物の変革だけではありません。その点にフォーカスしていけば、ウォーターフォールとアジャイルは二項対立ではなく共存できる考え方と捉えられます。

著者の経験した10年以上前の話になります。
チーム内3業務うちのひとつのリーダーになった当初、筆者はある違和感を感じて仕事をしていました。それは、慢性的に各業務チーム間の残業時間に差がある状態だったことです。
極端な日だと、同チームでありながら同日の退社時刻が「定時の人」と「23時の人」がいるような状態でした。理由はいくつかあり、主にスキルマッチの問題・担当業務の季節性やピークの影響だったと思っています。

誤解のないように触れておくと、筆者は業務に対して「必要な時は徹底的にやる、それ以外の時は帰る」という考えの持ち主です。よってある一日を切り取ればメリハリのある正しい姿だと考えています。ただ慢性的に業務量に差がついている状態であり、その理由に「ユーティリティプレイヤー不在」があるのであれば、これは組織が解決すべき大きな中長期課題だと考えました。

ただ「ユーティリティプレイヤー」の存在が不可欠といっても、いきなり誕生するわけではなく、筆者は以下流れでチームの下地を変えていきたいと考えました。

• ステップ1：自分の状況を理解

• ステップ2：他人の状況を理解して興味を抱く

• ステップ3：他人の業務を理解

• ゴール：ユーティリティプレイヤーが生まれる土壌を造成する

そんな観点で、2013年からチームで「日次の集合会議⇒朝会」の開催を決めました。

時系列が前後していますが、5年ほど前から”アジャイル”を意識するなかで・・・筆者が実施していることは「視点<1>チーム」の整備であることに気づきました。

ここからは実践したことをもとに掻い摘んで記述します。

■朝会開催ルール
シンプルに以下3点としています。
（１）すべてに優先して始業直後に業務チーム単位で集合（・・・我々はオンサイトです！）
（２）主催者は業務リーダーで時間は10分程度を目標とし、スタンディングで開催
（３）各人が「実績・予定・課題」を声出して伝える（資料更新）

■目的
開始当初からメンバーに対して、以下目的を割と口酸っぱく伝えています。
（１）進捗共有（実績報告と本日予定の宣言）
（２）課題共有（現状の課題の報告）
（３）他メンバーの状況把握

注意点
メンバーもリーダーも”兆候”を意識すること
予定実績の乖離が生じた場合は必要に応じてリーダーが各所調整するが、前提としてメンバーが兆候を報告していることが原則となります。
前日までに兆候がなく遅延が発生した場合、報告内容のレベルアップは要求します。

■見えてきた変化
（１）毎日予定と実績を口にすることで、予実乖離が大きくなる前に調整ができるので、進捗が安定してきた。
　⇒メンバー自ら予実の乖離を体感する中で、予定の立て方のスキルがアップした。
（２）課題を一人ではなくチームとして受け止め、チームとして解決に進めるので、課題解消のスピードが向上した。
（３）リーダーとのコミュニケーションだけではなく、メンバー間のコミュニケーションが増えた。

筆者の置かれているウォータフォール型業務環境では、もちろんPDCAサイクルをベースに作業しています。そして殊更大切なのが”予算に関わる”「Plan（計画or方針）」であり、この重要度は今後も変化しないと考えます。
ではどこでループ的な考え方を取り込める余地があるのか・・・

以前流行った鬼速PDCAに近い内容ですが、”P”はそのままに”DCA”の部分をループさせるイメージになります。そのループによって、現状を評価＆判断し続けることにより、より精緻なレベルアップを可能にしたいということになります。
結果として、視点<4>お客様②要求変更受付時期に関してどこまで後ろに倒せるか、という部分にも寄与できると考えます。ただし予算・納期を固定する前提なので、制約はあります。

• 制約１：納期や予算への影響が発生する可能性が高い「テストフェーズ以降」では適用しにくい
• 制約２：納期や予算に影響が出る場合に、お客様に相談できる関係・環境にあること

要件定義～外部設計フェーズならばお客様要望をできるだけ後期まで受付けて、レベルアップして取り込むことが可能になるかもしれないと考えています。
そして実現するうえで中核となるのが、チームの「自己組織化」「”改善プロセスのスピード」だと考えています。特に目的や進む方向を共有している「自己組織化」については、結果的に品質担保という面でも大きいと考えます。

かなり当たり前の話で拍子抜けかもしれませんが、つらつらとまとめさせていただきました。
この文書を書いている際に感じたことアジャイルとはこういうものだ！と形を決めてしまうと、ハード面やツール面が先に見えるため手を出しにくく感じます。
しかし身近な改善や課題解決の方法として、アジャイル的な発想を一部取り入れることはさほど難しいことではないかもしれません。

今回「4.偶然のアジャイル」の考察にて記載した課題は、現実的には大きい話ですが、実践したからこそある程度解決の糸口は見えています。
時間がかかるという部分はある程度やむを得ないですが、開始時に目的と手法を整理して挑めば時間短縮は可能です。
また要員の固定化については、組織が良化している状態であれば、新人の育成面でも成果は出やすいのも確かです。現状の中で新人育成に挑戦するのもありだと思います。

モード1保守において、オールアジャイル化するのは厳しいですが、分類してしまえば印象ほど高い壁ではないと思います。
二の足を踏むより、とりあえず弱い一手でも繰り出して進んでみるのもありなのでは、と筆者は感じています。そしてその道程の評価として、自分たちがアジャイル的発想を持てているか、ということも一つの材料になってもよいと思います。

フローに回されるだけではなく、自分たちが意思を持って回転できる、そんなシステム屋集団を整備して、今後も胸を張ってモード1保守を進めていこうと思っています。