Clojureをやってみた感想

この記事はClojure Advent Calendar 2019 - Qiitaの20日目の記事。 僕はClojure使いではなく、Javaメインのプログラマーですが、一昨年からclojure勉強し始めた。最近さぼってる。。。文系出身で、CSのバックグラウンドは皆無。比較的敷居が高いと思われる言語に、初心者から見た雑感を書いてみます。

興味を持ったきっかけ

• 一人でとあるアプリをLispで書いた人のことを聞いて。個人的感覚だと一人で書ききれる代物じゃなかったので、Lispってすげえんじゃないか、という気がしてた。
• 川島さんとか、アンクルボブとか、自分がすごい、と思う人がやってた。
• 関数型言語をやってみたかった。

勉強してみたこと

とりあえず、何冊か目を通した

Programming Clojure (The Pragmatic Programmers)

Living Clojure: An Introduction and Training Plan for Developers (English Edition)

The Joy of Clojure

フレームワークもいくつか触ってみた。

GitHub - duct-framework/duct: Server-side application framework for Clojure

Pedestal

開発ツールは色々試そうとしたけど、やはり、これになった。。。Emacsは何度か試したことあったけど、やはり挫折する。

cursive-ide.com

いまだと、Vs codeでもよさそう。

よかったこと

• 関数型っぽい考え方が分かった気がする。あと、抽象として扱うことを突き詰めること。
• Repl駆動を知れた。
• Rich Hickeyという天才の存在をしったこと。彼のスピーチが（多分）分かりやすくなった。
• 本やドキュメントも全体的に鋭い洞察にあふれているのでプログラマーとしてのレベルアップにつながると感じる。
• 触ってて気持ちいい。

現時点でつらいこと

• 設計の考え方があまりパターン化されていない気がする。というより、Javaのようなレイヤみたいな考えがなくても抽象度高く書けるのでそこらへんはどう書いていけばいいのか戸惑う。Javaっぽくやるのは違うと思っているので。
• 特にJavaとの接続部分で似たような機能があって、ちょっと戸惑う。DataTypeとRecordとか。先にどっち使うか決めなきゃいけない？
• 社内のツールをClojureで書いたが、やっぱメンテ辛いらしい。S式は見た目が違うので、勉強する気を失わせる可能性がある。

今後

やっぱ、不思議な魅力があるので今後も頑張って、勉強したい。多分、身に着けると、相当品質、生産性ともに高く開発できるポテンシャルがあると思う。 使わなきゃ身につかないのでツール作るとか、色々考え中。

1on１に頼らないこと

1on1 Advent Calendar 2019 - Adventarの14日目です。ちと体調崩してアップ遅くなりました。

1on1の源流

部下との1on1ミーティングの重要性、必要性を強調したアンドリュー・グローブはコンピュータシステムの発達によって、1オン1ミーティングの頻度はずっと減るだろうと言っている。

一対一 の こうした ミーティング は 果たして 必要 なの だろ う か。 絶対 に 必要 なの だ。 それでは 10 人 の 部下 が いる 場合 でも、 ５ 人 の 部下 の 場合 と 同じ だけの 頻度 で、 こうした 会合 を 持つ 必要 が ある の だろ う か。 その 必要 は ない。なんでも かん でも ミーティング を 持つ 必要 が ある の だろ う か。 そんな 必要 は ない。 という のは、 今日 の 従業員 は 10 年前 に 同じ 立場 に い た 従業員 よりは、 コンピュータ・ネットワーク を通じて、 自分 たち の 企業 の 中 で 一体 何 が 起き て いる かを たいてい の 場合 ずっと よく 承知 し て いる からで ある。

アンドリュー・S・グローブ. HIGH OUTPUT MANAGEMENT (Kindle の位置No.447-452). 日経BP. Kindle 版.

HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント

1on1ミーティングは時間がかかる。ミーティングを有意義なものにしようとして準備なんかをしようとするとなおさらだ。アンドリュー・グローブが本を書いた時代よりはるかにシステムが発展しているはずの現代で1on1がマネジメント手法として注目されているのは、ちょっと注意が必要だと思っている。

1on1の外のマネジメント

