2009年12月 Archive

でも今から出勤。

さすがに年越しの瞬間は会社で迎えたくないのでそれまでには帰宅したいところだけど。

年始は3日から始動かな、今のペースだと。バグ解析とか残機能の実装設計とかやらないといけないことがけっこう残っているし。

来年も前半は仕事がどんどん積まれそうな雰囲気だしなぁ...。ちょっと組織自体がキーマンの高稼働に依存しすぎてるような気もするので来年はその辺を改善すべく声を上げていきたい。

予定なら今日から正月休みだったはずなのだけど、今のところ休みが確定しているのは元旦だけ。

今年のまとめというか振り返りも少ししたいのだけど、そんな暇無さそうね...。

年末のギリギリになってプロジェクトがドタバタして、急きょ正月も出勤とかねぇ。経緯を見てるとなんで？って思うような理由なんだけど、けっきょくしわ寄せ来るのは現場。

...ということで今日も今から出勤。

なんとか正月休みを迎えられそうだと思っていたら、事態が急展開で正月休みも出勤になるかも知れない状況に。

この業界に入って10年、ブラック企業と言われてるこの会社でもさすがに正月に仕事だったことは無いのだけどね...。

実際にどうなるかは明日決まるのかな。

忙しさにかまけているうちに、学校は冬休みにはいったらしく子供たちを朝から見かけるようになったり、博多駅に行けば大きな荷物を持った帰省やら旅行やらの人で溢れている。

早い人はもう年末モードなんですねぇ。私はまだまだ２９日まで仕事がぎっしりとあるので全然年末って気分では無い...。

博多駅も久しぶりに行くと、新幹線口の改札が変わってたり、新ビルもだいぶ棟上げされていたりと着々と進んでるのが分かる。普段は自転車で家と会社を往復してるから、足を伸ばさないと博多駅も行くこと無いのよね。

街に出ないと、本当に月日だけが過ぎて行っちゃってクリスマスだの正月だのっていう雰囲気が体でわからなくなるな。

たまにはちょっと遠くにぶらっと行ったりしたいものだ。適当に電車とかバスとか乗り継いで。特に目的の無い遠出もけっこう好きだし、最近そういうのやってないしなぁ。

久しぶりにbeagleboardを出してきてandroidを入れて立ち上げてみた。

EclaironBeagleBoard - android-development-environment - BeagleBoard に eclair をのせる - Project Hosting on Google Code

手順は↑のサイトをそのまま参考に。

ちょっとUSBの認識が上手くいったり行かなかったりとするけど、USBキーボードを接続して操作するところまでやってみた。マウスは接続すると起動途中でsystem_serverプロセスが落ちてダメだった。

beagleboardは各方向にいろんなケーブルを繋げるので机の上がゴチャゴチャしがち...。

adbもネットワーク経由でしか繋がらないし、本格的に遊ぶにはいろいろ準備が必要なのでまずはどうしようかなぁ。beagleboard用のパッチがどこにどんな差分があるか見てみるあたりから始めてみたほうがいいのかな。

休日出勤前に紀伊国屋に立ち寄り。久しぶりの書店。

ちょっと気になっていた本があって、それがこの「プロジェクトファシリテーション」。

これは全社単位の改革プロジェクトなので、もっと小さなプロジェクトとかにどれくらい参考になるかわからないけど、成功したプロジェクトの物語として興味があったから。

amazonレビューでも高評価だったし、変に物語り風だったり自画自賛的な内容じゃなければと、まだ読んでないので期待。

プロジェクトファシリテーション
	おすすめ平均 日本版、実名入り「GOAL」、これだけうまくいったプロジェクトだけに、参考になる個所は多数 もはやビジネス書ではない 感動に震えたビジネスノンフィクション 生の声が面白い 自分が関わったプロジェクトを思い出し涙が出てきた Amazonで詳しく見る by G-Tools

気がついたらクリスマスも終わって、門松が立つようになってますな...。

