【検討】カメラ買い替え検討

現在XT-1という富士のカメラを使っている。このカメラで出力される絵は、解像度が高く立体感がすごく、また色合いもすごく綺麗。記憶色というカラーでとても鮮明に思い出を残すことができる。とても気に入っているカメラ。

ただ、最近子供が大きくなってきたからか、動きが早いのでブレたり、シャッターチャンスを逃すことが多くなってきた気がする。フォーカス時、連写時のブラックアウトが気になる。ということで、カメラの買い替えを検討してみる。

画質について

フルサイズって、センサーサイズが大きいので光を多く取り込める。これによるメリットは暗い箇所でも、シャッタースピードを稼げるのでぶれにくかったりする。あとは、階調がキレに出た色々ある。 フルサイズってなんか憧れる。でも重要なポイントとして、センサーサイズ以外にもレンズとの組み合わせを考える必要がある。フルサイズでも微妙なレンズをつけていると、APS-C + いいレンズの方がいい絵がでる。富士の単焦点でとったのと、フルサイズとズームレンズで撮ったのでは、単焦点の方が綺麗にでたりする。あと、富士のレンズはフルサイズのレンズに比べて安くて軽いので、単焦点を数本持って切り替えながら使うこともできる。なのでレンズでカバー可能。

おもさ

軽い方がいい。気軽に持ち運べるし。検討している機種の重さを整理 - 6DMK2：686g(本体)、765g(バッテリー+カード) - X-H1：623g(本体)、673g(バッテリー+カード) - X-T2：457g(本体) - H-T1：390g(本体)

調べてわかったこととしては6Dmk2と、X-H1が100g差しかなかった。X-H1は意外と重いんだな。手ぶれ補正がカメラ本体にはいってるから仕方ないけど。

手ぶれ補正

手ブレ補正はあった方がいいけど、重さとのトレードオフ。 X-H1は5.5段分。手持ち1秒でも手ブレしないそうな。これはかなりすごい。望遠での撮影にも大きく貢献しそう。

ブラックアウト問題

今使っているX-T1は、かなりブラックアウトがあり、連写するとずれることが多い。X-H1はブラックアウトが改善されてる模様。グリップをつけることで、さらにブラックアウト短縮も。この辺はやっぱり一眼と比較するとまだまだですね。 X-T3は積層センサーになって、ブラックアウトフリーになるという噂もありますね。これは期待です。

まとめ

フォーカススピードやブラックアウトを考えると一眼に軍配があがります。6Dmk2も欲しいけど、重いし、レンズの値段も高くなるのでちょっと難しいですね。運動会とかでのズーム利用を考えるとフルサイズはちょっと手が届かないですね。 今のレンズ資産を生かしながら、X-T3の発売を待つことにします。で、X-H1と比較してどっちがいいかまた考えます。とりあえず毎月1万X-T3貯金を始めようと思います。節約頑張ろうっと。無駄なものは買わない。

【読了】恕-ひとに求めない生き方

恕─ひとに求めない生き方

読んだ。自分を制御できてないときがあると思って反省したので。もっと心の器を大きく育てる。 もっと怒りと向き合って、もっと相手を重んじ、そして謙虚に。

自分メモ

• 批判や誹謗は劣等感の表れ
• 自分を大きく見せると臭くなる、素直で謙虚でいる
• 怒りは疲労でしかない
• 見下す、人は人、自分は自分。それぞれに同じ価値がある。
• 思っても口にしない、という優しさ
• ひどい人は憐れだと思う
• 相手が嬉しくなるようなことを続ける、もっと人の感じ方を考える
• 誰にでも役目がある
• 言葉を発する時にこそ、自分の心を見る
• 自分が優位に立ってる的発言をしたいんだ、自分は、それよくない
• 感謝を忘れない
• まずは相手を認める、理解する、成功や長所を探す
• 思ったことをすぐに口にしない、相手の栄養になるか考える

【読了】営業の魔法

読んだのでメモ。プリセをやる上で振り返りとして読んだ。今後、技術に加えて営業力を身につけていきたい。

営業の魔法

小説仕立てで、新卒の少年が師匠に出会い、育っていくお話でした。 実際の営業現場をイメージしやすく、エンジニアとして10年やってきた私にもわかりやすくて学ぶ部分も多くありました。初心を思い出し、今の自分がプリセールスとして足りない部分が多いなって思いました。読了したのでダンプしておきます。

営業をやっていて悩んでる方にお勧めしたい本です。特に新人など営業を初めてやっている方。

