常連

## テーマ、知りたいこと
みなさんの思うアジャイルという概念についてお聞きしたいです。
よくスクラムと同列に語られがち(主観)と思っているのですが当然スクラムではないアジャイルもあるわけで、具体的に言語化できないのがもやもやしています。

## 背景、状況
アジャイルであれ！と色々なことに要件や手順を踏む必要を生むことは本来すぐにアラートがあがるもの、開発が生まれるものを時間がかかるようにしていると思ってしまう。
また、さまざまなところで語られているテーマではあるが核心をつく、とは言わずともなるほどなと納得できるだけの言語化に自分はまだ出会ったことがないためみなさんの考えを知りたい。


アジャイルとは何なのか？

バーンアップチャートとバーンダウンチャートはどう使い分けますか？
チームでバーンアップチャートとバーンダウンチャートの導入を検討していますが、開発でどのように利用されているかをお伺いしたいです。

個人的な解釈ですが、目的は以下の認識です。
バーンダウンチャート
- 期間の終了までに残工数を0にできるか。MVPにしてなるべく最小限な状態にして0を目指す
バーンアップチャート
- 残工数ではなく、完了した工数に着目。チームの平均ベロシティを把握するために活用

それぞれ利用用途が違うと思うので、
- どのように運用しているのか
- 運用していて課題と感じることは何か
伺いたいです！



バーンアップチャートとバーンダウンチャートはどう使い分けますか？

## 以下2冊のどちらがおすすめでしょうか？

