非IT系にもおすすめなリモートワークに便利なタスク管理ツール「Redmine」

ふと思い立って。

IT系の人には常識になっているけど、たぶんリモートワークにもかなり使えるツールとしておすすめしたいのが「RedmIne」

redmine.jp

本来は準備が必要なツールだけどWebサービスとして提供している会社が複数ある。

lychee-redmine.jp

hosting.redmine.jp

チケット管理ツールは色々あるけど、IT向けに特化しているものも多い。Redmineはその点、使いやすいと思う。

チケット管理とは

この手のツールは、タスクや問い合わせなど、何か作業が発生するものを「チケット」として定義して作れる。計画があってもなくてもいいので、突発的に発生する作業なんかもチケットにしておけばよい。

チケットには、担当者の他、チケットについて話した内容やその他なんでも情報を追加できる。

チケット管理ツールの良いところ

• 今、誰が何をやっているのか。誰もやっていないタスクは何か、等が可視化できる
• 経緯（誰がそれについてどんな作業をしたのか、）が分かる
• なれると結構気軽にチケット上でやり取りできる

特に素晴らしいのは、履歴が全て残るという点。

あるタスクについて相互にボールを投げ合うってことはよくやられるが、それをチケット上でやる。

「このタスクについて〇〇さん、こういうことお願いします。終わったら僕が残りやります。」

みたいなとき、チケットの担当者をその人に切り替えて依頼すればよい。担当者が変わった履歴もチケットをみればわかる。

注意するべきところ

多分作業内容を明確にすることは慣れていない場合が多いので、「~の件」みたいな曖昧なチケットでも最初は良しとした方がいい。ビデオ会議ツールやチャットなんかで補足する。

むしろ、雰囲気でマネジメントしていたことが可視化されただけだから、それをすぐに変えようとして、無理やり細かく書かせようとすると効率が落ちると思う。

システムの複雑さについてのメモ

これをみて、改めて、システムの複雑さについて考えてみた

Udemy System Thinking Made Simple

複雑さを生み出すもの

Rich Hickeyの下記のプレゼンで複雑とは複数の意味をもっちゃうものと定義していることから発想。

Simple Made Easy

役割が定義できない要素の存在が複雑さをもたらす。機能や特性が要素に還元できない。例えば以下のようなもの。

• システムの要素が担う役割が状況や時間の経過によって変わる

• 要素が複数の役割を兼ねる

複雑なシステム

• 人間の運動。筋肉のある箇所を使ったり使わなかったりして同じ機能を果たすことができる。
• サッカー。局面によってFWも守備をする。DFも攻撃する

人間組織の複雑性

人間行動が絡むと殆どのシステムが複雑さが増す。 人間は個々人の判断で適応行動をするから

• 一つの機能を果たすために様々なロールを担う。ロールが流動する
• 様々な機能を求める。製品を出力するだけではなく、給与、地位、人間関係、自尊心を与える機能を担う

制御するために必要なこと=ゴールの共有、プレーモデル/ロールの調整、満足する給与/関係性/承認の提供

情報システムにおける複雑さ

• コンポーネントの役割分担を進めるのが吉
• 一つのコンポーネントが何役もやるのが複雑さを増す
• 非機能要件もコンポーネントに還元できるのが吉
• 性能などの一部の要件は機能を実現するコンポーネントが担うため、複雑になりやすい。並行性を高めることは性能要件を並列実行数に還元できるようになるため、複雑さを抑制することになる

複雑さの価値

刻一刻と変化する状況に対応するためには、複雑かつ、自己組織化システムの方が適応しやすい。シンプルなシステムは柔軟性に欠ける。 情報システムは人の手によってしか変更されないからシンプルさが価値をもつ

にわかサッカーファンによる久保建英論

自分はサッカー経験なしで、観戦経験も薄いにわかファン。ガチのサッカーファンは妄想だと思ってスルーしてください。

ふと、youtubeで久保建英のプレーを目にしてからハマった。釣られてサッカー見出したら、面白くて、サッカーの戦術本とかも買いあさってしまった。

こんな記事も書いた。

mattun.hatenablog.com

最近の息抜きは久保建英の記事とか、youtubeとかを見ること。インプットするとなったら凝るので結構久保建英オタクになっていると思う。

久保建英選手について

