« 2020年4月 | トップページ | 2020年6月 »

2020年5月

2020/05/30

「人工知能は人間を超えるか ディープラーニングの先にあるもの」の感想

「人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書) 」がとても良かったので、感想をメモ。
ラフなメモ書き。

たまたま古本屋で「人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書) 」を見つけて立ち読みした。
2015年出版なので、内容は古いだろう、と勝手に想像していたら、ディープラーニングや機械学習の概念の比喩や説明が非常に分かりやすくて、良い本だった。

興味を引いたフレーズ、理解した内容は下記の通り。

人工知能は、飛行機の例と近い。
人は飛ぶために鳥の真似をするような羽ばたく飛行機を作ろうとして失敗した。
実際は揚力という概念を見つけて、揚力を得る方法をエンジンによる推進力で実現することで、工学的に解決できた。
同様に、人工知能も、人の脳みそを真似したとしても、実装方法は生物と同じようにやる必要はない。
人工知能でも、知能の原理を見つけて、それをコンピュータで実現すればいいだけだ。

機械学習は所詮、力任せに探索手順を全て探すアルゴリズムに過ぎない。
ただし、人工知能ブームを経ていくつかの成長がある。
一つは、膨大なデータを元に機械学習をさせると、より良い特徴量が発見できてきたこと。
たとえば、将棋ソフトの特徴量では、以前は2つの駒の関係だったが、3つの駒の関係を使った方が有効だと分かってきた。

2つ目は、スコア評価にモンテカルロ法を導入して、ある局面まで来たら、人間が重み付けで評価するのではなく、ランダムに数億手を探索させてスコアを評価させる。その中から良いスコアの探索手順を選ばせる方が精度が高い。
コンピュータによるシミュレーションで膨大に計算できるのだから容易いこと。

ニューロンの誤差逆伝播のたとえ。
ある組織の上司が判断を下す場面で、部下からの情報を元に判断を下す。
自分の判断が正しかった時、その判断の根拠となった情報を吸い上げた部下との関係を深めて、判断が間違った時はその間違いの原因となった情報を吸い上げた部下との関係を弱める。
これを何度も繰り返せば、組織として正しい判断を下す確率が上がる。
つまり、正しい判断材料が部下(下)から上司(上)へ上がる一方、修正を加える時は、上司(上)の判断の誤り(誤差)から部下(下)との関係の強さに修正を加えるので、誤差は逆伝播するわけ。

しかし、上司と部下の距離が遠すぎると、誤差逆伝播による修正の情報は届きにくくなる。
この比喩は、ニューラルネットワークの誤差逆伝播は、組織の情報伝達と似ていて非常にわかりやすい。

機械学習は、ニューラルネットワークを作る学習フェーズと、できあがったニューラルネットワークを使って正解を出す予測フェーズに分かれる。
学習フェーズの作業はとても時間がかかる一方、いったんニューラルネットワークが完成すれば、予測フェーズは一瞬で終わる。
たとえば、人間も学習している時は体得するのに非常に時間がかかるが、学習した成果を使って判断するのは一瞬だ。
それと事象は似ている。

機械学習の手法はいくらでもあるが、結局、いい特徴量を作るのが一番大変で、人間がやるしかないんですけどね、と先生から言われた。
つまり、特徴量をどうやって作るかが機械学習の本質である。
人間は特徴量をつかむのに長けている。

特徴量の話は、言語哲学者ソシュールの議論に似ている。
彼は、記号とは、概念(シニフィエ)と名前(シニフィアン)が表裏一体となって結びついたもの、と考えた。
たとえば、シニフィエは猫そのものであり、シニフィアンは日本語は「猫」、英語は「Cat」と呼ばれて、人はそれぞれ理解して運用されている。

コンピュータが特徴量を取り出したら、それは概念(シニフィエ)であり、そこに記号として名前(シニフィアン)を与えれば良い。
そうすれば、シンボルグラウンディング問題は解決される。
Googleがディープラーニングによって膨大な画像データから、猫の顔や人間の顔を判別できた、というのはそういうこと。

ディープラーニングは多階層ニューラルネットワークである、という意味が分かっていなかったが、ようやく分かった気がした。

ディープラーニングとは、特徴表現学習と呼ぶべきだ。

ニューラルネットワークで、3層からどんどん多層にすれば人間の脳みそに近づくのに、精度が上がらなかった。
原因は、深い層では、誤差逆伝播が下の階層まで届かないから。
つまり、組織の階層が深いと、一番上の上司の判断が良かったか悪かったかどうかが、末端の従業員に届く頃には、ほとんど影響がゼロになってしまうから。

ではディープラーニングではどうやって解決したのか?
ディープラーニングが従来の機械学習と大きく異なる点は2つ。
一つは、1階層ずつ学習すること、もう一つは自己符号化器という情報圧縮器を使うこと。

自己符号化器では、ニューラルネットワークの入力値と出力値を同じにする。
つまり最初は教師あり学習をさせる。
隠れ層は細くくびれているので、情報量を圧縮させて復元エラーが出ないような特徴表現を学習させる。

統計に詳しい人であればピンとくるだろうが、自己符号化器でやっていることは、アンケート分析結果でおなじみの主成分分析と同じ。
たくさんの変数を少数個の無相関な合成変数に縮約する方法。
実際、線形な重みの関数を用いて、最小二乗誤差を復元エラーの関数とすれば、主成分分析と一致する。
自己符号化器では、非線形な重み関数(シグモイド関数とか色々)を使い、復元エラーを最小にさせるだけでなく、様々な形でノイズを与えて非常に頑健に主成分を取り出す。
これにより、多階層にディープにでき、主成分分析では取り出せないような高次の特徴量を取り出せる。

「ディープにする」図23が非常にわかりやすい。
隠れ層を上に引っ張り出し、入力層と出力層は同じだから便宜的に重ねてしまい、隠れ層を2段目、3段目、と何段にも重ねればよい。

相関のあるものをひとまとまりにすることで特徴量を取り出し、さらにそれを用いて、高次の特徴量を取り出す。
人間がぼーっと目や耳から入った情報から、「お母さん」の概念を発見する仕組みも同様に実現できるはず。

なお、データから概念を作り出すというのは、本来、教師なし学習である。
ディープラーニングでは、教師なし学習を教師あり学習的なアプローチでやっている。

ところが少し難しい点は、そうして得られた特徴量を使って最後に分類する時、教師あり学習になることだ。
つまり、ディープラーニングは「教師あり学習的な方法による教師なし学習」で特徴量を作り、最後に何かを分類させたい時、「教師あり学習」になる。
では、ディープラーニングは教師あり学習をやっているなら、ディープラーニングの意義は小さいのではないか?
(ここは、僕にとっては一番難しい所)

だがこの違いは非常に大きい。
ディープラーニングによって得られた特徴量を使ってデータを判断する時の教師あり学習は、非常に高度なレベルなのだ。
「世の中の相関する事象」の相関をあらかじめとらえておく(つまり、特徴量で抑えておく)ことで、現実的な問題の学習は早くなる。
なぜなら、相関があるということは、その背景に何らかの現実の構造が隠れているはずだから。
つまり、世の中の2つの事象の関係に強い相関関係があるならば、その背後には、概念や意味のレベルで何かしら同一な概念が含まれているはずだから。

ディープラーニングは所詮、主成分分析を非線形にし、多段にしただけ。
とても単純な理屈。
しかし、考え方は単純であっても、こうした高次の特徴量や概念を取り出すには、非常に長時間の精錬の過程を必要とする。
つまり、特徴量の頑健性(ロバスト性)が必要。
すなわち、入力にノイズが多少あっても、ニューラルネットワークの特徴量による判断がぐらつかないレベルの頑健性が必要。

頑健性を得るには、ニューラルネットワークに過酷な環境を与えて、いじめ抜かないと、データの背後にある本質的な特徴量を獲得できないのだ。
画像認識の精度が上がらなかったのは、頑健性を高めるためにいじめ抜く作業の重要性(正則性)に気づかなかった為、そもそもマシンパワーが不足していた為だ。
それさえ気づけば、単純明快な話に過ぎない。

人工知能は本能を持つのか?
本能とは、快や不快を感じるかということ。
人間が獲得する概念の中には、復元エラーを最小化するだけでなく、何が快か不快かによって方向づけられてるものが多い。
ゲームや漫画、スポーツ、音楽など。
こうしたことは、人工知能では「強化学習」として知られている。
報酬を与えることで行動を方向づけて、その結果を生み出した行動を強化される仕組み。
強化学習で重要なのは、何が報酬になるのか、何が快や不快の基準になるのか?
人間は、生存に有利な行動が快、生存の確率を低くする行動は不快になる。
こうした本能に直結する概念をコンピュータが獲得するのは難しい。

この部分は、強化学習は今ホットな話題の一つ。
DeepMindのAlphaGoが以後の世界チャンピオンを破ったのは、強化学習にディープラーニングを取り入れたから。
たぶん、今後色々解決されていくはず。

強化学習の話は、昔習った教育学の話に似ている感じがする。
快や不快の基準は、マズローの欲求段階説における生存レベル、安全レベルの人間にとても当てはまるだろう。
つまり、貧しい人達の行動は、経済学の合理的人間説、強化学習のアルゴリズムにとても近い。
一方、低次の欲求が満たされて高次元レベルの人間になると、生存や金銭に関係なく、より複雑な行動を取るようになる。


| | コメント (0)

2020/05/29

オンラインサービスmiroとastahを連携するastah-miro plugin

オンラインサービスmiroとastahを連携するastah-miro pluginのリンクをメモ。

【参考】
astah-miro pluginを作ってみました | astah in 5 min

Miro | Free Online Collaborative Whiteboard Platform

便利なオンラインホワイトボードサービスmiro(ミロ)の使い方の基本

便利過ぎる!オンラインホワイトボード miroを使ってmiro!|あしたのチーム デザイン事業部|note

デジタルホワイトボード「Miro」が目指すコロナ時代の「ニュー・ノーマル」な会議 ? BRIDGE(ブリッジ)

【miro】コロナ時代の神ツール!リモートチームを一つにするオンラインホワイトボード「miro(ミロ)」 | MAPLOG|ビジネス思考を整理するためのマインドマップ活用ブログ

以前、坂根さんから、miroがお勧めですよ、と教わったが、その意味が正直分かっていなかった。
おそるおそる触ってみたら、無限大のホワイトボードみたいなイメージで使いやすそうな感触がした。

astah-miro pluginでは、astahのクラス図とマインドマップをmiroと相互連携してくれるみたい。
このツールがあれば、ホワイトボードでラフな設計を書いた後、astahに取り込んで、モデリングを深化させていくことができる。
一方、自分で考えたastahのモデルをmiroに連携することで、ホワイトボードに書き出せるので、皆で議論するのが便利。

試してみたいと思う。

| | コメント (0)

2020/05/28

ツールを使いこなせる事の重要性が増している

直近2ヶ月のコロ助を経験して、ツールを使いこなせる事の重要性が増している事を感じた。
ラフなメモ。

たとえば、学校の理科の先生がタブレットを使って花壇の花を撮影しようとしたが、写真の撮り方が分からなかった、というニュースが流れていた。
たとえば、塾なども、ほとんどがオンライン授業になっている。

たとえば、スーパーもレジはナイロン幕を張るだけでなく、店員は、客が渡すお金すら、できるだけ触らずにトレイからレジマシンに放り込んでそのまま渡したり、会員カードもバーコードを読み取るだけで手に触れないようにしている。
できるだけキャッシュレスにしようとしている。
たとえば、再開した図書館も、職員は図書館カードをトレイで受け渡しするだけでなく、手袋までしてる。

