最近のワーキングスタイル

最近、19時頃、遅くとも20時前には会社を出て、喫茶店に寄って仕事して帰る（仕事がある日は）というワーキングスタイルを繰り返しています。

これは、気分を変える為にやってみたことがきっかけで、意外と効果があるので習慣になりつつあります。僕は元々、夕方まわるとちょっとおねむで頭回らなくなり、頭に靄がかかってどうしようもなくなる人なのですが、場所変えると気分が変わって集中力も復活することがわかったので。でも、これ、一つ難点があって。毎回喫茶店を使うから出費が結構イタイのです。あと、僕は無線LANサービスにhotspotを利用しているのですが、これが使える喫茶店が結構限定されていて、マンネリになりがちだという点も。

とまれ、場所を変えることはやはりメリハリが効いて気分もいいので、生産性も考慮したトータルの収支で考えればプラスかなと思っています。

あと、夜、遅くまで作業するか、朝、早起きして作業するかどちらかをやりたい、というかそれをしないと毎日与えれた作業をこなすだけになってしまうから。どうにかしたいのだけど、眠くて眠くて全くダメ。先々月のアツいプロジェクトで燃え尽きたのがまだ後を引いてるのかなぁ。まぁ、普通に考えて朝早起きがいいに決まってる。身体的にも。そのためには早く寝ないとね。わかっているんだけど、追い込まれるとついつい夜に頼ってしまうね。こういう頭の悪いループは止めないと。

さて、突然ですが連続更新も

今月一杯で一旦やめようかと思います。

というのも、最近、毎日書くことが目的になりすぎて、かな～り、おざなりな内容になってきていたので。
ちょっとインプットが足りなくなってきているみたいだし。

あと、このブログの方向性、少し考えた方がいいような気がしてきました。
これまでは、単に書きなぐるスペースがあればよいと思ってやってきましたけど。それも少しむなしくなってきたし。

PM、PL、開発プロセス、見積り、ここら辺のテーマだけを取り扱っていくようにしようかと思っているのですが、いかんせん、ここらを書くには毎日はきついのよね。インプットのペースが追いつかない（笑

SNS、BlogSphereに粋は共存できるのか？

江 弘毅さんの「街的」ということを読む。

街は店という点で始まり、点が集まり面になり、それがストリートになる。そこでは店は街の一部であり、また、街は店によって構成されるという相補的関係にあり、街と店とを切り離すことはできない。街にはストリートがある。つまり、店の外界に中心が構築される。

一方、SNS、BlogSphereはどうだろうか？SNS、BlogShereは確かに点としての機能を持っている。そして、それが集合してあたかも街のような情景を作り出してもいる。が、SNS、BlogSphereには街にはあってないものがある。それはストリートだ。SNS、BlogSphereには点の外界に中心がない。中心は常にユーザたる自分になる。それは各ユーザの個人的資質とは関係なく、構造的にそうなっている。SNS、BlogSphereにおいては、中心はマイページであり、自己のブログになる。そしてその空間は極めて自己を表現することに制限の少ない空間になる。外に中心を持たないということは、つまり、役割がないということにつながる。そして役割とは、個々の要素の行動、様式、思考に制限を与えるものであるから、役割がないということはむき出しの個が常に世界の中心として鎮座する状況であるということになる。

現実の街においては、各店舗は好むと好まざるとに関わらずストリートからの距離、その他もろもろの街自体の制限、特質、空気によってその店特有の環境にあてはまる役割を演じることになる。ストリートに面したブティックと、ストリートと住宅街の中間に位置する赤ちょうちんとでは必然的に役割は異なってくるし、それを好む好まざるに関係なくその状況は受け入れざるを得ない。だが、SNS、BlogSphereにおいては、そうした状況によって与えられる役割というものは構造上存在しない。自己の外界に中心を持たない以上、ストリートを持たない以上、これは必然的に導かれる結果になる。SNSで言えば、自分のお気に入りのユーザのページにアクセスする際に、わざわざ大通りに出て、小道も経由して、そのユーザにたどりつく必要はない。友達に加えるなり、お気に入りに登録すれば直接アクセスが可能になる。これは、便利だ。だが、その便利さの代償として失っているものがあるように思うことがある。

