はてなブックマーク

ソフトウェアレビューにはいくつかタイプがあり、十分に時間をかけて取り組むことができ、レビューで問題を見逃すことは許容されないものが一つ。時間が限られていてレビューで全ての問題を検出することが前提とはされていないタイプがもう一つです。現実には、時間は限られているのに問題を見逃すことが許容されていないという厳しい組み合わせが多いように思います。しかし、よくよく精査すると後者の時間の制約が厳しいものの全ての問題を検出することは求められていないものもあるでしょう。 この時間が限られていて問題を効率よく見つけることが前提となっているレビューでも見逃すと困る問題があります。それは見逃すと大きな手戻りにつながるものです。性能問題をはじめとして「レビューで検出しておいてよかった」という問題にいくつか心当たりがないでしょうか。振り返ってみると「このタイプを重点的にみつけていた」というものもあると思います。で

Agile Japan 2015のパネルディスカッション「日本企業としてアジャイルに期待すべきこと、やらなければならないことは何か？」で印象に残ったこと 2015/4/16に開催されたAgile Japan 2015で「日本企業としてアジャイルに期待すべきこと、やらなければならないことは何か？」というパネルディスカッションのモデレータを拝命しました。パネリストは横塚 裕志氏（東京海上日動システムズ）、宮田 一雄氏（富士通システムズ・ウエスト） 、誉田 直美氏（日本電気）です。 横塚氏が東京海上日動システムズ前社長、宮田氏が富士通システムズ・ウエスト社長、誉田氏が日本電気ソフトウェア生産革新本部 主席品質保証主幹という顔ぶれで私でモデレータが務まるのか心配でしたが、内容は非常に興味深く、評判もよかったそうです。参加できなかった方にも共有できるようパネリスト、実行委員のご協力のもと、「日本企業

2015/2/19にDevelopers Summit 2015（デブサミ）のセッションで対談をする機会をいただきました。私は聞き手となり、機械学習、人工知能のエキスパートであるIBM東京基礎研究所の渡辺氏に質問に答えていただきました。 開発の構成要素として人工知能を使おうとするときに疑問に思うことを質問しました。まず、人工知能を大別し、汎用人工知能とタスク特化型の機械学習があること、このセッションでは主にタスク特化型の機械学習を中心に考えることにしました。 最初の質問はタスク特化型の機械学習と通常のプログラムの違いはどこにあるかでした。次のように回答いただきました。通常のプログラムは事前にロジックを決めて実装しておきます。プログラムを実行する際には、何らかの入力に対してあらかじめ決まっているロジックによって出力が得られます。機械学習では学習のフェーズがあり、そのフェーズで学習データを与え

このエントリを書こうと思ったのは二つの記事を読んだことがきっかけです。一つはGoogle VenturesのDaniel Burka氏の"Don't let team politics get in the way of shipping great design"（安藤幸央氏の翻訳から知りました）です。この記事は要素技術に長けていても他のチームメンバがプロダクトにそれを活かしてくれるとは限らないという段落からはじまります。Burka氏はWebを通じて提供されるサービスのユーザインタフェースのデザインを手がけているようで、要素技術としてPhotoshopの使い方や色に関する理論やキャッチコピーが挙げられています。Burka氏の記事の残りの部分では、チームの他のメンバの考えを知ろうとすることや他のメンバに信頼されるよう自分の主張の裏付けを持っておくことを勧めています。 この話はデザイナに限定

2010年くらいからライトウェイトなコードレビューをその他のレビューと区別してモダンコードレビュー(modern code review)と呼ぶことが増えています。コードレビューのツールを使い、対面での会議を実施せずに完了できることや欠陥の検出だけでなく情報共有も対象になっている点が異なっているようです。 モダンコードレビューの明確な定義やコンセンサスのとれた定義はまだありません。書籍Making Softwareの18章の章タイトルにもModern Code Reviewが使われ、言及されています。Making Softwareの日本語版は2011年、英語版(原典)は2010年に出版されています。18章をご覧になるとわかりますが、レビュー一般に関する言及、レビュー会議を実施する効果に関する言及があります。 2013年にInternational Conference on Softwar

