外部発信よりも内部共有・実践 [プログラマー現役続行]
エンジニアが集まって、LTを行ったり、20分から30分程度の発表を平日の夜に行うというのは、いつ頃から広まっているのか定かではありませんが、この10年間で確実に広まってきています。さらに、コロナ禍により、オンライン開催も加わり、広く行われるようになりました。
一方、Advent Calendarといったtech blog(技術文書)を公開することも多く行われています。企業内の開発で得た知見を、オンラインで説明しながら話したり、tech blogとして公開することは、今日のIT業界では、当たり前のように行われています。これらは、すべて外部へ向けての発信です。
外部発信することで、その企業の技術力を発信することにもなり、エンジニアを惹き付けることにもなります。私自身もTech Talkで話をしたり、tech blogを書いてきました。このような情報発信は、今後も多くのIT企業やスタートアップで行われていくと思いますし、ソフトウェア業界で知見を共有する上でとても有益だと思います。
このような情報発信を外部から見てみると、発信されている知見がその企業で広く共有され、ベストプラクティスと思われるようなことは、その企業内で広く実践されていると思いがちだと思います。しかし、本当にそうなっているのでしょうか?
多くのIT企業やスタートアップでの情報発信は、「外部へ発信」することが目的であり、「知見を社内で共有する」ことは目的ではなかったりするのではないでしょうか。得られた知見やベストプラクティスなどは、外部へ発信するのではなく、内部で共有して実践することが、企業にとっては本来優先順位が高くあるべきだと思います。その上で、外部発信することで、業界全体へ貢献することになります。
おそらく、このような状況になるのは、外部への発信を促進する責任を持つチームやグループが組織内にはあるけど、内部での共有や実践を促進することに責任を持つチームやグループが存在しないからではないでしょうか。あるいは、個々のエンジニアにとって、そのような活動をすることが責務ではないからかもしれません。あるいは、一人のエンジニアとして強く推進するのにはかなりの努力が必要な場合があるからかもしれません。
組織として何らかの活動をしないと、さまざまな知見やベストプラクティスが、属人化したものとなってしまい、たとえそれらが外部へ積極的に発信されていていも、組織内で広く共有されいなかったり、実践されていなかったりするのではないでしょうか。
一方、Advent Calendarといったtech blog(技術文書)を公開することも多く行われています。企業内の開発で得た知見を、オンラインで説明しながら話したり、tech blogとして公開することは、今日のIT業界では、当たり前のように行われています。これらは、すべて外部へ向けての発信です。
外部発信することで、その企業の技術力を発信することにもなり、エンジニアを惹き付けることにもなります。私自身もTech Talkで話をしたり、tech blogを書いてきました。このような情報発信は、今後も多くのIT企業やスタートアップで行われていくと思いますし、ソフトウェア業界で知見を共有する上でとても有益だと思います。
このような情報発信を外部から見てみると、発信されている知見がその企業で広く共有され、ベストプラクティスと思われるようなことは、その企業内で広く実践されていると思いがちだと思います。しかし、本当にそうなっているのでしょうか?
多くのIT企業やスタートアップでの情報発信は、「外部へ発信」することが目的であり、「知見を社内で共有する」ことは目的ではなかったりするのではないでしょうか。得られた知見やベストプラクティスなどは、外部へ発信するのではなく、内部で共有して実践することが、企業にとっては本来優先順位が高くあるべきだと思います。その上で、外部発信することで、業界全体へ貢献することになります。
おそらく、このような状況になるのは、外部への発信を促進する責任を持つチームやグループが組織内にはあるけど、内部での共有や実践を促進することに責任を持つチームやグループが存在しないからではないでしょうか。あるいは、個々のエンジニアにとって、そのような活動をすることが責務ではないからかもしれません。あるいは、一人のエンジニアとして強く推進するのにはかなりの努力が必要な場合があるからかもしれません。
組織として何らかの活動をしないと、さまざまな知見やベストプラクティスが、属人化したものとなってしまい、たとえそれらが外部へ積極的に発信されていていも、組織内で広く共有されいなかったり、実践されていなかったりするのではないでしょうか。
2022-09-07 17:11
コメント(0)
株式会社メルペイを退職します [転職]
2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。
メルペイでは私が入社した時点で、すでにマイクロサービスをGo言語で開発していました。私自身は、Go 1がリリースされるより前の2010年夏からGo言語を学んでおり、メルペイへ入社した時点で、次の2冊のGo言語に関する翻訳本を出していました。
Go言語に関しては特に問題はなかったのですが、それ以外の使っている技術やサービスは初めて触れる物がほとんどでした。
最初の仕様が確定してから、マイクロサービスをどうやってテストするのかを検討しました。正直、ウェブサービスが初めてで、マイクロサービスも初めてでしたので、どのようにテストするのが標準的なのか全く知らない状態で、テスト方法を検討しました。
その結果、gRPCのエンドポイントを呼び出して、マイクロサービスの本番コードをほぼそのまま起動して、手元のMacBook Proでテストできるテストフレームワークを考案しました。正直、その時点で、メルペイ内の他のマイクロサービスがどのようにして、gRPCのエンドポイントを呼び出してテストしているのかはほとんど知りませんでした。
フレームワークの実装が終わったら、gRPCのエンドポイントを順にテストファーストで開発していきました。この時の経験をGDG Dev Fest Tokyo 2019で話をしました。その後、同じ話をいくつかのカンファレンスで話したのですが、最後は、Mercari Gearsとして動画(およびテキスト)にしてもらいました(merpay マイクロサービスの開発とテストファースト/テスト駆動開発)。
私が考案したマイクロサービスのテストフレームワークは、後に独立したリポジトリとして共通ライブラリとして私自身で整備し、現在では、採用しているマイクロサービスが増えています。
異動してきた時点で、そのマイクロサービスの自動テストは安定しておらず、かなりflakyなテスト群となっていました。テストを安定させるために、何が問題なのかを一つずつ調べて修正していきました。その際に、問題点を洗い出すための用いた手法が、「長時間ランニングテスト」です(「長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」「(続)長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」)。
長時間ランニングテストは、私自身にとっては、目新しい手法ではなく、2003年からずっと行ってきた手法です(「マルチスレッドプログラミングにおける重要な4要件」)。基本的に、この長時間ランニングテストは、ずっと続けてきました。
テストが安定化した後に、問題になったのは、テスト時間でした。そのため、
週4日勤務
「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました(週4日勤務で働くことに関して、入社前に合意してもらっていました)。10月からの会社では、週4日勤務の雇用契約で働きます。初めてのウェブサービス開発
富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に従事してました。ウェブサービス開発に従事するのは、(gRPCの経験は、前のソラミツで多少は経験していましたが)メルペイがほぼ最初と言ってもよい状態でした。メルペイでは私が入社した時点で、すでにマイクロサービスをGo言語で開発していました。私自身は、Go 1がリリースされるより前の2010年夏からGo言語を学んでおり、メルペイへ入社した時点で、次の2冊のGo言語に関する翻訳本を出していました。
Go言語に関しては特に問題はなかったのですが、それ以外の使っている技術やサービスは初めて触れる物がほとんどでした。
最初に担当したマイクロサービス
最初に担当したマイクロサービスは、「加盟店様向けの管理画面」用のAPIマイクロサービスでした。管理画面の仕様に対して、バックエンドのAPIマイクロサービスがどのような機能を提供すれば仕様を実現できるかと検討しながら、マイクロサービスのAPI仕様を.proto
ファイルにコメントとして記述して、API仕様を策定する作業を2か月ほど行いました(「gRPCを用いたマイクロサービスのAPI仕様の記述」)。最初の仕様が確定してから、マイクロサービスをどうやってテストするのかを検討しました。正直、ウェブサービスが初めてで、マイクロサービスも初めてでしたので、どのようにテストするのが標準的なのか全く知らない状態で、テスト方法を検討しました。
その結果、gRPCのエンドポイントを呼び出して、マイクロサービスの本番コードをほぼそのまま起動して、手元のMacBook Proでテストできるテストフレームワークを考案しました。正直、その時点で、メルペイ内の他のマイクロサービスがどのようにして、gRPCのエンドポイントを呼び出してテストしているのかはほとんど知りませんでした。
フレームワークの実装が終わったら、gRPCのエンドポイントを順にテストファーストで開発していきました。この時の経験をGDG Dev Fest Tokyo 2019で話をしました。その後、同じ話をいくつかのカンファレンスで話したのですが、最後は、Mercari Gearsとして動画(およびテキスト)にしてもらいました(merpay マイクロサービスの開発とテストファースト/テスト駆動開発)。
私が考案したマイクロサービスのテストフレームワークは、後に独立したリポジトリとして共通ライブラリとして私自身で整備し、現在では、採用しているマイクロサービスが増えています。
他のマイクロサービスチームへの異動
その後、いくつかのチームを異動して、2020年7月からは「メルペイスマート払い」に関連するマイクロサービスチームへ異動しました。このチームでは、私自身で何らかのビジネスロジックを実装することはほとんど行っていません。しかし、行った作業の中でも印象的なのは、「テストの安定化」です。異動してきた時点で、そのマイクロサービスの自動テストは安定しておらず、かなりflakyなテスト群となっていました。テストを安定させるために、何が問題なのかを一つずつ調べて修正していきました。その際に、問題点を洗い出すための用いた手法が、「長時間ランニングテスト」です(「長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」「(続)長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」)。
長時間ランニングテストは、私自身にとっては、目新しい手法ではなく、2003年からずっと行ってきた手法です(「マルチスレッドプログラミングにおける重要な4要件」)。基本的に、この長時間ランニングテストは、ずっと続けてきました。
テストが安定化した後に、問題になったのは、テスト時間でした。そのため、
t.Parallel()
を呼び出したら並列に動作しないテストコードを一つずつ修正して、できる限り並列に実行するようにしました。そのときの知見をまとめたのが、「Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜」です。複業の継続
「複業を20年」に書いていますが、週4日勤務というのもあって、メルペイ在籍中も継続して行ってきました。技術書の翻訳
翻訳本としては、以下の4冊を出版しました。新世代Javaプログラミングガイド[Java SE 10/11/12/13と言語拡張プロジェクト] (impress top gear)
- 出版社/メーカー: インプレス
- 発売日: 2020/03/13
- メディア: 単行本(ソフトカバー)
スーパーユーザーなら知っておくべきLinuxシステムの仕組み
- 出版社/メーカー: インプレス
- 発売日: 2022/03/08
- メディア: 単行本(ソフトカバー)
Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築
- 出版社/メーカー: オライリージャパン
- 発売日: 2022/08/03
- メディア: 単行本(ソフトカバー)
技術教育
企業向けの技術教育としては、「Go言語研修」と「Java言語研修」を行ってきました。2020年2月まではオフラインの教育でしたが、それ以降は、オンラインの教育でした。オフラインの教育では、研修後に受講生の人達と懇親会をするのも楽しみでした。また、Go言語研修では、古川陽介さんや和田卓人さんも受講してくれました(「第6期、第7期のGo言語研修が終了しました」)これから
これからもソフトウェアエンジニアとして働きながら、技術教育や技術書の翻訳、それにオンライン読書会(ブログのPC版で左上に一覧があります)も続けていきたいと思っています。2022-09-02 18:02
コメント(0)