Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

チームビルディングのためにやったこと、できていないこと

management non-tech 仕事

これ↓読んで、自分の経験をまとめようと思ったのでメモ。

www.yutorism.jp

チームビルディング、ないし組織・オフィスの改善のためにやってきたことはけっこうある。反面、できていないこともかなりある。

やったこと、継続していること

社内技術勉強会

上海拠点設立時に董事長と話してやったのがこれ。せっかくCS専攻の人を集めたのだし、ポテンシャルある人ばかりなので、彼らが互いに刺激を与え合える機会を作ろうという狙いだった。当時は20名弱だったので、全員にスライドを使って企画意図を説明したのを覚えている。

最初は発表者が2,3名に偏ったり、開催時間が固まらなかったり（最初は朝開催を目指したが、結果的には夕方開催に落ち着いた）、発表が数週間連続でなかったりという問題も多かった。しかし結局は、私が異動でいなかった時期（1年間）も含めて6年間続けられている。継続するのが一番難しいので、これは普通に素晴らしいことだと思っている。

継続のコツは、やはりイベント自体を楽しいものだと思ってもらうこと、他の人を巻き込んで協力を得ることだと思う。魅力を理解してくれた数名が引き継いでくれたからこそ私が不在でもイベントが回ったし、今は自分が聞き込みや勧誘をしなくても社内交流促進の専門家が代わりに調べてくださっている。ので、最近の私はたまに発表するだけという立場。たぶん私が立ち上げ人ということを、新人は認識していないはず。

問題共有イベント

最近は拠点規模が大きくなって、拠点全体で何が起こっているのかを把握するのが難しくなってきた。また異なるチームで似たような問題をバラバラに解いているような状況も散見されるようになってきた。問題解決こそが仕事なのにこの状況は好ましくないだろうということで、従来人事評価時にやってきた成果発表とは別に、プロセスと問題とを拠点内で共有するイベントを立ち上げた。怒らないことを強調しないだけで、前述のイベントとほとんど同じ。

部署の壁を超えて数百人巻き込むので、コストが大きいことを個人的には気にしている。ので毎回アンケートで発表者と聴衆の両方から実際役に立ったのかフィードバックを得ているが、いまのところコストを成果が上回っている認識。今後も成果の評価と改善検討を続けていくつもり。

AMAイベント

これについては自分の上長が事業部で実践していたものをパクって上海に持っていっただけ。主に新人が持っているであろう疑問や、いわゆるhard questionを部長らが匿名（実名付記も可）で集めて一括で答える。文書化されてないルールや、歴史的経緯でそうなっているもの、（中国の）普通の会社でやっているのにやっていないこと（あるいはその逆）とかに関する質問が色々集まる。推測や疑問を検証できる機会を公式に作るだけで、教育やモチベートの切欠を作ることができる。問題回収と整理は非同期でできるので、複数人を一同に集めることもなく開催コストもそんなに高くない。

最初はQuestion Gathering Eventと呼んでいたが、最近AMAという言葉が身近で流行したので、今はAMAあるいはAsk Us Anythingと呼んでいる。

技術交流用WeChatグループ

WeChatでグループを作り、社員と元社員とでFOSSについて話す場としている。はてブと同じノリでURLをポンポン投稿する感じ。任意参加なので尖った技術者が集まりやすい。RustとかTaigaとかConduitとかはここでキャッチしている情報もある。新人には、興味を感じる分野を探す一助になっていればいいなと思っている。

MBO-S

これに関しては普通に目標管理の教科書を参考にやっている。変わったこともたいしてやってないはず。上長としては部の短期・中期目標（どのProblem Spaceにフォーカスするか）を明確に提示し、それぞれに固有名詞を付ける（Project FooBarとか）ことで、メンバー間交流が促進され挑戦・工夫がしやすい状態になるよう心がけている。自分のMBO-Sフォーマットは社内SNSで公開し、壁に貼って誰でも閲覧できるようにしている。

1on1