サッカーのスペイン、ラ・リーガ1部に挑戦中の久保建英。スター軍団のレアル・マドリードと契約して、2020年3月現在は１部昇格したマジョルカにレンタル移籍して奮闘中。

詳細はこちら。

ja.wikipedia.org

10歳でFCバルセロナの下部組織に入り、そこで大活躍。中学生のときに日本に帰って話題になった。中学生の時は高校年代、高校生の時はJ3と、基本的にかなり年上の集団に混じってプレー。中学生で高校年代の大会での得点王とか、Jリーグ最年少ゴールとか、二番目に若い日本代表への選出とか。18歳でレアル・マドリードと契約。多分、Bチームの補強だったと思うけど、レンタル移籍してスペイン一部でプレー。下位チームで苦労している。

騒がれる理由と何故か多めな懐疑論

FCバルセロナは組織や特殊で、特に下部組織での育成が非常に有名。メッシを筆頭に、イニエスタ、シャビ、ブスケツみたいな世界最高レベルのテクニシャンたちを育ててきた。その下部組織で中心選手として活躍していたから、当時から日本中の期待を集めてた。自分も当時から名前は聞いたことがあった。

ただ、日本に帰ってから、自分みたいな熱狂的なファンとともに、アンチもかなり多い選手。なんか、人の感情を左右させる不思議な魅力がある。

それとは別に、今年J1でブレイクするまでは、もしくは今現在もかなり懐疑論が多かった印象。

hominis.media

それはなんとなく分かる。J3での試合とか結構埋もれていた。「上手いけど。。。」それだけの選手なのではないか、と感じさせるものがあった。

選手としての特性と評価

長所

サッカーIQの高さ

バルサ時代から、そして、現在も懐疑的な人も含めて誰もが認める選手としての長所は頭のよさ、戦術理解、プレービジョンみたいな言葉で表現されるところ。ゴールから逆算してプレー選択を考えられる。純粋な頭のよさに加えて、オタクが好きそうな戦術論をおそらく知識としても理解している。また、自己認知力が異常に高く、自分を客観的に分析して努力できると多くの人が評価している。

コミュニケーション力/メンタルの強さ

年上に混じっても物怖じしない、ピッチ外、ピッチ内でのコミュニケーション力も高いと多くの人が認めている。スペイン語はネイティブレベルで、英語で記者からの質問に答えることもできるだけの英語力もある。数学があんまり好きじゃないと言っていたが、多分、語学の天才系だと思う。

技術

ドリブルを筆頭に、パス、シュートの技術が高いとされる。そこら辺は下記の動画に詳しい。

www.youtube.com

現状、

ドリブル > パス > シュート

の順で得意なんだと思う。毎試合改善しているが。

認知能力・視野

首振りが異常に多く、プレー中、常に状況を確認している。それによって判断の質を挙げているし、プレーの精度も上げている。

個人的な評価

詳しい人には理解されているが、久保選手のパーソナリティは天才タイプのそれではなく、超努力型。課題を明確に定義して一歩一歩克服していく努力の天才。

ボールを扱う技術みたいなところはそこまで才能のある選手じゃないと思っている。小野伸二や宇佐美みたいなボールタッチと比べるとどこか人工的な感じがする。まだ、考えてプレーしている。第二の天性のようになるには多分、もう少し時間がかかる。選手としての特性から考えると晩成タイプのはずだけど、親の英才教育によって若くして活躍している、と思っている。

こういうところが久保に懐疑論が出てくる理由な気がする。

英才教育

このレベルまでいくのは本人の努力と才能はもちろんだけど、どう考えても親の教育がすごい。本人も父親に全てを教えてもらったと言っている。細かいタッチのドリブルなんかはお父様がメッシを研究して教えたのではないかと思っている。

バルサに行った子供の頃からプロが使う体幹トレーニングのジムに行ったり、中西のパーソナルトレーニングをつけたり、まあ、すごい。長友と同じトレーニングを10歳からやっているわけだ。

久保建英の本当の才能

さて、ここからが自分が本当に書きたかったことなんだが、久保選手はよく、「上手い」選手で、周りとの連携が鍵、と言われているんだが、自分はそう思っていない。何年か後に答え合わせするために自分の直感を書く。

前に書いたように、久保のボールを扱う技術は英才教育と本人の努力の成果でトッププロの中では突出した才能ではないと思ってる。

