はじめに

さくらインターネットでは数多くのサービスを開発し提供しています。それらを開発する中でどのようなマネジメントを行っているか、およびそれらの経験から得られた知見を共有する会を社内イベントとして実施しました。本記事では、この知見共有会の模様を2本に分けてレポートします。

前編の記事では以下の発表をお伝えしました。

「IoT事業部流プロジェクト管理術」(小田島太郎さん)
「ユーザー価値とプロダクト」(野田宗一郎さん)

続いて後半2人の発表をご紹介します。

分断マネジメント

3人目の発表者は、クラウド事業本部の成嶋健一さんです。成嶋さんは、当社が開発・運用を受託している衛星データプラットフォーム・Tellusなどの開発マネジメントを担当しています。今回は「分断」というキーワードを軸に、プロジェクトにおけるリスク管理やコミュニケーション管理について発表しました。なお「分断マネジメント」という言葉は成嶋さんの造語です。

システム開発案件で発生した分断

成嶋さんが過去に(当社に入る前に)担当したシステムで、こんな業務がありました。

メインフレームのデータをCSV形式で出力
CSVのデータをExcelに読み込んで編集し、再びCSVで出力
出力されたデータをメインフレームに読み込む

ここで、ExcelでのCSV形式のデータ編集には以下のような問題が存在します。

桁数の多い数字列が指数表示になる
数字列の先頭に並んでいる0が消える (例：0020220929 → 20220929)
編集後のデータが問題ないかをチェックする仕組みがない
ExcelにてCSV形式で出力するときにメインフレーム向けに整形されない

これらの結果として、Excelで出力したCSVデータがメインフレームに取り込めないことがあります。

しかし、Excelでの編集作業を担当するのは非エンジニアで、Excelのこのような特性には詳しくないので、問題に気づくことができません。一方、システム開発を担当するエンジニアは、ExcelでもCSV編集はできる(問題があってもなんとかなるだろう)と考えていて、問題を認識できませんでした。

これが小規模なチーム内での業務など、お互いのコミュニケーションが緊密であれば問題に気づける可能性が上がるのですが、開発を外注しているなどで相手の状況が見えづらいと、こういった問題が発見されにくくなります。これが今回のテーマである「分断」です。

分断の原因と解消への取り組み

このような分断は意図的に起こされるものではなく自然発生的に起きるものであり、またそれ故に観測しにくいものでもあります。しかしプロジェクト管理においては、こういう分断で生じる問題にも対応していかなくてはなりません。

成嶋さんは分断に関する考察として、分断はメンバーのさまざまな属性の違い(多様性/ダイバーシティ)が重なって発生することや、価値観の異なる人々が集まるとコミュニケーションに問題が発生しやすいといった点を挙げました。分断は人々の属性に起因するため、これを解消することは困難です。分断を解消するのではなく、分断により見落とされる致命的な問題を発見し解消していくことが重要です。

分断解消への取り組みとしては、メンバー間の共通点やギャップを観測し、それを共有することで多様性の存在に気づいてもらう、分断が生み出す問題を言語化しリスク分析を行い、深刻な場合は解決を試みる、といったことを行っています。

まとめと感想

組織におけるリスク管理やコミュニケーション管理についての発表をお伝えしました。発表の最後に成嶋さんからは「日頃からコミュニケーションを取り、互いの属性を理解し合うことが、分断とそこから発生する問題を正しくとらえることにつながる」という言葉がありました。近年はリモートワークが普及しオンラインでのコミュニケーションが中心になっていますが、こういう時代だからこそ日頃からのコミュニケーションがより一層大事になっているのではないかと感じました。

オブジェクトストレージでアジャイルになってみた

4人目(最後)の発表者はクラウド事業部の川井俊輝さんです。川井さんはさくらのオブジェクトストレージの開発に携わっていますが、その開発プロセスにアジャイルを活用してみた件について発表しました。

アジャイルとは

アジャイルとは、開発者やマネージャーが実践的なマネジメントを支援するためのフレームワークです。ツールというよりも規律や行動様式を指す言葉なので、「アジャイルを使う」ではなく「アジャイルになる」という表現がふさわしいとされています。

アジャイルは短期間(1〜2週間程度、これをスプリントと呼びます)での開発(計画・設計・実装・テスト・リリース)を繰り返す方法を採用しており、こうすることで開発におけるさまざまなリスクにうまく適応することを狙っています。

また、1スプリントにおけるチームの労力を算出することで、開発にどれぐらいの労力がかかるかを見積もり、開発マネジメントを支援することもアジャイルの目的の1つです。見積もりは時間ではなく労力(ストーリーポイント)で見積もります。1スプリント内のストーリーポイントの合計をベロシティと呼びます。

オブジェクトストレージチームの状況と課題

アジャイルの実践例を紹介する前に、オブジェクトストレージチームの体制や状況を説明します。

