久しく更新してなかったこのブログですが、久々に更新です。更新しなかった理由、、というわけでもないのですが、今年の4月から仕事でドイツにしばらく住んでます。ドイツは、ヨーロッパの中では日本と国民性も近いし、治安もいい、アウトバーンや鉄道も発達しているので、どこへ行くにも便利。料理は、、、まぁ南欧の国に比べたら落ちるかもしれませんが、素朴でおいしいです (^^)。ということで、非常に快適な国なのですが、唯一の問題は言葉の壁、つまり「ドイツ語」です。ということで、久々のエントリのテーマは「翻訳」です。

幸いにして、ドイツの方、特に都市部の人達の多くは、英語が結構堪能なので、英語さえ多少話せれば、ドイツ語はしゃべれなくても生活にはそれ程困りません。とはいえ、仕事柄、ドイツのニュースやネットを検索して情報をとったりする必要があります。この時、単語単位で調べてたら日が暮れますので、大抵翻訳ツールのお世話になります。市販ソフトもありますが、onlineで無料のものがありますので、そちらを利用します。有名なのは、Excite翻訳やGoogle翻訳でしょうか。使われてる方も多いと思います。

・Google翻訳 よくある質問
・Google翻訳が面白すぎる件 (Cozy Ozy)

なんだか、前ふりが長くなりましたが、このGoogle翻訳は、決して誤訳を楽しむだけのものではありません。かなり実用性があります。
特に、実力を発揮するのが、二つの言語構造が似ていて、且つどちらもメジャーな言語の場合です。具体的には、英語、ドイツ語、フランス語、イタリア語、スペイン語、あたりでしょうか。特にドイツ語と英語だと、同じ西ゲルマン語群で文法構造も似ているので、学習精度も高いのでしょう。実際、ドイツ語のニュースや記事をGoogle翻訳で独->英翻訳して読んでいますが、だいたい意味は分かります。例えば以下のような感じです。

・ Wikipedia - Hanshin Tigers (独->英翻訳)
・ Wikipedia - Hanshin Tigers (独->日翻訳)

英訳時の精度の高さがよく分かります。もちろん不自然な言い回しはどうしても出てきますが、私はあんまり気になりません (自分の英語能力が高くないおかげもあると思いますが.. :-P)。 上の例でも分かるように、欲張って、日本語訳まで期待すると、かえって訳がわからなるので、英訳で止めておくのがポイントです。
他の言語のページもたまに読みますが、英訳までで止めておけば結構使えます。もし、英語以外の言語のページを参照しないといけないという方は、ぜひお試し下さい。Google翻訳の真の実力が分かりますよ。

(補足) よく使う方に向けには、ブックマークレット(bookmarklet)が (翻訳ブラウザ ボタン)

【関連記事】
・googleを電卓として使う
・検索力

【関連書籍】
・翻訳に役立つGoogle活用テクニック 安藤進
・Google Hacks 第3版 ―プロが使うテクニック & ツール 100選 山名早人
・Spidering hacks―ウェブ情報ラクラク取得テクニック101選 村上雅章

サンクコスト (sunk cost) という単語を耳にされたことはあるでしょうか。日本語では「埋没費用」と訳されます。Wikipediaを見ると、「事業に投下した資金のうち、事業の撤退・縮小を行ったとしても回収できない費用」と説明されています。マーケティング用語ですが、今回は、ソフトウェア開発におけるサンク・コストとその対応について少し考えます。

サンク・コストのわかりやすい例としてよく用いられるのが映画館の話です。これまた、Wikipediaからひっぱってきましょう。

ある映画のチケットが1800円であるとする。しかし映画が余りにもつまらない時、1800円払った映画を見るべきか、それとも映画館を出て残りの時間を有効に使うかが問題となる。

• 映画を見るのを止めた場合：チケット代1800円は失うが、上映時間を有効に使うことができる。
• 映画を見続けた場合：チケット代1800円に加え、約2時間（上映時間）を失う。

この場合、チケット代1800円が埋没費用となる。この埋没費用は、どの選択肢を選んだとしても回収できない費用である。そこで時間を浪費してまで、つまらないと感じる映画を見続けることは合理的な選択とはいえない。残りの上映時間を有効に使うことが合理的な選択となる。

