SOLID原則をまとめてみた Part1 ~SOLID原則とはなんぞや編~

はじめに

はじめましてorこんにちは!
ecbeing2年目、R&D部門所属の浦…改め蓑代です。
※結婚して名前変わっちゃいました

これまでは、Dockerの記事やスクラムに関する所感記事、JavaScriptライブラリに関する記事を書きました。
blog.ecbeing.tech

そして今回…というより本シリーズでは、泣く子も黙る『Clean Architecture』本を参考に…。
www.amazon.co.jp ソフトウェア設計の5つの原則として名高い「SOLID(ソリッド)原則」についてまとめていこうかと!

…既にSOLID原則をご存じの方は、「すごく難しい話題をまとめるんだな」と察していただけましたかね…?

SOLID原則は「原則」と名が付いているように、非常に概念的な話が多く。
※具体的な実装の話ではなく、もっと上位の概念の話が多い…という感じです

実は筆者は新卒のころにSOLID原則について学ぶ機会があったのですが…。
趣味でプログラミングしてた程度の知識しか持ってなかったからか、さっぱり身につかず。
そんな状態でSOLID原則を見ても、2週間後には「SOLIDのSってなんだっけ…」となるくらいに頭から消え去っちゃいました。

しかし、そんな筆者も今年で2年目(とちょっと)。
様々なプロダクトにプログラマとして関わってきた今の筆者なら、以前よりもSOLID原則の事が分かるようになる…と淡い希望を抱き、まとめてみようと決心した次第です。

後、社内の凄腕アーキテクトの青木さん(めっちゃすごい)が、こんなことを話してくれ…。
※筆者の要約なので、これをまんま話したわけではないです

世の中の様々なアーキテクチャを学ぶと、新技術を学ぶときに「その技術がどんなアーキテクチャを採用したか」が分かるようになる。
例えばMVVMを知っていれば、Vue.js製のプロダクトを見た時に「画面上へどんなデータが出力されるのか」はViewをたどれば見つける事が出来る。
「どこのフォルダやファイルにどの様な処理が書いているか」が、その技術を知らなくても推測できるようになるのだ。(ここ重要)
十分な知識と良く練られた良質なソフトウェアであれば、僅かなコードを見るだけで何のアーキテクチャを採用したのかが分かるようになり…。
そこまでのレベルにたどり着くと、新技術のinput速度が圧倒的に早くなる。

