カルチャーに関してはリーン開発をプロセスとして根付かせた事が大きいということでした（自分もリーンスタートアップ等に関しては全然理解が及んでいない領域なので早く読まねば… この記事とかとりあえず見てる）。また、もともとクローズドな雰囲気だった開発体制をインナーソース（組織内におけるオープンソースの文化とベストプラクティスの実現、と聞いた）にすることにより、開発に参加しやすい・改善しやすい環境づくりに務めたそうです。

次に開発・テストに関しては、自動化とユニットテストがポイントでした。手動でのオペレーションの危険性について理解しているのはもちろんのこと、部分的な自動化を避け徹底的に自動化していることがすごいなと思いました。また不具合の数のモニタリング、指標設定も徹底されていてシステム化が進んでいるなあという印象を受けました。また結合テストではなくユニットテストを増やしていくことで、影響箇所を最小にしつつCIによるチェックを小さくしFBを早くする取り組みがなされていることが印象的でした。（CIによるFBで数十分かかっててNGだったらそりゃ記憶数十分戻さないといけないし、嫌ですからね）

最後にリリース・ライブサイトについては、デプロイメントのステージを細かく分け慎重に検証し最小の影響範囲で済むような仕組みが整備されていました（いきなり顧客に使ってもらって失敗だと最悪数十億人規模で影響が出るから、でしょうね）。またライブサイトでプロダクションの状況を常にモニタリングすることで、いち早くプロダクション環境での問題に対応する環境づくりがなされていました。

GitHubパート（後半）

次の3つを大事にしているとのことでした。

GitHub Flow
ChatOps
Continuous Delivery

GitHub FlowはGitHubさんでも愚直に運用されていますが、CIの数が50くらいあって驚きました。ここでも徹底的な自動チェックがされていることを感じました。そしてGit Flow的に開発環境も分けられていて（review-lab 、production/canary、productionと手元のメモにはある）、自動的にデプロイしたり、実際に本番で流れてくるようなデータを処理してみて問題がなければproductionに含まれるみたいなフローらしいです。すごい。

次にChatOpsに関しては、Slackでビルドやテストを回せる環境を整えているとのことでした。Hubotを使ってカスタマイズしたコマンドをガンガン使っているそうです。また担当者情報もHubotが返してくれるので、自明なことはbotが返すことによって人が返信する手間を排除しているんだろうなと思いました。

最後にContinuous Deliveryについては、開発効率を最大化するために現在はリリーストレインという仕組みを使ってProductionに反映しているそうです。これはPRを一つ一つデプロイして反映していると時間がかかりすぎてしまうため、いくつかをまとめてビルドして反映する仕組みだそうです。ボトムアップ的にこのアイディアが採用されたというのもオープンソース的なカルチャーが影響しているのでしょうか、業務改善が様々なところから出てくるのはとても良いなと思いました。

エンジニアはものづくりの夢を見るか - AWS Loft Tokyo 入館アプリの開発事例 -

結構エモ目な話だった記憶があります。個人的に重要だと思った点だけ箇条書きでピックアップ。

ソリューションアーキテクトという普段はAWSをどう使うかをやっているエンジニアがアプリケーションを作ることで、アプリケーションレイヤーの人視点も持てた
- 普段の活動から得られない視点が普段の業務にも役立った
- なぜその需要があるのかを発見できた
「技術的な負債があろうが、現在動いているソフトウェアはなにかしろの問題解決はしている」→「エンジニアならばクレームではなく、技術的な正確性を持って問題に対応していく」
きちんと開発する = 組織のルールに則ること AND 体制変更に耐えること、という気づき
- 個人で開発されたスクリプト、その人が退職したあとメンテされない問題
- 本番でしか正しく動かないアプリケーション、構成
ちゃんと開発する、時間が取れない問題との向き合い
- 🆖 一度に大きな変化をしない
- 🆗 なにか「きっかけ」を見つけ、小さな変化を続けていく
そのためにやったこととして
- 人の冗長化（1人でやると自分自身が単一障害点になる）
- 組織のルールに「準拠できている」チームのメンバーを巻き込んで、メンターになってもらう（そして要件と早く合致させる）
- 必ずやらなければいけないことと、その期限を明確化し、それをチームで分担してフォーカスする
- 小規模MVP(Minimum Viable Product)をまず作ってリリースし、評価と改善のサイクルを回す
- 長期安定性を見るためにか並ぶベータリリースをはさみ、可能な限りカナリアリリースとロールバックの仕組みを整える
- 開発以外のリソースを減らす（SaaSの活用）
- 自分のモチベーションの適切な保ち方を見つけ定期的に思い出す
技術的に便利だったもの
- AWS Amplify Console
- AWS Chalice

こんな感じでしたかね…。結構最後は気持ち！みたいなところもありつつも、どうすれば問題を解決できるのかに全力でフォーカスしロジカルな行動をとってちゃんとリリースできてるのがすごいと思いました。

あのイベントの裏側が知れる！？カンファレンス運営者LT