あるソリューションの開発に巨額の投資をしてきたが、他社がそれを大きく上回るソリューションを提供してきた。今の開発を続けても勝ち目はない。それでもとりあえず開発を完成させるべきか、それとももう一歩のところとはいえ、ここできっぱりやめるべきか。こういう事業判断もそうですね。
ついつい「せっかくここまでやったのだから。。」という考えをしてしまいがちですが、どちらにせよ過去の投資は返ってこないのだから、それらはサンク・コストとして考えてはいけないはずです。冷静に考えて見ればあたり前の話ですが、人間心理としてついついサンク・コストとこれからの投資を混同してしまいがちです。今までやってきたことを「無駄」だったと認めることは、精神的にはつらいところですからね。しかし、それは仕方のないことなので、きっぱりあきらめることが肝心です。

先の例は、事業判断の話になりますが、開発の現場でも同じような話があります。で、よくある話としては、初期の設計がまずい、あるいは、担当者のスキル不足から「こりゃ作り直した方が早いな」というケースです。こういう場合、「せっかくここまで作ったんだから」あるいは「この人もせっかく慣れてきたところだし」ということで、結局そのまま作り直さないでいることがありますが、この時サンクコストに囚われていないか判断が必要です。本当にその判断が正しいであれば、「せっかくここまで」というサンク・コストは無視して、今を基準にした判断が必要です。

こう書くとと、「問題がでたらすぐにあきらめましょう」と誤解されるかもしれませんが、そうではありません。それまでに払ったコストは返ってきませんが、そこで得られた経験はあるはずですので、それは考慮すべきです。これらは今後の投資額に利いてきます。 それに、プログラマという人種は「作り直し」が好きなので、本当に作り直した方が早いのかは、よく考えた上で判断する必要がありますね。
また、方針転換でリソース再分配する際には、部分最適だけに走って、プロジェクト全体のクリティカルパスに影響を及ぼしたり、長期的に無理が生じるようなことのないようにもしないといけません。

何にしても「引き時」というのはほんと難しい。それを痛感する今日この頃でした ^^;

【関連記事】
・手堅い見積もりが遅れを生む - セーフティの弊害
・このバグ直しますか? - 原因療法と対症療法

【関連書籍】
・サンクコスト時間術 (PHPビジネス新書 66) (PHPビジネス新書 66) 斎藤 広達
・ソフトウェア開発者採用ガイドJoel Spolsky 青木 靖
・図解 実戦マーケティング戦略 佐藤 義典
・ソフトウェアプロダクトライン―ユビキタスネットワーク時代のソフトウェアビジネス戦略と実践 前田 卓雄

人気blog「分裂勘違い君劇場」の記事「中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント」という記事が注目エントリになっています。ということで、ひさびさにコメントがてら投稿したいと思います。

• 分裂勘違い君劇場
  中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント

あげられているのは、次の三つ。

• 「変数のスコープは狭いほど良い」と妄信する
• 「同じロジックのコードを2度以上書くな」と妄信する
• 「プログラミング言語を極めるのが大切」と妄信する

さて、この手の話でよく引用されるのが「守破離」とう言葉。茶道や武道で用いられる上達に至る経緯を表した言葉です。「守」は、師についてその流儀を習い、その流儀を守って一般的には、「守」の段階ではまず型に従うことに徹して技を磨き、「破」ではその型を破ることで自分の型を見出し、「離」の段階で、元の型から離れ独自の境地に達する。 本質を端的に表した言葉ですが、これを実践するのはなかなか難しい。特に、ステップ移行のタイミング。早ければ独りよがりになり、遅すぎればいつまでも進歩しない。そうならないためには、自分の得意分野をひとつは持ってそれを極めつつ、視野を広くもって周りにも目を向ける。局所最適を防ぐにはほどよいノイズがあるくらいが調度よいものです。

【関連書籍】
・プログラミング作法 Brian Kernighan Rob Pike
・チェンジ・ザ・ルール！ 三本木 亮
・組込み現場の「C」プログラミング 標準コーディングガイドライン 福田 晃
・改訂版 組込みソフトウェア開発向けコーディング作法ガイド[C言語] (SEC BOOKS)
・武士道 (岩波文庫) 矢内原 忠雄

【関連記事】
・過学習と局所解
・このバグ直しますか? - 原因療法と対症療法
・ルールを破る時のルール

