New Year's resolution

一年の計は年末に生まれる

故に元旦には既にある状態となる。

判断を早くする。これを抱負としたい。

この一年を振り返ると環境に大きな変化があった。

制限された環境で不自由の中でも PowerShell に出会って、 Windows のスクリプト環境を楽しむことができた。 RSpec とよく似た BDD が可能な Pester というテストフレームワークもあり、非常に強力な開発環境だと感じた。 BDD は判断を早くする良き相棒になると思っている。

IE 向けの Web アプリケーションの開発では、構造化されていない JavaScript や Java で書かれたコードに触れてしまい、それを守ろうとしたがためにひどく苦しんだ。デバッガやテストコードに支えられたが、これらを本当に守るべきだったのか、もっと早く判断して捨てるという選択は可能だったのではないかと悔やむことがある。 IE にも強力なデバッガがあることがわかったのは僥倖だった。

早く判断できればやり直しが効く。

一年の計を早々に立てればこれもまたやり直しが効く。

しかし、判断を早くするしか言っていなくて何も計画は立っていないという

My hobby

Redmine が好きで6年ほどの付き合いになります。

チケットという単位にタスクを分解できるのが気持ち良く感じます。ちゃんとゴールが見えているか、そのために何をしたら良いのか、そういうのを整理していくのが楽しいです。

ロギングして可視化もしてくれます。何に何時間かかっているのか、それが見えてがっかりすることもあります。これだけのことにこんなに時間をかけてしまったのかと。そういう目の瞑りたいことも記録してくれる相棒となっています。何も小言も言わずに君はこれをこれだけやったよと受け止めてくれます。

この Redmine を活用したチームによるチケット駆動開発は必ずしもすべてのプロジェクトの管理にマッチするわけではなく、却って開発を愚鈍化させることもあります。ツールが最初にあるのではなく、まず問題があってそれを解決するためにツールを使うべきです。問題というものも、私が問題ですと自己主張しているわけではなく、見る人によっては問題だったり、そうでなかったりします。どうやって問題に気付くか、また気付くことが本当に幸せなのか、それが問題です。

というようなことを考えるのが趣味になるのかなあと思います。

Team work

チームワークを向上させるために連携を増やせば、足枷となり却って動きが悪くなる。

そもそもチームワークとは、またそれが向上したと評価する基準は、チームとしての生産性だったりするのだろう。そうするとチームに属する個々の活動を平均化して、あるいは抽象化してしまって見ないようにする。多くを管理する立場であれば、見るべき情報が少なくなるので良い面がある。しかし、それを頼りにチームとしての振る舞いを見直そうとすると個が見えなくなってしまう、見なくても良いものと判断されてしまっているように感じる。その結果、チームとしてどう良くしていこうか、と考えたとき、連携を増やそう、連絡を密に取り合おう、という目標を抱えてしまいがちではないだろうか。

チームワークというものを、仮に上述の判断基準で評価するのなら、これを向上させるには個々の技術力を向上させるしかない。

技術力が向上すれば、扱う情報の精度も増し、伝達する情報も効果的に行われ、それをもって結果的に連携が良くなると考える。

連携を良くしよう、良くしようとつながりに注目するのではなく、その間をつないでいるものの質を高めていくことに注力することでチームワークを向上できるのではと思った次第。

Who is leader

リーダーというものが仮に存在するとしたら

どんな人物だろうか

度量について興味深い話を聞いた。

どんなメンバーであってもまず懐に入れる。

その上でどうしたら良いか考える。

この時の受け皿の大きさというか、受け止める覚悟のある無しを度量と呼ぶのだと。

量という言葉で数値化されそうだと思いがちだが、そうではなくて、極端な話ではあるが、あるか無しかという真偽値といって良さそうだ。

そうして受け止めたメンバーに対してどれだけ向き合うことができるか。

おそらく、受け止めた時点で向き合うことは容易だと思う。

次は向き合った状態で何に気づくことができるか。

こう考えるとリーダーシップというのが、これらを実践していく行為を指すのだとしたら、すべてのメンバーに求められる要素だと思う。

ただ各々磨いているセンサの向いている方向、感度が異なり、それぞれの分野、役割ごとにリーダーシップを発揮していくのが効果的だと思う。

特定のリーダーを定めずに有機的にチームが機能すれば、皆がリーダーと呼べる場面を切り替えながら成長していくのかなあと思っている。

Communication sciences

コミュニケーションとは、情報伝達である。

開発におけるコミュニケーションは目的ではなく、情報を伝達する手段の一つだと考える。では、一人で開発している場合は不要だろうか。一人で開発していても必要だと思っている。極端な話で、一人で今だけ開発しているなら不要とできるだろう。今だけでなく、継続して開発していく場合は、未来の自分に対してコミュニケーションが必要になる。

情報を効率良く伝達するためには、情報を構造化して記述していくことが望ましいと考える。これは繰り返しの記述を避けることにもつながるし、構造化しづらいのであれば、扱っている情報の整理が必要であるサインかもしれない。Wiki に代表されるような形式で構造化できると良いと思っている。

