電子産業などの収益構造を表す言葉の１つで，製品の組み立て・製造工程の利益率が低いことを表現しようとする場合に良く利用される。例えば，製品企画やその製品の構成要素である部品の開発・製造，あるいは製品を製造した後のサービスなどによる付加価値が大きく，機器の組み立てなどの製造工程では大きな価値は加わらないと仮定する。この場合，横軸に製品開発から販売/サービスに至る工程，縦軸に付加価値をとって図示すると，両側が持ち上がった曲線を描く。人が笑ったときの口のような形なので，「スマイル・カーブ」と呼ばれる（図１）。 スマイル・カーブは，台湾エイサー社の創始者であるスタン・シー会長がパソコンの各製造過程での付加価値の特徴を述べたのが始まりとされている。図２は，シー会長の作成した図に基づいて日経エレクトロニクスが1996年4月8日号に掲載した図である。 図1　製造の付加価値は低い （日経エレクトロニクス20

「カレーなる辛口Javaな転職日記」に@ITの記事の批判があり、その中に見積りに関するものがあった。 この書き方だとカンで見積もる方式よりも、より高い精度で予測できる工学的手法が存在するかのように見える。しかし、現実には未だに「精緻に見積もる工学的手法」などというものは実用化されていない。また近い将来においても実用化される可能性もまずない。 見積り精度を向上させようとすることは、ソフトウェア開発においては、本質的な矛盾を抱えている。見積り精度を向上させるには、「同じものを同じやり方で作った、精度の高い多くのデータ」が必要になる。だが、「ソフトウェア開発はハードウェアにおける設計」であるから、まともな技術者、まともな組織なら、同じものを開発したりはしない。「同じものを同じやり方で作った、精度の高い多くのデータ」が得られない以上、見積り精度の向上は本質的に無理がある。 完全に同じではない類似度

上流で品質を作り込むことを狙い，設計レビューを強化する現場が増えている。しかし，長時間に及ぶレビューは現場の負荷を高め，メンバーを疲弊させる。それだけの労力を投じても，重大な設計ミスが必ずしも減らないのが現実だ。3人のITエンジニアが座談会でその実態を語った。（聞き手は中山 秀夫＝日経SYSTEMS） 情報システムの信頼性に対する要求が厳しくなるなか，品質管理を強化し「設計ミス」をなくそうとする動きがあるようです。みなさんの現場では，いかがでしょうか？ Aさん：私は製造業のシステム部門に勤めています。設計の品質向上は，大きな課題になっていますね。テストでバグをつぶすのではなくて，もっと上流できっちり品質を作り込んでいこうという方針です。最近はレビューの強化に取り組んでいます。レビューの回数を増やしたのに加えて，設計レビューで有識者を必ず入れるルールになりました。 有識者は具体的にはどんな人

［App Inventor in Action – YouTube］ このビデオは必見だ・・・ Android のプログラミングがこんなに簡単にできるのなら、これはスゴいことだ。 Technologizer: “Android Gets a Build-Your-Own-App App” by Harry McCracken: 11 July 2010 ＊　　　　　＊　　　　　＊ App Inventor 登場 スマートフォンアプリがどんなものか知っているだろうか？ Android フォンを持っているひとなら、「App Inventor for Android」を使えば簡単にアプリが自作できる。App Inventor は Google Labs の新しいソフト（Windows、OS X および Linux  用）で、Android のプログラムがまるでブロックをつないでいくように簡単に作

Androidのアプリケーションを作って 最終的にはAndroidマーケットで公開する この連載ではAndroidのアプリケーション開発を実際に行いながら、最終的には制作したアプリケーション（世界時計を予定）を「Androidマーケット」に登録するまでの手順を解説していきます。 前提条件として、Javaのプログラミングが可能な方を想定していますが、基本的なプログラミング経験があれば、Javaの勉強中という方でも読めるように配慮する予定です。筆者もJavaを日常的に使うことはなく、Javaについて言えば、初心者も同然ですが、それでもアプリケーションを作ることはできました。なので、Javaのプログラミングに関しては、それほど高いものは要求しないつもりです。また、開発にはWindows 7上のEclipseで行なうことを前提としています。筆者は64bit版のWindows 7を利用していますが6

2010年4月17日に開催された「Android Developers Forum in Tokyo」（主催 日経BP社 ITpro、Android Application Award事務局、日経BPセミナー事業センター、特別協賛 NTTドコモ、特別協力 ソニー・エリクソン・モバイルコミュニケーションズ、日本Androidの会、関連記事）では、Androidの開発現場にいる開発者らによるライトニングトークス（LT）が催された。制限時間5分を過ぎるとドラが鳴り強制終了、というルールによるプレゼンテーション大会である。 日本Androidの会女子部長 矢野りん氏のLTタイトルは「Flashさんいらっしゃーい」。 Web開発の世界ではFlashはかなりの規模の開発者コミュニティを築いており、ActionScriptライブラリの蓄積なども進んでいる。開発元の米Adobe Systemsでも、現在の

「仕様書」は，設計者とプログラマをつなぐ重要なコミュニケーション・ツールだ。それゆえ，安易な書き方をすると問題を起こす。よく議論されるのは，「仕様書の内容はどこまで詳しく書くのが適当か？」という点だろう。過剰品質を避け，効率的に書きたいところだが，きちんと意図が伝わることが大前提である。二つの実例を通して，そのキー・ポイントを紹介する。 今回から，題材を「仕様書」に移して設計書作成の心得を紹介していこう。 前回までは，ユーザーからの要望聴取を基に作成する基本設計書を題材として，設計者とユーザーとのコミュニケーションを軸に展開してきた。これに対し，今回から取り上げる「仕様書」は，基本設計書を基にシステムを実装するプログラマやSEに対して，より具体的なシステムの詳細を伝える設計書である（図1）。 このような設計書は「詳細設計書」や「プログラム仕様書」など，様々な名前で呼ばれていることと思う。ま

