Moonmile Solutions Blog

ソフトウェア開発者の道具箱 | Moonmile Solutions Blog シリーズの第3弾めは、情報発信の話。

研究開発でもプログラミングでもそうなんだけど、実際にモノを作っている時間と、モノを作ろうと設計としている時間がある。モノを作っているときは、集中している時間を多くして、出掛ける時間を減らしたり人と会う時間を減らしたりする。じゃないと「モノを作る」時間を捻出できない。逆に、モノを作るための設計とか計画をしているときは、適度に情報を取り入れたり出したりしないとうまく発想が回らない。情報を取り入れるところはすぐに分かると思うけど、「情報を出す」というところに手が回らないくてやめてしまう人が多いのだが、実は違う。情報を効率よく取り入れるためには、情報を出すという自分なりの整理が必要になる。

1. 雑多な未知な情報を取り入れる。
2. 自分の中の既知な情報と組み合わせたり比較したりする。
3. 取り入れた情報に対して「本質」を外していないか、客観視するために情報を出す。

というサイクルが必要になる。よく、Twitter で書いた途端に誤字をみつけるとか、人と話した途端に理解が進むとか、コンピューターの横に熊のぬいぐるみを置いて話しかける、というアレです。

でもって、何らかの情報を出し入れしている間にだんだん固まってきて、ひとつに集約するためにモノ（プログラムコード）を形作っていくわけだけど、物理的なモノづくりと違って、プログラミングコードなんてのは作ったり消えたりするサイクルが非常に早いので、作る時間と考える時間を結構なタイミングでスライスさせても問題がない…ように見えるのだが、それでも交互に来ることには違いない。

「金の鍵」ってのは、情報を発信するときに内側から開けるための鍵です。外からの情報をシャットアウトするために鍵が必要なのは直ぐに分かると思うけど、内側から出るときに何故鍵が必要なのか？そう、先の設計時の思考で書いたように、情報の流入と流出のバランスと保ために、内側のほうにも鍵を付けておいて「常に外側に繋がっているという状態ではない」という状態を保つのに必要だということだ。「平田弘史のお父さん物語」に詳しく書いてあるのだが、呼吸と同じ。「吸」だけ続けても何も吸収できないので、「呼」があって循環させないといけない。これは仏教の呼吸法にもあるんだが、循環とか輪廻とかそういうところに根差している「思想」になる。だから、科学的に「本当に知識の吸収ばかりすると効率が悪いのか？」という証明は別として、温故知新な経験的なところから、情報の入力と出力のバランスを取れ、というのセオリーということになる。こんな風に、ブログとかで出力すると自分にとっても客観視ができやすくなるので、それなりの効用はある。

内部から外側にでるときに「鍵」を使うということは、情報発信をするときに、なんらかの形で情報を整理するということでもある。つまり、取り入れた情報をそのまま垂れ流すのではなくて、何がしかの理解をしたうえで流す／伝えるということですね。そうなると、安易なリツイートやまとめサイトの云々がアレなのが分かると思う。ひと呼吸おくということが、ちょうど「鍵」の役目をすることになって、それが「思慮深さ」を生むことなる。思慮深さは会話のテクニックでもあるのだけど、即答しないでひと呼吸置くとか、相手が息を吐ききった後に話かけるとか、そういうタイミングの話でもありますね。武術においても、相手が呼吸を吐いたときに当てるのが一番ダメージが大きいので、それを見る。同時に、呼吸をさとらせないという技もあれば、偽の呼吸を相手に伝えて惑わすという手法もある。これは武術に限らず、会議とか競合会社のアレとかにも使える。

そういうタイミングが鍵になる。

ちなみに、逆引き大全のほうは、1対多の情報発信の話になっているので、こっちはISO9000絡みの、「外に漏れるとまずい情報≒メンバ全体が知らなくても良い情報」あたりの鍵の話になってる。

道具箱シリーズの第2弾は「同情プログラミング」の話です。

プロジェクト運営（プロジェクト「管理」ではなく）の視点から言えば、プロジェクトやチームがうまく動く方法は「うまくいかない部分」を切り去っていくことです。「切り去っていく」ということは、冷徹な感じがするような気がしますが、人を切り去るのではありません（チーム崩壊を招く「マイナス生産者」に対しては、切り捨ての手法をとりますが）、その人が何かをやるときに、うまくいかなくてマイナスになってしまう部分を切り落として捨て去ります。人なのだから、何かの間違いもするし、勘違いもするし、運が悪いときもあるし、体調が悪かったときもあるし、状況によりうまくいかない場合もあるでしょう。だから、トータルで考えるわけですが、チームとして（それは人として「成長」なのかもしれません）今よりもうまくいくためには、今、ダメである部分を少しずつ切り取っていくのが着実な方法なのです。なので、何らか状況でうまくいかなかったとき（能力が低かったというのも含めて）は、再び同じ状況に陥ったときには回避できるようにしておきます。完全に同じ状況というのはないのですが、今後も似たようなことはおきますよね。ISO9000の「是正処置」という考え方ですが、これを流用します。勿論、なんでも是正処置が必要なわけでなく、レアな場合（今後は1度も起こらないようなこと）は是正する必要はありません。苦くて忘れたい経験は、忘れ去ってしまうのがベターです。

