カテゴリー別アーカイブ: IT

【移動】「オフショア開発」と「コンテキストをあわせる」

コンテキスト(コンテクストとも言う)は、文脈や文章などの前後関係、事件・出来事の事情や背後関係、と定義されている。わりと範囲の広い言葉で、自分自身は共通認識や文化が異なるときに「コンテキストが違うのでウンヌン」と言う使い方をすることが多い。

【文脈/コンテクスト】 に、コンテキストとは何かを理解するのに、とてもわかりやすい説明があった。

 <コンテクストのすり合わせ>とは特に、演劇において使われている用語です。
例えば、劇のとあるシーン。役者Aは自分の演じるキャラクターが、そのシーンで怒っているのだと思った。しかし役者Bは、そのシーンで役者Aの演じるキャラクターは、悲しんでいるものだと考えてしまった。
このまま舞台練習を開始しても、役者AとB、ふたりの演技は食い違ったものとなってしまいます。ですから事前に、脚本その他演劇全般に対する解釈を、皆の間で一致させる作業が必要となってきます。
解釈、すなわちコンテクストを共有・一致させる。このような作業が、<コンテスクとのすり合わせ>なのです。

日本は高コンテキスト文化と言われる。最近はそうでもないのかもしれないけど、おおよその価値観が人や地域によって大きく異なることは少なく、「空気を読む」ことで、お互いが求めてるものを理解することができる。一方、アメリカなど多くの人種が入り交じっているような国は低コンテキスト文化とされている。そもそも読むべき空気が無く、価値観もまちまち。両者の差異は本の厚さでも比較することができる。低コンテキスト分化の国では、経緯や背景、心理状況などを事細かに記載することで、まずコンテキストのすり合わせから入る必要がある。

同じような職種の人のように、お互いに同一のコンテキストを持っている同士では、非常に楽にコミュニケーションできる。お互いにお互いの空気を読めるため、それをわざわざ伝えなくてもその背景が共有できてしまう。これはいっけん良いことのように思えるけど、この「コンテキストをあわせる」という能力がまったく育たなくなってしまう。

オフショア開発の課題の一つとして、「日本側の要件・要求が正しく伝わらない」ということがある。これはこの高コンテキスト文化でのコミュニケーションが主な原因だと思う。異文化間でコンテキストをあわすことは難しい。いや、おそらく無理だ。欲しい物、つまり品質目標も含めて「要件をすべて書き切る」必要がある。

面白いのは、「いい感じによろしく」と、他人にある程度丸投げてやってもらっていた人にオフショア開発向けの要件定義書を書かせてみると、いくら頑張っても「要件を書き切る」ことができない。しょっちゅう、望んでいたものと違うものが出来上がってくる。書かせてみることで、内容についてどれぐらい網羅的に考えているかの判定に使うことができる。誤解されがちだけど、頑張っても「伝わらない」のはコミュニケーションスキルの問題ではない。

なるべく、コンテキストの共通点が少ない人と話すことで、このあたりの能力を伸ばすことに繋がってくる。例えば同じ会社の中なら「まったく技術の分からないセールス」と「技術者」のように、専門用語が通用しない相手がいい。技術がわからない人に対して、技術の話をわかりやすく話すという経験を積みまくることで、このあたりのスキルがすごく身についた。


【移動】受注者にとって「やりづらい」発注者になるには

社内の自分の目が届いていなかった部署で、ある開発会社に対して明らかに不要な費用を支払っている例があった。横柄になれとか圧迫しろという意味ではなく、騙しづらいという意味で、受注者にとってやりづらい発注者になる方法を考えてみる。

知識がないと騙される

業者にいいようにされてしまう場合、往々にして自分達に適正な知識が無い場合が多い。業者から出された金額や工数、あるいはその作業内容が妥当なものかどうかを自身で判断することができないため、そのまま丸呑みするしか無くなってしまう。最近あったケースだと、問題集アプリを作ってもらった業者に、別の問題を差し替えるだけの作業にも関わらず、初期開発の時と同じぐらいの費用を請求されていたということがあった。これは直前に知ることが出来たのでストップかけられたけど、危ないところだった。

自分でちょっとしたものなら開発できるぐらいまで知識を身につけておけば、勘所を理解できるようにはなると思う。ただ、いま騙されてしまうレベルの人達にそれを求めるのはちょっと難しい。

受注側の事情

