開発ツールの運用で発生する作業
開発ツールは、タスクや課題の管理、ソースコードの管理、進捗の可視化といった工程を支える仕組みです。まず、導入後にどのような作業が続くのかを把握しておきましょう。作業量が見えないまま体制を決めると、担当者に負荷が偏る要因になります。
導入後に続く作業の内容
運用では、プロジェクトの作成と終了、メンバーの追加と削除、権限の見直し、課題の分類方法の調整、テンプレートの更新といった作業が発生します。組織やチームの構成が変わるたびに、設定を実態にあわせる必要があります。
作業の頻度は組織の変化の多さによって変わります。年に数回の見直しで足りる場合もあれば、案件の立ち上がりにあわせて毎月調整する場合もあります。自社でどの程度の頻度になるかを見積もっておくと、必要な体制の規模を判断できます。過去1年のプロジェクト数を目安にする方法もあります。あわせて、1回の作業にどれくらいの時間がかかるかも記録しておくと、担当者の負荷を具体的に示せます。
体制を決める順序
体制は、担当者を決めてから作業を割り振るのではなく、必要な作業を洗い出してから担当を決める順序が進めやすくなります。作業の内容が見えると、どの職種が担うのが適切かも判断しやすくなります。
洗い出しの際は、日常的に発生する作業と、年に数回の作業を分けて整理しましょう。あわせて、それぞれの作業に必要な権限も書き出しておきます。開発の進め方に詳しい人が担う作業と、アカウント管理に関わる作業を分けると、無理のない分担を組めます。
管理を担う人が限られる場合
エンジニアリングマネージャーが他の業務と兼任している場合や、情報システムの専任者がいない場合でも運用を続けられるかは、多くの企業で確認される点です。
兼任の担当者が管理する場合の進め方
兼任の担当者が運用する場合、まとまった作業時間を確保しにくいという前提で設計する必要があります。1回の変更にかかる時間が短く済むかが、判断の材料になります。
確認したいのは、よく行う変更を管理画面から短い手順で行えるかという点です。プロジェクトの作成、メンバーの追加、権限の変更といった操作を、デモの場で実際に試してみましょう。既存のプロジェクトから設定を複製できる機能があると、立ち上げのたびに一から設定する手間を減らせます。よく使う構成をテンプレートとして保存できるかも、あわせて確かめておきましょう。
情報システムの担当がいない場合
専任者がいない企業では、設定に専門的な知識が必要かどうかが導入の可否を左右します。サーバーの用意や保守が不要なクラウド型であれば、開発チームだけで始められる場合があります。
一方で、社内の認証の仕組みとつなぐ場合や、社外からの接続を制限する場合は、情報システムの知識が必要になることがあります。自社で対応できる作業の範囲を伝えたうえで、ベンダーがどこまで支援するのかを契約前に確認しておきましょう。設定の代行を依頼できるかも確かめておくと安心です。
多拠点の開発チームをまとめる場合
拠点ごとに開発チームがある場合、それぞれで設定を管理すると内容にばらつきが生じます。まとめて管理する方法を確認しておきましょう。拠点が離れているほど、設定の違いに気付くまでの時間も長くなります。
拠点ごとの設定と共通化
すべてのチームを同じ設定にすると、開発の進め方が異なるチームで支障が生じる可能性があります。共通で使う部分と、チームごとに変える部分を分けて設計しましょう。
共通の部分をまとめて変更できる仕組みがあれば、全社的なルールの変更を一度で反映できます。チームごとの設定については、そのチームの担当者が自分で変更できるようにするか、本社でまとめて管理するかを決めておきます。どちらの場合も、変更の履歴を確認できるかを確かめておきましょう。誰がいつどの設定を変えたかをたどれると、想定と異なる動きが起きた際の切り分けが進みます。
時差や勤務時間の違いへの対応
拠点が離れている場合、作業する時間帯が重ならないことがあります。同時にやり取りをしなくても進められる仕組みがあるかは、実際の使い勝手に関わります。
課題のやり取りが文章として残り、後から読んで経緯を追える構成であれば、時間帯が違っても作業を引き継げます。通知の送信時間を調整できるか、担当者ごとに通知の条件を変えられるかもあわせて確認しておくと、業務時間外の連絡が積み重なる状況を避けやすくなります。表示する言語や時刻の基準を利用者ごとに切り替えられるかも、海外の拠点がある場合は確認しておきましょう。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料を取り寄せて機能や特徴をさまざまな製品で比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力(約60秒)で開発ツールの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
本社やグループ全体で状況を把握する場合
複数のチームや関連会社の開発を統括する場合、状況をまとめて確認できるかが検討の中心になります。確認できる範囲と権限の設計を整理します。見たい情報の粒度と、見せてよい範囲という2つの方向から考えると整理しやすくなります。
進捗を確認できる範囲
本社で全社の状況を確認したい場合、プロジェクトごとの進捗、課題の件数、遅れの有無を横断して見られるかを確認しましょう。集計の単位や、確認できる期間の範囲は製品によって異なります。
あわせて、リアルタイムに近い形で状況を確認できるか、日次の集計になるかも確かめておきます。遅れが生じている案件に早く気付きたい場合は、一定の条件で通知を受け取れる仕組みがあるかも聞いておきましょう。必要な確認の頻度にあわせて判断することが求められます。確認する時期をあらかじめ決めておくと、報告のたびに集計し直す手間を減らせます。
権限の分け方
統括する立場と、現場でプロジェクトを進める立場では、必要な権限が異なります。全社の状況を見られる権限、自チームのみ見られる権限、設定を変更できる権限を分けて設定できるかを確認しましょう。
関連会社を含めて管理する場合は、会社ごとに範囲を区切れるかも確認が必要です。他社の詳細な情報まで見えてしまう構成では、契約上の条件に照らして問題が生じる可能性があります。権限の設計は、管理部門や法務の担当とあわせて検討することをおすすめします。設定した権限の一覧を定期的に見直し、異動や退職にあわせて整理する時期も決めておきましょう。
報告に使う集計の出力
経営層や関係部署へ状況を報告する場面では、集計した内容を資料として使える形で取り出せるかが関わります。出力できる形式と項目の範囲を確認しておきましょう。
毎月同じ形式で報告する場合、集計の条件を保存して繰り返し使えると作業を減らせます。定期的に自動で送られる仕組みがあるかも確かめておきます。手作業での加工が多く必要な場合は、その工数も運用の負担として見積もっておくことが求められます。
職種をまたいで分業する場合
開発を担うエンジニアと、計画や調整を担うプロジェクトマネージャーが分かれている場合、役割の整理が運用の安定につながります。どちらか一方に作業が寄ると、変更の依頼が滞る要因になります。
担当範囲の切り分け
分業する場合は、どの作業をどちらが担うかを具体的に決めておく必要があります。範囲があいまいなままでは、設定の変更が必要な場面で対応が滞る可能性があります。
作業の一覧を作り、それぞれの担当と、判断が必要な場合の相談先を明記しておきましょう。課題の分類方法や進捗の定義は計画を担う側、開発の記録に関わる設定はエンジニア側というように、知識が必要な領域にあわせて分けると無理が生じにくくなります。一覧は関係者が参照できる場所に置き、体制が変わった際に更新する運用にしておきましょう。
画面の見え方の調整
職種によって必要な情報は異なります。エンジニアは自分の担当する作業を、管理する立場の人は全体の進み具合を見たい場面が多くなります。
役割ごとに表示する項目を変えられるか、個人ごとに画面を組み替えられるかを確認しておきましょう。全員が同じ画面を見る構成では、必要な情報を探す手間が増えます。設定の自由度が高いほど管理の手間も増えるため、自社の体制で維持できる範囲かどうかもあわせて判断してください。デモの際は、それぞれの職種の担当者に実際の画面を見てもらうと判断がずれにくくなります。
運用の負担を抑えたい場合の開発ツール
管理を担う人数が限られる環境では、設定の手間や引き継ぎのしやすさが選定の材料になります。運用を続けやすい構成の製品を集めました。
JUST.DB
- 【完全ノーコード×生成AI】マウス操作と"ことば"でシステム開発
- 【多彩な標準機能】高い拡張性により、全社DXをJUST.DB1つで実現
- 【同時ログインライセンス】全社展開してもコストを抑制
株式会社ジャストシステムが提供する「JUST.DB」は、業務アプリケーションをノーコードで作成できるクラウド型のサービスです。画面上の操作で入力フォームや一覧、集計を組み立てられるため、プログラムの記述を前提とせずに運用できます。作成した内容が画面の設定として残る形になり、担当者が交代した際にも中身をたどりやすい構成です。管理を担う人が限られる組織で検討しやすいサービスです。
楽々Framework3
- EOL(サポート終了)を気にせず長く使える開発基盤
- 部品活用で高品質・標準化されたシステム開発
- 開発から運用保守まで支え、継続改善と内製化を実現
住友電工情報システム株式会社が提供する「楽々Framework3」は、業務システム向けのWebアプリケーション開発基盤です。画面や帳票、データベース処理といった共通部分が用意され、設計情報をもとに生成する仕組みを備えています。開発の進め方を基盤側でそろえられるため、担当者ごとに作りがばらつく状態を抑えやすくなります。長く保守を続ける前提の業務システムに向いた構成です。
GitLab (GitLab合同会社)
- DevOpsのライフサイクルを導入
- マネジメント機能でシステム全体を可視化
- 豊富な機能で製品開発を徹底サポート
DevOps推進ソリューション (株式会社日立ソリューションズ)
- 人財育成から環境構築まで一貫支援
- 組織に適した開発プロセスへ改善
- 最適なDevOpsツールを選定・導入
まとめ
開発ツールの運用体制は、発生する作業を洗い出してから担当を決める順序で組むと無理が生じにくくなります。人員が限られる場合は変更作業の手数、多拠点では共通化と個別設定の両立、グループ全体では権限の分け方が焦点になります。分業する場合は担当範囲と画面の見え方もあわせて整えましょう。運用支援の範囲を資料請求で確かめ、比較検討を進めてみてください。