ソフトウェアテストのドキュメントはテストの実施後に完成する実施報告書とテスト実施前に実施計画やどういうテストケースを実施するかを記載するドキュメントに大別できます。ここでのドキュメントはきっちりとした書式に埋めていくものもホワイトボードに書いた内容やメモ書き程度のものも両方含みます。テストツールへのインプットやテストコード自体はテスト実施前のドキュメントに該当し、実行結果が実施報告書に含まれるでしょう。 テストの実施計画やどういうテストを実施すべきかといった準備はプログラムが動作する前に開始することができます。規模の大きなソフトウェア開発であれば、個別のドキュメントとして残すこともありますが、仕様書に付記されたり設計書の一部に含まれていたりすることもあります。たとえば、仕様を確定する段階で、個々の仕様に対してどういうテストケースによってその仕様を満たせたと言えるかといった対応付けをすること

過去のバージョンのソフトウェア（母体、流用元、コア資産と呼ばれることもあると思います）をもとに拡張、変更をして次のバージョンのソフトウェアを開発することを保守開発(software maintenance)、ソフトウェア進化(software evolution)と呼んでいます。同一の過去バージョンをもとに、類似のソフトウェア、サービス、製品を同時に開発する場合には、派生開発と呼ぶこともあります。多数のバリエーションがある機器の組込みソフトウェアを想定いただくと派生開発がイメージしやすいと思います。 こういった過去のバージョンをもとに次のバージョンを開発するときの課題の一つは、過去のバージョンとの整合性を保ちながら新しいバージョンでの拡張、変更を実施することです。こうした開発では、拡張、変更した部分が期待通り動くだけでなく、過去のバージョンで提供されていたものも期待通り動くことが前提となっ

レビューで同じような情けないミスをしてしまい、恥ずかしくてミスの指摘や改善方法がしっかり聞きとれず、言い訳し続けたり謝り続けたりするという経験は誰にでもあると思います。指摘側になると同じ単純ミスをたくさん見つけると何度も指摘しているうちに、腹が立ってくるということもあるのではないかと思います。 ミスの程度やレビューにどのような参加者がいるかにもよるので一概には言えませんが、何度か経験すれば「誰にでもあること」とこれらの恥ずかしい思いや腹が立ってくる思いをコントロールできるようになります。客観的な視点に立つきっかけを作るのを習慣づけるのはコントロールできるようになるための一つの方法でしょう。私の場合は「んー。ひどい。これはこれまで見た中で何番目にひどいものだろうか？」と考えるのを習慣づけるようにしています。少し客観的になれたら、自分でミスしているときは「これが自分だ。次から直していこう」と考

本エントリはいつものソフトウェアに関するブログエントリとは少し異なるエントリですが、海外のカンファレンスの中継や動画を字幕や通訳なしで聞きたいと思っている方は少なくないと感じているので紹介することにしました。 ブログに掲載されているエントリや一部の記事はテキスト、音声の両方が用意されています。テキストも音声も内容は同一で音声を再生すると、ブログや記事はどこを発音しているかがハイライトされたテキストでわかります。全てを調べていませんが音声は肉声ではないものがほとんどだと思います。（肉声の音声を何らかの方法でトラッキングして表示しているように解釈できる表現になっていることを指摘いただき追記しました） その様子は下の画像のような感じです。表示しているブログエントリは"The Web is eating software"で、今読んでいる文が緑色、読んでいる単語が水色で表示されます。画像ではちょう