たとえば、銀行のATMに行って、現金を出して財布に入れることすら、コロナ感染のリスクがある。
銀行振込や引き出しは、オンラインバンキングサービスやモバイルサービスでやるのを銀行自身が推奨している。

たとえば、ほとんどの飲食店や居酒屋は、玄関に「テイクアウト始めました」の看板を出している。
宣言解除前まで、客は居酒屋に入れなかった。

たとえば、IT勉強会やコミュニティ活動は、すべてオンライン配信となり、Zoomで講演を流したり、お互いに議論するのが普通になった。
もちろん、仕事はテレワークとなり、出勤せずに自宅で仕事して、GoogleサービスやSlack、Zoomを使うのが普通になった。

そんな風景が突然現れた。
すると、オンラインでやり取りできるツールに慣れていないと、仕事はおろか、生活することすら不便になった。

スーパーなどの日常の買い物は基本はPayPayやクレジットカード支払い。
飲食店のテイクアウトはスマホで予約して、UberEatで配達してもらう。

勉強会やコミュニティでは、Zoomでやり取りするので、もちろんフレッツ光などの高速な回線がないとやってられない。
仕事もオンラインでやり取りするので、会社ノートPCのセキュリティ担保はもちろん、SSL-VPNを張った時に会社のオンプレサーバーに負荷がかかっても困る。
自宅では、自分も仕事するし、子供もオンライン授業を受けていれば、フレッツ光でも通信速度は落ちてしまい、正直仕事しづらい時もある。
もちろん、子供はPCの操作が分かっている必要があるし、オンライン授業を見ながら自分の理解を深めていくように、自分の学習方法も変えていかないといけない。
先生もタブレットが使えるのは当然出し、自分の授業をオンラインで配信できるように、授業を組み立てて、Zoomも使いこなせる必要がある。

そんな状況を踏まえると、Zoomのようなビデオ会議ツールを使いこなせるだけでなく、キャッシュレスで生活できるようにネットバンキングやPayPayやクレジットカードを使いこなせること、もっと根本的に、スマホでテイクアウトの宅配サービスを受け取れるように使いこなすことが必要とされてきている。

けれど、そういう状況に皆が馴染めたのか、と言われるとそうでもないと思う。
80歳の親を見れば、未だに銀行ATMから現金を引き出し、スーパーでは現金払いだし、スマホをあげても使いこなせない。
何せ老眼なのでスマホは小さくて見にくい。
世の中の情報はテレビや新聞だけから収集している。
スマホからWebを見たり、Youtubeで好きな動画を見たり、SNSから最新の情報を収集することはしていない。
そういう生き方もあるだろうし、今の時代は弱者でも生活できるようになっているので問題はないのだろう。

さすがに年をとって80歳を過ぎれば、過去の人生経験がありすぎて、今までの経験を捨てて新しいツールを使って、新しい環境に馴染むのは辛いかも知れない。
でも、より主体的に生きていくには、新しいツールを使いこなせなければ、欲しいサービスが得られないし、欲しい情報も取得できないし、色んな人達と出会いを求めることができない。

コロ助の影響のため、80歳の親が楽しみにしていたコーラス教室や漢詩教室は無期限延期となり、お隣さんとのやり取りも劇的に減った。
実際に会って話ができる人達は、自宅にいる家族だけ。
たぶん寂しいと思う。

僕も2ヶ月以上、都心部に出てないからリアルに対面で会った知人はいない。
でも、ほぼ毎日、SNSやZoomなどでやり取りしているから、人間関係が劇的に減ったという感覚はない。
人間関係がオフラインからオンラインに変わっただけ、みたいなイメージがある。

そんな経験をふりかえると、新しい環境では、新しいツールを使いこなすことで、以前と同じサービスやコミュニケーションを維持できるんだな、と改めて感じた。
最初は抵抗感もあったけれど、それは生きていくために必要なのだ、と。

「強い者が生き残るのではなく、環境に素早く適応した者が生き残る」という言葉を、今ほど体で経験したことはなかったと思う。

| | コメント (0)

次元の呪い

機械学習に出てくる「次元の呪い」をリンクしておく。

機械学習と次元の呪い | TechCrowd

(引用開始)
次元の呪いとは
大量のデータを分析する時は大きな次元のデータの処理をする事が多くなりますが、次元数が大きくなると次元の呪いと呼ばれる問題が発生する事に注意しなくてはなりません。
次元の呪いとは、データの次元数が大きくなり過ぎると、そのデータで表現できる組み合わせが飛躍的に多くなってしまい、その結果、手元にある有限なサンプルデータでは十分な学習結果が得られなくなることを指しています。
ビッグデータを処理するためのコンピュータシステムを用意している場合でも、機械学習でデータを処理する場に、次元の呪いに注意しないと、計算コストが莫大となるだけでなく、十分な学習結果が得られず、未知のデータに適切に対応出来なくなる等の不具合が発生してしまいます。
(引用終了)

次元の呪いについて - Qiita

(引用開始)
超球をメロンパンに例えています。高次元空間においては、「皮」に相当する部分が体積の殆どを占めるようです。
3次元では皮の体積が3%であるのに対し、500次元では99.3%が皮になります。とても不思議です。
(引用終了)

高次元空間では、任意の相異なる点同士の距離はかなり疎になる。
つまり、高次元空間では、皮に相当する部分にデータが集まっている。
距離が離れると、予測の信頼性は大幅に下がってしまう。
訓練データの次元が多いほど、過学習のリスクが高くなる。
だから、次元削減のための手法がいくつか生み出されているストーリーらしい。

人間は3次元までしか認識できないので、1000次元空間の中の200次元曲線なんてイメージできない。
絵も書けないから、数式からそのイメージを沸かせるしかない。


| | コメント (0)

2020/05/27

Python と R の違いのリンク

PythonとR言語の違いについて興味を持ったのでメモ。

【参考1】
Python と R の違い・関数の対応表 ? Python でデータサイエンス

基本ライブラリやデータ分析に関する処理の違いをコードベースで書いてくれているので読みやすい。

Python と R の違い (データフレーム編)
Python と R の違い (数学関数・データ整形加工編)
Python と R の違い (日付・時間の処理)
Python と R の違い (データ可視化・グラフ作成編)
Python と R の違い (決定木分析)
Python と R の違い (サポートベクターマシン)
Python と R の違い (ナイーブベイズ分類器)
Python と R の違い (ランダムフォレスト法)
Python と R の違い (線形回帰による予測)
Python と R の違い (k-NN 法による分類器)

PythonとR言語のコードを比較しながら読んでいると、まるで、ロゼッタストーンを発見した時に、古代エジプト語とアルファベットを比較したような感覚に似ているのかな、と空想したりする。
つまり、同じ内容を表現する時に、全く違う言語で表現したら、見た目が全く違う、みたいな感じ。

【参考2】
PythonとRのコマンド比較表 - Qiita

データフレーム、プロット、リスト、計算、処理などの観点でコード比較している。
Numpy、Pandas、Matplotlibに相当するRのライブラリは自分でも整理してみる。

【参考3】
R vs Python:データ解析を比較 | POSTD

実際にデータ分析したいことについて、PythonとRで比較している。
Pythonは、scikit-learnみたいにライブラリを使いまくるイメージかな。

一方、Rの方がPythonよりも行数を短く書ける場合もあるみたい。
この辺りは、自分で書いてみて理解する。

Haruhiko OkumuraさんはTwitterを使っています 「https://t.co/fxE6ETowKd Rで書けば5行だ df = read.csv('...') plot(df$costs, df$profit) r = lm(profit ~ costs, data=df) summary(r) abline(r)」 / Twitter

【参考4】
「データ分析をやるならRとPythonのどちらを使うべき?」への個人的な回答 - 渋谷駅前で働くデータサイエンティストのブログ

このブログを読むと、試行錯誤しながらデータ分析するならR言語、機械学習や深層学習ならPython、という使い分けなのかな。

ちょっとずつ書いてみると違いが分かり始めて面白い。


| | コメント (0)

2020/05/24

「クライアント-ベンダーアンチパターン」という根本問題

今更ながら「ユーザーストーリーマッピング」を読んだ。
この本で一番ピーンと来たのが「クライアント-ベンダーアンチパターン」。
自分が理解したメモ。

【参考】
【復習】CSPO研修(2) クライアント-ベンダー アンチパターン - きっと、うまくいく~非IT業界をスクラムで変えるための系譜~

「ユーザーストーリーマッピング」を読んで | GMOインターネット 次世代システム研究室

『ユーザーストーリーマッピング』|感想・レビュー - 読書メーター

(引用開始)
プロダクトオーナー向けの推薦図書、と紹介を受けて読む。様々な局面でのベストプラクティスとアンチパターンが書かれており、スクラムマスターや開発チームの人達と読んでも面白そう。終始いいこと書くなぁと思いつつ読む。
大きな組織内でも、社内ベンチャー的に何かサービスを作ってみよう、新規サービスを、とするチームにも必読かな。
SIer的には「クライアント-ベンダーアンチパターン」が刺さる。こうはならないように間を取り持つような、うまい関係性を構築したいものだなと思う。近いうちに再読、リファレンス的に使いたい。
(引用終了)

【1】「クライアント-ベンダーアンチパターン」こそが、ストーリーの活用を阻害する最大のアンチパターン。
「ユーザーストーリーマッピング」は、いかにしてこのアンチパターンを解決すべきか、色んな角度から解決方法を述べているように感じた。

「クライアント-ベンダーアンチパターン」では、発注者であるクライアントと提供者であるベンダーが敵対関係になる。
クライアントは要件を話して、ベンダーに見積もりを要求する。
見積もりは契約と同義語なので、ベンダーはリスク回避のために、ガチガチの要件を定義して、コンティンジェンシーも加味した見積もりを出す。
そして、リリース前後にクライアントはこんなものを期待したわけではなかった、と言い出す。

特に、日本のSIとユーザ企業は、まさに「クライアント-ベンダーアンチパターン」に陥っている場合が多い。

「クライアント-ベンダーアンチパターン」の本質は、問題と解決方法の会話が要件とその合意の議論にすり替わっている点にある。
本来、クライアントは業務上の何かの問題を解決して欲しくて、システム導入による解決方法をベンダーに期待する。
ベンダーはIT技術屋なので、技術がどのように役立つのか、をよく知っている。
しかし、「クライアント-ベンダーアンチパターン」のように、クライアントとベンダーで役割が分離されてしまうと、システム開発のリスクをどちらかに投げたい気持ちが強くなり、互いにリスク回避の行動になってしまう。
システムシンキング的には、共有地の悲劇みたいな感じかな。

「ユーザーストーリーマッピング」では、医者と患者の関係に近づけるべきだ、とアドバイスする。
医者は患者を検査し、どこに問題があるのかを調べて処方する。
同様に、ベンダーも医者のように振る舞い、要件ではなく、本来の問題解決の役割に徹するべき。

【2】「プロデューサーとしてのプロダクトオーナー」という節も重要だ。
古いIT部門にいると、プロダクトオーナーという概念が分かりにくい。
特に基幹系情報システムの担当にいると、誰が最終決定を握っているのか分からない。
なぜなら、誰もシステムの全てを知っていないから。
サブシステムや各サービスの要件を決めるプロダクトマネージャがいるだけだ。