彼の他の人に容易に真似できない本当の才能はむしろ、弱点と思われてきたフィジカル面だと思っている。

ボディバランスと体の使い方の上手さ。

フィジカルが弱かった時からシュートの威力があったこともそう。これは小さい頃から。そして、姿勢がいい。体幹トレーニングをつんでもあそこまではいかない。武道家のような立ち姿。これが彼のプレーを独特のものにしている。パスやシュートよりもドリブルがまず通用したのはそれが原因と思う。

自分はサッカーみたいな球技はそこまで好きじゃない。やっているのは柔道（弱いけど）。そして、自分が昔、久保建英と同じように惹き込まれたサッカー選手は柔道の経験もあったこの選手。

レアル・マドリーのレジェンド。

www.youtube.com

ジダンがボールをもつと時間が止まると言われた。独特の間で局面を打開してしまう。体の使い方が美しい。立ち姿だけでも絵になる。久保建英も立ち姿が綺麗。自分はそういうのに惹かれる。

もちろん、長い手足を利用したジダンとは違うけど、相手に飛び込ませず、間合いを制して決定的なプレーをする、みたいな片鱗は見せている。

今はまだ体ができていないから、彼の本当の才能が発揮されていない。21歳くらいになったら、その真価がようやく見られ始めると思う。対人がめちゃ強くなると思う。

また、個人で局面を打開する、すごい選手になりたい、と昔インタビューで言っていた。

久保建英の未来予想：バルサよりマドリーの方が似合っている

今のマジョルカでのプレー。バルサでの久保を期待していた人には辛いかも。そして、何人かのプロ選手が、「連携で生きる」久保がいきない環境だと評価している。

自分はまだ開花していないだけで、下位チームでも試合を決めてしまうタイプの選手になると思っている。それが世界のどのレベルまで行けるのかは分からないけど。

自分の久保の未来予想は下記。

• 連携して崩すだけではなく、ボールを持ったら独特の間で場を支配して、局面を一人で打開してしまう強烈な個。
• 自分の体の特性を生かした鬼のキープ力

もちろん、頭のいい選手だから戦術的な行動も取れる。

だから次のように思う。

未来の久保建英に似合うチームは連携のバルサではなく、個の集まりであるレアル・マドリー

本人は案外個人技が求められる今の環境を楽しんでいるのではないかと思っている。

書評『A Philosophy of Software Design』:古典的かつ本質的な設計論

ここ数日で読んだ下記の本。非常に感銘受けたので書評を書く

A Philosophy of Software Design

著者はスタンフォードで教えているが、元実務家らしい。大学のコースの内容を本にしたものという。研究領域は比較的低レイヤっぽい。題名は訳すと「あるソフトウェア設計の哲学」

総評

ソフトウェア設計を複雑性（complexity） を減じるためのものだ、という基本的な考えのもと、非常に実践的なアイデアが学生のよくある間違いや好ましい例とともに記述されている。UNIXの設計を良いものと主張する場合が多い。間違いの例などは自分もやっていたな、と思うものもあり、かなり考えさせられる。数年教えてきた内容を使っているので、伝え方がうまい。

基本的なアイデアは古典的なものであり、目新しいというより原点回帰の設計論。当初はビジネスアプリケーションの設計には微妙かな、と思ったが、むしろ大事と思った。

アジャイルの罪

いくつかの議論は、いわゆるあちらのアジャイルのグルたち（アンクル・ボブやケント・ベック）と違うことを主張している。例えば、Unit Testには肯定的だが、TDDは設計を疎かにする恐れあり、として否定的だ。また、「クラスは小さくすべし」というアンクル・ボブの勧めに対して、「小さく分けすぎるな」という。

何も考えずにアジャイルで機能中心にガンガン作るってのをやると良い設計にならない/技術的負債がたまるって認識がそろそろ一般化してきていると思われる。その対策としてDDDなんかが注目されているのだと思うけど、この本に書かれているような基本的な哲学を抜かしてそこに向かうとなかなか厳しいことになると思われる。

こうした短期的な機能中心のプログラミングを著者は戦術的プログラミングと呼び、より長期の良い設計を探究しながら行うプログラミングを戦略的プログラミングと呼んでいる。TDDや機能中心のアジャイルは戦術的プログラミングを助長するという。