これも初めて6年になる。運用上工夫しているのは3点：

  1. 直接の部下（課長？）とは週次、間接的な部下とは月次で実施
  2. 時間を自由に使って良いことを前提として、聞きたいことリストをこちらから提示（情熱的に働けているか、やりたいことの妨げになっているのは何か、上長に期待しているのは何か、直近の全社集会について質問はあるか等）
  3. 1on1を受けてこちらがやることを、最後の時間でコミット

本当は2みたいな質問の提示は誘導に繋がるのでやらないほうが良いと思っているが、何も持ってこない人が散見されるので補助線として用意している。

参考にしている本は複数あるが、最近読んだのはフィードバック入門、マネジャーの最も大切な仕事、HIGH OUTPUT MANAGEMENTあたり。特にフィードバック入門のTeaching + Coaching = Feedbackという図式はわかりやすく応用がきく気がしている。

できていないこと、継続できなかったこと

ライトニングトークイベント

前述の社内勉強会の一環として、30分ずっとLTするようなイベントを考えたことがある。結果、3〜5分という短い時間で話し切ることに慣れさせることができずに終わってしまった。会社を一歩出ればLTの機会がたくさんある東京と違って、勉強会が少ない上海ならではの問題かもしれない。

輪読会、読書会

これが定着しない理由は明確で、私自身に成功体験がないから。どこかでちゃんと運営された読書会に参加して、感覚を身に着けたい。

今は本を一緒に読む代わりに、おすすめの記事や本を社内SNS等で発信している。今のところはCI/CDやMSAについて語る機会が多いので以下だが、随時アップデートしている。

休祝日のチームビルディングイベント

これは日本で開発合宿経験済みではあるのだが、自分が子持ちということやその他の事情から積極的にやる予定がない。上海の部下はともかく、日本の部下とはかなりやりにくいという事情もある。やる気と関心がある部下に、提案から丸投げている状態。

社外の人を巻き込んだ勉強会

これは1回だけやったことがあるが、会場と参加者の定期確保に失敗した。そもそも上海で定期的に勉強会を開催しているのがWiredcraftくらいなものなので、潜在市場はありそう。深センほどではないとしても、上海にはGoogleもMicrosoftもeBayもチームラボもサイボウズも色々居るはずなので、ちゃんとツテを作って運用したい。

とりあえず現地日本人コミュニティに顔を出しつつ、上海のMeetup.comで定期的に参加できる勉強会を探していくつもり。

Maven3電子書籍の利用され具合（2017年）

java Maven GitBook

ほそぼそと続けているMaven3の入門書「Maven3のはじめかた」ですが、最近はprh入れたり、リポジトリの適当すぎた説明を修正したりといった微修正を行っています。

www.gitbook.com

で、意外にも年間2万人のユニークユーザがついたようです。以下が2016年12月〜2017年12月のデータです。

f:id:eller:20171230222121p:plain

どこからそんなユーザが流入したのか気になるところですが、KDDI ChatWork、Teratail、Yahoo!の社内サイトと思しきものがリファラにありました。どうやらMaven用語の説明に活用されたようです。今は正直プラグイン実装手法の説明が厚く用語解説が貧弱なので、用語解説系をもうちょっと強化したほうが良さそう。

検索サイトはGoogle, Yahoo, Bing, 楽天の順。インドやベトナム、ロシアの検索サイトと思われるものもありました。現地で働いている日本人が使っているのでしょうか。今日Google Analyticsを入れたので、次回は検索キーワードあたりも調べられるでしょう。

国別に見ると日本、米国、シンガポール、オランダ、中国の順です。米国とシンガポールには日本人技術者多い印象でしたが、オランダが入ってくるとは意外でした。ただユニークユーザ数は低いのでヘビーユーザがいらっしゃるのかもしれません。

f:id:eller:20180101222920p:plain

この本は今後も継続してメンテしていきます。コードは全てGitHubで公開されていますので、内容へのフィードバックやPRもお待ちしています。

Mavenプロジェクト用Travis CI設定（2017年末）

Maven travis-ci

今年はビルド周りで自分の常識がいろいろ変わった年だったので、既存の知見もあわせてまとめます。

Mavenのバージョンを固定する

Travis CIは不定期にビルド用仮想マシンを更新しますが、そのタイミングでの最新のMavenを仮想マシンに入れるようです。このブログ投稿時だと3.5.2が入っています。