どういったイベントがあるのか、またどうイベントを運営していくのかについてLTを聞きました。日程かぶってて行けないやつも結構あったけど…。全部について書いているとスペースが足りないので、ここで発表があった各種イベントの開催日情報だけまとめます。

知っているイベントも知らないイベントもあったのですが、明日の開発カンファレンスとXP祭りはそもそも知らなかったです。どちらも自分の興味とかぶりそうなので、気になっています。

あと個人的に印象に残っているのがXP祭りの運営方針です。長年開催されていることもあり、スタッフが巡り巡って基調講演の発表者として登壇するなどの循環が特に興味深かったのと、まずは最低コストで運営する（いわゆるMVPがしっかりされているということだと思います）ことの話が心に残りました。また、PHPConのモデルコースっていうのも面白かったです。

自分自身もカンファレンススタッフとしてぼんやり参加していることもあるので、こういうところで学んだことを自分が関わるところへプラスになる形で取り入れてみたいなと思いました。

まとめ

久々に大きめのカンファレンスで参考になりそうな話をたくさん聞けたので良かったです。（もっといえばこういう場所で発表できるような成果をあげて、発表しなければ… とは常に思っていますが）

このあと参加予定だったイベントは例のウィルスの問題で潰れてしまったので、このカンファレンスで得た熱い想いを受けて活動していけたらと思います。AWSの受付アプリで話があったAWSのサービスはちょっと覗いとこう…。

2020-02-09

熱意あるPython使いの発表会に参加した

Python エンジニアリング勉強会

今更ですが書きます。

勉強会URL

熱意あるPython使いの発表会 - connpass

使ったツールの話

nkgrnkgr/put-your-hands-up： Where feedback to the speakers gather.

このツールを使って少しクローズドにトーク内容に対してコメントしたり、意見交換したりしていました。コンセプト等はいい感じなのですが、微妙に使い勝手悪いなーと思ったポイントもいくつ買ったのでissue立てとかないとなと言う気持ちです。。。

会の雰囲気とか

発表について

参加者の都合や人の集まりが悪く、発表タイトルは3本だけでしたが、内容としては充実していました。何しろ発表者がそのあたりにいるので、休憩時間に話を聞いてみたり、深い話をしたりということが簡単にできたのはとても素晴らしかったかなと思います。ただスタッフ登録して場所を間違えて遅刻してしまったので大変申し訳なかったです（流石に申し訳なさすぎたので後でカンパとして500円払いました）

Pythonを使った子供向けの実践学習の話では現場のリアルな声が聞けてとても面白かったです。ラズパイなどハードウェアと組み合わせることで、物理的にも色々できるのは魅力的（子どもたちにとってわかりやすい世界）なのかなと思いました。あと意外と頑張って教えればなんとかなるものだなと思いました。子どもたちの頭の柔らかさや発想の柔軟さは（前提条件を考慮してないので生まれるという噂もありますが）参考にしつつ、これから先デジタルネイティブな方と仕事するのが今から楽しみだったりします。

PythonでカードトレーディングゲームをWebで実現する話では、ゲームルールの複雑さのため、大変な印象しかありませんでしたが、山札があって、引けて… みたいなモデルはどんなゲームでも必要な項目なので、そこを胸中化しつつ、プラグイン的にあとから独自のゲームたちを実装していくのかなとか考えていました。（ちなみに趣味で創作されたカードゲームは結構あって、もちろん頒布数が少ないので目にする機会も少ないのですが、対戦する機会がそもそも、という課題があるのでこれでラクーに公開できれば創作カードゲームの広がる速度が上がるのかなと思いました）

最後にLambda煮上げるのが大変だった話を聞いていましたが、うーん、これ本当にわかりますね…。という気持ち。意外とMacで作ってZipであげて、みたいなことをやると失敗するの皆通る道なんですかね？ Dockerを使って解決する方法がてがるそうですが、まあ自分ならレンタルサーバーとか借りてなんとかしちゃうかなーって気がします。

You tubeの視聴

採択されたトークで面白いものを見てみましょう、ということでいくつかピックアップされたものを見ていました。面白かったのは Python による日本語自然言語処理〜系列ラベリングによる実世界テキスト分析〜と Ending Keynote - PyCon SG 2019 - YouTube ですかね。いづれも時間の関係上、途中までしか見れなかったのですが…

まあでもここで気がついたことがあって、PyCon JPで見てないトークってまだまだあるなと思いました。発表資料を流し見しただけとか、動画も流し見しただけとか結構学べるところはあるなと思いつつも手を出せていなかったんと気が付きました。また海外のPyConについても動画で死傷することができるということに気がついていなかったので、海外の動向を知ったりするために少しづつ見てみようかなと思います。

まとめ

個人的には人数はたしかに集まらなかったかもしれなかったけど、とても楽しいイベントだったと思っています。これはPyCon JP 2019のRejectConであり、何やら色々インターネットで意見されているのも見ましたが、参加してわかったということは確かにためになったし、面白かったし、運営自体も健全だったということです。純粋にPythonが好きな人が集まって、交流する良い場でした。