もう年賀状も基本的に書かないし帰省も無いので、正月に向けて準備だのどうこうは無いのだけど、会社と家の往復で天神にもしばらく行けてないしほとんど仕事ばっかりだな。

30歳過ぎてから、自分の時間について本当に気にするようになった。

20代はデスマーチ含めてほとんどを仕事に費やしてしまったけど、30代はもう少し自分の時間を確保したい。今の会社、立場では昔に比べてさらに難しいのかもしれないのだけど、このままずーっとこの生活は続けてられないねぇ。

「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey

質問　日本はウォーターフォールが盛んな状況ですが、それは顧客が昔からそうした契約の発注を続けていることにも一因があると思っています。自分の顧客にもウォーターフォール型の開発を望んでいるところが多くあります。こうした顧客にアジャイルを理解してもらうためのアドバイスをいただきたい。

Guo氏　これはアジャイルに関してよくある課題です。顧客からすれば、これだけ払うのでその対価としてこれだけやってもらいたい、この料金を支払えばこの機能が手に入る、という契約は、なかなか変えにくいものがあります。

受託だとこの「いくらくらいでできる？」という引き合いは必ず言われる。発注側としても、予算を確保してその中で発注するしかないので、まずは総額でいくらかかるのか、というのが大事になってしまう。請けるほうも、ある程度の要求仕様を固めて、じゃあ全工程の見積もりでこのくらいですというかたち。

でもどのプロジェクトもそうだけど、設計段階で仕様Fixしても最後までその仕様がFixしたままなんてことは無かった。小さい仕様変更ならそのままやるし、大きな仕様変更ならまた追加請求だのなんだのという話になる。

ウォーターフォールは一見、発注側も請け側も価格は最初に決まるし、仕様もほぼ先に決まるし全体が見えてるから分かりやすい、やりやすいと思ってしまうのが間違い。

でもこの商習慣は変わらないだろうなぁ...。発注側に予算という枠がある場合は。

可能性があるのは、顧客にビジネスのプレッシャーがかかっているときです。マーケティングや事業開発部門の人たちは要件が変わりやすいものです。「開発中にどれだけ要件の変化に対応しましょうか？」といった質問から始めるのがいいのではないでしょうか。

弾力的な予算確保が発注側にできそうな場合は、たしかに可能性はあるかも。ただ商習慣的にこういうことができるケースがどれくらいあるんだろう。

Guo氏　多くの組織、企業文化の中ではコードを書くの仕事はいちばん底辺で、そこからマネージャになっていくことがキャリアを上っていくことになっています。しかし、これは間違いだと思います。

コードを書くというのは、例えて言えば地面にタイヤが接地するようなもので、有能な人がコードを書くべきです。賢い人がマネージャでそうではない人がコードを書く、というのは企業文化における課題だと思います。

SIerの課題かも。コードが書ける人でも、年数が経つと人的コストからコードを書かせてもらえなくなるっていう。

もちろん、若手や後輩に経験を積ませたり教育をしたりするためにコーディングさせるということも必要だろうけど、キャリアパスが画一的すぎていちばん脂の乗った時期にマネージメントのみというのも開発の生産性を下げてる面もあると思う。

本人が望んで、かつ能力があるのならコーディングや現場の仕事ができるようにすべきだよな。

Android-Eclair porting guide to BeagleBoard - Labs.embinux.org wiki

↑を見て、久しぶりにBeagleboardでandroid(eclair)だと思ってrepo syncしてみたのだけど、どうもまだ一部がdonut相当らしく、ubuntu9.10ではビルドできなかった。

EclaironBeagleBoard - android-development-environment - BeagleBoard に eclair をのせる - Project Hosting on Google Code

まだ試してないけど、↑のほうが本家eclairのツリーにパッチを当てる形のようなので良いかも。

原油高と同じくらい深刻な「ホワイトカラーの仕事破壊」 - アンカテ

「本気」で仕事する人間と競争して勝てるのかってところに尽きると思う。

高給、社会的名誉、やりがい、夢、どれでもいいけど、中国やインドや新興国で特にITをやってる人ってたぶんどれかをモチベーションにしてるんだと思うのですよ。あと先進国のベンチャーとか。