私見としてはプラクティスの提唱者たちは本書における基本的な考え方を身につけているから害はないのだろう。

抽象化というプログラミングと設計の核心

著者はインクリメンタルな開発には賛同するけど、それは機能（feature）単位ではなく、抽象単位であるべきだという。モデル単位と言い換えてもいいと思う。

「インクリメンタルに開発する」というのは一般的にはいいアイデアだ。だが、開発の増分というのは、機能ではなく、抽象であるべきだ。もちろん、機能によって抽象が必要とされるまで考えることを延期するのはいい。だが、ひとたび、抽象が必要とされれば、適切に設計するのに時間の投資を惜しんではならない。

TDDが設計を阻害するメカニズムとして次のように述べている。

テスト駆動開発は過度にインクリメンタルだ。...抽象化が必要になったならば、その抽象をバラバラに作り出すことをしてはならない。抽象は全体を一度に設計しなければならない。（もしくは、ある程度核となる機能のまとまりを提供できるだけの大きさは必要だろう）

ある程度一般的なモジュール（somewhat general-purpose fashon）

著者がいう抽象化のための実践的な指針が「ある程度の一般化」だ。SI稼業で何らかの成功体験がある人は、顧客の要件を鵜呑みにせず、後でどうにでもなるような仕組みを提供してうまくいった経験がある人は多いだろう。これはG.M.ワインバーグが著書でも触れていたテクニックで、長い歴史がある。

ただ、この一般化をやりすぎると結局何ができるのかが分からなくなったり、複雑性が設定ファイルやテーブルのデータ内容に移動しただけ、ということになりかねない。SIのプロジェクトでもよく見る。なんでも入るテーブルみたいなやつもそれだろう。一般化のしすぎ。

著者は個別の煩雑な要件を満たし、かつ、複雑性を減じるようなバランスの取れた一般化された目的のモジュールを設計することを推奨している。著者の例はテキストエディタの編集処理の際にUIモジュールから呼ばれるメソッドだ。

個別のユーザーの操作に対応したメソッドを一つ一つ提供するのではなく、より一般的なメソッドを提供し、それをUIが使う。

個人的にはこれらの工夫はドメインモデリングにつながると感じた。ソフトウェアのUIの下の層にドメインの本質が構築される。多分、いいUIはその下の層と操作も一致するか近しくなる。

ソフトウェア設計の本質への回帰

本書はUNIXのファイルアクセスやネットワークプロトコルのソフトウェアとしての設計などが多く出てくる。

近年のDDDなんかだとともそれば、基盤的要素は軽視されがちだけど、ソフトウェアを作る上ではそれらも大切な要素の一つ。むしろ、技術的な要素は上手く設計がされている場合が多いから問題にならない、といった方がいいかもしれない。TCPを意識することが我々があまりないってのは偉大な設計の勝利なんだよな。

この本は現代のプログラマが、ソフトウェア設計の歴史的な蓄積を身につけるのに非常に優れた本だと思う。そしてそれは新しいテクニックをみにつけ、活用するための土台になる。

こういうのが大学で教えられている、というのは非常に素晴らしいことだな、と思った。

独断と偏見にもとづく政治について学ぶための推薦図書

眠れないので、ふと昔を思い出して記事を書くことにする

自分の背景

• 政治学修士。研究者の道は挫折。今はIT業界。王道の政治過程論、政治哲学、比較政治学その他のものは基本ナンセンスだと思って、地域研究を専攻してた。

• 政治的志向は、中道右派 / 平等 < 自由と公平 / 適切に管理された市場経済の信奉者/ 立憲主義万歳 / 社会権等は擁護

全く知識がない人へ

高校の教科書がおすすめ。なんだかんだ言って、日本の教科書はレベルが高い。検定教科書はアップデートもされていくのでそこも良い。

最新政治・経済　新訂版　［教番：政経313］　文部科学省検定済教科書

高校倫理　新訂版　［教番：倫理312］　文部科学省検定済教科書

俺的おすすめ

かなり変わったおすすめだと思う。

ベースの本

日本国憲法論 (法学叢書 7)

とりあえず、これを読んでおけば生きた政治のかなりの部分が学べるんじゃないかと思う。佐藤先生は政治理論とかも参照しながら統治制度なんかも解説している。抽象的な人権論とか、政治哲学なんかより、実際に生きた人間に影響を及ぼした判例って事例から学べることは多い。まあ、６００ページ以上あるので、佐藤先生の他の本でもいいかも。でも網羅しているのはこれだから。