自分は誰を幸せにしたいか？

この本では、営業をやる上で重要なこととして、誰を幸せにしたいのか？ということが何度も出てきた。自分はどうなのかを振り返る。 プリセールスやっていて、顧客の課題を解決したいという思いでやってましたが、改めて考えると技術でぐいぐい行き過ぎのときもあった。もっと顧客によりそって考えるべき場面があったなーと反省。今後は、本当に悩んでいるポイントを深掘りしてヒアリング、提案を聞いた顧客が笑顔になること目指す。

魔法その0：プロローグ

• 会話の進め方次第で、時間感覚かわる
• 相手が集中して話せると、時間はあっという間に過ぎる
• 3割自分、相手7割くらいで会話
• 会話自体は自分の流れに巻き込む

魔法その1：瞬間の沈黙

• 間が大切、間を作ることで考える時間を作ってあげる
• 会話の中で判断を繰り返すから、間は絶対必要

これはすごく分かる。社内でファシリテートすることが多いので、これは実体験としてわかる。昔は間に耐えられずに話を進めちゃうことがあった。みんな考えてるって気づいて、間を取るように改善した。これは実際に失敗して学んだ。特にテレビ会議とかは気を使う。

魔法その2：人間力

• 営業とは、お客様の問題を解決するお手伝いをすること。売ることが仕事ではない。あくまで数字は目標であって、目的ではないんだと思う。
• お客様と感動を共有する仕事。つまりファンになってもらう。
• 常に謙虚で、正直であること

魔法その3：売らない営業

• 顧客の悩みにフォーカスする
• 何に困っているか、アドバイザーになる
• 欲しくはないものを話されても、時間の無駄だと思われる

魔法その4：既成概念

• イメージの限界が、自分の可能性への限界。イメージしたこと以上のことはできない。
• 経験などでできあがった既成概念、常識というものに従って行動すると、可能性を見失うことがある
• 色々なものを見て、想像力を鍛える
• 自分で作った、自分の限界を常に破り続ける必要がある

魔法その5：応酬話法

• 正しく使う、説得ではなく納得してもらう
• 普段考えてることが言葉になる
• しっかり相手の話を聞く
• 応酬話法
  • 質問話法：即座に答えないで質問を繰り返し、真意を確認する
  • Yes,But話法：反対意見でもまずは受け入れる。そうすると話を聞いてくれるようになる。
  • 例話法：身近な例を列挙する
  • 聞き流し話法：本気で話すと議論に成りそうな場合、一回受け取ってから話題を変える
  • 直球話法：否定的な意見を言われたとき、自信があるときに伝える。もう一度言わせてください。

魔法その6：二者択一話法

• 二つの選択肢を用意して質問する
• アポイントを取るときも、二者択一話法が使える。来週だと前半？後半？
• 5分ください！okもらえたら30分はいける

魔法その7：イエス・バット話法

• 意見を肯定して質問を繰り返す
• 肯定したあとに、否定するのではなくさらに質問する。それで、自分で気づいてもらう。つまり自分の考えで肯定してもらう

魔法その8：質問話法

• ノーと言われたときこそ笑顔で。感情ではなく、意思で自分の行動をコントロールする。ノーと言われたときこそ、本音を聴くチャンス
• 検討するとは、今は決めないという決断
• 何を検討するのかを聞いてみる、それを徹底的に解決する

魔法その9：類推話法

• 身近なものに例える、上からではなく納得する形で伝えられる
• 例え話の引き出しを沢山持とう
• 人は説教が嫌い！ストーリーがあると聞き入れやすい
• 営業の基本：聴く、見る、伝える、この3つだけ

魔法その10：推定承諾話法

• イエスと仮定して話をどんどん進める
• もし仮にhogehoge
• 仮にという問いで、リアルな状態を想像する

魔法その11：肯定暗示方

• プロ営業、普通の営業の違いはクロージング
• ポジティブに言い切る
  • やってみませんか？ > やりましょう
  • いかがですか？ > すばらしいでしょう！
  • お時間はありますか？ > お時間を作ってください！
  • 最近、調子はどうですか？ > 最近、調子良さそうですね！
  • お会いしませんか？ > ぜひ、会いましょう！
• 営業の基本：先義後利

魔法その12：ポジティブシンキング

• 真のポジティブシンキングは、明確なビジョンのもとで、それに向かって思考を集中し、断固たる勇気を持って行動すること
• 真の成功とは、社会に還元できたものだけが唱えられる