さて、粋とはなんだろうか？残念ながら、その実定的な定義を表現することは難しい。けれど、必要条件の一つは挙げることができる。それは、我慢（多くの場合やせ我慢）によって担保されているということだ。やりたいけどしない。できるけどしない。言いたいけど言わない。欲しいけど欲しがらない。勝ちたいけど勝ちにこだわらない。そうした、我慢、やせ我慢、つまり、がっつかないことが粋であることの必要条件としてあることは概ね共感していただけるのではないだろうか。どんなに心の内では煩悩の炎に心をやかれていても、やせ我慢で乗り切る、あっさりさっぱりと割りきってみせる。それが粋とイコールというわけではないが、少なくとも必要とされる態度の一つであるように思う。そして、このことが示すことは粋であることとは自分の役割を意識して受け入れるということと切り離しては考えられないということだ。自分の行動を制限する何かしらの外的な規制、例えそれが当人の幻想に過ぎないとしても、そうした規制があること。本人がそう思い込むこと。役割があること。自分の外界に中心があり、自分はその外界の一要素であると同時に、外界なくして自己は存在しえないという意識があること。つまり、ストリートを意識する自己のあり方、それが粋を担保している。そう思う。

従って、自己を中心として放射状に世界を捉えるSNS、BlogSphereにおいて、粋とは非常に存在しづらいものではないだろうかと思う。相容れないとも言ってもいいかもしれない。SNS、BlogSphereは簡単に他者と繋がることができる。それはストリートが存在せず、点としての自己の役割を意識しづらい構造になっている。粋であることが正しいなどというつもりはない。が、自分は粋にあこがれる人間だ。役割を受け入れ、制限の中で個を表現していく生き方にあこがれる。そして、SNS、BlogSphereの奔放さにも親しむ人間でもある。そうした人間にとって、SNS、BlogSphereがどのよにしてストリートを表現し得るか、街になり得るかを考えることは面白いテーマになる。

現状で言えば、SNS、BlogSphereは全く街的ではなく、粋ではない。マイページ、または自分のブログという非常にパーソナルな空間でスタートしていることがいけないのかもしれない。全ての情報がオープンになり、繋がっていく2.0時代に時代錯誤も甚だしい考えだとは思うのだけれど。

最初から作り直したい症候群

過去に学ばず新しい方法論にやみくもに飛び付くのは、最初から作り直したい病と同じです。

結果として最初から作り直すこととなり、それがよい結果になることはままあります。が、どうにもうまく行かなくなってこれまでの反省、知見をもってやり直すのではなく、まだ失敗して学ぶべきをまなんでもいないのに、漠然とこれまでより良くするための手法としてのやり直しは十中八九失敗します。前にも少し書きましたが、万事一度は失敗することになるのですからこの結果は必然です。失敗しないためのやり直しは必ず失敗を招きます。

直ぐに新しい手法に飛びつくのは、これまでの手法できっちり失敗してきていない可能性が高いためやり直し症候群と同じ末路をたどります。新手法も失敗しないために採用してはいけないのです

仕事法や時間管理法に関する素朴な疑問

自己啓発系、ビジネス系の書籍に散見される、仕事法や時間管理法に関する素朴な疑問です。

どうしてこの手の本は出版され続けるんでしょうか？

効果があるなら一冊あれば充分のはず・・・だよね。

電源落ちた

喫茶店で仕事してたら思いのほか長くかかって、途中で電源落ちました・・orz

幸い、オートセーブのエディタを使っていたので問題はなかったんですけど、やっぱり急に落ちるとびびるよね。

ところで、別居決定しました^^;
まぁ、しょうがないです。

おじさんとお義母さんの回復を祈るばかりです。

ネタがない・・・

最近、業務絡みの本も、哲学、社会思想の本も、歴史の本も読まずに、横溝正史ばかり読んでいるので、夜この時間になってＰＣに向かっても何も更新のネタがない事態になってます。