すると、こういう古い組織では、ビジネスアナリストなる人が要件収集の役割を与えられる。
彼らは、サブシステムごとのプロダクトマネージャや利害関係者というビジネスピープルと、開発者の間の仲介者の役割を果たす。
この時に、ビジネスピープルがクライアント、ビジネスアナリストがベンダーの役割を演じて、「クライアント-ベンダーアンチパターン」が発生する。
ユーザ企業側にいると、まさにこういう症状が発生しがちで、要件定義フェーズでよく行き詰まる。

「ユーザーストーリーマッピング」では、ビジネスアナリストが音楽バンドに対するプロデューサーのような役割をにない、医者と患者の関係に近づけるべきだ、とアドバイスする。
この比喩はとても上手い。

一方、僕は当初は、ユーザ部門がプロダクトオーナーの役割を担うべきだ、と思っていた。
本来は、ユーザ企業のIT部門がベンダーと張り合えるぐらいの技術力を持たいないと、技術の目利きやベンダー管理なんてできないでしょ、と思っていた。
しかし、現実は厳しい。

プロダクトオーナーの仕事もスキルも簡単なものではない。
ユーザ部門がプロダクトオーナーの役割を全て担うのは、スキルがなければ危険だ。
ビジネスアナリストはユーザ部門を手助けするプロデューサーの役割を担う方がいい。

【3】この指摘は、「エッセンシャルスクラム」に出てくる「プロダクトオーナープロキシ」の役割に似ている。
つまり、「プロデューサーとしてのプロダクトオーナー」は「プロダクトオーナープロキシ」、つまり、プロダクトオーナーの代理人と同義語と思える。

ユーザ部門の人に時間を与えて、プロダクトオーナーの仕事を担当してもらうが、ビジネスアナリストまたは情報システム部門がプロダクトオーナーと開発チームのやり取りを担当し、特定の状況ではプロダクトオーナーの代わりに意思決定できる役割も担えるようにする。
つまり、ビジネスアナリストまたは情報システム部門はプロダクトオーナーと同じ立ち位置にいて支援も行い、問題解決を図るようにする。

【4】「クライアント-ベンダーアンチパターン」を読み直すと、日本のソフトウェア開発の問題はここに尽きるのではないか、と思ったりもする。
ユーザ企業は一括請負契約としてベンダーを縛り、開発リスクをベンダーに負わせる。
だから、ベンダーはリスク回避のコストを見積もりに入れて、多額の開発費用を契約する。
そして、要件定義でベンダーの支援範囲を固定し、リスクを回避しようとする。
お互いに敵対関係となり、「クライアント-ベンダーアンチパターン」にはまる。

その点、スクラムはよく考えられていると思う。
プロダクトオーナーの人は、開発チームに入り、スクラムチームの一員になることで、開発チームと一体化する。
その結果、プロダクトオーナーは開発チームとコミュニケーションが取りやすくなるし、開発チームも、要件ではなく本来の問題を認識できるので問題解決がより即した形になる。

また、ユーザ部門がプロダクトオーナーとして完全に発揮できない場合、ビジネスアナリストや情報システム部門がプロダクトオーナープロキシになって、プロダクトオーナーと開発チームの仲介役を担う。
その結果、ユーザ部門の要望や問題意識は、プロダクトオーナープロキシによってシステム内容に置き換えられて、開発チームに渡されるようになる。

【5】こういう話を聞くと、日本人は、大規模な官僚組織を操縦するのが本当に下手なんだな、と思う。
中国や米国や欧州の人も上手いとは言えないが、日本はもっと下手すぎる。

中国は2千年以上も前から、非宗教的な官僚組織を作り出し、それをいかに手懐けるか、に知恵を絞ってきた。
欧米は社会心理学や行動経済学、組織行動学などの学問を揃えることで、官僚組織の運営に、概念や理論を適用してきた。

一方、日本人は腹芸や根回しみたいなスキルばかりに注力して非効率的だ。
もっと、組織運営というスキルを磨くべきなんだろうな、とか思ったりする。

【追記】先日、@ryuzeeさんと、@kyon_mmさんのやり取りも非常に参考になった。

Ryutaro YOSHIBAさんはTwitterを使っています 「そもそもPOとSMは利害相反する箇所があるので、1人に内包すると歯止めが効かない。たくさん作りたいPOと持続可能にやりたいSMでバランス取るみたいなのできないしね」 / Twitter

きょん@アジャイルコーチ、システムアーキテクトさんはTwitterを使っています 「@ryuzee なぜ人がわかれているとできるんですか?」 / Twitter

Ryutaro YOSHIBAさんはTwitterを使っています 「@kyon_mm 書き方よくなかったかもね。分かれてても出来ないこともある。当たり前だけど健全な関係性の上に成り立つので、PO・SMが主従関係みたいな感じならかわらんね。」 / Twitter

| | コメント (0)

2020/05/23

第18回東京Redmine勉強会~オンライン勉強会の可能性 #redmineT

第18回東京Redmine勉強会を始めてオンラインで実施できました。
参加者、講演者、スタッフの皆様、ありがとうございました。

【参考】

第18回勉強会 - redmine.tokyo

第18回東京Redmine勉強会『Redmineによるテレワーク運用』(2020/5/23) - Togetter

第18回redmine.tokyoでテレワークの工夫と真髄を知る【リモート開催】 #redmineT | マドびっ! Madosan's View

redmine.tokyo 参戦|makoto0119|note

第18回redmine.tokyo勉強会 - ryouma-nagareのブログ

デッドナイト東京、ではなくredmine.tokyo onlineに参加|みけねこ|note

【1】約3時間の長丁場のオンライン勉強会にも関わらず、最大風速でZoom75人、YoutubeLive100人超えで大盛況でした。
まだ事後アンケートを見ていないが、それだけテレワーク中にRedmineを利用していたり、興味を持つ人が多かったのかな?
ツイートも多くて、読み返すのが楽しい。

【2】講演で気になった感想をメモしておく。

【2-1】前田さんの講演では、RedmineのVer4.2の新機能が紹介されていた。

ユーザグループでウォッチャーに登録できる機能。
ユーザグループを大量に作っている時は欲しくなる。
Feature #4511: Allow adding user groups as watchers for issues - Redmine

ユーザーアカウントのメールアドレスのドメインの制限。
Redmineにある守秘義務のあるデータを個人スマホに転送できなくする為に必要。
ISMSでも必要。
Feature #3369: Allowed/Disallowed email domains settings to restrict users' email addresses - Redmine

優先度が高いチケットの更新を通知するオプション。
Patch #32628: Notify users about high issues (only) - Redmine

akipiiさんはTwitterを使っています 「#redmineT 優先度が高いチケットのみ通知メール対象にする設定の機能追加。通知メールの量を抑えながら、重要な情報のみ検知できる運用が可能。」 / Twitter

プロジェクト一覧のデフォルトの表示形式設定。
Feature #32818: Add a system settings for default results display format of project query - Redmine

akipiiさんはTwitterを使っています 「#redmineT プロジェクト一覧を常にリスト形式で表示できるが、初期表示をカスタムクエリで設定した情報で保存できる機能追加。PMOや経営層のようにPJ横断で見たい人には必要ですね。」 / Twitter

チケット表示画面に「完了」「未完了」のバッジを表示。
完了チケットなのに、コメントする人がいるので、それを気づかせてくれる。
Feature #33254: Show open/closed badge on issue page - Redmine

Wikiツールバーのテーブル挿入ボタン。
Feature #1575: Toolbar button to insert a table - Redmine

Wikiツールバーのコードハイライトボタンのカスタマイズ。

akipiiさんはTwitterを使っています 「#redmineT Wikiで表を簡単に挿入できる。Wikiのコードハイライトでよく使う言語を個人で指定して保存できる。この辺りは、Wikiを使って情報共有したい人には、手が届く痒い機能ですね」 / Twitter

チケットがクローズできない場合の理由を表示。
Feature #31589: Show warning and the reason when the issue cannot be closed because of open subtasks or blocking open issue(s) - Redmine

akipiiさんはTwitterを使っています 「#redmineT チケットがCloseできない理由を警告メッセージで表示してくれる。例のように、親子チケットのCloseができない場合が多く、問合せも多くて面倒でした」 / Twitter

【2-2】門屋さんから、Redmine活動家のお話。
PMOならではの苦労が想像できる。

Redmine警察、Redmine職人、Redmine活動家のような役割は、Redmineの運用をスムーズにさせるには必要な機能と思う。
彼らはRedmineの潤滑油。

ししゃもさんはTwitterを使っています 「Redmine ー警察 ルールが守られているか ーマイスター 職人 使い方の理想を追いつつメンバーを教育 ー活動家 あるべき姿に到達させる人 ー神 まえだ?さん #redmineT」 / Twitter

活動タブをよく見てます、という意見。
プロジェクトの活発度合い、チームの雰囲気を知るのに役立つ。

もりのあささんはTwitterを使っています 「チケット管理は”活動”はかなり重要よね。 よく見る。 #redmineT」 / Twitter

Redmine利用レベルはCMMIを参考にしている、と聞いて、上手く考えているな、と思った。

ししゃもさんはTwitterを使っています 「活動家 レベル1-自主調整 レベル2-相互調整 レベル3-是正提案 レベル4-介入 #redmineT」 / Twitter

あさこさんはTwitterを使っています 「redmine利用のレベル1-5は、CMMIレベル1-5を参照してますよ~ #redmineT」 / Twitter

JiraではチケットよりもConfluenceをよく使う、という意見もあった。
情報を蓄積する機能はWikiの方が良い、ということなのだろう。
以前、Jiraでは、設計書などの仕様は全てWikiで実現すべきという発想であると聞いたので、Confluenceを多用する気持ちは分かる。

もりのあささんはTwitterを使っています 「うちの会社(JIRA)だと詳細がチケットに書かれずにコンフルに書かれてることが多いんだよな。 チケットに書いた方がいいんじゃないかなとは思うんだけど。 (JIRAのアクティビティじゃなくてコンフルの週報とか日報の更新メールを監視してる) #redmineT」 / Twitter

タマコナ??Backlog最近の更新家さんはTwitterを使っています 「門屋さんのお話、RedmineのところをBacklogやJIRAに置き換えても全く違和感ない。それだけ普遍的なお話だということ。 #redmineT」 / Twitter

【2-3】yukiaさんのBacklogとRedmineの比較も興味深かった。

タマコナ??Backlog最近の更新家さんはTwitterを使っています 「Backlogはすぐに利用できる。 (=カップ麺) Redmineは食材を料理してから利用する(=スーパーマーケット) #redmineT」 / Twitter

あさこさんはTwitterを使っています 「「なんで使いにくいと思うのか?」の違和感の追求をすると、本来やりたいところにフィットするツールが選択できるのよねぇ。 機能だけ知っていても、無駄無駄無駄無駄無駄無駄無駄...ッ! #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT Redmineにもユーザが既読したのか表示する機能は欲しいな。スマホのMessenger等では今は当たり前だから。」 / Twitter

@saitoさんの「Redmine+Teams=TeleWork」の話も興味深かった。
チケット管理ツールとチャットツールをどのように使い分けるべきなのか、どの利用シーンで使うべきか、という議論が聞きたかったから。

もりもりさんはTwitterを使っています 「初動 Teams ・チャットの嵐 ・ファイル、メモの嵐 ・Web会議 →キーマンへチケット化指示(Redmine) #redmineT」 / Twitter

