About me

中野 暁人 (Akihito Nakano)

  • Strongly interested in distributed systems and peer-to-peer networking.
  • Building Ethereum at Sigma Prime part-time. | 2022 - current
  • Web application developer at ASKUL | 2018 - current
  • Formerly core team & founding member of OpenAPI Generator | 2018 - 2020

Career history

Talks

Blog posts

Books

REST APIのためのコード生成入門 - OpenAPI Generatorを利用したRESTful API開発の効率化

REST APIのためのコード生成入門

https://gumroad.com/l/openapi_generator_ebook_jp
William Cheng 著, 中野暁人 / 和田拓朗 訳
※ 2018年2月に発売した “REST APIのためのコード生成入門” の内容をOpenAPI Generatorで更新したもの
2019年7月 発売

WEB+DB PRESS Vol.108|技術評論社

WEB+DB PRESS Vol.108|技術評論社

https://gihyo.jp/magazine/wdpress/archive/2019/vol108
「特集1 [効率急上昇!]スキーマ駆動Web API開発」の1章後半〜2章を執筆
2018年12月22日 発売

REST APIのためのコード生成入門 - Swagger Codegenを利用したRESTful API開発の効率化

REST APIのためのコード生成入門

https://gumroad.com/l/swagger_codegen_beginner_jp
William Cheng 著, 中野暁人 / 和田拓朗 訳
1〜3章の翻訳を担当
2018年2月 発売

Skills

過去在籍していたGMOペパボという会社では、上級職への選考の際「技術力」を “作り上げる力” “時間の経過に耐える力” “影響を広げる力” の3つに分解して評価が行われていました。

ペバボのエンジニア職位制度のアップデートについて - Kentaro Kuribayashi’s blog

これらの基準は当該企業の事業内容等への依存が一切無くきれいに一般化されていますので、以下でもこの3つの力の観点を使わせていただきながら私の技術力について書きます。

(ブログで公開できるレベルまで一般化した表現で自身の技術力について継続的に書き出すことで、対外的なアピールと、自身の振り返りと今後を考える材料としていきます)

1. 作り上げる力

これは、一般に技術力といった場合に想像しやすい能力でしょう。「他の人にはない、技術的に優れた何か」を用いて、技術的に困難な問題を、素早く、確実に解決することができる、ということです。

オープンソースソフトウェア(OSS)への貢献とそれを業務に活かすサイクル

OpenAPI Generatorという、Swagger CodegenをフォークしたOSSCore Teamのメンバーとして活動しています。

<貢献度の高さ>

当該プロジェクトの立ち上げ期(OSSプロジェクトとして公開する前に非公開リポジトリで開発を行っていた期間)の唯一最重要な課題がOpenAPI Specification3(OAS3)への対応でした。
40人以上のSwagger Codegenのコントリビュータがフォークすることに賛同し、プロジェクト公開までの1ヶ月半の間に300以上のプルリクエストが送信されました。このうち私が出した25のPRがマージされていて、これはPR数でいうと上から3番目になります。(非公開リポジトリでの作業なのでPRは見れませんが、OpenAPI Generatorのコミットログとして残っています)
また、Contributorsの上位10人に入っており貢献度の高さの証明になっています。

<貢献の多様さ>

プロジェクトの公開時はメディア数社にリリースの通知を行いPublickey様に記事化していただきました。はてなブックマークで400以上ブックマークされており、これをきっかけに一気に国内での認知が広まりました。

REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク - Publickey

また、Twitterの公式アカウントで国内ユーザーのフォローを行ったり、プロジェクトへのコントリビュートに関心を持っている開発者に対してTechnical Committeeへの参加を呼びかけ、実際に加入していただくなど、コードを書くこと以外の面でも貢献しています。

<業務に活かすサイクル>

このようにしてプライベートで携わっているソフトウェアを自身の担当業務に導入し、導入して感じた課題をフィードバックするサイクルを実践している例を2つ挙げます。

(1) “OpenAPIドキュメントのバリデーションをCIのプロセスに組み込む”

OpenAPI Generatorには、validate サブコマンドでドキュメントの妥当性をチェックすることができます。これをCIのプロセスに組み込むことで、OASのフォーマットの間違いを機械的に検出することができるようになりました。
また、v3.0.2では validate サブコマンドに --recommend オプションが追加されており、私はこの機能の仕様検討に参加していました。

CLI: add info about unused schemas in the validate command · Issue #142 · OpenAPITools/openapi-generator

(2) “OpenAPIドキュメントから自動生成したAPIクライアントを公式クライアントとして公開する”

自身が担当しているサービスのAPIクライアントをOpenAPI Generatorを利用して生成/公開しました。

pepabo/colormeshop-ruby

公開していく中で感じた改善点を下記のようにフィードバックしています。

このように高い質・量・スピードでソフトウェアを改善しながら、それを業務に導入することでサービスの改善とOSSへのフィードバックのサイクルを回すことが私の作り上げる力を示しています。

2. 時間の経過に耐える力

一方で、我々が作るものは、単に一度作れば済むものではなく、継続的に価値を届け続けるべきものです。つまり、ある特定の時点における線の価値のみが高いだけでは不十分です。それに加えて、時間の経過に対して積分的な面の価値を増大させる必要があります。そのためには、設計力、テストを書く能力が必要です。

目指しているアーキテクチャが抱えるであろう課題を見通してオープンなかたちで解決する

当時、ロジックが様々なロール/言語でそれぞれ実装されているために機能追加や保守が難しくなってきている背景があり、それを解決するために(ロジックが集約された)APIを中心にして、サービスを提供するロール群がそれを取り囲むようなかたちのアーキテクチャに移行するという方針のもと事業部全体の開発が進められていました。

その中で私は 中心に据えたAPIの障害が周辺のロールに波及してしまう ことを懸念し、その対策としてサーキットブレーカーの導入について事業部のTech MTGで発表し、社内にカスケード障害の危険性とサーキットブレーカーの有効性を啓蒙しました。

また、APIを利用するのはPHPで実装されたロールが多いのでPHP製のサーキットブレーカーのライブラリをいくつか試したのですが良いのが見つからなかったので自分で実装しGanesha(ガネーシャ)という名前でオープンソースとして公開しています。

ackintosh/ganesha: PHP implementation of Circuit Breaker pattern.

Tech MTGでの発表では実際にGaneshaが動作する様子をデモし、上々の評判をいただきました。Ganeshaはその後もRedisアダプタの実装GuzzleMiddlewareの対応のように開発を継続しています。現在(2019-08-01)、実際に海外のサービスで採用されていたり、Github star数は “191” で Packagistで公開されている “Circuit Breaker” タグが付いている中で最もスター数が多いライブラリです。

このように、プロダクトが目指しているアーキテクチャが抱えるであろう課題を見通し、すばやく手を動かしながらオープンなかたちで解決することが私の時間の経過に耐える力を示しています。

3. 影響を広げる力

さらには、上記の能力に基づいて、自分や身の回りだけではなく、エンジニアリングにおけるリーダーとして影響力を広い範囲に及ぼせることも、シニア、アドバンスドシニアには求められます。技術的には技術レイヤーの上下方向へ、プロセス的には広い範囲の人々を巻き込んでいく左右方向へ、それぞれ影響を広げていける能力です。

(((WIP)))