発注者側の理不尽な依頼や、締め切り直前の急な仕様変更などに振り回された経験のない受注者は居ないと思う。明らかに騙しに来ている場合はともかく、誠実にやろうとしている受注者であっても、可能な限りバッファをいっぱい取りたいと考えてしまう。往々にして発注者側の怠慢や横柄さを起因とした結果でもあるため、なかなか業者だけを責めるのは難しい。

「比較」は知識の代替になる

まったく未知の領域の事柄で、自分自身に知識が全くない状況にも関わらずその評価をしなければならない場合には、同種の物を「比較」することで知識不足を補うことが出来る。複数の業者に相見積もりをすることで、見積もりのケースにおいて「比較」をすることが可能になる。

複数の見積もりを比較することで、作業項目やその単価がわかる。比較をすることで、突出したものや過剰な項目、あるいは不足しているのが何かを把握することができる。不明なことがある場合には、全ての会社に対して同じ疑問をすることで、騙されずに「正解」を知ることが可能だ。つまり、たとえ自身に知識が不足していたとしても、相見積もり先の企業の知見を間接的に借りられる。

相見積もりをされた場合、受注者側は自分達と同様の知識・スキルを持った同業者との戦いになるため、かなり「やりづらく」なる。さらに、相見積もりを取っているということを事前に言うことで、「やりづらい」効果は増していく。


【移動】squid が spam の踏み台になった

一昔前は、グローバルIPを持った回線やサーバを買うコストの問題で、専有サーバを持つのは一苦労だった。しかし最近では、特にVPSサーバが普及するようになってからは、レンタルサーバではなく、専有のサーバを借りることもすっかり珍しくなくなってきた。

VPSによりサーバを持つことのコストが劇的に下がったため、本来であったらサーバ運用も出来ない、そもそも運用で必要なことを理解していないレベルの人が持つようになってしまったため、知らない内に犯罪に加担してしまっている事例が増えているように感じる。

先日知り合いから、「あなたのVPSサーバがspam送信の踏み台になっている。一週間以内に何とかしないとサーバ落とすよ」とVPS運営会社から言われたので助けて欲しい、という連絡があった。昔はクラックされたサーバの調査や再設定などを良くやっていたけど、最近は久しく見ていない。ちょっとワクワクしながらサーバにログインして状況を確認してみる。

spamの踏み台になっているということなので、まずは/var/log/maillog を調べてみたけど、特に不審な点は見あたらなかった。踏み台になっているという連絡があった以上、踏み台になっていること自体は間違いないとは思うけど、状況が良くわからない。

いったんその IPアドレスを RBL で引いてみると・・・出るわ出るわ。あちこちの RBL に登録されまくっていた。これで、少なくとも踏み台になっていた証拠はつかめた。ps で見ても特に不振なプロセスは動いていな・・・! なぜか squid が動いている。

squid のアクセスログを見てみると、もの凄いサイズ。次に netstat してみると、外部の SMTP サーバへのコネクションがある。squid の設定を確認するとアクセス制限がまったくかかっておらず、いわゆる「オープンプロキシ」になっていた。これが犯人だ!

tcp 0 0 192.168.1.1:46708 199.236.32.56:25 ESTABLISHED 607/squid

実際にやったことはないけど、確かに接続先を 25 にすれば、spam を送ることも原理的に可能だ。知り合いに聞いてみると、「過去に実験用として squid を立ち上げた記憶がある。ただ、実験が終わったあとには確実に停止したので、再度起動している理由がわからない」らしかった。

とにかく、squid の停止とアンインストールをして、RBL に delist の申請を行った。その後、特に連絡もないし RBL からも削除されたようなので、事態は収束したようだ。その時はなぜ squid が起動していたのか不明だったけど、その後どうやら、VPS の母艦サーバがハードウェア障害で落ちたため、ゲスト OS にもリブートがかかったらしい。squid が自動起動になっていたので、その時に起動してしまっていた。運用会社から障害報告の連絡がなかったので、再起動したことにまったく思い当たらなかったと。

VPSになってサーバを持つ敷居が下がったのは素晴らしいことだけど、あまり運用に関する知識が無い層の人達も、VPSを持つようになってきてしまった。Heroku や Google App Engine あるいは Windows Azure のような PaaS は、オートスケールなど、どちらかというとプロユースを想定したものになっている。従来であればレンタルサーバを使っていた層を吸収してくれる PaaS は(PaaS に当たらない物を勝手に PaaS と呼んでいる場合を除いて)今の所は思い当たらない。