ししゃもさんはTwitterを使っています 「Teams…第一報はココ。大体の嵐が去った後に作戦が立つ。収拾がつかなかったらweb会議へゴー。この会議がなかなか優秀 Redmine…キーマンが宣言してチケット起票 #redmineT」 / Twitter

Ryo MiuraさんはTwitterを使っています 「「共存」「使い分け」はもっともだと思う。シンプルなツールほど使いやすい。昔は、いろんな機能が入ったソフトが流行っていたけど、いまは、スマホのように「シンプルな機能を自分の画面で並べて使っていく」。こんな時代。PCでも、同じかと。#redmineT」 / Twitter

カエ太さんはTwitterを使っています 「ほっとくと皆チャットに籠もってしまうので、いかにチーム/チャネルに誘導するかがポイント>Teams #redmineT」 / Twitter

【2-4】@naitoh さんによるアンケート集計結果で興味深い点がいくつかあった。
Ver4.xが半数以上なので、ほとんどの人達は最新機能の恩恵を受けている。
よって、RedmineのVerUPに追随できるだけのインフラや環境構築の知識がある人達が多いのだろうと推測する。

また、チャットツールはSlackとTeamsとZoomが半数以上を占めること。GoogleMeetは少なかった。
懇親会で聞いた話では、TeamsはMicrosoftがすごく力を入れているので、どんどん使いやすくなってますよ、と。
僕はTeamsの経験がないので、どのチャットツールがどんな特徴があるのか、この辺りのツール比較は興味がある。

akipiiさんはTwitterを使っています 「@naitoh さんによるアンケート集計結果。興味深い点は、Ver4.xが半数以上。チャットツールはSlackとTeamsとZoomが半数以上を占めること。GoogleMeetは少なかった。 https://t.co/WbOoFpsXMf 18 questionnaire #redmine https://t.co/5xNYCDW6wQ」 / Twitter

【3】オンライン勉強会の裏方を担当して、こんなやり方もあるのか、という経験ができて良かった。

講演を普通にZoomで配信するのは当たり前。
課題は、オンライン勉強会では参加者の反応が見えず、シーンとなりやすいので、参加者のフィードバックを集めていかに場を盛り上げるか、という点にあると考えていた。
今回は、Twitterで感想や質問を流してもらい、裏で集めてフィードバックする方法を取ってみた。

講演者の立場では、すぐに感想がもらえるのでとてもありがたい。
スタッフとしても、勉強会の評価に直結するので気になる。

今回は流れる量が非常に多く、その内容を質疑応答タイムで使ったら、講演者とスタッフの間で盛り上がってしまって、ちょっと長引いてしまったくらい、良かった。
この辺りの、勉強会の場を盛り上げる方法はいくつかあると思うので集めてみたいと思う。

たぶん、アジャイル開発のコミュニティであれば、全員がリーダーでありファシリテーターでもあるだろうから、こういう段取りをしなくても上手くいくのかも知れない。

| | コメント (0)

2020/05/18

Redmineヘッドラインで今の話題をチェックする

@g_maedaさんが、Redmineヘッドラインを公開されていたのでメモ。

【参考】
Redmineヘッドライン ? プロジェクト管理ツールRedmineの今の話題をまとめて紹介

MAEDA GoさんはTwitterを使っています 「Redmineヘッドライン https://t.co/xRfgvzB3pZ に先週 (2020/05/10-16) は計6件のリンクを追加しました。 - redmine-issue-loader 2.3.0リリース - Issue Templates 1.0.2リリース - Full Text Search plugin と ChupaTextで添付ファイル内全文検索 ほか」 / Twitter

MAEDA GoさんはTwitterを使っています 「@akipii Redmine関係の記事やソフトウェアの情報は、見つけたものはどんどん載せます。Redmineのコミュニティの盛り上がりに少しでもつなげられるといいなと思っています。」 / Twitter

MAEDA GoさんはTwitterを使っています 「@juno_nishizaki ありがとうございます! いろんな方がせっかく公開してくださった記事やプラグインの情報がRedmineに関心がある方に届きやすくして、コミュニティに少しでも貢献できればいいなと思っています。」 / Twitter

Redmine本体だけでなく、Redmineに関するプラグインやTips、ブログなどがリンクされているので、とても参考になる。
最近の流行はすごく速いので、こういうサイトで時々チェックできれば、最新動向も把握できる。

直近の話題は下記ですね。

「こどもれっどまいん」というテーマを作っています。 - Qiita

Docker Compose で作った Redmine だって Full Text Search plugin と ChupaText サーバーを連携させたい - Qiita

doc2vecでredmineのチケット(csv)を学習させてみる - Qiita

redmine-issue-loader のバージョン2.3.0をリリースしました - Enjoy*Study

Redmine draw.io plugin がすごい便利そうなので紹介したい - Qiita

他に、まどさんや僕のブログもリンクされてましたね。

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ! Madosan's View

Redmineとチャットツールはどのように使い分けるべきなのか: プログラマの思索


| | コメント (0)

2020/05/17

オンライン勉強会のノウハウのリンク

最近の勉強会は、オンライン配信する時が多い。
友人からオンライン勉強会のノウハウを聞いたので、リンクをメモ。

【参考】
Zoomを活用してOSC2020 Online/Springを開催しました - 宮原徹の日々雑感

Zoomで開くオンラインイベント入門

アットホームな感じの オンラインイベントの配信を意識してみた

20200326 meetup video shooting meetup vol2 kitazaki いつも持ち歩ける ワンオペ配信機材

なぜ Infra Study Meetup運営は配信トラブルを引き起こしてしまったのか - Forkwell Press

オンライン勉強会に参加したり、自分たちが主催になった立場で経験してみると、いくつか気づきはある。

良かった点は、2つある。
一つは、東京など遠方の勉強会であっても、参加しやすくなったこと。
今まで行きたかったのに東京だから無理だ、という障害がなくなった。
また、参加者は全国が対象になったので、多数の参加者を集めることも可能になった。
さらに、会場費用も不要なので、勉強会のコストはせいぜい、Zoom管理費用をサブスクリプションで払うぐらい。

もう一つは、コロナ感染防止による自粛で外出できなくなっても、毎日どこかでオンライン勉強会が開催されているので、参加すれば、孤独感を感じることはなくなった。
むしろ、以前よりも頻繁に勉強会に参加しやすくなったし、以前と同じ交流ができた。
休日ならば、1日間に3回もオンライン勉強会をハシゴすることも可能だ。
実際経験してみたら、朝から晩までノートPCにしがみついているので疲れた。

他方、課題や留意点はいくつか感じる。

1つ目は、それなりの機材や環境は必要であること。
通信速度は100M以上は欲しい。
回線が細いと、ビデオも音声も途切れがちになり、お互いのコミュニケーションがやりにくくなる。

ノートPCにカメラは付属しているけれど、音声はヘッドセットが別途あった方がいい。
ハウリングしたり、自宅のノイズを拾ってしまうから。
片耳にかけて会話も出きるBluetooth ワイヤレスヘッドセットがあると便利。

2つ目は、Zoomなどのツールを使いこなすこと。
Zoomの管理機能はまだよく分からないが、部屋を作って参加者を分けたり、とか、割と機能が豊富みたい。
他にも、GoogleHangoutやSkype for businessなどある。
それらのツールでどこまで使いこなすのか、まだ理解している途中。

また、ビデオで会話するだけでなく、チャット機能やチャットツールも欲しくなる。
だが、オンライン勉強会を主催する立場になると、Zoomのようなビデオツール、参加者とやり取りするためにslide.ioやTwitterなどのチャットツール、スタッフ同士で裏でやり取りするMessengerやSlackなどが必要になってくる。

すると、Zoom、slide.io、Messengerの3つのチャネルを随時見ないといけないので、ノートPC以外にタブレットやスマホなども総動員して、3つ以上の通信機器を机に広げることになる。
つまり、割と大変なのだ。

3つ目は、オンライン打合せのファシリテーションスキルが必要になっていること。
対面の打合せでもファシリテーションは必要だが、オンラインになると、どうしても一方通行になりがち。
いかに参加者から活発な発言を促して発散させるか、そしてその議論を収束させていくか、オンライン特有のファシリテーション技術が必要な気がしている。

対面のファシリテーションでは、ホワイトボードやPostItが有効だったが、オンラインではそれらツールが使えない。
エディタやGoogleスプレッドシートを画面共有したり、マインドマップをツールで書いたりする。

オンライン・ホワイトボードは下記のツールがいいよ、と、坂根さんから教えてもらった。

便利なオンラインホワイトボードサービスmiro(ミロ)の使い方の基本

ファシリテーションでは、人間的なスキルだけでなく、こういうツールを使いこなす技術も必要なのだ、と気づいた。

たぶん、こういうツールや課題は、今はまさに発展途上な状態。
来年になれば、当たり前になっているかもしれないし、まだ先のノウハウも生まれているだろう。
いろいろ試してみたい。


| | コメント (0)

2020/05/15

Docker ComposeにRedmineとFull Text Search pluginを入れる記事のリンク


Docker ComposeにRedmineとFull Text Search pluginを入れる記事があったのでメモ。

【参考】
Docker Compose を使って自分好みの Redmine 実行環境を作ってみた - Qiita

さらに、添付ファイルの全文検索のために、ChupaText サーバーを入れたらしい。

Docker Compose で作った Redmine だって Full Text Search plugin と ChupaText サーバーを連携させたい - Qiita

下記はまさにその通り。

(引用開始)
Redmine の良いところの 1 つに、本体だけでなくプラグインにも素晴らしい機能がたくさんあることが挙げられると思います。有志のみなさんにはいつも心から感謝しています。

しかし、Redmine は構築するのが難しいので、せっかくこのような素晴らしい機能があってもセットアップすることができずにメリットを享受する機会を失っているのではないかと危惧しております。
(引用終了)

ツイートを見ていると、Redmineのセットアップでつまずいている人も多い。
Dockerなどのツールで罠にはまらないようにしたい。

| | コメント (0)

2020/05/10

PythonとRubyの違い

PythonとRubyの違いの記事が参考になったのでメモ。

【参考1】
PythonとRubyの違い | Qrunch(クランチ)

記事の内容は同意する。
個人的感想では、Pythonの方がより実用的な気はする。

実際、Javaはelse if、Rubyはelsifだが、Pythonはelsifと一番短い。
Pythonは予約語も一番少ない。
from モジュール import 関数で書くと、モジュールやオブジェクトは意識しなくていいので、関数っぽく書ける。

【参考2】
【Ruby】PythonプログラマーがRubyを触って感じたこと - 歩いたら休め

Pythonプログラマから見ると
「Rubyはオブジェクト指向にこだわりすぎている」
「変な記号がいっぱいある」
「ブロック(ラムダ式)が強力すぎる」
であるらしい。
確かに、変な記号は多すぎるので最初は慣れるのに時間はかかる。

下記のアドバイスも参考になった。

(引用開始)
逆に、RubyのプログラマーがPythonを勉強したいなら、以下の3点を押さえておけば、ちゃんとしたプログラムが書けると思います。

リスト内包表記
ジェネレーター(遅延評価)
ふつうに定義した関数がオブジェクトであること
(引用終了)

【参考3】
Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - Qiita

Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法 - Qiita

個人的感想では、Rubyのリファクタリング例はとても綺麗で参考になる。
Rubyの威力を見せつけられる感じ。

一方、Pythonの例はもう少し意義が感じにくかった。
もっといい例があるのかも知れない。

| | コメント (0)

乱立したPythonのオライリー本のリスト

Python本が読みたいと思っていたら、オライリーの本が大量に出版されていたので、下記の記事をメモ。

オライリーのPython & 機械学習本が渋滞気味なので整理してみた - Deutschina's Tech Diary

自分が読みたい本をリストアップしておく。

NumPy、Pandas、MatPlotLibを一通り勉強する時の本。

DeepLearningの構造を最初から理解する。

「scikit-learnとTensorFlowによる実践機械学習」は今読んでるけど、機械学習が今までのアルゴリズムと何が違うのか、網羅的に書かれていてとても役立つ。

これもいつか読みたい。


| | コメント (0)

2020/05/08

Ruby技術者認定試験の感想

Ruby技術者認定試験Silver・Goldに合格したので感想をメモ。
Ruby初級者なので、間違っていたら後で直す。

【参考】
Ruby技術者認定試験

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

Ruby技術者認定試験(Silver && Gold)合格体験記 | Avintonジャパン株式会社

ruby gold 2.1 - Qiita

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

新人プログラマがRuby技術者認定試験(Gold 2.1)に1ヶ月半以内で合格する勉強法 - IT女子ブログ

Ruby初心者だけどRuby Association Certified Ruby Programmer Silverを取得した! - suusan2号の戯れ

Ruby技術者認定試験 Goldを受験しました - ZENET Tech Blog

【1】Ruby技術者認定試験Silver・Goldは、とても良い試験だったと思う。

Rubyの文法やライブラリを一通り知っておく為に勉強せざるを得ない環境にできること、そして、初級者はSilver、中級者はGold、というように、レベルも上手く設定されているからだ。
特にGoldは、メタプログラミングの知識や経験がないと合格は難しい。
Ruby経験者、Rails経験者であっても、一夜漬けでは合格できないだろうと思う。

【2】試験対策は、Ruby技術者認定試験にあるオンラインの模擬試験を100点が取れるまで解くこと、推奨の書籍3冊を読み込むことだった。

オンラインの模擬試験はたぶん、Ruby実務経験があっても試験慣れてしていないと取りこぼすかな、と思う。
間違えた問題は、ミスした原因を分析して、理解できていないのか、分かっているのに勘違いしたのか、でふるい分けて、Webや書籍で調べて納得するまで腹落ちさせることが大事。

【3】お勧めの書籍は5冊ある。
「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」
「メタプログラミングRuby第2版」
「Rubyのしくみ Ruby Under a Microscope」
「改訂2版 Ruby逆引きハンドブック」
「Effective Ruby」

【3-1】「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」に記載の模擬試験は必ず解いておくべき。本試験でも割と同じ問題が出るときもある。

【3-2】「メタプログラミングRuby第2版」はとても良かった。
Rubyにあって、Javaにはない特徴がメタプログラミングにあると思う。
Rubyの面白さはここにあると思う。
Javaの経験に引きずられていたので、サンプルを写経してようやく、ダック・タイピングのイメージがつかめてきた。

たとえば、io.print という処理では、ioはFileオブジェクトかもしれないしIOオブジェクトかもしれないし、printはインスタンスメソッドではなくインスタンス変数かもしれない。
つまり、的確にオブジェクトを定義すれば、ポリモルフィズムが背後で上手く動作して、たった一つの表現で複数パターンの処理を実現できる。
さらに、Rubyは読みやすさを重視しているので、処理がそのまま英文であるかのように読める。
特に、内部DSLをRubyで表現する時はそうだ。

「メタプログラミングRuby第2版」の良かった点は2つある。
まず、Railsの仕組みを紹介してくれていること。

たとえば、ActiveRecord::Baseでは、インスタンスメソッドが300個以上、クラスメソッドが500個以上も含まれている巨大なクラスだ。
著者が言う通り、Javaプログラマならば、こんな設計は狂っている、スパゲティコードだ、と最初は思うだろう。
しかし、むしろRailsでは読みやすく変更しやすい設計になっているのだ。
つまり、著者の言う通り、設計技法は絶対的なものではなく、設計技法は使用言語によって変わる。

その他に、ActiveSupport::Concernは進化的設計から生まれたし、alias_method_chainは廃止されてprependが使われる設計に変わった。
つまり、最初は問題解決のためのシンプルなコードを書いて、その後、ゴーストメソッド多用に対するパフォーマンス改善やalias_method_chain多用に対するスパゲティコード対策などのために、どんどんフレームワーク設計そのものを変えていった。
すなわち、Rubyのやり方は、最初から正しい設計を行うよりも、後から機能改善やパフォーマンスを改善していく進化的設計、つまりアジャイル開発がとても向いている。
その理由は、Rubyが徹底したオブジェクト指向言語でありメタプログラミングしやすい特徴を持つので、とても柔軟性の高い言語だからだろう。

【3-3】「メタプログラミングRuby第2版」の付録「よくあるイディオム」は、Ruby初級者が暗記すべきテクニックと思う。
参照したいので、イディオムを載せておく。

O’Reilly Japan - メタプログラミングRuby 第2版

アラウンドエイリアス(Around Alias)
ブランクスレート(Blank Slate)
クラス拡張(Class Extension)
クラスインスタンス変数(Class Instance Variable)
クラスマクロ(Class Macro)
クリーンルーム(Clean Room)
コードプロセッサ(Code Processor)
コンテキスト探査機(Context Probe)
あとで評価(Deferred Evaluation)
動的ディスパッチ(Dynamic Dispatch)
動的メソッド(Dynamic Method)
動的プロキシ(Dynamic Proxy)
フラットスコープ(Flat Scope)
ゴーストメソッド(Ghost Method)
フックメソッド(Hook Method)
カーネルメソッド(Kernel Method)
遅延インスタンス変数(Lazy Instance Variable)
ミミックメソッド(Mimic Method)
モンキーパッチ(Monkeypatch)
ネームスペース(Namespace)
nilガード(Nil Guard)
オブジェクト拡張(Object Extension)
オープンクラス(Open Class)
Prependラッパー(Prepended Wrapper)
Refinements(Refinements)
Refinementsラッパー(Refinements Wrapper)
サンドボックス(Sandbox)
スコープゲート(Scope Gate)
自己yield(Self Yield)
共有スコープ(Shared Scope)
特異メソッド(Singleton Method)
コード文字列(String of Code)
SymbolのProc変換(Symbol To Proc)

メタプログラミングRubyの感想: プログラマの思索

【3-4】「改訂2版 Ruby逆引きハンドブック」は、Rubyのライブラリを一通り説明してくれているので、APIを調べたい時に便利。

特に、RubyでもJavaでも、どんなプログラミング言語でも、配列Array、連想配列Hash、文字Stringのメソッドは最低限必ず覚えておくべき。
なぜなら、配列やハッシュ、文字を自由自在に操れないと、自分がやりたいことを実現する手間が多くなりすぎて、イライラするから。
もちろん、それ以外にもファイル処理、Web操作、クラス設計なども必要。

Java経験者から見ると、RubyはArrayやHashのライブラリが非常に多いし、便利な使い方が多いように思う。
Rubyはブロックが使いやすいので、ArrayやHashの各要素に何らかの処理を一括操作したい時に、1つのメソッドで1行で書ける場合が多い。
VBやJavaならば数行もまどろっこしく書いてしまう部分が簡単に書けるのは素晴らしい。
但し、たとえば、mapとcollect、selectとfind_all、injectとreduce、findとdetectなどのように、異音同義語が多い点は注意。

「改訂2版 Ruby逆引きハンドブック」は今も愛用している。

Ruby初心者が間違いそうなこと: プログラマの思索

SmalltalkとLispから来たメソッドmap と collect、reduce と inject: プログラマの思索

【3-5】「Effective Ruby」はRubyらしい書き方の解説本。
最初はRubyらしい書き方が分からず、VBやJavaみたいな書き方になってしまっていた。
その原因は、Rubyのライブラリを幅広く深く知っていないこともあったが、Ruby独特の考え方や書き方が分かっていなかったからと思う。

僕は、下記が参考になった。

項目1 Rubyは何を真と考えているかを正確に理解しよう
項目2 オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目6 Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目12 さまざまな等値の違いを理解しよう
項目15 クラス変数よりもクラスインスタンス変数を使うようにしよう
項目18 要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19 reduceを使ってコレクションを畳み込む方法を身に付けよう
項目24 リソースはブロックとensureで管理しよう
項目28 モジュール、クラスフックを使いこなそう
項目29 クラスフックからはsuperを呼び出そう
項目30 method_missingではなくdefine_methodを使うようにしよう
項目31 evalのさまざまなバリアントの間の違いを把握しよう
項目32 モンキーパッチの代わりとなるものを検討しよう
項目33 エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34 Procの項数の違いに対応できるようにすることを検討しよう
項目35 モジュールのprependを使うときには慎重に考えよう
項目47 ループ内ではオブジェクトリテラルを避けよう

全てのイディオムを掲載しておく。

Effective Ruby(長尾高弘 arton PeterJ.Jones)|翔泳社の本

第1章 Rubyに身体を慣らす
項目1 Rubyは何を真と考えているかを正確に理解しよう
項目2 オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目3 Rubyの暗号めいたPerl風機能を避けよう
項目4 定数がミュータブルなことに注意しよう
項目5 実行時の警告に注意しよう

第2章 クラス、オブジェクト、モジュール
項目6 Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目7 superのふるまいがひと通りではないことに注意しよう
項目8 サブクラスを初期化するときにはsuperを呼び出そう
項目9 Rubyの最悪に紛らわしい構文に注意しよう
項目10 構造化データの表現にはHashではなくStructを使おう
項目11 モジュールにコードをネストして名前空間を作ろう
項目12 さまざまな等値の違いを理解しよう
項目13 ""<=>""とComparableモジュールで比較を実装しよう
項目14 protectedメソッドを使ってプライベートな状態を共有しよう
項目15 クラス変数よりもクラスインスタンス変数を使うようにしよう

第3章 コレクション
項目16 コレクションを書き換える前に引数として渡すコレクションのコピーを作っておこう
項目17 nil、スカラーオブジェクトを配列に変換するには、Arrayメソッドを使おう
項目18 要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19 reduceを使ってコレクションを畳み込む方法を身に付けよう
項目20 ハッシュのデフォルト値を利用することを検討しよう
項目21 コレクションクラスからの継承よりも委譲を使うようにしよう。

第4章 例外
項目22 raiseにはただの文字列ではなくカスタム例外を渡そう
項目23 できる限りもっとも対象の狭い例外を処理するようにしよう
項目24 リソースはブロックとensureで管理しよう
項目25 ensure節は最後まで実行して抜けるように作ろう
項目26 retryでは回数の上限を設け、頻度を変化させ、オーディットトレイルを残そう
項目27 スコープから飛び出したいときにはraiseではなくthrowを使おう

第5章 メタプログラミング
項目28 モジュール、クラスフックを使いこなそう
項目29 クラスフックからはsuperを呼び出そう
項目30 method_missingではなくdefine_methodを使うようにしよう
項目31 evalのさまざまなバリアントの間の違いを把握しよう
項目32 モンキーパッチの代わりとなるものを検討しよう
項目33 エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34 Procの項数の違いに対応できるようにすることを検討しよう
項目35 モジュールのprependを使うときには慎重に考えよう

第6章 テスト
項目36 MiniTest単体テストに慣れよう
項目37 MiniTest仕様テストに慣れよう
項目38 モックオブジェクトで決定論をシミュレートしよう
項目39 効果的なテストを追求しよう

