システム開発や業務の仕組みづくりで直面する課題を解決するための、方法論と知識をまとめています。
移管・つまずき
移管できます。継続改修か再構築かは、自社に何があるかによって変化します。最初に権利と名義と稼働方法を確認します。
8語
開発対象を最初にすべては確定させず、数週間ごとに動作するものを構築して確認し、優先順位を再検討しながら開発を継続する考え方です。発注側が継続して関わる手間がかかります。
要件定義、設計、実装、テストの工程を順に1回ずつ遂行し、前の工程を確定させてから次へ移行する開発の進め方です。何を開発するかを着手前に決め切れる案件向けで、途中の変更には追加の費用と期間がかかります。
ソフトウェアの作りに改善の余地が残存し、以後の変更に余分な手間がかかる状態を借金にたとえた言葉です。速さのために意図して負うことも、知識不足や運用後の発見で生じることもあります。
ソースコードの変更をこまめに取り込み、自動でテストして、いつでも本番に反映できる状態を維持する開発の進め方とその仕組みです。リリースが速くなるほか不具合を混入させたときに前のバージョンへ切り戻しやすくなります。
会計、販売、購買、在庫などの基幹業務を1つのデータでつなぐ統合パッケージです。費用と期間は製品の標準に業務をどこまで適合させられるかで決定します。
あるシステムの機能やデータを別のシステムが所定の手順で呼び出して利用できるようにした窓口です。CSVの受け渡しで十分な場面も多く、APIは開発後も保守が続きます。
業務の機能を他のシステムから呼び出せるサービスとして切り出し、組み合わせて全社のシステムを構築する設計の考え方です。ESBと呼ばれる連携製品を中央に配置する構成は変更のたびに中央の作業が必要になる問題を抱え、考え方はAPIに引き継がれました。既存の連携基盤は変更にかかる期間と担い手で評価します。
販売、購買、在庫、生産、会計、人事給与など、取引を金額と数量で確定させて記録する業務のシステムです。基幹システムには変化の少ない処理だけを実装し、変化の速い機能は周辺のシステムで開発するほうがよいです。
