テラスカイは11月25日～26日に「TerraSkyDays 2021 Online -Fly Ahead to 2030 次のパラダイムに備えよ」を開催した。11月25日にはDX推進企業の事例として、同社子会社のBeeXが開発パートナーとして関わる、日本経済新聞社における法人向けサービスの開発体制内製化の取り組みが紹介された。

【関連記事】
≪テラスカイが年次イベント、クラウド活用した「DX Ready」の先進事例≫
≪テラスカイ、働く人の幸せと事業成功を両立させる「mitoco Work」提供≫

当日は、日本経済新聞社の法人向けサービスのうち、「日経リスク&コンプライアンス」と「Nikkei The KNOWLEDGE」に技術リードとして関わる、デジタル事業情報サービスユニット サービス企画・開発グループの齊藤祐也氏が登壇した。

冒頭で齊藤氏は、「ニーズの変化の速さに対応し、新たな価値を提供するためには、日々改善を繰り返して新たな機能を実装する必要がある。新サービスの立ち上げと事業成功には、内製化に向けてエンジニア組織の改革を行うことが欠かせないと考えた」と明かした。

  • 日本経済新聞社 デジタル事業情報サービスユニット サービス企画・開発グループ 齊藤祐也氏

サービス開発体制の改革にあたっては俊敏性を高く保ち、ニーズに対して細かく、早くPDCAを回せるようにするため、ベンダー依存から脱却し自社主体の開発体制の構築を進めている。また、エンジニアが主体性やプロダクトへの愛着を持って関わり、事業を成長させられるチーム作りを意識しているという。

齊藤氏は、「俊敏性と柔軟性」を内製化で得られる成果として念頭に置き、それらを得るために信頼できるチーム作りと、自律するチームの育成を目指して組織改革を進める。自律したチームづくりで活用しているのがRitual（リチュアル）だ。

Ritualは、直訳すると「(ある宗教の)儀式、典礼」という意味で、システムやサービスの開発においては「(いつもの)決まったやり方」といった意味合いが近い。チームの拠り所となるツールやミーティングを指すことが多く、スクラム開発におけるセレモニーもRitualの1つだという。

「我々の開発チームではコラボレーションを連続的、非同期的に行うために、他社が実施しているさまざまなRitualを採用しつつ、チームに合わせてアレンジを加えて活用している」と齊藤氏は述べた。

開発のプロセスでは、顧客への提供価値を言語化・現実化するための方法や計画などをドキュメントとして残す「DevDoc」を活用する。DevDocは通常、代表者が記述するものだが、齊藤氏の開発チームではエンジニア全員で作り上げるものと定義し、DevDocへのコメントを求めるRFC(Request for Comments)を必ず実施している。

  • 齊藤氏の開発チームで行うDevDocの例

「記載内容に対してどうアプローチするか、どんな疑問を持ったか、課題解決方法へのフィードバックを出し合う。開発前から開発が終わるまで、DevDocで継続的にコラボレーションを行いながら、プロジェクト完了まで進める仕組みになっている」(齊藤氏)

今後は、内製でのアジャイル開発のスピードを落とさないために、意思決定の一元化ドキュメントである「ADR」(Architecture Decision Records)を導入する予定だという。同開発チームでは、ADRの実装の検討にあたってもDevDocとRFCを活用し、「どうすれば自分たちらしいADRを構築できるか」を検討している。

社内外のエンジニアのコミュケーションを効率化するため、同開発チームでは米Amazonが採用するSilent Meeting(静かな会議)の要素を加えた「スプリントミーティング」を実施する。ミーティングでは、「TableRead」と呼ぶアジェンダ兼議事録をベースに、Slackのテキストチャットを使ってプロジェクトの進捗確認などを行う。

  • アレンジを加えたスプリントミーティングのねらい

業務上のコミュニケーションにはソースコードレビューも欠かせない。同開発チームもGitHubでプルリクエストを用いてレビューを行うが、ソースコードレビューがチームの信頼醸成につながるよう、「承認したコードは日経が責任を負う」と明示する。そうすることで、開発者は新しいアプローチを試しやすくなり、心理的安全性の担保にもつながるという。

Ritualを活用した組織改革を4年続けてきた中で、齊藤氏は挑戦を継続することの重要性に気付いたという。「アジャイルという原則が生み出した方法論をそのまま受け入れるのではなく、その時々の状況に合わせて、小さくても変革を積み重ねることが開発環境を変えるために欠かせない、という学びを得られた」と齊藤氏は振り返った。

開発パートナーとの協業では、当初は指示待ちが多かったものの、、今はパートナー企業からの判断で提案がなされるなど、社内外問わずエンジニアが自走・自律して開発を進める体制になったという。今後はDevDocの初版もパートナー企業のエンジニアが書くなど、開発のプロセスにもさまざまなエンジニアが意見を出し合えるようなチーム作りを目指す。