モチベーションを持って本気で仕事をしてくる人たち、そしてそういう人たちが集まった組織に、日本人、日本の企業は勝てるのかって言えばたぶん厳しい。嫌々会社に行き、残業して疲れて帰って、会社の愚痴はネットで憂さ晴らしって感じの毎日やってる人と比べてどうよ、と。

日本の場合は働く側だけの問題では無いのだけど、どちらにしろ海外と競合する産業はこのままだと厳しいだろう。

まだ調査中ではあるのだけど、そんな動作をするようだ。

例えばandroidのServiceは、常駐させたりして使うこともある。そんなServiceが何らかの原因で例外を吐いて落ちたとき、1度目であればActivityManagerが5000ms以上の間隔を開けた後に再起動してくれる。

WARN/ActivityManager(53): Scheduling restart of crashed service net.swingingblue.testservice/.TestService in 5070ms

でも再起動したあと、さらに例外を吐くと、

WARN/ActivityManager(53): Service crashed 2 times, stopping: ServiceRecord{43c14178 net.swingingblue.testservice/.TestService}

と表示され、"stopping"という状態になる。この状態になるとActivityManagerはServiceを再起動してくれなくなる。

この時、

1. ActivityからのstartServce()やbindService()
2. AlarmManagerからのIntent発行

でServiceは再び起動するのだけど、それが無い限りServiceは動作しない。

また、60秒の間に2度死ぬようなことがあると、

WARN/ActivityManager(53): Process net.swingingblue.testservice has crashed too many times: killing!

と"crashed too many times"となり、こうなるとAlarmManagerでintent発行によるService起動は

WARN/ActivityManager(53): Unable to launch app net.swingingblue.testservice/10024 for service Intent { act=net.swingingblue.testservice.TestService cmp=net.swingingblue.testservice/.TestService }: process is bad

と"process is bad"として内部で蹴られてしまう。

この状態でも、ActivityからのstartService()やbindService()は有効なのだけど、常駐サービスとしてServiceを使っていて、かつAlarmManagerで自分自身にIntentを飛ばしてるような場合だとエラー時にシステムに救済されるのは最悪1回のみ（60秒間に2度エラー吐くと起動禁止）ということになる。

常駐型のServiceを作ろうと思っている人は気をつけたほうが良いかも。

また、この辺のActivityやServiceの起動管理は、androidのソースの

mydroid/frameworks/base/services/java/com/android/server/am/ActivityManagerService.java

を見ると、少しわかると思う。

イーバンクマネーカード（クラシック）のVisaデビット機能終了ならびにポイント制度の改定について イーバンク銀行｜インターネットバンキング

年1000円とは言え、ちょっと残念。

たぶん、私のような少額決済目的で口座を持ってる人が多いんだろうなぁと思うんだけど、銀行からしてみれば不良顧客なんだろう。

VISAデビットがもっと他の銀行でも取り扱ってくれればいいんだけど、選択肢がイーバンクとスルガ銀行しか無いしな...。ふつうのクレジットカードみたいに翌月の請求書見てびっくりということが無くて残高にほぼリアルタイムで反映されるから便利だと思うんだけどね。

Wikipediaを見ると、残高不足で引き落とせなかったときの処置がカード会社と銀行間で決まってないからという理由で採用されてないみたいなこと書いてたけど...。

イーバンクも経営が苦しいんだろうけど、ここ1，2年の相次ぐ制度変更で逆に「こんなにコロコロ変える銀行にたくさんの資産を預ける気にならない」と思われると思うんだけどね。まぁどの制度変更も少額しか預けてない、取引額も小さい人向けにハードルを上げてるものがメインだから、それなりのお金がある人には関係無いのかも知れないけど。

会社の忘年会。久しぶりの飲み会も兼ねて。

グループ別に開催だったので例年のようにやたらに大人数ということもなく、私は同期入社の奴と久しぶりにゆっくりと話し込む。

テンション上がって盛り上がる一角あり、普通に話し込んでるところもあり、それぞれ楽しめたんじゃないだろうか。

