第1回　SHIFTユーザー会開催レポート　＜後編＞

＜後編＞
サイロ化された組織、開発体制が生み出すもの
複雑化する障害の発生原因と障害スパイクの抑止課題

＜前編＞はこちらから
各社の取り組みやSHIFTとの関わり方
情報システムの課題、SHIFTへの期待と改善要望
システム老朽化や障害の再発防止に対する取り組み

大規模なシステムや組織であればあるほど、開発体制が複雑化。サイロ化された領域に外部ベンダーが加わることによる課題やコスト効率など、プロジェクト推進におけるさまざまな議論になりました。

「当社ではシステム開発所管が、3部署に分かれており、領域ごとに開発体制が置かれ、サイロ化してしまう現状課題があります。
複数の領域にまたがるプロジェクトを推進しようとすると、横連携でポテンヒットが発生してしまうことがあり、このサイロをどうやって解消していくかが一つの課題です。それぞれの領域で、サイロの上流工程から下流工程まで一貫して同一の委託先にお願いするというケースが『ベンダーロックイン』の原因を生み、コスト効率が非常に悪くなっています。金融機関におけるITコストは経営コストのなかでかなりウェイトが大きいので、コスト効率の向上が経営課題として非常に重いミッションになっています。
SHIFT社への期待は、このサイロ解消や、ベンダーロックインからの脱却です。今まで上流工程から下流工程まで縦に構築されているサイロを、テスト工程で横断的に対応していただくといった、サイロを横串に刺していく部分は、今まさにSHIFT社から提案いただいています。システムテスト要員をプール化して、必要なところに必要な人材を供給していく形で、テストのコスト効率を検討していきたいと思っております。
すべてのサイロがつねに均一に100%の仕事があるわけではありません。人が足りないサイロは、コストを追加して人を足さなければなりません。余力があるサイロは、遊ばせておくのがもったいないので、何か仕事をつくらなければなりませんが、柔軟に人を入れ替えるのは簡単ではありません。これまで常識的に進めてきたシステム開発や開発体制の構築を、横串を突破口にして、少しずつ効率的な形に変革できたらと考えております」

「弊社も各領域、各社サイロになっていて、結構苦戦しています。
今回、弊社が大きく障害を起こしやすい3つのシステムに、試しにテストに入ってもらいました。すべてサイロ化しているのですが、他者がテストを行うことで、サイロを破るという行動への価値だったり、気づきを与えたり、というのを現場の3部署で実践しました。しかし、3部署とも『今の人がやりやすい』『今のサイロでも』という結論でした。フル工程を受託させているので、ある種、ベンダーロックインを剥がすことや、テストだけ分けることが相当むずかしいんですよね。
横串でテストを、システムテストを横串で外すのは、現実的には（杉谷様のところでは）行うことができそうなのでしょうか？」

「サイロ解消に一番有効なのは、現場からのボトムアップです。
まず前提として、私の部署がシステム企画やシステムリスク管理ではなく、システム開発そのものであることです。当社では過去に企画主導の開発体制の改革を行ったこともありますが、なかなかうまくいきませんでした。今回のSHIFT社との取り組みとの決定的な違いは、現場からボトムアップで進めていることが大きいと考えております。
違う観点から申し上げます。テスターや開発者はそれぞれのシステムを開発する委託先にお願いせざるをえないのですが、総合テストやシナリオテストといった上から下までシナリオを流す局面では、開発の委託先だけでは消化しきれない場合があります。ここにSHIFT社に入っていただくことで、徐々にSHIFTの認知度を上げていくということを行っています。
もう一つは、コスト効率です。SHIFT社を組み合わせることで10%や20%のコストが下がることに対して、やらない場合の効率化を現場に求めることにより、徐々に現場の意識を変えているところではあります」

「立場、ポジションの違いはありそうですね。北風と太陽ではないですけれども、特に、企画主導で北風的にやられると、現場としてはイヤだなと感じるところもあるはずです。4月からは、SHIFT社をチームの一員として現場に派遣して、一緒に何ができるか、品質向上に向けた取り組みを予定しています。現場に馴染んでもらい、よい案を出していく方が正しそうだ、と感じたので参考になりました」

「当社も、現場は『馴れ親しんだベンダーさんはよく知っているし、なかなか手放せない』という声は多くありますが、特定のベンダーや特定の要員に依存することは良し悪しがあります。そういう中でSHIFT社を有効活用するには、他のベンダーとの違いをどこに見出すか、ということだと思います。
私どもからするとSHIFT社のノウハウである「第三者目線」をシステム開発のなかに取り入れていくという、草の根活動が浸透した部分で品質が上がっている状況からも、SHIFT社と他のベンダーとは活用の仕方が違うということを明確に感じているので、SHIFT社には他のベンダーさんと同じような活躍を期待していない、という違った意味での期待をしております」