日進月歩が激しいこの業界で、爆速input力を身につけられればエンジニアとしてものすんごい強みになりそうだなと思い。
筆者もそうなりたい!と強く思ったというのも動機です。
((というかこっちが本命

その取っ掛かりにまず、SOLID原則を学んで行こうかなと。

…序章が長くなってしまいました…。
早速本題、「SOLID原則をまとめてみた」に入っていきましょう!

SOLID原則とは

まずは「SOLID原則」という言葉の説明から。

SOLID原則は、オブジェクト指向プログラミング分野を前提とした「ソフトウェアの5つの原則」を覚えやすくするための用語です。
「オブジェクト指向プログラミング分野が前提」とあるように、当該の話は関数型プログラミング等の他分野には当てはまらない原則となりますのであしからず。

同じくソフトウェアの原則である「GRASP」とは異なります。
こちらは「クラスやオブジェクトに責務を割り当てる方針を導くパターンや原則」なので、SOLID原則が指す方向性よりも狭いものになっています。

すっごい蛇足ですが、このSOLID原則を提唱したRobert C. Martin氏は『Clean Architecture』や 『アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技』、『Clean Code アジャイルソフトウェア達人の技』など、素晴らしい著作物の生みの親です。

そんなSOLID原則が掲げる5つの原則は、それぞれ下記の様に呼ばれます:

  • Single Responsibility Principle:単一責任の原則(SRP)
  • Open/closed principle:オープン/クロースドの原則(開放閉鎖の原則)(OCP)
  • Liskov substitution principle:リスコフの置換原則(LSP)
  • Interface segregation principle:インターフェース分離の原則(ISP)
  • Dependency inversion principle:依存性逆転の原則(DIP)

それぞれの原則が意味するものはこうです。

  • Single Responsibility Principle:単一責任の原則
    • 1つのクラスは1つだけの責任を持たなければならない
    • ソフトウェアの仕様の一部分を変更したときには、それにより影響を受ける仕様は、そのクラスの仕様でなければならない
  • Open/closed principle:オープン/クロースドの原則(開放閉鎖の原則)
    • ソフトウェアのエンティティは拡張に対して開かれていなければならないが、変更に対しては閉じていなければならない
  • Liskov substitution principle:リスコフの置換原則
    • プログラムの中にある任意のオブジェクトは、プログラムの正しさを変化させることなく、そのサブクラスのオブジェクトと置換できなければならない
  • Interface segregation principle:インターフェース分離の原則
    • 汎用的な目的のインターフェイスが1つだけあるよりも、特定のクライアント向けのインターフェイスが多数あった方がよりよい
  • Dependency inversion principle:依存性逆転の原則
    • 具象(具体的な物)ではなく、抽象に依存しなければならない

これらの原則は、ソフトウェアをより理解しやすく、より柔軟に、よりメンテナンス性の高いものにするために考案されたものです。

どうしてSOLID原則が生まれたのか

ここからはSOLID原則の理論を提唱した論文(Design Principles and Design Patterns - by Robert C. Martin)を追いながら、「どうしてSOLID原則が生まれたのか」を深堀りしていきましょう。

ダメなソフトウェア設計の4つの原因

当該論文によれば、ダメなソフトウェア設計の原因には次の4つがあるとのこと:

  • Rigidity-剛性
  • Fragility-脆弱性
  • Immobility-不動性
  • Viscosity-粘性

…名前だけじゃようわからんですね…。
1つ1つ詳しく見ていきたいと思います。

Rigidity-剛性

「Rigidity-剛性」は、変更や修正が困難であることを指します。

例えばで言うと、1つのモジュールを変更したいのに、影響範囲が大きかったり調査が難航することで数週間もかかってしまう状態です。
これにより、修正コストの大きさからエンジニアだけでなく、マネージャー職、経営者ですらシステムの変更を恐れる様になり(剛性)、やがてそれは経営方針にも悪影響を及ぼす…かもしれません。エライコッチャ…

Fragility-脆弱性

「Fragility-脆弱性」は、剛性と密接に関わるものとして挙げられています。

先に挙げた例の様に、1つのモジュールを変更するだけで影響範囲が色んな箇所に散ってしまうと、十分な影響範囲の調査なしの修正によりシステムが壊れてしまう可能性が出てきます。
また、壊れやすさが上がると、時間の経過とともにシステムが壊れる可能性も高くなる…とのこと。

これが脆弱性が指すものです。まぁこんな状態のシステムなんてメンテできませんよね…。

この悪影響はそのまま、顧客やシステムの経営者からすらの「エンジニアに対する信頼度」の低下につながるとのこと…
悪いコードにより信頼度が低下するなんて、いやぁゾッとしますねぇ…😱ギャー
それこそ、「せっかく優秀なエンジニア雇ったのに、改修後の他範囲への影響率が下がらないじゃないか!高いお金出して雇ってるのに!」なんて事になる未来もちょっと見えるような…。ウヒー

Immobility-不動性

「Immobility-不動性」は、「作成したソフトウェアを他のプロジェクトに再利用できない事」を指します。

これは「1つのモジュールに色んな処理が複合されている場合」を考えてみるとわかりやすいかもです。
この状況下で「そのモジュールの一部の処理を他プロジェクトで再利用したい」事を考えてみましょう。

…察しの良い方はもうお分かりかと思いますが…。
こう言ったモジュールでよくあるのが「そのモジュール内でしか使用しない前提で処理を書かれていること」や「依存する処理が多すぎること」です。
この様なモジュールでは、一部の処理だけを移行できず「モジュールを丸ごと移行しないと使用できない」ケースになることがほとんどです。

ただ、モジュールを丸ごと移行して動かすなんてことは大概の場合はできないはずです…。
モジュールを丸ごと移行した後に待ち受けるのは「そのモジュールを自分たちのプロジェクト用に書き換えること」。
再利用性なんて0に等しい環境が出来上がっちゃうのです…開発コストが上がるのは言わずもがな。

ちなみに、こちらの不動性につながるもの…と言っていいのかですが…。
私たちのチームでは、チーム独自に「新規プロダクトを作成する際の雛形フレームワーク」が存在します。
ReviCoや今後ローンチされるとあるプロダクトも、実はこちらのフレームワークを元に作られたものなのです。

また、雛形のフレームワークは絶えず進化を遂げています。
雛形のフレームワークが使用している.NET Coreのアップデート対応だったり、細かな改善だったり…。

さらに、雛形フレームワークの進化内容をReviCoや他プロダクトに取り込むコストは結構控えめであるため…。
すでにローンチされているプロダクトであったとしても、NET Coreのアップデート対応だったり、細かな改善だったりを雛形フレームワークを元とした少なめコストで実現できると言う流れが生まれているのです!
不動性の逆、再利用性が高いと言えるんじゃないかなと。

Viscosity-粘性

「Viscosity-粘性」は「設計」や「環境」の影響で、開発に無駄に時間がかかっちゃう事を指します。

例えばデザインパターンの1つMVVMに沿ってきっちりと作成されたプロダクトにおいて、完全新規に1画面を作成する改修を考えてみましょう。
MVVMで1画面を作成するには、新しくViewModelやView、Modelを作成しなければなりません。
((大体は既存のコピペで済むかもしれませんが…

ただ、もしこれが「既存の画面にちょこっと処理を追加するだけで実現できるなら?」
MVVMに沿わないかもしれませんが、圧倒的な速度で実装が完了するはずです。
つまりこれが、デザインパターン…「設計」の影響によって無駄に時間がかかっちゃうことです。

一応補足すると、粘性はデザインパターンを否定しているものではないと思います。
要は「適材適所ではないデザインパターンを採用したせいで、無駄に開発コストを上げない様にしようね」って事だと思います。
堅牢なシステムであればそれ相応のデザインパターンを、プロトタイプ開発であればそれ相応のデザインパターンを採用しろって事なのかなぁと。

個人的な所感としては…。
「既存の画面にちょこっと処理を追加する」だけで本当に改修が終わるならそれでもいいかもしれませんが、まぁ大体そんなわけないですしね。
「以前追加してくれたあの画面に、こういう機能もつけて!」なんて要望が出てきたら…きっとその時は、新規に1画面を作成しなかった自分を呪うでしょうね。

「環境」による開発に無駄に時間がかかっちゃう事についても触れましょう。
ここで指す環境とは「エンジニアの開発環境」を指します。

例えばエンジニアに渡されるマシンが低速で、1回ビルドするにも非常に長い時間がかかっちゃうと…。
ビルド時間を少しでも削減するために、デザインパターンの観点から見ると正しい修正をしたくても、先に挙げた様な小手先の修正(既存の画面にちょこっと処理を追加する)だけで済ませたくなっちゃうのではないでしょうか。

これはエンジニアへ渡されるマシンだけでなく、デプロイ時のビルド用サーバーやソースコード管理システムにも同じことが言えるかと。
1回のデプロイにうん何時間もかかる様な環境や、1回のcommitやpushに数分もかかる様な環境では、デプロイやcommit/pushするのに尻込みする風土が生まれちゃう様になっちゃうかと…。

そうなってしまうと「エンジニアの開発効率」だけでなく「システムのリリース頻度」も下がり、結果的に「たまにしかリリースされないプロダクト」ができてしまいます。
日進月歩な世界で、更新頻度が遅いプロダクトは遅かれ早かれ置いてけぼりになるでしょう…。

本当の原因

ここまで見てみると、先の章で述べた4つの特性によってソフトウェア設計が悪くなっちゃう…と思いますが。
当該論文には、これら4つの特性よりももっと根本的な原因について示唆しています。

それは…初期段階では想定していなかった形で要件が変わること

「何を言ってるんだ、要件なんて変化するものやろ」と思いの方もいるかもしれません。
(筆者も論文読んでて思いました)

ここで言いたいのは「初期段階では想定していなかった形で要件が変わり、元々のデザインパターンにはそぐわない修正を余儀なくされる」ことです。
もしくは、初期段階でアサインしていた「採用したデザインパターンに詳しい方」がいなくなり…。
全く別の「採用したデザインパターンに詳しくない方」が既存デザインパターンを無視して改修した結果、元々のデザインパターンにはそぐわない修正となったパターンもあるかもしれません。

いずれにせよ、これらの変更により「プロダクトが採用するデザインパターン」と「要件」がそぐわなくなり…。
「なんでこんなデザインパターンを採用したんだ」という形にまでたどり着いちゃうかもしれません。
ここまでくると、リファクタリングを検討してもいいかもしれないですね…。

どんな変更が設計をダメにするのか

ここまでは「設計がダメになっちゃう要因」について見てきました。
次に論文では、「設計がどんな変更でダメになっちゃうのか」を記述してあります。

どんな変更でダメになるのか…論文では「モジュール間の不適切な依存関係にある」と述べています。
これだけじゃちょっと分かりにくいので、自分なりに解釈してみます。

恐らく「モジュール間の不適切な依存関係にある」というのは…。
例えばMVVMを採用したプロダクトが、度重なる変更によりModel層にViewModel層に関わる記述やView層に関わる記述が増えてしまうと言う事なのかなと。

これにより「View層に対し改修を加えるならView層のロジックだけを見ればいいはずが、Model層の改修もやらなくてはいけない」状態になってしまいます。
様々な要件によってやむを得なくそうなってしまったかもしれませんが、この状態がいい状態とは決して言えませんよね?

そしてさらに…。
当該論文では、これを解決するために「依存性を区切る仕切りを作成し、管理することで依存関係を適切に正すことができる」とあります。
その後「この仕切りとモジュールの依存性を管理するために、SOLID原則が必要である」と続くのです。
SOLID原則は、この話の流れで出てくるということですね…。

…ここは正直筆者もよくわかってないのですが…。
きっとSOLID原則を深く理解した後、もう一度これを読むと分かるのかなと。

現段階の自分では「世にある様々なデザインパターンの様に、各レイヤー層を要件に合わせて正しく区切り管理すること」なのかなと感じてますが…SOLID原則を深く理解した後の自分はどう解釈するでしょう、楽しみです!

お次はこのSOLID原則の1つ1つを詳しく見ていきましょう…と思いましたが、記事が長くなりすぎるので今回はこの辺で。

おわりに&次回記事に続く…

今回の記事では、SOLID原則の概要やその出自についてまとめてみました。
まさかSOLID原則自体で1Partになっちゃうとは驚きです…。
((SRPも今Partに入れれると思ったのですが…

次回記事では、SOLID原則のSの部分「Single Responsibility Principle:単一責任の原則(SRP)」についてまとめていこうかと!
今Partでは具体的なソースコードは書いていきませんでしたが、今後見ていく5つの原則については簡単なコードも合わせながら見ていこうかなと思います。

ちなみに余談ですが… 「はじめに」でちょこっとお話に出た青木さんは、過去にこんな記事を書いてます
blog.ecbeing.tech blog.ecbeing.tech

どれも素敵な記事なので、タイトルにある技術に興味のある方はぜひ!

それでは~!

~ecbeingでは基礎的な技術も深堀りまとめてくれる、発信力のある若手エンジニアを大募集中です!~ careers.ecbeing.tech

〜〜参考記事〜〜

(元)データサイエンティストらしく、見える化をしてみたって話

f:id:ecb_tkaihatsu:20200730174359p:plain

この記事は前回(TSTSTS)の続きです。

前回の記事は ↓↓↓↓↓こちら↓↓↓↓↓

blog.ecbeing.tech

はじめに

ブンブンHello World.

最近はフロントエンドよりのコーディングにハマりつつある開発です。

どうせフロントエンドやるなら、見た目に凝った何かを入れたい。

だってフロントエンドだもの。

そんな感じで今回は、実行結果をグラフにしてそれっぽい感じにする方法をまとめたいと思います。

見える化、出来ていますか?

  • はじめに
  • 前回までのあらすじ
    • TS入門してみた
    • 課題点
  • vue-chartjs
    • Vue.js
    • vue-chartjs
  • 何はともあれ実装
    • 環境構築
    • vue-chartjsのコーディング
    • 合☆体
  • 結果
  • おわりに
続きを読む

バーコードリーダーをブラウザから使えるようにしたい!JSのバーコードリーダーライブラリを調査しました

  • はじめに
  • 技術調査まとめ
    • 余談: サーバーサイドで何とかする選択肢について
  • QuaggaJSについて
    • QuaggaJSの素敵ポイント
    • QuaggaJSの注意ポイント
  •  まとめ

はじめに

はじめましてorこんにちは!
ecbeing2年目、R&D部門所属の蓑代です。

前回や前々回には、Dockerの記事やスクラムに関する所感記事を書きました。
blog.ecbeing.tech blog.ecbeing.tech

そして今回は…技術寄りな記事となります。
具体的には、「バーコードリーダーが実装可能なJavaScriptライブラリについて」まとめていこうかと思います!

…というのも、半年前程に自分が所属するプロジェクトから「ブラウザベースでバーコードリーダーを実装してほしい」というオーダーがありまして。
また、「アプリ形式ではなく ブラウザから 利用したい」という条件付き。
((アプリ形式なら実践してみた系の記事はわんさかあるんですけどね

なぜこの様な条件が付いたかというと…。
当時の(今もですが)プロダクトはブラウザベースで稼働するものでして。
バーコードリーダーのためだけに、わざわざiOSやAndroid用のアプリを作るのは高コストだという背景があります。

「ブラウザベースでバーコードリーダーを実装してみた」系の記事は意外と少なく…。
中々いいJSライブラリが見つかりませんでしたが、それでも何とか3つほどライブラリを見つけられたので、こうして記事にまとめてみた次第です。

前置きが長くなりましたが…それでは記事本編へ参りましょう!

続きを読む

Microsoft Teamsで何ができるの??

f:id:ecb_ssakagami:20200401185857j:plain



初めまして!シングルファーザーで時短勤務をしているガミさんです
このご時世、娘っ子の臨時休校やら何やらでテレワークをしていてあまり上京してきていませんが元気です

さて、本題です。
本来RTJ(リテールテックジャパン)でマイクロソフトさんと協業で ブース出展するはずだったのですがコロナの影響で出展停止に なってしまったのでここで少し技術情報が共有できればいいかなと ネタが少し硬いのでLINEチャット風でお送りましす!


天の声
えらいひと
RTJに出店するからTeams連携よろー
ほえー
何すりゃええんやろなぁ
ユーザが持ってきた写真をTeamsで
画像検索して商品詳細画面に案内したろ
ついでに在庫確認できますってシナリオでええんかの・・・

あとは売り場にカメラでも付けて
顔認証から年代と性別集計して
PowerBIで分析できるようにしたろ!
(承知しました!)
既読
0:30
えらいひと
心の声と逆やで
まぁそれでええで
期限は来月末までなー
ほな
既読
0:30
※画像はイメージです。本当は期日指定以外ちゃんと指示されました!


続きを読む!

さてまずはTeamsに画像を投稿したら近い商品画像を検索してECサイトの商品詳細画面へ飛ばして商品説明と在庫がわかればいいかなということで調査開始
これは宣伝ですがecbeingではオムニ対応の一環でEC在庫の他に店舗在庫を表示する対応も可能です!

話を戻してTeamsに画像投稿しても検索するトリガーが必要になります
そこで登場するのがチャットボット
チャットボットというと身近なもので質問すると返信くれる例のアレです
文字を入力したらサーバ側で解析してこれかな?という回答を返すやつです
それを画像にしてしまおうというのが今回の趣旨になります
チャットボットに投稿された画像を今度は解析しなくてはなりません
マイクロソフトさんのブースで出すんだからAzure使わないとね!
ということでAzure Cognitive Serviceの登場です
PaaSで用意されているサービスですが検索を主とするものになります
その中にCustom Vision Serviceがあるのですが、マイクロソフトさんのサービスなのにマーケットプレイスという落とし穴が・・・
そのためお支払いは一本化できません!

動きのほうに戻ろう
Custom Visionでは何をするかというと・・・
まずは画像登録
今回は自動登録までは考えていないのでECで持っている商品画像をCustom Visionに登録していきます
そしてその商品へ商品コードのタグ付けをしていきます
時間があれば検索された商品画像をCustom Visionへ登録して、その後選択された商品の商品コードをタグ付するという自動化を考えていたのですが叶わずヾ(・ω・`;)ノ

チャットボットから通知された画像をCustom Visionで解析して一致率が80%(今回一致率の判断は適当です)以上の商品コードをURLルール化して戻すという設定をします
チャットボットへ商品名、商品URL、画像一致率を戻して処理完了

構成図ですが・・・

f:id:ecb_ssakagami:20200401175903p:plain

①Teamsのチャットボットから画像登録した場合にCustomVisionへ画像を飛ばす
②事前にラーニングされた画像の一致率の高い画像をピックアップ
 ピックアップされた画像のタグに設定してある商品コードをチャットボットに戻す
③リンク付きにしたので商品詳細ページに案内してやれ!


ちなみに動画にしてみるとこんな感じです

f:id:ecb_ssakagami:20200401184439g:plain




次はレポート表示や!

シナリオとして考えたのはスーパーでも家電屋さんでも色々なカテゴリーの売り場が存在しています
そこで各売り場にカメラを設置しておいて訪問者の年齢、年代をためる
時間ごとにグラフ表示して年代、性別ごとの売り場改善やセールの判断ができるようになればいいな
店長会議などでグラフ化しておけば資料を用意する手間も省けて他の仕事に専念させることができるかな?
こんな感じです!

さて用意するのは・・・
顔認証するにあたり、kioskアプリを使ってみよう
kioskアプリはAzure Cognitive Servicesのデモを簡単にできるマイクロソフトさんのデモアプリです
ここでFace APIを繋いで年齢、年代を判断してもらいます
社内を駆け回って顔収集していたのですが、若くみられる分には全然構わないのだけど老けてみられた人への申し訳なさと言ったら・・・言葉にできません
判断された時刻、年齢、性別、感情(無表情、嬉しい、悲しいなど)をSharePointに配置したエクセルファイルへ追記していきます

次にMicrosoft Flowを使ってエクセルファイルからレコードを読み込んでPowerBIに渡して集計と並び替えを実施します
担当者がTeamsにアクセスしてPowerBIタブを開いたときに集計されたグラフを表示させる

構成図ですが・・・

f:id:ecb_ssakagami:20200401180955p:plain

①カメラアプリでAzure Faceと繋いで年齢、年代を取得(判断はAzure任せ)
②結果をSharePointにエクセルで保存
③Microsoft Flowからエクセルデータ読み出してPowerBIで解析
④Teamsの担当者がPowerBIを開いたときにグラフ表示


天の声
こんなのできたでー
えらいひと
RTJはコロナの影響で中止や!
おつかれさん!
ほな

f:id:ecb_ssakagami:20200401182235p:plain

既読
1:30
ーーーーー

ということでマイクロソフトさんがRTJのリカバリプランとしてそのうち公開されるはずです!
※コロナ禍の影響で遅れているようです

~ecbeingでは、新しいことに楽しんでチャレンジできるエンジニアを大募集中です!~
careers.ecbeing.tech



.NET Core の設定情報の仕組みをしっかり理解したい方向け基本のキ【その2】

f:id:ecb_mkobayashi:20190924113406p:plain

こんにちは、アーキテクトの小林です。

前回の記事では、さまざまなプロバイダから提供される情報がフラットな KeyValue データ構造に変換され、後勝ち方式でカスケーディングされていることをご紹介しました。

今回の記事では、フラットな設定情報から階層構造を持ったクラスのプロパティに値をバインドする方法と、設定ファイルが更新されたときに自動的に設定情報を再読み込みさせる方法を紹介します。

まだ前回の記事をお読みでない方は以下をお読みください。 blog.ecbeing.tech

続きを読む

ウォーターフォール型PMと新人が半年間スクラムと向き合って感じたこと(新人編)

  • はじめに
  • 新人目線でスクラム開発を振り返ってみて
    • スクラム開発の良さその1: 恐れずに早く機能を作れ、リリースできる
    • スクラム開発の良さその2: 誰か1人に機能開発の責任を押し付ける…という考えがなくなる
    • スクラム開発の良さその3: 打ち合わせがいっぱいあるので、仲良くなれる機会が多い!
  • まとめ & おわりに

はじめに

こんにちは!ecbeingの浦…もとい蓑代です。
※結婚して名前が変わりました

今回は、こちらの記事の「新人編」の位置づけとして…。
blog.ecbeing.tech

ウォーターフォール型開発を知らない新人目線から、スクラム開発について感じた事を書いていこうかなと。

ちなみに、私のスクラム経験や開発経験について少し触れると…。

  • スクラム開発=未体験
  • ウォーターフォール型開発=未体験
    • スクラム開発に携わる前は、保守開発を中心に行ってました

…というような感じです。
ウォーターフォール型は未経験といいましたが、職場の同期がウォーターフォール型開発であり…。
「設計書を作るの大変だー」とか「テスト項目書作るの大変だー」とかは良く聞きますが、まぁほぼほぼ知識0みたいなもんです。

そんな私がスクラム開発を通じてどう感じたのか…。 見ていきましょう!

続きを読む

ウォーターフォール型PMと新人が半年間スクラムと向き合って感じたこと(PM編)

はじめに

こんにちは。ecbeing金澤です。
浦さんと共に、レビュー最適化サービスReviCoの開発に携わっています。

 

ReviCoでは、よりアジャイルにプロダクトを成長させるために、昨年秋からスクラム開発を導入しました。
私も浦さんもスクラム未経験の状態からのスタートだったのですが、特に私の場合は、長くウォーターフォール型開発をやってきたこともあってか、スクラムの考え方や進め方に最初はかなり戸惑いました(今でも完全に克服したわけではないですが…)

 

今日はそのあたりを記事にまとめられればと思います。

続きを読む