チームにスキルが足りない!? その時どうする?
こんにちは。ryuzeeです。 先日、スキルマップ作成のすすめという記事を書きましたが、それに関してオンライン上で色々議論になりました。 せっかくですので、その内容を共有します。 まず、おさらいですが、スキルマップとは以下のようなものです。横軸にプロジェクトで必要となる技術、縦軸に名前を入れます。 それぞれの記号は、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というのを指していますがこれはチーム次第です。 このスキルマップを作ることで、「スキルの見える化」「リスクの見える化」「学習速度の向上」が期待できます。 さて、議論になったのは、以下の話です。 チームに足りないスキルセットがあることがわかって、でも期間的にそれを埋めてる余裕がない場合どうする？ スキルの話なのかヒトの話なのか。ジャッジメントしなければならないのは誰なのか。 端的に
【資料公開】DevOpsの基本
こんにちは。@ryuzeeです。 営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
ウォーターフォールとアジャイルにおけるマインドセット | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。 なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。 以下の表は、ウォーターフォールとAgile（第一世代、第二世代に分けた。）におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。 我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。 ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。 第1世代アジャイルと第2世代アジャイルの類似点
ウォーターフォールの方が楽ですか？
(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市
ドキュメントレビューをする際の10のポイント | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 重厚長大なドキュメントは、動かなかったり嘘が書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで辛いことが多いのが現状です。 今回とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみます。 なお、個人的には、ドキュメントレビューよりソースレビューの方が重要だと思っています。 とはいえドキュメントレビューで肝心なのは、 ドキュメントレビューをするなら、その投資に見合う何を得るのか？を決めておく必要がある本当にそのドキュメントは必要か？をよく考える（会社のルールだから！というのは理由にはなっていない）だと思います。 レビューのポイント1. 体裁をレビューするのではなく、中身をレビューするひどい現場だと、文書のインデントやフォントのサイズ、誤字脱字ばかりを重箱の隅をつつくようにチェッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
