ソース静的解析ツール「SonarQube」は「Quality Gates」という、コードレベルの品質基準を設定できます。ただ、どういった値を設定すればいいか？ 悩ましいところなのでいろいろ調べて自分なりの基準を考えてみました。 Quality Gatesの魅力 Quality Gatesの魅力。それはずばり、基準値ができることだと思います。SonarQubeによってソースコードレベルで解析が行われ、コードカバレッジ、ソースの重複度、複雑さといったデータがわかるようになれば、次はそのデータをどう扱うかがポイントになるはずです。 周囲でSonarが流行っていたときに感じたのですが、解析結果がグラフィカルに確認できるようになったのに、「で、どうしようか？」と困っている雰囲気がありました。確かに、「Complexity 8.2」って言われても、それがいいのかわるいのかよくわからない。 だから、得た

By: Maegan Tintari ご結婚おめでとうございます。また、ご両家の皆様にもお祝い申し上げます。おめでとうございます。私は新郎と仕事を通じて出会いました。当時、あるプロジェクトを私が担当することになり、そこにアサインされたのが、まだ新人の彼だったのです。 新郎との出逢い その仕事は私にとっても、思い出深いものでした。他のメンバーも同じようなことを言っていましたが、今日、この場所にそのときのメンバーがたくさん来ているので、恐らくそういう仕事だったのだろうと思います。 仕事ではたくさんのことを話しました。仕事の話やプライベートの話。エンジニアとしての技術の話など。仕事を通してたくさんの時間が私たちにはありましたが、いつか終りが来るのがなんだか寂しいような。今思えば「青春の1ページ」に似ていたのかもしれません。 あの日。当たり前だった電気が使えなくなった。 そして、仕事も半ばのころ、

誰かが言いました。人生には三度のモテ期がある。似たような感じで、自分の仕事にふりかえる時期がやってきた気がするので、真面目に仕事の話を書いてみます。どちらかというとアジャイルの文脈が多いですが、これまで考えたことの総まとめとして。 はじめに 個人の意見です。できるだけ、相手の立場もふまえて考えるようにしてきましたが、僕はそこまでできた人間でもないってこと。 できるだけ、問題や課題の解決策を考えてきましたが、全然うまくいかなかったことのほうが多いです。結果的にうまくいったことも多数ありました。つまり、何が正しいかなんて答えはないってこと。 全体最適を考えるチーム時代 SIerでJava！ WebLogic！ Oracle！ 業務Webアプリ！ をしていて、もっとWebよりの仕事をしたいと考えて転職。「将来、アーキテクトになりたいっす！（おめめキラキラ）」と面接で話したはずなのに、「標準化」と

彼は6～7年前に今の会社に転職している。入社時、彼はある数名のチームに配属されて、そこでリーダーをしているKさんという人に出会った。そして、数ヶ月で彼は気がついたらしい。Kさんは仕事ができないと。 当時のその会社 その会社は急成長を続けていて、ベンチャーからはじまった企業だったので、創業当時のマインドをもった人が多く、とても活気があった。 しかし一方で、競争が激しく、人の出入りも激しく、行き過ぎた行動をする社員も中にはいた。 「勢いのある新興企業は、どこも同じだろう」と彼は補足した。 仕事のできないKさん 自分の実力を試したいと思って入社した彼は、仕事ができないチームリーダーのKさんに戸惑った。 彼がリードする仕事にはビジョンも戦略もない。だから、アウトプットが当然でない。だから売上げにも貢献できない。チームの評価は当然さがる。 意を決し、Kさんに課題点・問題点を相談しても、態度が急変して

昔、アジャイルにおけるリーダーシップと組織改革について話をしたことがあります。こんなネタを話した本人がいうのもなんですが、今になって思えば、組織改革なんて不可能では？ と思いはじめました。今日はその理由を書いてみようと思います。 アジャイルリーダーシップと組織改革 当時の資料はSlideshareで公開しています。また記事も書いているのでそちらも参照のこと。 //daipresents.com/2012/post-3985/ 要約すると、「個人レベルでアジャイル導入してみたけど、いろいろあったけどなんかうまくいってる気がするよ」という話です。 さらに細かい話をすると、当時「正式な」アジャイル導入トライアルプロジェクトというものが別であり、そちらは有名なアジャイルコーチさんがサポートするということになったので、「自分は自分でがんばろう」と別ではじめた経緯がありました。 結果だけでいうと、正式

あなたが生まれていろいろ変化がありました。自分の保険を見なおしたのもそのひとつです。お父さんは図書館で本を読みまくって勉強したのですが、せっかく得た知識なのでわかったことや考えたことをまとめてみます。 これまでの保険はボッタクリ まずは、お父さんの入っている保険の内容を確認しました。それは特約がたくさんついて契約がわかりにくいものでした。自分でわからないものにお金を払うのは変ですよね。しかし、当時は「社会人になったのだから」「これからに備えて」という聞こえのいい言葉にのせられていました。 また、お父さんの保険は、お父さんのお母さん（あなたのおばあちゃん）の友人からおすすめされて入った保険でした。そのまま引き継ぐのではなく、どこかのタイミングで今の自分にこの保険が必要なのかを考えるべきでした。 さらに、現在の値段が高いのか安いのかがわかっていませんでした。今だとネットで気軽に試算でき、比べて

