A Day In The Boy's Life -111ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

バルス祭りに見るネットとテレビのこれからの関係 @ 未来私考


これ、よくわかる。

Twitterに限らずネットって共有する空間が必要なんだなって。

ネットがその共有する空間を埋めるものと考えられてたりもしますけど、まだそういう風な使い方をできるのは限定的なところなんだな、と感じたりします。



のっかる感覚


今の子供たちはどうかわかりませんが、私の小学生や中学生の頃は、面白いテレビ番組があったら必ず「あれみた?」というところから、会話が進んで言ったりもしました。

見なかったらその会話についていけない、でも見てたら勝ち組みたいな。


それは、単に同じ空間を共有したという仲間意識を働かせたいだけなのかもしれませんが、コミュニケーションの根底にあるのって、そういう共有できる情報を持ち合うところにあるのかなと思ったりもします。

大人になって同じ仲間みたいなところは意識しなくとも、同じ情報を持ってた方が会話も弾みます。

共有の話題があって、自分の視点をそこに重ねていく、重ねられていく感覚が楽しいのかなと。


Twitterで、一言POSTがRTによって別の人の一言ネタに重ねられていくのも、そこへのっかることで参加している感覚の楽しさがあるからじゃないかなと。

同時多発的なPOSTをするのも、そこに参加している楽しさを感じているからなんでしょう。

カウントダウンイベントなんかでみんな一斉に声をそろえて数えるみたいな。

そこにいる全員が空間を共有しているという一体感はなんともいえない楽しさがあります。


幾らネットがリアルタイムになろうとも、そのコンテンツを消費する時間帯を揃えることは難しいですし、その消費している人を見せることも難しかったりします。

Twitterのよさは、そのリアルのような一斉に馬鹿騒ぎするという空間を作ったうえに、可視化できているところにあったりするなと思います。



ネタが必要でみんな飢えている


Twitterで幾ら空間が共有できるようになったとはいえ、肝心のネタが無くては何にもなりませんよね。

自分の日常から搾り出すこともできますが、そうそうみんなでわーと騒げるようなものって簡単に見つかったりもしません。

自分で興味を持ったネット上のコンテンツを紹介したところで、見る人が数人でしかも反応が返ってくるとなるとより稀だったりもします。

それだと、空間を共有しているという感覚はかなり弱かったり。


で、ネット以外で一番簡単に、みんなが同時に見ているものということで、テレビが登場したりします。
これは、テレビのいいところでも悪いところでもあると思うのですが、全国に同じ情報を同じ時間に垂れ流しにできるところにあります。(地域によって異なる場合も多いですが)

Twitterのつぶやきの中でもテレビネタというのは結構多い部類ではないかなと思います。

日曜の夕方になると、笑点やサザエさんがバズってますし、リアルに人が見えるツールですから、その人の行動とPOSTが連動していることが目に見えたりもします。

テレビってネット違って見る時間帯を揃えていることと、幅広い年齢層でも理解できるようにかなりわかりやすく作ってます。

なので、ネット上にあるコンテンツに比べて受け取る情報の個人差も少ないのではないかなと。


こういうと何なんですが、ネタにするためのネタを探してたりするところもあるんじゃないかなと。

なので、テレビは死んだみたいな議論もあったりしますが、テレビが無くなったら無くなったで困る人も多いんでしょうね。

ネタとなるためにテレビ頑張れ、なんて言いませんがお茶の間の空間を取り戻すというようなことを言うぐらいなら、お茶の間にあった空間を別の場所に作る取り組みも良いんじゃないかなと思います。

それって、お茶の間どころの規模じゃないと思うんですがね。

Twitterの中の人は、そんな空間を共有できるネタというのを常に心待ちにしている気がします。



Tracを使い始めて2年近くなりますが、バグトラックとしての使い道以外に、タスク管理の観点からTracの利用を推奨する記事もちらほら見かけたります。

実際に利用していると、タスク管理で使った方が便利であることも多かったりします。

または、ナレッジ管理のような側面で使うのもありかなとか。



保守・運用の中で使うTrac


開発の現場においては、構築する機能やモジュール単位、テストフェーズでのバグの報告とその対応などに使われたりもしますが、開発後の保守・運用のフェーズに入ると業務の内容ががらっと変わるために、そういう使い方もあまりしなくなります。


構築というよりは、機能の改善や運用の中で見つかった不具合への対応などが中心になってきますので、必然的にその要望や対応時のタスクの管理というものが色濃くなったりします。

後述しますが、保守・運用の中で業務の役割も違ってくるので、チケットの粒度もまた違ってくることにもなったりします。

開発メンバーであれば、システムの詳細な仕様について書いてくる人もいれば、ヘルプデスクチームからはユーザーからの要望や問い合わせなどがチケットにあがることもあるでしょう。


で、そのタスク管理の側面を延長していくと、今度はナレッジ管理の観点が生まれてきたりします。

一つのチケットとタスクがイコールになると、そのタスクを完了したプロセスがその中に含まれてきますので、その後に似たようなタスクが発生したときに参照することで業務の効率化ができたり

保守・運用フェーズに入ってくると、そういう似たようなタスクというものが繰り返し出てくることがありますからね。

マスタとなる詳細な手順を書いたチケットをそこにリンクしておけば、他の要員でも対応がやりやすくなったりもするわけです。


チケットの粒度がそれぞればらばらになってくるということを気にする人もいたりしますが、あまりそこは気にしなくても良いような気がします。

先に書いたことをまとめると、Tracの役割は大きく2つあると思ってて、


1. 対応ステータスと対応者を明確にする(タスク管理)

2. 対応時のプロセスを後で参照可能にする(ナレッジ管理)


というところにあるので、それが管理できていれば問題ないのではないのかなと。


それぞれのタスクやナレッジ管理の観点でチケットの粒度がそろわないこともあるでしょう。

バグのトラックでも、改善の要望でも、ユーザーからの問い合わせでも、最終的にはそれを何らかの対応を決定しなくてはならないわけで(対応しないという決定も含めて)、あまり細かく管理するとタスクの管理が煩雑になり、ざっくり管理しすぎるとプロセスが見えにくくなったり、細かなタスクを見落とす危険性もあったりしてきます。


チケットは関連性を持たせやすいので、担当チームで分解して対応するというのも良いでしょうしね。



どういう単位でプロジェクトやマイルストンを分けるかは結構重要


チケットの粒度以上に気を使うのが、マイルストンの扱いだったりします。


開発から保守・運用のフェーズまで、システムのライフサイクルで業務を行うのであれば、1つのプロジェクトの中でマイルストンを切ってやっていくことができます。

マイルストンのきり方は何も、開発・保守・運用などの区切りでなくとも、開発のフェーズで分けたり、ウォータフォール的に「要件定義」や「設計」などの分け方でも良いかと思います。


ただ、保守・運用になってくるとそういうマイルストンの区切りが付けにくくなったりします。

保守・運用という業務は、そのシステムのライフサイクルが終焉を迎えるまで永続的に続くものですからね。


なので、どちらかというと業務的な観点でマイルストンをきっていった方が良いかなと感じたりしています。

機能改善対応や監視業務の中で発見した不具合や報告、ヘルプデスクによるユーザー側からの問い合わせなど、各々の業務やチームで切ってタスクをそれぞれに登録していくというようなやり方です。

こうすることで、それぞれの業務の中でどれだけのタスクが発生していて、進捗はどうなっているのかということが見やすくなったりします。


プロジェクトに関しては、システムの単位や、根本的にそのシステムの保守・運用業務とは異なるところで使いたいという場合に分けることがあります。

Aシステム用のプロジェクト、Bシステムのプロジェクトといった具合や、チームごとにタスク管理に課題管理などをしたいというような場合です。


ただ、Tracでプロジェクトを分けてしまうと、DBも分かれてしまうのでプロジェクトの横断的な情報の検索というものができなくなります。

タスク管理の観点では、AシステムのタスクとBシステムでのタスクは分かれるでしょうから、あまり問題にならない(似たようなタスクでも別々にチケットを作ってしまえばよい)ですが、ナレッジ管理の観点からは参照したい情報がばらばらになってしまうと、管理しづらくなることがあります。

あのタスク、過去にやったことあるけど、どのシステムでやったんだっけな・・・、みたいな。


また、課題管理もそのチーム内でクローズするようなことであればいいですが、他のチームと共有する必要があったり、その課題を昇華して保守・運用の業務と絡めたチケットに関連性を持たせようとすると、管理が面倒になるので、そのプロジェクトの中のマイルストンとして設定した方が良い場合もあると思います。

(こうすると逆に課題全体を管理しづらくなりますが)



まとめ


保守・運用の業務が多いことから、その観点から書いて見ましたが、開発するにしろTracを使う場合は、それを使う人がTracの存在を強く意識しておかなくてはならなくなります。

