i3Systems Engineering blog

株式会社アイキューブドシステムズの製品開発メンバーが、日頃のCLOMO開発の様子などを紹介します。

CLOMOの開発スタートガイド作成までの道のり

こんにちは、サーバーサイドエンジニアのM-Yamashita01です。
現在、弊社ではCLOMOシステムの開発にスムーズにJOINできるように、開発スタートガイドを整備しています。しかし、この開発スタートガイドは数ヶ月前までは弊社にありませんでした。今回、この開発スタートガイドが作られるきっかけとなった従来の課題と、どのような経緯を経て作られていったのかを紹介します。

製品開発部が抱える3つの課題

CLOMOシステムが開発、運用され始めて10年以上の年月が経ちました。その間に多くの機能が追加、改善されてきました。また、社員が増えていく中で、開発初期の社員の退職もありました。

この中で、CLOMOシステムを開発していく上で知っておくべきドキュメントが散在したり、特定の人のみ知見を持っていたりする状況になっていました。主な課題として、「オンボーディング対応時間の増加」、「複雑化した全体像の把握」、「仕様書の散在」があります。

これらの課題について説明します。

オンボーディング対応時間の増加

弊社では新入社員に対し、1対1の説明会形式で説明や教育を行なっています。この説明会では、説明担当者が変わる場合があり、新入社員へのトレーニング内容にばらつきが生じることがあります。
また、弊社では継続的な採用活動を続けているため、開発メンバーが増加しています。その結果、開発メンバーへのオンボーディング対応時間が増加の一途をたどっていました。

複雑化した全体像の把握

CLOMOシステムが開発、運用され始めてから、機能追加、各OSへの対応、インフラの改善など、さまざまな対応が行われてきました。その中でメンバーの入れ替わりにより、仕様や設計方針の背景といった属人化していた知識が伝達されなくなり、CLOMOシステムの全体像が見えづらくなっていきました。

また、今回の開発スタートガイド作成前までは、他の開発メンバーに聞いたり、後述する散在した仕様書を検索、組み合わせしたりしながら全体像を把握していました。
そのため仕様の見落としなどによる考慮漏れや作業漏れを引き起こす原因になっていました。

仕様書の散在

弊社では機能追加や改善を行う際、軽微な修正を除いて設計書を記載しています。しかし、設計書には一部の面から見た仕様が書かれているのみであり、仕様全体を把握するには、複数の設計書を見ながら理解する必要がありました。

また、これらの設計書がGoogle DriveやConfluence、Jiraに散在していたため、探し回るコストの大きさも問題となっていました。
探し回るコストを下げるために、ConfluenceやJiraなどのツールから検索性能がさらに良いツールへ変更する方法もありましたが、これらのツールは製品開発部だけでなく、弊社全体の情報共有として使用しています。そのため、製品開発部のみツールを変更するわけにはいきませんでした。

改善部隊による取り組み

この3つの課題に取り組むため、以下活動内容を検討しました。

  1. クイックスタートガイドの作成
  2. CLOMO技術ドキュメント体系の整備
  3. ドキュメント作成環境の整備、ルールの策定

「クイックスタートガイドの作成」では、新入社員向けにCLOMO製品の全体像、要素技術、実装技術を解説する資料を作成、整理します。また、1対1のトレーニングを実施しなくても開発メンバーとして立ち上がれるドキュメントの整備を行います。

2番目の「CLOMO技術ドキュメント体系の整備」では、CLOMO製品の仕様書としてのあるべき姿と現状の差異を認識して、仕様書をよりよいものにする活動を計画します。ここでは既存仕様書の整理や、現状との差異の分析を行います。

最後の「ドキュメント作成環境の整備、ルールの策定」での目的は、CLOMO製品の仕様書を充実させるために必要な環境・ツールを整備します。またドキュメント体系を適切に運用するためのルールを策定します。

これら3つを取り組む改善部隊として開発メンバーから有志を募ったところ、モバイル側、サーバー側で2人ずつの計4人がメンバーとなりました。
このメンバーは開発業務と並行での作業となったため、活動に割けるリソースが限られていました。また活動内容の優先順位もありました。この点を考慮した結果、まずは「クイックスタートガイド」のVersion 1.0作成を目標として、活動を始めていきました。

実際の活動では、まず必要なドキュメントの洗い出しや現状の把握を行いました。各メンバーが開発作業と並行作業のため、活動の作業計画で作成ドキュメントの優先順位とスケジュールを決めた後、各々作成に取り掛かりました。

ドキュメント作成後、他の開発メンバーにレビューしてもらい、不足していた知見の追加や、新入社員の視点で分からない箇所の修正を行いました。

活動を振り返って

本活動では大きな遅延が発生せず、計画通りに進みました。ブログ執筆時点で、クイックスタートガイド Version 1.0がリリースされています。
以下の図は、本活動で作成されたクイックスタートガイドの一部となります。

クイックスタートガイド

この活動を振り返り、多くの良かった点、改善すべき点が挙がりました。ここではその一部を紹介します。

良かった点

  • あらかじめ作業項目と優先順位をふっていたので、優先度が高いものから取り組めた
  • 社内のリソースの制限があるなかで、ドキュメントを完成できた
  • インターンシップ(※)でドキュメントを使ってみて、必要性を再認識できた
  • 活動を進める中で、開発パートナー様にもドキュメントを見せたいという要望が挙がってきた
  • 本活動前に下書きとして作っていたドキュメントを流用することができた

※弊社では新卒の方々に対し、希望に応じて入社前のインターンシップを行っています。

改善すべき点

  • 開発パートナー様にも見せられるように、社外秘情報を書かないといったドキュメント作成ガイドラインを用意しておく

改善すべき点で挙がった点に関しては、今後次の段階の活動を検討しているため、その活動で反映していきます。

まとめ

このブログでは、弊社の製品開発部が抱える3つの課題に対し、ドキュメントを作成、整理して対応した話を紹介しました。今後開発メンバーが増えていった際に、今回作成したドキュメントが役に立ってくれると考えています。

今回は現状の設計ドキュメント作成と整理でしたが、今後は追加機能や改善点といった新しい情報を都度取り入れていく仕組みも必要となってきます。そのため、その仕組みも構築できるよう活動を進めていきます。