そして二次会は社内の別のグループと合流...だったけど、正直なところ知らない人が多かったなぁ。ふだん話すことがない新人たちとチョロチョロと話してたくらいかな。新人の皆さんには、もともと絡みづらいキャラなので悪いことしたかもなー。でも新人の入社してから感じたことなどを聞いてると、いろいろと思うことがあって、ちょっと自分の中の考え方変わったかも。

最近はずっと仕事ばっかりだったので良い息抜きになったかな。

今のプロジェクトに応援で来てもらっているメンバーも、2月くらいで離れる予定。

そろそろこちら側のメンバーへの引き継ぎのことも考え出さないと。

自分のチームはそれほどブラックボックスなところはないのだけど、設計とソースコードの構成だけは誰かにきちんと引き継がせないと。今回は私がコーディングに入ってないので、ソースコードの細かいところまでは把握できてないってのもあるから。

あとはドキュメントを最新の状態に更新するのと、特に陥り易い仕様とか処理などの補足ドキュメントが必要かな。

たぶん私自身も2月くらいからは片足を別のプロジェクトに突っ込む可能性もあって、私以外の人にきちんと引き継ぐようにしないとダメだろうね...。

細かい作業がいろいろ発生して、何をやればいいのか整理しないといけないな。

プロジェクトも終盤に入ってきて、積み残しの作業を洗い出して不具合管理と一緒に常に対応していくようにしないと、何の問題を解決しないといけないかすぐに混乱しそう。

自分の情報の管理が悪いせいでしばらく放置したままの問題が発覚したりと、ちょっと気を引き締めないとなぁ。

このごろはどうにも頭がボーッとして物事が手につかない。

なんだろうな、たまに何か思いついてもすぐに忘れてしまうし、たぶん集中力が無いんだろうな。単に忙しいからそうだっていうのなら良いんだけど、いろいろ目標を見失ってる感じもするし。

なんかじっくり考える時間が欲しいような気もするけど、頭が回るかな？

少しだけ平穏な日。

ここまで来るのに時間かかったなぁ。まだまだ年末に向けてやらないといけないことは山積みなんだけど、少しだけホッとしている。

もう半月くらい早く今のような状態なら良かったんだろうけど、それは無いものねだりというものか。みんなずいぶん頑張ったし。

仕事のメールで相手とやりとりするとき、どうにも効率が良くないことがある。

[件名]X関数の動作について

[本文]この関数はAのような動作しますか？それともBの動きでしょうか。

[件名]Re:X関数の動作について

[本文]その関数はBのように動作します。

[件名]Re:Re:X関数の動作について

[本文]では、Bのように動作するなら、Cのケースで呼び出しても問題無いですか？

[件名]Re:Re:Re:X関数の動作について

[本文]はい、問題ありません

...実際はもう少し中身が伴うけど、一問一答のようなメールのやりとり、しかもメールごとのタイムラグが数時間単位だったりすると、ちょっとした結果を知りたいだけなのに一日かかってしまう。電話したほうが早いね...。

こういうときは質問をもっとまとめて、一回のやり取りで終わるように質問する側が工夫したほうが良いと思う。

[件名]X関数の動作について

[本文]この関数はAのような動作しますか？それともBの動きでしょうか。

もしAなら2番目の引数には1を設定すれば良いですか？

また、動作がBのケースの場合はCのケースでの呼び出しは可能ですか？

[件名]Re:X関数の動作について

[本文]その関数はBの動作をします。そして、Cの場合でも呼び出しは可能です。

...と、あらかじめAやBのどちらかの回答があったとき、追加質問がすでにこちらがわにある場合は先に一緒に書いて一気に解決を目指す。

相手が数十分以内に返信してくるような状況なら一問一答式でもいいけど、お互い忙しくてメールのタイムラグが大きいときは絶対に、内容をまとめて、先のことも一緒に質問として投げるべき。

時間の無いときほどお互いメールの返信は悪くなるわけだし、ちょっとした発想で仕事の効率はあがると思う。意外とそこまで考えが回らない人多いんだよなぁ。