「以前は『低価格にするにはどうすればいいのか』というところにずっと取り組んできました。例えば、同じシステムでも、ブラウザで動くバージョンとWindows端末にインストールして動くソフトの開発は、それぞれベンダーさんを分けています。例えば、新商品の見積をするときに、両社だけ極端に高い場合は原因を追究しています。
また、オンラインの領域でも、生命保険の設計書や提案書から、画面遷移の手続きで申込書までつくれるシステムがありますが、設計書はAベンダーさん、以降の申込書をつくるフェーズは別のベンダーさんと分けたりしています。見積は両社に取りますが、他に似たような画面もあるので比較もできます。我々も、見積はきっちり精査しているつもりですが、やはり限界がありますので、1社にすると低価格化は目指せないという結論です。
テスト工程は、ベンダーさんに結合と少し総合までやってもらうのですが、いまSHIFT社に依頼している総合テストは変えないですね。変えるつもりはなくて、役割が違うと思っています。SHIFT社が見つけた不具合を、『君たちは見つけられなかったけどSHIFTさんは見つけたよ！』と既存ベンダーさんに突き付けています。一定のプレッシャーにもなっていますので、今の関係はいいのかなと思っています。あとは、例えば、ベンダーさんは自社でカスタマイズしたJavaのフレームワークを入れたがるのですが、入れちゃうと将来逃げられなくなっちゃうので、入れないようにするとか、そういう視点でもベンダーを見ています」

システムの複雑化や更改による予期せぬ障害を事前にどう予期し、どう防ぐか、各社の取り組み状況をお話いただきました。

「複雑化する障害の発生原因が課題です。年々、統制を強化して単純な障害は減り、総障害数も右肩下がりなのですが、レアケースの踏み抜きが増えてきています。考慮不足や影響調査不足が多く、レアケースを踏み抜いてしまう障害をどうやって潰していこうかなと。ただ、プログラム総数、システム総数も増えているので、レアケース踏み抜きの可能性がどうしても一定数発生しつづけるので、どうしていくべきか課題です。
また、大体5年か6年に1度、システムの大規模更改があります。当然、更改に人は張っているのですが、それでも障害を抑止できません。ここに対してSHIFT社には何人か張り付けて踏み込んでもらうことで、転ばぬ先の杖として障害スパイクを抑止したいなと思っています。『本当にどこまで行けるのだろう』と半信半疑でありつつ、現場にSHIFT社を紹介しつづけている状況ですので、案件が増えると思いますが、いい意味で期待を裏切ってくださる、という期待をしていますので、よろしくお願いします」

「一時期、『このパターンに合致したときだけ、これが起こってしまう』とか、あまりにもレア過ぎて気づかずに、過去数年分のデータを直さなければならないことがつづいたことがありました。どうやったら抑止できるのか、逆に私も教えていただきたいくらいです。現場一人一人のレベルアップをして、愚直に考慮不足を一つ一つ潰していくことに時間をかけるしか、今は答えをもち合わせていないというのが実情です。一定数、起こってしまう障害に対して、どう備えていくかは非常に難しいと感じています」

「障害を全部集めて、何か起こったら半期分まとめて全ベンダーさんに還元したりしています。他で起こっているから起こさないでくれよ、といった愚直な活動をしつづけて品質を上げていくことをやっています」

エンタープライズ金融統括部　宮田
「SHIFTは、ジェーシービー様（一部）や三菱UFJトラストシステムズ様の本番障害の傾向分析をして対策をお伝えしていますが、『これってテストでできたんじゃないですか』という我々の評価に対して、担当の方からは『それは絶対テストでは出ないよ』と言われます。当初のプロジェクトに参画していないこともあるので、文面だけで判断せざるを得ないのですが、そのあたりでギャップがあるなと思います。
レアケースの課題ですが、パターン＝テストの組み合わせとして、レアかどうかという判断が大事かと思います。例えば『令和になったから出た』という障害もありますが、何年に1回しかないイベントを踏んでしまうのがシステムのロジックに必ず仕組まれています。どこかで可視化されていないとならないはずなので、なぜできなかったのか、という分析が大事だと思います。何がウィークポイントで、それが会社の全体の課題がある場所なのか、システムやベンダーの問題として発生している場所なのかという、ポイントの分析が未然に防止するには必要になってきます。『レアがレアである』というポイントを少し客観的に分析するといいのかなと考えます」

「レアケースには2種類あると思っています。システムに対する要件としては提示されていたものが実際に発生するデータへの考慮として設計やプログラムに落としきれなかったというケースと、落としきれていたがそんなケースが起きるはずはないと思ってテストが実施されなかったケースです。
どちらも問題はありますが、心配なのは後者です。システムとして十分な品質を提供できなかったという点において、例えば、限界値設定や、桁数、年数の考慮が不十分であったなど、いろいろな原因がありますが、システムに詳しい人が『テストはここまでやれば大丈夫』と判断したけれども実は大丈夫じゃなかったということがあると、その人が認識できる範囲の品質が限界になる、ということになります。
それを解消するには、各フェーズでやるべきことをきちんとやり、それをいかにトレースできるかというだと思います。2種類どちらにおいてもSHIFT社によって効果がでる部分はあると思いますが、どちらかというと後者を解消できると良いと考えています」

SHIFTでは金融・証券・保険・決済業界をはじめとする、多くのエンタープライズ企業が抱える課題を品質という観点からサポートしています。サービスの内容や事例はこちらからご覧ください。

SHIFTテスト・品質保証サービスはこちら
お客様導入事例一覧はこちら

※掲載内容やお客様のご所属は2021年3月当時のものです。