第7章 ツールとライブラリ
項目40 Rubyドキュメントの扱い方を覚えよう
項目41 irbの高度な機能を使えるようになろう
項目42 Bundlerでgemの依存関係を管理しよう
項目43 依存gemのバージョンの上限を指定しよう

第8章 メモリ管理とパフォーマンス
項目44 Rubyのガベージコレクタの動作に慣れよう
項目45 Finalizerでリソースリークを防ぐセーフティネットを作ろう
項目46 Rubyプロファイリングツールを使おう
項目47 ループ内ではオブジェクトリテラルを避けよう
項目48 コストの高い計算をメモ化することを検討しよう

Effective Rubyを読んだので感想を書いてく - WEB SALADの記事も参考になる。

【3-6】「Rubyのしくみ Ruby Under a Microscope」はRubyのインタプリタYARVの仕組みを解説しているディープな本。
普通はこの本のレベルまで理解する必要はないと思うけれど、僕はRubyの定数探索のアルゴリズムと特異メソッドがどうしても腹落ちできなかったが、この本で何となくイメージできた。

たとえば、Rubyのメソッド探索は継承チェーン上に1本でたどる一方、定数探索は最初にレキシカルスコープで検索してから次に継承チェーンをたどる。
よって、定数検索の方がやや複雑だし、ソースを上から読み込むので、そんな挙動になるのかという発見もあった。

たとえば、Rubyのオブジェクトの特異メソッドやクラス本体のクラスメソッドは、特異クラスという別のクラスに存在する。
よって、特異メソッドやクラスメソッドが存在する場所は別のクラス、特異クラスにあるので、特異クラス系列の継承ツリーが別途存在する。

なお、「メタプログラミングRuby第2版」にも特異クラスの絵が掲載されていて詳しく説明してくれているのだが、通常のクラス系列の継承ツリーと、特異クラス系列の継承ツリーを混ぜ込んだ絵で記載しているので、僕には分かりづらかった。
一方、「Rubyのしくみ Ruby Under a Microscope」では、メモリ上にRubyのオブジェクトがどのように配置されるのか、絵が書かれているので、僕には理解しやすかった。

結局、プログラミング言語を理解するには、メモリ上に変数やオブジェクト、配列、ハッシュがどのように配置されるのか、を自分の頭でイメージできなければならないから。

下記の章がお勧めと思う。
Rubyがメモリ上にどのように展開してくれているのかをイメージしやすくなる。

第5章 オブジェクトとクラス
第6章 メソッド探索と定数探索
第8章 Lisp から借用したアイデア
第9章 メタプログラミング

Rubyの定数のお話 | media.growth-and.com

Rubyの定数探索の個人的な謎に迫る - Qiita

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

【4】Rubyを実際に実務に使う場合は、事実上、Railsをマスターすべきだと思うので、Redmineのソース解読もしながらちょっとずつやっている。

Javaや.NETのWebシステムの開発経験からRailsを見ると、Web開発でまどろっこしい共通処理やWeb特有の処理をRubyのメタプログラミングで上手く隠蔽して、コーディングルールを強制することで数行で書けるようにしている部分はすごいな、と改めて思う。

僕がRailsですごいなと思う点は、特に、JavaScriptとの相性が良い点だ。
Railsが生まれた当初から、prototype.jsやJQueryとの連携はスムーズだったし、JavaScriptを駆使することでWebのUIを豊かにしてくれた。
最近のRailsは、JSライブラリの発展とともに、VueやReactとも親和性が高い。
つまり、クライアントサイドのUI改善も取り込めるので、JavaやPHPなどの他の言語よりもRailsの優位性は高いような気がする。

【5】Rubyを勉強している時の僕の脳みそは、錆びついた機械時計に油を挿しながら、回転させようとしている感覚だった。
こういうことをRubyで実現したいんだ、要件や設計は分かっているのになぜすぐに書けないのか、という苛立ちを感じながらRubyのライブラリを覚えて、動きに慣れようとしていた。

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索にある「プログラミングができない羊」みたいな地点から登っている感じだった。

でも、初めてのプログラミング言語を習得するには、どんな手順を踏めば良いのか、どういう点に注意すれば習得速度を上げられるか、という感覚はつかめてきた。
今は次のプログラミング言語としてPythonを習得しようとしているが、Rubyの習得経験や、RubyとPythonは考え方が似ているメリットもあって、割と楽に習得できそうな感じ。

結局、プログラミング言語が分かったという感覚になるには、自分の脳みそがコンパイラになりきって、メモリ上に変数やクラスがどのようにロードされて値が変わっていくのか、イメージできる必要がある。

こんな経験は誰でも知っているのだろうが、20代の若い年齢なら簡単であっても、40・50代と年齢を取るごとに、新しいプログラミング言語の習得はどんどん難しくなる。
しかも、プログラミング言語の隆盛は10年おきに移り変わるから、そのたびに以前の言語を捨てながら新しい言語に慣れていかないといけない。
たとえば、FortranやCobolからC/C++/VB、そしてJavaやC#、さらにRubyやPHP、そしてPythonやR、へどんどん変わってきている。
JavaもKotlinで書くのが普通になってきているようだし。

そんな事を考えると、アジャイル開発は常識だ: プログラマの思索にも書いた通りだったのを思い出す。

(引用開始)
ソフトウェア業界の特徴の一つは、一度高い能力が得られてもそれを完全にやり直さねばならない点がある。
Cobolで一流であったとしても、JavaやC#のプログラミングは一流とは限らない。むしろ、オブジェクト指向の概念を知らない可能性も高く、オブジェクト指向の初心者かもしれない。
Javaを知っていても、RubyやiPhoneやAndroidアプリは初心者かもしれない。
様々な言語を学び、共通部分があったとしても、技術の変化によって常に立場は悪くなり、完全に分かったという状態にはならない。
また一から勉強して成長しなければならない。
(引用終了)

最終的には何かアプリが作れればいいな、と思っている。

| | コメント (0)

2020/05/07

ユタ州15歳少女と父親のデュエット「The Prayer」のリンク

ユタ州15歳少女と父親のデュエット「The Prayer」をYouTubeで聞いた所、思わず聞き惚れたのでメモ。

ユタ州15歳少女と父親のデュエット「The Prayer」、国を越えて反響 - VOICE 洋楽

コロナウイルスの状況は日本よりも米国の方がひどいとニュースで聞く。
そんな中で、素晴らしい歌声を聞きながら、下記の記事にも惹かれた。
「ウイルスよりも伝染しやすい唯一のものは、希望です」という言葉はまさにその通りと思うし、こういう状況だからこそシンプルな言葉が響く。

(引用開始)
With so much going on in the world, sometimes it’s best to pause and remember the simple prayer of a father and daughter for “life to be kind.”

「世界で様々なことが起きているなか、時には立ち止まり、”穏やかな人生”への父と娘のシンプルな祈りを、思い出すに越したことはありません」(Facebook)。

(中略)

試行錯誤しながら、共に学びながら歌い、親子の絆を深めているという。子どもたちはあっという間に大人になり、巣立っていく。マットは「このコロナウイルスの状況の中で、私たちにとって一条の光があるとすれば、それは私たちが一緒に過ごす時間がたくさんできたことです」。

(中略)

マットは、「ウイルスよりも伝染しやすい唯一のものは、希望です」、「ですので、少しでも希望を広げる小さな手助けができればと願っています」。
(引用終了)

「The Prayer」のYoutubeのコメントに思わず声を失ったし、そういう中で人間性を保ち続ける厳しさも感じ取った。

(引用開始)
My husband has been battling cancer. He was in the hospital having part of his liver removed and because of the Corona Virus I was not allowed in the hospital to be at his side. I was home pacing and scared. A friend sent me an email and told me to listen. I sat alone at my computer, listening to your song, with tears streaming down my face. I have heard The Prayer sung by many different artists but you two are the most amazing! Not only do you have the most beautiful voices, you two have the most pure, sincere voices! You sing from your soul! I can't thank you enough for touching the deepest part of me and lifting me up during a very dark and scary moment in my life. You both have been given an incredible gift. God Bless You for using it to lift so many others! With Love and Gratitude, Debbie
(引用終了)

「You Matter to Me」も素晴らしい歌声。
最初は「You Matter to Me」の意味が分からなかったが、娘も父親もすごく心も力も込めて、「ユー・マター・トゥー・ミー」と歌うので、その意味を思わず辞書で調べた。
たぶん「あなたは私にとってとても重要なのです」というメッセージ。
つまり、「あなたは一人ではない。私があなたの存在を必要としている」というメッセージを送っているのだろう。

でも、今回のコロナウイルス事件は、親密な人間系を大切にする欧米の文化をことごとく潰そうとしているのだろうと思う。
Social Distanceの文化は、人間関係の距離を縮めたい本能を妨げるものだから。

Savanna ShawはInstagramを利用しています:「My little sister was slowly walking towards my mom today, crying and heartbroken. My mom thought maybe she’d fallen off her bike, but when…」

(引用開始)
My little sister was slowly walking towards my mom today, crying and heartbroken. My mom thought maybe she’d fallen off her bike, but when she asked her what was wrong, she said “I miss my grandma. I just want to be close to her. I wish the quarantine was over.” ? The physical distance from our loved ones has been so difficult, even for young children! Grandma matters to Pennie Jean. Our family and our friends matter to us, and we matter to them. But, that’s not where the circle of “people who matter” ends. To all of the healthcare workers and first responders keeping us safe, you matter. Those who are working overtime so stores are able to stay stocked with essential items we need to live, you matter. To the moms and dads who are now juggling their normal responsibilities with homeschooling and easing the worried hearts of their children, you matter! .
.
There is so much love to be given, and received. Tell somebody they matter to you. ??
(引用終了)

こういう洋楽を聞いていると、欧米人は表情豊かで、親密な人間関係を大切にする人達なのだ、と改めて感じる。
だから、初対面でも、ハグしたり、キスしたり、個人的なパーティを開くわけだ。
そういえば、かつて下記のような記事を読んで、その時はピンとこなかった。
しかし、今はその意味が分かるようになった。

恥ずかしくなるくらいでちょうどいい! 英語の息の使い方 | 語学力アップブログ | アルク

(引用開始)
かつて私がイギリスに留学中、ある程度英語は話せていたけれど、今思えばまだまだ平坦にしゃべっていた頃、イギリスで育った日本人の友人が私のステイ先に遊びに来ました。彼女がホストマザーと話していた時、その家にあった立派な置物を誉めるのに、

"Oh, that's beautiful!"

と言ったのですが......。
皆さん、今これをさらっと読みましたね? 違うんです(笑)。彼女は(文字では表しにくいのですが、あえてひらがなで)「びゆーてぃふぉー」と、「ユー」の音をものすごく強く高く叫んだのですよ。これにはやられました。「うわ、やりすぎ......」と、こちらが恥ずかしくなるくらいでちょうどいいのね、というのを私はこの時学んだわけです。
(引用終了)


| | コメント (0)

2020/05/05

After Covid (With Covid)の世界や付き合い方

After Covid (With Covid)の世界や付き合い方について、papandaさんの記事がとても秀逸なのでメモ。
自分が考えていることをラフなメモ書き。

【参考1】
ウィズコロナにおける事業の再定義 (逆ゴールデン・サークル)|papanda|note