「安価で使いたいときだけ起動して使う」といったカジュアル利用を目的とした PaaS サービスが出てこないだろうか。それが他社との差別化に繋がるかどうかはわからないけど、使わないときには落とすという習慣により、結果として知らないうちに加害者になっているという状況は改善するように思える。というか、踏み台になってうちに spam を送りまくるサーバは全部落ちて欲しい。


SmartNews 問題は「気に入らない」という感情の問題ではないか?

ソーシャルニュースリーダの SmartNews のスマートモードがいま話題になっている。これはTwitterで言及されたURLを集約して、それをニュースコンテンツのように配信するアプリだ。オフラインでも読めるよう、アプリ起動時にコンテンツをダウンロードする機能があり、スマートモードではあらかじめダウンロードしたコンテンツを表示することができる。

この機能にまつわる議論は ニュースアプリリーダー「SmartNews」をめぐる議論 にまとまっているが、要するにダウンロードされるコンテンツに対して、サーバ側で広告除去やページ分割無視などの加工を行なっていることが、完全タダ乗り、フリーライドと批判されている。

これを受けて、開発元の株式会社ゴクロは、SmartNewsに関心をおもちいただいているみなさまへ で、その見解をプレスリリースしている。

メディアの視点から考えてみる。媒体にとって最も重要な媒体力、つまり広告主に対してアピールできる最もわかりやすい指標はPVやUB、あるいは広告の表示・クリック数である。しかし SmartNews のようにキャッシュされたコンテンツを参照されてしまうと、どちらも増えない。せっかくコンテンツをページ分割してPV稼ぎをしているのに、それが台無しになってしまう。

サイト上で RSS を提供しているため、RSS リーダで読むことと一緒だと考えることもできるが、RSS に出力するコンテンツはメディア側でコントロールすることが出来る。本文の一部だけに限定することも出来るし、また広告を差し込むことも自由にできる。SmartNews のようにコンテンツを持っていかれてしまい、その出力形式を自由にコントロールされてしまうのは、彼らにとって望ましくないと言える。

一方、SmartNews を使ってコンテンツを読む人間、つまりユーザの立場で考えてみると、ほとんどのユーザはメディアに対して特別な感情、つまりファン意識のような物を持っている人は少ない。メディアに対して別にロイヤリティを持っているわけではない。いちいち各メディアのコンテンツに見に行くのも面倒くさいし、コンテンツを複数ページに分割するようなPV稼ぎは利便性が下がるだけで、あれを不愉快に思わない人間は居ない。ニュースを集めてくれたり、分割されたページを1ページにまとめてくれるようなサイト・アプリがあれば、そりゃ使うだろうな、と思う。

SmartNews がリリースされてからこれまでは絶賛の声しか無かったため「何だか気に入らない」という感情論もあるとは思う。ただ結局の所、ユーザにとっての不便を軽減してくれるツールなのにも関わらず、「SmartNews 自体がメディア」のような顔をしているのが問題なのではないか。

コンテンツが自分自身の物でない限り、メディアという見せ方は好ましくないと思う。ツールならツールらしく、「ツール」に徹するべきだろう。一連の議論を見る限り、ゴクロ社は技術や法律(著作権)という観点で問題がないと主張しているが、反対している人たちは感情論で話しているため、議論がかみ合っていないように思える。

感情がその根底にあるのだから、法的に正しいことをやっているといくら主張しても収束はしない。その感情を納得させるような対応が必要になる。


【移動】ATOK Padでひどい目にあった

以前、iPad mini+ポケモンキーボードを絶賛 したけど、今日のミーティングではひどい目にあってしまった。

何人かの人にインタビューをしている時のメモ書きとしてiPad mini+ATOK Pad を使って書いていたけど、

・初回:途中でいきなり固まった。一度HOMEに戻ってATOK Padを起動すると、書いた内容がさっぱり消えてしまい編集前の状態に戻ってしまっていた。

・二回目:無事に記入し終わってからATOK Padの文書一覧に戻り、また文書を表示すると、これまた途中まで書いた内容に戻ってしまっていた。

発生原因がわからないのでどうやれば再現するかどうかはわからないけど、自分用のメモ書きのようなものならともかく、他人が絡むミーティングの時には危なくて使えない。

問題点の一つとしては、「保存」という機能が無いからだと思う。人によってまちまちだとは思うけど、自分は結構頻繁、それこそ指がちょっと止まったタイミングで必ず保存するような癖がある。