最後に

技術者にもお勧めしたい。営業というか、仕事に向かう時の持っておくと良い姿勢について沢山学べるんではないかなーと思いました。毎日がDay1でいこう。周りに沢山すごい人がいるので、いっぱい学びます。

【読了】Kubernetes 入門 第2章

入門 Kubernetes

コンテナの作成と起動

• オーバーレイファイルシステム(aufs, overlay, overlay2なお)を利用している
• システムコンテナ(initを実行)、アプリケーションコンテナ(1つのアプリプロセスを起動)がある
• Kubernetesはアプリケーションコンテナに最適化されている
• Dockerfileはコンテナイメージ作成を自動化するためのファイル
• Dockerイメージは共有できる
• イメージのセキュリティ
  • アプリケーションやパッケージの配布に関するベストプラクティスに従う
  • 例えばコンテナにパスワードを入れない
  • ファイルシステムがオーバーレイ方式なので、ファイルを削除しても前のレイヤではファイルは存在しているので注意
• イメージサイズの最適化
  • イメージを重ねていくとサイズが大きくなる、ファイルを消してもアクセスできないだけでファイルシステム上は残ってる
  • 前のレイヤを変更した場合は、再度ビルドし直す必要がある
  • あまり変更されないレイヤ(ゴールデンイメージ)を作って、頻繁に更新のあるレイヤ(アプリ)の順でビルドするとよい
