2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
須田一也氏(以下、須田):コンシューマ向けサービスにおけるDevOpsについて、私須田がご説明いたします。
コンシューマ向けのプロダクト開発においては、ビジネス価値にフォーカスした仕組みを取り入れています。まずCI/CDですけど、“早く作って早くデリバリーする”かたちでCI/CDの仕組みを取り入れ、毎日進捗確認をして短いサイクルで開発し、振り返ってすぐ改善するようなスクラムのフレームワークを取り入れています。
そして疎結合、マイクロサービス、モダンアプリケーションといったインフラストラクチャーの仕組みも取り入れており、可観測性、サービス状況の可視化、ビジネスKPIの可視化といったかたちで、モニタリングやダッシュボードの仕組みも取り入れています。これらすべては、ビジネス価値を生み出すために作る仕組みとして、選択をしています。
続いて、その中からCI/CDの事例に関して紹介いたします。DevSecOpsの事例に関して、とあるチームの事例を紹介いたします。まず開発者がコードを書いて、TDDサイクルを回すことをルール化しています。それによって仕様の明確化であったり、変更容易性であったり、品質の維持に役立てています。
そして、モブプログラミングを採用することで、コードレビューの省略や、スキルシェア、多能工化を目的として実施しています。そうしてできあがったコードがsiderを使った静的コードレビューに用いられたり、CircleCIでテストとビルドとデプロイを行って、環境にデプロイをしています。
そのテストの中で「yamory」というサービスを使い、OSSの脆弱性診断を実施しています。環境にデプロイされたモジュールに対しては、定期的なリグレッションテストや、さまざまなモニタリングを実施することで、品質面に関しても自動的に確認を行う仕組みを導入しています。
続きまして、MaaSの開発サイクル事例に関して説明いたします。同じように、開発者がペアとかモブプログラミングをやっていますが、コードレビューの省略とかスキルシェア、多能工化につきましては、先ほどの事例と同じような効果を期待しています。それと併せて、最近はリモートワークなので、リモートワークでの孤独感の排除にも役立つかたちになっています。
このように作られたコードも同じく、CircleCIでテスト、ビルドを行い、AWS環境にデプロイしています。iOSだけはBitriseを使い、テスト、ビルド、デプロイを行って、DeployGateにアップロードして、アプリを配布しています。それぞれの仕組みに対しての状況に関しては、Slackに通知されるようになっています。
続いて、スクラムでの取り組みに関して紹介いたします。CI/CDもチームごとに適したものを選んで使っていますが、スクラムに関する、スケール方法もチームごとに選択しています。「auでんき」アプリの事例では、Scrum@scaleの仕組みを使っています。こちらは各開発チームごとにプロダクトバックログがあり、スプリントごとにバックログを選択しています。
各チームのスクラムマスターが、毎日スクラム・オブ・スクラムというかたちで集まり、その中で話し合いながら、障害の除去や解決、ナレッジの共有につなげていくようになっています。
「au HOME」アプリに関しては、LeSS(Large-Scale-Scrum)方式を使っています。こちらは、1つのプロダクトバックログの中から、各開発チームがスプリントごとにバックログを取っています。開発チーム間の垣根を排除してフラットに編成することで、チームの障害やナレッジの共有も自発的に横展開される仕組みを採用しています。
チームのコミュニケーションのツールを紹介いたします。リモートワーク導入前に関しては、ほぼオフィスワークで開発を進めていました。メインのコミュニケーションツールはSlackを使っており、オフィスにいるので、雑談とか相談はその場でできます。
地方で開発している1名とのコミュニケーションは、Slackのテキストチャットとビデオを使っています。スクラムイベントもオフィスで実施しており、壁に付箋を貼って看板を設け、JIRAとかConfluenceにバックログの詳細などを保存しています。
リモートワーク導入後にどう変わったかというと、当然ながら全員リモートワークになりました。メインのコミュニケーションツールは変わらずSlackを使っていますが、やっぱり雑談・相談が少なくなったので、Tandemというボイスチャットのツールを入れてみたりしました。
スクラムイベントに関しても、Zoomを使って実施するかたちになったので、リモートワーク前とはかなり違ったやり方になってきています。看板についても物理的な看板を見るのはちょっと難しいので、GitHub Enterpriseの中でIssueとかProjectを使って看板代わりに使ったり。JIRA、Confluenceは、変わらずバックログの詳細を格納するというかたちで使っていました。
最後に、マインドについても触れたいと思います。アジャイル開発の考え方なんですが、もともとアジャイルソフトウェア開発宣言というかたちで「プロセスやツールよりも個人との対話を」が重視されています。それと、我々の中でアジャイル開発センター憲章というのがあり、ベースのカルチャーとして「楽しくやる」ことを謳っています。
「個人との対話を重視して楽しくやる!」ところが我々のカルチャーとして根づいているので、そういったかたちでこれからも開発を続けていきたいなと思っています。
ご視聴ありがとうございました。
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには