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

A Day In The Boy's Life

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

GWの前半戦、旅行に出かけていて4日ばかりネットに触れられない生活をしていたのですが、帰ってきてPC立ち上げて普段回っているようなサイトを巡回しようとしましたが、結構な未読の量があってちょっとうんざりしてしまいました。


普段であればたいした量と感じないのですが、それが積み重なるとちょっと一気にそれを処理する気にはなれなかったりします。

毎日1時間で見回っていたことを、帰ってきて一気に4時間かけてみると言うのはさすがにちょっと・・・と言う気分になります。


時間だけの問題でもなく、普段でも色々なサイトのRSSを購読してアンテナを広げてたりしますが、それでも全てに興味を持つわけではなく、その中から自分に興味がある記事をピックアップするという選別作業をしてたりします。

毎日1000件の情報の中から自分にとって有用であると感じる10件あるかないかの情報を選別する作業が、5000件近い中から50件を見つけようと言うのは少し骨が折れます。

例えそこに普段の5倍近く興味のあるものが含まれているとしても、母数が大きくなるとその探すと言う作業の労力を考えて少し億劫になったりするわけです。


旅行行くときもPCを持ち歩いておけばいいという考えもあるかもしれませんが、行く相手によってはその行為自体に不満をもたれることもあります。

例えば彼女と旅行に行ったとして、観光名所でPCを立ち上げてサイトをチェックするなんてことしてたらキレられるかもしれません。

会社の同僚と団体で旅行に行っている間、PCを立ち上げて1人でモニターを覗いてたらもう呼んでもらえないかもしれません。


なので思うことは、適度な諦めが必要なんだなとということです。

ネット上の情報を追いかけ続けることは、無限の作業を繰り返すことに等しい行為です。

1日にネットに上がる情報量に比べると、人間の1日の時間は果てしなく小さなものとなります。


大きな話題は、ネットの中でもしばらく余韻が残ることがあります。

派生して次の話題が持ち上がることもあります。

たとえ元ネタを見失ったとしても、その後に持ち上がる話題によってソースを追いかけることはできたりします。

なので、その辺はきっぱりあきらめて今を楽しむことに集中したほうがよいのだろうなと。


何か大きな話題があったのかもしれない、と旅行中にそわそわした気分になるかもしれません。

ですが、それを追いかけることは、旅行に行っている意味がありませんし、突き詰めるとなぜ旅行に行こうという事になったのか、快適な部屋でネットに興じておけばよかった、という問答をする羽目になります。


もしネットの世界にどっぷりつかりたいなら、極論としてリアルをあきらめるというのもあるかもしれません。

私自身、ネットもリアルもその境界線と言うのはなくって、ネットの中の活動も(例えばブログを書くとか、サイトを巡回するとかも)、「買い物に行く」とか「お茶する」っていうリアルの行動と並んで成り立つものだと思ったりしています。

なので、その選択肢もあながち間違いではないのかなという思いもあります。

それは、全て個人の優先度のつけ方によるのでしょうが。




Twitterユーザーの6割は加入1カ月で幽霊会員に――米Nielsen調査 @ ITmediaエンタープライズ


やらなくなる理由はきっと何が面白いのかわからないってところにあると思うのですが、自分がTwitterにはまった理由は、3つあって


1. 自分の頭の中で思っていることをそのままPOSTできる

2. 誰かの考えや行動がPOSTされるのが面白い

3. 情報の収集が便利


というところにあるかなと感じてます。



自分の頭の中の考えをそのままPOSTできる楽しみ


これはブログでできるじゃん、というのはもちろんその通りなんですが、わざわざ「眠い」だの「お昼ご飯何食べるか迷う」だの他人にとってどうでもいいことを書く気にはなれません。

Twitterの場合、その辺の敷居が思いっきり低く感じます。


ブログの場合、文字の制限がないと言うところで、何か表現が自由すぎる感じがするのですが、Twitterの場合は140文字と言う制限が、逆に都合よく感じることがあったりします。

つまりは、140文字という制限の中に濃密な情報を詰め込むことはそもそも無理だと言う前提があるので、気軽な情報でよいと言うような感じです。


そういうところから、頭の中で思っていることを簡単にPOSTできるってところにつながるのかなと。

逆に言えば、頭の中にあるようなどうでも良いことを簡単にPOSTしても良いツールと言えるかもしれません。

その辺りがすごく楽でわざわざブログに書かないようなことも、TwitterではついついPOSTしてしまいます。



誰かの考えや行動が見れる楽しみ


言ってしまえば少し趣味が悪いのかもしれませんが、誰かの行動を見るというのは結構面白いものです。

人間観察が趣味です、というのと同じような感覚がTwitterの中にはあるような気がします。


先ほど書いた、頭の中にある考えをそのままPOSTできるTwitterでは、その人をフォローすることでその人の頭の中や行動が簡単に見て取れます。

これは考えると少し怖いツールでもあるなと思うのですが、さして重要でもないことが多いので、あまり自分は気にもしていません。


他人に興味をもてないと言う人はTwitterはあまり面白く感じないかもしれません。

誰がどう考えていてもあまり関心がなく、自分の考えを淡々と述べたいならブログのほうが向いていると思います。


その辺りの心理的要因によって私はTwitterが面白いと感じたりします。

これは、フォローする人の数をそれなりに増やさないといけませんし、同じ興味を持つ人をフォローしておかなければなりません。

