ビジュアル・コンプレキシティのChapter3を読んでおくといろいろ捗るかも、というはなし。

2月 2, 2014

マニュエル・リマ氏が来日するのですこしでも活かすため事前勉強会を開催した。
この勉強会で、「ビジュアル・コンプレキシティについて理解するには、『ビジュアル・コンプレキシティ』のChapter3にはネットワーク・ビジュアライゼーションについて読むと良いんじゃないか」とアドバイスをいただいたので、再読をした。

たしかに、Chapter3には、

  • 関連する手法と技術
  • 5つの機能
  • 実現するための8つの原則

がまとってまっていて、とくに8つの原則は実践的な内容なので、「どうやって活かすの?」という疑問を持つ人にはおすすめの内容だ。

しっかり読んでも1時間程度なので、読んでおくとビジュアル・コンプレキシティに通底している、ネットワーク・ビジュアライゼーションについて整理することができる。
詳しい内容は本を読むのが一番なので、ざっと要点を引用して紹介する。

関連する手法と技術

ネットワーク・ビジュアライゼーションはさらに大きなくくりとしてネットワーク表現の領域に収まり、研究されている。
そして、ネットワーク表現はおおきくネットワーク・ビジュアライゼーションのほかに、グラフの描写について研究されている。
ネットワーク・ビジュアライゼーションにはグラフ理論、コンピュータグラフィックス、地図製作法が大きな影響を及ぼした。

今日のネットワーク表現は、一般に(グラフ理論に則した)グラフの描写と(情報の可視化に則した)ネットワーク・ビジュアライゼーションの2つの領域で研究が行われている。
p.79

ネットワーク・ビジュアライゼーションに大きく影響を与えたものには、グラフ理論と近年のコンピュータグラフィックの成果のほかに、地図製作ある。(原文ママ)
p.79

ネットワーク・ビジュアライゼーションがもつ5つの機能

ネットワーク・ビジュアライゼーションは、5つの機能を備えることにより、人々との知的好奇心を刺激し、ビジュアルを通じて情報の処理や理解をたすけ、発見を導くことができる。
またビジュアルが新たな研究へ展開するきっかけとして作用することをも期待されている。

では、ネットワーク・ビジュアライゼーション固有の目的は何なのか? 複雑なものの表現は、以下の「記録」「明確化」「表面化」「拡張」「抽象化」という主要な5つの機能によって実現される。
p.80

ネットワーク・ビジュアライゼーションを実践するための8つの原則

8つ原則はいかのとおり。
事前の勉強会でも「そもそもビジュアライゼーションをするプロセスが謎だよね。」などと話していたのだけど、しっかりヒントは本に載っていたのだった。

  1. 質問から開始する
  2. 関連性を探す
  3. 多変量解析を可能にする
  4. 時間を含める
  5. 語彙を豊かにする
  6. グループ分けを顕在化する
  7. 拡大縮小を活用する
  8. 複雑さを管理する

インフォグラフィックは、作成者が説明したいことを閲覧者の理解してもらうのが目的で作られる。
なので、「この図ではこういうことが表現したい」という、作成者の目的が定まっている、という前提がある。

しかし、ビジュアル・コンプレキシティの中で紹介される図は、動的なインタラクションができないためか、「なにを表現したいのだろう」と思わせる図が多い。
そのため、図を作成するときの目的が、「単純に見た目の美しさ、視覚的な快が目的なのか」「なにか発見があったらいいな、という漠然とした目的なのか」という疑問を抱かされる。
とくに、見た目が幻想的な図は、作成意図もまた神秘のヴェールに包まれて徐々にはっきりしてくる、というプロセスをたどるのか、という疑問があった。

上記の8つの原則を見ると、やはり図を作成には目的ありき、であることがわかる。

以上、ざっとChaper3を読んだ結果を引用を含めてまとめた。

最終的に「ネットワーク・ビジュアライゼーションとビジュアル・コンプレキシティの違いってなんだろう?」というのが新たな疑問がうまれた。
また、図を見て発見がある、という経験をすることがあるけど、作成者が故意に閲覧者に発見を促すことは可能だろうか。
ようるすに「発見」を促すためのネットワーク・ビジュアライゼーションの開発のプロセスというのは存在するのか、またそのプロセスというのはどういうものなのか、が疑問としてのこった。

ふりかえりのふりかえり

1月 26, 2014

昨年末、会社自体のふりかえりを会社のメンバー全員(6名)で、ちょっとぼやかした感じのKPTを取り入れて、1年分の

  • 良かったこと・維持したいこと
  • 悪かったこと・やめたいこと
  • チャレンジしたいこと・やりたいこと

の洗いだしと総括をおこなった。
ちなみに1年分だったの4時間程度の時間がかかった。

ふりかえりという名称でこうしたことを行うメンバーもいたのだけど、概ね好評で、
「こんどは、もっと短い時間で頻繁にやりたい」という意見ももらった。

この意見を聴けたので、ふりかえりは有意義であったのだとかんがえているのだけど、自分なりの反省点もあるので書いておきたい。
書いてみたら、いわゆる言い尽くされた注意点なので、基本は大事、ということだったりする。

付箋は強粘着を使おう

壁に貼った付箋が、ハラハラと落ちてくると、議論がとまる。
落ちた付箋を壁にはるのは、ふりかえりにおけるムダな時間の1つだ。

今回、参加したメンバーには、

  • 良かったこと・維持したいこと
  • 悪かったこと・やめたいこと
  • チャレンジしたいこと・やりたいこと

を付箋に書いて1人、1人発表してもらった。

今回は、100円ショップで売っている付箋を利用した。
100円ショップの付箋でも、テーブルをつかってやるのなら問題はないが、壁に貼り付けながら行うと粘着力のなさが問題になる。
1番最初に発表した人の付箋は、5,6人目の人が発表している際に粘着力がなくなり、ハラハラと落ちはじめる。

せっかくたくさんの時間をふりかえりに利用するのだから、付箋を貼りなおす時間など貴重な時間を利用してはいけない。
強粘着の付箋はたしかに高いが、見返りは十分にある。

お手本を用意しておこう

とくに付箋の書き方、まとめ方、については、事前に説明をしておくと議論がやりやすので、付箋の書き方についてお手本があると良い。
付箋を使う目的は2つある。
1つは自分の思いついた意見を端的にまとめる、という自分のメモにすること。
もう1つは自分の意見を端的に他の参加メンバーに伝える、という他の人への説明書きにすること。

どんな人でも自分のメモとして付箋を利用することに戸惑う人はいない。
また、自分の意見のメモとして記憶を保管する目的なのだから、利用方法を間違えることはない。

しかし、付箋はその後、意見を発散・収束するためにも利用するので、他の人が読んで意味が伝わるものであることが必要だ。
この方法は、あらためて参加者にお願いしておかないと無視されがちだし、実際、どのように書いたら良いか、という疑問もでてくる。

自分が慣れているとそのつど説明してしまえばいいや、と端折りたくなる部分なのだけど、最初にちょっと手間をかけえておくと、議論も意見の整理にも便利な付箋ができあがり流れによどみがなくなる。

もちろん、参加メンバーが付箋やKPTのような方法に慣れていれば、この項目は不要だ。

こまめにやろう

これが最大の反省点で、ふりかえりは年に1度などと言わずこまめにやる。
ふりかえりは、自分の仕事の仕方や他の人の仕事の仕方、会社のビジネスの状況や顧客の状況など、自らの行動を見直す時間を作ることだ。
そして、行動を見直すことにより発見や反省を行って学習を深める時間だ。

学習の時間はなるべく多く、そして、機会は頻繁であるほうが望ましい。
状況は1週間もすれば変化しているし、変化にはなるべく早く対応したい。

毎日やるか、1週間毎にやるか、毎月やるか、開催頻度は、それぞれが置かれている状況によるだろう。
ふりかえりを行うと約1時間から2時間×人数分の時間がかかる。

この時間を投資して得るものがあるか否か、ここはメンバーをふくめて考えると良いだろう。

ちなみに、毎日ふりかえりを実施したらこれは有用だろうか。
こう聞かれたらぼくは、「有用だ」と答える。
とくに設立したての企業では、仕事や現状にたいするメンバーの考え方や気持ち、状況についてよく知ることができるからだ。
ただ、会議室を用意して、付箋に書き込んで、という方法は時間を取り過ぎるので、別の方法をとるほうが良い。

ぼくは、個人的に手帳を使って簡単にやっている。

おまけ

ちなみに事前に下記のようなメールをおくった。
送ったことでメンバーに良い効果があったかは定かではないが、自分自身の考えが明確になる。

明日のふりかえりについて、遅くなりましたが目的やプログラムの共有を致します。

みなさまには、今年を総括するにあたり、みなさまには下記について準備、ご協力をお願い致します。
・自分がなおしたい!とおもう問題を整理して持ち寄る
・自分がやってみたい!とおもう課題を整理して持ち寄る
・手軽にとれる食事やお菓子
普段はづらいことなどもあるかと思いますが、
あたらめて意見を集める場として、積極的に意見をいただけますと、うれしいです。

目的:
ミッションと方向性を再確認する
会社の良い所と悪い所を共有する
来月からできることをはっきりさせる

アウトプット:
来月からやることリスト

スケジュール:
13:00 – 13:10 開始の挨拶
13:00 – 13:50 あらためて会社のヴィジョンを考える
休憩
14:00 – 14:50 良かったこと、維持したいことの総括
休憩
15:00 – 15:50 悪かったこと、やめたいことの総括
休憩
16:00 – 16:50 チャレンジしたいこと、やりたいことの総括
16:50 – 17:00 終了の挨拶

2013年に印象に残った言葉への解釈

12月 31, 2013

逸脱せよ

自分にとって重要な考え、思い、感情を周囲の環境に埋没させていはいけない。
常識や習慣に考えや思いを委ねすぎてはいけない。

自分にとって大切なことは、他者にとって大切なこととは限らない。
自分が気づいていることに、他者が気づいていることは限らない。

自分の中に芽生えた考えや思いを大切にできるのは、自分だけだ。
自分の考えや思いを周囲に伝えるのは、自分の行動だけだ。

周囲との摩擦やずれを恐れてすぎてはいけない。
自分が考えや思いが大切で価値があると信じることであるなら、一時的な対立を肯定しよう。

そして、対立を克服し、協調にいたる努力をしよう。

成果を追求しろ

報酬は努力や才能にたいしては支払われない。
報酬は、努力や才能をつうじて生み出された成果にたいしてのみ払われる。

よいコードはユーザーに価値をもたらすコードであり、自分たちに利益をもたらすコードだ。
よいプロダクトはユーザーに価値をもたらし、自分たちに利益をもたらすプロダクトだ。

成果は会社の利益として現れ、報酬はその利益に従って得られる。

だからこそ、才能豊かで正しい努力ができる人間は、利益を公平に分配される組織に身をおく事を考える。
だからこそ、才能豊かで正しい努力ができる人間には正当な報酬を支払うことが必要だ。

管理されるな。管理しろ

もっともくだらないことは働く姿勢について、咎められることだ。
もっとも面倒なこと自分が取り組むべきことについて、人から指図されることだ。

今日、この1ヶ月、今年、何をすべきでどのように行うべきか、知っているのは自分だ。