[Adaptive Code　～　C#実践開発手法　第2版](https://www.amazon.co.jp/Adaptive-Code-%EF%BD%9E-C-%E5%AE%9F%E8%B7%B5%E9%96%8B%E7%99%BA%E6%89%8B%E6%B3%95-%E7%AC%AC2%E7%89%88-Gary-McLean-ebook/dp/B07DJ2BL4Y/ref=sr_1_1?crid=AN43Z7E5LEM0&dib=eyJ2IjoiMSJ9.N1mmwXYtBkSbpsYhEJggJ0LMU6sF_7VjIg-F8n6Ac8fnRCGcHue9PCXZyojgN2SJGehgmMHg9MA6vto-r9ghgCep-TkWnoZDnvfaos_kAeA89QfX7B8sMSBJkufSCT0xkHPttSxpatr78Z8FHBJzpjjrnmj2G362ROR7douvgzScNTkuZycwqNrDVqxc3R_73KjzUj3XGR78eThnZfGYdRVteYzo501pcBn16OBxP27M4lJm2a8gSqJd34WIpmXRIcDwhYcjg4lyPH993Jp-DJDqDj55Aczxm5023zrN838.wtt-KGqT3_Xou-bcL70cTpRIc-pLKI5uOCSqAc84mO0&dib_tag=se&keywords=adaptive+code&qid=1713521832&sprefix=adaptive+%2Caps%2C205&sr=8-1)
[アジャイルソフトウェア開発の奥義 第2版](https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9-%E7%AC%AC2%E7%89%88-%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E9%96%8B%E7%99%BA%E3%81%AE%E7%A5%9E%E9%AB%84%E3%81%A8%E5%8C%A0%E3%81%AE%E6%8A%80-%E3%83%AD%E3%83%90%E3%83%BC%E3%83%88%E3%83%BBC%E3%83%BB%E3%83%9E%E3%83%BC%E3%83%81%E3%83%B3/dp/4797347783/ref=sr_1_1?crid=3KRRNXVC1TP2P&dib=eyJ2IjoiMSJ9.rd2DLDLztNBUWuDfACcY29t584e0lYpe45o_EEBSc8XGjHj071QN20LucGBJIEps.m6R4axDZpB0Ysa6qc3ONPNkAa1KINMJGtretLmeJlJI&dib_tag=se&keywords=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9&qid=1713521848&sprefix=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AE%2Caps%2C184&sr=8-1)

## 質問者について

- オブジェクト指向を用いた設計を学びたいプログラマ
- 上記2冊の評判が大変良いため興味を持っている
- Java、C#ともに経験あり
- デザインパターンはTemplate MethodとSingletonくらいしか知らない初学者
- アジャイル開発はDeveloperとして経験あり

## 期待していること

目次を見たところ内容が2冊とも似ており、決定的な違いは言語くらいの印象なので、「自身が業務で使用している言語が記載されている方の書籍を買えば良いのでは？」という漠然とした理由しか思い浮かばず...。なので、2冊それぞれに対する感想やおすすめ理由など、買うに至る他の理由を探しており、皆様の意見を頂戴したいです。
「2冊とも止めてこの本を買うべき」や「2冊とも買うべき」などの第三の意見も歓迎です。

どちらの書籍がおすすめでしょうか？

この投稿は不適切な内容を含んでいたため、削除されました。
ご理解いただけますと幸いです。

プログラミングについて

いつもお世話になっております。

システム開発を行う中で、アジャイル開発を行い、最終的に基本設計書を起こしています。
開発サイクルが早いため、詳細設計書まで書ききれていません。

一度、開発プロセスを見直し、詳細設計書を記載したいと考えています。

APIを開発しAPI設計書は作成しているのですが、
APIの内部設計までは制作できておりません。
私の会社では、サーバーサイドの開発とクライアントサイドの開発が、
遠距離で別れているため、シーケンス図、API設計書、画面設計書が
どうしても中心になってしまっております。

ソース上にコメントを残しているのですが、それでも、これじゃまずいとおもい現在に至ります。

テーブル設計書しかり、ドキュメントが追いついて来ない場合が多々あります。
それがその状況であまり必要でないため、後回しになってしまっているためだと思いますが、
ドキュメントを起こす手間が否めません。これを見直すために、開発プロセスを見直すのですが、
ドキュメント作成に手間がかかりすぎて、開発があまりにも遅くなるのもどうかと思ってしまいます…。

皆様にご教授頂きたいのですが、

1. APIの内部設計書の内容・精度
2. 設計書のドキュメントのおすすめ
 (私は、Excelと、WebサービスのCacooなどを利用していますが、Excelの内容が悪いのか手間です)

上記、2点をご教授いただけないでしょうか。

よろしくお願い致します。

設計書の記載内容について

### 前提・実現したいこと

SES(準委任契約)で協力会社もいる中で、アジャイルを清く正しく円滑に行いたい。
そのためのチーミングなど注意点を知りたい。
そもそも委任契約が向いていないのであれば、清く正しい契約形態を知りたい。
※前向きなご意見をお聞きしたいです。

#### 登場人物
発注元A社、受注B社、B社の協力会社C社(B社と準委任契約)、C社の協力会社D社(C社と派遣契約)
それぞれに数名ずついるとして。

### 発生している問題

気になっているのは「作業指示系統と契約ってどうするといいのだろう？」ということです。

アジャイル開発は、各メンバーが顧客と一緒に開発していきます。
アジャイルでは「これ作っといて」「はい・・・・できました〇〇億円です」ということはありません。
実際にやってみて、どんどん良いものを各メンバーが協調して作っていく形になりますし、自主性が重んじられます。

一方準委任契約では、作業管理者が存在し、作業者への指示はその人を必ず経由するようになっています。
※作業者への直接指示は偽装請負となります。

アジャイル開発で行う場合、作業指示というものはあまり存在せず、顧客と協議していく中で「じゃああれをやろう」と決まっていくかと思います。
その中では、作業管理者は必ずしも作業者に指示を出しませんし、規模が増えてスクラムオブスクラムとかになっていけばPJが複数のチームで構成され、例えばB社の社員は個々人が別々のチームになることも考えられます(場合によってはD社の社員がC社の社員がいないチーム、C社の社員がB社の社員のいないチームに行くこともあり得ます)。そうなると作業管理者が全作業者に作業指示を与えるのはいよいよ困難になります。

清く正しく、それでいて円滑に開発をするためには、契約形態やチーミングをどのようにしていけばよいでしょうか。アドバイスいただければ幸いです。

SES(準委任契約)でアジャイルってどうやればよいのだろう

アジャイルな見積もり手法において質問です。

ストーリーの相対見積もりを
**「作業規模を表すストーリーポイント」**ではなく
**「時間」(人日/人月)**の単位にするのはNGなのでしょうか？

個人的な解釈としては
**「作業規模を表すストーリーポイント」**がオススメであるけれども
相対見積もりのルールに準じていれば**「時間」**で見積もっても問題ないと
考えています。

皆様のご意見をお聞かせ頂けたら幸いです。

アジャイルな相対見積もりにおいてストーリー見積もりの単位を「時間」にするのはNG？

今自分が携わってる案件(初期開発は終わって7年ほど保守されてる段階)の話なのですが、
Redmine上に都度都度改修依頼(小さなものだとSlackで)や改修内容の詳細を記したExcelファイル等はあるのですが、
仕様について一括で管理されているドキュメントというものが存在せず、今動いてるものが仕様書という感じです。

この案件にアサインされていてよくあるのが、既に退社した人が開発した機能や複雑度の高い機能については
上流から下流にいる人間誰1人把握していない場合も多く、

上流の人『これバグっぽくない？』→RedmineやSlack、コミットログを1時間ほど漁る→『あ、これ仕様です。』
というような全く生産性のない作業や、

上流の人『ここの仕様どうなってるの？』→誰も答えられない→『調査だけでn日かかります。』
といったことが結構あります。

今いるメンバーの知識に依存して業務が回っている面が多いので、
特に困るのが今アサインされてるメンバーが退社して入れ替わりが発生したり
新入社員が新たにアサインされたときで、『引き継ぎ』だけで結構な日数がかかってしまいます。

この手の仕様を把握できてない故に発生する作業や課題に直面する度
「ドキュメントがもうちょっとまともに管理されてたらなぁ」と思ってしまいます。。。

勿論運用される年数や規模にもよるとは思うのですが、システム開発における
システムの仕様等を記したドキュメントってどういう形でどこまで管理されるべきなのでしょうか？
漠然とした質問ですいません・・・