情報の中に課題やバグと呼ばれるものを扱うときは、 Issue Tracking System や Bug Tracking System が有用だろう。これはその課題やバグごとの状態管理、共有のしやすさが非常に優れていると感じる。口頭やメール、静的ファイルの共有と比較すると尚更である。

さて、これらの情報をどのように記述するのかは、関わっているチーム、メンバーによるだろう。情報伝達なので、意図した内容が伝わらないと意味がない。これにはレビューを繰り返していくしかないだろう。なのでレビューをしやすい環境作りが重要であると考える。

ここで究極の情報伝達とは何かと考えると、テレパシィだろう。何も伝えずに伝わる。こういったテレパシィの類は実現可能だと考える。経験に裏打ちされた先読み、直感的なもの、サッカーや将棋、演奏のアドリブなんかはこれに近いものがあるのではと思っている。これらは相手あってのもので、知識を詰め込むというよりも、体験の共有によって、蓄積した経験が回答へのショートカットを生成し得る。これはパターン認識なのだろうか。であれば、デザインパターンと呼ばれるような型を学習することで知識を詰め込むことで到達可能だろうか。

情報を構造化する前段階のメッセージのやり取りに関しては、対個人でやり取りするよりもスレッドやチャネルといったテーマごとにやり取りできると、その時点で構造化の第一段階をクリアしている。各テーマごととなっているので、やり取りする内容がそこに属しているのか、新しいテーマなのではと意識することにもなるので、情報が混ざって埋もれるようなケースを回避しやすくもなる。

これらの実現のために利用しているもの

- Redmine

- Slack

- Bitbucket

どのレベルにおいても Redmine は有効だと思う。

Slack はメッセージのやり取りに関して優れている。

Bitbucket はリポジトリと密に連携しているので、コードを起点とできるプロジェクトであれば Redmine よりも手軽に始めることができる。Redmine のリポジトリ連携はプラグイン次第だが弱い。

■

文章を読んでいて、ああこれが作者の言いたいことなんだろうなと感じることがある。

しかし、冷静に考えてみると、自分が読みたかったこと、言って欲しかったことなのだと気づく。

センサの問題なのだと思う。

自分が何に関心を持っているのか、それが可視化される。

結局、どんなに思っていても、言葉で表現するのはなかなか難しい。そのもやもやとした状態をぴたりと言い当てる表現に出会うと嬉しいものだ。

同じ文章を読んでもそのセンサの向いている方向性、感度によって受け取る情報量や質、情報そのものが全く異なるだろう。そうやって受け取った情報から自分のセンサの状態を知ることができる。

文章を読んでいて、もっと早く読みたかったと感じることがある。

これもセンサの問題で、もっと早く読んでも何も感じなかっただろう。今のセンサの状態だから受け取れるものがあったのだ。そのためには、ここに至るまでの経験が不可欠だったと思う。

文章を書く場合、これの逆のことを意識すると良いのだろう。

自分が言いたいことを書く、のではなく、特定のセンサを持っている人に向かって感知したい情報を言葉で表現する。そうすれば、すんなりと伝わるんじゃないだろうか。

業務上のメッセージのやり取りで歯がゆい思いを経験している。知りたいのはそれじゃない的な。これはお互い様だろう。相手が何を知りたいのか、それを考える。

何となく、文章を読む、書くのベクトルが逆のように感じた。

文章を読むのは、他人の考えを知るようで、自分の考えへアクセスする。

文章を書くのは、自分の考えを伝えるようで、他人の考えへアクセスする。

蛇足だが、読書感想文の複雑性は、このベクトルの異なるものを合体させているからだろう。文章を読んで自分の考えにアクセスしたその結果を、他人の考えにアクセスするように書いていかなくちゃならない。

さて、難しいを簡単にするのが天才で、簡単なものを複雑にするのが馬鹿という慣用句を聞いたことがある。

上の文章はまさにそれで読書感想文というシンプルなものをよくまあわかりくく捉えたものだ。

Forbidden failure

失敗を禁じれば、失敗を隠し、やがて失敗しないように挑戦しなくなるであろう。

何としても成功させる

失敗してはいけない

こういったことでモチベーションが高まり、成果が上がっているなら何も言うことはない。

ただ、行き詰まりを感じているなら、失敗しても良いように考えるべきだと思う。

むしろ如何にして速く失敗してリトライするか突き詰めたものがテスト駆動開発だったりするし、そういった考え方がプログラミングでは有効だと考える。

なぜか？

やり直しがしやすいという特徴があるからだ。

はい。

聞こえます。やり直しなど無縁、取り返しのつかない状況に追い込まれてデスマーチを歩む足音が。

中途半端に動いているものを切り捨てるのは、やはり難しい。

レガシーコード改善ガイドの教えでは、そういった状況でも少しづつやり直しのきく範囲を増やしていこうとある。

また失敗とは何か再定義してみる。

自分の目標が達成できないことを失敗と定義していたら、視野が狭い。お客さんとの関係性と定義していてもまだ足りない。真のユーザに価値を届けることができるかどうかに着目すると、失敗することがそもそも難しかったりする。

自分が成功に関わらなくても、価値を届ける手段は考えることができるはずだ。

それはビジネスとして成立しないとも思うが、ビジネスが成立しなくても済む世界に憧れる。