売り上げランキング: 10911
つまらなくはないけど普通かも。
大ヒットした原作の割にはイマイチに感じたからおそらく原作の面白さを伝えきれてないんだろうなと予想します。
つまらなくはないけど普通かも。
大ヒットした原作の割にはイマイチに感じたからおそらく原作の面白さを伝えきれてないんだろうなと予想します。
あまり話題にもならなかった気がするし、そこそこな映画かなと思っていたのですがかなり楽しめました。実際のANAの現場があんなにドタバタしているのかは分かりませんが、色々な人が協力しあって飛行機をスケジュール通りに飛ばすのは大変なんだなと裏側を見せられて感じました。
見ていると飛行機に乗って旅に行きたくなる気分になります。おすすめです。
「業務が組み込みメインでもそろそろ並行処理も避けて通れないよね」という雰囲気を年初から職場で醸し出し、勉強会を開くことにこぎつけました。内容は並行コンピューティング技法 ―実践マルチコア/マルチスレッドプログラミングの輪講です、The Art of Concurrencyの邦訳ですね。
「職場の1人ができてもしょうがなくて、みんなの基礎がある程度揃ってないと話もかみ合わなくなるだろう」という思いが勉強会を選んだ理由の1つ。もう1つの理由は「勉強会ならサボらず最後まで読まざるをえないよね」という自分へのハッパがあります。今は他にも実用Gitを読んでいて、実は昨年の夏からレガシーコード改善ガイド (Object Oriented SELECTION)
を積読にしたままです。3冊平行に読むのが良いとは思えませんが、読んだ記録をそれぞれつけて行こうと思います。
前置きが長くなりましたが、まずは第1章「速くしたい人、手を挙げて!」です。
◯並列と並行の違い
・並行:複数の動作を同時に実行状態に保てる機能を備えていること。
・並列:複数の動作を同時に実行できること。
スレッドライブラリを使ってマルチスレッドプログラミングを実装し、シングルコア(Pentiumとか)でプログラムを実行した→並行処理
スレッドを使ったプログラムをCore i7で実行した→並列処理
ということですね。並列処理は並行処理に完全に包含される関係があります。
◯効率的な並行アルゴリズム
コア数に応じて処理時間が短くなる(2コアで1/2、4コアで1/4) が理想だけど、処理の一部は逐次処理が不可避な場合がほとんどで理想的な性能を得られることは殆どない。
特定のコア数を念頭においたアルゴリズムではなく、今後新しく発売されるCPU(16コアとか、32コアとか…)に応じて望ましい性能がそのまま発揮出来るように実装するのが目標。
◯スレッド化のステップ
通常の開発が1.仕様定義、2.設計、3.実装、4.テスト、5.チューニング、6.保守の流れを取るのに対し、スレッド化のステップは以下をとる。
逐次処理のソースで動く実装を固めるのが第1、いきなり並行処理アルゴリズムを実装すると元々の問題か、平行化に起因する問題か切り分けが必要になる。
◯歴史的な話
古くは複数の機器を組み合わせて処理を平行化する分散メモリプログラミングが主流だった。最近はCPUのマルチコア化が進んでいるので共有メモリプログラミングに移っている(本にはこんな記述無いんだけど理解があってるかな?)。
◯これから学んでいくこと

Subversion, Git, Redmine, Hudson – 今考えている連携 » tune webでいただいたコメント、実際にやってみて出来なかったことを反映してアップデートしてみました。
前回からの差分がいくつかあります。
gitとSubversionの橋渡しにかなり悩んだのですが、実用Gitによると、窓口を1つにして、いくらか気をつけなければならない点があるそうです。これはまた別のエントリで。
上記構成が出来そうな目処はついてきたんですが、余力があればgerrit、Overview — Sphinx v0.6.4 documentation、TestLinkをうまく組み合わせたいですね。
◯2010年3月3日追記
離れた箇所にリポジトリをコピーするのにはgit bundleは便利だけど、差分を渡し続けるのは無理がある気がしてきた。
masterを両者で同期を取るとなると、git bundleで貰う側はローカルのmasterにpushしちゃうとbundleからpullするのが面倒になる。ローカルでmasterにコミットするなというのは結構な制限を課している気がする。branchを切って、branchを同期するようにすると、branchからcherry-pickするような運用になるのだろうか? じっくり同期を取れる気がするけど、そこまでして同期をとらなきゃいけないものでは無い気がする。
そこまでしてリポジトリの同期を取るよりも、素直にパッチを送り合う方がいい気がしてきた。リポジトリ構成さえあっていれば最初のbundle送付すらいらないかも。
前にコメントをくれたmootohさんも、よくよく読んでみると「bundleを最初に送付して、あとはパッチを”送り合ってる”」てなってるし。
何か思い違いをしているかもしれません。おかしな点に気づかれた方は遠慮なくツッコミください。