【関連リンク】
・ソフトウェア開発の守・破・離

設計レビューやソースコードレビューといったレビューは、ソフトウェアの品質確保だけでなく、開発者のスキル向上のためにも非常に有意義です。このレビューを有意義なものとするために心がけてべき最も重要なことのひとつが、
「自分の書いたソースコードや設計書に対して客観的であること」
です。簡単そうで、これがなかなか難しい。

人間、自分で作ったものは愛着が出ます。これはソースコードも同じ。エレガントなモデル設計やスマートなアルゴリズムに仕上がったものは誇らしいけど、混乱した設計や実装も、こんなはずじゃないんだ、分かっているんだとかばいたくなる。なので、人からつっこまれると、ついつい、ソースコードの味方をしてしまうことがあります。これは、ちょっと過保護で、ソースコード君のためにはなりません。

レビューに関しては、「責める」のではなく「褒める」とことが大事だという意見もあります。確かに、自分の書いたコードや設計が褒められるのは悪い気はしません。褒められて伸びるというのも否定しませんが、そこで喜ぶのはその成果物を客観的に見れていないということです。「褒める」という行為によって、自信をもたせることもひとつ重要な点だとは思いますが、悪い点はそこそこに、良い点ばかりを見るように仕向けるのは決していい方法とはいえません。

「プラス思考」「ポジティブ・シンキング」という言葉があります。この言葉を「いいように考える」という意味で使っている間は、決してスキルアップはありません。マイナス面に目をつむって、いい部分だけ見ていては、それ以上の改善はありません。「いいように考える」のではなく「よくするように考える」、悪い点があるのなら、そこをどうやっていい方向に持っていくかを考える、守るだけでなく攻める、そういう姿勢が重要です。批判は単に「耐える」ものではありません。素直に受け入れてそれを力に変えることが重要です。レビュアは敵ではないんですからね。

なお、レビュアの方も単に攻撃してやろうという気持ちだけではいけません。意見を受け入れられるように的確な対案をまじえながら建設的な指摘する、そういうレビュア側の姿勢も、高品質・高効率なれビューには非常に重要です。

  ....
  len = strlen(name);
  strncpy(buf, name, sizeof(len));
  ....

/* database中のoldをnewに置き換え */
void replace(DB* db, const char* old, const char* new);
...
  replace(db, new, old);
  ....

あなたはフォーク、ナイフ、スプーン、箸に続く画期的な食器を思いついてしまいました。またたくまに全世界で広く認知されるようになったその食器について以下のことを教えてください。

■ 画期的な食器の詳細
以下のA、B、Cにあてはまる語句を考えてください（回答必須）。
その食器はみんなが食事中になんとなく感じている（A）という問題を、（B）することで解決していました。その食器の名前は（C)。

その食器はみんなが食事中になんとなく感じている「ここにソースかけたらとなりのおかずまでソース風味になっちゃうかな」という問題を、「盛り付けられたおかず周辺のソースの流れをコントロールすることで、ターゲットのおかずにソースを集中させる」することで解決していました。その食器の名前は「低反発でおかずもあなたも快適プレート」。

• ごはんとおかずの三角食べをサポートする「ほっとけない君」
  
  • ごはんだけ残ったりしないように、おかずがへると警告するためのもの。
    各食器にセンサーを搭載して、おかずの消費具合を通信して、バランスを監視。
• おいしさのピークをどこへもっていくかサポートする「食べごろ君」
  
  • 大好きなおかずを食べるべきタイミングをお知らせするお皿。
• 食事中の会話をもりあげる「ネタふり君」
  
  • 話題がとまったときのネタふりサポート。カニなべ等でついつい食事に集中してしまいがちな時や、気まずい雰囲気になった時の会話のきっかけ作りに大活躍。

• できることが増えると、できないことが増える
• できないことが増えると、ストレスが増える

• 「できること」が増えると、「できそうなこと」が増える
• 「できそうなこと」 - 「できること」が、新たな「できないこと」として増える。
• 「できそうなこと」はどんどん増える。
• 「できることは」その内当たり前になって、「当たり前のこと」になる。
• その結果、以前より「できないこと」が増える

• 実際にできるというような間違った期待を抱かせない
• ・それでいて、将来に対する夢はあたえてくれる