深夜まで勤務が続いているので、夕方くらいに間食を採るのだけど、家に帰って夜食も採るのについつい夕方に食べ過ぎてしまって、最近少し太り気味。

太るだけならまだ見た目の問題だけど、体に負担がかかっているのかどうも体調がすっきりしない。

本当は間食の量を減らさないと駄目だよなぁ。以前はSoyJoyで済ませられてた時もあったのに、コンビニやスーパーに買い出しに行く癖が付くといろいろ買い込んでしまうし。なんか食べる時がストレス解消みたいになってしまってるからね。

どう考えても食べ過ぎなので、できるだけ節制しないとな...。

【速報】Google Phoneは近日発表か。現時点でのスペックまとめ：in the looop：ITmedia オルタナティブ・ブログ

Google Nexus One phone - SlashGear

実際発売されたとして、日本の場合はキャリアとの関係はどうなるんだろう。

SIMロックフリーまわりの事情には詳しくないのだけど、他の機種で契約したSIMに差し替えれば国内でも定額で使えたりするのかな。

あとキャリアの値引きが無い分、価格は（ケータイの感覚としては）高めになりそうな気もする。$500～$600、スペックが良ければ$700近くまで行きそうだし、そうすると手を出せる人は少ないかも。

ただ、国内ではAndroid端末の選択肢はまだ少ないし、来年に入ってやっと色んなところから出てきそうって状況だから、ガジェット好きな人には良いのかも。逆に変にキャリアに縛られなくても良いというのもあるし。

それより、Android2.1でまたどのあたりが変わるんだろうってほうが興味がある。ホーム画面がけっこう変わってるって話しもあるようだし、だんだんと練られたUIになってくるのかなぁ。

http only proxy での Source取得 - 日本Androidの会 | Google グループ

日本Androidの会で↑のような投稿が。

以前、私も社内からいろいろ試したことあるけど結局うまくいかずに諦めたんだよなぁ。

その時はgitをHTTPトンネル通してやろうとしたんだけど、コネクションがすぐに切れたりして不安定だった覚えがある。

ちょっとこの方法でもう一度試してみるかな。Eclairのソースとか今後の仕事のためにも見て調査したりしたいし。SubversionならHTTP/HTTPSサポートしてるところが多いのでオープンソースをダウンロードしたくなってもそれほど困ることはないのだけど、今gitが急速に広まってるし...。

たぶん、gitなどを使うようなアクティブな開発者の人たちは、会社ネットワークもHTTP縛りとかないところなんだろうな。

40日ぶりくらいだろうか。

今日の担当の人はけっこう丁寧にアドバイスしてくれて良かったな。いつも「今より1センチ短く」くらいの注文しかしないのだけど、全体のバランス見て良い感じに切ってくれたみたい。

次回もこの人にあたるといいなぁ。

Androidのフルソースのexternalディレクトリの下に入っている各種オープンソースのソフトウェアのように、bashのソースを展開してAndroid.mkを書けばいいのかと思っていたら予想外に難航。

configureスクリプトを使うソフトはandroidのビルドシステムでビルドできるんだろうか、先に手動でconfigureくらいはしておく必要がありそうな気もするな。

Android.mkも、コンパイル対象のソースファイルを全てAndroid.mkに書いてしまうやりかたと、各ディレクトリのMakefileを使ってmakeするやりかたと二種類あるようだし。

ネットを探すと、ARM用のツールチェインを使ってビルドしておく方法がほとんどだけど、どうせならAndroidのソースをビルドするときに一緒にできたらなぁと思ってるんだけどね...。

もうかれこれ4年くらい使っているflickr。

自分が撮った写真はほぼすべてアップロードしていて、機能的にも特に不満は無い。シンプルなサイトデザインも好みだ。

たくさんの写真を上げているので、有料オプションの契約をずっとしてきている。今年も更新の通知が来ていたので1年延長した。1年で$24なのでそれほど高いものでもないだろう。