もっと新しいバージョンを使う、あるいはMavenのバージョンを固定するには、Maven Wrapperを使うと良いでしょう。Travis CIはプロジェクトルートディレクトリにmvnwスクリプトがある場合はそれを優先的に使います。

mvnコマンド指定時の注意点

script や install、deploy などのフェーズで mvn コマンドを明示的に実行する場合、 -B オプションを忘れないようにします。このオプションによってMavenはインタラクティブなログを抑制するようになり、ログサイズが激減します。Travis CIはログサイズに上限があるため、うっかり忘れるとビルドが不安定になります。

グローバルにコマンドラインパラメータを指定する方法

グローバルにコマンドラインパラメータを指定する場合、それがローカルでの実行時にも必要となるパラメータならば、Maven 3.3から導入された .mvn/maven.config あるいは .mvn/jvm.config を使うことも可能です。ただし現状これらのファイルはコメントを書けないので、チームで使用する場合はどこかで説明が必要でしょう。

SonarCloudによるコード解析

FOSSならSonarCloudを使えば無料で解析できます。Travis CIには専用Addonがあって、MavenでSonarQube専用プロパティをややこしく設定しなくても、pom.xmlをよしなに解析してプロジェクトホームやIssueトラッカのURLを見つけてくれます。

なおコード解析をPRにも働かせる場合は、PRのもととなるブランチも同じリポジトリに存在する必要があります。これはトークンの復号化に必要なためです。

Travis CIによるSonatype Nexusへのデプロイ

これを取り入れるかどうかは意見が別れるところだと思います。というのもこれをやるには、暗号化済みとは言えGPG署名に必要なファイルやSonatype Nexusのパスワードをリポジトリにコミットする必要があるのです。

私の場合、個人プロダクトでは使わずに Maven Release Pluginを使うようにしています。ただしSpotBugsのような共同リポジトリの場合、リリース難度を下げ属人性をなくすために使用しています。

作業内容は単純に、GPG public keyring, GPG secret keyring そしてGPG passphaseとSonatype Nexusアカウント情報を含んだ settings.xmlを暗号化してリポジトリにコミットし、それをデプロイ時に使うだけです。以下のPRが参考になると思います。

GPGのkeyringは以下のようにコマンドで出力できます。

$ gpg --export $KEY_ID > .travis/pubring.gpg      
$ gpg --export-secret-key $KEY_ID > .travis/secring.gpg

またリリースの属人性をなくすため、リリース手順書も合わせてコミットしておくと良いでしょう。settings.xmlのテンプレートもあると、引継や暗号化済みファイルの更新に役立ちます。

Contributorに対するリマインド

GitHubはPRやIssueにテンプレートを作成することができます。またContributing Guidelineを作成することもできます。従来はこれがユーザに対するほぼ唯一のIssue/PR作成時のリマインダでした。

ただチェックボックスをテンプレートに入れたとしても、すべてのContributorがこれを使ってくれるわけではありません。ので、個人的には以下のブログで紹介されているProbotに期待しています。

SpotBugs 3.1.0 RC6の利用とフィードバックのお願い

SpotBugs FindBugs java

先日SpotBugsの最新版となる3.1.0 RC6が出ました。大きな問題が無ければ、これが最後のRC版となる予定です。

SpotBugs開発において、私は新マニュアルサイト整備、CHANGELOG整備、Ant廃止、Gradleスクリプト整備、Travis CI整備、Bot管理、パフォーマンス改善、JUnit用test-harness作成、Gradleプラグインの統合テスト作成、などなど色々やらせてもらいました。昨年FindBugsがforkされてからの10ヶ月間で数多くの変更と修正を入れてきましたが、どうにかJava9リリースのタイミングに合わせる形でSpotBugsの安定版をリリースできそうです。
助けていただいた各位、特にドキュメントの日本語訳にコントリビュートしてくださっているKannoさんと、SpotBugsチームの要請に応えてv6.1を出してくださったApache BCELメンテナ各位に御礼申し上げます。

