「チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで」を読んで
書籍
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
- 作者:市谷 聡啓
- 発売日: 2020/02/17
- メディア: 単行本（ソフトカバー）
TL;DR
- 読み物としても面白く、チームで仕事をする人は読んで損しない本。
- 読めばモチベーションが上がり、現在のチームに何らかのアクションを取りたいと思わせてくれる。
この本を選んだ理由
- 現在チームで働いているがチームで働く良さを十分に活かしきれていないと感じている為。
- 感銘を受けた「カイゼン・ジャーニー」の続編であり、ファンとしては読まない訳にはいかない為。
印象に残った点
チームの成長戦略にも段階の設計を取り入れる[第1部 第03話]
- いきなりたどり着きたい「目的地」に向かって全速力で走り出すのではく、目的地を見据えつつ、その過程をデザインする。 - 目的地を明らかにするための問いとして「私達がたどり着きたい場所はどこか?」がある。 - 目的地から逆算し、段階を構想する。その際、段階の傾き、期間の妥当性を検討する。 - 最初の見立ては正確性に欠けるので段階を進めていく中で段階設計を見直す。
- 理想を掲げるのは良いが段階を踏まないといけないのか。当たり前のことなのに読んでいて気付かされた。
- 逆算して段階的にチームの練度を高めていきたい。
チームの構造には4つの要素がある[第1部 第04話]
- 共有ミッション、役割、コミュニケーション、ルール - 要素が足りないとチームの力を発揮できない
- 明確に打ち立てチームのメンバーに伝える必要があるのか。曖昧に定義するところだった。
現状を打破するためにチームのDIFFを取る[第1部 第05話]
- DIFFの取り方は3つある - 過去、未来、並行 - 過去からの差分で着地点を決める - 未来の姿からの差分で着地点を決める - 並行(別チーム)の姿からの差分で着地点を決める
- チーム開発に限らず、個人を広げるためにも視点の変え方だなぁ。
コミュニケーションの構造化する[第2部 第10話]
- チームからの越境をするために、コミュニケーションの構造化が必要
- デイリースクラムによるチーム内の同期
- リード(職能別)による同期
- 各チームのリーダー開発による同期
- リーダー会が意思決定の場にしてはいけない
- 背景、対象とする問題や事象、原因、施策、施策採用理由、実施にあたっての前提をセットにして伝えること
- ただ言われたことをやるという構図にならなくなる
- 今のプロダクトチームはチームの同期と全体の同期のみしている。全体の同期が広範囲すぎるんだよなぁ。。。リーダー会はリーダー会として別途やるべきで、伝えたいことはちゃんとリーダーがチームに伝えるようにしたらいいのになぁ。と思う。
横断チームが必要になる状況と直面する問題がある[第2部 第12話]
- 横断チームが必要になる状況
- 専門性不足やこぼれ球が山積みになっている
- 自チームの開発を有利にしたいという状況
- プロダクトチーム全体として最適ではない
- 横断チームが直面する問題
- タスクを引き受ける範囲の線引きが曖昧になる
- 稼働率問題(専任、兼任)
- フロー効率を取るなら兼任、リソース効率を取るなら兼任
- どちらの選択がミッションの実現により効果的かを考えて判断する
- ミッションに必要な期間を見定め、一時的なチームとする。
- 今の組織はミッション実現のためにより効果的だと考えて兼任という判断をしているのか、深く考えたい。
- 状況特化のために横断チームを期間を決めたほうが良いというのは実体験ベースでも感じる。
クモ型チームとヒトデ型チーム[第2部 第14話]
- クモ型チームとは中央集権型の組織 - 強いリーダーが引っ張り続けるが、頭がやられるとクモもたちまち動けなくなる - ヒトデ型チームとは分散協調型の組織 - ヒトデはどこをやられても活動が停止しない
- 今のプロダクトチームはクモ型になっている。ヒトデにはなれないのか?と考えるとある程度練度が上がっており、無理はないと個人的に思う。
- ただ、今のリーダーがそういう体制にしないのはまだ現状に不安があるからなのかもしれない。
- リーダーの視点に立って考えないといかんな。
視座や視野を意図的に変えることが理想だが、簡単に出来ない[第2部 第15話]
- 視野が同じでも視座を変えると見えるものが変わる - 現状の最適化=現状に合わせた思考&行動に気づいていない - そもそもこの仕事で何を実現したいのか?、この仕事は必要なのか?を問い直す必要がある - 役割の固定により視座や視野が固定される - リード役をローテーションをする - 対応方法は色々あるが難しい - チームで臨むことで、チーム総体としてあらゆる観点から物事を捉えられる。
- 経験してみないと分からないというのは良く分かる
- リードを変えるのは良いなぁ。今の体制では難しいけど。
- チームで臨む良さを今一度考えないといけない。誰にでも穴はあり、その穴を互いに埋めてこそチームなのだろう。
その他所感
- DBスペシャリスト受けるつもりが試験が延期？中止？になり久しぶりに時間が取れたので読んでみた。本を読むというのは勉強とは違う楽しさがあるなぁ。
今後
- 「他者と働く」を読んでみたいなぁ。
2020年目標
2020年目標
2019年の振り返り＋個人的に取り組みたいことから今年の目標として下記を設定。
目標①：実務に役立つ資格を2つ取る
数値目標：データベーススペシャリスト＆医療情報技師の合格
- 自分で学びたいと思う分野は実務に離れた内容が多い。
- 実務に直結する内容を学びつつ、結果も明確なため資格試験を受ける。
- データベーススペシャリストは4月、医療情報技師は8月なので、上期は殆ど試験勉強で埋まる予定。
目標②：ブログにアウトプットする
数値目標：8記事(資格試験(2記事)＋読んだ本の感想(6記事))
- 目標①の勉強内容や所感を2記事書く。
- 前年実績だと月平均約1.5冊の本を読んでいた。
- 8月までは試験勉強で本を読めないと思うので、9月～12月の4ヶ月×前年実績で目標を設定。
目標③：社外のエンジニアと交流する
数値目標：4回
- 昨年は社外のエンジニアの方と話す機会があり、とても刺激を貰えた。
- (家庭の事情でなかなか自由な時間は取れないかもしれないが、)四半期に一度は社外の方と交流し良い刺激を貰う。
2019年振り返り
2019年振り返り
今年の目標と実績
振り返る前に、まずは新年に立てた目標に対して予実を確認する。
| No | 内容 | 目標 | 実績 | 補足 |
|---|---|---|---|---|
| 1 | ブログ更新の単位を週ではなく成果レベルに切り替える。 | 8記事 | 7記事 | 写経してみた系の記事(7記事))＋自作Webサービスについての記事(1記事) |
| 2 | 朝活のように手を動かす必要がない本を読んだ場合でもアウトプットする。 | 5記事 | 17記事 | 写経しない本を読んだまとめ記事(17記事) |
| 3 | 土日も自己研鑽の時間を少しでも取る。 | 5時間/月 | ？？ | 時間は測れていない問題はあるが、月平均5時間以上は間違いなく本を読めた。 |
今年の振り返り
- Keep
- 出張や有休以外の平日は朝活できた。(193日活動できた。)
- 目標の3倍を超える本を読むことができ、本を読む習慣化が出来た。
- 5月からGoogleAnalyticsを導入することで月当たりのPVが分かるようになった。(はてなブログだけだと、先月のPVが分からなかった。)
- Web開発素人でもFirebase＋Vue.jsで在席管理サービスが作れた。とても勉強になった。
- 社外のエンジニアの方と話す機会があり、良い刺激を貰えた。
- Problem
- 目標の3つ目は実績が測りづらい目標にしてしまった。
- 通勤に時間がかかるようになり、手を動かす朝活の量が減った。(その分本は読めるが…)
- 会社での朝活中に声を掛けられ、作業が中断することがあった。
- PVを取るようにしたが、本当にジワジワとしかPVが増えない。
- 社内の自己研鑽をする意識の高い人達が辞めたり別の部署に移動したりし、モチベーションを高められる環境が減ってしまった。
- Try
- 来年度は計測が出来るような目標を立てる。
- 本を読む以上に得られるものがあるため、自作のアプリを何かしら作る。
- 引き続き本を読む週間は続ける。
- 刺激をもらえるよう社外のエンジニアと会う。
- 来年は今年よりPVをどれだけ上げるか目標を立てて取り組む。
今年の振り返り結果を反映した目標を立てよう。
「SQLアンチパターン」を読んで【第Ⅳ部】
書籍
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
はじめに
読んだ書籍は1記事にまとめると文量が多くなるため、導入＋各部ごとの記事としてまとめる。
本記事は「第Ⅳ部：アプリケーション開発のアンチパターン」になる。その他の部についての記事は下記参照。
- 導入
- 第Ⅰ部：データベース論理設計のアンチパターン
- 第Ⅱ部：データベース物理設計のアンチパターン
- 第Ⅲ部：クエリのアンチパターン
- 第Ⅳ部：アプリケーション開発のアンチパターン(本記事です。)
印象に残った点
※ 下記のカッコ書きは該当する章番号。
リーダブルパスワード(読み取り可能パスワード)[19]
- 目的:パスワードのリカバリーとリセットを行う - アンチパターン:パスワードを平文で格納する - アンチパターンを用いてもよい場合 - 少人数が使うイントラネットのアプリケーション - 解決策:ソルトを付けてパスワードハッシュを格納する
- 前に読んだ本も認証のためにソルト使ってた。ソルトを使うことが最低ラインなのかもしれない。
- パスワードのハッシュ化はなるべくユーザに近い箇所でやるべきなのか。その通りだと思った。
SQLインジェクション[20]
- 目的:動的SQLを記述する
- アンチパターン:未検証の入力をコードとして実行する
- アンチパターンを用いてもよい場合
- 正当化する理由はない
- 解決策:誰も信用してはならない
- 状況に応じて以下技法を適切に使い分ける
- 入力のフィルタリング(無効な値を事前除去)
- プリペアドステートメントを用いる
- 動的値を引用符で囲む
- ユーザの入力をコードから隔離する(マッピングする)
- レビューしてもらう
- プリペアドステートメントだけで良いと思っていたがそれだけでは駄目なのか。
- 状況に応じ、入力値のフィルタリングやマッピングなど様々な引き出しを使えるようにならないといけないなぁ。
- レビューも効果的に使う必要があるのか。それなりのスキルがないと効果的なレビューにならないなぁ。
シュードキー・ニートフリーク(疑似キー潔癖症)[21]
- 目的:欠番を詰める - アンチパターン:隙間を埋める - 欠番を埋める(欠番を探すクエリは不要な自己結合が必要) - 既存行に番号を振り直す(Updateするため競合状態を引き起こしやすい) - アンチパターンを用いてもよい場合 - 正当化する理由はない - 解決策:疑似キーの欠番を埋めない - 疑似キーは行番号ではないため連続している必要はない - GUIDを使用する - 上司を管理する(技術やコストについて説明)
- 疑似キーはあくまで擬似的なキーなのに欠番を埋める意味ある?と思っていたが、解決策は自分の考えと同じだった。
- 行番号と同じだと思う人もいることを認識しておかないといけないなぁ。
- GUID使えるベンダー製品あるのか!!GUIDであれば欠番を意識することないのでメリットもあるなぁ。
シー・ノー・エビル(臭いものに蓋)[22]
- 目的:簡潔なコードを書く - アンチパターン:肝心な部分を見逃す - 戻り値を無視する - 実行するクエリをログ等に残さない - アンチパターンを用いてもよい場合 - close関数でエラーを返してもその後アプリが終了する - 処理の責任がないので例外を無視する - 解決策:エラーから優雅に回復する - 戻り値と例外をチェックする - 実際に構築されたSQLクエリを出力する
- これは当たり前にやってるのでは?と思った。戻り値や例外を握り潰すのはアカンでしょ。
- 昔保守していた製品はSQLクエリをログに出していなかったので調査が辛かったことを思い出した。痛みを知ってるから当たり前と思っているのかもしれない。
プログラマティック・イミュニティ(外交特権)[23]
- 目的:ベストプラクティスを採用する - アンチパターン:SQLを特別扱いする - アプリケーション開発のルールをデータベース開発に当てはめない - アンチパターンを用いてもよい場合 - 1度きりの利用だと割り切れる(利用したら躊躇わず消せる) - 解決策:包括的に品質問題に取り組む - 文書化/バージョン管理/テスティングを行う
- アプリケーションコードの文書化の価値は低いが、データベースの文書化には価値があると述べる人達もいるのか。
- 今保守している製品はこの考えに近い。アプリ観点であればアンチパターンになるケースは少ない気がする。
- StackOverflowのPodcastあるのか!知らなかった。
- テーブル定義はバージョン管理しているけど、ER図や関連の説明が弱いんだよなぁ。やっぱ欲しいよなぁ。
- DBに関するテストもやるのか。確かにやったほうが良い。
マジックビーンズ(魔法の豆)[24]
- 目的:MVCのMを単純化する - アンチパターン:モデルがアクティブレコード(魔法の豆)そのもの - アクティブレコードはモデルをデータベーススキーマに強く依存させてしまう - アクティブレコードはCRUD機能を公開してしまう - アンチパターンを用いてもよい場合 - テーブルの各行を操作するだけのシンプルなアプリ - 素早くコードを書くプロトタイプ作成(技術的負債を生むリスクはある) - 解決策:モデルがアクティブレコードを「持つ」ようにする - ドメインモデルの使用(DB操作をモデルクラスに完全に隠蔽する)
砂の城[25]
- 目的:サービスの安定稼働 - アンチパターン:想定不足 - アンチパターンを用いてもよい場合 - コストとのトレードオフで許容する - 解決策:トラブルを「当然起きる日常的なもの」として捉える - ベンチマークを取る - テスト環境を用意しておく - 適切な例外処理を実装する - バックアップを取る - ディザスタリカバリを考慮する - 運用ポリシーの作成
- 問題かサービスへ及ぼす影響が軽微であれば、自動的にトランザクションをリトライして問題を無視することも視野に入れることは大事なのかもしれない。
- 保守していて思うのは、全てを完璧にする(＝何も問題がない)ことは不可能だと感じるので、重要度に応じた対応を意識したい。
- リスクマネジメントをちゃんとやりましょう!ということだろう。リスクの想定が甘いと問題になりますよね…
「SQLアンチパターン」を読んで【第Ⅲ部】
書籍
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
はじめに
読んだ書籍は1記事にまとめると文量が多くなるため、導入＋各部ごとの記事としてまとめる。
本記事は「第Ⅲ部：クエリのアンチパターン」になる。その他の部についての記事は下記参照。
- 導入
- 第Ⅰ部：データベース論理設計のアンチパターン
- 第Ⅱ部：データベース物理設計のアンチパターン
- 第Ⅲ部：クエリのアンチパターン(本記事です。)
- 第Ⅳ部：アプリケーション開発のアンチパターン
印象に残った点
※ 下記のカッコ書きは該当する章番号。
フィア・オブ・ジ・アンノウン(恐怖のunknown)[13]
- 目的:欠けている値を区別する - アンチパターン:NULLを一般値として使う、または一般値をNULLとして使う - アンチパターンを用いてもよい場合 - 外部データの入出力 - 欠けている値の区別 - 解決策:NULLを一意な値として使う
- SQLの3値論理の振る舞いを理解していれば迷うことはない。ただ3値理論だと知らなかったらハマるのは分かる。
- IS DISTINCT FROM便利だなぁ。対応していない製品もあるのか。
アンビギュアスグループ(曖昧なグループ)[14]
- 目的:グループ内で最大値を持つ行を取得する - アンチパターン:非グループ化列を参照する - アンチパターンを用いてもよい場合 - 関数従属性を用いてクエリ結果の曖昧性をなくせる場合 - 解決策:曖昧でない列を使用する - 関数従属性のある列のみにクエリを実行する - 相関サブクエリを使用する - 導出テーブルを使用する - 他の列に対しても集約関数を使用する
- 単一値の原則か。普段利用しているDBMSだとエラーが出るためあまり意識していなかった。違う製品使っていたら危なかったかも。
ランダムセレクション[15]
- 目的:サンプル行をフェッチする - アンチパターン:データをランダムにソートする - アンチパターンを用いてもよい場合 - データセットが小さく、大きくなる増える可能性もない場合 - 解決策:特定の順番に依存しない - ランダムなキー値を選択する - アプリケーションコードで対応する - ベンダー依存の解決策を使う
- ランダムな値を業務上使う事がなかったのでなるほど。と思うところが多かった。インデックスが効くかどうかを常に意識することが鍵だなぁ。
- ベンダー依存の解決策は製品間の移行を考えなければ良い解決策だと感じた。
プアマンズ・サーチエンジン(貧者のサーチエンジン)[16]
- 目的:全文検索を行う - アンチパターン:パターンマッチ述語を使用する - アンチパターンを用いてもよい場合 - シンプルな用途や使用頻度が低い場合 - 解決策:適切なツールを使用する - ベンダー拡張機能を使用する - サードパーティのサーチエンジンを使用する - 転置インデックスを自作する
スパゲッティクエリ[17]
- 目的:SQLクエリの数を減らす - アンチパターン:複雑な問題をワンステップで解決しようとする - デカルト積が発生し想定外の結果になる場合がある - アンチパターンを用いてもよい場合 - 単一SQLクエリを前提とするコンポーネントやレポートツールを利用している場合 - 複数の結果を1つのソート順で表示させたい場合 - 解決策:分割統治を行う - ワンステップずつ - UNIONを使う - SQLを用いてSQLの自動記述する
- 複雑なSQLをメンテするのは本当に辛いので分割統治は保守観点からみてもとてもありがたい。
- SQLの結果にSQL文を出力させるのか。そういう考えはなかった！実務でも使えそう！
- デカルト積とは何ぞや?と思ったが、結合のベースとなる考えとのこと。
インプリシットカラム(暗黙の列)[18]
- 目的:タイプ数を減らす - アンチパターン:ショートカットの罠に陥る - ワイルドカードや暗黙的な列指定によってタイプ数を減らすも、リファクタリングや帯域の使いすぎになる - アンチパターンを用いてもよい場合 - アドホックなSQL - 開発時の効率や可読性の向上をトレードオフしてでも採用したい場合 - 解決策:列名を明示的に指定する
「SQLアンチパターン」を読んで【第Ⅱ部】
書籍
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
はじめに
読んだ書籍は1記事にまとめると文量が多くなるため、導入＋各部ごとの記事としてまとめる。
本記事は「第Ⅱ部：データベース物理設計のアンチパターン」になる。その他の部についての記事は下記参照。
- 導入
- 第Ⅰ部：データベース論理設計のアンチパターン
- 第Ⅱ部：データベース物理設計のアンチパターン(本記事です。)
- 第Ⅲ部：クエリのアンチパターン
- 第Ⅳ部：アプリケーション開発のアンチパターン
印象に残った点
※ 下記のカッコ書きは該当する章番号。
ラウンディングエラー(丸め誤差)[9]
- 目的:整数の代わりに小数値を使用する - アンチパターン:FLOATデータ型を使用する - 丸めが避けられない - 浮動小数点数の誤差累積がでる - アンチパターンを用いてもよい場合 - 科学技術計算を行うアプリケーション - 解決策:NUMERICデータ型を使用する - 精度とスケールを指定し固定精度の小数点数を表現する
- 保守している製品は計算に利用する値を一旦文字列型データとしてDBに入れ、アプリ側で利用する際は数値に戻して計算することが多い。SQLを使った計算をすることがなければそれで良いのかもしれない。
サーティーワンフレーバー(31のフレーバー)[10]
- 目的:列を特定の値に限定する - アンチパターン:限定する値を列定義で指定する - 限定する値の取得が難しい - 値の追加や削除が手間 - CHECK制約がDBMSによって異なるため移植が困難 - アンチパターンを用いてもよい場合 - 相互排他的な2つの値(例:左/右、有効/無効) - 解決策:限定する値をデータで指定する - 限定する値の参照テーブルを用意し、外部キー制約で参照する
- CHECK制約を使うタイミングは気をつけないといけないなぁ。この本を読めば読むほど保守している製品のDBの使い方がユルユルだと感じる。
ファントムファイル(幻のファイル)[11]
- 目的:画像をはじめとする大容量メディアファイルを格納する - アンチパターン:物理ファイルの使用を必須と思い込む - レコード削除時にファイルが連動して消えない - ロールバックしてもファイルが消えない - SQLのアクセス権と外部ファイルのアクセス権が一致しない - レコードにある画像パスが正しいとは限らない - アンチパターンを用いてもよい場合 - DBの容量を減らしたい - バックアップを短時間で終わらせたい - 画像ファイルの編集やプレビューを容易にしたい - 解決策:必要に応じてBLOB型を採用する
- 保守している製品は外部ファイルを用いているが、運用を考えるとアンチパターン採用した判断には賛成できる。
- SQL Server 2008にはFILESTREAMという型があるのか。実際に利用している記事があまり見つからなかった。(使い方紹介が多い。)
インデックスショットガン(闇雲ショットガン)[12]
- 目的:パフォーマンスを最適化する - アンチパターン:闇雲にインデックスを使用する - そもそもインデックスを利用しない - インデックスを多くを定義し過ぎる - アンチパターンを用いてもよい場合 - なし(情報を集め検討することが必要) - 解決策:「MENTOR」の原則に基づいて効果的なインデックス管理を行う - Measure(測定):クエリのパフォーマンスを測る - Explain(解析):クエリの処理が遅くなる原因を解析する - Nominate(指名):インデックスを使わないでアクセスしている箇所を特定する - Test(テスト):変更による効果を確認する - Optimize(最適化):キャッシュサイズを最適化する - Rebuild(再構築):不均衡なインデックスを整える
「SQLアンチパターン」を読んで【導入】
書籍
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
はじめに
読んだ書籍は1記事にまとめると文量が多くなるため、導入＋各部ごとの記事としてまとめる。
本記事は「導入」になる。その他の部についての記事は下記参照。
この本を選んだ理由
- RDBをより深く学びたい為。
- 尊敬する先輩がオススメしていた為。
この本の対象読者
- DBを使った製品開発の経験がある人。
- 製品開発経験があると、自分の経験と照らし合わせて「分かるわぁ…」とあるあるネタを共感できて良い。
- 製品開発経験がないと、「ふーん、そういう事あるんだ…」で終わってしまう可能性がある。
所感＆今後
- 章の数は多いものの、各章のボリュームが少ない＆構成が決まっておりとても読みやすい。
- ここまで読みやすい専門書は他にあったかな？と思うくらい良くまとまっている。
- DBって面白い。DBスペシャリストの試験受けてみよう。
- DBの仕組みをより深く知りたい気持ちが強くなった。より深く学べる本を探して読んでみたい。