オブジェクトストレージチームには、プロダクト全体の責任者である企画担当と、開発や運用の取りまとめを行うドメインエキスパートがいます。その他に開発チームとインフラチームがあり、開発チームはフロントエンドとバックエンドに分かれています。

実務をどのように進めていくかは開発チーム・インフラチームに委ねられており、両チームともそれぞれの仕事の進め方があります。また、メンバーの多くは、他のプロダクトの業務も兼任しています。

このような体制での進め方について、川井さんは以下の課題を感じていました。

進め方が各チームに依存しているため、データに基づいた見積もりが難しく、予測と実績を比較して振り返ることができない
統一されたマネジメント手法が存在しない
兼任メンバーが多く、仕事の優先度や裁量が個人に依存するため、スプリント内で開発が完了しない場合がある

川井さんは、ここにアジャイルの手法を導入することにより、以下のように変わるのではないかと考えました。

ベロシティを提供することで見積もりが可能になる
「顧客へのインパクトを重視する」という指針でマネジメントを統一できる
開発サイクルの短縮によりスピーディーに顧客に価値を届けることができる

アジャイルを小さく始める

しかし、アジャイルという、従来とは異なる手法を持ち込むことの難しさもあります。説明や啓蒙にかかるコストの高さ、従来の手法との融合の難しさなどです。

そこで川井さんは、いきなりチーム全体にアジャイルを導入するのではなく、まずはスモールスタートとして「自分だけでアジャイルになってみる」ことにしました。チームで策定した今年度のロードマップからスプリントで着手するストーリーを選定し、スプリントを2週間に設定して実施してみました。

実際にやってみると、選定したストーリーに対する作業項目や作業手順の記録はあっても、どれぐらいの労力を要するかというデータは残っていないため苦労もありましたが、それでもなんとか見積もりを作った上で作業を実行し、見積もりと実績をストーリーポイントの値というデータで算出することができました。これを半年ほど繰り返し、下図のグラフにあるような結果が出ました。

アジャイルの効用

このようにして開発にかかる労力をデータで持っていると、プロダクトオーナーからの質問にも答えやすくなります。例えば、ある機能のリリースがいつ頃できそうかを尋ねられた場合も、それにかかる労力が何ポイントであるかを把握していれば、それに基づいて「開発チームがフルコミットすれば2週間でできます」などと回答することができます。これが「データを提供することで開発マネジメントを支援する」の一例です。

兼任メンバーが多いことの難しさ

先ほど提示したグラフを見ると、期間によって獲得ポイントにムラがあることがわかります。この業務にフルコミットできればこうしたムラは少なくなる(グラフの傾きが水平に近くなる)のですが、実際には川井さんにも兼任業務があって、常にフルコミットできるわけではないのでこうなります。

このような状況下でアジャイルをチーム全体に広げようとしても、兼任メンバーが多いとフルコミットできない期間も多くなり、ベロシティの確度が下がるという問題があります。

仲間を増やす

このような問題に対して、兼任メンバーの稼働をコントロールする方法として、集中作業日を設ける、マネージャーがチーム横断で稼働をコントロールする、そもそも兼任しない体制を作る、などがありますが、そういうトップダウン的な手法は当社らしくないと考えた川井さんは、別のアプローチとしてボトムアップ的な手法、つまり一緒にアジャイルになる仲間を増やすことを試みています。

やっていることとしては、川井さんが所属する開発チームとインフラチームとの定例ミーティングにおいてスプリントの中間報告をし、スプリントが終了したらベロシティを確認するといったことです。チーム全体に報告するとプレッシャーがかかるので、少人数で共有することでプレッシャーを低減するとともに、まず身近なところからこういった手法を共有し、共通の尺度を持つことでアジャイルの効用を広めていこうとしています。

まとめと感想

オブジェクトストレージの開発プロセスにアジャイルを導入した事例をお伝えしました。川井さんはこの他にもドメイン駆動設計を取り入れるなど、ソフトウェアの開発手法をいろいろと試行しています。おそらく当社のシステム開発ではこれまであまり行われてこなかったと思われる取り組みです。こうした手法を導入することでより良い開発が行われることを期待しています。なおドメイン駆動設計に関してはさくナレのこちらの記事をご覧ください。

オブジェクトストレージ開発におけるDDD (ドメイン駆動設計)

おわりに

当社のサービス開発におけるマネジメントの知見共有会の模様をお伝えしました。マネジメントといってもいろいろあり、今回は製品開発寄りの話題もあれば組織や人に関するものもありましたが、いずれにしてもこういう種類の情報交換が行われる機会はこれまであまりなかったと思われるので、貴重な会になったと思います。これからも「業務を通じて得た知見を共有する」というさくナレの趣旨に沿って、読者の皆さんに良い情報を提供していきたいと思います。

それではまた次回のイベントでお会いしましょう！