保存という作業をすることで、少なくともそのタイミングまでの文書の内容は固定されるけれど、ATOK Padには保存機能が無いため、そこまでに書いた内容(が保存されること)が保証されない。結果、どこまでの内容の文書が保存されるのかさっぱりわからない。挙句の果てに内容が巻き戻ってしまう。これはきつい。

最初に消えた時に、ALT+Sを押すことで保存されるのかと思い結構頻繁にやってたけど、このザマだ。全然保存されない。これだとビジネスではまったく使えない。漢字の変換などで気に入ったんだけど、別のevernote連携のメモ帳を探さないといけないな。

2012/12/01追記:ちょっと探してみたら、iText Pad というものが評判が良かったので買ってみた。ローカル環境に対して「保存」という機能もあるし、Evernoteとの連携もできる。「圏外の時にはローカルに保存しておいてオンラインになったら差分を同期する」という最も希望していた機能は残念ながらなかったけど、

  • evernoteのファイルをオープン
  • 圏外での編集時はローカルに保存
  • オンラインになったら手動でevernoteに保存

という運用で逃げられるというのがわかった。これで何とか次回のミーティングの時も iPad mini を使えそう。


【移動】Mac版Evernoteからランダムにノートを選んで表示

今まではEvernoteのユビキタスキャプチャ用のノートブックからノートを定期的にピックアップして見返していましたが、偶然 Evernote からランダムにノートを選ぶ(AppleScript) という記事を見つけました。

これはイイですね。今までは適当にノートをピックアップしてたため、どうも偏りがちだったんですが、これならランダムにできる。

tell application "Evernote"
set query to query string of window 1
set notelist to find notes query

repeat 5 times
set rand to random number from 1 to length of notelist
open note window with item rand of notelist
end repeat

end tell

どうせならランダムで5つピックアップして欲しいんで、こんな感じにループするようにしました。いやー、便利になったな。


【移動】PHPから任意のbacklog APIを呼び出す

最近、Backlog を会社で使うようになりました。まだベータ版とは言え APIがあるようなので、PHPからAPIへのアクセスを試してみました。

Backlogアプリケーション を見てみると PHP用のライブラリがありましたが、2009年から更新されておらず、また対応しているAPIの数が圧倒的に少ないようです。ただ中身を見ると単なるXML-RPCコールに過ぎないので、こんな感じの関数を追加して任意のAPIを呼び出せるように改造しました。

% diff -u org/Backlog.php Backlog.php
--- org/Backlog.php     2009-05-20 12:05:53.000000000 +0900
+++ Backlog.php     2012-04-08 11:46:09.434337869 +0900
@@ -75,6 +75,16 @@
         $this->client->setCredentials($user, $password);
     }

