ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。

Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。

しかし、こうした取り組みだけではどうにもならないものも少なからずあった。
そのひとつは、「悪い報告がしづらい」ことだった。

これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。

「あと少し頑張れば、なんとかなると思って」
「会社やみんなに迷惑をかけちゃいけないから」

そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から袋叩きに合う。これでは、身を守るために化粧した報告をする人が出てきてもおかしくはないし、うつ病にならずにいる事の方が難しい。


だが、考えてみれば、そもそも、「注意を与える」レビューでは、問題は何も根本的に解決はしないのだ。

仮にレビューが正常に機能したとしても「問題に気づくことができる」だけであり、「問題の発生を防ぐ」という根本解決にはならない。根本解決をするには、「問題に気づく」のではなく、「問題を起こさない」ようにしなければならない。そして、そのためには、顧客との折衝能力、プロジェクト管理能力、ソフトウェアの開発力、メンテナビリティの高い美しいコードを書く能力、などの能力を高めていく施策が必要不可欠だ。それに、注意を与えるレビューによって現場を萎縮させてしまっては、そもそも問題の報告自体もしづらくなる。レビューを厳しくしたのに問題が見えにくくなるのでは、本末転倒以外の何物でもない。


きっかけは、意外なところからやってくる。

SIのプロジェクトの状況を確認して回った。この主な趣旨は、「モダンなツールや開発手法をどの程度取り入れているか」という点についての現状を確認することだった。

結果として分かったのは、少数ではあるが、一部のプロジェクトは、とても上手くいっている、ということだった。そしてこうしたプロジェクトにおいては、CI/CDの導入、被依存度の高いモジュールに対してのテスト自動化、デザインパターンの習得と適切な活用、コードレビューの実施等が行われていたのだ。


「注意を与えるレビュー」の文化を超えていくにはどうすれば良いのだろうか?その答えが見えたように思えた。

「『いいな』と思えるやり方を広めて、成功して、そのやり方のファンが増えて、ファンがまたインフルエンサーとなり別のファンを増やして、結果的に会社全体が良くなっていく。」

これしかない、と思った。

そこで、昨年の10月に「モダン開発推進」というチームを作った。

このチームのリーダーには、社内のプロジェクトでもっともうまく行っていたチームのリーダーであるA氏が着任した。

現場へのヒヤリングを通じて、他にも分かったことがあった。

リファクタリングは、顧客に提案できない。なぜなら、「プロなのに、お金をもらっておいて、後で直さなきゃいけないコードを書いたの?」と言われてしまうから。しかしある程度の複雑度を持つソフトウェアであったり、ある程度の変化に対する許容性を持つソフトウェアをメンテナビリティ高く維持していくには、リファクタリングは必要不可欠だ。まず一度その価値を体験してもらうために、リファクタリングのお手本を見せるコストについては、こちらで持つことにした。

CI/CD、テスト自動化についても同様だった。「これまでやっていないし、その調査コストをお客様に請求することはできない」、だが必ず知っておくべき、というものについては、モダン開発推進が工数に見合う費用をSIの現場に請求せず、現場に寄り添って一緒に実践していくので、まずは体験してみてほしい。そしてもし納得してもらえたなら、その体験に根ざした利点をきちんと説明した上で、今後はSIの工数に組み込んでいってほしい。そんな思いでこの取り組みを進めている。

そして、モダン開発推進の活動を始めて半年が経った。
ちょうど3件のプロジェクトでモダン開発推進を実施し終わったところで、モダン開発推進が入って起きた変化は例えば次のようなものだ。

  • ソースコード管理
    【Before】
    ST前に一斉コミットしていた。
    【After】
    デイリーコミットが習慣化し、個人で抱え込まずに、チーム全体で共有できるようになった。また、問題の早期発見につながりやすくなった。支援開始初期の段階では「自信のなさ」や「恥ずかしさ」からデイリーコミットが進まなかったが、ソースコードの共同所有の有用性を体験してもらうことで、次第にリズムが生まれ、習慣化していった。

  • 脆弱性診断 / 静的解析
    【Before】
    ST完了時に実施していた。
    【After】
    コミット単位でCIを回し、そこに脆弱性診断と静的解析を組み込んだ。これにより、段階的かつ確実な品質の作り込みが可能となった。

  • テストコード
    【Before】
    作成していなかった。
    【After】
    実装箇所の優先順位に基づき、機械的に実行可能な単体テストコードを実装するようにした。これにより、バグ修正やリファクタリングの際に既存コードの品質が担保可能となった。

  • コミュニケーション
    【Before】
    メール・電話による情報伝達が行われていた。
    【After】
    Slackを活用したコミュニケーションが行われるようになった。メールに比べてリアルタイム且つライトなツールであるため、コミュニケーションのオーバーヘッドが削減。冗長になりがちなメールに対して、問題の具体的な内容をシンプルに議論しやすくなった。また、オープンなコミュニケーションツールであるため、課題発生時に有識者を交えて議論し、短時間でトラブルシューティングにつなげることもできるようになった。各自のコミット状況やジョブの実行結果等を自動的に通知し、出社時にチャンネルを確認するだけで前日のテスト状況の把握し、必要に応じて修正を素早く行えるようになった。結果として問題の解決速度が早まった。

  • 考察
    総じて、問題の早期発見が行いやすくなった。デイリーコミットが数日間コミットが行われない、静的解析ツールの解析結果が数日経っても改善に向かわないなど、リズムが崩れ始めている時にチーム全体で早期に気づけるようになった。また、チームのカルチャーが「一人で抱え込まずにチームで開発」という文化に自然に引き寄せられていき、「どうしよう、悪い報告はできない、なんとかキャッチアップしなきゃ」、そして報告が遅れて更に・・・というネガティブスパイラルに陥りにくくなった。


上記のような感じで、こうしたやり方が良いのだな、という機運が生まれ始めており、
と同時に、次にやるべきことも見えてきた。

次の一手とは、4月から始まった「PMジェダイ評議会」の立ち上げである。これはスター・ウォーズのジェダイ評議会にインスパイアされたSIer改革の第二弾の新制度である。私が取締役会で「スター・ウォーズにインスパイアされた制度です」と説明した時、これまで保守的だったセゾン情報システムズの取締役会の空気は一瞬凍りつき、しかしその詳細を聞いて凍りついた空気は氷解し、満場一致で推進する方針になったのであった。

長くなってきたので、続きはまた次のエントリで書こうと思う。

To be continued...