"Are you too busy to improve ?" について考えた。
前口上
今回紹介するのは、あるブログ記事の画像です。
記事はこちら。（何故かタイトルに が入ってる、、？）
Are you too busy to improve?hakanforss.wordpress.com
この画像をネタに一つ書いてみようと思います。もしも、「画像 “Are you too busy to improve ?” から考えられることを記述せよ。」というお題が降ってきたら？
画像内容そのものの理解
台車を引く人がいる。台車の車輪は四角くて押すのは大変そう。その傍らに丸い車輪を持ったヒゲメガネの人がいる。 丸い車輪を台車を引く人に提示している。丸い車輪なら楽に早く台車が進みそうであるが、台車を引く人は「忙しいから要らない」と答えている。 提案を拒否している情景である。
画像から読み取れること
仕事の仕方の改善（＝生産性の向上）は、往々にして受け入れられません。ビジネスを止めてまで実施する価値があると思われることが少ないです。 ではその理由として考えられることはたくさんあるとおもいます。いくつか挙げてみます。
- 台車を引く人はヒゲメガネの人を信頼していない。
- ヒゲメガネの説明が改善になると理解されていない。
- 改善だと理解されているが、ビジネスを止めてまでする価値が無いと判断されている。（効果が小さいなど）
- 価値があると理解しているが、今そのタイミングでないと判断されている。（外部要因的な何かがある。）
そして、いずれの理由にせよ理由がヒゲメガネの人に伝わっていないことも同時に起きています。 このようなコミュニケーション不全から、総合的なパフォーマンスが向上しなくなってしまいます。 複数人で仕事をしているのに協力が無いのはもったいない話です。
まとめ：教訓として考えられること
忙しくても最低限の対話をすることが重要です。 ヒゲメガネの人に受け入れられない理由が伝われば、彼は状況を理解して次の手を考えることができます。対話がなければそれも出来ません。 対話があれば組織としての最適な行動を取ることが期待できます。
余談
こんなプレゼン発表があったようです。これについては追々キャッチアップしてまたネタになりそうなら使ってみたいです。
メール削除ツールを作ってみた。
使っているgmailの環境では大量のメールが流れてくるのですが、そういうのをバッチよろしくまとめて削除するツールを作りました。
メアドとパスワードと環境設定をいくつかやれば、誰でも使えるツール（のはず）です。
ここでは作ってみた印象を並べてみます。
安全性の低いアプリとみなされるのはちょっと残念ですが、こうならないためにはOAuth認証が必要ぽくて大仰すぎるので諦めました。このツールを使ってあらかた消せたのでしばらくの間使わなくなるのですが、また使いたくなったら考えてみるかな。
java.util.concurrent.ExecutorServiceを使った教科書通りのマルチスレッドなバッチで作ってて楽しかったです。パラメータを弄ってどうすれば速くなるか試すの楽しい。当初はJavaMailで直接削除していました。これは1件1件削除なのでとても遅かったのです。しかし複数まとめてゴミ箱フォルダに移動させるとやりかただととても速いことを見つけてちょっと感動したりとか。あと実行時のログの出方を工夫して、どのスレッドが速くメールを捌けているか見てみたりとか。
大した事のないごく小さいツールですが、自分で作ると楽しいですね。
コミットメッセージと言うものを5W1Hで捉えなおしてみる。
5W1H とは以下の６個をまとめたものです。
- What なにを
- Why なぜ
- When いつ
- Where どこで
- Who だれが
- How どのように
ニュース記事の慣行とか、情報伝達のポイントらしいです。
さて、gitなどソースコード管理システムでは、コミットにメッセージを残しながら開発を進めますが、これと5W1Hを並べて考えて見ました。
- When と Who は、管理システムが機械的に残してくれます。
- What と Where は、考え方次第なところがありますが、修正を入れる前のコミット（あるいはリビジョン）か、修正を入れる箇所（どのファイルの何行目）と考えられます。
- How は、修正前後の差分です。
以上のものは管理システムが機械的に残してくれますが、そうでないものがあります。 Why。これはシステムが機械的に残してはくれません。開発者が人力で頑張ってコミットメッセージで残す必要があります。これの書き方についてはいろいろな意見があるようですね。
個人的にはコミットを一覧で見る事が多いので、「何のために何を修正した」という体裁の一文にするようにしています。（ボリューム的にも一文で済む量に抑える。）「何のために」というのを毎回考えるのはちょっと頭の切り替えが必要だったりしますが、後々どうしてこうなったのかを調べたいときには有益なのかと。ちょっとした文言直しとか、CSSのデザイン修正だと単に「UI改善のため」とか簡単なものに割り切ることもあります。無理すぎたら諦めたりもします。（"fix typo" みたいな小さい修正とか。）
コミットでの修正内容とメッセージをわかりやすい形で残していく。コミット職人にでもなったような気分です。
別の話ですが、共有フォルダにExcel方眼紙で仕様を書いているところもあります。このやり方は5W1Hはまったくない世界ということになりますね。更新履歴を書くシートがあったり、古いファイルはコピーしてリネームというローカルルールもあったりしますが、どんなときでも全員守っている保証はありません。人力の使い所を間違えているのです。5W1Hを諦める前提なら良いかもしれませんね。（超短期間のうちに仕様検討をする。長期的な仕様書のメンテナンスはしない。とか？）
第７回日曜数学会で発表してきました。
第７回日曜数学会で発表してきました。(もう１週間経ってしまいましたが、、、)
facebookのリンク
https://www.facebook.com/events/858311494303516/
発表スライド
www.slideshare.net
準備に使ったソース
振り返りよろしく、思ったことを並べていきます。
ニコ動での発表動画まだみてませんが、５分は多少超えたとは言え、概ね狙い通りのプレゼンが出来たと自画自賛しております。そして、とても楽しかったです。 ２６ページ目（比を修正した数が、連続する数の積で表せることを示したページ）に行くちょっと前に、 客席から感嘆の声が聞こえてきたあたりで、「この発表は成功！」と内心感動しておりました。 時間制限がキツイことはわかっていたので必然早口気味になったのですが、聴衆の皆さんついてきてくれたかなと。
keep
- 黒曜石（指輪型スライド送りリモコン）が活用できた。スライド操作を手早くできた。
- 発表しないスライドをそこそこ適切に選べた。（とおもう。）
- 質疑応答で飛ばしたスライドを使って回答できたので、結果発表に使えた。（ラッキー！）
- ネタ準備は十分できた。（長すぎたぐらい）
- 発表前に、パワーポイントのIMEをオフにすることを忘れなかった。（忘れると黒曜石のBLACKOUTボタンがIMEに拾われてハマる。しかも発表最中に。）
problem
- 発表時間少し５分超えた。（色々やむを得ないのでそれほど重大でないと認識）
- 黒曜石の操作が目立っていた様子。（ニコ生コメントで突っ込まれた。本当は目立つべきではない）
- 質疑応答時、プレゼン開始・終了の切り替えで、プロジェクターへの信号が一瞬止まる挙動が見えた。時間がもったいないので避けたい。
- 発表しないスライド・縮められるスライドがもしかしたらあったかもしれない。
try
- 黒曜石のBLACKOUTボタンを活用したプレゼン。（スライドではなく、発表者に集中してもらう。）
- プロジェクターへ接続した時は画面を複製するモードにする。（信号連続してくれるかも？）
その他雑感
この問題を考えていて同時に思ったことは、行列の並びを見せて、次の行列や一般項を求めるような問題はあまりみたことがなかったなということです。 普通の数列クイズはそれなりに見たことあるのですけど。数学の問題やパズルとしては手軽でないので単に避けられているだけかもしれませんね。
ついでに他の方の発表なのですが、話について来れた発表とそうでない発表がきっちり別れた感じでした。正直に言うと、解析系のネタはさっぱりでした。ソフトウェアエンジニアをやっていると、考える分野が離散数学寄りになったり、「コードが書けるか？動くか？」を重視する、、、というのは我ながら言い訳かもしれません。自分で勝手にやってる分には好きなことをやればよいのですが、やはり数学の主戦場は解析なのではないかと。式を自由に操れないとなぁと思った次第です。（数学ガールの「僕」が、趣味は式変形って言ってたのは、実に正道なのだなとか）
さてこの問題ですが、 @mattyuu123 さんが、一般解を提示しています。
@kazurof 一般解出せました！福原さんお墨付きです(^^) b=0のところだけでもご飯何杯かいけます(*^^*) 福原さん素敵な問題ありがとうございますm(__)m #日曜数学会 pic.twitter.com/5ltCJgiee1
— mattyuu (@mattyuu123) 2016年10月6日
追って、解説記事が書かれることでしょう。期待して待て！
（毎度毎度の〆ながら）やっぱりまた面白いネタを思いついたらどこかでなにかしら登壇したいなと思います。発表ネタ考えて準備するのは大変ですが、プレゼン発表面白いです。
第十六回 #渋谷java で、LT発表してきました。
第十六回 #渋谷java で、LT発表してきました。
発表内容は、「JUnit 5 M1 をやってみよう」です。最近出たJUnit 5 M1 を触って見ました系の内容です。Qiitaのスライドモードを使ってみました。
振り返りよろしく、思ったことを並べていきます。
急すぎた。というのが準備含めた全体的な感触でした。M1のリリースに気がついたのが７月８日。渋谷javaのLT枠が空いているのに気がついたのが大体当日の１週間前で、下書きを始めたのが、１８日。 他の個人的スケジュールを考えるとついうっかり限界に挑戦してしまったような感じでした。でも見送ったら２度目はないし、誰かがやらなきゃなとも思ったので勝手に思い込んでやってみた次第です。
内容は単に機能の差分を並べるだけでなく、最低限の価値を出せたかなと思います。Ruleのようなフィールドを使うような拡張はやめる方針でありますと。他にもネタはあるようですが、どうにも手が回らなかった。
あと、今回Qiitaのプレゼンモードを使いましたが、フォントサイズが大きくなりすぎて発表やりにくい感じでした。（つい焦ってスライド１枚飛ばしてしまったような）これなら普通にスライド書いたほうが良いなあと。あるいはフォントサイズ調整ぐらいはできても良い気がしますが。（スライド全体に渡るフォントサイズ調整として）
リポジトリを見ると、もうM2 が出ています。リリース間隔縮んでる感じですね。これからはじわじわバグ潰しと新機能（従前、Ruleでやっていた機能をExtendWithへ移植するとか？）の提供があるような気がします。 プロジェクトのアナウンスでは2016年の終わりまでにはGAをリリースしたいらしいので、今後はチラチラと見ていこうかなと。
でもやっぱり毎度ながら、また面白いネタを思いついたら登壇したいなと思います。発表ネタ考えて準備するのは大変ですが、プレゼン発表面白いです。
第十五回 #渋谷java で、LT発表してきました。
第十五回 #渋谷java で、LT発表してきました。
発表内容は、「nextProbablePrime() について」です。おそらく素数を取得するこのメソッドは、どこまで正しい素数を返すのかを調べたという発表です。
www.slideshare.net
今回の検証に使ったソースをgithubに上げています。興味のある方どうぞ。
振り返りよろしく、思ったことを並べていきます。
とりあえず、問題を立ててその原因を探って答えを出すというストーリーを粗々ながらでも立てることができたのは良かったと思いました。 ロジックを追ってもなかなか十分追いきれなくて、このままだと単に処理の流れを追うだけになっていたかもしれなかったです。けれども丁寧ではないながら、ゴールを立てて到達できたと勝手に自負しています。
もっと時間があれば、カーマイケル数と非自明な１の平方根の話と、計算量や失敗する確率の根拠まで丁寧に話せたかもしれません。そうすれば、エラトステネスの篩の話はまるっと捨てる事ができたかもしれません。リュカレーマーテストについても処理概要と目的と、このプレゼンの趣旨には直接関係ないことを言えたほうが良かったかもしれません。
未消化のところもあってリュカレーマーテストが何のためにやっているのかさっぱり読めませんでした。試しに適当な値を入れてリュカレーマーテストのメソッドを動かしたら、9とか25とかで、処理に長時間かかるようになることを見つけて、多分そこには何か見落としがあるのだろうけれど、何なのかわかりませんでした。
聴衆の反響としては、ハッシュタグ上の反響はそれなりにあった*1ので、それは良かったと捉えておきます。具体的に手を動かして出てきた具体的な結果はそれなりに印象持ってもらえるのかなと。内容完璧ではなくても、出さないことには何も無くなってしまうので。能力限界で出さないぐらいなら、能力限界で品質悪いほうがまだ良いと思っています。
前回の登壇からまるっと2年経ってますが、また面白いネタを思いついたら登壇したいなと思います。発表ネタ考えて準備するのは大変ですが、プレゼン発表面白いです。
