タグ

ブックマーク / sakaba.cocolog-nifty.com (7)

  • 労務費からメトリクスを考える - IT勉強宴会に参加して - - ソフトウェアさかば

    第38回 IT勉強宴会in大阪は「中小企業の社長は何を考えているか」というテーマでした。簡単に言うと「なんぼもうかりますねん?」と常に資金繰りを考えていると理解しました。 お話の中で気になったのは、粗利益の考え方です。労務費を含めた粗利益を中小企業の社長さんに説明すると、労務費を入れると作業をしない人が出ると言われたそうです。 プロジェクトに最適化すると労務費を少なくしようとして、余っている人を有効に使おうとしないと言う事なのでしょう。ソフトウェア開発では労務費がほとんどを占めますので粗々(大まかな粗利)と言えども考えにくいですが、同時に稼働率を管理する事を考えると、その主旨は理解できます。 この労務費の扱いを聞いて思い出したのはアメーバ経営です。アメーバ経営ではGQMのようにゴールからメトリクスを決めます。 アメーバ経営では付加価値を示す時間あたりの採算(人件費を含まない)を用いて、「売

    労務費からメトリクスを考える - IT勉強宴会に参加して - - ソフトウェアさかば
    iR3
    iR3 2015/01/13
    なるほど “会社のゴールを達成するには、部門の利益だけをゴールとし、それ以外の監査的なメトリクスはトレーサビリティと部門内での自律的な管理に用いれば、うまくいくようになるのではないかと思いました”
  • [#Agile] アジャイル開発の課題と対策 その1 - ソフトウェアさかば

    アジャイル開発が日で知られるようになって10年以上経ちました。去年、あるいは一昨年からアジャイル開発2次ブームになって、大手ベンダーが取り組みを始めるようになりました。たぶん、今回は一定の広がりを見せると思います。 しかし気になるのは「なぜ、普及が遅れたか?」です。アジャイル開発の特長は数多くありますが、コード優先の繰り返し、テスト自動化、 現場能力発揮、顧客優先、いずれも大きな障害と考えにくく、 そのいずれを考えても遅れた説明がつきにくいと思っています。 関連する文献 そこで思い出したのは、児玉さんの「UMLモデリングの質」に書かれた一文でした。 1990年代に入って、世界では構造化分析/設計手法がオブジェクト指向分析/設計手法に取り込まれました<中略>。一方、日では、情報システムをWebアプリケーションで作成する事が主流になる2000年までは、DOA型の構造化分析/設計手法が依然

    [#Agile] アジャイル開発の課題と対策 その1 - ソフトウェアさかば
    iR3
    iR3 2013/08/27
  • [#47Redmine]ユーザコミュニティが盛り上がってきた - 第5回 品川Redmine - - ソフトウェアさかば

    品川Redmine 第5回勉強会で基調講演をさせていただきました(つぶやきのまとめ:togetter、@akipiiさんの感想)。 講演は「チケットシステムの可能性 - 開発から業務まで -」と言うタイトルで、チケットシステムの可能性をメタに説明した後に、社内の業務改善例を紹介しました。 業務系の若い方達はモジュール間結合度を知らなくとも、オブジェクト指向なので引数をきちんと使われると思います。しかし、組み込み系だと諸般の事情で外部変数を使う事もあるので、身近に感じられた方もおられたかと思います。業務形の方は年配の上司の方への説明などの参考にしていただければと思います。 社内業務の例はエクセルシートをメールで配って行っているPCの資産管理業務をRedmineで行いつつある例で、200回繰り返していた庶務の方の作業をそれぞれ1回ずつに改善した例です。 勉強会はワークショップが中心でしたが、L

    [#47Redmine]ユーザコミュニティが盛り上がってきた - 第5回 品川Redmine - - ソフトウェアさかば
    iR3
    iR3 2013/07/03
  • [#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 - - ソフトウェアさかば

    以前ご紹介した平鍋さんと野中先生の書籍「アジャイル開発とスクラム」は私のお気に入りの1冊です。アジャイル開発とはどのようなものであるかだけでなく、モノ作りはどうあるべきか、人が知的な存在として関わるにはどうすれば良いかが書かれているからです。 アジャイルスクラムが完成する際に必要だった最後のパーツが野中先生の実践知とSECIモデルです。今回のSEA関西プロセス分科会での講演は「アジャイル開発とスクラム」の内容ということでざっくりとお願いしました。そして、お話の中心は実践知とSECIモデルで、このでとても大切な内容の一つだと思いました。 アジャイル開発(というかXP)が日に入って来た時、その背景にある「なにか」に気づいて、我々は興奮しました。その「なにか」は、人が知恵を出し合い、助け合い、より良いモノ作りを目指す事だったのかもしれません。 SECIモデル 書籍に載っているSECIモデル(

    [#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 - - ソフトウェアさかば
    iR3
    iR3 2013/07/03
    ふむふむ「エンピリカルソフトウェア工学において観察は基本だが、鳥をいくら観察しても空は飛べない」
  • 理にかなったアジャイル王子の華麗なるペラペラ英会話メソッド - 第24回 関西IT勉強宴会 - - ソフトウェアさかば

    英語が大の苦手で、英語の入門書は山の様に買いました。何度挑戦してもやる気が続くのは初めだけで、もう買うまいと決めていました。しかし、第24回 関西IT勉強宴会 「ITエンジニアの ゼロから始める英語勉強法」で、アジャイル王子こと著者の牛尾さんの説明を聞いて、このはぜひ買いたいと思いました。 王子の説明をまとめると(私の理解した)ポイントは以下の3点です。 能力にあわせて勉強法を選ぶ 発音から始める 英語脳になるには英語漬け シンプルな方法ですが、これが理にかなっています。 能力にあわせて勉強法を選ぶ 多くの学習法はそれなりに納得できる説明があり、良さそうに思うのですが続きません。これは私も経験したことです。王子いわく、学習法にはそれぞれ前提があるが、説明されていない。前提となる能力がなければ身に付かないし、どの学習法もある程度続けると伸びなくなってくるので、別の勉強法に変えなければいけな

    理にかなったアジャイル王子の華麗なるペラペラ英会話メソッド - 第24回 関西IT勉強宴会 - - ソフトウェアさかば
    iR3
    iR3 2013/07/03
    ふむふむ
  • [#Agile] アジャイル開発は混乱を避ける - ソフトウェアさかば

    アジャイル開発の特徴の一つは混乱を避ける仕組みがある事です。従来の開発方法では、以下のような混乱要因がありました。 1) 変化(仕様変更、実装方法、環境)の無秩序な受け入れ 2) 品質の問題による手戻り作業の増大 3) 作業者間のコミュニケーション不足 コミュニケーションは内容が多いので、この記事では1と2に対するアジャイルの優位性について書きます。 1. 変化の受け入れとリズム 変化の受け入れ アジャイル開発の特徴は早めに小さく失敗する事です。イテレーションと呼ばれる開発期間に区切って繰り返し開発を行う事で、変化による影響を小さくする事ができます。例えば実装が完了してから仕様変更や問題が発覚して、もしその手戻りが全体に影響する場合、n回のイテレーションに分けて開発していたなら、最初のイテレーションで発見できれば被害を1/nにする事ができます。このようにアジャイル開発は作ってから分かる変化

    [#Agile] アジャイル開発は混乱を避ける - ソフトウェアさかば
    iR3
    iR3 2012/10/14
    ふむふむ「品質問題による手戻りの増大は、繰り返し開発によって早めに小さく失敗することで軽減されます。しかし、アジャイル開発はそれだけではありません。バグが発生した際に効率的に除去できる仕組み..」
  • ソフトウェアさかば

    液晶パネルが精細になったLUMIX DC-TX2D全機種の発売を記念して、カメラ選択のポイントと全機種のLUMIX DC-TX2をどう考えたかをまとめました(その1購入経緯はこちら)。 センサーのサイズ 大きいサイズのセンサーの方がたくさんの光を受けられますので、無理に感度を上げなくて良いのできれいな写真をとることができます。一般向けでは35ミリフィルムと同じフルサイズが大きくてきれいな写真えお撮ることができます。 逆にサイズが大きいとレンズのひずみが出やすくなるので、レンズが複雑になって高価に、重く、大きくなります(ひずみが大きいと写真の端の方で柱を撮ると曲がって映るなど見てわかるひずみが出たりします)。価格や携帯性を考えるとセンサーが小さい方が有利になります。 そこでカメラを選ぶ際は価格と携帯性のバランスを考えることになります。 私の場合、下の項目も考慮して1インチで良いと思いました。

    ソフトウェアさかば
  • 1