ツール

多くの情報は例えばツールなどでタスク管理していれば状況は把握できるし、マネジメントからのメッセージも当然多人数向けのミーティングやwikiなんかの情報共有手段でアップデートされるはず。それらが有用な情報なら多くの人はそれを採取しようとする。もし、それらが受け取られていない場合は別の問題かもしれない。

MBWA(Management By Walking Around) ウロウロすることによるマネジメント

当然、対面でのコミュニケーションは大事だ。ただ、それがフォーマルなミーティングに限定する必要もない。日々ウロウロしながら声をかけながらチームや組織の状態を把握しておく、個人の仕事の状況やどのように困っているかを把握する、雑談する、困っているときに相談されやすい状況を創ることはリアルタイムで問題を把握したり対処したりすることに役立つ。

例えば、ミスが目立ったり、成果物をつくるのが遅いメンバーがいたりしたとき、ちょっと断ってどのように行動しているのかを観察する、などをするのもいいと思う。スキルが足りないメンバーはほとんどの場合、何が足りないのか理解できないので、1on1なんかの場で、自分で課題を説明させるってのは大抵正確ではないし、そこから効果的な解決策なんて生まれないのだ。加えていうと、フィードバックが最も学習効果をあげるのは、その行動を行ったとき、すかさず行うフィードバックだ。（ここらへんは、Scrum使っているときは難しいかも。）

こうした積極的なコミュニケーションは当然、1on1ミーティングで部下から話をきく必要がある情報量を下げる。普段言えないことや潜在的な課題、マネージャーと部下との認識齟齬、訓練などに時間を割くことができる。

MBWA(Management By Walking Around) については自分はこの本で知った。

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

心理的サポートと内省支援

1on1ミーティングは悩みを聞いたり、内省を促したり、といった機会を提供することもできる。また、お互いの本音をさらして打ち解ける、みたいな効用もあるのかもしれない。一方で、こうしたフォーマルな形式に依存させるのはやはりあまり得策ではなく、普段からオープンなコミュニケーションができる環境をつくる、ということが大切と思う。

ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

内省にしても、プロフェッショナルの仕事は日々省察しながら実践を繰り返すものだ。日々振り返りながらやっていくもの。

省察的実践とは何か―プロフェッショナルの行為と思考

マネジメントツールの一つとしての1on1

アンドリュー・グローブの本の中には、優れた知識をもつ部下からマネージャーである著者が学ぶ時間としている例がある。彼によれば、1on1の目的は「相互に教えたり、情報交換する」ことだ。教えるというのは、上司からの教育も、部下からの他者視点からのアドバイス、高スキルを持つ部下からの上司の教育も含むのである。これは1on1の目的が成果を上げるためのマネジメントの一つだと位置づけられている、ということだと思う。

1on1の頻度もタスクの習熟度によって変える。多くの会社で1on1を一律の頻度で実施するということになってはいないだろうか。（習熟度は、例えば二年目までは月一回のような抽象的、形式的なものでない。）

形骸化を避ける

1on1はあくまでマネジメントのツールの一つであり、効果的ではあるが、それはあくまで全体のマネジメントシステムの中で機能するものだ。一方で、何をやっているのか定義が困難な「マネジメント」という仕事の中で、1on1は「やっていること」が分かりやすく、「仕事をした気」になりやすいものであると思う。1on1をやる、という発想ではなく、マネジメントに1on1を活用する、という捉え方の方が形骸化を避けられると思われる。

創造的なチームと礼儀正しくすることについて

この記事は Engineering Manager vol.2 Advent Calendar 2019 の3日目の記事です。ちょっとまとまってないですが、何かの足しになれば。

礼儀正しくすること

個人間の社会的儀礼は、一般的に文脈を異にする人同士のコミュニケーションでは重要なものだ。儀礼を尊重することでお互いが相手にとって危険ではないことを伝えることができる。

相手のスキルの低さや成果物の品質の低さを指摘することは無礼なことと感じる人が多い。これはマウンティングと一緒で、「お前は弱く、無能で、自分の言うことを聞かなければならない」というメッセージを受け取ってしまっているからだろう。人は多分、本能的に自分を支配しようとする人、支配できる人には脅威を感じる。

マウンティングメッセージは送り手が意図的に込めることもあるし、防衛のため、無意識に込めることもある。 また、メッセージの送り手がマウンティングを意図していなくても、受けて側が勝手にそう受け取ることもある。だから、礼儀正しく、相手を批判しないことは安全なコミュニケーションになる。

また、礼儀正しさは、他人の想定外の行動や期待と大きく外れた行動や反応をしない、ってことでもある。自分は研修の仕事をしているけど、例えば、講師が丁寧に説明しているのに、話を聞かずに別のことをしていたり、演習中に泣き出してしまったりするのは「礼儀正しくない」。

礼儀正しくすることのリスク

礼儀正しさは、社会的期待に合致した行動をとること、もしくは、そうできる能力を示すことで「安全に、不安なく」コミュニケーションをとる方法であるといえると思う。ただ、それは多くの場合、本当に起きている生の出来事を多少歪ませることで達成していることが多い。初めて取り引きする取引先にも「お世話になっております」と必ずつけるメールのマナーなんかは、その典型。

こうした礼儀正しさは、切迫した、創造的な思考や行動を阻害する可能性がある。現実と乖離したコミュニケーションが増えると、複雑な場では人々は現実をコントロールする力を失う。上位マネージャは儀礼的なコミュニケーションからは全く現実が把握できなくなり、何が起こっているか分からなくなる。

マイケル・チェーホフという演技教師のメソッドを学んだとき、ファシリテーターだった方はワークショップの場で愛想笑いや、儀礼的なハグのようなものを徹底して排除していた。参加者たちは非常に集中して、今場に起きていることや自分自身に起きていることに自覚的になり、学び易い環境になったと思う。

チーム内コミュニケーションの心理面の不安などに対処するために、礼儀正しさを強調すると欺瞞が増える可能性があるのだ。もちろん、例えばサッカー選手が年上の選手のことを「~君」と呼ぶように、特殊な礼儀を導入することでそれに対処する方法もあるだろう。

起きている現実に対処すること

レビューなどを含むチーム間のコミュニケーションで問題が起きているのであれば、それを礼儀正しさを強調することで対処して現実を隠すのではなく、現実に起きている事象に試行錯誤しながら取り組んでいった方が益が多いと感じる。

例えば、レビューなどの場でチームで期待された水準に達していない成果物であることが判明したときに、レビューイが「傷ついた」場合、いくつもの対処しなければならない事象がある。レビュー以前にスキル不足やリソース不足が判明しなかったのはなぜか、判明しても対処できなかったのはなぜか、そのほか、レビューの結果を個人的に受け止める必要はない、ということやプロとして仕事の評価を受けることは当然である、という認識の不足。チームとしての結果にフォーカスできていない環境などなど。

高スキル者が強い言葉で相手を批判する場合なども、何が起きているか、どうしてそのような行動パターンをとるのか、を理解すれば大抵の場合対処は可能だし、対処方法が分からなかったとしても、現実の問題を高スキル者と共有すれば改善してもらえるものだ。単に言葉の選び方を知らなかったり、問題を認知できていなかったりするだけの場合も多い。

例えば先に挙げた、講義を聞かない受講者の場合、かなりの確率で話についていけず、理解できていないことが原因だ。自分としては、話を聞かなくてもいいから、相当初期の内容を復習するように指示することが多い。（わが身を反省しつつ。。。）ここで、分からなくても聞け、というのは学校の教師がよくやることだが、学習に何のメリットもない。

礼儀正しさを強調して、表面上の心理的安全性を達成しても、「見えないルール」や「欺瞞的なコミュニケーション」が増えればチームの能力に悪影響を与えるリスクがある。

儀礼はコミュニケーションを密にできない人々や複雑性に対処する必要のない場合には有効だ。店頭での商品の売買などは儀礼を適切に使えるシーンだ。ソフトウェア開発はその真逆の状況だと思う。

ちなみに、原因を理解しようとして分からない場合は、分からない、ということを認めてパッチワークをすればいい。原因は大抵複合的だから、対処法はやってみないと分からないことも多い。問題の定義をすることの方が何倍も重要だ。

ヴィゴツキーにおける科学概念と生活概念の発達の違いとその意義

先日、この本を読んだ

「発達の最近接領域」の理論―教授・学習過程における子どもの発達

第6章の「生活的概念と科学的概念の発達」についてメモ。

ヴィゴツキーによれば、学校で教えられるような科学的概念の発達と生活概念の発達は、相互に関連しつつも別の経路をたどるという。

その中で、彼は、「であるから」のような言葉を歴史学習の問いかけでは正しく答えられるのに、現実の生活の例だと正答率が落ちるような例をあげている。

彼によれば、無自覚に習得した生活概念が強いところでは、自覚的な科学概念が弱く現れる傾向にある、という。

研修をやっていると、こういうのは至る所で見る。机上の空論と呼ばれるやつだ。学習の文脈の中では言葉上で理解しているのだけど、現実に当てはめることができない。新しく学んだことを利用するのではなく、古い慣習的なものの見方をつい、適用してします。

つまり、生活概念が邪魔しているのだ。ヴィゴツキーは、第二外国語を学ぶ時にもこれと同様なことが起こっているという。

さらに、科学的概念を生活の文脈の中で適用できるようになるには、その概念の内在的な成長、そして、教師などによる支援が必要になってくる。

ここまでの議論で自分が受けた示唆は以下の点だ。

一つは、学んだことが現実に適用できず、言葉だけのものであったとしても、それは科学概念の萌芽なのであって、無意味ではない。それどころか、実践的に学んだことを適用するために不可欠である、ということ。

２つ目は、生活概念が邪魔をする、ということを教師も理解しつつ、辛抱強く新しく学んだ科学概念がその生徒の内面で発達してくることを待ちつつ支援する、ということが重要だということ。

---------

追記:ヴィゴツキー 『教育心理学講義』では、現実的に表象できるようにしなくては、砂上の楼閣だと言っている。上で書いた「言葉だけの理解」というのはよろしくないということになるだろう。概念として、未熟なものであっても、現実に根差した表象は伴わないといけない、ということだと理解している。

----------

創造指向と問題解決指向の違いについて

ロバート・フリッツがよく言っていることだが、

創造（Creation）と問題解決（Problem Solving）は全く違う。

なぜ、それが強調されなければならないのか、というと両者は表面的には似ているから。

ロバート・フリッツが定式化したシンプルな創造プロセスは下記のようなものだ

www.soljapan.org

望む結果があり、現在存在している現実がある。その差異がエネルギーを生み出す。

一方で、G.M.ワインバーグの定式化した問題の定義は下記のようなものだ。

望まれている状態と現在の認識の差異

参照

ライト、ついてますか―問題発見の人間学

コンサルティングやシステム開発のビジネス要件定義などで行うGap分析もこれだ。

果たして両者に違いはあるのだろうか。文章だけ読んでいただけでは、その違いは明確ではない、自分もよく分からなかったし、その違いは重要ではないと思っていた。。

だが、最近これを区別することはかなり実践的なインパクトがある、と考え直すようになった。

指向（orientation）の違い

今のところの自分の理解では、創造（Creation）と問題解決（Problem Solving）の違いは、その出発点と方向。英語のOrientationの違いにあると考えている。

問題解決（Problem Solving）は現状の不満、不足、マイナスから始まる。現状の評価から出発する。現状から離れることが目的。成果はそれほど重要ではない。多くの場合、抽象的な「完璧モデル」や漠然としたイメージから「望んだ状態」を定義する。

創造（Creation）は出発点において現状を評価しない。ニュートラルにみる。創り出したい状態から現状を見てその違いを識別するだけ。その差異の認識がエネルギーを生み出し、創り出すことを後押しする。

問題解決（Problem Solving）は現状から離れることに主眼があるため、対策が効果を持ち出すとどうしても望んだ成果へ向かうエネルギーが失われていく。そのため、ある程度の対策をすると問題が解消され、次に問題が再発生するまで放置されることになる。問題発生→解決→放置→発生→解決のサイクルを繰り返す。