優れたプログラマはコードを書くのと同じくらい、コードを読みこなせなくてはならない。優れたコードを読むことで、自身のスキルも上達するのだ（編集部） Ruby on Rails（Rails）には、scaffoldという大変便利な機能が付いています。scaffoldを使えば、アプリケーションの実行に必要なデータベースのスキーマの準備から、データベースにアクセスするコード、画面周りのコードまで、一通り自動生成してくれます。 そのおかげもあって、多くの開発者がscaffoldを使ったRailsのアプリケーションを試しに作ったことでしょう。ただし、scaffoldはあくまで土台であって、その後は、生成されたコードを拡張していく必要があります。 本連載ではコードリーディングという形で、オープンソースとして公開されているRailsアプリケーションのソースコードを題材に使って、その動きや機能がどのように実装

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman 作者: David H. Hoover出版社/メーカー: Oreilly & Associates Inc発売日: 2009/10/21メディア: ペーパーバック 本書の「ソフトウェア職人気質とは」（What Is Software Craftsmanship?、p.3）からの引用です。 私達は、プロセス中心ではなく、スキル中心です。私達にとって、「正しい」プロセスを使用するよりは、高いスキルを持つことが重要です。Gawande は、次のように質問しています。「医学は、技能、それとも工業ですか。医学が技能であれば、職人の技を修得するために産科医を教育することに焦点を当てます。新たな技法を見つけるために研究をします。物事を誰が行っても常に上手くいくとは限

■アプリを「作る」ことは価値を生まない 日本の生産性は悪化の一途をたどりOECD加盟30カ国中第20位まで落ち込んだ。その原因の一つはナレッジワーカーの業務非効率にある。優秀な社員が手間をかけて素晴らしい業務をしているが、それは本来手間をかけるべきではない非戦略領域である事が多い。ITの面でそれが如実に現れているのが乱立するアプリケーションである。 例えば、ある大手企業Ａ社の例を見てみよう。 大手企業Ａ社は10年前からNotesを利用し始めた。現場のニーズに合わせたアプリを容易に作ることができるためEUCが進展、現場発で次々とアプリが作られ、最終的にDB数が2,000DB近くまで達した。 10年間でIT化は大きく進んだが、その反面DB数の多さがメンテ・サポートコストに跳ね返ってきた。また、バージョンアップや移行をしようとしても、DB数が多すぎて身動きがとれなくなった。ユーザーからみてもイン

Anker's 3-in-1 MagSafe foldable charging station drops back down to its Prime Day price

先日リリースして以来、多くの皆さんに好評をいただいている Google 音声検索ですが、開発者の方の中には、この認識エンジンを使っていろいろなアイディアを実現したい、と思われた方もいらっしゃるのではないでしょうか。 実は、Google 音声検索の認識エンジンを使った Android アプリケーションは、どなたでも開発できるようになっています。Recognizer Intent API （サンプルコード）を使えば、さまざまなサービスに音声認識を組み合わせることができます。例えば、天気予報のアプリで場所の設定を声でできるようにしたり、乗換案内のアプリで駅名を音声入力できるようにするなど、さまざまな可能性があります。 なお、Google 音声検索の認識エンジンは、検索キーワードの認識に特化しているため、複数のキーワードを認識するのに適しています。逆に、会話の聞き取りなどには適していません。このよ

日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問　日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海

いかにレビューが有益なものであろうと、また、実践のための合理的な準備・計画があろうと、それだけでは効果は望めない。レビューにかかわる全関係者にその有用性を理解してもらうことが、成功の前提条件となる。 あなたの組織では、レビューが軽んじられていませんか？ 第1回『“確実な記録”こそが、品質・コストに貢献する 』では、「レビューには目的意識が大切」といったことを述べましたが、何事も「目的」を実現するためには「計画」が必要です。特に、一見“自由度が高い”レビューにおいては、綿密な計画を立てることが非常に重要な意味を持ちます。 ただ、「計画」といっても、堅苦しい文書を作るわけではありません。具体的には、「どのようなレビューをするか」「レビューの開始と終了の条件」などを明確化するとともに、「レビューを行うことによる、開発メンバーにとってのメリット」「早期にミスや問題を発見することによるリスク低減効果

“形だけ”になりがちなソフトウェアレビュー 近年、ソフトウェアレビューに対する認知はますます向上しつつあります。例えば商用開発なら、「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが実施されていますし、オープンソースソフトウェアのプロジェクトなら、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 その背景として挙げられるのは、ビジネスや社会におけるITの重要性が高まっていることでしょう。われわれの日常にこれだけITが浸透しているいま、ソフトウェアの品質は、システムの運用に大きな影響を及ぼします。その品質が低下すれば、ビジネスなら機会損失や収益悪化、社会的信用の失墜につながりますし、社会インフラなら公共交通機関などのサービスがストップすることも起こり得ます。ソフトウェアレビューの認知度が向上してい

新米と秋刀魚のわた焼き お刺身用の秋刀魚を買いました。1尾250円です 3枚におろして、秋刀魚のわたに酒、味醂、醤油で調味して1時間ほど漬け込み、グリルで焼きました 秋刀魚のわた焼き わたの、苦味が程よくマイルドに調味され、クセになる味わいです 艶やかな新米と一緒に 自家製お漬物 土…