ソフトウェア開発の世界には、様々な法則があります。 遅れたプロジェクトに人数を追加しても、さらに遅らせることになるという「ブルックスの法則」は有名ですね。他にも、ソフトウェアの構造は、それを作った組織の構造が反映させるという「コンウェイの法則」などなど。（参考） 最近、ソフトウェア開発を通じて感じていることは、ソフトウェアの仕様を決める人の数は、ソフトウェアをプログラミングする人の数と同じだけ必要なのではないか、ということです。 そこで、この記事ではこれを「人数等価の法則」として考えてみることにしました。 balance / hans s これまで考えられてきた開発にかかる人数の感覚 ソフトウェア開発には、何を作るかを考えるという段階があって、どう作るかを考えてプログラミングするという段階があります。それを２人以上の人間で役割分担するとしたら、その間に入るものが「仕様」となります。 「仕様
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファ
The document discusses specification by example (SBE) as an approach to software development. It outlines key aspects of SBE including deriving scope from business goals, specifying collaboratively through examples, refining specifications, automating examples, and validating frequently through living documentation. An example is provided showing how SBE can be implemented using Cucumber features,
■ [Rails] erase_render_results で render をキャンセル ビジネスロジックが複雑になってきたのでafter_filterでいろいろフィルタリングするようにして、問題があったら RecordNotFound を raise するようにしたところ、render2回やっちゃダメって言われたので、「erase_render_results」をつけた。こんなのあったんだーというメモ。 class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found protected def record_not_found erase_render_results # コレ render :file =
システム開発案件が寄せられた時、それがどの程度の工数を必要とするかを見積もることはとても重要だ。開発の「規模感」がイメージできれば、投入すべきリソースも見当がつくし、それはそのままコスト面での計画にも結び付く。 経験則に拠ったり、開発協力ベンダーが提示してきた概算に頼るという方法もあるが、世の中一般の開発プロジェクトから導き出した「指標」を参考にすることも検討したい。 日本情報システム・ユーザー協会（JUAS）が2004年度から毎年続けている「ソフトウェアメトリックス調査」では興味深い調査結果を発表している。スクラッチ開発、つまりパッケージソフトを利用せずに独自でゼロから開発することを前提とした場合、対象システムに実装する「画面数」「バッチ処理数」から、おおよその総工数が見積もれるというものだ。その計算式は以下で表される。 総工数（人月） ＝ 0.97 × 画面数 ＋ 0.26 × バッチ
結局皆さんテスト密度等の実際の数字が気になるところですよね。今まで出てきた数字をまとめてみます。指標の数字は実施している手順やテストケースの書き方等に大きく影響されるので一概にこれが正しいという数字はありません。しかしなにも手がかりや実績も無いという人もいらっしゃるかと思いますのでそのような場合は以下のような設定をおいてみるのも良いかもしれません。ちなみにKLOCはJavaがベースです。 開発期間 開発期間＝工数^0.5 開発期間は平方根で求めます。たとえば9人月の作業は3人で3ヶ月です。 最大期間短縮率 最短開発期間＝工数^0.5*0.75 短縮率は最大75%。これ以下の開発期間はデスマ高し。 工数割合 設計:実装・テスト 3:7 設計終了段階で既に4割くらい使ってしまっているとかなりデスマ率は高いと思うので機能を減らす等早めに手を打った方が得策かもしれません。 ケース数 単体：150ケ
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
Web業界の業務委託について考察してみたので記事を書いてみる。 今回は、業務委託費として必要な単価を、各種パラメータを適当に置いて計算した。 アウトプットは、「会社がそれなりに幸せであるための、平均単価」です。 ■必要なパラメータ 1. 必要な給料の定義 社員平均 700万円／年とする。 なお、労働35年として、35-40歳くらいでピークで700万とした場合、大体、生涯賃金は下記。 青棒：1億9000万円（ピーク後の下がり方が緩やか） 赤棒：1億5000万円（ピーク後の下がり方が急） 現実的には、赤棒よりもさらに厳しい業界かも。ここは別途考察します。 2. 平均チャージ率 80%とする。 日々の業務のなかで、クライアントにチャージ（請求）できる業務の割合が何%くらいかという指標。 たとえば社内の行事や、営業にかかる時間、瑕疵対応にかかる時間とかは、クライアントにチャージできない。 もちろん
変更履歴 2012-06-24 ドキュメントの所に *diag シリーズについて追記 概要 開発があればリリースがあり、リリースが終われば、メンテナンスがあり、さらに開発があります。プロダクトが EOSL (End Of Service Life) を迎えるまではこれを続ける必要があります。 去年の 8 月に「継続開発のススメ」というので、やっていることをまとめたのですが約 1 年経ってもう少し細かくまとめて見ようと思いました。基本的には自分がいる環境を前提に書いてます。 継続開発のススメ http://d.hatena.ne.jp/Voluntas/20110823/1314036482 開発スタイルは常に変化し続けていくべきだと思っています。これだ、というのを作らないのが一番良い開発スタイルでは無いかなと。 脳内を書き出しているので、日本語がおかしい上に一貫性が無いと思います ...
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
という資料を捏造したい気分だったので書いてみた。特に意味はないしオチもない。 フリーマンを置く目的は、以下である。 ・システムの品質向上 ・プロジェクトに潜伏している問題の早期発見 ・メンバーの技術レベルの把握と向上 フリーマンは明確なタスクを持たず、名前の通り、手の空いた状態でプロジェクトに携わるエンジニアである。 システム開発におけるフリーマンが行うべき主な作業は以下である。 ・ソースコードレベルでの問題の発見と指摘 ・テストコードの不足分の拡充 ・仕様が曖昧且つ後日問題となりそうな点の明確化 ・メンバーの技術レベルの把握と作業分担の適正化 フリーマンは直接コードは書かない。その代わり、製造されているすべてのソースコードを把握し、問題があれば指摘を行う。 また、技術レベルに問題があるメンバーがいる場合は、指導もしくは適切な作業の割り当てを提案する。 フリーマンの存在が効果を発揮するのは
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、システム統括部の駒田です。 昨今、内部統制やJ-SOXといった言葉を良く耳にしますが、 ヤフーもご他聞に漏れず、粛々と対応を進めて参りました。 今回は、その対応の一環として行った、 「開発と運用の分離」に関してのエントリーをさせていただきます。 例えばですが... 開発成果物であるソースコードをテスト終了後に改ざんし、 不正に利益を得る様なエンジニアが存在していた場合、 それはヤフーにとって、一般のお客様に対する裏切りであり、 信用の失墜となってしまいます。 このような事態を回避するため、 当開発部では開発者と運用者とを明確に分離し、 開発者はリリースモジュールに触れる事が出来ない。 運用者はソースコードに触れる事が出
チーム開発のためのオープンな統合プラットフォーム「Jazz」 Jazzプロジェクトと言っても日本ではご存じない方もいらっしゃるかもしれません。「Jazz」とは、ソフトウェア開発チームのコラボレーションを支援するための新しいテクノロジー・プラットフォームであり、それらを開発するプロジェクトの名称です。大きな成功を収めたEclipseプロジェクトの次のステージとしてIBMが進めているプロジェクトです。Jazzプロジェクトは、人々がソフトウェア開発においてどのように協調して働くべきか、すなわち、いかにコラボレーションし、生産性を向上させ、透明性を確保してソフトウェア開発を行うかという観点で開発されています。 Eclipseは、エディター、コンパイラー、デバッガーなど開発者がこれまで別々に利用していたツール群を1つの環境に統合したプラットフォームを提供することによって開発者個人の生産性を向上させて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blogger