(引用開始)
4月が終わろうとしている。コロナを意識する状況が2月から数えると3ヶ月に経過することになる。緊急事態宣言を予定どおり終えるという可能性は低そうだ。こうした状況でも、引き続き事業作りやデジタルトランスフォーメーション事案の支援をしている。

 この状況が始まった当初は「いつ元に戻るか」「戻ったときに備えて何をしておくべきか」という前提を置いて支援にあたっていたが、ここに来て自分が使う言葉が変わっていることに気がついた。「これまでから、どう変えますか」

 仮に宣言を5月末で終えられたとしても、今後第2波、第3波に備える適応が求められるだろう。そこまで続いていくことを考えると、人の生活スタイルは変わらざるを得ないはずだ。生活の行動や思考の変化は、価値観の変容へと繋がる。私達は「戻る場所を失って、次に向かう場所を得る」過程にあるのかもしれない。
(引用終了)

(引用開始)
得てして、自己認識している「対面コミュニケーションこそ、これまで培ってきた強み」(実際に間違っていない)が、次の適応を阻む現状維持の重力になりやすい。ぼんやりと現状に対応し続けていると、手遅れになりかねない。意識的な再定義(redesign)が必要だ。

 なお、この問いの組み立ては、以下の構造をなぞっている。

何をしている?(What) → どのようにする? (How) →意味は何? (Why)
 いつものゴールデン・サークルとは真逆だ。差し迫るような非常時には、適応行動の方が早い(そうしなければ日常が崩壊する)。ただ、急場しのぎの手段になっていることが多いため、そのままの延長ではなく、その適応行動をより効率的に、より効果的にするためには根本的に何が必要なのかを捉え直す。その上で、その行為は何なのか意味づけを行う。
(引用終了)

【参考2】
discordが再定義する「ともに居る場所」|papanda|note

(引用開始)
箱の意味を再定義する
 箱(ワークスペース)は、組織や部署、チーム、プロジェクトなどという単位で作られることが多いだろう。箱は現実世界の組織の写像となる。ゆえに、現実世界の組織にある、内外を分け隔てる強力な境界線がそのまま引き継がれることになる。用もないのに、むやみに人を招き入れることが無いということだ。

 それはdiscordで箱(サーバ)を作ったときは同じだ。ただし、人と人との関係性は、フレンドという箱に依らない方法で形作ることができるため、フレンドを眺めていて、ある人とある人を含めて新たな目的で箱を作るということが簡単にできる。箱(ワークスペース)単位で世界が分断されているslackと違って、discordは新たな場所を作る行為がその枠組み中にビルドインされている。

 これは画期的なことだと思った。
(引用終了)

【参考3】
discordで、同じフロアにいて「ちょっといい?」と話しかけるあの感覚を思い出した。|papanda|note

(引用開始)
いよいよリモートワークが増えてきた。年季の入った組織でも、なし崩し的に(備えなく)、全員フルリモートへ突入、という潮目になってきている。現場、組織運営としてはここから正念場に入っていくことになるだろう。
(引用終了)

今年初めの時点で、リモートワークやオンライン勉強会が普通になるなんて誰も想像してなかったはず。
でも、緊急事態宣言が発令されて1ヶ月以上たった今、皆薄々分かってきたことは、今の変化は不可逆的なことだ。
おそらく、コロナウイルス流行は今後数回発生するかもしれない。
そうなれば、数年は今のような状況が続く。

今は、After Covid (With Covid)について、誰もあるべき世界は知らない。
Twitter、Facebookによるオンラインのつながり、Youtubeなどの情報発信などでグローバルにやり取りできる世界なのに、外出するのはせいぜい、スーパーへの買い物ぐらいで、それ以上遠くに行くことすらできない。
飛行機はもちろん、電車に乗ることさえ憚られる。
オンラインの世界は広いのに、今の時点では、人と対面で会う現実世界の範囲はせいぜい3キロ圏内しかないのだ。
このギャップにたぶん、誰もまだ付いていけてない。

そういう状況を想像して対処するには、リモートワークやそれに付随した仕事環境、生活環境を準備すべきだし、そういう方法に慣れていくべき。

papandaさんの記事で興味深い点はいくつかある。
一つは、Why→What→Howという今までのトップダウン的な考え方ではなく、How→What→Whyというボトムアップ型のアプローチで思考せざるを得ないこと。
実際、誰もあるべき世界を知らないのだから、実際に行動して、それから考えを深めていくしかない。
もう一つは、SlackやZoomよりもDiscordを推していること。
Slackでは逐一、チャットしたい相手を招待する手間がある。
Zoomでも対面で話したい人を招待する手間がある。
しかし、discordには、組織やロールのような概念があるので、招待するというよりも、何らかのグループでまとめて、話をするチャネルを作るだけ、という。
この点は、なるほど、と参考になる。

仕事も生活もオンライン環境になった時、どんな価値観や行動様式が求められるのか?

1ヶ月間のリモートワークやオンライン勉強会を経験して分かったことは、そんなに寂しいという感情はなく、誰かとつながっている感覚を保ち続けることができた。
以前にオフラインで仕事や勉強会で気心の知れている人とは、コロナ事件後でも、オンラインの世界でも何事もなくスムーズにやり取りできる。
この人の発言にはこんな気持ちがあるのかな、とか想像できる。

ゴールデンウイークも全く外出できなかったが、1日でオンライン勉強会をZoomで3回ハシゴした時もあった。
Zoomで話しかけたり、自分の意見を述べたり、チャットで反応したりすることで、全く違和感もなかった。
以前なら、1日の間で、全く異なるコミュニティを3つもハシゴすることはできなかったはず。
でも、オンラインの世界ならば、東京であっても大阪であっても関係ないから、どこでも人につながることができる。
そういう意味では、少しずつこの環境に自分を慣れようとしている。

一方、初めての人との人間関係の構築やチームビルディングは苦労している。
たまたま緊急事態宣言の前に対面で会うことができた人とは、その後のオンラインのやり取りはスムーズにできる。
しかし、初対面の人やチームには、相手がどんな性格や人物像なのか分からないので、どんな言葉をかけたら良いのか、どう進めていけば良いのか、まだ分からない。
手探りでやっている。

今後の課題は、オンラインの世界で初対面の人との関係構築や、オンラインでのチームビルディング技術がある、と感じている。
その課題の解決方法は、今はほとんどの人が知らない。
その課題を解決した後のあるべき世界を知る人はほとんどいない。
だからこそ、試行錯誤することに意義がある。


| | コメント (0)

緑バージョンのこどもRedmineが可愛い

@akiko_pusuさんが公開された緑バージョンのこどもRedmineが可愛いのでメモ。

【参考】
たかのあきこ@freeCodeCamp攻略中さんはTwitterを使っています 「I created this theme inspired by JIRA Jr., various WordPress themes for kids and children and Animal Crossing?? This theme is still experimental, but I hope to provide a more friendly #Redmine with bright colors and fun fonts. https://t.co/1j29EYZvMu」 / Twitter

akipiiさんはTwitterを使っています 「緑バージョンのこどもRedmineは、どうぶつの森をイメージしていたわけか!? https://t.co/fNMv167HII」 / Twitter

たかのあきこ@freeCodeCamp攻略中さんはTwitterを使っています 「@akipii はい、そこはかとなくです」 / Twitter

akiko-pusu/redmine_theme_kodomo_midori: Redmine theme for kids and children green version.

以下、Twitterの画像参照。

Redmineを普及推進していく上で、RedmineのUIは古臭いと言われがち。
でも、こういう可愛いテーマがあれば、緊急事態宣言で家に閉じこもっている子どもたち向けに、学習状況の管理にRedmineを使ってもらう、など、色々やり方が生まれるのではないだろうか。

こどもRedmineテーマは、40代のおっさんの発想では無理なので、女性や若い人のように色んな人達の発想が必要だな、と思う。

以前、@akabekobekoさんもRedmine勉強会で講演された時に、SCSSを駆使してRedmineのテーマを開発することで、Redmineをお化粧してみましょう、という事例もあったな。

第17回勉強会 - redmine.tokyo

Redmineのプラグインだけでなく、テーマも色々試してみるといいかもしれない。
見た目が変わるだけでも、初心者ユーザの敷居は低くなるから。

その場合、redmine_theme_changerを使うといいだろう。
デフォルト機能では、Redmine全体のテーマを切り替えするしかないが、redmine_theme_changerプラグインを使えば、ユーザ単位でテーマを保持することができる。
よって、ユーザは自分の好みでテーマを決定できるようになるので便利。

Theme Changer - Plugins - Redmine

haru/redmine_theme_changer

【追記1】
akipiiさんはTwitterを使っています 「いいね!RT @shara52750009: GW こどもれっどまいん構築で、Redmine が好きになったのが 嬉しいです こどもれっどまいんの Themaなら、 早ければ3歳くらいから、、、 プログラミングを習い始める子たちが、アプリを触り始めるのにも良さそうです https://t.co/KTTMMZQ8Qe」 / Twitter

【追記2】
akipiiさんはTwitterを使っています 「これは欲しい!RT @ryouma_nagare: @akiko_pusu ・redmine_theme_kodomo_midori ・redmine_message_customize ・view_customize を組合わせた結果がこちらになります。 胡散臭いシステム開発会社のホームページっぽくなったw https://t.co/yuLH5bHSUg」 / Twitter

以下、Twitterの画像参照。

| | コメント (0)

2020/05/04

Redmineとチャットツールはどのように使い分けるべきなのか

「Redmineとチャットツールはどのように使い分けるべきなのか」という疑問についてラフなメモ。

akipiiさんはTwitterを使っています 「第18回勉強会 - https://t.co/i2sJFMEe2v の議題は、やはり、テレワークにRedmineをどのように有効活用して運用できるか、という点と思います。多分Redmineを普段運用していればスムーズに移行できたはず。今回の緊急事態宣言によってRedmineのメリットが明確になったはず。 https://t.co/XHELA5jGsZ」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを利用する一方、チャットツールを皆さんは何を使っているのか、も気にしてます。チケットに書くほどでないコミュニケーションはChatツールを使うならばRedmineとチャットツールを使い分ける基準は何か? チャットが重視されるとRedmineのチケット起票が重く感じられる為。」 / Twitter

y503Unavailable@Redmine Kindle本出版unofficialcookingさんはTwitterを使っています 「@akipii 先月からTeamsですが、チャットはフローでありストックではないことを明確にしています。 相談程度はチャットで軽く進め、途中経緯をRedmineにコピペし蓄積。 チケット起票しないと設定しない程度の運用を確立していれば回ると思います。」 / Twitter

齋藤さんはTwitterを使っています 「@y503Unavailable @akipii Teams には、内容のコピペとかコピーとかの配慮があまりなくて、長くなると面倒なんですよね。是非、そこは強化して欲しい。」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii ストックとフローの話はどこかでやりましょう コミュニケーション設計からコストを下げるような」 / Twitter

たけちゃんさんはTwitterを使っています 「@akipii @MadoWindahead chatはTeamsを使ってますが、コミュニケーションとタスク管理で用途を分けているつもりが、プロジェクト毎に線引きが異なって来ました。Teamsもシェアポイントでのファイル共有ができるので、ちょっとしたファイルはこっちでやり取りしちゃう人も出てきます。」 / Twitter