最近は全くと言って良いほど写真は撮ってなく、iPhoneで少し撮るくらいになってしまってる。また時間があったらデジイチ持ってどこか行きたいところだけど。

ボーナスが出るには出たけど、いつもの3分の1。

出るだけましかとも思うのだけど、やっぱりテンションは下がる。

今の会社の状況だと、おそらく来年の夏もほぼ同程度かなぁ。たぶん、もう今までのような額は無いんだろうな。

支給率が低いのはわかっているので、支給日なのに会社でも誰もボーナスの話題を出すことも無く。

とりあえず使う予定も特に無いのでそのまま口座でしばらく眠ってもらうことにしよう...。

@nifty：デイリーポータルZ：美味しすぎる立ち食いそば巡り

東京に行ったときにいつも思うのが、各駅にほぼ立ち食いそば屋か何か食べられる店があってお手軽便利なこと。

立ち食いそばもある意味ジャンクフードなんだけど、安いし早いし、そこまでカロリー気にしなくて良いし、去年旅行で東京行ったときは色んな所で食べたなぁ。あとカレー屋も駅ナカに多いのでけっこう巡ったりしたし。

福岡も駅などで食べるところはあるけど、立ち食いほどいつでも気楽に入れるところは無いかなぁ。まぁちゃんと店に入って座って食べるって感じで。時間もそんなに遅くまでは空いてなかったりするし、遅い時間で手軽に食べられるのは、博多駅の吉野家とホームにうどん屋とかラーメン屋があるくらいかな...。

たぶん、遅い時間に食べるならソバはラーメンよりかカロリーとか脂っこさを考えても良さそうなものだけどねぇ。あと個人的に東京のダシの味が意外に好みだってのもあるのかもなぁ。

東京に行くと、ソバとカレーばっかり食べてる気がする。

職場で「人が育った20年前」と 「育たなくなった今」は何が違うのか | なぜ職場で人が育たなくなったのか | ダイヤモンド・オンライン

筆者の雑誌社の昔話というケースがどれくらい他の業態に当てはまるかは別として、企業側で若手に時間を割いて構ってられないというのが一つあるのかなと思う。

逆に、新人教育なんかもシステマチックになってしまって、入社○ヶ月後にはビジネスメールを一通り書けること、みたいな「目標」ばかりが羅列されたカリキュラムをこなしていくだけ、のようなものだったり。その間を埋めるように先輩社員がいろいろアドバイスなどをできればいいんだろうけど、彼らは仕事が積まれてて相手にする余裕が無くなっていたり。

あとは中堅、若手が後輩にあんまり興味を持たなくなってきたというのもあるかもしれない。自分の事にしか興味が持てず、会社とか組織とかチームとか、他人が絡むものにあまり深入りしなくなってきたというのもあるのかも。自分のスキルアップに励めば、どの会社に属しているかは関係ないっていう考え方が広まってきたからだろうか。

いろいろ要因があるんだろうなぁ。若手側も自分がやっている職種に対してあまり思い入れが無いケースも多いし。とりあえず就職したって感じだとそこまでやる気も起きないだろうし...。まぁ普通に給料貰えればいいやって感じの人も増えたって事かな。

なんだか、色んなものが「淡泊」になりすぎてるんだと思う。

人間関係、仕事に対する考え方とかね...。新人も若手も中堅も。

高度成長期みたいにモーレツ社員になる必要は全くないし、昭和的「愛社精神」が良いとも思わないけど、組織がまとまらなくなってきてるのは間違いないのでは。

土日出勤の代わりとして、代休。

月曜の朝3時半くらいまでいろいろ作業して、まとめてからリリース。

正直なところ、品質は良くないと思う。外的要因、内的要因の両方で。

この週末で徹夜作業も一段落かと思いきや、今の品質向上と別の追加作業が発生しそうな予感。品質向上はやらなければならないが、追加作業はもう入る余地無いように思うんだけどね...。

でもたぶん請けるんだろうなぁ。そして気合いで頑張れとか言われるんだろうか。気合いもそうそうずっとは続きませんって。

