はじめに
頑張れば、何かがあるって、信じてる。nikkieです。
8/12の「みんなのPython勉強会」の裏側と、そこで知ったある本の感想をアウトプットします。
目次
勉強会の概要
「みんなのPython勉強会」では、Pythonを中心としてプログラミングを仕事、研究、趣味など様々なシーンに生かす方法を一緒に学びます。
今回の主なテーマはマーケティングです。Pythonが得意とするデータ分析のニーズはビジネスやマーケティング分野で高まりを見せています。
勉強会の様子
Togetter
配信の裏側：痛恨のZoom設定ミス！😫
#stapy Zoomの参加人数上限の問題は解消しました。
— nikkie 技書博のPython argparse本 boothにて頒布中 (@ftnext) 2020年8月12日
お申し込みの方でZoomで参加したい方はぜひZoomにお越しください！
今回はお申し込みの方にご迷惑おかけしてしまい、申し訳ありません https://t.co/nFHpylGJ1l
これまでのオンライン開催では、スタッフと登壇者がZoom Meetingに集まり、参加者の方はYouTube Liveで配信を見ていました。
今回は、参加者もZoom Meetingに集まる趣向を試しました。
始まるまでお品書きスライドを自動プレゼンしながら、参加者が増えていくのを見てワクワクしていました1。
100人に届く直前で本編がスタートしたのですが、直後に100人上限が設定されていることが判明😱
アーカイブ用にYouTube Live配信もあったので、そちらを案内し、100人しか参加できない状態は回避しました。
勉強会中に設定が直り、途中からは再度Zoom参加を案内しています。
Zoomの参加人数の設定は怖いですね。
懇親会では「事前リハーサルで100人入って確認できないですもんね」という話になりました。
毎回振り返りしているので、そのときにスタッフ全員で対策を考えていきます。
個人的には、「Zoomの設定がエクスポートできればいいのに」と思います。
OSCなどZoomを使ったカンファレンスではノウハウの1つとして設定値が共有されるようになりました。
例：新しいZoomミーティングの設定について紹介します - 宮原徹の日々雑感
これはありがたいことですが、退屈な手動操作が大嫌いな私は、設定をコード化したいと思わずにいられません。
人がやるのではなくコードにやらせようとすると、ブラウザ操作自動化かなあ？（設定をいじれるAPIがあるのかな？）
落ち着いたときの素振り材料の1つですね。
閑話休題：ぬいぐるみ🤗
技術者と企画力についてお話しいただいた吉政さんが、パイちゃんとソンくんのぬいぐるみ背景を公開してくださいました！
めっちゃかわいい！😍😍😍
これがあればパツパツなmtgデーも何のそのですね（シリアルなmtg中でも、顔が緩んでしまうのが悩み）
感想：『その仕事、全部やめてみよう』が面白い🤩
冒頭で阿久津さんが紹介していた1冊。
小野さんは過去の登壇者2でもあるそうです。
小野さんからたくさん学んだ！#stapy pic.twitter.com/OwIFwDKJvN
— ◥◣◥◣あべんべん◢◤◢◤ (@abenben) 2020年8月12日
目次の中の「俺がやったほうが早い病」の治し方に惹かれて読み始めました3。
エンジニアの先輩の言葉として、ハッとさせられるところがいくつもありました。
特に興味深かったポイント
- 阿久津さんが紹介していた、「谷」を埋めるな、「山」を作れ！
- チームで働くについて示唆があった、職場は「猛獣園」である
「谷」を埋めるな、「山」を作れ!
- 谷（＝弱点）は最小限カバー、山（＝強み）を尖らせる
- 周りの製品を見て谷を埋めようとすると、仕事が増える（99%の仕事は谷を埋めるもの）
例えば文書のレビューは、谷を埋めようとすると、ちょっとした単語選びや敬語などなど、めちゃくちゃ時間がかかるものです。
山があって、谷が最小限カバーされていれば、レビューはパスでいいんだと気づきました。
なぜ山を作るかというと、ユーザを喜ばせる仕事をしたいから。
時間は有限ですし、ユーザを喜ばせるのに直結する仕事が増やせるのは、やりがいがあると思います。
ユーザを喜ばせるのに直結しない仕事はまずやめることを考えてみようと思います。
脱線ですが、「ユーザを喜ばせる」を読んだ後、「ユーザを喜ばせるプロダクトって実はあまりないかも」と気づきました。
読んだ翌日、職場でチームランチがあって、menuでちょっといいランチを取り寄せたのですが、ぶかぶか容器で運んだらそうなるよねという「ウーバーイーツ系の洗礼」を浴びました。
見た目がひどいことになり、全然ちょっといいランチ感はなかった😭ので、しばらくウーバーイーツ系を使うことはないと思います。
店舗は無料で導入できるそうですが、持ち運ぶ部分は伸びしろ（工夫の余地）があるなと思いました。
ここがクリアできれば、ユーザは喜び、広く受け入れられそうです（コンビニの丼もの弁当の容器のノウハウとか使えそうじゃないですか？）
職場は「猛獣園」である
- とがった部分（山）が異なるメンバーを重ね合わせたチーム→猛獣圏
- エンジニア風林火山（とがりかたの4類系）
- キレるのは高みを目指しているから
「キレる」についての考察は興味深かったです。
「高みを目指しているから」、高い理想と目の前の現実にギャップを感じているからキレる。
実は私もよくキレていて（例えば、PyCon JPスタッフ活動で、運用でカバーしようとする提案が出たときはキレてます4）、キレることに対して「よくない」と思っていたのですが、この本で捉え方が少し変わりました。
ただキレて取り繕わなかった結果、同席した方に不快な思いをさせては元も子もないので、マイルドな言い方など、追求の余地があります。
運用でカバーや複雑なもの以外には、人が生み出したわかりにくいもの、性能が悪いものにもキレます5。
例えば、以下の2つの製品にはキレました。
- dropbox：注釈機能の実装がひどすぎる
- 注釈が増えてくるともう本当にダメです
- 何百のレビューが付いたdezero3公開レビューでは、ブラウザがもっっっっっっさりして、レビューになりませんでした😡
- Adobe Document Cloud：共有設定がわかりにくい
終わりに
8月のstapyについて、ミスの共有と、知った本についての感想を書きました。
途中で抜けてライブで見られていない松本さんパートは後ほど見られたらと思っています。
9月は11日に開催です。
みんなのPython勉強会#61 - connpass
内容はまだ禁則事項ですが、よろしければお越しください！（なんだろう、本が積まれていますね）
懇親会のLTもお待ちしています！！
-
『サマー・ウォーズ』を思い出し、夏を感じていました↩
-
私がまだstapyを知らない時代ですね。歴史を感じます↩
-
PyCon JPのスタッフ業で忙the殺されている現状はこれがあると思っています。この話はまた別の機会に↩
-
繰り返しますが、私は退屈な手動操作が大嫌いです。また、複雑な手順で運用でカバーするのは本当に嫌です。過去に複雑な手順にしたために、誰でもできる作業ではなくなる（属人化する）というツライ経験もしてきました。複雑は可能な限り避けて単純にを信奉しています（これも谷を埋めようとして複雑にするのではなく、単純に考えて山を尖らせると通じるかも）↩
-
書いていて思ったのですが、エンジニア3大美徳の怠惰と短気が当てはまりそうですね↩