さて、プログラミングにおいて、プログラムコードを書くということは、それなりの時間をかけて、それなりのかの人の努力の結果が示されているわけです。なにがしかに時間は、会社の給与のうちかもしれないし、自主的に家に帰って考えた結果かもしれないし、どこかの講習でお金を払って覚えた技かもしれません。1,2日のコードであれば、捨て去る勇気もあるのですが、1週間も掛かって苦労して作りあげたコードを、人情的に捨てるに忍びないですよね。ちょっとぐらいまずくても、何らかのいいところを拾うとか、かの人の心情を害さないような手段を取りたいものですよね。

ですが、残念。それらは捨て去ってしまうほうがベターなのです。

プログラムコードが、アジャイル開発的に動くものを達成するのであれば（場合によっては、「動かない飾りのコード」というものもありますから）、動かないまずいコードは、そのままゴミでしかありませんし。何の価値もありません。そこに「同情」をしてしまうと、先行き負債を抱えてしまうのは明らかなことです。いや、コード自体の負債以前に、かの人の成長機会を失ってしまうのです。

ベストな方法、かの人に書き直して貰う事です。仕事として。

うまくいかない原因は、まずい設計かもしれないし、時間がなかったのかもしれないし、予想よりも時間が掛かったかもしれない、能力が足りなかったのかもしれない、いろいろな原因があります。でも、2度めにコードを書くときは、設計の見直しや、時間をしっかりとったり、計画を立て直したり、かの人の能力だけでなく他の人の助けを求めたりすることが可能であり、それは「経験」として生きてきます。それを、本人に伝えずにこっそり直してしまったり、直すべきところを指摘して勝手にピンポイントで直してしまったりというような、かの人の「成長機会」を奪うような方法は、結果的にチームやプロジェクトにとって損失でしかありません。そう、いわゆるかの人の生産性が変わらないままになってしまうのですから。

この「同情プログラミング」をやめるのは、かの人にシビアすぎるような感じがするでしょうし、無意味につらくあたるような気がしますよね。いいえ。「同情プログラミング」をやめるためには、

• 失敗を前提として、コーディング期間の計画を立てる
• やり直しの時間を確保する
• 失敗しても問題が少ないところを新人に配置する

というプロジェクト運営/計画が必要です。それがなければ、単なる無法地帯で、プロジェクトの成否は偶然によって左右されているだけですよね。

6月末に出版した 現場ですぐに使える! Visual Basic 2015 逆引き大全 520の極意 なのですが、この第19章には不思議な Tips が入っています。章自体は「トラブルシューティングの極意」ということで、運用保守や設計段階の落とし穴について書いた章なのですが、最後の10個の tips が「対人関係」になっています。端的に言えば、トラブルシューティングなんて、その場その場の経験の積み重ねと、根本的な対処の方法を知っていればよいだけなので、あまり表面的な対症療法なものは、これ以上追加したくなかったんですよね。というのと、試しに「技術書に技術的なじゃないものを紛れ込ませてみたかった」というのがあります。真面目に書くと、えらい時間が掛かるのだけど、Tips 風に1頁にまとまるぐらい（1000字ぐらい）を目標に書き下してみました、という具合です。

でもって、ものがVBだったからなのか、やっぱり読者対象がずれていたのか分かりませんが、まったく反響がないので、ここにブログの記事としていくつかついかしておきます。中身的には、見積もり本舗とか消えてしまった別のブログに書いてきたものでもあるのですが、なんらかの形で検索に引っ掛かるようにするもひとつかと。あと技術顧問的なことをやるので「ここ読んで」という具合にできるようにしておきます。

タイトルはワインバーグ著「コンサルタントの道具箱」から持ってきてるので、いわゆる「ソフトウェア開発者の道具箱」です。コンサルタントだと、どこかのシャチョーさんとかマネージャーを相手にするのですが、ソフトウェア開発者の場合は同僚やプロジェクトリーダー、新人、顧客の担当者が相手になります。書籍のほうは、改変が効かないのである程度オブラートに包んで話をしていますが、バックグラウンドには行動経済学とか心理学とか孫子とかそんなものも入っています。参考文献としては「コンサルタントの道具箱」しか出てきませんが、そのあたりは「読み取って」頂くというのが主旨でもあったり、そもそも「イチゴジャムの法則」ってのがそんなものなのです。