創造（Creation）はその成果が実現されるまでエネルギーが失われることはない。また、その成果が得られてから失われることはない。新しい創造の土台になる。

創造指向（Creative Orientation）の肝は、最初に現状を抽象的な評価基準を持ち込んで、評価することをやめることだ。ビジョンを定義し、そこからの差異としてのみ現実を評価する。

ワインバーグの問題定義は、おそらく、問題解決指向（Problem Solving Orientation）から創造指向（Creative Orientation）への変換、どこへ行きたいのか、という問いを根本的に問い直すきっかけを確かに与えてくれるだろう。ただ、ビジョンもなく、現状の分析から始めるだけでは、「望まれた状態」はでっち上げられたものになる。

創造指向（Creative Orientation）において、現実はただそこにあるだけなのだ。画家がキャンパスを前にしたら、それに絵を描いていくだけ。キャンパスの材質が悪い、とか、小さいとか、キャンパスを修理し出しても絵は完成しない。

そして、創造は常に、選択でもある。やってもいいし、やらなくてもいいことなのだ。

不満のない状態から目指すものを見つける、というのはある種のスキルだ。そこに理由は不要。カレーが好きとか、野球がしたい、とかそういう純粋な動機。多くの大人はこれを失っている。

増田さん/@irofさんのDDDサンプル徹底解説についての雑感

jsug.doorkeeper.jp

本当に面白かった。DB周りの質疑も楽しかった。

内容は他の方のブログ参照。

これとか

takeda-san.hatenablog.com

以下雑感

DDDと増田さん流のOOPを使ったアプリケーション開発

個人的にDDDというのは、アプリケーションの目的であるユーザー世界の関心毎を中心に置こう、というだけでコンセプト自体はそんなに特殊なものではなく、ソフトウェアエンジニアリングというか、プログラマー界隈では多くのグルたちが同じようなことを目指していたと思う。要するに関心毎の分離。

いくつかの重要なアイデアが発明されたけど。RepositoryとかAggregateとか、境界づけられたコンテキストとか。

いくつかの点で増田さんのやり方はエバンズが本で書いたものとはずれてたり、ポイントが違っていたりするから、DDDということではなく増田さんというプログラマーの先輩によるOOPを使ったアプリケーション開発の解説、ということと捉えている。

ドメイン層の解説と質疑聞きながら思ったこと

• ドメイン層は条件分岐と計算ロジック、という整理はかなりしっくりくる。改善の指針にもなる。入出力の関心毎はドメイン層ではない所に追い出すこととなる。
• フィールドのゲッターをフィールド名()というメソッドにしている。役割はゲッターだけど、getはいらない、可読性優先、ということという。確かに見やすい。C#とか、Kotlinとかプロパティが機能としてあるけど、目的は同じと思う。
• パッケージ構造/関連の重視。一貫して、コードをドキュメントとして扱えることを目指していると思うが、このパッケージ構造の重視も面白い。変な循環参照なんかはコードの不吉な匂い、ということ。
• Java標準の型ではなく、汎用的なDateとかの型を定義している。それはいいんだけど、PayRollというすごく抽象度の高い、というかコアなクラスのメソッドで汎用型が顔を出すのは、自分としては納得がいかない。後でコード見て考えてみたい。
• 試行錯誤の過程を見せてもらえたってのはすごく大きい。可読性、パッケージの関連、見た目の感覚、ドットの数,一覧。こういうものを手がかりに改善していく、ということ。
• 動くものを作ってから改善していった、ということらしい。多分、経験豊かな人なら最初からやれるんだろうけど、多くの人がこれをやる指針になると思う。

アプリケーション層とインフラ層の解説と質疑聞きながら思ったこと

