準委任契約だけど、責任は取ってください
連載目次 準委任契約と請負契約 今回は、システム開発の要件定義工程の契約形態についてお話しする。 本連載の読者ならご存じの方も多いと思うが、情報システムの開発は、準委任契約に基づいて行われる場合か請負契約に基づいて行われる場合が多い。そして1つの開発においても、要件定義工程は「ユーザーの作業を支援する」という意味合いで、成果物の完成責任を負わない準委任契約で、設計以降の工程（ここでは便宜的に「開発工程」と呼ぶ）は「ベンダーが主体となる」ために成果物の完成責任を伴う請負契約で行う場合がよくある。準委任契約は、「専門的知識やスキルを持つ人間が契約で合意した時間働けば、その対価は払ってもらえる」というのが原則である。 では、専門家が一定時間働きさえすれば責任を果たしたことになるのだろうか。 今回取り上げる事件は、ITベンダーが要件定義工程から開発工程までを一貫して行ったが、要件定義に抜け漏れがあ
開発組織の生産性を可視化するState of DevOpsとFour Keysとは(増補改訂版) / Introduction to State of DevOps and Four Keys for Visualizing Productivity in Development Organizations expanded and revised edition
以下のイベントの発表資料です。 https://phpcon.php.gr.jp/2022/ 想定課題 開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。 そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。 その際にこのようなことを言われがちではないでしょうか？ 今動いているものを直す必要ある？ 効果測定どうやんの？ 費用対効果はどれくらい？ パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。 本セッションの目標 以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。 State of DevOpsとは Four K
10の40乗通りの運賃パターンにどう対応する？---オムロンの自動改札機用組み込みソフト
鉄道の自動改札機の重要な機能の1つとして、瞬時の運賃計算がある。改札機に組み込める2Mバイトほどのメモリーを使って、50msec以下で計算しなくてはならない。しかも、駅や路線が増えたり、乗り入れが増えたりする度に既設の自動改札機に内蔵された運賃計算プログラムの書き換えが必要となる。自動改札機を開発しているオムロンソーシアルソリューションズ（本社東京）では、自動改札機に組み込む運賃計算ソフトの開発に独自の手法を用いていることを明らかにした。
請負仕事の愚痴：プログラマー社長のブログ：オルタナティブ・ブログ
このところ愚痴っぽい記事や、説教臭い記事が続いてますが、お盆休みも取れずに、さらに徹夜をしたりなんだりで、こんな時に柔らかい記事が書けるほど器用ではないので、地のままで。。 あるプロジェクトで、とにかく工程管理やドキュメント管理が厳しく求められていて、メンバーも疲弊しており、精神状態や体調にまで影響が出るほどの状態（大げさでなく）なのですが、私は何度も書いているように、短期間のプロジェクトで、なおかつ、試行錯誤が必要なプロジェクトでは、ウォーターフォール型の進め方は無理があると考えています。 私もこのプロジェクトの一部を担当しています。まず、元請けさんから、基本設計書が出てきます。それをベースに詳細設計書を作成するのが本来の流れなのですが、私は交渉して（踏み倒して？）コーディングに着手しました。すると、想定通りなのですが、基本設計書で記述が足りない点がどんどん出てきました。 これは当たり前
“開発のよくある問題”を解決するCMMIの3大メリット－ ＠IT情報マネジメント
効率的に開発作業を行うために、どのような業界標準を使っていても、さらなる改善に組織を導いてくれるCMMI。今回はその3大メリットを紹介する。 （→記事要約<Page 2>へ） 前回、CMMIとは「開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”」であり、単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う「組織としてのビジネスの成功を目指したものである」と解説しました。 また、以下の図1はIT業界で使用されている開発の主な標準モデルと、そのカバー範囲をおおまかに示したものですが、このように、アジャイルとCMMIなど「一連の業界標準はお互いに排他的ではなく、重なる部分が多い」ことも紹介しました。すなわち、今現在スクラムを使って開発作業を行っている場合でも、作業を改善するためにCMMIを有効に使うことができるのです。 図1 IT業界で使用されている主要な業界標準
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
煩雑なことを非属人化し、創造性を高める - Strategic Choice
煩雑なことを非属人化し、創造性を高める萩原 正義どういうこと？ソフトウェア開発の工業化を、大規模な製造の自動化と考えるのはよく見られる誤りです。ソフトウェア開発での工業化は、「人による創造性や知的作業」と、「自動化による煩雑なことの非属人化」の分担で実現します。その意味では、ソフトウェアは完全な工業製品というより、むしろ人の創造力を含んだ「工芸品」を目指しているといえます。技術と創造力を融合したソフトウェア開発の在り方が、「ソフトウェア工芸」の基となるのです。どうして？ソフトウェア開発の自動化は、「繰り返し起こる煩雑な開発」部分を自動化し、省力化するために使用します。ソフトウェア全体を自動化する目的で使うべきではありません。ソフトウェア開発はそれほど単純なものではないのです。また、問題領域あるいは解決領域のスコープ自体も、ビジネスの進化、ソフトウェア技術の進化､要求の変化によって、固定的な
IT産業には民族誌が必要だ 2011-11-08 - 未来のいつか/hyoshiokの日記
先日からContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automationの読書会をしているというのは、日記にも書いた。*1 本日は第3章Continuous Integration（継続的インテグレーション）だ。早瀬さんが2号館のカフェテリアでやろうというので、近所のコンビニでビールとつまみを買いこんで参加した。（うひひ） コンビニ袋にビールとポップコーンを突っ込んでカフェテリアに登場したところ、目ざとくビールを発見され、「おっビール」と言われるのだが、「えっビールじゃないんですか」と返す。早瀬さんもわたしのビールにつられてドリンクとつまみをコンビニに買出しに行った。 そんなこんなで、飲みながら第3章は始まったのであるが、その前にわたしのヨタ話を披露した。 Conti
ソフトウェア開発に本当に必要なものは人手か？ | Social Change!
当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。 SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。 ・アジャイル開発のボトルネック ・Publickey「納期を半分にしてくれ、金なら出す」 大規模なソフトウェアを作るには、大人数が必要と考えがち
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
12-コードは設計である - やさしいデスマーチ
「プログラマが知るべき97のこと」の12個目のエピソードは、設計と自動テストに関する話題です。重要なので引用します。 私たちは、「コードを書くことは設計をすることである」ということ−機械的な作業ではなく、創造的な仕事なのだということーを肝に銘じる必要があります。 ソフトウェア開発が行われ始めた頃に比べ、求められる要件も機能も複雑になっています。一方でプログラミング言語・フレームワーク・ライブラリ・開発環境など直接的なコストは下がり、ソフトウェア開発での設計に関する比重が高くなりました。つまり、現在のソフトウェア開発では与えられた仕様をそのままコードに落とすだけの人材は不要になっているのです。各プログラマは優れた設計をすることが求められます。さらに、スピードや要求定義の能力も求められています。 このような状況で、十分な品質を確保して行くには「自動テスト」が有効ではないか？と本文で述べられてい
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
第8回 ソフトウェアデベロップメント：キャリアアップのカギは強みや得意分野の確立
今回は、ソフトウェアデベロップメントのモデルキャリアパスとキャリアアップのポイントを紹介しよう。ソフトウェアデベロップメントとは、OS、ミドルウエア、業務パッケージなどのソフトウエア製品の企画、仕様決定、設計、開発を手がける職種である。 図1に、ソフトウェアデベロップメントのモデルキャリアパスを示す。 まず入社して数年間は、プログラマとして、ソフトウエア製品の実装やテストを担当し、開発手法などの基本技術・手法を習得する。そのうえで10年目までに技術リーダーとなり、製品開発デザインなど他の役割も兼務しながら、得意領域において誰にも負けない高度な技術力を習得する。 10年目以降は、製品アーキテクチャの設計や基盤技術に関する業務など、より高度な技術力が必要で責任も大きな業務に携わりながらリーダーとしての実績と経験を積み、20年目くらいから、個人の得意分野や強みを生かして、様々な分野のプロフェッシ
もう携帯開発やデジタル家電の開発現場は破綻しているのではないか
今年の残業可能時間がだんだんと少なくなってきている。 労働基準法の「36協定」で決まっている年間の残業限度時間の残りが、11月～3月までの5ヶ月で割ると1ヶ月あたり平均して40時間の残業分しか残ってない。 1ヶ月40時間「も」ではなく40時間「しか」、と言ってしまう感覚自体がどうかという気もするけど、数年にわたってこんなことをやっていると感覚が麻痺してくる。 季節ごとに複数機種を出す携帯電話の開発なんかは、すでに月～金曜の週休2日のペースでは開発スケジュールが最初から破綻するほど短納期＆開発ボリュームの多さになっている。メーカーから「恒常的な土日の出勤体制を検討ください」と要請が来るほどだ。平日でも朝から終電近くまで作業しているのにもかかわらず。 中には、スキル不足ゆえの非効率な作業で自分の首を絞めている部分もあったりするのだけど、だいたいは ・数機種の平行開発スケジュール ・最後まで固ま
技術的負債: 柴田 芳樹 (Yoshiki Shibata)
リーンソフトウェア開発と組織改革 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳出版社/メーカー: アスキー・メディアワークス発売日: 2010/10/09メディア: 単行本（ソフトカバー） 技術的負債 成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・ 誰が引き継いでも意図が明確に伝わるコードを書こうとせずに、不明瞭なコードがあっても受け入れてしまう。開発者は、特に経験の浅い開発者は、「クリーンなコード」の書き方を訓練されるべきだ。クリーンなコードとは、わかりやすいロジックに基づく、
サイボウズで学んだこと - IT戦記
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 （写真はゆうすけべーさんです） この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
そろそろIDEよりコマンドラインのほうが理解が深まるという有害な妄想は捨ててはどうか？ - きしだのはてな
「Java入門ブックガイド（入門編)よりよき入門書と出会うために」を読んで。 第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。 コマンドラインでは慣れ親しめない サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。 「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか？ 現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。 そして、まだプログラムの面白さを知りません。 コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。 それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。 javac
仕様書の書き方って，習いました？ - 日経エレクトロニクス - Tech-On!
突然ですが，読者諸兄姉は，仕様書の書き方って，教わったことはおありでしょうか。あるいは，部下に教えたことはおありでしょうか。 日経エレクトロニクス 2007年2月12日号のGuest Paper（pp. 133-152）では，「仕様書の記述力を鍛える」と題して，フェリカネットワークスのソフトウエア・エンジニアの栗田太郎氏に，「形式仕様記述」という手法を使ったプロジェクトの体験記を執筆していただきました。 同社は「おサイフケータイ」などとして知られる携帯電話機向けの「モバイルFeliCa」の開発元で，そのICチップのファームウエア開発に当たって，「仕様をキッチリ書けるところは，書こう。実装者任せにしないようにしよう」という意識を徹底，高品質なソフトウエアの開発に成功しました。成果物は，NTTドコモの携帯電話機「903iシリーズ」の全機種に採用されるなど出荷数も多く，責任の重いプロジェクトです
開発組織のDNA（2）: 柴田 芳樹 (Yoshiki Shibata)
以前、「開発組織のDNA」を書きました。ソフトウェア開発は、生物ではないのですから、DNAは存在するのではなく、形成されていくものだと思います。しかし、一度形成されると世代間に遺伝していくのかもしれません。 ハーラン・ミルズが述べているように、「企業自体の生産性にも10倍の開きがある」というは、様々なソフトウェア開発組織で働いて経験からして、当たっていると思います。しかし、一つの組織の中で長年属していると、その開発組織のDNAに染まっていき、客観的に自分達の生産性を知ることはできなくなってしまうのではないかと思います。つまり、自分たちが行っているソフトウェア開発のやり方に疑問を持たなくなってしまいます。 そのDNAを変えるには、外の世界を知る必要があります。そのための手段の一つが、書籍を通した学習と学んだことの実践です。実際にやってみて良いと思われることはどんどん取り入れていくということで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://twitter.com/saltheads/statuses/21750645131