後でチケットをあげればいいやと、先にタスクに取り掛かるとそのステータスが見えなかったり、面倒になってプロセスが省略されたり、そもそも登録し忘れたり、ということになると意味を成さなくなってきます。


チケット駆動開発なんて言葉もありますけど、それは自分のやるタスクをわかりやすくするということだけでなく、他人に何をやっているのか示したり、後人のために対応方法を示しておこうという意識も必要になってくるんだなと思います。




だいぶ古いコマンドみたいなんですが、結構便利なので。


ngrepは、サーバーに対して通信した情報をわかりやすくキャプチャしてくれるコマンドです。

こういうのって、クライアントサイドで可視化してくれるツールはあったりもしますが(FireBugとか)、サーバーサイドで動かした方が便利であったり、取れない情報もあったりしますので、場合によってはかなり便利に使えると思います。


見え方はこんな感じ。


T 192.168.0.1:80 -> 192.168.0.2:1978 [A]
HTTP/1.1 200 OK.
Date: Wed, 18 Nov 2009 15:34:44 GMT.
Server: Apache/2.2.3 (CentOS).
Last-Modified: Tue, 26 Aug 2008 15:20:20 GMT.
ETag: "3954c06-4486-711f3500".
Accept-Ranges: bytes.
Content-Length: 17542.
Connection: close.
Content-Type: text/plain.
.

HTTPの通信に限らず、色んなパケットをキャプチャできます。



ngrepのインストール


まずは、ソースをダウンロード し、サーバー内で展開します。

後は、お決まりの呪文でとりあえずいけるかと。

私の環境では、関連するライブラリが不足していたため、configureでエラーがでましたが、それをインストールすることで回避できました。(後述のおまけ参照)


# tar -jxvf ngrep-1.45.tar.bz2

# ./configure

# make

# make install


ngrepを使ってみる


幾つかオプションがありますが、基本的な使い方は下記のような感じになります。


# ngrep -W byline 'HTTP' -q

行単位で出力するようにし(-W bylineオプション)、キャプチャしたパケットの中身をみてHTTPのものだけを表示し('HTTP'で指定)、関係ないものを表示しなく(-qオプション)しています。


この他にも


# ngrep -W byline -q port 80

とすることで、80番ポートの通信だけを見てみたり、


# ngrep -W byline 'HTTP' -q -d eth0

とすることで、eth0のNICの通信だけを対象にして見てみたりすることもできます。


また、POSTしてきた内容を見ることもできますので、デバッグしてみたりという用途にも便利です。

例えば、テキストボックスからデータを送信したときのパケットをキャプチャしてみると、


T 192.168.0.2:2458 -> 192.168.0.1:80 [AP]
GET /hoge/form.html HTTP/1.1.
Host: 192.168.0.1.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729).
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.
Accept-Language: ja,en-us;q=0.7,en;q=0.3.
Accept-Encoding: gzip,deflate.
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
If-Modified-Since: Wed, 18 Nov 2009 15:33:50 GMT.
If-None-Match: "1e7c008-93-f8263380".
.

T 192.168.0.2:2460 -> 192.168.0.1:80 [AP]
POST /hoge/post.php HTTP/1.1.
Host: 192.168.0.1.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729).
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.
Accept-Language: ja,en-us;q=0.7,en;q=0.3.
Accept-Encoding: gzip,deflate.
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
Referer: http://192.168.0.1/hoge/form.html.
Content-Type
: application/x-www-form-urlencoded.
Content-Length: 51.
.
form1=%E3%81%BB%E3%81%92%E3%81%BB%E3%81%92%EF%BD%9E

T 192.168.0.1:80 -> 192.168.0.2:2460 [AP]
HTTP/1.1 200 OK.
Date: Wed, 18 Nov 2009 15:58:27 GMT.
Server: Apache/2.2.3 (CentOS).
X-Powered-By: PHP/5.1.6.
Content-Length: 15.
Connection: close.
Content-Type: text/html.
.


というような通信内容が見れます。(POSTした内容はエンコードされてますけどね)


おまけ - インストール時のエラーの対処 -


configure時に、下記のようなエラーが出ました。


# ./configure
-snip-
checking for a broken redhat glibc udphdr declaration... no
checking for a complete set of pcap headers... no
!!! couldn't find a complete set of pcap headers

原因は、下記の関連するライブラリが無かったためで、yumでインストールし再度configureしなおしてみると上手くいきました。


libpcap
libpcap-devel