ウォーターフォール開発

TL;DR 自己紹介 新チーム立ち上げ前の状態 変革過程でぶち当たった3つの壁 考え方の移行：慣れ親しんだやり方に引っ張られる 関係性の移行：心理的安全性が高まらない 関連性の移行：チームが単独でリリースすることが難しい 今後の展望/最後に TL;DR 本記事では、社内マーケティング機能を開発しているウォーターフォール開発チームをアジャイルチームに移行した事例を紹介します。ただ単に開発手法を変えるだけでは、アジャイルなチームとは言えません。真のアジャイルを実現するために必要な「考え方」「関係性」「関連性」の移行をどのように行ったかご紹介します。 自己紹介 NTTドコモのデータプラットフォーム部…

はじめまして。ファイナンシャル・ソリューション開発部の赤坂です。 私は主に案件遂行の仕事をしているのですが、案件遂行はプロジェクトの全体像が見えないとなかなか難しいものがあります。そこで今回は、プロジェクト（＝案件）の基本となるウォーターフォール開発を解説しながら案件遂行で気を付けることを書いていこうと思います。 １．ウォーターフォール型開発とは？ ２．ウォーターフォール型開発の主な工程 ３．要件定義 WBSを作成し、概要とスケジュールをメンバへ説明 ４．基本設計 この段階でテスト概要や実施リスクなども考える ５．開発・単体テスト ６．結合テスト・総合テスト 丁寧な橋渡しと進捗管理がカギ ７．…

ちょっと職場で話題になった。 アジャイル開発 現在主流になっているシステムやソフトウェアの開発手法の1つで、 『計画→設計→実装→テスト』といった開発工程を 機能単位の小さいサイクルで繰り返すのが最大の特徴 とのこと。 従来？の手法は ウォーターフォール開発 って言うらしい。 知らんかった。。。 要件定義から設計、開発、実装、テスト、運用までの各工程を 段階的に完了させていくシステムやソフトウェアの古典的な開発手法 とのこと。 monstar-lab.com さんより。 そんなんはあんまし意識してやってこなかったけど、 その説明からすると、仕事で開発ごとも、工作趣味事も 何十年も前から自分はア…

結論から言うと 「システムの発注者が受注者に対して設計段階で適切なフィードバックをできていない」 から。 はじめに これは個人的な経験に基づく意見であり、観測範囲はすごく狭く、広範囲の調査を行ったものではありません。あくまで個人的にはこうだったから、こうなんじゃないかなという仮説とポジショントークてんこもりの話です。 前提とか背景とか 私の経験では受託開発の受託側で仕様の検討から実装・テストまで担当することが比較的多く、また、システム開発にあまり詳しくない発注者が、実際にシステムの開発を行う受注者に発注する開発スタイルが多かったです。 また、開発体制などの都合からまっとうなアジャイル開発やスク…

今回は、従来よく使用されていたオンプレミスとクラウドの違いについてまとめていきます。 オンプレミス（自社で運用していること） メリット セキュリティ面では社内ネットワークなので攻撃を受けにくい デメリット 高価（固定費） 障害時に自社で復旧 ユーザー自身でセキュリティ導入・運用バージョンアップまで クラウド メリット 安価 メンテが少ない サービス提供者がセキュリティ対策を実行 バックアップできる 24時間監視で復旧 デメリット セキュリティリスクが高い 長期使用では、コストがかかる 機械学習アプリケーション Machine Learning Studio・・・マウス操作のみで機械学習が可能 …