+
+    public function callAPI($method, $params = NULL) {
+               if ($params == NULL) {
+                    $message = new XML_RPC_Message(self::PREFIX . $method);
+               } else {
+                    $message = new XML_RPC_Message(self::PREFIX . $method, $params);
+               }
+               return $this->_send($message);
+    }
+
     /**
      * 参加プロジェクトを取得する
      *

APIの呼び出し自体は非常に簡単です。ID/Passwordを指定してライブラリのインスタンスを作成して、メソッドを呼び出すだけです。

<?php
require_once 'Services/Backlog.php';

define('FQDN', 'hogehoge.backlog.jp');
define('ID', 'apiuser');
define('PASSWORD', 'password');

$backlog = new Services_Backlog(FQDN, ID, PASSWORD);

echo '<pre>';

# getProjectsの呼び出し
$result = $backlog->callAPI('getProjects');
print_r($result);

# getProjectの呼び出し
$params = new XML_RPC_Value('TESTProjectKey', 'string');
$result = $backlog->callAPI('getProject', array($params));
print_r($result);

# countIssueの呼び出し(ProjectID=12345, 状態=未対応、担当者未設定)
$params = array();
$params['projectId'] = new XML_RPC_Value('12345', 'string');
$params['statusId'] = new XML_RPC_Value(1, 'int');
$params['assignerId'] = new XML_RPC_Value(-1, 'int');
$result = $backlog->callAPI('countIssue',
  array(new XML_RPC_Value($params, 'struct')));
print_r($result);

echo '</pre>';

当たり前ではありますが、管理者権限じゃない限り、任意のプロジェクトの情報などを取得することはできません(人間ができないことはAPIでもできない)。

いずれは自動投稿なども試しては見たいですが、最初はプロジェクトや課題の状態を表示するダッシュボードのようなものが作れれば十分なので、ビューアー権限でAPI用のユーザ(例えばapiuser)を作成して、全プロジェクトに追加するという運用にしました。


【移動】PukiWiki Plus! を Ubuntu にインストール

Wikiはずっと Pukiwiki を使ってきたんですが、その後継版(?)の PukiWiki Plus! というものがあると知ったので、Ubuntu にインストールしてみました。

PHP5.3 対応やHTML5+jQueryUIポートを行なっている PukiWiki Advance というものもあるようですが、7-zip形式という良くわからない形式でアーカイブされているので試すことはできませんでした。

PukiWiki Plus! のインストール方法は普通の Pukiwiki とほぼ同じようで、多少 locale の設定で迷った位で簡単にインストールできました。

まずは /etc/locale.alias に utf-8 の設定を追加して、ロケールを作り直します。

ja_JP           ja_JP.utf8

% sudo locale-gen

その後、Apacheを再起動すれば前準備は完了です。ロケールが正しく設定されていないと、英語表示となります。詳細に関しては PukiWiki Plus! の質問問箱/247 が参考になるかと思います。

あとは PukiWiki Plus! をインストールするだけです。まずはgitからファイルを持ってきます。

% git clone https://github.com/miko2u/pukiwiki-plus-i18n

次に適当なディレクトリに移動して、Basic認証の設定とファイルのパーミッションを修正します。

% htpasswd .htpasswd xxxxuser
% sudo chown -R www-data *

あとは auth.ini.php でパスワードを設定したり、各種 ini で自分のお好みの設定をすれば完了です。

$adminpass = '{x-php-md5}' . md5('xxxpasswords');

2012/03/29追記:会社にあった Ubuntu 11.04 で試した場合、デフォルトの状態が変わったのか、日本語関係の設定がされてないだけだったのかわかりませんが、locale-gen の前に、言語パックなどのインストール・設定が必要でした。

% sudo aptitude install language-pack-ja
% sudo localedef -i ja_JP -f UTF-8 -A /etc/locale.alias ja_JP.UTF-8

 


【移動】zphoto を Ubuntu 10.04.4 で使う

お手軽にフォトアルバムを作る必要があったので、ものすごく久々に zphoto を Ubuntu で使ってみました。

libming-dev, libpopt-dev, libimlib2-dev をインストール後に configure, make してみると、下記のようなエラーで止まってしまいました。

make[2]: Entering directory `/home/xxx/tmp/zphoto-1.2'
g++ -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -DZPHOTO_TEMPLATE_DIR='"/usr/local/share/zphoto/templates/default/en"' -DZPHOTO_FONT='"/usr/local/share/zphoto/fonts/EfontSerifB.fdb"' -DZPHOTO_TEMPLATE_DIR_RELATIVE='"templates/default/en"' -DZPHOTO_FONT_RELATIVE='"EfontSerifB.fdb"' -I. -I. -I. -I.        -O2 -Wall -Wunused -Wuninitialized -c -o image.o image.cpp
image.cpp: In function 'int convert_needed_p(const char*, const char*)':
image.cpp:557: error: invalid conversion from 'const char*' to 'char*'
image.cpp:558: error: invalid conversion from 'const char*' to 'char*'
make[2]: *** [image.o] Error 1
make[2]: Leaving directory `/home/xxx/tmp/zphoto-1.2'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/xxx/tmp/zphoto-1.2'
make: *** [all] Error 2

このエラーを調べてみると、Getting Invalid conversion from const char* to char* on gcc 4.4.1 にもある通り、gcc(g++)のバージョンが 4.4 なのが問題のようです。g++のバージョン4.1を下記のようにしてインストールしました。

 % sudo aptitude install g++-4.1

後はMakefileのCXXをg++-4.1に変更することで、無事にコンパイルが通るようになりました。

% diff -u Makefile.org Makefile
--- Makefile.org     2012-03-26 22:39:09.413993750 +0900
+++ Makefile     2012-03-26 22:41:33.549992947 +0900
@@ -138,7 +138,7 @@
 CFLAGS = -g -O2 -Wall -Wunused -Wuninitialized -Wmissing-prototypes -Wmissing-declarations -pedantic
 CPP = gcc -E
 CPPFLAGS =
-CXX = g++
+CXX = g++-4.1
 CXXDEPMODE = depmode=gcc3
 CXXFLAGS = -O2 -Wall -Wunused -Wuninitialized
 CYGPATH_W = echo

コンパイルが必要なアプリを入れたのは何年かぶりですが、gcc4.4で同様の問題にハマっている人は結構多いみたいです。有名な問題(?)なんですね。