「IT業界の病理学」を読んで
IT業界の病理学
完全にタイトルに惹かれて読みました。笑
各テーマ(ex: エンジニアリング、プロジェクトマネジメント)とかの解説書の一角に、「こういう問題が発生したら、こう対処したらいい」みたいな言説があったりするかもしれませんが、「IT業界」という大きな枠から「よくある問題とそれに対する解消法」といった観点で書かれている本は珍しく、読んでいておもしろかったです。
以下は読んで特に興味深かった内容です。
本からの抜粋
アジャイルのチェックリスト
| チェック項目 | 判定 |
|---|---|
| ユーザーは協力的か | No -> アジャイル不可 |
| 開発メンバーのスキルは十分か | No -> 不可 |
| サービス開始日は決められており、延長不可か | Yes -> 不可 |
| ミッションクリティカルか | Yes -> 重大な被害が出ることがある |
| ユーザー、メンバーは同じ場所で作業できるか | No -> 不可 |
| 厳密なタイムマネジメントで管理可能か | No -> 不可 |
| 開発のあと、別のベンダーが運用するか | Yes -> XP不可 |
このあたりの駄目なポイントは覚えておきたい。
そもそも導入可能か、という判断基準であるところはもちろん、
ものによっては時間経過によって変化し、駄目なパターンになってしまっていることもあるので、忘れずにいたい。
レビューの頻度ややり方など
重大欠陥を効率よく検出するレビュー手法の提案と
有効性の実験報告
https://www.juse.or.jp/sqip/workshop/report/attachs/2012/SQiP3-riku.pdf
https://www.juse.jp/sqip/symposium/archive/2013/day1/files/happyou_shiryou_A1-1.pdf
なんとなく「あまりサイズ感が大きくなく」「できるだけ早いタイミングで」「複数回やる」ほうがレビューはいいのかなと思っていたが、体系的にまとまってるものを見たことがなかったので、ちゃんと読んで説明できるようにしたい
バグレポートの改善に向けた 問題事例の調査とアンチパターン作成
https://www.juse.jp/sqip/symposium/archive/2014/day2/files/happyou_C3-3.pdf
こちらも同様。ちゃんと把握しておきたい。
DevOpsの体制
解決案としては「対等の連携ではなく、上下をつける」という方法が有効です。
・開発を上にして、運用部門を管理・コントロールさせる
・運用部門を上にして、開発は運用サイクルの一環という位置づけにする
DevOps内で開発と運用は対等な関係をイメージしていたが、たしかに対等だと対立が起きてうまく進まないことがあるのだなと改めて理解した。
開発を上にしちゃうとちょっと運用側がないがしろ、というか実装やリリースを優先されてしまいそうなイメージもあるが、運用側が強くなると、開発側が不満を憶えそうな気もする。。。
もちろんちゃんと歩み寄れ、という話ではあるが、どちらの体制がよいのかとても興味がある
高齢化するばかりの運用現場
これは単純に読んだ感想であるが、運用現場にも高齢化の波が押し寄せているのだなと思った。
過去の慣習がそのまま残り、職人芸化した運用手法や、それを変える風潮のなさ。
どんな場でも、どんどん日々勉強し、改善していくという環境を作っていく必要があるのだなと考えた。
マネジメント/リーダーシップ理論
以下あとで確認したい
レヴィンのリーダーシップ類型
ゴールマンの6つのスタイル
三隅のPM理論
納期の考え方
日本の納期はピンポイントの日付だが、本来は○○日~☓☓日と幅をもたせるべき
デコルマら「熊とワルツを」
冷静に考えると確かにピンポイントで決まってる必要はないなと思った。
もちろん何らかの公開日とかは定まってる必要はあると思うが、納期自体は幅があってもよいと思った。
大きなプロジェクトとなるとさらに不確定要素が多くなるため、柔軟性が求められる。
エンジニアをレベルアップさせる「ファシリテーション入門」
さすがWeb上になんでもある時代・・・
勉強します
https://gihyo.jp/lifestyle/serial/01/facilitation
全体の雑感
当たり前ではあるが、各テーマに対して深堀りした研究や本などもあって、あんまりそのへん勉強せず、過去の知識だけでなんとかしようとしているなと改めて思った。
本の中で記載のあった引用元の本を起点にもう少し勉強してみたいなと思った。
特にレビューまわりとか・・・