akipiiさんはTwitterを使っています 「@ta_ke_chan_ @MadoWindahead そう、よく分かります。GSuiteを使ってると、Google Chat, HangoutMeetを使ううちにGoogleスプレッドシートなどで課題管理やタスク管理し始めてしまったり。ツールの利用シーンはどうしても組織文化が出てくる」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii @ta_ke_chan_ そう、GSUITE派なのでどうしても二次元管理が横行してます 二次元で大丈夫なものはそれでもいいと判断したいので、redmineがいいパターンを出したい あと、chatやSNS系(salesforceなど)の長所短所もまとめればいいのかな? たけちゃんはhttps://t.co/EeqCzfWvkz参加ですね よろしくお願いします」 / Twitter

neta @ redmine.tokyo 5/23(土)オンラインやりますさんはTwitterを使っています 「@MadoWindahead @akipii @ta_ke_chan_ ウチは G Suite 『Google ( Hangout ) Chat』なので、まずは Redmine の通知を連携することからはじめたいと思ってる」 / Twitter

テレワーク中のシロくまさんはTwitterを使っています 「テレワークができる環境づくりに役立ったもの ペーパーレス⇒プロジェクト管理(Redmine) コミュニケーション⇒チャット(Microsoft Teams 秋から会社方針でGoogle Meets) 固定電話⇒クラウドPBX(Dialpad) 次は仮想オフィスツールがねらい目でしょうか。」 / Twitter

吉澤さんはTwitterを使っています 「パン工場じゃ無理だけど、WBS書いて、redmineでチケット切るようになれば、日本の事務職の生産性は飛躍的に向上すると思う。 https://t.co/E6V2xJhGIZ」 / Twitter

【1】昨今、急にテレワークの作業環境を強いられた場合、Redmineのようなプロジェクト管理ツールでプロジェクト運営していなかったら、案件で開発するのは非常に難しいだろう。

一方、従来からRedmineでプロジェクト運営していたら、VPNさえ確保できれば、オンライン上で作業の管理を継続できるので、スムーズに移行できているだろう。

しかし、日々にコミュニケーションはオフラインのチャネルが全て駄目になったので、オンライン上で何かしらのコミュニケーションが必要になってくる。
もちろん、Redmine単体でチケットのやり取りを通じて、日々の課題やタスクは管理できるが、それだけではコミュニケーションは足りない。
たとえば、非公式なコミュニケーション、ZoomやGoogleMeetによるオンライン打合せを補強するチャットなどでチャットツールが欲しくなる。
おそらく一般には、Slack、MSならTeams、GooleならGooleChat、他に、FB Messenger、LINE、Discordなどが使われているだろう。
つまり、Redmineのようなプロジェクト管理ツールだけではプロジェクト運営は不十分であり、もっと気楽でレスポンスの早いチャットツールが必要ではないか、と思われる。

【2】では、Redmineとチャットツールはどのように使い分けるべきなのか?
また、Redmineとチャットツールを併用することでどんな問題が噴出して、どんな課題が出てくるのか?

「顧客ごとにチャネルがこれだけ違うとは。リアル過ぎて参考になる。RT @_alimika_: 顧客A→Slack 顧客B→Facebook Messenger 顧客C→Chatwork 顧客D→Microsoft Teams 顧客E→メールオンリー 顧客F→Backlog オンリー 顧客G→Confluenceオンリー 顧客H→Redmine オンリー 顧客I→GitHubオンリー」 / Twitter

【2-1】一般には、Redmineのチケットは記録して残す内容、チャットは日々流れて消えてしまう内容、というように使い分けているだろう。
しかし、その使い分けは人によって様々に異なる。

Slackでは、数多くのスレッドをチャネルとしてどんどん追加できるので、チーム間や1対1のやり取りが非常にやりやすい。
すると、そのチャットのやり取りだけで、仕事が捗るので、チケットにわざわざ残すのが億劫になる。
チケット上で成果物のレビューをキャッチボールするのが非常に時間がかかるように思われて、チケットに逐一残すのが面倒に感じてしまう。

特に、気心の知れたメンバーであれば、チケット化しなくても、お互いの暗黙知でいい感じに何とかなってしまう時も多い。
すると、課題やToDoがあったとしても、お互いの頭の中に共有されていて、チャットで常に同期されている感覚になる。
わざわざチケットでやり取りするほどでもない、みたいになってしまう。

【2-2】一方、チャットでは大量の発言が流れる場合が多いので、何が決まったのか、どんな経緯で結論に至ったのか、を把握するのが難しくなる。
作業がスムーズに運ぶ場合はチャットで十分だが、試行錯誤しながら振り返りを参考にして進める場合には、何かしらのログを残したくなる。
しかし、チャットで議論した内容をチケットにまとめる作業は割と手間はかかる。
その手間とチケットの起票更新のコストのトレードオフを無意識に計算しているような気もする。

他方、Githubでプルリクをやり取りするプロジェクトであれば、ソースコードのコミットとプルリクが重要であるから、その部分は必ずチケット化される強制力は働く。

【3】Redmineとチャットツールの間の情報連携にも、いくつか問題や課題はある。

【3-1】ITS(Redmine)→チャット(Slackなど)へ連携する運用は多い。
その理由は、Redmineのチケット・Wiki更新の通知をメールではなく、チャットで把握したいからだ。

Redmineの通知メールは正直うっとうしい。
たとえば、コメントなしの単純なステータス更新、項目更新だけでも通知メールが飛ぶので、プロジェクトが活発になると、1日100通以上のメールが飛び合うのはよくある。
大量のメールに更新内容が埋もれてしまうよりも、チャットで流れた方が正直扱いやすい。

【3-2】一方、チャット(Slack)→ITS(Redmine)の情報連携は手作業でやるのが多い。
REST APIを駆使すれば、チャット内容をチケットに起票できるだろうが、チャットの手軽さの文化と合わない気はする。

しかし、チャットで議論された内容をチケットに記載したい場合は多い。
議論していくうちに、こういう課題は検討すべきだ、とか、ここまでは解決できたから残りはこのToDOだけだね、とか、色々出てくるはずだ。
それらの内容はチケットに残して、誰が担当してボールを持っているか、その課題はどんなステータスにあるのか、を後日把握したいからだ。

そういう運用をしたい時に、チャット→ITSの情報連携をもっと気軽にやりたい課題がある。

【4】Redmineとチャットツールの情報連携の問題点は、たとえば、RedmineやJenkins、GitLabなどの開発基盤の連携とは観点が異なる。

後者は、作業の起点がチケットであり、チケットが更新されていくたびに、Gitへコミットされたり、JenkinsやCircleCIなどでビルドされて、ビルドモジュールがリリースされていく。
つまり、ソースコードという成果物の構成管理が、利用シーンに応じて各種ツールで管理されていくべきだ、という観点になる。

一方、前者は、プロジェクト内のコミュニケーションは、どんなチャネルでやり取りすべきなのか、という点が本質的な観点だ。
議論で発散していくフェーズならばチャット、発散した議論を収束させて検討すべき課題や残タスクにまとめて管理していくならば、Redmineのようなチケット管理ツールが必要になる。
つまり、チームで議論している内容を、チャネルごとに無意識に使い分けているのではないだろうか。

だからこそ、コミュニケーションチャネルをどんな利用シーンでどのツールでやるべきなのか、をプロジェクトリーダーは明確に意識しておくべきだろう。
コミュニケーションチャネルを意識することで、Redmine単体で運用している時よりも、チーム内のコミュニケーションが活発になり、単純な命令伝達だけでなく、メンバーのモチベーション向上も期待できるだろう。

この辺りの事例も色々収集してみたい。

| | コメント (0)

2020/05/01

Redmineとbacklogに関するゆきあさんの記事

RedmineとBacklogに関するゆきあさんの記事をメモ。
体験談に基づいているので、すごく説得力を感じた。

Redmineをどうも好きになれない人のための、20%の基礎を抑えれば、80%位の業務に対応できると気がついた長話。|ゆきあ|note

気になった点をいくつか引用しておく。

(引用開始)
では、backlogには出来なくて、Redmineの得意な事とは、何だろうか。
これに答えられるようになるのが、一番初めの準備だ。
色々な回答があると思うが、僕の見つけた回答は、
ワークフロー機能、つまり権限や承認による、
組織的な統制の設計自由度が高いこと、である。
(引用終了)

Redmineとbacklogでは、それぞれの利用シーンがかなり限定されているのだろうと思う。
backlogはSaaSで提供されているので、利用者のニーズを収集して即反映していくことにより、特定の利用者に最適化されているのだろうと思う。
僕はbacklogの詳細は知らないが、日本の一般の中小企業ユーザにとってはリーズナブルで使いやすいのだろうと思う。

一方、Redmineもredmine.orgで議論された内容が随時反映されて、最近はUIもかゆいところに手が届くようになってきた。
Redmineの利用シーンを考えると、Redmineはオンプレで導入する場合が多いので、自分たちの組織に合うようにカスタマイズした場合が多いのだろうと推測する。
つまり、インフラ構築と運用が自前でできるならば、カスタマイズしやすいRedmineの方が使いやすいのだろう。
日本の企業は、特にメーカーは、自分たちの組織文化にこだわりを持っているので、自分たちの業務フローに合わせたツールを欲しがる傾向があると思う。
そういうニーズにたぶん、Redmineは合っている。

(引用開始)
トラッカーとは行動パターンの大分類である。
ロールとは、役割に名前をつけることである。
ワークフローとは、トラッカーとロールごとに、チケットの状態(ステータス)の変化を定義する事が出来る、最後の仕上げである。
(引用終了)

「トラッカーとは行動パターンの大分類である」という指摘にしびれた。
なるほど、そういう表現の方法もあるのか、と。

ワークフローが同一だったり、チケットの項目が同一であれば、トラッカーはより抽象的にアウフヘーベンされた概念にした方が良い。
そうでなければ、似たようなトラッカーなのに名称が違うトラッカーが乱立して、異音同義語のようになってしまい、ユーザも混乱してしまうから。

いろんな現場のRedmineを見る時、トラッカーの名前を見れば、だいたいどんなワークフローなのか、推測はできる。
トラッカーは、業務を抽象化した概念であり、その会社の業務(行動パターン)を分類した概念である。

(引用開始)
最悪のパターンなのは自分がRedmineの管理者権限を持てないような場合だ。
(引用終了)

この意見は同意する。
プロジェクトリーダーである自分自身がRedmineを構築してプロジェクト運営した経験があった。
その時、チケット管理ツールと開発プロセスのフィットギャップ分析を自分で試行錯誤しながら、アジャイル開発の概念をいかに取り入れていくか、を試していた時もあった。
そういう時は、システム管理者の権限が自分にあれば、好きなようにトラッカーやワークフローを作って、チームメンバーに試してもらい、自分が理想とする開発プロセスのアイデアを試すことができる。

そういう状況が、Redmineを使っていて一番楽しい時だ。
「ツールが開発プロセスを改善する」「Redmineでソフトウェア工学の理論を実験する」という感覚を持つことができて、まるでRedmineを使って、チームメンバーの行動やチーム運営を実験している気持ちになった。

Redmineの良い所は、経験不足のプロジェクトリーダーであっても、技術力さえあれば、Redmineなどの開発基盤を駆使することで、プロジェクト運営に必要な開発プロセスを自前で構築できることだ。
マネジメントの経験が不足していても、各種ツールを組合せた開発基盤を使って、再現可能な開発プロセスを持つことができ、プロジェクトマネジメントやチームビルディングをどんどん改善することができる。
だから、若手の人にもっとRedmineを使ってもらえたら良いな、と思っている。

| | コメント (0)

« 2020年4月 | トップページ | 2020年6月 »