開発手法の捉え方
動向を見る前に、比較の土台となる考え方を押さえておきましょう。
従来から用いられてきた進め方
要件の定義、設計、実装、試験、稼働という工程を順に進める方式は、長く用いられてきました。各工程の終わりに成果物を確認し、次へ進む形です。工程ごとの責任範囲が明確で、計画も立てやすくなります。
一方、後の工程で要件の見直しが生じると、前の工程へ戻る手戻りが大きくなります。求められる内容が最初に定まっている場合には適する一方、進めながら変わる可能性がある場合には対応しにくい面があります。
手法を比べる際の前提
手法はどれも、特定の課題に対応するために生まれています。そのため、自社が抱える課題と合っているかを基準に見ることが実務的です。
また、名称が同じでも、実際の運用は組織によって異なります。取り入れた結果、形だけが導入されて効果が出ないという状況も起こり得ます。何を変えるための手法なのかを理解したうえで、自社の体制に合う部分から取り入れる進め方が現実的です。
注目されている考え方
近年語られることの多い考え方を、三つに分けて確認します。
短い周期で作り進める考え方
全体を一度に作るのではなく、優先度の高い部分から短い周期で作り、確認しながら進める方式です。早い段階で動くものを確認できるため、認識のずれに気づきやすくなります。
要件が固まりきらない段階でも着手できる点が特徴です。一方で、関係者が継続して関わる体制が前提になります。確認の場に判断できる人が参加できなければ、周期ごとの判断が滞ります。計画の立て方や契約の形も、従来と異なる考え方が必要になります。優先度をどう決めるかも、この方式では重要になります。何から作るかの判断が定まらなければ、周期ごとの目的も曖昧になります。関係者の間で優先順位を合意する場を、あらかじめ仕組みとして設けておきましょう。また、周期ごとに動くものを確認するには、試験や配置の作業を短時間で行える環境も前提になります。この準備を伴わないまま周期だけを短くすると、確認の負担が増える結果になります。導入の前に、この環境を整えられるかを見極めておきましょう。
開発と運用をつなぐ考え方
作る側と動かす側が分かれていると、稼働後に問題が生じた際の対応が滞りやすくなります。両者が連携し、公開や更新の流れを自動化していく考え方が注目されています。
試験や配置の作業を仕組みに任せることで、更新の頻度を高めやすくなります。ただし、自動化には整備の工数が必要です。更新の頻度が低いシステムでは、投じた工数に見合う効果が得られない場合もあります。対象を見極めて取り入れましょう。
記述を減らして構築する考え方
画面から部品を組み合わせることで、記述を最小限に抑えて仕組みを作る考え方です。専門的な知識を持たない担当者でも、業務に必要な仕組みを用意できる点が特徴になります。
業務部門が自分たちで作れることで、依頼と待ち時間を減らせます。一方、作られた仕組みが増えると全体の把握が難しくなります。誰が何を作ったかを記録し、扱う情報の重要度に応じて作成できる範囲を定めておく運用が必要です。
動向の背景にあるもの
なぜこうした考え方が語られるのかを、二つの観点から確認します。
要件の変化に対応する必要性
事業を取り巻く状況が変わる速さが増し、最初に定めた要件が完成までに変わることが増えました。長い期間をかけて作った結果、稼働時には求められる内容が変わっていたという事態も起こり得ます。
短い周期で確認しながら進める考え方や、更新を素早く反映する仕組みは、この変化への対応として位置づけられます。ただし、要件が安定している領域では、従来の進め方のほうが計画を立てやすい場合もあります。
人材の確保と分担の見直し
開発を担える人材の確保が難しい状況では、限られた人員でどう進めるかが課題になります。記述を減らして構築する考え方は、この事情を背景に関心を集めています。
業務部門が自分たちで作れる範囲を広げることで、専門の担当者はより難しい領域に集中できます。ただし、任せる範囲を明確にしなければ、管理されていない仕組みが増える結果にもなります。分担の設計とあわせて検討することが求められます。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料を取り寄せて機能や特徴をさまざまな製品で比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）で開発ツールの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
手法を選ぶ際の判断軸
どの進め方を採るかを判断する材料を、二つ挙げます。
対象となるシステムの性質
要件が明確で、稼働後の変更が少ない領域では、工程を順に進める方式が計画を立てやすくなります。求められる水準が高く、検証の記録が重視される領域でも、この方式が選ばれる傾向があります。
一方、利用者の反応を見ながら改善を重ねる領域では、短い周期で進める方式が適します。一つの組織の中でも、対象によって使い分ける考え方が現実的です。すべてを同じ方式で進める必要はありません。
体制と関わり方の前提
短い周期で進める方式は、関係者が継続して関わることが前提になります。判断できる立場の人が確認の場に参加できない体制では、進行が滞ります。
外部に委託する場合は、契約の形も関わります。作る範囲を最初に確定する契約と、期間を区切って進める契約では、扱いが異なります。手法だけを取り入れても、体制と契約が伴わなければ機能しません。導入の前に、この点を整理しておきましょう。
開発ツールの選び方
ここまでの内容を踏まえ、ツールを選ぶ際の確認事項を整理します。
対象工程と体制の整理
最初に、どの工程を支えたいのかを決めます。設計の段階なのか、記述と管理なのか、試験や配置の自動化なのかによって、必要なツールが変わります。
あわせて、利用する人数と役割も整理しましょう。専門の担当者だけが使うのか、業務部門も使うのかによって、求められる操作のしやすさが変わります。人数に応じた料金体系を採る製品が多いため、規模の想定は費用にも関わります。
必要な機能と既存環境との関係
すでに使っている環境や、開発に用いている言語や基盤に対応するかを確認します。既存の資産を活かせるかどうかは、導入の負担に直結します。
他のツールとの連携も確認点です。記述の管理、試験の実行、配置の自動化といった工程をつなげる構成では、それぞれが連携できるかが実務に関わります。導入後に追加したい機能があれば、その計画も伝えておきましょう。
費用とサポート範囲の確認
料金は、利用人数に応じた月額制、機能ごとのプラン分け、利用量に応じた課金など、製品によって考え方が異なります。無料で使える範囲を設けた製品もあるため、まず試す進め方も選べます。
サポートについては、どこまで対応してもらえるのかを具体的に確かめます。操作方法の案内にとどまるのか、導入時の設定や進め方の相談に応じてもらえるのかは製品ごとに差があります。社内に経験者がいない場合は、この部分の充実度が定着を左右します。
開発手法の変化にあわせて活用できる開発ツール
アジャイル開発やノーコードといった動向にあわせて検討できるツールを紹介します。
楽々Framework3
- EOL(サポート終了)を気にせず長く使える開発基盤
- 部品活用で高品質・標準化されたシステム開発
- 開発から運用保守まで支え、継続改善と内製化を実現
住友電工情報システム株式会社が提供する「楽々Framework3」は、業務システムを効率的に開発できるフレームワークです。定型的な処理をあらかじめ用意した構成になっており、ノーコード・ローコードの動向にあわせて開発期間を短縮したい場合に活用できます。
Magic xpa Application Platform
- 【クロスプラットフォーム】ワンソース・マルチデバイス
- 基幹業務システムの運用基盤としてグローバルで40年の実績
- 【超高速開発！】CやJavaの10倍の開発生産性
マジックソフトウェア・ジャパン株式会社が提供する「Magic xpa Application Platform」は、業務アプリケーションのローコード開発基盤です。一度の設計から複数のプラットフォーム向けアプリを生成できる機能を備えており、開発の効率化を重視する動向に対応した製品です。
Swift （Apple Japan合同会社）
- 安全性を考慮したモダンな言語設計
- 高速処理と簡潔な構文を両立
- Apple製品向けアプリ開発に対応
システム39 （株式会社ジョイゾー）
- 定額料金でシステム開発に対応
- 対面打ち合わせ中にアプリを開発する支援
- 最短2週間でスピーディーに業務システムを構築。
開発手法に関するよくある質問
検討を進める担当者から寄せられることの多い質問と回答をまとめました。
- Q1： 新しい手法へ切り替えるべきですか？
- 新しいことが自社に適することを意味するわけではありません。対象となるシステムの性質と、関わる体制を踏まえて判断しましょう。すべてを切り替えず、対象によって使い分ける進め方も現実的です。
- Q2： 短い周期で進める方式を取り入れるには何が必要ですか？
- 関係者が継続して関わり、周期ごとに判断できる体制が前提になります。外部に委託する場合は契約の形も関わります。まず小さな範囲で試し、体制と進め方を整えてから広げる方法が採られます。
- Q3： 記述を減らして構築する仕組みはどこまで使えますか？
- 業務に必要な仕組みを短期間で用意できる一方、複雑な処理や大規模な構成には向かない場合があります。作れる範囲と、扱ってよい情報の種類を定めたうえで、業務部門に任せる範囲を設計しましょう。
- Q4： どのツールから導入すべきですか？
- 現在どの工程に時間がかかっているかを整理し、そこから着手する進め方が現実的です。すべてを一度に整えようとせず、効果を確認しながら範囲を広げることをおすすめします。
まとめ
開発手法の動向としては、短い周期で作り進める考え方、開発と運用をつなぐ考え方、記述を減らして構築する考え方が語られています。背景には、要件が変化する速さと、人材の確保という事情があります。ただし新しい手法が常に適するわけではなく、対象となるシステムの性質と、関わる体制を踏まえて選ぶことが実務的です。対象工程と体制を整理したうえで、既存環境との関係や費用を比べてツールを選びましょう。