• Repositoryはアプリケーション層。これはすごく面白い。これまで、入出力はIoCを使って隠蔽し、インタフェースのみをドメイン層としてきた考えだったけど、現実として、インタフェースにも入出力の考慮が出てきてしまう。Repositoryそのものをドメイン層から追い出したことで、アプリケーションの処理方式に基づいた様々な考慮がアプリケーション層で記述する、という形にすることができる、と感じた。
• 履歴の追加と最新状態の書き換えは別トランザクションにしている、とのこと。ここは理想としてはそうしたいものだと理解している。現実的に一つのアプリだと、１トランザクションにしてしまった方が楽とは思う。ただ、どちらにしてもそれらはアプリケーション層の関心毎。履歴の追加と最新状態の書き換えは別の仕事ということかと
• トリガーを利用して最新の書き換えをDB側でやっていて、うまくいっている、という方がいた。個人的にトリガーでやりたいな、でも怖いなあ、と思ったことはなんどもあるので、それで行けるんだなあ、と思った。こういうの挑戦するのはすごいな。考慮すべきは、ソースからその処理の情報が消えることかな、とは思う。ソースを読んでもアプリの全体像が分からなくなる。ドキュメンテーションとしての機能が奪われる気がする。ここら辺は方針の問題。
• DB例外（多分ユニーク制約違反とか）とかは基本的には起こらないようにする。起こるのはシステムエラーなので例外なげて終わらせる。これ、そうだよね、という気がする。
• JSONとかは、ドメインオブジェクトをそのまま出したい。階層深くなるけど、ということ。ここ、個人的にかなり悩んでた。結局階層が不自然だから、詰め替え発生するよなあ、と。ここら辺を綺麗に、ということならプレゼンテーターを導入してもいいんだろうなとは思う。
• 画面、API共に詰め替えをする時もある、とのこと。個人的にどこを綺麗にしていくか、ということかと。

JIGも素晴らしかった。 

効果的な研修について

研修の有効性

学校でのお勉強が役に立たないのと同じように、脱文脈化された死んだ知識はどんなに頑張って暗記しようとも役には立たない。

多分、最もやりやすくて効果的な研修は、文脈を同じくする社内での実践知を形式知化して、知識付与→実践とフィードバック→振り返りによる改善　 のサイクルを回していくことだと思う。

下記の本では、やって見せる　→　種明かし　の効果も述べられている。

リーダーが育つ変革プロジェクトの教科書

大事なことは文脈を失わないこと。

効果的な研修とは何か。

効果的な研修にはいくつかのパターンがあると思う。

• 複雑なスキルや知識だが、On-the-JOB での実践的なフィードバックと組み合わされているもの（一般的なソフトスキル、コミュニケーション/問題解決などがフィットする。）
• 煩雑なスキルや知識だが、体系的に整理され、かつ、受講者に前提知識やスキルが確保されているもの（ソフトウェアのフレームワークの知識とその利用などがフィットする。）
• 比較的単純な技術の反復トレーニング（単純なコーディングスキルやアルゴリズム構築などがフィットする）

上記が比較的やりやすいものだが、もう一つのカテゴリが上記の合わせ技。 「複雑なスキルの土台にある機能しているシステムを、理解しやすい教授用モデルとして提示し、それをトレーニングする」

というやつだ。こういうのは、複雑系のスキルのトレーニングにも有効。

このモデルは、実践の中でスキルを拡張し、現状に適応し、成長していくための種になる。

理解しやすいモデルにする、ときの注意点は、簡単にしようとして実践で活用できないモデルにしてしまうこと。これは職業講師や著述家などがよくやる。アンケートや評判がよくなるから。

この「理解しやすい教授用モデル」というのは、熟達者すら自覚しきれていないイノベーティブなアイデア。とうぜん、モデルに完全な最終的な解はなく、継続した洗練が必要である。古来優れた教育者には知られてきたものだけど、ユーリア・エンゲストロームが分かりやすく定式化している。

mattun.hatenablog.com

実例

• 柔道における「崩し」と「つくり」と「掛け」。ただし、洗練度はいまいち。

• 演技におけるスタニスラフスキーシステム。これは本当のイノベーション。

  俳優の仕事―俳優教育システム〈第一部〉

  演技ー創造の実際―スタニスラフスキーと俳優

• オブジェクト指向のこころ。デザインパターンそのものは、教授可能なモデルとしては洗練度がいまいち

  オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

• ワインバーグの有機的リーダーシップ論。ＭＯＩ

  スーパーエンジニアへの道―技術リーダーシップの人間学

• スペインサッカー

  サッカーの新しい教科書 戦術とは問題を解決する行為である