中心に何か伝達したいものがある、というのをイチゴジャムの法則では「粒」と表しています。その粒は、広げようと薄めようと逆に濃くしようとも同じなわけで、過不足なく書けば「粒」そのもになるけど、人によって受け取り方が違ったり詳しい説明が必要だったりするときには、粒の外側に解説を付け加えます。まあ、それが書籍の売りだったりするし、「コミュニケーション」とか「会話」とか呼ばれるものですよね。ツーカーの関係であれば、メール一本で済むようなところも、顧客との関係であれば電話をするなり相手先まで行くなりの「礼儀」的なコミュニケーションを必要とします。それをしないと「コミュ障」と呼ばれたり、相手からコミュニケーションの取れない人と排斥されてりします。書籍にちらっと書きましたが、このコミュニケーションを過剰に付ける技というものあります。いわゆる「広告」的なものだったり、上滑りな議論だったり、暇つぶしのお昼のワイドショーだったりします。「粒」がないのですから、どこまでも薄く薄く引き伸ばせるし、そもそも「粒」がないのだから、議論にも反論にもなりません。ただ、ぴーちくとさえずっているだけになります。そう、暇つぶしだったらそれでいいんですけどね。残念ながら、人によっては「粒」のありかが何処なのか見えなくなってしまって、疑似的な「粒」に引っ張られて議論がどこかに飛んで行ったりします。いや、もともと「粒」がないのだから、議論自体にもならないんですけどね。

そういうわけで、とあるコミュニケーション（顧客との間柄だったり、チーム内の間柄だったり）の中には「粒」があったりなかったりするわけで、若い頃には「粒」がない会話にイライラすることもあるでしょうが、いやいや歳をとると「粒」ない会話はそれはそれとして、頭の中で別な「設計」を考えたりできるようになるので大丈夫です。そのあたりの話は、けらえいこ著「たたかうお嫁さま」や「セキララ結婚生活」に詳しく書いてあります。

ちなみに、「粒」とはいっても、クオリアみたいにこれと示せるものではありません（つーか、クオリア自体がアレなので、そういう意味では「粒」ない会話を「クオリア的な」と言ってもよいかしれません）。そこは双方の合意のものとに通じるものでもあり、共通の個人的体験の重なりや、重ならないけどツーカーに考えられる、というようなひとつの単語や文では表せないものかもしれません。明示的なものであれば、UMLのようにあらわせるのですが、概念的なものは伝えにくいので暗喩（メタファ）を使います。メタファーを重ねることにより色濃くなる中央を明らかにするんですね。これは質問の応酬という形でも表せる（ディスカッションとは違います）ので、双方、それなりの技能が必要です。そういう意味では、文体が読者を選ぶというものもあり、かつこの文章自体もそういうメタファーに含まれているという意味で、やっぱり「粒」的なものを強化するために「イチゴジャムの法則」をもう一度持ち出してみるわけです。

河合隼雄著「中空構造日本の深層」のように、中空であるからこそ中央にあるものを双方が了解できるという場合も多いのです。私はこの方法を好みますが、最近の世の中はそうではなくなりつつありますよね。実際に中央にあるものを右に寄せたり左に寄せたりすれば、当然ならが双方の主張が異なるのだから議論が一致するはずはありません。一致することもなく、妥協もせずなのだから、そこは社会は広く階層化されている（ねじれの位置にあるという意味で）交差位置で満足すればよいのです。

さて、話を元に戻すと、ある程度価値観が一緒だったり、共通の体験があれば粒を使ったコミュニケーションが楽≒効率よくなります。まあ、そこがアジャイル開発的なチームビルディングなんですけどね。スクラムの本にもそう書いてあります。ある意味で、チームで残業をしたりチームで経営的な視点を持ったりチームで趣味を共有できたり、というのは、濃厚なコミュニケーションを欲しているのではなく（そういう場合もあるけど）、仕事上の煩雑なコミュニケーションを省略するために「あらかじめ」価値観を共有するという目的があります。なので、チームビルディングにおいて、スタート時点の「価値共有」と同時に「仕事上の価値の共有をお互いに認めることができるか？」というハードルも必要となり、組織だからこ組織に成り得るという分岐がそこにはあります。

そうそう、もうひとつのチームビルディングの仕方として「オーケストレーション」もあるので、こっちのは別の機会に。いわゆる LLC（合同会社） です。