これからが本番、検索エンジンから来た方は先にSubversion, Git, Redmine, Hudson – 現状の連携 » tune webを読むことをおすすめします。上記が週末考えていた「こういう連携なら今の問題点を解消できるかな」と思えるフローです。「こうしたほうがいいよ」とかコメントありましたらお待ちしています。
1番のポイントはバージョン管理システムとしてGitを中心に据えました。社内はSubversionで統一するという規則があるので残すとして、開発チーム内ではgit svnを使ってGit化し、Subversionを直接触らないようにします。協力会社はSubversion縛りが無いのでGitで統一してもらいます。これまでは差分ファイルを送り合っていましたが、Gitを使えばパッチをうまく作り、修正単位でパッチファイルをやり取りすることが出来るでしょう。これまでは複数の修正がまとめて送られてきてましたが、パッチ単位ならレビューもやりやすく、「こうした方がいい」とか「こうして欲しい」というやりとりもやりやすくなります。
リポジトリがプロジェクト専用になるので、フックスクリプトも仕掛けやすくなります。現状は「空メッセージのコミットは禁止」程度の緩めのものですが、コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書きました|SNS構築の手嶋屋を参考にすればRedmineのチケットが無いコミットは禁止できます。これで闇コミットがなくなるはず。
さらにGitを使えば「歴史を書き換えて」テストが通らないコミットをなかった事にも出来るはずです。コミット前にテストをする機能がTeamCityにはありますが、Hudsonにはありません。[#HUDSON-1682] Pre-tested commit feature – Hudson JIRAとして要望が挙げられていますが実現はまだ先になるでしょう。HudsonのGit Pluginのページにpushされた変更をテストして、成功したらmaster/stableにマージする設定手順がありましたが、リリースブランチを持ったときにも同じように出来るかは不明です。
というのをtwitterにつぶやいていたところ、@bleisさんと@masanobuimaiさんから情報をもらえました。Gitのフックスクリプトですが
とすることでいけそうです。Hudsonのジョブ実行結果を知る方法は複数あると@masanobuimaiさんに教えてもらったのがPlugins – hudson – Hudson Wikiのページです。プラグイン無しでもリモートAPIを使っても出来るのかもしれません。
自前でフックスクリプトを用意する必要がありますが、出来ないことはなさそうです。
post-receiveでのテストに多少の時間がかかることを踏まえ、Redmineで参照するリポジトリはGitではなくSubversionにするのが良さそうです。
あとはRedmineのメール経由のチケット登録機能を有効にして、HudsonのナイトリーテストでこけたらカスタマイズしたメールをRedmine指定のアドレスに送ればOKですね。上の絵には「静的解析とメトリクス集計」が入ってますが、これは内製ツールです。リポジトリを集中管理してもらえるとこういうこともやってもらいやすくなりますね。
上記構成に3月中に取り組む予定です。うまく行くといいんだけど。

会社の仕事を「Gitを中心に据えた開発ワークフロー」に変えたいなとこの週末ぼんやりと考えていたんですが、現状を整理して残しておくのも、あとで振り返った時も参考になるかもしれないと思って残しておきます。
開発しているものは画像処理ライブラリで、言語はC言語。プラットフォームはWindowsとLinux両方に対応していて、32bitと64bitどちらでも動くようにしたいのが前提。ほとんどのソースは共用出来るようにしています。開発者はWindowsを使ってVisualStudioで開発し、自動テストやリリース時はLinuxでMakefileを使ってビルドします。
バージョン管理は課で管理しているSubversionを使い、他のプロジェクトともリポジトリを共用しています。他に使っているツールはテスト自動化にHudsonとタスク管理と障害管理でRedmineがあります。Hudsonは2種類のテストを管理していて、コミットの度に動くビルドのテストとCUnitを使った単体テストと、毎晩複数枚の画像入力を処理するストレステストの実行を制御しています。Redmineはチケット駆動開発(TiDD)を意識し、コミットはチケットに関連付けるようにしています。あとは開発者の1人(自分です)がgit svnを使ってローカル開発をgitにしているぐらいです。
開発メンバは社内に2人、あとは社外の協力会社に手伝ってもらっています。両者の間にはネットワーク的に「超えられない壁」があり、リポジトリを参照させることができません。ということで双方でSubversionリポジトリを持ち、同期は定期的(1〜2週間おき)に差分ソースを送り合って手動で実行しています。
ここまでが現状の紹介、以下は上記フローによる問題点です。
問題1 双方でのソースの同期を取るのが大変
一週間から二週間に一度差分ファイルを送り合ってるけど、マージに時間がかかる上、複数の変更がごっちゃになっておくられてくるためレビューしたくても途中で断念してしまう。
問題2 単体テストが通らないコミットが履歴に残り消せない
ちょっとしたミスがあってビルドに失敗してもsvnの履歴が消せない。Windows上での単体テストはコミット前に確認するけどLinuxで毎回やるのが面倒になったり、32bitと64bitを全組み合わせでやるのは面倒だったりする。動くだろうと思ってコミットすると壊れていたりとか。
あとはgccでは警告をエラー扱いしているので、使われてない変数があるとかその程度のことでエラー扱いされてしまう。
問題3 闇コミット
RedmineでTiDDに近いことをしているが、闇コミットが結構ある。スタイル直しただけとか、変数名リファクタリングしたとか。複数プロジェクトでリポジトリを共用してるからチケットIDが無いコミットを弾くのが難しい
問題4 Redmine上でチケットとコミットの関連付けを直せない
テストで問題が見つかってもRedmineのチケットとコミットの関係を直すことが出来ない。間違ってるfixesが残ってしまい、何とも出来ない
問題5 HudsonでビルドにコケてもRedmineのチケットに自動登録されない
Hudsonでコミットごとの単体テストとは別にストレステストを含むナイトリーテストを設定しているが、テストに失敗した時にRedmineのチケットが自動登録されない
問題6 TortoiseSVNのパッチ機能が腐ってる
外注からパッチで差分を送ってもらうことも考えたが、TortoiseSVNの文字コード認識がおかしく、一度エディタで開いて文字コードを保存し直す必要があった。(ちなみにソースはUTF-8)
問題7 機能ブランチの管理が大変。
一度切るとなかなか戻ってこない。戻すにも準備がかなり必要になる。試しに作ったけどいらなかったブランチも扱いに困る。
問題だけ見ると「何でこんなフローにしたんだ」と自分でも思ってしまうけど、少しずつプラクティスを取り入れた結果うまく連携できてない現状になってしまった。近々Subversionのリポジトリを課管理から本部管理に移行するお仕事があるのでこれを機にこれまでの問題点を解消しようと思っています。
詳細は後半で → Subversion, Git, Redmine, Hudson – 今考えている連携 » tune web
本屋で見かけたらどうにも気になってしまい購入して読みました。最初にこの本の存在を知ったのは日本半導体・敗戦から復興へ JBpress(日本ビジネスプレス)だったかな? この本の主張は前半部に固まっており、Webで読むことができるし、Amazonの書評を見ても大体わかるようになってます。
本書だと図やグラフ、実際のデータも使って説明されていますがざっくりまとめると
サラッと読めるので、興味があれば立ち読みしてみることをおすすめします。半導体に限らず他の業種でも同じような現象は少なからず起きているのではないかと。
あとはこの本がお勧めできない理由です。
◯コードの共同所有のやり方
共同所有をすると品質向上、リスクの低減、チームの自己組織化、メンバの安心度につながるが、どうすれば実現出来るのか。
最初は物理的な共有、svnやgitなどのツールの活用がこれに当たります。
次は知識の共有、ペアプロやレビュー、TDDなどの取り組みがこれに当たります。
最後が責任の共有、リファクタリングの実施やCIがこれに当たります。
単にコードを共有しましょうというよりも段階を見せて、効果を説得しないと駄目ですね。社内で使わせていただきます。
◯オフショアで成功するコツ
工程ではなく、機能で委託する。機能単位で責任を持ってもらうことが出来る。
例えばテスト工程だけオフショアに出すと、高い確率でレベルが低い人材が割り当てられる。
アメリカではオフショアをかなりやめているらしい。5割から6割を国内に戻したらしい。結論としては「オフショアはうまく行かない。」という認識が広まっている。(ハーバードビジネスレビューで見たとか?)
オフショアするのは企業が重要視してないところ、テストをオフショアする企業は結局「テストを軽視している」ということ。
あとは人が辞めてしまうので、仕組みにノウハウがたまるようにしないとだめだとNEC誉田さんからコメント。
品質の期待値をきちんと伝えるのも効果があるらしい。
◯オフショア開発におけるテスト改善
事例発表でTISの鈴木三紀夫さんが「890個のテスト観点リストと745個の不具合推測リスト」を作成したと話していた。こんなにたくさんのリストを見きれるのかという疑問がすぐ頭をよぎるが、全部読むことが重要ではなく「作業者に頭を使わせることが大事」とのこと。数が膨大だと作業者がコピペで済ませることができなくなり、担当者なりに頭を使う必要が必ず生じる。
・・・
基調講演と招待講演は大変タメになりましが、その他のセッションは役に立ちそうなものと、役に立たなそうなものと結構はっきり分かれました。
参加費は2日間で8000円ぐらいでしたが、値段的にはこんなものでしょう。学会の延長線上と思えば。
でも来月同じ雅叙園で開かれるデブサミを考えるとデブサミのほうがおすすめかも知れません。
来年は誰か他の人に行ってもらおうかな。
NECの誉田直美さんが、自信が考える品質のあり方について語った90分のメモです。
・・・
誉田さんが考える「王道を行く」とは本質を理解した上で、決意を持ち達成に向けて行動すること。
手段ではなく目的、手抜きではなく効率化、新たな気持も大事だけど先人の知恵に学ぶ。
品質のみを追求している訳ではないが、品質を追求すればコストも納期も改善出来ると誉田さんは考えている。
<事例1>
自社が関連する単体テスト実施状況を調査したところ、単体テストをきちんと実施しているプロジェクト(限界値とか、テストの組み合わせを考慮して普通にやる)は単体テストで手抜きをしている or 単体テストをしていないプロジェクトと比較して出荷後のバグが38%少なかった。きちんとテストを実施すれば62%も取り除けたのに(きちんと単体テストをしても38%も残るのかという見方もできるけど・・・これは私の主観)
<事例2>
オフショアの品質を改善するために、海外子会社をかなりの労力をかけて教育した。具体的には数値目標を立て、プロセス・基礎開発技術・マネジメント・日本語語学力に国内同等レベルを求めた。結果として現地管理職の認識も代わり、改善が進むようになった。(最も、事例としてあげた中国の工場は管理者が転職してしまったらしいんだけど・・・)
<事例3>
開発案件や組織力が似ている組織Aと組織Bからいろいろなデータを取ってみた。Aを100%としたとき、Bの全工数は106%程度、ただしレビューやテストは50%前後だった。1000行あたりのバグ件数はBはAの80%。全バグ数に対する上流工程までのバグ摘出率はAとBはほぼ同じ。Bのテスト項目数はAの約半分だった。
組織Bは「プロセスを改善すれば工数やバグ数は減るはず」と解釈し、そのように取り組んでいた。だからテスト工数がAより少なくなり、そのような統計結果も出た。でも市場で出たバグを見るとBの方が品質が悪かった(数は変わらなくても、Bの方が長期間にわたってバグが出続けた!)。結果としてBのほうがAより2倍以上品質が悪いという調査結果が出た。
データを分析すると組織の取り組み方の違いが現れた。Bの組織は目標の達成が主眼となってしまい、数値目標を達成したらテストを終えてしまっていた。本当はプロジェクトごとに差が出るものなのにそれがなかった。基準値順守が「形骸化」してしまった。社内のベストプラクティスを組織Aと組織Bに適用しても組織Bでは効果が得られなかった。結局組織Bはルールだから実施していた、テスト時に担当者が頭を使っていなかった。
誉田さんがまとめのスライドに載せていたのは「何のためのプロセスかを常に考える土壌作り」が必要とのこと。形だけを真似ても成果は得られない。
・・・
目から鱗でしたね。ソフトウェアの状態をツールやメトリクスを使って見える化し、データをノウハウとして蓄え、組織として横展開できれば品質は今より良くなるはずだと思っていましたから。まさに組織Bの人間です。
プロジェクトごとに性格や条件が違うことに気づき、もっと頭を使わないと駄目ですね。自社の品質改善を考えていくに当たり、大きな宿題をもらった講演でした。
1/28と1/29に目黒雅叙園で開催されていたJaSST’10に行ってきました。色々学んだことはあったのですが、まずは基調講演の振り返りから。基調講演はJohannna Rothmanさん、Manage It! 現場開発者のための達人式プロジェクトマネジメントの作者さんですね。
開発者が行う改善は55%だが、マネージャーは65%の改善に貢献出来る。目的を持って人をまとめるのがマネージャーの仕事、開発に集中出来る椅子とかを揃える以外にに良い人間関係を築くことが大事。
効率的なマネージメントのやり方を17の法則としてまとめた。以下原文ママ。
以下Rothmanさんの発言メモ、一部意訳があるかも。
1. 業務上の肩書きと実際の職務内容、使命があっているか確認すること。
3. 優先度1のタスクは常に1つしか無いはず。複数あるのは何かがおかしい予兆。
4. タスクはチームで決めよう。
5. 雇うべきはgreatな人材、それは必ずしもチームに今いる人材とは違う。タイプ(性格/個性)の異なる人を集め、アイデアを生む。
6. 良いチームは残そう、解散するとチームが備えていた力が失われる。
9. 信頼できる関係を築くなら1対1がいい。直接のフィードバックもし易い。
13. 作業時間に比例して作業内容も増える。1週間40時間で仕事を終えられるよう作業を組むのもマネージャーの仕事。
Pragmatic Programmerシリーズの1冊を書いているだけあって実用的で、口先だけの話をしている人ではないのだなと聞いていて感じました。