そういうところで、積極的な使い方と言うのも最初は求められてきます。

Twitterを始めただけでは、まずほとんど何もおきませんので、興味を持った人をどんどんフォローしていくと言う能動的な行動が必要になってきます。


その辺りを知らずに、または面倒と感じてしまうとなかなかTwitterの面白さも感じ取るのが難しいと思います。


ニュースソースとしてのTwitter


これは「Twitterのタイムラインはオリジナルのニュースソース 」の中で書いたようなことですが、何もTwitterの中でPOSTされるつぶやきは、なんでもないことばかりではありません。

何かの時事ネタを基にした発言もあったりしますので、その辺を追うことで話題のニュースをキャッチすることもできたりします。


ネットで祭りになるようなネタはTwitterでも祭りになっていることが多いです。

また、特定分野におけるニュースであっても、その分野に属している人によって情報を押し上げてくれたりします。

例えばプログラマーの人をフォローしておけば、新しいソフトウェアの情報やWebサービスなんかのネタを元にしてPOSTしてくれたりします。


企業がTwitterのアカウントを使っているケースもありますので、それをフォローすることでそこから発信される最新のニュースを追うこともできます。

また、ボットを登録しておくことで特定の役割を果たしてくれたりもします。

あるサイトに関する情報をまとめてPOSTしてくれたり、そのボットに向けて情報を投げかけると、結果を返してくれるボットなんかも存在します。


Twitterの面白いところは、フォローする人によってニュースソースが刻々と変化するところにあると思います。

ある情報についてTwitter上で追いかけたい場合は、その情報を熱心にPOSTしてくれる人を探してフォローしておけばよいでしょう。

なので、ある程度自分の興味のある範囲の人をフォローしていくことが楽しむコツなのかなと思ったりします。




あるシステムを保守しているAさんに、緊急で対応しなければならないことができたため、他システムの保守をお願いすることになりました。

そのことを聞いたXさんの反応は「ちょっと調べてやらないと難しいです」という後ろ向きな反応。


もともと2つのシステムは同じシステム基盤上で動いているため、技術的な差と言うのはほとんどありません。

違うのはそのシステムを使って行われている業務の内容とその仕様。

どうもそのシステム仕様やら業務仕様を理解するのは難しそうだから簡単に「はい」とは言いたくないというような雰囲気を出していました。



業務アプリが難しいと思う背景


情報システム部の残念な秘密 」に書いたように、社内システムの構築にはあまり先進的な技術要素を取り入れようと言う動きはありません。

より安定しているもの、より情報が豊富なもの、より保守が容易なもの、というようになるべく不安定となるリスクが取り除かれたものを採用しようとします。


ですので、システムの技術的要素が難解でそれを把握するのは素人では無理だ、というようなことはほとんどありません。

どちらかと言うと難しいのが業務仕様のほう。


※ もちろんソースコードがぐちゃぐちゃで読み解くのに時間がかかるというのはある話ですが


色々なシステム保守をしているエンジニアならよくある経験だと思いますが、自分が作ったものだと仕様もある程度、頭の中にありますし愛着もあるため進んでやろうと言う気分にもなりますが、他の人が作ったシステムとなると少し億劫になってきます。

何よりも過去にソースに触れたことがあると言う点において、ある一定の自信を持つことができます。

この仕様変更がどこまでの影響範囲があるかという技術的な要素だけでなく、その業務アプリの担当者の雰囲気から気軽に使用に関する話ができるレベルか、堅物で怖そうな人だからあまりそこでトラブルを起こしたくないという思いとか。


同等のシステム保守を行っているのであれば、他のシステムの保守も十分に対応できる能力を持っています。

ですが、その辺のことが頭をよぎって難しそうだという先入観を与えているような気がしました。



要は仕事の進め方


仕様を理解すると言うことだけであればそこまで難しくもありません。

仕様書を読んだり、担当者にヒアリングしたりしてある程度の基礎情報を集めることができます。

そして、システムの仕様変更を行うとしてもいきなり本番環境に適用するなんて無謀な保守をやるわけではないので、検証環境でテストを行うことで影響点の分析もできたりします。

なので、手順を追えば全然問題なく対応できるわけです。


業務アプリと一口に言っても大なり小なりありますので、中には本当にこれどれだけの人数で作ったの?というような大規模なシステムもあったりします。

ただ、そういった場合でもやり方は大して変わらなくって単にその中のタスクにかかる時間が大きくなるかどうかという問題だけになります。


自分の頼み方も悪かったのかもしれません。

矢継ぎ早に依頼事項だけを伝えて、「簡単にできるよね」という雰囲気を出しながら喋っていたという印象を受け取られたのかも。

エンジニアのタイプもそれぞれですから、技術的に長けている人であればソースさえ読めばどうとでも対応できると考えている人もいれば、保守的でなるべくリスクをとりたくないと考えている人もいます。

前者の中には、一人突っ走って改修を加えた要件が業務仕様とずれていた、なんて事を巻き起こす人もいます。

ただ、そうした場合でもそのことを伝えればすぐに対応してくれたりします。

後者の人の場合は、頭の中でやり方はわかっていても、いろんな不安要素も頭をめぐるのでなかなか安易に「できる」とはいえないのかなと。


そういうのを解消するために、多少の手間をかけても必要な情報を渡してあげて安心感を与えた上で取り組んでもらうようなマネジメントも必要になるんだなと感じました。