サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
changeworld.hatenadiary.org
残業を悪とするチームを作るだけでは全く足りない - Change The Worlds 個別最適化では残業はなくならない - Change The Worlds 残業をしない会社を作るために - GoTheDistance 残業を悪とするチームを作ろう - ひがやすを blog SIerにてエンジニアの残業を無くす方法 - ledsunの日記 残業をなくすためにすべきこと - ひがやすを blog と色々なところで残業をしないというスタンスの事が言われてきた。gothedistanceさんは少し別の視点で、人が手作業でやっている作業をITにやらせるというアプローチだが、自分も含めて他の人はチームの成果や生産性をあげるというアプローチを取っている。自分なりの具体的なアプローチについて、以下に記載しよう。 ムリ・ムダ・ムラ殆どの人はトヨタ生産方式で聞いたことがあると思うが、ムリとは負荷が能力を
以下の昨日の日記にレスをいただいた、ありがとう! 残業を悪とするチームを作るだけでは全く足りない - Change The Worlds 置かれている環境によって考え方や感じ方は異なると思うので、自分の置かれていた環境を書くと 残業すればしただけ残業代がでる(=サービス残業はない) 従業員が多い(wikipediaの定義では大企業になる) である。 また、こちらにも書いていた回避策を邪道→覇道→王道の順に実施し、残業のない状態にすることもできている。 SIerにてエンジニアの残業を無くす方法 - ledsunの日記 ここで考えるのはSIerにてエンジニアの残業を無くす方法です。残業を無くすには労働生産性を上げればよい。 までは分かる。が、ここから繋がる 労働時間が月184時間以内で売上が今と変わらなければ、給料を上げない限り残業は無くなる。 の部分に疑問符が浮かんだ。殆どの会社は売上を拡大
残業を悪とするチームを作ろう - ひがやすを blog 仰っていることに対しては概ね同意。 でも大事なことが欠けている。それは『残業を悪とするチームを作るだけでは全く足りない』ということだ。 残業を悪とするチームを作った後に起こる事象前提条件として、ひがやすをさんも書かれている通り、社員の稼働率が売り上げに直結する所謂SIerの場合の話。 仕事の質に誇りを持ち、残業を悪とするチームを作ることは、あなたにもできます。 仰る通り、『仕事の質に誇りを持ち、残業を悪とするチームを作ることは、あなたにもできます』は正しい。色々苦労をするだろうけど、残業を悪とするチームを作り、チームの生産性も他のチームより高くすることはできる。しかし、残業をしなくてすむ様な生産性の高いチームを作ったら上司からの圧力はかからないか?と言うとその答えはNoだ。 殆どの人は体感していると思うが、仕事はできる人に優先的に回さ
こくちーず 6月25日 DevLOVE vs スクラム道(東京都) Togetter DevLOVE VS スクラム道 vol.1 - Togetter DevLOVE VS スクラム道 vol.1 (オレオレまとめ) - Togetter 6/25(月)は株式会社 VOYAGE GROUPを会場に開催された『DevLOVE vs スクラム道』を手伝ってきた。 オープニング集合時間になっても主催者(主にDevLOVE側)が集まらず、ちょっとばたばたしたが、ほぼ参加者は定刻通りに集まられたので、会場説明及びスクラム道、DevLOVEのコミュニティ紹介からの開始。スクラム道の紹介プレゼンは直前まで作っていた様子、DevLOVEの紹介プレゼンは駆け足での紹介だったの詳細が分からなかった。本編1部-ディスカッション『フィッシュボウル式ワールドカフェ』ということで、それぞれのコミュニティから代表が出
Togetter スクラム道.09 #scrumdo - Togetter スクラム道場.09 に参加してきました。 今回のテーマは「インセプションデッキ」で、講師*1の[twitter:@nawoto]さんでした。 最初に30分行われる発表はインセプションデッキに関する内容でした。 また、議論の元となる参加者からの問いに関しては、私や参加者の方がスクラム道中に呟いており、それらはTogetterにまとめられているので、そちらをご覧ください。 質問タイム07〜08に参加していないので、方針が変わったのかどうか分かりませんが、以前の参加者同士が議論するというものではなく、[twitter:@nawoto]さんに対して、質問をするといったものでした。 Q. インセプションデッキをするに当たって、使用しているガジェットはありますか? 付箋紙 ホワイトボード Q. 実際にPO(受託、サービス)と一
これはアジャイル開発を自分以外の人に伝えようとする際に必ず立ち塞がる疑問だと思います。 社内でアジャイル開発を認めてもらうまでに社内外問わず、色々な人からこの疑問についての意見を頂きました。「朝会(デイリー・スタンドアップ・ミーティング)をしたらアジャイル開発」、「TDDをしたらアジャイル開発」、「ペアプロをしたらアジャイル開発」、「いやいや、それら3つをして初めてアジャイル開発」等々の意見を聞きましたが、少なくとも私の中ではこれらではないと考えています。現にスクラムではTDDやペアプロをする様に規定していませんが、それをもってアジャイル開発ではないとは言えないはずです。同様に、朝会(デイリー・スタンドアップ・ミーティング)をしているからといって、それをもってアジャイル開発であるとも言えません。 他にも「ユーザに価値を提供する意識を持って行動を判断出来ること」、「ユーザとチームを組めること
ではない。 事の発端は以下の blog の アジャイルサムライ読書会(横浜道場) 第1回に参加してきた #agilesamurai #横浜道場 - Shinya’s Daily Report のこの部分 アジャイルを導入するには“ツール(Redmineとか)を用意する” これへの私の所感は である。 ツールの導入から始めることについて、私のツイートを切欠に色々ツイートされていたりするが、一行目に書いてある通り、本質的な問題はそこではない。 確かにアジャイル開発の度合い、割合を高めていくと、ツールによる負荷の軽減がなければ、回らなくなる。これは事実だ。しかし、それとアジャイル開発を始める際に最初にツールを導入することは全く異なる。まず自分たちの状況にアジャイルのメソッドがどの様に作用するかを知る必要がある。Redmine が例として出ていたが、Redmine を使うならば、どの部分の負荷を軽
日本鼻メガネの会 新年会の2次会にて話題となったことについて、深堀したいと思います。 これは私の主観、考え方ですので、「そういう考え方もあるか」程度に思ってください。 私はまず何よりも先に自分で考えて、行動することが大事だと思います。最後に別の例も示しますが、プログラミングを例にすると、プログラミングを始めようと思ったら、最初に本を買うのではなく、まずはWebサイトを検索して容易に知り得る情報を見ながらでも簡単なプログラムを作ってみることが第一だということです。 また、たくさんのことを覚えることよりも、やり方を自分で考える経験をたくさん積む方が大切です。プログラミングを始めようと思うと、数多くの言語があることを知ると思います。しかし、言語というのはそもそも所詮は誰かが作ったプログラムに過ぎません。 ことの本質はそれ(言語、つまり道具)によってどんな処理(計算)をどの様な方法で行うかにありま
はじまり 文章に少しおかしい部分がありますが、そこは大事な部分ではないのでおいておくとして、この一連のTweetをReTweetしてもらいました。で、自分からすると最多RT数となる一番多いRT数のTweetは以下のものになります。 自分の一連のTweetで言いたかったことは受け手が理解出来る、納得出来る言葉でなければ、どんなに良い言葉でも伝わりませんよということです。そういう意味では、経緯の部分ではなく一部の言葉だけがRTされてしまったということは私の言葉が足りなかったことも意味しているので、そこは反省しています。 大事なことは『何を(What)』ではなく、『何故(Why)』人は『何を(What)』ではなく、『何故(Why)』に動かされる。まず第一に、人は『何を(What)』ではなく、『何故(Why)』に動かされます。 皆さん、胸に手をあてて思い出してください。あなたが他人から何かの作業を
こちらで約束していた通り、FeatureBranch を翻訳しました。ダメダメかもしれませんが、wikiの方に記載しようと思います。 原文はこちら フィーチャーブランチ gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。 ここ、特にフィーチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 シンプルな(分離した)フィーチャーブランチ フィーチャーブランチの基本的な考え方はフィーチャー(またはあなたがその言葉を好むのならばストーリー)の作業を開始する際、そのフィーチャー上で動作する様にリポジトリからブランチを取得することである。DVCSでは、あなた個人のリポジトリにこれを行うが、この種の作業は、中央集中型バージョ
はじまり アジャイルな開発を始めたばかりの時、最初に乗り越えるもの@ryuzeeさんが仰る様に、今までのアジャイルではない開発のやり方からアジャイルな開発に変えると、今までの開発のやり方よりアジャイルな開発のやり方の方が作れる物の量が減ります。 例えば、『アジャイルな開発を始めたばかりの時、最初に乗り越えるもの』をいつものやり方として、左から右へ『ア・ジ・ャ・イ・ル…』と書いていくのと、昔の日本の様に右から左へ『アジャイル…』と書いていくのでは日頃書き慣れていない右から左へ書いていく方が書くのが遅くなると思います。 この理由は単純で、慣れ親しんだやり方と慣れ親しんでいないやり方では経験による作業の熟練度に差があるので、出来る量が減ってしまうのです。 何が違うのか?では何故私の開発チームは増えたかと言うと、アジャイルなやり方にする際に以下に気をつけているからです。 一気に変えない チームみん
スクラム道バーストに参加してきました。 当日のテーマ これまでのスクラム道を知っていただければと思い、過去(スクラム道.01�、02、03、06)のどれかを会場の皆さんに決めてもらい再演します。 スクラム道.01 「ふりかえり」KPT is harmful スクラム道.02 「スプリントバーンダウン」スプリントバーンダウン虎の巻 スクラム道.03 「スプリント計画ミーティング」 スクラム道.06 「スクラムマスター」 ※スクラム道.04 「スプリント0」 につきましては読み手の方のご都合がつかないため対象外とさせていただきます。ご了承ください。 当日のタイムテーブル 18:30 - 18:45 テーマ決め、選手入場 18:45 - 19:15 読み手の発表 19:15 - 19:50 ディスカッション ラウンド1 19:55 - 20:30 ディスカッション ラウンド2 20:30 - 2
スクラム道.06に参加してきました。 今回のテーマは「スクラムマスタ」で、講師*1の@kappa4さんの発表の題名は「スクラムマスター?」でこちらで公開予定だそうです。 発表内容は、スクラムマスタについて、知識ややったこと、どう考えるか、行動は?といった内容でした。 詳細はTogetterのスクラム道.06をご覧ください。 イベントの写真はこちらにアップされています。 以下は、プレゼンをふまえて、参加者同士のディスカッションの流れとか私の感想とか覚書です。 Q. SM*2は何をする人? チームの生産性を最大限向上させ、ユーザのビジネス価値の向上に最大限貢献する様にする人。not コード書かない人。 Q. SMとしてチームにやって欲しいことがある。その場合、どういう風に伝える? 指示する派:ティーチングでメンバにやって欲しいことを伝える。 指示しない派:課題をメンバに伝えて、コーチングで相手
Free Mind Plugin 1.0.0 をリリースしました。 https://bitbucket.org/changeworld/redmine_free_mind ダウンロードはこちらからどうぞ。 今回対応した機能は、以下になります。 WikiにFreeMindファイルを添付して、表示させたい。 Free Mind で作成したマインドマップ限定ですが、Redmine の Wiki で表示したい場合はお使いください。
スクラム道.02に参加してきました。 今回のテーマは「スプリントバックログスプリントバーンダウン」で、講師*1の@ryuzeeさんの発表の題名は「スプリントバーンダウンチャート虎の巻」です。 発表内容は、スプリントバーンダウンの簡単な説明とその後はスプリントバーンダウンをどう使うか?という実践的な内容です。 具体的な流れとしては以下の通りです。 スプリントバーンダウンについてのおさらい スプリントバーンダウンは改善の為のインプットとして利用する事が大事 スプリントバーンダウンの落ち方の形状((グラフの形状)))といったパターンの確認 しかし、形状だけ見て判断をするのではなく、現場の状況を把握する事が大事 綺麗に落ちていてもそれはテストをサボっていたり、リファクタリングを疎かにしているのかもしれない スプリントバーンダウンに別の指標を追加する事によって、より状況を把握するのに効果的に そこで
JRuby on Rails実践開発ガイド (Professional Ruby Series) 作者: Ola Bini,株式会社万葉,大場光一郎,大場寧子,田中祐樹出版社/メーカー: 翔泳社発売日: 2010/05/18メディア: 大型本購入: 2人 クリック: 111回この商品を含むブログ (12件) を見る 「JRuby on Rails実践開発ガイド」目次 日本語版の刊行にあてて(原著者まえがき) 訳者まえがき 刊行に寄せて 謝辞 著者について テクニカル・レビュワーについて 第1章 はじめに 背景となる知識 なぜ JRuby on Rails なのか? 本書の構成 まとめ 第2章 JRuby on Rails をはじめよう JRuby のインストール RubyGems のインストール データベースのセットアップ まとめ プロジェクト1 オンラインストア(Shoplet) 第3章
このページを最初にブックマークしてみませんか?
『Change The Worlds』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く