このバージョンにはMANIFEST.MFに記載されたClass-Pathが間違っているという既知の問題がありますが、MavenやGradle、AntなどのビルドツールあるいはEclipseによってFindBugs/SpotBugsを使っている場合には問題になりません。ぜひ日頃の趣味開発ないし業務開発で使っていただいて、イシュートラッカーにフィードバックをお願いします。
なおjarコマンドあるいはSpotBugsが提供するスクリプトを利用されている方は、こちらに記載のMANIFEST.MFでjarファイル内のものを置き換えてください。

なお私は今後も個人的にSpotBugs開発に携わっていく予定です。BCEL自体がスレッドアンセーフらしく一筋縄ではいかないようですが、マルチスレッド化を進めていきたいと考えています。今後ともよろしくお願いします。

FindBugsの後継としてのSpotBugsの紹介

java FindBugs SpotBugs

このエントリは「Announcing SpotBugs as FindBugs successor」の意訳です。一部、明らかなURLの誤りを修正し、可読性のため強調を施しています。

皆さんこんにちは、

このメールはこのメーリングリストにおける私の最後の投稿であり、また昨年のこちらの投稿の続きです。
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html

TL;DR: FindBugsプロジェクトはプロジェクトリードが管理者権限を移管しないままプロジェクトを離れ、また1年以上応答がなくなったため停止しました。SpotBugsプロジェクトがその後継であり、バージョン3.1.0 RC5を既にリリースしています。ASM6の安定バージョンがリリースされしだい、SpotBugsの3.1.0 RC6そして3.1.0安定バージョンがリリースされる予定です*1。

私が前述のメールを書いてから数名の有志がプロジェクトに参加して、私たちがプロジェクトが生き残るチャンスをものにできるよう助けてくれました。FindBugsという名称は商標であることから他の名称を使う必要が生じたため、新しいプロジェクトはSpotBugsと名付けられました。コードも新しいリポジトリに移され、ホームページ，メーリングリスト，バグトラッカーなどもGitHub上に用意されました。

私たちはASM 6のリリースを待ってSpotBugsの3.1.0 RC6と3.1.0 finalバージョンをリリースします、これは今月中に実現する見込みです。

SpotBugs 3.1.0 RC6がリリースされたら（このバージョンは最後のRC版になるでしょう）、私たちはコマンドライン，Antタスク，Mavenプラグイン，Gradleプラグイン，Eclipseプラグインそして新しいマニュアルを提供します。

FindBugs 3.0.1からの変更点はこちらに一覧化されています：
https://github.com/spotbugs/spotbugs/releases

注目すべき変更点は以下のとおりです（私が何かを忘れていたらすみません）：

  • リリースされたばかりのJava 9で動作します
  • 実行にはJava 8かそれより新しいJavaが必要です
  • Eclipseプラグイン，MavenプラグインそしてGradleプラグインのIDが変わりました*2
  • BCEL 6.1とASM 6を使用しています
  • GradleプラグインはGradle 4かそれより新しいバージョンで動作します
  • EclipseプラグインはEclipse 4.6*3かそれより新しいバージョンで動作します
  • プロジェクトのビルドにはGradleを使っています
  • 新しいマニュアルはreadthedocsでホストされています
  • 新しいプラグイン開発者向けテスト機構を備えています
  • Travis CIを使ったプルリクエストの検証を行います
  • その他コミュニティによる多数のバグ修正と貢献が含まれます

我々はすべてのFindBugsユーザが大きな問題なくSpotBugsを使えるよう望んでいます。マニュアルのマイグレーションガイドを見てください。我々はまた皆さんがテストやバグ報告や貢献を通じてSpotBugsプロジェクトを支援してくれることを期待しています。実際のところ、コミュニティの助けがなければ開発を続けることはできません。

もちろん上述のメーリングリストやイシュートラッカーの購読も忘れないでください。

私*4はまたSpotBugsを助けてくれたすべての人々に感謝の言葉を伝えたいです。GitHubの貢献者一覧を見てください。

特にJuan Martín Sotuyo DoderoとKengo TODA*5。彼ら二人がいなければ今日のSpotBugsプロジェクトは存在しなかったでしょう。二人ともありがとう！