• リモートレジストリ(ECRとかDockerHubとかGCRとか)にイメージを置くことで共有できる
• デフォルトのコンテナランタイムはDocker(https://www.slideshare.net/potix2_jp/docker-77560696
• DockerではLinuxのcgroupsを利用してリソース(CPU、メモリ、ディスクI/O)の制限をする

【読了】Kubernetes 入門 第1章

入門 Kubernetes

EKSがGAになる前に勉強しとく！

Kubernetesを使う利点

ベロシティ(速さ)

• CDに入れられるソフトウェアから、Webベースのサービスに移り変わりユーザーへ提供するスピードが速くなった
• 近年はスピードに加え可用性を求められ、常にサービスを提供していく必要がある
• Kubernetesとコンテナがあれば、これらを実現出来る
• これを実現するための核となるコンセプト
  • イミュータブルであること
  • 宣言的設定
  • オンラインで自己回復するシステム

イミュータブル

• イミュータブルであることは分散システムを構築しやすい、ロールバックが容易
• ミュータブル：伝統的にシステムはミュータブル。既存のバイナリや設定ファイルを変更が積み重ねられる
• イミュータブル：一回のオペレーションでイメージを更新する、既存のものを変更するのではなく新しく入れ替える

宣言的設定

• Kubernetes上はすべて宣言的設定のオブジェクト
• 宣言的なため、設定間違いが起こりにくい、ソースコード管理ができレビューやテストをしやすい
• 宣言的設定(declarative)：状態を定義する(Ansibleやコンテナのように状態を定義)
• 命令的設定(imperative)：命令的なコマンドの羅列によって状態を定義する(古くからある手順書による設定)
  • 例：あるソフトウェアのレプリカを3つ起動するとき
  • 宣言的設定：レプリカ数を3にする
  • 命令的設定：Aを起動し、Bを起動し、Cを起動する
• 昔ながらの切り戻し手順考えて頑張ってた世界がかなり簡単で完全にロールバックできるようになる

自己回復するシステム

• 旧来であれば命令的なので、障害はアラートで通知され、オペレーターが手順に従い復旧を行う
• Kubernetesは宣言的設定になり、その状態は継続的に保たれる。障害が起きても宣言的設定に従い、状態を回復すり。AWSでいう、AutoScalingのイメージ。
• オペレータが介在しないので、確実で素早く、コスト効率のよいシステムを運用できる

サービスとチームのスケール

分離

• 分離し境界を設けることで、チームのスケールとインフラリソースのスケールが容易になる
• 各コンポーネントの分離：各コンポーネントはAPIで分離
  • チームの境界が明確になる
  • コンポーネント単位でのスケールが可能になる
• インフラの分離：インフラはロードバランサとコンテナによる分離
  • 各チームがインフラの競合を意識せずに、アプリケーションをデプロイできる
  • スケールがしやすい

アプリケーションとクラスタの簡単なスケール

• コンテナのスケールはイミュータブルかつ宣言的設定なので容易
• クラスタのスケールも、コンテナによるインフラの分離がされているので、インスタンスをクラスタに追加するだけ
• 複数のアプリを同じインスタンスで共有できるので効率が良い

マイクロサービスによる開発チームのスケール

• チームの人数は2枚のピザ。ただ開発規模との兼ね合いで人数が必要だったりする。これはマイクロサービスによる複数チームによる開発で解決する
• Kubernetesはマイクロサービス開発を容易にする、抽象化層やAPIを提供する
  • Pod：複数のコンテナをグループ化
  • マイクロサービス間の接続のために、ロードバランシグ、ネーミング、ディスカバリ機能を提供
  • Namespaceが分離とアクセス制御、リソースの分離など
  • Ingress：ロードバランシングとインターネットフェイシングのエンドポイント、SSLのターミネーション

インフラの抽象化

• インフラ管理とアプリケーション管理を分離できるので効率的

効率性

• 1つのサーバーに複数アプリを依存なく、効率的に起動できる、集約できる

【読了】部長の仕事術

部長の仕事術 (アスカビジネス)

ふと、部長に求められることに興味を持ったので読んでみました アウトプットしておきます 感想としては今の会社は、メンバー、マネージャー、部長、社長に恵まれてるなと思った。なぜなら、この本に書かれていることは当たり前なことでしかなかった。そして今の自分を継続して行っても大丈夫って自身を持てた。ただできてない箇所もあるので、今後は意識して実践していく（ボールドの箇所）

部長と課長の違い

部長には経営上の重要な判断をし、部門の長 課長は一般社員と仕事することが多く、現場レベル仕事がメイン

部長に求められること

• 専門性より組織を動かすこと
• プロセスより結果
• 過去より未来にコミットし、どうやって実現するか
• 世の中は進歩しているのに、去年と同じことをやっている状態だと、衰退しているだけ
• 部下の話に耳を傾ける
• 2 - 3年後のビジョンを持つ

部長のマネジメント力

• 誰に対しても丁寧に対応する、メンバもお客様と考える
• 地味で面倒な仕事でも重要、監査とか。他の部署との面識も増える
• 組織やそれ以外の業務に関する方針を作ること、臨機応変い対応できる組織にすること
• 細かい指示を伝えるのではなく、目標、方針、予算、スケジュールだけ伝える、報告を受けながら軌道修正する
• 失敗を恐れて細かく聞いてくる場合は、失敗を許容する文化を意識する、本人が考えて行動するために指示を我慢する
• 作業を細かく分担するると、視点が全体的ではなく局所的になる。結果、他の人の作業を気にしなくなる。スクラム的なアプローチが有効そう
• 属人化を排除して仕組みで対応できる組織を目指す
• 判断力と決断力、決断したあとの補正、いい情報だけで判断せず、0ベースでもの後を見る
• 悪い情報こそ早めに報告し、軌道修正する
• 工数は5割り増しで想定するのが落とし所、見直しや他部署との連携など想定外が起こるので想定しておく
• 時間がないときに、早めに判断して手放す。早く判断しないと、時間だけがなくなり、チームの負荷が大きくなるだけ
• プレイング部長で、部下のことを気にかけないのはだめだよね、部下の成長を考えながら仕事を渡す
• 部下の相談は速攻で乗る、すぐ判断する
• モチベーション低下やマンネリしたら、他部署移動を案内したり
• ＊チェックポイントを設けておく、序盤、中盤、終盤、いいかんじに物事をすすめるため、後から遅れに気づいて怒るのは3流だと思う
• 定期的な振り返りポイントを設ける、私の場合はこういう本を読んだり、銭湯行った時。＊月一で銭湯行く日を設ける
• 打ち合わせは自分の意見を通す場所ではない、会議の目的を達成すること。必要なのはファシリテーション力。聴いて相手の意見を引き出す。＊意見をしていない人にどう思うか聴く
• プレゼンに必要なのは、相手が判断するためのポイントを齟齬なく伝えること、それには相手のリサーチが最も重要

部長の数字力

• 人は見たいと思う現実しか見ようとしない、いい数字はよろこばれる、悪い数字は受け入れられにくい
• 世界共通で、悪い報告は叱責される、ただ叱責だけだと隠蔽や報告の先延ばしが起こる、そして叱責しても事実は変わらない
• 悪い報告こそ早く行う
• 悪い報告をされる場合は、一呼吸置いて笑顔で話を聴く、建設的な話をする、悪い報告をしやすい工夫をする
• ＊数字を把握することで、投資やネクストステップ、現在の課題が浮き彫りになる。数字を根拠に話す
• ただし数字を武器にしない、社員のモチベーションを結果的にさげる可能性がある。相手をねじ伏せるのではなく、前向きな目的のために数字を使う
• 数値の予測の場合は、正確さよりも早さが重要な場合もある
• 成果を横取りされる場合もなきにしもあらず、数字は他部署に渡さない
• 悪い数字は早めに報告する、部長レベルだと足の引っ張り合いや功績の奪い合いになる可能性あり
• 通常の数字と、挑戦的な数字やベストケース、ワーストケースなどの2段構えで用意する

部長の育成術

• ダイバーシティを理解し、特性や属性に合わせた育成を実践する
• 新入社員は暖かく迎えて、育む雰囲気を作る
• メンター制度を導入する、安心して頑張れる環境を用意する
• 仕事の半分は部下の育成に使う、細かい指示は出さず目的、方針の共有をし進め方をガイドする
• 部下は部長の手足ではないよ！
• 仕事の移譲とサポート
• 言われたことを着実にこなすタイプは、思い切って担当を変えて成長する機会を与える、ただし責任は自分がもって安心して仕事ができるように伝える
• 上級管理職に適任な人とは？バランス型、調整もするし、着実に仕事もこなしつつ環境も整備できる人
• 地位があがると結果責任を求められるようになるが、部下には結果だけではなくプロセスも考慮する
• 評価する場合は企業理念に沿っているかを考慮する、企業理念から逸れた方法で業績をあげても評価しない、それをきちんとフィードバックする

部長の人間力

• 公平性を持つ
• 誰にでも同じ態度をとる、人によって態度を豹変しない
• 弱い立場の人にも同じ態度で、協力的に、ただし改善など建設的なフィードバックはバシッと。目的は互いのためでありwin-winになるようにするため。
• 年齢や性別、人種も考慮し公平性を保つ
• 誠実さを持つ
• ルールで縛らない、ルールよりも価値観を大切にする
• 価値観を定期的に共有する
• 部下のやったことに責任を持つ、責任をとる
• 柔軟性を持って、走りながら考える
• スピード感を持って仕事を進める
• ＊弱みを強みに変える
• 失敗したこととどう挽回したか、調整したかというネタをもっておく。失敗したことから学んだこと、そして挑戦すること
• 修羅場は買ってでも体験する。そうすると苦難に遭遇しても開き直れる。これはすげーわかる！冷静な頭脳と温かい心を手に入れられる
• 社畜とは自分の意思と良心を放棄すること、上司に絶対忠実である必要はない！
• 会社の理念の共鳴して、理念を追求してく人を新社畜として定義

役員の出世術

• 部長はスキルより人間力が大切、役員は人間力より運が大切
• 無駄に敵を作らない、人格や能力を否定しない、論理で相手をねじ伏せない、恥をかかせない
• 言い訳をしない、バックアッププランを用意する
• 不運のことが書いてあったけど、個人的には運に逃げるのは好きじゃない、良いこと悪いことは必ず起きるので、考えて対応していくかが超重要。運は言い訳。
• 負のエネルギーをためない、感情的にならない

苦難の乗り越え方

• 部長は逃げ出したくなるようなことが多々起こる、対応するときのアドバイス
• 会社の業績が悪いときでも、致命的な失敗しないこと。命や法に触れるとかはしちゃいけない、窮地に陥ると判断ミスしやすい。倒産しても命が取られるわけではない、またやり直せる
• 上司とうまくいかない、相手の要求に応えること、例えば不安だからマイクロマネジメントを行う、この場合は自分の実力を伝えて信頼を勝ち取るとまるっと任せされる
• いじめやパワハラ、仕事に注力する、あまりにひどい場合は転職も検討する
• 部下から総スカン、一方的にやる気がない、たるんでると押し付ける、やり方が間違ったときでも、めげずにコミュニケーションしていく

部長の自己啓発

• 部長になっても自己啓発は大切ね
• 年一回振り返りをする、職務経歴書をアプデする、マンネリ回避してチャレンジしていく
• ＊自己啓発に歴史、哲学が必要、自分の物差しを得る
• 実務は専門家に任せる
• 専門家に任せられる程度の知見を持つ
• 英語、粘り強い英語、質問力
• ＊会計力、簿記3級レベル

宿題

• ＊数字を把握することで、投資やネクストステップ、現在の課題が浮き彫りになる。数字を根拠に話す
• ＊弱みを強みに変える
• ＊自己啓発に歴史、哲学が必要、自分の物差しを得る
• ＊会計力、簿記3級レベル

読了 SCRUM BOOT CAMP

SCRUM BOOT CAMP THE BOOK

読んだのでアウトプットしておく

スクラムとは

• プロダクトをチームで作り上げる
• プロジェクトの透明性を大切にする
• プロダクト小さく作って育てていく ためのメソッド

ウォーターフォルと比較

• ウォーターフォルはタスクで担当が決められて分業なイメージ、スクラムは全員がプロダクトに責任を持つスタイル
• ウォーターフォールはリーダーが管理するスタイル、スクラムは全員がプロダクトの方向性や機能の背景、要件を知りかつプロジェクトの状況も把握し課題があったらチームで解決する
• 要件がかっちり決められたらウォーターフォール、それができない新しいプロダクト、未来がわからないものについてはスクラム

メソッド

• プロダクトバックログ：要求がすべて記載されているリスト。優先順位が高いものを上にもっていく。開発は上から順に実装していく。機能をどうつかうかというストーリー、テストができる具体的なレベルで記載する
• スプリント：2週間とか1ヶ月とかテンポを決めてプロダクトをシップする。期間を延長しない。
• スプリントバックログ：開発チームのためのタスク一覧

ロール

プロダクトオーナー

• プロダクトの結果責任。要件を決めプロダクトバックログを管理する。開発チームと協力してプロダクトを作っていく。
• リリース計画
• 予算管理
• 利害関係者への報告、相談
• 開発されたプロダクトの検査

開発チーム

• プロダクトバックログの項目に従って開発していく
• 3-9人で構成される
• 上下関係なし
• スキルを補って全員で開発する
• スプリント期間を決め、その間にリリース判断 可能な成果物をアウトプットする
• プロダクトバックログからタスクとして切り出して、スプリントバックログを作る
• デイリースクラム：昨日やったこと、今日やること、困ってることを簡潔に共有する

スクラムマスター

• プロジェクトがうまくまわるようにサポートする
• 妨害を排除し、支援し、スクラムについて教育する
• プロジェクト効率的に進めるために妨害リストを作って、課題を解決していく
• PMとしてスケジュール管理するS

プロジェクトのキックオフ

インセプションデッキやビジネスモデルキャンバスを使って、チームないでプロジェクトに関する共通認識をもっておく

見積もり

プロジェクトがいつ終わるか、どれくらいの工数がかかるかを見積もるにはプロダクトバックログを利用する プロダクトバックログには、要件がまとまってるので、どれくらい開発がひつようか、1つ1つの項目に対して行なって合計をみる 開発チームが見積もるのがよい、この機能を開発するにはどれくらいか、1から10で数値化する あとはスプリント1回でどれくらいのポイントを消化できるかがわかれば、必要な期間、期間に合わせて人数がどれくらい必要かを見積もることができる

ただし、マニュアル作成やリリースにかかる作業が見積もりから漏れることがある マニュアルやリリース、インフラ構築など非機能要件、マーケティング活動につても最初から検討できるとよい

リリース作業が見積もれない場合は、スプリント以外のスケジュールとしてリリース期間を設ける

ルールはチームで決める

• デイリースクラムの目的とルール
• リリースに関するルール
• などなど チームで決めることで、なぜこのルールが必要かの共通認識を持つつともに、ルールに問題があればチームで改善できる

進捗アップするには？

スケジュールを前倒ししたいと言われても簡単ではない 前倒しするには人を増やすことで可能だが、スクラムに慣れる、チームに慣れることが前提になるため時間がかかる

技術的負債

プロジェクトを進めていくと必ず発生する これをいつ返すか、必ず悩む時期がくる 技術的負債を理解した上でプロジェクトを進める必要がある

スコープの調整

リリース前にスケジュールが間に合わない可能性が出てきたらどうする？ 予算、期間、スコープで調整する ただ、まずスコープを再度検討することからはじめる 最低限の要件を満たすようにする、必要な機能に対し優先順位を決める、ユーザーの要件を満たすようにしながら不要な機能をけずる、実現方式をかえて簡単な実装に変更するなど

開発チームでのスキルマップ

全員がなんでもできるわけではないので、スキルマップを作って得意不得意を見える化し、得意なことでチームに貢献できるような仕組みを作ろう

規模が大きい場合の開発

規模が大きい開発でスクラムをやるには、スクラムチームを複数作って対応していく マイクロサービス化し、システムを分割してスクラムチームを作る