一見同じようにみえるソフトウェア開発も個々に異なっているものがほとんどでまったく同じものはなかなかないという実感をお持ちの方も多いと思います。個々に異なれば同じ方法で開発すれば期待する効果をいつも得られるというわけにはいきません。同じ方法が通用するかどうかを考えた上で方法を活用することが大切であると考えています。また、そのことがうまく伝わるためにはどのように表現すればよいかを考えています。個々に違っていることを「文脈」の意味をあらわす「コンテキスト」と呼んでいます。個々の違いを考えることの大切さを理解してもらうのに少しは寄与したのではないかと思っています。 本エントリのタイトルの「杓子定規」もうまく伝えるための表現の一つだと思っています。「杓子定規に考えず適したやり方になっているか吟味する」は何をすべきかをイメージしやすいのではないでしょうか。SDN(Software Defined Ne

去年の記事でOracleがJavaのStringの実装（内部的な実装）を変更したことを伝えているものをよみました。変更の理由は、以前の実装がメモリリークの原因となり得るもので、新しい実装はそれを防いでいるそうです。変更により実行時間が増えるそうです。 http://www.infoq.com/news/2013/12/Oracle-Tunes-Java-String http://java-performance.info/changes-to-string-java-1-7-0_06/ R42日記のこちらの記事をはじめとして、和訳や日本語で説明されているものもあります。 redditのフォーラムでStringの実装を担当する開発と思われる人からの投稿に300件を超えるコメントが寄せられており、インパクトが大きい変更で様々な議論が起こっていることが伺えます。 変更の詳細は上述Webを読んで

ソフトウェア開発のコンテキストとは、ソフトウェア開発の置かれた状況や背景を指します。コンテキストを明確にすることにより、あるソフトウェア開発において効果が得られたことが自身の開発ではうまくいくかもしれない、あるいは、うまくいかないかもしれないといった判断を助けます。他の開発で効果のあった技術、プロセス、プラクティス、手法を取り入れたときに、コンテキストが異なっているために同じような効果が得られないということはよくあります。 講演、セミナー、勉強会でソフトウェア開発の成功事例が公開されるようになって、「お、いいな」と思うような技術、プロセス、プラクティス、手法を見聞きする機会が増えました。しかしながら、見聞きした事例の前提や制約を把握して、自身の開発でも適用可能かどうかを判断しないと期待する効果が出ないことがあります。そういった前提や制約をコンテキストと呼んでいます。たとえば、些細なバグであ

今年9月にドキュメントレビューの詳細な手順とマインドを記載した書籍「間違いだらけの設計レビュー」を上梓しました。amazonでの1時間おきのランキングを1日1回送信してくれるサービスを使ってみているとこの1ヶ月半くらいは200～1500位の間を行き来しているようで、好評いただいているのではないかと思います。 内容はレビューの課題に関する約700件のアンケート、検出された欠陥、実験データ、レビュー会議の様子を録画したビデオ等、研究を進める上で分析した内容と私のエンジニア時代に感じていたことをもとに、お勧めの手順、気をつけるべき点を読みやすく書いています。手順の中には試行を通じてその効果を確かめたものも含まれます。初心者～中堅を想定して書いていますが、ベテラン向けの注意点もいくつか書いています。ぜひ、書店でお手にとってみてください。 目次はこちら（http://coin.nikkeibp.co

マツダは1980年代からモデルベースでの開発に取り組んでいるそうです。モデルベースの開発の対象はソフトウェアだけでなく、エンジンやトランスミッションを含むハードウェアです。様々なパラメータをシミュレーションによって組合せ、最適な設計を机上で得て、机上で検証することができるようになり、試作や調整の時間や手間を減らせます。 マツダでの最初のモデルベース開発は1980年代のRX7の加速時の振動を抑える点火アクティブ制御だったそうです。その後、1991年のル・マン24時間耐久レースに使ったそうです。1991年の同レースでマツダは優勝しています。最近では、エンジンでの燃焼をシミュレーションすることにより、これまでにない高圧縮比のエンジンの実用化を支援しています。 モデルベースの開発を主導する原田氏のインタビュー記事（択一の世界を変えた! 「SKYACTIV TECHNOLOGY」を支えるマツダのモデ

IEEE Softwareという雑誌でsoftware analyticsという分野に関する特集が組まれています。当初は1号分の特集の予定だったそうですが、2号に分けることとなったそうです。2013年7, 8月号の特集記事のタイトルは以下のとおり。ここに7, 8月号全体の目次があります。 T. Menzies, T. Zimmermann: Software Analytics: So What? R. Musson, J. Richards, D. Fisher, C. Bird, B. Bussone, S. Ganguly: Leveraging the Crowd: How 48,000 Users Helped Improve Lync Performance O. Baysal, R. Holmes, M. W. Godfrey: Developer Dashboards: T

2008年に"Assessing the value of coding standards: An empirical study"というタイトルの論文がIEEE International Conference on Software Maintenance 2008に掲載されています。 論文のPDFはIEEEの電子図書館のページから入手できますが定期購読していたり、IEEE memberのアカウントが必要になります。本論文と同等の内容のテクニカルレポートが著者のサイトからも閲覧できます（こちら）。 MISRA Cで定義されているコーディング規約の逸脱と不具合数との関連の調査結果を報告しています。対象ソースコードは家電製品用の組込みプログラムのもの。開発中に構成管理システムに蓄積されたソースコード編集履歴からコーディング規約準拠と不具合数の関係を調べて報告しています。 MISRA Cは

Cisco SystemsのCustomer Experience Reportの記事が興味深かったので紹介します。「Consumers Desire More Automated Automobiles, According to Cisco Study」です。全般的に自動車の購買と技術との関係を調査しているのですが、その中に自動車の自動運転に関する調査結果が（最後あたりに）報告されています。 「自動車の自動運転を信頼しますか？」という質問に対して全体として57%の回答者が信頼するという回答をしたそうです。国別の回答の割合も報告されていて、ブラジルが95%、インド86%、中国70%、・・・と続き、ドイツ37%、日本28%で日本が最下位です。米国は60%だそうです。 約1500人に対する調査で、それぞれの国がどのくらいの人数の調査で、どういう方法で調査したかを見つけることはできませんでした

2013/3/12に「業務観点でのレビューを目指した不具合情報の分析」というタイトルで情報処理学会ソフトウェア工学研究会で発表しました。論文PDFはこちら。（本著作物の著作権は情報処理学会に帰属します。本著作物は著作権者である情報処理学会の許可のもとに掲載するものです。ご利用に当たっては「著作権法」ならびに「情報処理学会倫理綱領」に従うことをお願いいたします。） レビューのコスト削減効果は、レビューで検出して欠陥を修正したときのコストとレビューで見逃して（あるいはレビューを実施せず）レビュー以降のフェーズで欠陥を検出し、修正したときのコストの差です。@IT情報システムマネジメントの記事「レビューを「数」だけで管理しているからコストが膨らむ」で解説しています。 レビューで検出することによってコスト削減につながる欠陥をつきつめると、どのようなものになるでしょうか。おそらく対象ソフトウェアにとっ

2013/3/8（金）に第7回要求シンポジウムに参加しました。要求シンポジウムの詳細はこちらから。4つの講演から構成されています。私は業務の関係で後半2つの講演しか参加できませんでした。後半2つのセッションは、楽天 森氏による「インターネットビジネスにおけるサービス開発: 「要求」のありようと開発方法の実際」、東京海上日動システムズ横塚氏による「俺の要求開発～二つの事例にのせて～」でした。 それぞれ私にとって気づきの大きいセッションでした。私が参加した1つめのセッションの森氏の講演で私の印象に残ったのは以下です。 楽天で海外展開されているサービスの中で、日本だけが特殊なものや海外のある国で特殊なものを紹介なさっていました。たとえば、中国向けのオンラインショッピングサイトでの価格交渉用のチャット機能です。こういった機能は文化や習慣を知らないと実現が難しく、そういった背景を把握しておかなければ

変更波及解析は既存のソフトウェアに変更を加えたら、どの場所に影響を与えるかを調べる方法です。影響は本来の意図であるものや本来意図していない副作用も含みます。変更波及解析が不十分だとデグレードする場合があります。 Steffen Lehnert氏のA Review of Software Change Impact Analysisという文献調査をしたテクニカルレポートがここで公開されています。調査対象の文献が182件ある大きめの調査です。網羅性や調査方法に関しても客観的な基準を与え、洗練した上で論文として公開されるのかもしれません。 このテクニカルレポートで紹介されている影響波及解析のカテゴリの一覧は以下のとおりです。10カテゴリのうち9番目は組合せ、10番目は「その他」なので、実質的には8カテゴリあります。どのくらいのカテゴリをご存知ですか？ いずれも完璧とはいかないまでも、変更波及解析

大学教員の業務は、大きく教育、研究、運営、社会貢献に分類されています。本ブログのエントリは、ほとんどが研究に関わる内容ですが、今回は教育に関するものを紹介してみたいと思います。 私が担当している演習でスマートフォンアプリケーションを開発しました。開発は2段階にわかれていて、最初は指定されたスペックのもの、その後、「利用者数を増やすことを目的とした機能を考えて実装してほしい」という要求に合わせてチームで考えて機能追加します。 日本IBMに協力いただいて、Worklightというスマートフォンアプリケーション開発のためのフレームワークを使いました。日本IBMの米持氏、大澤氏にご協力いただき座学で講義いただきました。また、RTCという構成管理や課題管理をはじめとする統合型の開発支援環境を活用し、分散非同期型の開発に挑戦しました。学生は3人または4人で1チームとし、そこに米持氏、大澤氏にも加わって

いつものブログエントリとは少し内容が異なりますが、マインドセットや価値観に関してここ最近で印象に残った話があるので紹介します。 一つはScrum Alliance Regional Gathering Tokyo 2013でのJurgen Appelo氏の基調講演「Agile Management ? Learning From Software Development」で聞いた内容。 誰かを雇うときは、スキルセットよりもマインドセットを優先すべきだ。組織文化と組織の構成員の価値観のズレを修正するのは難しい。社員が仕事を楽しめていないときには、会社は、その社員にとってより良い場所を紹介することも考えなければならない。 講演ではそのような20年間仕事を楽しめていないまま住宅ローンを支払うためにだけ働いている人物をどう助けるか？という問いかけがありました。 もう一つはダイヤモンドオンラインの記

ソフトウェア品質シンポジウム2013の企画を実行委員として推進しています。委員会ではシンポジウムによりよい論文・発表を投稿していただくにはどうしたらよいかという議論をよくしています。シンポジウムのメインコンテンツは投稿論文や発表のセッションであることは委員会で合意しています。委員会は多彩な顔ぶれで発表のメリットを知る方も多くいらっしゃいます。委員一覧はこちら。 聴講するメリットは誰にもわかりやすく「他社事例を聞ける」くらいで十分説明できます。発表するメリットは、発表の経験がない方にスッと理解いただくための説明が難しく苦労しています。私自身も研究者として自身が考えたことを発表しています。私が感じるメリットは、発表のための準備の過程において自身の考えを改めて整理できること、発表後の質疑において今まで気づいていなかったような点でフィードバックがもらえる場合があることです。質疑は発表セッションの中

プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからはじめる、多くのユーザが使う基本機能の正常動作からはじめる、依存関係が多く様々な部分から参照される共通モジュールからはじめる、今後も長期にわたって保守、拡張する部分からはじめるといった方針が考えられます。もちろん、できた部分から順番にという順位付けもあるでしょう。 優先順位のつけ方の一つとして、ソースコードの特徴から不具合がありそうなクラス、モジュール、メソッド、関数を予測する技法としてFault-proneモジュール予測という技法があります。過去の不具合のデータとソースコードの特徴を表わす数値をモデルに与え、不具合が起こりやすいソースコードの特徴を学習させます。数値は関数、メソッド、クラスとい

「ビジネスとITが一体化している」「ビジネスとITの密接な連携」とよく聞くようになりましたが、具体例が挙げられていることはそれほど多くないと思います。東京海上日動システムズ横塚氏、リクルートテクノロジーズ米谷氏、Publickey 新野氏によるトークセッションの内容がその具体例を示していると思いましたので本エントリで紹介します。あわせて、その状況に対応するための開発体制、手順をお話されていて興味深く感じました。現実に即した裏付けのある工夫で説得力があります。 2012/10/30にIBM Innovate2012のスペシャル・トーク・セッションとして実施された。ユーザ登録すればここから動画を視聴できます（画面左側の再生ボタンのアイコンが表示されている画像をクリックします）。当日私は会場に行けなかったので動画で拝見して本エントリを書きました。 横塚氏は社長、米谷氏は執行役員でありCTOで、ビ

講演や発表での事例、エンジニアコミュニティでの事例や雑談、ブログ、tweet, facebookを見聞きしていると、ソフトウェア開発の目的やソフトウェアの品質向上活動をいくつかのレベルに分けられるのではないかと感じていました。 講演の機会をいただいたので、これまでの私の考えを少し整理して、以下のとおり4+1レベルに分けました。タイトルとアブストを考えた時点では3レベルとしていたのですが、4+1が説明がしやすいと思い、変更しました。セッションの主旨がソフトウェア品質に関するものなので、品質向上活動としていますが、ソフトウェア開発の目的と考えることもできます。 レベル1: 開発関係者が各々の考えで品質向上活動を実施している 開発中のソフトウェアに求められる品質を共有できておらず各々の考えで取り組んでいる状態。使い勝手が最優先と考えて、ユーザビリティの向上に時間を使っているメンバもいれば、保守性

スバルの運転支援システムEyeSightは自動車に搭載した2つのカメラからの画像にある物体を認識し、一定の速度以下で走行している際にはブレーキをかけて衝突を回避します。研究段階を含めると開発に20年かかったそうです。 以前に本ブログでも紹介しましたが、最初は自動車に2つのカメラを取り付けて、植え込みに向かって走って物体を認識できるかどうかというところからはじまったそうです。実用化に向けて様々な光の当たり方、気候条件、路面の条件を試したそうです。特定の条件で期待通り動かないことがあったり、サプライヤの変更が必要になったり、初期バージョンはなかなか売れなかったりとたくさんの困難が伴ったそうです。 規模や種類が全く異なるのですが、私がエンジニア時代にはじめて作ったサービスも新しいことが多く、想像以上に基本的、雑多なところから始めなければなりませんでした。EyeSightの開発はおそらくそれとは比