gemmoth via frickr 最近、「いいチームだなー」っていうのと「残念なチームだなー」っていうのを同時期に見ることがありました。どちらもアジャイル開発に取り組んでいたりしたので、残念な方を「うんこアジャイル」と名づけ、原因と対策を後輩といろいろ話しました。 よくある「うんこアジャイル」 思いつく限りの共通点を挙げてみましょう。 教科書通りのアジャイル開発を当てはめようとしている メンバーの性格に問題があるように感じてしまう 自分がやっていることが正しいか自信がない トレーニングや認定試験を重視する このへんの「不安」は『リーン開発の現場 監訳者まえがき』も参考になるかと思います。共通点だけ読むと「ああ、なんかつらそうだな」って思うのですが、後輩がこんなことを言ってました。 ちょっとうんこだろうと行動した分、失敗してもそこからまた行動しようとしている分、何も変わる気もない変える気

1位もリーンスタートアップネタ。わずか10枚の資料が1位ってのが熱い。 6位から50位まで こうやってみるといろいろあって面白いですねぇ。スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!は自分の環境にあわせた感が素敵だし、AgileJapan2010 佐賀県庁でもできる！プロジェクトファシリテーションは、何回みても面白い熱い物語だし、「納品のない受託開発」にみるソフトウェア受託開発の未来は講演を2〜3回見ているけど、何回聞いても面白かった。 33729viewsUXのためのUIデザイン 31199viewsふつうの受託開発チームのつくりかた 28019viewsAgileJapan2010 基調講演：野中郁次郎先生による「実践知のリーダシップ～スクラムと知の場作り」 27941viewsProject Facilitation From Hiranabe

僕はコミュニティに参加したり、イベントを手伝ったりする機会に恵まれ、いろんな経験をさせてもらっている。でも最近、コミュニティは面倒くさく、アジャイルコミュニティは超面倒くさいのではないかと考えるようになった。 「なぜ」とか「価値」とかが面倒くさい そう思った理由は、[読書]わかりやすいアジャイルの教科書 – u1r_red’s blogを読んだことが大きい。書評が書かれたブログだけど、こんなことが書かれている。 先駆者に質問すれば「あなたは、なぜアジャイルにやりたいのか？」と質問で返されるようになった。 確かに。僕も去年は発表をいくつかしてきたが、質問に対してこういった質問を返していた記憶がある。しかし、こうやって改めて読んでみると、不親切（不誠実）だなぁと反省だ。 確かに、つきつめれば「なぜ？」とかに行きつく。でも、そうだなぁ、一昔前には、「価値」という言葉をよく聞いたがこれもよく似てい

アジャイル開発の本質とスケールアップ読書会というのを、会社の先輩が開催しておりまして、 この本は、@ryuzeeさん翻訳のアジャイル関連書籍ベスト100にもランキングされています。（が、翻訳があまりよくない気がする） 2012/08/15追記 – Big PictureはWebで詳細が確認できるようになっていました。詳しくはこちら。 そこで、以下のようなエンタープライズアジリティの面白い図を教えていただきました。 以下、適当な翻訳 このブログのリーダーたちは、エンタープライズレベルで効果的なソフトウェアアジリティの実施には、たくさんの巧みな技が必要だと気づいている。 十分にコミットできている部門や企業であっても、アジャイルの紹介や、たくさんの基本的なアジャイルプラクティスの習得に6ヶ月から1年かかってしまう。そして、生産性を勝ち取ったり、それほどの重要なエンタープライズレベルのアジャイルへ

I Love You Lots by jeff_golden, on Flickr 最近、とあるマネージャーと飲んでいて「勉強会で共感したことが社内で伝わらない理由」についていろいろ話しました。 個人的に組織や人のマネジメントに興味をもつようになり、いろいろ考えがでてきたので、忘れないように書いておこうと思います。全ては僕個人の印象や経験による仮説でしかありませんがご了承ください。まぁブログなんてそういうもんです。 コミュニティ内での反応が社内で起こるとは限らない 最近は勉強会が盛んに行われており、たくさんの知識や人にアクセスしやすくなりました。そんな中、すばらしいセッションを聞いて感化されたり、自分から発信したりして、さまざまな反応を体験したりすることもあると思います。 しかし、残念ですが、体験や経験した反応が、社内で同じように起こるとは限りません。 外での発表で得たアイデアが受け入れら

I participated “Certified Scrum Product Owner Training” by Jeff Patton. I’m not understand about product owner’s role and their perspective but this training gave me new insight. Master Jeff’s explanation was passionate and he shared us much experience. I was impressed to meet him. Thank you so much Jeff. 10/20〜10/21の二日間。ジェフ・パットン氏による認定スクラムプロダクトオーナートレーニング、「情熱プロダクトオーナーシップ」に参加しました。 ジェフ・パットン氏は、日本の実践者で

前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考