こういう小さくても特定のトピックについて発表し、交流できる濃厚な場所はRejectConでなくても欲しいですね。東京で年1回開かれる大きなイベントだけではなく小さくても様々な場所で開かれて、そこで楽しむ新しいことを発見するつながる、というのも良いことだと思っています。

2020-02-08

OSS Gate東京ワークショップ2020-01-25に参加した

勉強会エンジニアリング

そろそろOSS開発をやってみたいなーと思うことが増えたので、参加してみました。

なお個人的には雑な活動（PrismDBとか）しか経験がなく、全く知らない人に対してGitHub上で呼びかけてみようみたいな活動はした経験がないのでビギナーで参加しました。

イベントページ

OSS Gate東京ワークショップ2020-01-25 - OSS Gate | Doorkeeper

あんまりDoorkeeperで参加することがないので、戸惑いました（えっ

所感

最初にアイスブレイクをして、その後このイベントの目的やコントリビュートしたいOSSを決める、などの作業がありました。イベントの目的が非常に明確で何を実現したいか、自分たちはターゲットのどこにいるのか、OSS開発のメリットとかコミュニティーの世界はどうなのか… などを説明いただいて丁寧な印象でした。また会場にはメンターがいて、わからないことを聞いたり、現状の説明をする中でタスクが整理されていくことを感じ、非常に助かりました。このあたりは一人で開発していたら気づかなかっただろうポイントなどもあり、こういうイベントが有って本当に良かったと思いました。

コントリビュートしたいOSSは個人的に最初から考えていたので（Flake8のプラグイン）、それを僕は黙々と読んでみて、まずはissueとして上げて見る活動をしました。コントリビュートしたいものを考えるところからやる人はチュートリアルをやってみて、引っかかったところとか怪しいところとか暗黙的に知ってなければこれ無理じゃない？ってところとかを上げていく活動からしていました。

ところでGitHubのIssueですが、英語で書かなければいけません。最近であればContribute.md？だったかでテンプレートとして書かれているものもありますが、私が触れていたものは少し古いものだったのでそういったたぐいのものがありませんでした。GitHubを探してそれっぽいDescriptionとかを参考に英語を書き、書いたものをレビューしてもらってIssueを上げました。それにしても英語の表現はいまいちわからないので、そこは障壁を感じます。普段からもっと英語を使わないとね。

Issueに関して言うと普段やり取りをしていない人にどう伝えるべきなのか、ということをたいへん考えさせられました。普段の開発ではチームが集まって開発できるので、これなんのこと？となっても会話の中で解決できるのですが、GitHubのようなオープンなインターネットで非同期なコミュニケーションが求められる場所において、相手に伝わるように書くということを大変意識させられました。タイトルと短いコメントだけのIssueもGitHubのいろんなリポジトリで見るのですが、これがなぜ必要なのか、期待は何なのか、といったことが正確に書かれていないとOSS開発者を惑わせヒアリングなどに時間を使わなければいけない状況に… なんてのも想像できました。開発者とて一人間、画面の向こう側には人間がいるということを再認識し、開発者にとって優しい書き方を自分はやっていきたいです。

お昼はピザを取って普段の仕事についての話などに花を咲かせました。普段はマネージャーとかでコードを書く機会が少なくなってしまった方や、他の言語を勉強し始めたのでそこでコミットできることを探している方など、向上心もありつつ貢献したいという気持ちが強い方が多いのかなという印象を受けました（そうでなかったらこういうイベントには来ないという話もありますが）

昼からはIssueをまだ上げていない人はIssueを書く、Issueを書いた人はパッチを上げてみる、という形で進んでいき、私はパッチを書いていました。といっても実は溜まっているPRの中に問題を解決できるパッチがあったので、最終的にはこれをマージして！この問題が直ります。というコメントを残すだけになりました。ここは最後までやり遂げたかったなーという気持ちがあります。

最後は振り返りをし、アンケートを書いて全員で読みました。人によって感じていたこと、学べたことが違っているところに面白さを感じました。このアンケートを全員で振り返るアクティビティが新鮮で、OSSコミュニティの文化！というのを肌で感じました。

資料や過去のアンケートも全てGitHubで公開されていて、コミュニティ自らがOSSを体現しているのもGoodでした。

そんなこんなで一日が終了しました。すごく濃密な時間で勉強になりました。解散が17時だったのですが、もう頭の中がヘトヘトで仕事をしてるとき位疲れました。

まとめ

非常に良いイベントなので、興味がある方はぜひ参加してみてください。とはいえ普段からライブラリやフレームワークを見たり使ったりしていないと難しい部分はあるかもしれませんが・・・。

またメンターが常に足りていないという問題があるらしく、OSSのコントリビュート経験がある方を募集しているとのことです。よかったらこういった場所でOSS開発者として一歩目を踏み出したい方向けに支援してみませんか？

私はタイミングが合うかわかりませんが、もう少し自分自身で色々活動してみて、メンターとして戻ってこれる時期があればいいなと思っています。（まずPRがマージされる、みたいな経験を先にクリアしたい）