これがこのメーリングリストでの最後の言葉です：私はこのようなことが起こるとは想像していなかったし、このようなことを言うことは非常に悲しいのですが……さようならFindBugs！あなたは10年間に渡り、何百万人もの開発者を助けてくれました。Bill、David、こんなに素晴らしいツールをありがとう。こんなアナウンスをしてしまって申し訳ないけど、ショーは続かなければならないんだ。

はじめまして、SpotBugs!

*1:訳注：3.1.0 RC6は既にリリースされています

*2:訳注：原文には記載がないがGradleプラグインもIDが変わっている

*3:訳注：Eclipse Neonのこと

*4:訳注：投稿者Andrey Loskutov氏のこと

*5:訳注：訳者のこと

javadoc.ioのクローンをreactorで実装した

Docker reactor checker-framework selenide java spring

また技術キャッチアップ用のプロジェクト作りました。今回使いたかったのは以下の4つ:

  • spring-boot v2.0（リリース前）
  • spring-webflux v5.0（リリース前）
  • selenide v4.5
  • checker framework v2.2

Springは5.0リリース前にマイルストーン版を使って感覚を見たかったため、特にreactorとRxJavaの違いを確認したかったため。 selenideはユースケースを見たことが無かったのでなんの役に立つのか肌感覚を持つため。 checker frameworkは公式ドキュメントに色々不明点がある*1ので、（今までやってきたライブラリやCLIツールではなく）自走するウェブアプリで色々確かめたかったためです。

以下所感をまとめておきます。

reactorによるウェブアプリ実装について

vert.xでも感じたことですが、reactive-streamsを使ってのウェブアプリ実装は十分に可能なものの、どの程度ペイするのかよく分からないというのが実情です。 外部サーバとのI/Oが処理のほとんどとなりやすいウェブアプリにおいて非同期I/Oを短く簡潔に扱えるというのは利点ですが、リアクティブに処理を書く必要性・Backpressureの利点をきちんと享受したいケースがどの程度あるかというと疑問という感じでしょうか。 これについてはそれなりの負荷がかかるサービスで比較検証する必要がありそうです。ab等を使った負荷検証をしてみます。

また静的解析ツールの支援を受けられないのはなかなかつらいなと思いました。 subscribe()時に正常系のconsumerだけ設定したためにエラーに気づけなかったケースとか、Mono.create()とMono.from()の違いを知らずonNext signalを掴み損ねたケースとか、習熟すればすぐに見つけられるがそうじゃないとかなり厳しい「書き方の問題」が多数ありました。年月が解決する問題ではありますが、現時点では業務用途はだいぶきつい印象です。

selenideでできることはコード短縮だけでないという話

Selenideを使ってみて「あれこれって大してコード量減らないのでは……？」と思ったのでつぶやいた結果、公式アカウントに突っ込まれました。

ブラウザのレンダリングを待つようなコードをいちいち埋めないでいいというのは、確かに大きな利点です。特にSeleniumを使ったテストの経験が浅い開発者は、気軽に Thread.sleep(long) してしまいテストを遅くする傾向にあります。コードレビューで指摘し育てるのも手ですが、Selenideのようなソリューションで統一的に解決してしまうのは手でしょう。

ただリダイレクト周りの検証とか、いまいち書き方がわからずWebDriverを直接叩くケースはまだまだありそうな感じでした。これだけ知っていればSeleniumについて気にしないで良い、というモノでは無さそうです。

checker framework

ちょっとまだfalse-positiveや価値の低い解析結果が多い印象です。Java標準APIはデータベースが整ってきているようですが、ライブラリ側（今回で言えばreactor含むSpring Framework）のデータベースが無いため、Nullableを許容するAPIでも「ここはNonnullだから！null渡さないで！」とコンパイルエラーになることが多いです。結局SuppressWarningをつけて回避しています。

彼らが配布するQualifierの認知度が上がり利用されるようにならないと、まだ積極的な導入は難しそうという印象を持ちました。

*1:サンプルプロジェクトがcompileOnlyではなくcompileでchecker frameworkに依存してるのはなぜ？等