ミステリーでは教養とか、知見を得られないということではなく、横溝正史は読んでみたところかなりおもしろくて、集中して読んでいたいがために、途中で脳裏に浮かぶよしなしごとは無視しちゃってるんですよね^^;
たぶん、読み返しをするから、２度目、３度目になったらメモったりするだろうけど、初回はね、そんな野暮なことしたくない。最高の贅沢だなぁ、これは。理解できない人多いと思うけどね

さてさて、でもネタがないことをネタにしたわけだから、いい加減、メモ癖復活させないとね。業務がらみの本もよまんと。明日、読みまくるか。

見積り１，２，３

最近の僕の見積りの手順を記します。
特に目新しいことはありませんが、もしかしたら役に立つ人もいるかもということで。

１．ヒアリングの議事録、メモ、資料などを元に、要求、懸案、注意点を中心にマインドマップに落とし込む。精度、粒度にはあまり拘らず、スピーディーに行う。
２．１で作ったマインドマップから要求を整理する。平行して、懸案を抽出して整理する。
３．要求仕様にかかわる懸案は（許される状況であれば）即時、顧客や営業・企画担当に問い合わせておく
４．要求から、要求仕様を導出する（先方が要求仕様を出してきている場合も、大抵その精度、粒度は不充分なので、精査して整理しなおす）。この際、３で問い合わせ中の懸案の回答によって要求仕様が影響を受ける箇所には※などで注釈をつけておき、回答を得次第修正を施せるようにしておく。
５．３の回答が返ってきたら、その回答をもとに要求仕様を修正し、顧客に要求仕様のレビューを依頼する。ただし、スケジュール優先の場合は３の回答を待たずに４の段階で想定仕様でレビューを依頼してしまう。
６．要求仕様がある程度固まったら、仕様単位にタスクを洗い出す
７．紙上に円を書き、円を３分割して、それぞれにM、V、Cと書く。M、V、CはModel、View、Controlの略で、データ操作系のタスクがM、表示系のタスクがV、画面遷移や制御構造関係のタスクがCに配置される。
８．７の円上に６で導出したタスクを配置してゆく。各タスクはM、V、C領域にまたがってもかまわない
９．８の結果からタスク間にまたがる共通タスクを導出してゆく。
１０．全タスクをリストして、各タスクに関してサイズを見積もる
１１．１０で導出した開発工数（サイズ見積り）に対して、ある比率で設計、検査、デバッグ工数を導出する。案件の特性にあわせて多少重み付けをして調節する。比率は組織の体制、選択するプロセスによって異なるが、開発工数が全体の1/2を上回ることは決して起こりえないことに注意する。
１２．案件によっては、サーバ構築費、ホスティング費、運用費、ドキュメント工数（マニュアル等）を追加する。死活監視等が必要な場合もあるので留意する。
１３．（可能であれば）社内の他スタッフにレビューしてもらう。人に説明するだけでも結構違う。

こんな感じ。日々、調整してます。

不幸は重なる

９月から夫婦別居になりそうです。

いや、喧嘩したわけではなく^^;

カミサンのおじさんが倒れ、お義母さんが入院、おじさんの面倒を診るためにお義父さんが遠方のおじさんの所へ詰める、そしてカミサンの実家には猫様がいるので、カミサン実家住まい・・・・ね？（ん？）

なんつ～か、自分が入院した時もそうだったけど、重なるねぇ、不幸ってのは、ほんとに。コンボですよ、コンボ。たたみかけてくるんだよね。ほんと。

まぁ、こういうの慣れているんであまり驚きませんけど、別居は悲しい^^;

脱・できない点取り虫

できないくせに分不相応に評価されようとする。
基本的なコトもできていないのに凄いコトをしようとして失敗する。
今まで散々っぱら間違えてきているのに間違うことを恐れて行動しない。

こういうできない点取り虫の根性が自分を苦しめていることに気づいた。

「間違っちゃいけない」なんていうケチな考え方を捨てる。
身の丈にあった目標と、現実的な計画をたてる。
人の批判を受け入れて、シリアスにならない。
できない自分から出発する。

うし、やるぞ。