危機の二十年――理想と現実 (岩波文庫)

政治における力と理想や規範/法の問題についての切れ味鋭い論考。国際政治の古典だけど、リアリストとユートピアンのアイデアの対立はあらゆる政治現象で見られるものと思う。

アメリカにおけるデモクラシーについて (中公クラシックス)

政治学の天才。トクヴィルが19世紀のアメリカで現実に行われている民主主義を鋭く分析した名著。やばい。。。

歴史

抽象的な政治学談義は無視して、実際に我々人間がどんな政治を行ってきたのかを知ることはとてもためになると思う。近代以降の歴史を知れば今を理解する助けになるし、古代の様々な歴史は時を超えて普遍的な原理を見出すのにいい。 個人的には

• 近現代ヨーロッパ史（どのように国民国家が生まれ、民主主義が広がって行ったのか、どのような差異が地域であったのか）

• 近代以降の世界史（ヨーロッパに世界が支配され、その支配がどのように瓦解して行ったのか。ヨーロッパにどうやって対峙して行ったのか、戦後の経済発展と民主主義の広がりと失敗）

• 幕末以降の日本史(西洋の衝撃をどのように受け入れ、近代化を成し遂げ、破滅の戦争に突き進んで行ったのか。)

あたりのテーマが今生きると思う。昔なら、ソヴィエトというものを理解しなければならなかったけど、今は、多分、開発独裁みたいな文脈で理解すればいいんじゃないかと思う。本はたくさんいいのがあると思うけど、個人的にマニアックな本をいくつか。

敗北を抱きしめて 上 増補版―第二次大戦後の日本人

アメリカ人による日本研究者の戦後史。視点が新鮮。

ゾルゲの見た日本【新装版】

ソヴィエトの対日スパイだったゾルゲの分析。戦前の日本の軍国主義化の根底にあった構造への鋭い洞察。

ヨーロッパ史については最近すごくいいシリーズが出てたね。

力の追求(上):ヨーロッパ史1815-1914 (シリーズ近現代ヨーロッパ200年史 全4巻)

フランス革命

フランス革命とナチスドイツ/ファシズムというのは、政治学における非常に重要なトピックだけどここでいくつか。

[新訳]フランス革命の省察 「保守主義の父」かく語りき

政治的洞察の天才エドモンド・バークの古典。フランス革命の徹底的な批判書。保守主義の父と言われるけど、彼はアメリカの独立には賛成した改革論者。 頑迷な保守主義者ではない。彼の論理は、フランス革命をある種の模範としたロシア革命やその他の革命がなぜ、殺戮と独裁に帰結していったかを恐ろしいほど的確に洞察している。 岩波の訳書では「バークに学ばずに政治を行うのは、海図のない航海のようなもの」という言葉が出てた気がする。

フランス革命についてはいろんな新しい歴史書があるけど、個人的にはトクヴィル先生の下記の本がお気に入り。歴史学的には多分、今では突っ込みどころ多いかも。

旧体制と大革命 (ちくま学芸文庫)

ハンナ・アレントの下記の本もどちらかというとフランス革命に批判的。

革命について (ちくま学芸文庫)

民主主義の可能性と限界

大衆心理についての警句

世論〈上〉 (岩波文庫)

民主主義のダメさ加減は、古代ギリシャやローマの歴史を学ぶといい。そして、個人的にはおすすめなのが下記。

政治学 (西洋古典叢書)

古典中の古典だけど、普通に政治学の本として読めると思っている。

法学

民主主義にはいろんな欠陥があるわけだけど、現代でうまくいっている要因のかなりの部分が立憲主義と法の支配、人権概念みたいなもののおかげと思っている。その根底には法についてのアイデアがある。下記の本も好き

法における常識 (岩波文庫)

理系っぽいやつ

組織の限界 (ちくま学芸文庫)

つきあい方の科学:バクテリアから国際関係まで (Minerva21世紀ライブラリー)

感情の役割。なぜ、これが絶版なんだ？？？

オデッセウスの鎖―適応プログラムとしての感情

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を活用する、という捉え方の方が形骸化を避けられると思われる。