ひとりよがりの行いで人に迷惑をかけたり、人を傷つけたりしたら謝って行動を改めれば良い。
それでも同じことについて文句をいったり、からかってくるやつがいたら放っておこう。

自分ですべきことは自分で決め、実行する。
それが、自由であるということだ。

学び、実践しろ。そして、実践に学べ

新しいことを学ぶことの楽しみを大切にしよう。

日々に追われると、学ぶことをおろそかにしがちだ。
未知の問題に対処する知恵や工夫は、対象の問題から離れた学びから生み出される。

また、学びを活かした実践は学びをさらに深めてくれる。
なにより、実践から得られる学びもある。
実践における失敗やユーザーや周囲の意見は学びの源泉になる。

失敗は小さく

失敗はしても良い。
しかし、取り返しの付かない大きな失敗はしてはいけない。
小さな失敗で多くを学ぶことが賢い態度だ。

たくさん失敗ができる、というのは、それだけ挑戦する機会があるということだ。

失敗をしても周囲の人は咎め立てはしないし、慰めの言葉をかけてくれる。

しかし、その失敗から立ち直り、新たな一歩を踏み出すのは自分でしかできない。

自力で立ち直れない失敗つながる大博打を打ってならない。
自分で立ち直れるように小さく試して小さく失敗しよう。

蛮勇と勇気を混同してはいけない。
勇気は、無謀と臆病の中庸に存在する。

必要なことはすべてやりきれ

必要なことをやりきるために、まずはやるべきことを徹底的に減らせ。
やるべきことには、優先順位をつけ、期日を決め、やりきる。

なにより、自分でできることに集中にしろ。
自分が影響を及ぼすことのできないことについて悩むのは時間の無駄だ。

大抵のことは自分一人ではできないが、できないことがあったら、他の人に助けを求めて巻き込もう。
それは、自分でやって来たことがどれだけ他の人たちに貢献してきたのか、がわかる良い機会だ。

現場と現場をつなぐ現場

11月 11, 2013

このエントリーは『DevLOVE Advent Calendar 2013 「現場」』の3日目の記事です。
(更新日付は11日になっておりますが、12日の0時に更新しております。。。)

自己紹介
oppy(おっぴー、ぴーおつ)と呼ばれるWebエンジニア兼COO。それぞれ、経歴は2年半と1年未満で未熟。
Webのアクセスデータを収集、解析してマーケティングなどに活かすWebサービスを渋谷で作っている。
好きなモノはビールとアート。
好きな言語は、JavaとJsとGroovy。

自分にとっての現場
DevLOVE現場甲子園では1回の裏に発表をさせていただいた。
ふりかえっても終始ありきたりな話になってしまい、せっかくお話を聞きに来ていただいた方にはもうしわけないな、と思った。
こういう場では話す側、つまり自分がいちばん勉強ができるのであって、今回も1つの学びを得たのでそれを書いて僕のアドベントカレンダーとする。

発表の際に僕が取り上げたのは、現場と経営の対立と協調だった。
よくわからないが現場と経営はよく対立するものであって、対立することが当たり前と捉えられている。

で、そもそも現場と経営ってなんだろう、という定義に立ち返るとむずかしい。
Devlove甲子園では、
現場:人が手と頭で価値創造する場
経営:お金(の按分)で価値創造する場
と定義してお話をしたんだけど、これだと「人事」や「総務」というお仕事はどこに入るのかわからない(という状態ではなした)。
ま、文系、理系のわけでいうと運動系や芸術系の学問はどっちにはいるのか、という問題に等しい。

DevLOVE現場甲子園で話し終わったあと、ある方と話していた気づいたことがある。
あたりまえなのだけど、エンジニアにはエンジニアの現場があり、経営者には経営者の現場がある。
エンジニアも経営者も、自分の現場で手と頭を使って全力をつくしているわけだ。
ようするに、現場と経営が対立しているのではなく、エンジニアの現場と経営者の現場が対立することがある、という状況の理解しかたが正しい、ということだ。

現場同士の対立を解消するには何が必要だろうか。
ここの答えは変わっていない。
つまり、お互いの現場で「なぜ」を追求しつづけるということだ。
「なぜコードを書くのか」「なぜ会社を運営するのか」「なぜ働くのか」こうした自らの行いに関する根源的な欲求にたいする問いとその答えに忠実な行動が会社というコミュニティを活性化させる。

根源的な欲求に対する問いは、自身の行動を深める。
自らの根源的欲求かが満たす事が出来る場で行動をするとき、人は無駄なく集中した一貫した行動で大きな成果をあげる。
これは、だれでも少しは経験があるはずだ。
たとえば、面白くてたまらない本を読んでいるときなんかはそうだし、きっと、部活なんかでもそんな経験がある人も多いと思う。

しかし、この「なぜ」は人によっても立場によっても異なる。
そして、現場が違い、見るものが違い、同じものを見ても解釈が異なり、それゆえ行動の優先順位が異なる。
そのためにお互いの現場で個別最適化がはかられ、対立が生まれてくる。

しかしながら、この対立、一方はAに向かい、一方はBに向かおうというする意志が引き起こす緊張こそが各々の現場を活性化させる。
お互いの現場の個別最適化が引き起こす緊張が上手く統合され、同じ目的に向かっている状態を生み出すことができているかいないか、
これが対立しているか、協調していないかを区別するものであって緊張は常に保ち続けるものだ。

エンジニアとして、COOとして2つの現場を知る僕の役割は、「翻訳」だ。

個別最適化することなく、複数の現場が活性化するには、CEOが示す統一的なビジョンにもとづいた対話が不可欠だ。
しかし、お互いの現場を知らない人たちの言葉は往々にして、相互理解をうまない。
相手の思考や思いへの無知から、相手の考えや価値観を否定することも少なくない。