作ってるモジュールの品質がなかなか上がらない。

直近で大きな改修を入れたせいもあるのだけど、その影響からか安定しつつあったところが再び不安定になったり。うまく行ってない。

そもそも正常系のシーケンスがきちんと流れなかったり、シーケンスが間違ってたり、準正常系のリカバリ処理が甘くてリカバリできてなかったり、組み込みソフトとして見た場合、全く弱い。

Android自体が少し大味なプラットフォームではあるものの、その上で作るソフトまで大味であって良いわけが無く、ユーザー操作、システムイベント、異常系にきちんと対応して作るべきで...。

これはちょっと安定品質になるまで時間がかかるかもしれないね...。

連日の徹夜続きでデスマ状態。

OSC2009 Fukuokaにも当たり前のように参加できず、TwitterのTLを見ながら悶々としていた一日。

日曜も出勤だし、ついてないね。

玄人志向、玄箱シリーズに手のひらサイズの小型LinuxBox開発キット「玄柴」 | パソコン | マイコミジャーナル

小型のLinuxデバイスが小さなブームになりそうね。日経Linux誌がけっこう頑張って特集組んでいたりするし。

まぁ、「玄柴」は限定50台で私がこのニュースを見たときにはすでに完売してたけど...。

Linuxが動くイコールAndroidも動くってことなので、Android移植していろいろ遊べそうな気がする。そのためにはこういうような筐体としてまとまってるデバイスは便利かもね。

こないだの日曜に書店に立ち寄って買ったもの。

Software Design (ソフトウェア デザイン) 2009年 12月号 [雑誌]
	技術評論社 2009-11-18 売り上げランキング : Amazonで詳しく見る by G-Tools

特集がLinuxカーネル。ちょうどAndroidでも深い所をやるとLinuxに行き着くので、まずは大枠の理解にはよさそうな特集。

徹夜勤務の待ち時間に読もうかと会社に置いてるけどまだ読めてない。

英語リーディング教本―基本からわかる
	研究社出版 2000-04 売り上げランキング : 341 おすすめ平均 徹底的に文法という標識に従って読む、自分の想像で読んではいけない 薬袋三部作　応用編 非常にクセが強い Amazonで詳しく見る by G-Tools

これは、はてダかどこかで紹介されてたもの。

中身はひたすら文法の解説書なので、ちょっと挫折するかもなぁと思いつつ購入。私の場合は英文は分かる単語をピックアップして前後の文脈も合わせて勘で訳して読むタイプ。単語力もぜんぜんだし、文法意識しても読まないし。

まぁでも現状のやりかただとレベルアップできないと思うので何か、単語力とか少しは強化したいところ。

Tiwtter経由で知ったのだけど、福岡でも始まったのか。

福岡でも入ったことない路地多いからちょっと興味あり。

↓は博多駅前。

大きな地図で見る

設計、開発の時点できちんとAPIとシーケンスについて詰められなかったというのが大きいんだと思うけど...。

遠隔地の開発部隊は「うちでは動作している」と言い、使用者のこちらが叩くと動かない。で、よくよく話しを聞くと、本物と少し違うシーケンスで動作確認していたり、API仕様書自体に誤りがあったり、とにかくこの辺の情報の疎通の悪さが今のプロジェクトが回らない原因のように思う。

どちらのチームもタイトなスケジュールの中、それなりの規模と難易度のものを作っているので仕様書やコミュニケーションまで手が回らなかったのも事実なので、誰かを責めるつもりはないのだけど、やっぱり提供者は使用者のことを考えて情報はなるべく、垂れ流しでもいいので出すべきだと思う。

作ってる側からすれば、中身を知っているので知らないうちに「言わなくてもわかるだろう」と思ってしまい、相手に必要な情報が抜け落ちることがよくある。でも相手からすれば、仕様書などの情報を見て作るしかないので、そこの情報が薄いと手戻りになる。

当事者側の「分かっている」は相手には「分かってない」。コミュニケーションロスのほとんどはこの「慣れ」から始まるんだと思う。