JSON.stringify()・.json()について
それぞれについて
- JSON.stringify()・・・JavaScriptの組み込みメソッドで、JavaScriptの値（オブジェクト、配列、数値、文字列など）をJSON形式の文字列に変換（シリアライズ）する。このメソッドは、JavaScriptの値をJSON形式の文字列に変換して、他のシステムやサーバーとデータを交換する際に使用される。
- .json()・・・Fetch APIとExpress.jsのレスポンスオブジェクトで使用されるメソッド。Fetch APIの場合、.json()メソッドはHTTPレスポンスボディをJSONとして読み取り、その結果をJavaScriptのオブジェクトまたは値に変換（デシリアライズ）される。一方、Express.jsの場合、.json()メソッドはJavaScriptのオブジェクトまたは値を取り、その内容をJSON形式のHTTPレスポンスボディとしてクライアントに送信する。
graphql-request, axios, fetch関数、何が違うのか比較検討してみた
目的
graphql-requestがプロジェクトで使用されることになったが、そもそも知らなかったので簡単に調べてみた。
また、他の選択肢とどう違うのかが気になったので、axios, fetch関数の特徴とメリットデメリットについて考えてみた。
graphql-requestとは
GraphQLクエリやミューテーションを送るための最もシンプルなFetch APIラッパー。npmパッケージとして提供されており、node.jsまたはブラウザにインストールして使用することができる。
主な特徴
使用例
シンプルな例
下記のコードでは、特定の映画（ここでは"Inception"）のリリース日とその出演者の名前を問い合わせている。graphql-requestはPromiseを返すので、async/awaitを使用して結果を受け取る。
また、より複雑なクエリやミューテーション、またはヘッダー情報を含むリクエストなども同じAPIを通じて送信することができる。
const { request, gql } = require('graphql-request') const endpoint = 'https://api.graph.cool/simple/v1/cixmkt2ul01q00122mksg82pn' const query = gql` { Movie(title: "Inception") { releaseDate actors { name } } } ` const fetchData = async () => { try { const data = await request(endpoint, query) console.log(data) } catch (error) { console.error(error) } } fetchData()
react-queryと組み合わせて使用してみる
import React from 'react' import { useQuery } from 'react-query' import { request, gql } from 'graphql-request' const fetchMovie = async () => { const query = gql` { Movie(title: "Inception") { releaseDate actors { name } } } ` const data = await request('https://api.graph.cool/simple/v1/cixmkt2ul01q00122mksg82pn', query) return data.Movie } export default function App() { const { isLoading, error, data } = useQuery('movieData', fetchMovie) if (isLoading) return 'Loading...' if (error) return `An error has occurred: ${error.message}` return ( <div> <h1>{data.title}</h1> <p>{data.releaseDate}</p> <ul> {data.actors.map((actor, index) => ( <li key={index}>{actor.name}</li> ))} </ul> </div> ) }
axios・fetchで置き換えてみる
axiosの場合
import axios from 'axios' import { useQuery } from 'react-query' const fetchMovie = async () => { const query = ` { Movie(title: "Inception") { releaseDate actors { name } } } ` const { data } = await axios.post('https://api.graph.cool/simple/v1/cixmkt2ul01q00122mksg82pn', { query }) return data.data.Movie }
fetch関数の場合
import { useQuery } from 'react-query' const fetchMovie = async () => { const query = ` { Movie(title: "Inception") { releaseDate actors { name } } } ` const res = await fetch('https://api.graph.cool/simple/v1/cixmkt2ul01q00122mksg82pn', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ query }), }) const json = await res.json() return json.data.Movie }
このコードだけ見るとそんなに大差がないように感じる。
それぞれのメリデメ
graphql-request
メリット
シンプルで直感的なAPIを提供し、GraphQLクエリやミューテーションを手軽に送信できる。
ラッパーが薄く、依存関係が少ないため、パフォーマンスのオーバーヘッドがほとんどない。
デメリット
GraphQLのクエリを送信する基本的な機能しか提供しないため、より高度な機能（例えば、自動リトライ、タイムアウト設定など）が必要な場合には適していない。
axios
メリット
axiosは、ブラウザとNode.jsの両方で動作する非常に人気のあるHTTPクライアント。リクエストとレスポンスのインターセプター、リクエストのキャンセル、JSONデータの自動変換など、強力な機能を備えている。
HTTPリクエストのタイムアウトを設定するなど、高度なカスタマイズが可能。
デメリット
axiosは、フェッチAPIをラップしたライブラリなので、フェッチAPIが利用可能な場合（モダンなブラウザやnode-fetchを使用するNode.jsの環境）は、その利用を検討する方が良いかもしれない。
GraphQLに特化したライブラリではないため、GraphQLのクエリを手軽に送信するための特別な機能は提供していない。
Reactのチャートライブラリを比較検討してみる
目的
chartライブラリの選定に先駆けて、各ライブラリの比較を行いたい。
仕様やデザイン（Figma）がFIXしていないので、あくまで仮選定。
実装が必要になりそうな仕様
- 棒グラフ（ネガポジのスタックバーチャート）の実装
- 折れ線グラフを混合実装
- 棒グラフは途中期間から色が変わる
- 折れ線グラフは途中期間から点線になる
- etc…?
npm trends
選定基準
- 拡張性（仕様を満たせそうか）
- スター数
- アップロード日
- サイズ
Tips
チャートの描画にはSVGとCanvasがある。
SVG（Scalable Vector Graphics）とCanvasは、ウェブ上でグラフィックを描画するための2つの異なるテクノロジーで、それぞれ特徴と利用シーンが異なります。
SVG（Scalable Vector Graphics）
ベクトルベース: SVGは、数学的な形状とパスに基づいて画像を記述するので、拡大・縮小しても品質が失われません。
DOMとの統合: SVG要素はHTMLのDOM内に存在するので、CSSやJavaScriptでスタイリングや操作が容易です。
アニメーション: CSSアニメーションやJavaScriptを使用してアニメーションを作成することができます。
パフォーマンス: 大量の要素を持つ場合、パフォーマンスが下がることがあります。
まとめ
react-chartjs-2かRechartsが良さそう。
2つのライブラリをハンズオンしてみて、使い勝手の違いなどを確認し、選択したい。
shadcnを使用してみる
目的
プロジェクトでTailwind CSSを使用することになったが、Tailwindのみだとstate周りがつらいのでRadix UIを使うことにした。
shadcnであればコピペでTailwind+Radixのコンポーネントサンプルを使用することができるそうなので、使用方法を確認してみた。
インストール～コンポーネントの使用
- ドキュメントのIntroductionより
Radix UIとTailwind CSSを使用して構築された再利用可能なコンポーネントです。
これはコンポーネントライブラリではありません。あなたのアプリにコピー＆ペーストできる再利用可能なコンポーネントのコレクションです。
コンポーネントライブラリではないとはどういう意味ですか？依存関係としてインストールしないという意味です。npm経由で利用することも、配布することもできません。
必要なコンポーネントを選んでください。コードをコピーしてプロジェクトに貼り付け、必要に応じてカスタマイズする。コードはあなたのものだ。
CLIで下記コマンドを叩くと、関連ライブラリがインストールされ、必要なファイルが作成される。
npx shadcn-ui@latest init
あとはshadcnに用意されているコンポーネントで、使用したいものをCLIで操作すると、/components/ディレクトリ配下にコンポーネントがインストールされる。
npx shadcn-ui@latest add [Component]
インストールされたコンポーネントのvariantやCSSを修正して、プロジェクト内のコンポーネントとして使用する。
また、components.jsonのaliasesを変更することで、管理するディレクトリの変更ができる。
{ ～省略～ "aliases": { "components": "@/components", "utils": "@/lib/utils" } }
Tanstack Queryをキャッチアップしたい
目的
Tanstack Queryをプロジェクトで使用することになった。
元々データフェッチやAPI周りの知識も少なかったので、この機会にしっかりキャッチアップしたいと思った。
Tanctack Queryについて
about
Webアプリケーションのためのデータフェッチライブラリとしてよく説明されるが、より技術的な用語では、Webアプリケーションのフェッチ、キャッシュ、同期、およびサーバーステートの更新を容易にする。
React Queryから改名してTanstack Queryになった。Vueなどサーポート範囲が増えたらしい。
npm trendsによると直近1年では一番使用されている。
簡単な使い方
useQuery Hook を利用したコード。データフェッチはfetch関数で。
import { useQuery } from "@tanstack/react-query"; const fetchTodos = async () => { const res = await fetch("http://localhost:3001/todos"); return res.json(); }; const Todo = () => { const { data: todos } = useQuery(["todos"], fetchTodos); return ( <div> <h1>Todo一覧</h1> <ul> {todos?.map((todo) => ( <li key={todo.id}>{todo.name}</li> ))} </ul> </div> ); }; export default Todo;
また、ルートファイルで QueryClientProvider、QueryClient の設定を行う。Todo コンポーネントで useQuery を利用するためには Todo コンポーネントを QueryClientProvider で wrap する必要がある。
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'; import Todo from './components/Todo'; import './App.css'; const queryClient = new QueryClient(); function App() { return ( <QueryClientProvider client={queryClient}> <div className="App"> <Todo /> </div> </QueryClientProvider> ); } export default App;
useQuery の戻り値のオブジェクトは、 data 以外にもさまざまな情報が戻される。
参照：
useQuery | TanStack Query Docs
豊富なオプション
useQueryやuseMutationにオプションを渡すことができる。
POST リクエスト成功時に実行される onSuccess, エラー時に実行させる onError, 成功、エラーに関わらず実行される onSettled、POST リクエスト実行前に実行される onMutate などがある。
例えばonSuccessを使用すると、追加ボタンをクリックした後にリクエストが成功するとリロードなどを行わずに追加したデータをブラウザ上に反映することができる（リフェッチ処理ができる）。
import { useMutation, useQuery, useQueryClient } from '@tanstack/react-query'; //略 const Todo = () => { const [name, setName] = useState(''); const queryClient = useQueryClient(); //略 const addMutation = useMutation(addTodo, { onSuccess: () => { queryClient.invalidateQueries('todos'); }, }); //略
残課題
optimistic updateについて、挙動や使用するべきケースを確認したい。
Optimistic Updates | TanStack Query Docs
アジャイルサムライ読んだ
目的
プロジェクトがアジャイル開発になり、アジャイル開発やスクラム体制について理解を深めるために「SCRUM BOOT CAMP」を読んだ。
現状自分にとってスクラム体制でのチーム開発が非常に楽しく感じていて、さらに理解を深めていきたいと思ったので、アジャイルサムライを読むことにした。
1日1章ずつ読みながら、自分なりに要点をまとめ感想を書きたい。
要点整理・感想
1部 アジャイル入門
1. ざっくりわかるアジャイル開発
- アジャイルな計画の立て方
大きな問題は小さくし、本当に大事な課題に集中する。質はしっかり担保し、フィードバックをちゃんと求める。大事な事が変わってしまうこともある為、変化に柔軟になる。成果に責任を持つ。
- プロジェクトが上手く行っている度合いの測定
ベロシティを元に完了の期限を推測できる。完了にはすべての作業（分析・テスト・設計・コーディング...etc）が含まれている。ただオプションを全て実装するわけではない。
- 3つの真実と、それを受け入れる効能
1. プロジェクト開始時点にすべての要望を集めることはできない。
2. 集めたところで、要望はどれも必ずと言っていいほど変化する。
3. やるべきことは、与えられた時間や資金よりも多い。
これを受け入れることができれば、霧が晴れたような視界を得られる...
- 感想
あらためて、アジャイル開発は好きだなと感じた。結局お客さんに良いものが届くし、縦割り組織ではないのでチームメンバー各々が責任を持つ一方で現実的で健康な開発体制を組めると思う。また、期待をマネジメントする、というTipsは面白かった。透明性を保ちながら同時にそこも意識して仕事をしていこうと思う。
2. アジャイルチームのご紹介
- 典型的なアジャイルチームはどんな姿をしているのか
アジャイル開発では役割がはっきりと分かれていなく、プロジェクト成功の為ならなんでもする。さらに、開発工程（分析・設計・実装・テスト）が途切れることなく連続的な取り組みになる。また、アジャイルプロジェクトではチーム一丸となって成果責任を果たす。
- 自分のチームをどう編成すれば良いのか
アジャイル開発の原則は自己組織化。そのために成果責任と権限委譲が必要になってくる。実際に実装したものをお客さんにデモをすれば、成果責任に対して自覚的になれる。またクロスファンクショナルな組織であれば、スピード感のある開発ができるようになる。ゼネラリストの方が向いている。
- どんな心構えでチームに参加すれはよいのか
アジャイル開発に曖昧な状況はつきもの。要求がかわることにも柔軟に対応する必要があるし、なんなら受け身ではなく自ら問題を探す姿勢も〇。また、チームで成果を出していく為、協調性も非常に大事。
- 感想
成果責任にはハッとさせられるところがあった。仕様がまだ決まってないから進められない...UIデザインが複雑すぎて作れない...なんて状況はいくらでもあるが、勝手に自分のポジションを限定して嘆くのはおかしいよな～と気づいた。何かあった時に自分から発信できれば、より価値があるものを作れるようになるなと感じた。
2部 アジャイルな方向付け
3. みんなをバスに乗せる
- インセプションデッキと10の課題
インセプションデッキを共有することで、プロジェクトで期待されていることをプロジェクトメンバーで共有することができる。ただし、これは単なるとっかかりでしかない為、プロジェクトの状況や方針の変更があれば、インセプションデッキも改訂しなければならない。
1. 我々はなぜここにいるのか
2. エレベーターピッチを作る
3. パッケージデザインを作る
4. やらないことリストを作る
5. 「ご近所さん」を探せ
6. 解決案を描く
7. 夜も眠れなくなる問題は何だろう？
8. 期間を見極める
9. 何を諦めるかはっきりさせる
10.何がどれだけ必要なのか
- 感想
今回のプロジェクトはPOやステークホルダーや一部の開発メンバーでやってしまったので、参加はできなかった。ただ、以前は眺めるだけだったインセプションデッキをより具体的にイメージできるようになりたいので、しっかり腑に落としたい。
4. 全体像を捉える
- インセプションデッキの前半でプロジェクトの目標を理解する
1. 我々はなぜここにいるのか
自分自身が現場に言ったり、顧客になってみたりすることで、顧客の考えや本当に必要としていることを知ることができる。
2. エレベーターピッチを作る
練られたエレベーターピッチは重要で、次の利点が得られる。
・明快になる。プロダクトが具体的に何で、誰のためのものなのか。
・チームの意識を顧客に向けさせる。プロダクトは何を提供し、なぜそれが必要なのか。プロダクトの強みと顧客にとっての価値が分かる。
・核心を捉える。本当に重要なのは何なのか。
3. パッケージを作る
パッケージを通してどんな訴求ができるのか。また客観的に見て、自分がそれを欲しいと思えるのか。
4. やらないことリストを作る
スコープを視覚的に理解することは非常に重要。
5. 「ご近所さん」を探せ
プロジェクトコミュニティは考えているより常に大きい。信頼関係を築いておく。
- 感想
「ご近所さん」を探せ、にはハッとさせられた。エンジニアにもコミュニケーション能力は必要だし、このような視点を普段から持てるだけで、ちょっとした懇親会などの意味付けも変わってくるので知れてよかった。
5. 具現化させる
- インセプションデッキの公判では「どうやって」の理解を進める。具体的な解決案と、プロジェクトのスコープを決める。
解決できる課題は以下。
6. 解決案を描く
図にするメリットはたくさんある。ツールや技術に対する期待のマネジメントや、プロジェクトの境界やスコープの可視化、リスクを伝えられることなど。イベントストーミングがこれにあたるかな？？
7. 夜も眠れなくなる問題は何だろう？
リスクを表題化し議論することは意味がある。取り組む値打ちのあるリスクをしっかり見極める。
8. 期間を見極める
原則として、プロジェクトの期間に比例して、失敗のリスクは増大する。ステークホルダーへの提案は2つの選択肢がある。期日を決めてスコープを調整するか、ある程度コアな機能は実装するつもりで期日に幅を持たせるか。大事な事として、提案がコミットメントととらえられてはいけない。実際の期日は作業を進めてみて、そのフィードバックを元にしないと正確性は担保できない。
9. 何を諦めるかはっきりさせる
品質は常に優先事項であり、期日と予算・スコープはトレードオフの関係にある。問題は何を諦めるか決めること。奥義トレードオフスライダーを使う。
10.何がどれだけ必要なのか
まずはPOの決定が非常に重要。コストの計算は簡単で、工数と人日を掛ければよい。
- 感想
プロジェクトがまず半年に最初のMVPのリリースになった時は驚いたが、この章を読むとそこが腑に落ちたので良かった。プロジェクトの期間に比例して失敗のリスクは増大するし、ウォルマートの在庫システムを作成したランディ・セットによると、長くてもファーストリリースの期間は6ヶ月以内にした方がよいらしい。期日を固定化し無限に増えるスコープを調整しようとするのは正しいと思った。
3部 アジャイルな計画づくり
6. ユーザーストーリーを集める
ユーザーストーリーとは、仕様を詳細に書き留めるものではなく、「会話の約束」という位置付けくらいの、簡単なものにする。機能を思いついた時点では、それがまだ必須のものか分からない。
また、ユーザーが理解できる言葉遣いで、ユーザーにとって価値のあるものを作る。様々な図を使うのも良い。
7. 見積もり：当てずっぽうの奥義
見積もりの目的は、結果を予言することではなく、達成可能な程度に現実的か確認するため。そのための見積もり手法として下記の3つが大切になる。
・今後の計画を立てられる
・見積もりは当てずっぽうだという前提を踏まえている。
・ソフトウェア開発の複雑さを理解している。
また、具体的な見積もり（継続的な）は下記の2つ。
・それぞれのストーリーを相対的に見積もる。
・ポイントを元にして予測を立てる。
- 感想
見積もりに関しても、やはり原則が大事だと感じた。予めこれらを知っているかいないかで、取り返しのつかない事態に陥るかどうか決まる。
8. アジャイルな計画づくり：現実と向き合う
プロジェクトに困難はつきもの。次の基準を満たすような計画をたてなければならない。
- 顧客にとって価値ある成果を届けられる計画・・・リリースの単位をMMFという。世の製品の64％は使われないほとんど機能。顧客にとって重要なものから作成する。
- 分かりやすくありのまま伝える誠実な計画・・・奇跡のマネジメントを信じない。表面を取り繕った誤魔化しに加担しない。
- 約束したことを守り続けられる計画・・・ベロシティを安定化させ、それを基に計画を立てる。
- 必要に応じて変更できる計画・・・スコープを柔軟にする。
- 感想
この計画で進めていくには、POやステークホルダーのアジャイル開発に対する理解が必要不可欠だと思った。そこが無い時に誠実に対応できる人間力も身に着けていければ良いと思う。
4部 アジャイルなプロジェクト運営
9. イテレーションの運営：実現させる
- 一言で表されるSBIをちゃんと動くソフトウェアに変換する方法
1. 分析。何もかもドキュメントにしない。必要な時に必要な分だけアウトプットする。
2. 開発。設計をしっかり行い、動く状態にしながら進んでいくのが理想。
3. テスト。適切に動作する確認をしながら進む。後に積み残しをしない。
- 感想
必要な時に必要な分だけ、というのはアジャイル開発では非常に重要な視点だと思った。ついつい、その場で詳しく全てを理解しようとしてしまうが、結局無駄に終わることがこれまでも多々あった気がする。
5部 アジャイルなプログラミング
12. ユニットテスト：動くことがわかる
アジャイルな開発プロセスのベースとなるのは確固たるプラクティスの実践。
バグを見つけた時の対処としては、必ず失敗するテストを書いて修正する。これはバグの本質を理解することになるし、自信をもってバグを修正したと言える。また、同じバグが二度と出ないことを保証する。
- 感想
テストについてまだ未熟すぎる。しっかりキャッチアップしながら沢山テストを書いていきたい。またカバレッジ（網羅性）だけを大事にするよりも、コードに自信を持てるような本質的なテストを書くことを意識する。
13. リファクタリング：技術的負債の返済
時間とともに技術的負債は必ず積み重なっていく。
積み重なってから大掛かりにリファクタリングのタスクとして切り出すのではなく（クライアントにも納得してもらいにくい）、コツコツと少しずつやっていく。
- 感想
良いコードが書きたい気持ちは強い方だと思う。だがまだまだ経験も知識も足りないと思っているので、別途リーダブルコードはまず読みたい。
14. テスト駆動開発
- 必要なテストだけ書く
- システムが既に実装されていると考えて先にテストを書く
- 感想
すぐにTDDを実践するのはプロジェクトの環境もあり難しいかもしれない。まずはテストの基礎をしっかり理解した後に挑戦していきたい。
15. 継続的インテグレーション：リリースに備える
- リファクタリングやTDDと同じく、インテグレーションもコツコツやる。
SCRUM BOOT CAMPを読んでみた
まとめと感想
1. ロールを現場にあてはめる
1. ロールはPO・SM・開発チーム
2. ロールはチーム内での責任範囲を明確にする。
3. 兼任はしない。
4. 具体的に何かが足りていないなら、チーム全体でどう補っていくか考える。
感想：ウォーターフォール開発での責任転嫁リレーが好きではなかった。チームで考えるスクラム開発は好きかもしれない。
2. どこを目指すのか明確にする
1. ゴール（どういうことを実現するのか）やミッション（絶対に達成したいことは何か）を考える
2. インセプションデッキを作成する。全員が参加し意見を出し合う。
感想：バランスが大事だと思った。全員で話し合うのは大事だが、叩き台が無い状態では収集がつかなくなるし、一部の人で決めたものを一方的に伝えるだけでも意味がないし。
3. プロダクトバックログ（PBI）を作る
1. PBIは実現したいすべての事が書かれている一覧。重要度は様々。リリース時期や、そこまでに何を実現するか、現在の進捗状況など、PBIを見れば把握できることが重要。
2. PBIはフォーマットは決まっていない。機能・要望・要求・修正事項などの項目がある。もしくはユーザーストーリーとして項目を作成する場合も。
3. PBIは変更されることが前提だが、変更が大きすぎると、計画も大きくズレてしまうため、最初に実現したい重要な項目に漏れがないことを確認するべき。
4. 開発チームはPBIの並び順に沿って開発していく。PBIの項目は重要度で優先順位を付け、並び替える。優先順位はプロダクトオーナーが責任を持つ。
5. スクラムチームは絶えずPBIの状況を把握し、必要であれば見直しをする。
6. PBIの作成は大事だが、今後継続して修正することも考慮し、一度に時間をかけすぎないことも重要。
感想：
- PBIは機能単位で記述してある？ フロントとバックで同じPBI？ フロント終わってないのに、完了のチェックマーク入ってる？
- PBIはスクラムチームから干渉可能？（現プロジェクトの場合）
- 何かあればPBIへ干渉するべき
- 過去にタスクを選択する際に、PBIの優先順位に沿っていないことがあったので、気を付けたい。
4. 見積もりをしていく
1. SBIの項目から実際にどんな作業があるか着目する
2. 開発チームで作業を相対見積もりする
3. 作業自体は不確実なものなので、フィボナッチ数列の値を使うなどし、細かな誤差は気にせず見積もる
4. 見積もりはあくまで推測なので、先々まで細かく時間をかけて見積もりをすると、推測が外れた場合に見積もり時間が無駄になる可能性がある。
感想：
- スクラム開発のPBIの見積もりは、開発の見積もり自体が不確実という前提に進めようとしていて、非常にフレームワークとして柔軟だと思った。また、少しやってみたら具体的に上手く行くところ行かないところが出てくるから、それを改善していきましょう、というスタンスが、すごく現実的だし前向きに取り組める感じがして良いなと思った。
5. 見積もりをより確実にする
1. 開発チームでプランニングポーカー
2. 開発者それぞれが発言し対話を通して認識のズレを合わせたり、見落としていた部分を洗い出すなどする。
3. 見積もれないことが分かることも大事。
感想：
- 自分の分からないところを見積もるのは大変だが、やっているうちにお互いの作業の理解にもなり良いと思った。
6. この先の計画を立てる
1. ベロシティが分かれば先の見通しが立つ。
2. ベロシティは決めるものではなく、測るもの。逆算思考ではなく、積み上げ思考。
3. 慣れるまでの期間はベロシティがなかなか上がらないこともある。
4. PBI以外にも、リリースまでのマイルストーンを図にするなど、先のことが分かるように整理しておくとよい（リリース計画の作成）
感想：
- ついベロシティを上げるために、タスクの進捗をごまかしたい邪念が出てくる笑。でも不確実なプロジェクトを前に進めていくために、1つ確実なベロシティを測定していくことが重要。その上でスプリント毎にベロシティを改善していく話し合いをしていくことが大事なんだと理解した。
7. 詳細な計画を立てる
1. スプリントプランニング
1. どのPBIを達成できるか、ベロシティを基にPOと開発チームで決める。
2. PBIからタスクに落とし込み、タスクの見積もりを行う。タスクと見積もり→スプリントバックログ（SBI）
3. 先まで考えすぎない。時間をかけすぎない。確実に実行できそうな具体的で詳細な計画を立てることが重要。それができれば先の予想も確実になっていく。
4. スプリントゴールをしっかり意識できるようにする。スプリント終了時のデモ手順をあらかじめ決めておくのも有効な手段。
感想：
- スプリントプランニングの際に、ゴールのデモを考えるのはすごく有効な気がした。
- スプリントゴールをかなりストレッチした目標に設定してしまっていたので、今スプリントのベロシティを基に、達成可能なラインにしていきたい。
- 現状のPBIがちょっと荒すぎる印象。。。
8. 素早くリスクに対処する
1. 毎日時間を決めて、デイリースクラムを行う。スプリントゴールを達成するために、昨日やったこと・今日やったこと・障害や問題点を伝え合う。
2. 目的は、スクラムマスターへの報告ではなく、問題の洗い出しを行い、スプリントゴールを達成するために修正を行うこと。
感想：
- デイリースクラムの目的に認識のずれがあった。ただの進捗報告にならないようにしたい。
9. 状況をうまく把握する
1. スクラムでは透明性が大事。いち早く問題にチームで気づき、微調整する。
2. タスクボードや、バーンダウンチャートなどで停滞しているタスクや問題に気づけるようにする。
感想：
- 透明性が大事。
- 現状進捗の共有はしているが、日々タスクの残工数を更新してはいなかった。
10. 何が完成したかを明らかにする
1. スプリントレビューでは何が完成して何が完成してないか説明する。また開発チームでデモを行い、フィードバックをもらう。
2. ソフトウェアは動くものを見てはじめて評価できるため、デモは重要。また、そのフィードバックはPBIの作成時点では分からなかったものが出てくるかもしれない。
3. 完成の定義はスクラムチームで話し合い、更新しながら進めていく。
感想：
- 今後スプリントが進んだでデモも見せた時に、フィードバックがたくさん出てくるイメージが沸いた。。その時に建設的な話ができるように準備をしていきたいと思った。
11. 先を予測しやすくしておく
1. タイムボックス（それぞれのイベントの時間やタイミング）をしっかり守ることで、先の予測ができるようになる
2. タイムボックスを守れないことがきっかけで、準備不足が分かったり、そのイベントがそもそも何をするものなのかを考えることができる。
感想：
- スクラムをやってみて、イベントの前に準備が必要っというのは分かってきた。今後もスプリントを重ねていくなかで工夫できることをやっていきたい。
12. 次にやることを明確にする
1. もしスプリント中にタスクが早く終わってしまったら、リファクタリング・自動テストなどを進めてもいいし、次のSBIに着手してしまっても良い。
2. PBIは常に意識し、整理しておく。PBIの編集は誰でもやってよいが、優先順位を決めるのはPO。
感想：
- PBIの内、どこまでをフォーカスして把握しておくのかが難しいと感じた。あまり先まで考えすぎてもいけないし。1・2スプリント先くらいまでかな。。。？
13. みんなの自立を促していく
1. スクラムイベントは最小限の枠組み。足りないことは足していくべきだが、ルールが詳細化しすぎると誰も守れなくなる。バランスが大事。
感想：
- チーム毎にルールを変えている理由が分かった気がする。メンバーの性格によって作るべきルールも変わってくるかも。そこが腑に落ちたのはよかった。より対話を大事にしていこうと思った。
14. ベロシティを上げていく
1. ベロシティには安定性が重要。上がり続けていてもダメ。良いスクラムチームは安定感がある。
2. ベロシティを上げたり安定させたりするために、どうすれば作業がスムーズにいくか考える。
3. ベロシティは短期間で劇的に変わるものではないし、あくまで目安となる数字である。
感想：
スクラムチーム外からリリースの前倒しなど要求されることは、あるあるだと思うが、ベロシティを基準にしたり、今後予期せぬ対応が出てきたりすることを想定して対処しないといけない。
15. 問題を見つけやすくする
1. スプリントプランニング・スプリントレビュー・スプリントレトロスペクティブはスクラムチームの全員が参加する。POは何をどこまでやるか、そのゴールを達成できたか確認する必要があるし、SMは潤滑にイベントを進める必要がある。またこのイベントは情報共有の場にもなっているため、どのメンバーにも重要。
感想：
本ではPOのタスクをみんなで支援しようとあるが、今の現場ではそれは現実的ではないかも…ただイベントの実施などに関してはなるべく柔軟にやっていきたい
16. 意図を明確にしておく
1. PBIをタスクに落としていくだけではズレが生じる。PBIをユーザーストーリーのフォーマットで伝えることで意図が明確になりやすい。ユーザーストーリーを基にデモを決めるのも良い。
感想：
ユーザーストーリーはすでにあるが、デモはそれを踏まえたものになっていなかったので、ちょっともったいない。改善していきたい。
ユーザーストーリーがPBIと並べて見れるようになったらいいのになぁ（どこに記載あったっけ）。
17. スクラムチームを支援していく
1. 問題が起きたら対処する。例えばコードの質が悪く作業効率が下がっているなら、リファクタリングのタスクを入れるなど。
2. 対処療法として問題にあたるだけでなく、そもそもなぜ問題が起こるのか、根本的な部分の解決も必要。例えばコードの品質を保つルールを作るなど。
感想：SMがチームにとってすごく重要。問題を敏感に察知して、それを上手く引き出す質問を投げかけるなどは、結構スキルも必要な気がする。
18. よりよい状態にしていく
1. スクラムチームに問題はつきもの。把握→対処のプロセスで進んでいく。
2. 問題が発生したらすぐに対処する。これはタスクを進めるより大事な事。
3. SMは障害を管理する。優秀なSMだと一覧にすると障害の数が50個以上？！
感想：
スプリント中にタスクを追加しても良い？？
19. 先の事をいつも明確にする
1. PBIは常に更新される。固定された人だけが管理せず、みんなの意見を出し合う。
感想：
改めてメンバー1人1人が参加していくことが大事なんだと感じた。ブレーンストーミング的な意味がある。
20. 手戻りを無くしていく
1. あいまいなまま進めようとするほど、手戻りが発生するリスクが高まる。
2. スプリント前にあいまいな箇所を確認しておくのがベスト。
感想：
改めてイベント前の準備って大事だなと思った。
21. ゴールに近づいていく
1. 達成すべきゴールは常に変化する可能性があるので、最新情報を確認する。
2. ゴールに近づくために2つのことを考える
1. よりチームの開発を円滑にできないか
2. 予算・期間・スコープを調整できないか（品質は調整できない）
感想：
もしリリースに間に合わない場合はスコープを調整するのが現実的だが、大きな組織になるほどそこの調整は難しくなりそうな印象。
22. さまざまな状況に対応していく
1. 自己組織化したチーム→状況に最適な人がリーダーシップをとっていく
2. 1人1人が優秀な開発チームより、助け合って進める開発チームの方がスクラムとしては良い開発チーム
感想：
自己組織化を目指す上でのリーダーシップの取り方がなるほどと思った。
メンバーは優秀であるにこしたことはないと思うが、コミュニケーションが適切に行われ、お互いを補完し合うようなバランスの取れたチームを目指したいと改めて再認識できた。
23. より確実な判断をしていく
1. 実際の作業に関係のない人の意見はあくまで参考意見。
2. コミットメントは重要。だからこそ責任の持てない約束はしない。
感想：
鶏と豚の例え話が全然良く分からない笑
24. リリースに必要なことをする
1. リリーススプリントを作成する
感想：
リリーススプリントで沢山課題が出てくるイメージが容易にできる…
結局漫画ではリリース前にずっと深夜対応している笑
25. 実践編で伝えたかった事
1. スクラム開発はあくまでフレームワーク。改めて下記メリットがある。
1. どこが上手くいってないか特定しやすい
2. 上手くいっていない問題を解消する機会がある
3. 上手く進めるためにやり方を変える機会がある
4. やり方を多少変えても影響が少ない
感想：スプリントレトロスペクティブを書かなかった理由が微妙。問題解決の場ではなく、よりよく進めていくための方向性決め、と説明すればよかったのでは？あとプロダクトの説明を省いたことについても、そこけっこう大事なのでは？と思った。
スクラム開発はだんだん身についてくるものでもあると思うので、今後も本を読み返したり、さらにアジャイルサムライを読んだりして、精進していきたい。