これは正しい緊張状態ではなく、対立を生みひいてはお互いを尊重する、という言い訳とともにお互いから遠ざかるだけだ。
だからこそ、お互いの現場の言葉が通じあうような場がつくれるように、双方の言葉を翻訳しお互いの言葉が通じする素地を作ることが必要になる。

まずは定性的なデータの共有と解釈を戦わせるところからが始まりだと考えている。
理想的には徹底した議論がおこなわれることだが、まずは、相手の言葉を聞く機会をつくるところからはじめよう。

相互理解の苦労を経ないまま、下手な協調にいたりうまれる慮りは馴れ合いを生む。
お互いが遠慮をして、居酒屋のテーブルに1つだけ残された冷めた唐揚げのように、心配事や問題を扱うような現場同士の関係性ではなく、
冷めて美味しくなくなる前に、熱いうちに自分が平らげてしまう、そんな関係がきっとお互いの現場を活性化する。

エンジニアの現場と経営の現場、どちらも未熟ながら知った人間の現場は、会社というコミュニティに多数ある現場をつなげ、活性化させる現場だったのだ。
そんな気づきをDevLOVE現場甲子園で得た。

ぼくの現場からは以上です。

次の人へ
DevLOVE現場甲子園では誠実かつ安定感のあるまとめ力は主砲級、4番バッターにふさわしい活躍されていました。
TheHiroこと伊藤さんです。
「If your smeeeeell what’s TheHiro is cooking!!!!!」(野球関係なし

「真実は小説の中にある」という言葉@『最初の人間』

1月 20, 2013

『最初の人間』を岩波ホールで見てきた。
http://www.zaziefilms.com/ningen/introduction.html

厳しい祖母、優しい母、理解ある教師そして、癒しである太陽と海、原作者であるアルベール・カミュの青春と人生を支えた存在への強い思いが優しく表現された映画だった。
独立を目的としたテロに揺れるアルジェリア。
そのアルジェリアにフランス人として生まれ、フランスで有名作家となった主人公、カミュの分身であるジャック・コムルリ。
出身大学でのアルジェリアを支持するスピーチをおこなったものの、会場は荒れる。

アルジェリアの寄り添うことを心に決めつつも、フランス人として名声と富を得た自らの立場とアイデンティティに悩む。
ジャックは、自らのルーツを探すように亡き父のことを調べはじめ、幼い時を過ごした場所を訪ねる。

僕の印象に残った言葉が、ジャックである恩師であるベルナールの言葉だった。
それがタイトルにもした「真実は小説の中にある」という言葉だった。

この言葉はどういう意味だろう。
小説にの中にある真実とは、人びとの生活を描き出すこと、そして、読み手にその生活を想像させ共感させることなのだと思う。

よく言われるが死者の数も多数になれば統計になる。
ようするに問題が大きくなればなるほど、その問題に煩わされ、不幸を背負う人びとの姿は消えてなくなる。

貧困問題、紛争という大きな概念を指す言葉がそうだ。
言葉から、問題の重大さは伝わってくるが、人びとの生活と苦悩を想像させる力はない。

たしかに、マクロな視点は問題を整理し、問題の真の原因を発見する手助けをしてくれる。
一方で、マクロな視点から生み出される解決策は単純化されていることがおおい。
「ここに至っては武力解決もやむを得ない」という言葉はまさにマクロな視点による発想だ。

地域紛争を解決する方法が、武力解決しかない、ということはありえるかもしれない。
ただその地域には生活している人々がいる。
武力による解決によって、生活する人びとは死をはじめとしたあらゆる不幸を背負う。

ベルナールが小説の中に真実がある、というとき、アルジェリアの独立という大きな問題が覆い隠す人びとの存在が描かれることを期待しているのではないだろうか。
アルジェリアの独立は、大きな視点からはアルジェリア人(映画ではアラブ人という言葉が使われていた)とフランス人の対立として捉えられる。
フランス人はフランスを支持し、アルジェリア人はアルジェリアを支持する、という暗黙の前提がある。
その前提では、事実として、フランス人としてアルジェリアに生まれ育った人びとがいることが考慮されていない。
彼らの苦悩は存在しない。

しかし、人びとの生活を描ける小説であるのなら、彼らの苦悩を描き出せる。
彼らのことを知らない人びとが、小説を通じて彼らに共感し、理解する機会を得る。

真実が宿る小説とはそんなものではないだろうか。

この映画を見た後で、奇しくもアルジェリアで日本人も人質に含まれるテロが発生していることを思い出した。
触れなければならないように思えたのだけど、なぜテロが発生したのかの理由、背景を僕は知らない。
人びとの生活がどのようなものなのか、想像もつかない。
ただ、問題への無知と想像力のなさが問題を長引かせる、ということが原因であることがわかるのみだ。
だから語れることがない。

ただ、双方の被害が少なく問題が解決することを祈る。

物語の外側の気になること@『最強のふたり』

9月 17, 2012

ふたりのうちのひとり。
大富豪の老人、フィリップ。

フィリップはパラグライダーの事故で首から下が全く自由が利かな体になったのだけれど、単身で事故にあったのだろうか。
パラグライダーのシーンでは、彼はインストラクターと一緒に飛んでいたのだけれど、それは体の自由が利かなくなったためなのだろうか。

もしも、フィリップが事故にあった時もインストラクターと一緒に飛んでいたとしたら、そのインストラクターはどうなったのだろうか。
一人は首から下が不髄になるほどの事故だ。
インストラクターも無事であるとは思えない。相当な大怪我をおったかもしれない。
再び空を飛ぶことが恐ろしくなってしまったかもしれない。
事故の責任を取らされて失職してしまったかもしれない。

フィリップの事故に巻き込まれたインストラクターが本当にいたとしたら、ドリスに出会って彼が救われたように、インストラクターにも救われてほしいものだ。
本当にいたらだけど。

ふたりのうちのもうひとり。
黒人移民の子、ドリス。
彼はフィリップはどこで打ち解けたのだろう。
移民の黒人の子と首から下が不髄の大富豪の老人、両者を結びつけたものは一体何だったのだろう。

貧乏と自由にならない体という弱点をお互いに持っている。
そうした弱点をもつ苦労を互いに認めあったり、慰めあったりする場面はあった。
ただ、お互いが自分の弱点についての事実や気持ちを率直に話すのは、すでに心をひらいているからだ。

その前の心を開くきっかけは何だったんだろう。
なにかドラマがあることを期待するけど、一方で、ドラマがあったというわけでもないというものわかる気がする。
毎日の一緒に居つづけることこそが、お互いの心を近づけたという方が説得力がある。

ただ、ドリスがその時まで全く関わりなかった大富豪の家にとどまり続け、介護の仕事を続けられたのはなぜだろうか。
自らが抱えていた貧困を解消したいという動機だろうか。
映画の随所で見られた性根の明るさと優しさゆえだろうか。

その動機はドリスだけの秘密。フィリップも知らないことなのかもしれない。
もしかしたら、ドリス自身にもわからないことなのかもしれない。

最強のふたり』という映画は実話を元にしている。
だから、ちょっとだけ映画では語られなかった外側の現実がきになった。

借りはコードで返せ、とかを学んだ1年でありましたよ。

8月 4, 2012

先月で転職してから1年がたった。
振り返りの意味を込めて、職場を変えて1年間で実感したこと書く。

僕は元COBOLer(もっと正確に言うとNATURALという言語で開発をしていた)から特定の業者さんが使用するWebサービスをASP提供する会社に移った。
COBOLerがWebサービスに移ったらという苦労話も需要が多いかもしれないけど、具体的にどのような技術や知識を必要としたか、というのは書かない。
強いて言えば、JavaでもPHPでもRailsでもGrailsでもよいから、Linux上でWebアプリを1つでも完成させた経験があると良いのじゃないかと思う。
というか、そういう経験がなかったので、死にかけた。僕は。

ともあれ、おかげさまで、今の職場は楽しいし、やり甲斐のある仕事を楽しんでいる。

◯業務知識重要
転職して一番苦労し、今も悩ましいのは自分の業務知識のなさだ。
業務知識を持たずに仕事はできない。
日々の仕事の優先順位を自分で立てられない。
優先順位を自分で立てられずに働くということは、人に指示されて働くということだ。
人に指示されて働くという状態は、自分をコントロールできないことを意味する。

自分がコントロールできないことのストレスは耐え難い。
なんとか自分のコントロールを取り戻す必要がある。

僕にとって自分がコントールできている状態を端的にいうと、自分で自分の仕事の質、量、期日が調整できるということだ。
もう少し具体的に言うと、取り組むべき最重要な課題と期日を自分で決め、期日通りに終了させられる、ということだ。

自分をコントロールするためには、サービスをどのように成長させてゆくのか、を想像できることが重要だ。
なぜなら、今日取り組むべき最重要の課題とは、自分たちのサービスをどのように成長させてゆくのか、という目的にとって最重要な課題だからだ。
そして、自分たちのサービスの成長させてゆくのか、を考えるためには道標が必要だ。
どういったものが道標になるのか、というと有名なった

アップルで働くまで、イノベーションというのは「今にない、新しいものを作ること」だと思ってた。でもそれは違って、イノベーションというのは「未来にある普通のものを作ること」なのです。この違いを理解できるまでかなり時間がかかった。

という言葉が全てであるように思う。

すなわち、今、僕たちのシステムを使って仕事をしている人たちにとって「未来にある普通のもの」こそが僕たちが作っているサービスの道標になるはずだ。
もしくは、その人たちの未来の普通にあるものを支えるサービスと言って良いかもしれない。

道標の探し方は、話題になっている『ビジネスモデリングジェネレーション』や『SubjectToChange』でも知ることができる。
その中で共通しているのは今の普通を知ることだ。
エスノグラフィとか人間観察とか、現状分析とか言われるものかもしれないが、今をくわしく知ることが、未来の普通を描くことのタネになるのだ。

そして、特定の業界に向けてシステムを作るエンジニアにとって今の普通を知ることとは、業務の商習慣や利益構造などについて詳しく知ること、すなわち業務知識を身につけることなのだ。

以前の僕は、受託開発で枯れた技術を使って開発をしていると業務知識に重きをおきすぎる文化が嫌いだった。
自分がコードのバグと格闘している立場にいると、コードが読めなくても書けなくても業務知識があればよい、という考え方には腹が立つことも多かった。
そして、業界の未来を描く、というと山師的でうさんくさい、業務知識というとおかたくてダサいと思っていた。

ただ業務知識をなくすと何も見えなくなる。
今を詳しく見れない人間には、未来の普通を描くことはできない。
エンジニアにとって一番、良い場所は、未来の普通を描ける場所で、サービスなりを構築することに自分の技術力を存分にふるえる場所なのかもしれない。
それが転職して得た気づきの一つだ。

◯経験の質と時間重要
RubyやAgileという言葉に吸い寄せられる人々だったら37signalsを知らない人はいないと思う。
知らない人はモグリじゃないが、損している。
『getting real』や『小さなチーム、大きな仕事』はシステムづくりを仕事にしているなら読んでみるとかっこいい言葉とともに多くのことが学べる。

その37signalsいわく

(前略)仕事依存症は不必要なだけでなく、バカげている。『小さなチーム、大きな仕事』(p.22)

という。
彼らはこの信念のもと働き、そして成功している。

生産性を仮に時間単位で稼げるお金の額(money/hour)とするならば、生産性を上げる方法は、稼げる額を維持するか伸ばしながら、労働時間を減らすことだ。
37signalsは、労働時間を短縮することは生産性を上げること、優れたソリューションを生み出すことに寄与すると考えている。

そんな経験をしていないのでわからないけど、直感的に37signalsの言葉は正しい。
ただ、僕が転職して直面した問題は、時間を減らしながら稼ぎをふやすということは非常に困難、ということだ。

業務知識がなくなったことも関連しているけど、右も左も分からない状態で期日までに目的を達成することがまず非常に難しい。

もちろん、周囲の人達は聞けば助けてくれる。
でもやり遂げるのは自分だ。そして、やり遂げるには自力が必要だ。

そして、自力をつけるためにも時間を投資する必要がある。
学習したい内容に最大限の時間を投資するのだ。
学習の対象が業務知識であり、自社サービスのプロダクトのことであるならば、仕事に時間を投資することは理にかなっている。
ワーカーホリックは馬鹿げているのはわかっているけど、右も左も分からない状況ならどっぷりと仕事につかるのは悪くないと思う。

もちろん、学習の方法は色いろある。
本を読む、写経をする、自分でアプリケーションをつくる、勉強会を開く(もしくは参加する)などだ。
ただこれらの学習方法は、実戦経験の補助に過ぎない。他社の経験の追体験でしかないからだ。
追体験は、仕事のような実践に活かしてこそだ。
結局、実践のための時間が必要になる。

ただ、陥りやすい罠は1つある。
やはり、37signalsがいうとおりだ。すなわち、

仕事依存症者は、ほどよい時間にしか働いていないという理由で、遅くまで居残らない人たちを能力に欠けているとみなす。これは罪悪感と士気の低下をはびこらせる。さらには実際には生産的ではないのに、義務感から遅くまで残るのような「座っていればいい」というメンタリティを生み出してしまう。『小さなチーム、大きな仕事』(p.22)

自分の仕事を果たして、時間通りに帰る。それが普通のことだ。
長時間働いていることは自分で選んでいることであって、人から強制されるものではない。
ましてや他人に強要するものでもない。

経験には時間だけでなく、質も関係する。
これも感覚でしかいないけれど、「仕事」という漠然にたいして長時間、投資を行うのは不毛だ。
不毛なことの1つの基準としてルーチンワークに落とし込めたらそれは時間を投資する価値がないもので、自動化の対象だ。
自動化できることを繰り返し自分の時間を投入するのは良い経験ではないし、時間の無駄だ。

また、質という点では人間の限界もあるだろう。
人間の集中可能な時間をこえて仕事に取り組むことは果たして良い経験になるか、ということだ。
たとえば1日8時間しか集中ができないとしたら、それ以上の時間を注ぎ込むことが良い経験になるだろうか。

僕の実感からだと、
・学んだことをメモに残せる
・1週間ないし2週間のイテレーションの計画を立てる時間がある
・週に1度ジムにいき、酒を飲みいける時間がある
これを満たせないとどんなに仕事に時間を投入してもムダになる。
作業のミスや抜けが多くなるし、経験したことを記録しておけないのでやったことを片っ端から忘れてゆく。
ようするに経験が蓄積されていない状態になる。経験をムダにしているのだ。

もちろん、これは僕の場合であって他の人に当てはまるかどうかはわからない。

働き過ぎは37signalsが言うように間違った価値観を生む。
あと、なんにせよ、他人の命令や指示で長時間労働することは馬鹿げている。
もしも、時間を仕事に投資するなら最低でも、その投資に自分が納得している必要がある。

◯借りはコードで返せ
そんなこんなで、一緒に働いている人たちには今もたくさんの迷惑をかけながら仕事をしている。
周りの人たちができるのに、自分がいまいち利益や仕事で貢献できていないのは肩身が狭い。
周囲の人たちに比べてできない自分が情けない。
そういう状況に陥ると、「他の人の邪魔をしちゃいけない」と考えて、優秀な人たちの時間が空くように雑用を巻き取る事を考えたりする。

ただ、それは逃げの思考だ。
よく言われる通り、組織の強さは最弱の部分に依存する。
もしも、組織の開発力を考えるのであれば、自分が底辺かつ成長しないのであれば組織の開発力は上がらないままだ。
組織を強くするためには、自分を鍛え、やることを増やし、質を上げるという正攻法の努力が必要になる。

自分ができなくて周囲の人たちに頼りっきりの状況は非常に情けないし、申し訳ない気持ちにさせられる。
でも、優秀な人たちと働くと自分の実力以上の仕事ができる。
そんな経験は何にも代えがたい。
自分から進んで会社をやめたくはないけれど、やめたほうが会社のためになるのではないか、という非常に悩ましい状況だ。

そんなさなか、いわれたのが

借りはコードで返してください

という言葉だ。

ようするに仕事の借りは仕事で返せ、ということだ。
仕事を進めていると、相手の邪魔をしたり迷惑をかけたり、はたまた時間を作って手伝ってもらったりすることがある。
そんなときには、ありがたいとか申し訳ないとか思う以上に、自分ができることをしっかりやり遂げることが一番の借りの返し方になる。

エンジニアの仕事は単にコードを書くだけではないけれども、仕事のうえので貸し借りや自分に求められる仕事へのコミットの仕方が端的に現れている言葉だと思う。
だから僕はこの言葉が好きだし、実践したいと考えている。

今までの借りはコードで返すのだ。

◯今後やりたいなぁと思うこと
ということで、1年分の借りを今年は返して行きたいと考えている。

Jenkinsのコミュニティってすごいなぁと思った@Jenkinsユーザーカンファレンス

7月 30, 2012

2012/07/29に行われたJenkinsユーザーカンファレンスに参加してきた。
1000人以上の参加登録が行われ、国内で行われるIT系のカンファレンスとしては有数な大きな規模で盛り上がったようだ。
大きなカンファレンスが有志で行われることは、Jenkinsが多くのエンジニアにとって有用なツールであり、また、多くのエンジニアに愛されていることの証拠だろう。

◯優れたツールをつくるコミュニティには貢献の意識が中心にある
川口さんの基調講演ではJenkinsの現状やこれからの取り組みについて聴いた。
話を聞いて考えたのは、
なぜJenkinsが多くのエンジニアに愛されているか
なぜJenkisnのコミュニティは活性化しているのか
ということだ。

この答えは非常に単純で、
エンジニアたちへの貢献を一番に考えた取り組みがなされているから
だろう。
Jenkinsの取り組みとして
- よくある作業をやりやすくするためのUIの見直し
- pluginによりユーザーが好みの機能を拡張しやすくすること
- 頻繁にアップデートができないエンタープライズでの利用者に向けてLTSの用意
など利用者がどこで困るのか、どんな対応をしたらうれしいのか、という点をよくみて対応が進んでいるように感じた。

またJenkinsのおすすめpluginを集めたおすすめpluginパックのようなものを作る予定があるらしい。
Jenkinsはpluginが豊富にある一方で、個人的にはどんな便利なpluginがあるかほとんど把握できていないので、この取り組みは非常に良いなと思った。

1000人も集まるカンファレンスを有志で開催できてしまうほどパワーのあるコミュニティは、Jenkinsという優れたツールに引き寄せられた人たちによって成り立っている。
Jenkinsに引き寄せられるのは、Jenkinsがエンジニアたちに貢献をしているからだ。
そして、Jenkinsが優れたツールであるのは、素晴らしいコミュニティとそこに集まる人たちの貢献があるからだ。

川口さんのお話を聴いていて、Jenkinsというツールとそのコミュニティは、エンジニアたちと良い循環をもった関係を築いており、エンジニアとコミュニティが相互に貢献の意識を持っているからなんだと感じた。

◯buildhiveが素敵
これも川口さんお話で出てきたのでけど、buildhiveというツールが非常に良い。
というかものすごく期待できる。使いたい。
現在、gerritを開発で使っているのだけど、その理由は1つ。
中央のリポジトリにバグを含むコードが入る確率を低くしてくれるからだ。

今回のカンファレンスでもgerritとjenkinsの組み合わせを利用した事例を発表していた方がいた。
その方も話していたけど、gerritを利用すると
- gerritにpush
- Jenkinsによるビルドとテストの実行
- test実行後に人間によるcodereview
- ビルドとテスト、コードレビューをすべてにクリアしたら中央リポジトリにマージ
というフローで開発ができる。
エンジニアたちがpullをするリポジトリには、ビルドとテスト、レビュー済みのコードが入ってることになる。

buildhiveというツールは、githubのpullrequestを利用してこれとほぼ同じことが出来る。
つまり、pullrequestを行ったプログラムにたいしてJenkinsでビルドとテストが実行できる。
そして、ビルドとテストを通過したものをコードレビューをした後に、受け入れるかどうかの判断ができる。

gerritは魅力的な一方で、管理や利用の面で覚えることが多い。
一方で、githubは個人で利用している人も多い人気ツールだ。
おなじことができるなら、githubとbuildhiveのほうが導入が早いかもしれない。
buildhiveがあるならgerrit入らないくなってしまうかも。

余談だけど、設定周りの管理はpuppetを利用している事例をよく聴いた。
名前は知っているけど何ができるかよくわかっていないので、ちょっと勉強してみたい。

◯自働化のキモは適切なジョブの分割
自働化で意識しておきたいこと下記の3つかな、と感じた。
- どこで、何が原因で処理が失敗したか検知しやすくする
- 時間のかかる処理を並列で行えるにする
- 失敗したジョブの再実行しやすくする

これらを達成するコツが適切な単位でのジョブの分割だろう。
というか、上記の3つがジョブを分割する際の指針になるような気がする。

◯Jenkinsを中心にすえて開発からデリバリーまでのプロセスを見直したい
サービスの開発から運用までをやっていると課題になるのは品質だ。
サービスの品質を維持するためには、プログラムのバグを出さないという基本からユーザーや開発に必要なドキュメントの整備まで、ひとつの機能を作ったり改善したりする際に行うべきことは多い。
現状、いわゆる「どのような状態をサービスの出荷条件とするか」というDone定義がチームでまとまりきらず、それによる作業の抜けが起きることがある。
また、やらなきゃいけないとわかっていても何かと言い訳してやらないこともある。

Doneを定義し実行する、という点においては、受け入れテストのレベルで自働化の必要性を感じた。
プログラムがどう動くかだけでなく、どのような目的を達成するか、という観点からテストが書かれて自働化することに加えて、コードのメトリクスをとり、テストの網羅率などをテストの成否の基準に加えたり(たしかCoberturaを利用していた)
単にバグないだけでなく、コードの品質も自働化により担保するなどの取り組みをおこなう。
また、Javaを使っているならJavadocをもとにドキュメントを生成する仕組みもある。

どのような品質のコードで、何が達成され、ドキュメントなどのどのような成果物が必要か、という観点から出荷すべて成果物を定義するきっかけとなるのが受け入れテストなのだ。
そして、Jenkinsにはそれを助けてくれる仕組みが用意されている。
Done定義そのものはチームが考えて決めてゆくものだけれども、Jenkinsを利用して自働化できることに注目することでDoneの定義に含めやすくなる成果物も増えるだろう。

gerritとJenkinsを利用したプロセスの話だと、開発のプロセスが固まるまでは半年ぐらいはかかったということだった。
はじめからモノゴトはうまくいかないし、問題意識があるからてすぐに改善できるわけでもない。
時間を捻出して少しずつ進めて行きたい。

で、そのための手段としてやはりベロシティやバグの発生件数、コードのテストの網羅率など利用価値の高い数値を簡単に取る仕組みを導入したいと考えている。
やはり現状がどうなっているのか、感覚値じゃなくて実測値から判断したい。
そろそろ取り組む余裕がでてくるはずだ。

◯最後に
今回のカンファレンスに参加して、Jenkinsは単にbuildとtestを自働化するツールという印象ではなくなった。
deployなどを含めて、開発から運用というプロセスにおいてあらゆる箇所の自働化の中心的なツールになってゆくことが期待されるツールなのだと感じた。

運営に携わった方々には、大変お世話になりました。
皆様、どうもありがとうございました。

チャラン・ポ・ランタンのライブがおもしろかったのでひさびさにブログを更新してみる

7月 22, 2012

JAZZ ART せんがわ2012というイベントで非常に面白いライブを見てきた。
http://www.sengawa-gekijo.jp/kouen/07423.html

アーティストの名前は、チャラン・ポ・ランタン。

jazzを聴けると思っていたんだけど、どう考えてもジャズじゃない。
あまり音楽を聞かない僕の知識を総動員して考えると、あれは昭和歌謡だった。
普段ほとんど音楽を聞かない僕でも、どこかで聴いたことのあるような懐かしさを感じる音楽と、人間が表には出したがらない自分の心のうちを描いたような詩が印象的だった。

ライブを聞いていると、人間の表に出しづらい心の奥底にある感情をテーマに書かれた連作短編の小説を読んでいる気分にさせられる。

1つ1つの曲に物語があり、1つの曲ごとに完結している。
そんな1つ1つの曲がつながって、ライブが1つの作品になっているという印象だった。

下記に彼女たちのHPのURLを貼っておいたので確認してほしいのだけど、可愛らしい彼女たちの風貌からは想像できない詩の内容、そして、迫力のある歌声に圧倒されてしまった。

もう一つ、びっくりしたのはアコーディオンの音色。
テレビでしか聴いたことがなかったので、うまい人が弾くアコーディオンを生で聴くととすごく綺麗な音がするんだな、と感心してしまった。

お店にお酒がなかったので、はじめてライブをシラフで聞いたけれど、とても楽しめた。音楽素人の僕が久々に皆に教えて回りたいな、と思ったアーティストに出会ったライブだった。

チャラン・ポ・ランタンが気になる方は下記のHPで情報チェックしてほしい。(というか、たぶん結構有名なんだろう)
今度、フジロックにも参加予定らしい。
http://charan-po-rantan.o0o0.jp/

アジャイルサムライから学んだこと

4月 16, 2012

1ヶ月に聞いたjonathan rasmussonの話で印象に残ったことを書いておこうと思う。

僕が彼からうけた教えは非常にシンプルで、
ルール1:
価値のあるフィーチャーを確実にリリースして信頼を築け
ルール2:
その信頼を決して裏切るな
という2つのルールだけだ。

アジャイルにやる目的というのは究極、価値のあるフィーチャの定期的なリリースだ。

もちろん、アジャイル開発を発祥とするプラクティスを上手く取り入れることは、開発現場が楽しくなったり、良い開発者を育てることができるようになったり、という効果もあるかもしれない。
とはいえ、それらは手段であって目的ではない。

楽しい開発現場は開発に携わる人の士気をあげる。
人が育てられる開発現場はチームのハネムーンナンバーを増やせるし、チームの能力を高められる。
だが、それは価値のあるフィーチャを継続的に生み出し続け、ビジネスとして成功する、という目的を達成するための手段だ。

たとえば、『アジャイルサムライ』で紹介されているインセプションデッキもデッキを作ることが目的ではない。
開発、プロジェクトの目的を忘れないために作成するのだ。
アジャイルにやるためにはたくさんの暗黙知がある。
アジャイル開発は、それらの暗黙知をプラクティスという名称で形式化した。
しかし、それがたくさん現れてきたことで意識的に考慮することが増えたことにより混乱が生じる。

ちゃんと朝会をやっているか、ちゃんとデッキを作っているか。
こうした視点は悪くない。
しかし、「ちゃんと」を判断する判断基準が大切だ。
単に実施されている、アウトプットが作成されている、という確認では意味が無い。
それは読まれない大量のドキュメントを作成する不毛さに似る。

アウトプットがあるか、という表面的な確認が行われていると、手段が目的になる。
そして、目的に近づくために取り入れた手段をこなすだけになる。
本当に目的にとって有用か、を判断せずに。

Jonathanの話を聞いて、限りなく単純化すると見るべきところは2つで良いように思った。
すなわち、
・チーム内で合意されたスコープを溢れさせずにリリースが出来てるか
・会社の業績は伸びているか
の2つだ。

Jonathanの教えをあまりに簡略化しすぎているかもしれない。
けど、彼の話を聴いていて反省したのは「実施したい、実施すべきだ」と思っていること、つまり手段を取り入れることに目を奪われすぎていて、自分の状況をうまく把握できていなかったことだ。
そして、なぜ「実施したい、実施すべき」と思っていたのか、理由を整理しきれていなかったことだ。

スコープを溢れさせずに定期的リリースができ、会社の業績が上向いているなら。
おそれらく、アジャイルにやれている。
そして、プラクティスを取り入れたいと思っているのは、アジャイルにやれている状況を維持するためだ。

アジャイルにやれているか。
という問たいする答えは非常にシンプルだったのだ。


フォロー

新しい投稿をメールで受信しましょう。