Classi開発者ブログ

教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。

中立的なGraphQLスキーマの管理

こんにちは、id:aerealです。

今回はGraphQLのスキーマ管理を工夫している点について紹介します。

背景

対象となるアプリケーションは内部向けのコンテンツ管理システム (以下、内部CMS) で、エンドユーザ向けを含む複数のサービスから呼び出されます。またAngularで書かれたWeb UIを備えます。

内部CMSを開発するチーム内には主にサーバサイドを担当するメンバーと、主にクライアントサイドを担当するメンバーとがおり、どちらもGraphQLを用いた開発経験があります。

この内部CMSはスクラッチから開発を始めており、目指すリリース予定日に対してやることは山積みなのでうまくタスクを分担したい状況にありました。

時と場合によってはクライアントサイドのチームの手が空いていたりあるいは逆になったり、状況は目まぐるしく変わります。

ですから手が空いた方がスキーマの設計に手をつけられるような分業体制を整えるモチベーションが強くあります。 *1

つまり スキーマの管理を特定のチームやコンポーネントに寄せず、責任・主導権を関係者の誰もがとれる ようにすることを狙って設計しました。 この点を指してタイトルにあるように「中立的な管理」と表現しています。

これから具体的な手法について紹介しますが、同等のコードを含むリポジトリを公開しましたのでぜひこちらも併せてご覧ください: https://github.com/classi/example-graphql-api-schema

内部CMSの構成

クライアントサイドはフレームワークにAngularを、GraphQLクライアントにはApollo Clientを採用し、TypeScriptで書かれています。

TypeScriptの型生成にはGraphQL Code Generatorを使っています。

サーバサイドはGoで書かれておりフレームワークの類は採用せず、標準のnet/httpのみでHTTPサーバを書いています。 GraphQLのサーバサイド実装およびコード生成はgqlgenを使っています。

スキーマの配置

クライアントサイド・サーバサイドのどちらからも中立させるためにスキーマは独立した単体のリポジトリに配置します。 簡便のため以後の文中では単に「スキーマリポジトリ」と呼びます。

スキーマリポジトリではGitHub Package RegistryのNPM registry (以下、単にGitHub Pacakge Registry) を介してスキーマファイルを含んだNPMパッケージを配布し、スキーマを利用するリポジトリはこのNPMパッケージを利用します。

後述するリリース関連のスクリプトや各種設定ファイルを除けばスキーマファイルのみが置かれています。 以下はファイル配置をtree(1)で出力したものです:

# tree --gitignore
.
├── LICENSE
├── README.md
├── analyzer
│   └── requireauthorize
│       └── checker.go
├── go.mod
├── go.sum
├── graphql.config.yml
├── index.ts
├── package-lock.json
├── package.json
├── schemata
│   └── main.gql
├── tools
│   ├── analyze
│   │   └── main.go
│   └── generate-manifest
│       └── main.go
└── tsconfig.json

開発者はスキーマファイルを変更するPull Requestを送り、関係者のレビューを経てマージされたあと新しいNPMパッケージがリリースされます。

スキーマのリリース

前述の通りスキーマはNPMパッケージとして配布されます。

このリリース手順は自動化されており、変更したい開発者の視点では単にPull Requestを送りマージするだけで新しいスキーマが配布されるようになっています。

既存のOSSを参考にsemantic-releaseを使って新しいバージョンの発行とGitHub Package Registryへの公開を自動化しています。

開発者に求められるのはConventional Commitsに従ったコミットメッセージを書くだけです。

Conventional Commitsを内部向けリポジトリに採用することへの懐疑や批判を抱かれる読者もいるかもしれません。

今回取り上げる内部CMSのスキーマリポジトリでは単に「semantic-releaseによって新しいバージョンを発行するための規約」としてConventional Commitsに従っているものとしており、厳密なsemantic versioningに従うものではないということを合意しています。

つまりごく単純化すれば「新しくバージョンとしてリリースしたい変更を含む場合は fix:, feat: などのタグをつける」「それ以外のリリースフローの改善などのみを含む変更はその他のタグ (e.g. chore:, build:, etc.) を使う」というルールしか強制しません。

いずれにせよシステムに変更を加える際には動作確認をすることを前提としているので「後方互換性を保つかどうか」といった含意を重視してないということです。

スキーマの利用

GitHub Package Registryは対応するリポジトリ自体の公開範囲とは別にパッケージ自身の公開範囲を定義できます。

たとえばリポジトリXからは読み取り (= インストール) のみ許可し、リポジトリYには加えて書き込み (= アップロード、新規リリース) を許可する……といった風です。

我々の内部CMSにおいてはクライアントサイド・サーバサイドそれぞれのリポジトリに読み取り権限を許可し、スキーマリポジトリに管理権限を許可しています。

読み取りたいリポジトリのGitHub Actionsワークフローで packages: read の権限を与えると、リポジトリが読み取りを許可されているパッケージをインストールすることができます。

これら詳細についてはPublishing and installing a package with GitHub Actions - GitHub Docsを参照してください。

もし単にGit submoduleやworktreeを用いてリポジトリを参照しようとすると現時点のGitHub Actionsないし類似のCIサービスでは、より複雑かつ潜在的な危険性を孕んだ構成が求められます。

細やかな権限付与により安全でありながら、利用する際に複雑な設定の既述や手順が求められないためGitHub ActionsとGitHub Pacakge Registryを採用しています。

Goで書かれたサービスでNPMパッケージを利用する?

クライアントサイドはパッケージレジストリのエコシステムとしてのNPMに既に乗っているから良いとして、Goで書かれたサーバサイドのリポジトリではどうするんだ? という疑問をお持ちかもしれません。

答えとしては「Goで書かれたサービスのリポジトリであってもpackage.jsonを置けば良いじゃない」というものになります。

おもむろに npm i -D @classi/example-graphql-api-schema (パッケージ名は例です) すれば node_modules/@classi/example-graphql-api-schema/schemata/main.gql が手に入ります。

gqlgenの設定ファイルでスキーマのパスをこれに揃えておけば、問題なくコード生成もできます。

サーバサイドのリポジトリを扱う際にもNodeやNPM/Yarnが必要になりますが、Classiの開発者はWebアプリケーションエンジニアですから大した支障にはなりません。

ローカル環境にインストールする

各開発者のローカル環境にインストールする際には公式のAuthenticating with a personal access token - Working with the npm registry - GitHub Docsというドキュメントに従います。

Classic Personal Access Tokenを発行し、npmrcに「npm.pkg.github.com を参照する際はこのclassic PATを使え」という設定を既述することで認可されインストールできます。

執筆時点ではGitHub Package Registryの認可にFine-grained PATsは対応していません。

Fine-grained PATsは必要最小限の権限のみを付与できるのに対してclassic PATsは大雑把な権限付与しかできないので漏洩したり誤用した時のリスクは大きくなります。

具体的には「リポジトリコンテンツの読み取り」という権限が少なくとも必要になりますが、対象リソースを絞れないので PATの所有者が権限をもつすべてのリポジトリを読み取れる ということになります。

相対的にリスクはあるものの、classic/Fine-grained共にPATの利用を追跡する仕組みがGitHubにより提供されていることもあり、利用を渋るほどではないと評価して呑んでいます。

Fine-grained PATsは若い機能で継続的に改善されているので、今後の改善に期待したいところです。

今後の改善点

classic PATs脱出

ローカル環境へのインストールにはclassic PATsが必要で、classic PATsはセキュリティ上の懸念があるということは既に述べた通りです。

これはGitHubがFine-grained PATsに対応させるしか本質的解決を望めないので座して待っています。

Renovate対応

依存パッケージの自動更新をしてくれる[Renovate]ですが、開発・提供するMendがホスティングするGitHub Apps版ではGitHub Package Registryでホストされているパッケージの更新にはPATが必要です。 これは前述のclassic PATの懸念に加え、[machine user]のPAT管理という新たな問題も生じます。

これはGitHub Package Registryの認可の仕組み上、仕方のないことではあります。

現時点では、スキーマをインストールする各リポジトリのGitHub Actionsワークフロー内でRenovateを実行するとこの制約を回避できます。

ただSaaS版と共存させようとすると煩雑で、GitHub Actionsで実行するということは、managedにせよself-hostedにせよrunnerの計算機資源を消費することになり、SaaS版と比べてクレジット消費増加やインフラコストの増加に繋がります。

我々はスキーマの利用者と密にコミュニケーションできる体制なのでRenovateによる自動アップデートを諦めています。 スキーマの利用規模が大きい組織ではこの問題はより深刻になるかもしれません。

むすび

我々が開発・運用している内部CMSで扱うGraphQLスキーマの管理・運用について紹介しました。

とても凝っているという印象を受けたでしょうか? あるいは意外と普通だなと感じましたか?

実際、筆者としては特別新規性のあることはやっていないと考えています。実はこうしたワークフローの設計・整備は特にOSSではよく見られるものです。

近年は、semantic-releaseのようにコモンセンスになっていたワークフローをロジックとして実装したソフトウェアや、内部向け用途にカスタマイズされたGitHub Package Registryなどの登場により、内部向け固有の要求を満たしつつ慣れ親しんだワークフローを実現しやすくなったと感じます。

また自動化されたワークフローとはワークフローがコード化されていることとほぼ同義です。

ソフトウェアエンジニアにとってコード化されたソフトウェアほど雄弁な文書はないというのが持論ですが、コード化されていれば変更を提案しそれを直ちに普及させることは、素朴な慣習や自然言語によるルールより、圧倒的に省力で済むのは間違いありません。

この記事で紹介したワークフローを提案し実装したのは主に筆者自身ですが、自動化されて考えることが少ないワークフローが整備されていることによって、実際に慌ただしい時にそのありがたみを感じることができました。

なにより便利さと「やりすぎなさ」のバランスをとりながらワークフローを設計するのはとても楽しい時間です。

エコシステムの成熟に感謝しながら、ぜひ身近なワークフローを自動化してみませんか?

*1:また、今回は深く触れませんがスキーマ駆動開発の実践として、モックレスポンスの生成・利用もしておりサーバサイドの実装を待たずにクライアントサイドの実装を進める余地があったことも手伝っての判断です。

SRE留学で体感したプロダクトチームとSREチームの違い

こんにちは。プロダクト開発部の id:ut61z です。

私は 2022/10 からSRE留学という社内制度を利用して、SREチームに所属しています。弊社のSRE留学制度については以下のliaob88さんの記事に詳しいので興味がある方は御覧ください。

tech.classi.jp

もともとバックエンドエンジニアとしてRailsのアプリケーション開発を行っていましたが、運用の一環でアプリケーション実行環境をEC2からECSへ移管する経験をし、それを皮切りにインフラ、AWS、SRE、DevOps などに興味を持ちました。

あるとき上司にSRE留学をしてみない?と提案されたのをきっかけに、自分でもできるのか?と不安を抱きながらもおもしろそうだなという感情が勝り、SRE留学を希望しました。

この記事では、実際に日々の業務を行っていくなかで感じたプロダクトチームとSREチームの違いや、ソフトウェアエンジニアとSREの業務の性質の違いについてなどを挙げていきたいと思います。

普段プロダクト開発に従事しているけれど、SREはどのようなことをしているのか?興味はあるけど専門知識が必要でハードルが高いのでは?といった疑問に対してなにかヒントになれば幸いです。

日々の仕事の進め方

日々の仕事の進め方は、プロダクトチームとSREチームでほぼ差異はないと言っていいでしょう。

今はカンバンでタスク管理をしていて、毎朝優先度の高いものを確認し、上から順に取り組むというスタイルで進めています。月に一度タスクのリファインメントを行い、優先度の見直しも行います。また、隔週で振り返りを行い、2週間で起こったできごとをベースに次の2週間でトライすることを定めて、業務のカイゼンにつながるように努めています。

タスクの性質

SREチーム特有の性質として、各プロダクトチーム、あるいは他部署からの依頼やシステムアラートなど、リアクティブに反応するようなタスクが比較的多いということが挙げられるでしょう。

  • インフラリソースの追加・変更・削除 (Terraform修正) のレビュー
  • 各チームから依頼を受けて行うSRE管轄のインフラリソースの操作オペレーション
  • システムアラートや障害発生時の対応
  • その他インフラに関する相談受付

SREは、サービスの信頼性を維持しつつ、プロダクト開発を行うエンジニアがより安全に素早く開発を行うことをサポートする責務があるため、直接的なフィードバックを得る「顧客」は、サービスのユーザーであると同時に、プロダクト開発を行うエンジニアでもあります。

誰に価値提供を行うか?という点でプロダクトチームがサービスユーザーであるのに対して、SREはプロダクトチームのエンジニア(の比率が高い)という捉え方もできるでしょう。

チームトポロジーでいうところの、ストリームアラインドチームとプラットフォームチームの違いと言い換えることもできそうです。

それ以外にも、トイルになりがちな、利用している各外部サービスとの契約、見積、アカウントの作成、権限付与なども行っています。このあたりの作業は、自動化したり、権限を渡して各チームでできないかというのを模索している最中で、エンジニアリングが求められるところだと感じています。

インフラ知識

言わずもがなですが、SREはインフラ知識が必要で、プロダクトチームのソフトウェアエンジニアより多くのそれを求められます。

しかし、SRE留学をしてみて逆説的に体感したのは、プロダクト開発においてもインフラ知識は必要だということです。

SREとして相談を受ける立場に立ってみると、要求を実現するための要素としてインフラ知識は一定欠かせず、インフラとアプリケーションを総合的に考慮したうえでの意思決定が求められるシーンがあると感じました。

「これを実現したいからインフラについてこうしようと考えている」という相談ができるような知識がプロダクトチームにあると、SREはそれに対する適切なフィードバックをしやすいです。少し話はそれますが、そういったプロダクトチームになるために、SREとプロダクトチームのエンジニアで接点を持つ機会を増やすべく、まさにSRE留学を含めたいくつかの施策をSREとして行っています。

プロダクトの知識

逆にアプリケーションの振る舞いや、ドメイン知識、事業戦略などについてプロダクトチームのみが知っているべきで、SREは知らなくてもよいかといえば、それもNOだと言えます。

インフラ設計や、SREingを実践していくうえで、それらのプロダクトの知識もまた必要不可欠だからです。

とはいえ、各チームが担当するすべてのアプリケーションの振る舞いを詳細に把握するのは現実的ではないでしょう。とくにClassiは、様々な機能を提供しているので全体像を把握するだけでも一苦労です。

ただ、各プロダクトチームから相談を受けることで、俯瞰的にプロダクトを見ることができるのもSREチームの特徴だと感じました。SRE留学前の一プロダクトチームに属しているときの自分では、そこまで解像度が高くなかった別チームの機能についても、インフラ面でのサポートやTerraformのPRレビューを通して理解を深めることができました。

システムアラート

システムアラート対応はSREだけが責任を持って対応しているかというと、弊社の場合はそうではありません。プロダクトチームのエンジニアであっても、即座に気づいた人が反応します。自チーム/他チーム問わず、まずはなにか起きれば反応して有識者を募れる組織だと言えます。

そのような姿勢は以下の記事でも紹介されています。

tech.classi.jp

システムアラートの発生から各チームのエンジニアが協力して最速で解決を目指すという姿勢は、SREの立場に立ってみると改めてとても頼りになります。

そもそもアラートのためのモニタリング設定や、すぐに切り戻しができるようなデプロイパイプラインの構築などがプロダクトチームで当たり前にできているからこそ、そのように反応ができる状態に至っているので、単にシステムアラートに反応するということを超えて、SREingがプロダクトチームに浸透していることを実感します。

システムアラートへの反応及び信頼性への意識については、SREとプロダクトチームで差異はないと言えるんじゃないでしょうか。

違いに注目することで見えてきたもの

いくつかプロダクトチームとSREチームの違いを挙げてみましたが、SRE留学を通じて私が感じたのは、プロダクト開発・運用の一側面を担っているという観点においては、SREチームもプロダクトチーム(の亜種)のような存在ではないかということです。

実はSRE留学をする前は、SREと聞くと特殊な領域で作業する特殊な技術分野に尖った"専門家集団"のような印象があり、少し敷居が高かったのですが、中に入ってみると、プロダクトをよりよいものにするという目的下において、SREチームはプロダクトチームと地続きな存在では?という印象に変わりました。

また、プロダクトをよりよくするには、インフラの知識やSREingのスキルやマインドセットがどうしても必要になってくるという逆の視点からも、プロダクトチームとSREチームは地続きな存在だと言えそうです。

もちろん違いもあり、さきにあげたように、プロダクトチームはストリームアラインドチーム、SREチームはプラットフォームチームという捉え方もできるので、業務の性質として異なる点もあります。たとえば、特定のインフラリソースの取り扱い方のポリシーを定めてそれに則ってもらうように働きかけるなどです。

そういった意味ではSREチームはプラットフォームチームとして、全体最適が図れるような動きが求められ、プロダクトチームはストリームアラインドチームとして、顧客価値を最大化するために、絶えずプラットフォームチームにフィードバックする動きが求められます。

さいごに

SRE留学を通して感じた、プロダクトチームとSREチームの違いを列挙してみました。

しかし、違いについて深堀りしていくと、そこには共通性があり、両チームは断絶されたチームというよりは地続きであるという視点が得られました。

Classiでは仲間を絶賛募集しています!SREをキャリアの選択肢として考えている方や、SRE留学制度のような組織文化に興味を持っていただけた方などなど、ぜひカジュアル面談などでお話しましょう!

【開発者インタビュー #2】藤田 勇希

こんにちは!Classiで働く開発者インタビューシリーズ企画の第二弾は、プロダクト開発部の藤田さんです。

まず簡単に自己紹介をお願いします

藤田勇希と申します。 仕事でもプライベートでも「ゴリラ」か「ハシビロコウ」の画像をアイコンにすることが多く、社内でも「ゴリラアイコンの人だ」というような認識をされているかもしれません。

藤田さんといえばゴリラのアイコン

経歴は、音楽・書籍・コミックのようなコンテンツ配信サービスのバックエンドの開発に、新卒から約5年間携わりました。 その後、スペースシェアのCtoCサービスのバックエンド開発・運用を2年ほど行ってきました。

Classi には 2021年7月にジョインして、この4月にリリースされた「学習トレーニング」のコンセプト検証を目的とした前身サービスの開発に関わりました。

ー これまでどんな軸で転職をしてきたのですか?

それぞれの転職のタイミングで大切だと思う軸が変化しています。

1社目から2社目はエンジニアとしてもっと挑戦的な立場で、スタートアップでの青春を味わいながらエンジニアとしての力量をプロダクトに直結させたい、という思いが強かったです。Classiへの転職の際は、スタートアップでの青春の卒業をし、次なるチャレンジをしたいと思っていました。あとは待遇や働く環境というところも気にしていたと思います。

Classiへの入社経緯、入社理由は?

最初は転職エージェントを経由してClassiに出会いました。そして、EdTechという難しい業界でマネタイズができている点や「学校教育」という社会貢献性が高い問題に携われることに魅力を感じて入社を決めました。 ジョイントベンチャーとしての土台があってスタートダッシュができた結果、成長してきたという納得感もありました。(参考資料:Classi会社紹介資料

ー 元々教育に興味があったのですか?

EdTechは前々から面白そうだと思っていました。

自分の人生を振り返った時に、学生時代の大部分を勉強のみに費やしたことに後悔のようなものがあるんです(笑) 勉強はもちろん大切だし今にも繋がっていますが、勉強以外にも大事なことって沢山あったなと。 なので、もう一度やり直して自分を変えられるとしたら教育なのでは思っています。将来の子どもたちには、私の数倍の効率で学力を得ることができて、残った時間を勉強以外にも使って有意義に過ごしてほしいなと思います。そして、自分と同じように学生時代を後悔する人が少しでも少なくなるような教育にすることが出来たらいいなと思っています。

また、前回のonigraさんのインタビューブログの中で機会の均等化の話があってすごく共感しました。貧富の差によって教育の優劣がつく状況を打破したいですね。

Classiでの仕事内容を教えてください

学習領域のプロダクトのバックエンドを中心に機能開発・運用を担当しています。 ユニットリーダーとして、学習領域のエンジニアが抱えるテックイシューへの取り組み、メンバーのコーチングなども行っています。 業務の割合としては、大体、9割が開発業務で、1割がユニットリーダーとしての仕事だと思います。

ー 学習領域についてもう少し具体的に教えてください。

「学習領域」とは Classi が提供するサービスや機能の中でも

  • 生徒に取り組んでもらう問題コンテンツを提供する
  • 生徒の苦手・得意に応じておすすめの問題を提供する
  • 模試に向けての対策テストを提供する

といったように、「学習」の体験を高めることを目的とした領域です。 この領域では、実際に生徒に解いてもらう各教科・単元の問題コンテンツを制作するシステムや、制作した問題コンテンツに Classi のサービスを使って取り組めるような機能の開発などをしています。

現在、私は Classi が提供するこの大事な問題コンテンツを、高い品質で制作できるように支援する社内サービスの開発を行っております。

ー ユニットリーダーとしてどんなことをやっているのですか?

ユニットリーダーとしてはメンバーと1on1をしたり日々のケアをしたりしています。 メンバーにはグレードが上がっていくのを支援したいと思っていて、「ちゃんとグレード上げていこう!」と日々伝えるようにしています。そして、Classiでは若手の成長や自立によって突き上げがあるので、すごく良い意味で怖いなーと思っています(笑)

ー どんなことを意識してユニットリーダーをやっていますか?

「自分が関わる人が動きやすくなるように、成長していけるように動く」ということを念頭に他者貢献に振って動くようにしています。それが結果的にチームとしてのアウトプットに繋がっていくと思っています。 チームで仕事をする時に私のように動く人は必要だと思うし、そういった自分のムーブはいい方向に行っているんじゃないかなーと思っています。

Classiでの仕事の面白さや、やりがいについて教えてください。

プレイヤーとして非常に優秀なエンジニアの人と一緒に仕事をできること。

あとは、教育現場の先生・生徒といった、ある意味コンテキストが限定されたユーザーの生の声に触れられて、フィードバックをもらいながらプロダクト改善を進められる環境があること。

ー 一緒に仕事ができてよかったと感じるエンジニアは?

何人もいるのですが…まずはlacolacoさんですね。

エンジニアとしてスキルが高いことはもちろんですが、それ以外のもっと抽象的な能力が高いなと感じています。課題を抽出したり物事を捉えたりが上手で、「社会人として強い」という感じです。その産物としてエンジニアリングができるという印象があります。 なので別の領域に置かれてもすぐに色々とキャッチアップできていて、コーポレート部門の課題解決に携わっていた時もとても活躍していたので本当に流石だなと思います。

ー 優秀だと思うエンジニアと一緒に働くことで変わったことはありますか?

だいぶ横暴になったと思います(笑)

横暴というとあんまり表現がよくないかもしれないですが、意見をはっきり言うようになったり、意見をつっぱねたりするようになったと思います。 チームメンバーが良い意味ではっきりと物事をいう人ばっかりで、「いかにシンプルに情報を正しく伝えられるか」というコミュニケーションがされていました。 私はこれまでは「忙しいだろうなー」とか「伝えたらどう思うんだろう?」とか、「シンプルに情報を正しく伝える」こと以外に気を取られることが多くありました。 でもそういった思考に邪魔されてはっきりと伝えられなかった結果、アウトプットが出せない状態の方がよくないということを学びましたね。徐々にそう言った思考が入らなくなっていき、今思うと気にしすぎていてあまり意味がないものだったなーとも感じています。

しっかりとチームに価値を出していきたいと思っている中で、これまでになかったコミュニケーションを取り入れていって変化をしていると感じています。自分を変化させていくことに痛みを伴うと感じることもありますが、本当に良い影響だと思っていて成長を感じます。

ー 「ある意味コンテキストが限定されたユーザー」の生の声があることの面白さをもう少し教えてください!

ICT化された学校を経験していないので「今ってこんな教育業界なんだ、こんな風に勉強をしているんだ」と自分の時代とのギャップが面白いです。 そのギャップや学校という文化に触れることでカルチャーショックもありますが、生の声をいただきながらプロダクト改善を進められる環境があることはとても良いなと思っています。

Classiでの仕事の難しさや課題について教えてください。

業界の文化に慣れる必要があることだと思います。今の学校教育の抱える現状や、先生・生徒の事情の理解が必要になります。

また、ITリテラシーに差がある様々なユーザーの立場を考えたプロダクト提案が必要で、Webサービス界のスタンダードな考え方が適用できない場面があり、それらの Unlearn が必要な点も難しさだと思います。

そして、目的を達成するために必要な衝突に臆せず向かえる強いマインドを持つことが求められます。

ー 学校を理解することは難しいのでしょうか?

先ほどお話しした通り面白さでもありますが、カルチャーショックが沢山あって最初は難しかったですね(笑) 例えば先生の要望を伺って「印刷して紙で見たい!」というアナログなニーズがあるんです。話を聞いて実際に授業で使うことを想定して考えてみると、その場でペンで書き加えたり、その加筆したものをコピーしたりなどが求められていることがわかりました。それは「紙でやる方法に慣れている」ということでもあります。 Webサービス業界の「最新のかっこいいスマートなものをつくる」と衝突して、ナウいものを作りたいエンジニアからすると「なぜ紙??」となるんです。

今後はWebでやることにも慣れていけるように先生も徐々にUnlearnは必要になるとも思いますが、今はそこに向かう過渡期としてのバランスが大切だと思っています。 バランスを大切にしながらしっかりとニーズを汲み取って、機能を改善してWebでできるようにしていきたいですね。

ー 「目的を達成するために必要な衝突に臆せず向かえる強いマインド」とは?

ある意味どこに行っても求められるものだとは思いますが…より良いものを作りたいという目的達成の過程では、適切な衝突をする必要があると思っています。でもそれは元々気にしいな自分にとってはなかなか難しいことでもありました。

全てを受容していたら良くないことが起こってしまう可能性もあるし、考えや意見を言わないことは責任放棄になると思っています。いろいろな目線があるなかで、みんなプロダクトをよくしたいと思っているからこそ、必要な衝突をしないといけない。 そう言った目的を達成するために必要な衝突に臆せず向かえる強いマインドや志を持つ人が活躍すると思います。

働く上で大切にしていることは何ですか?

How にこだわるのではなく、Why にこだわること。

ー なぜWhyにこだわるようになったのですか?

エンジニアがプログラムを書いて作ることは課題を解決する上でのHowの1つだと思っています。 仕事は納期もあるので、工数をかけて作るということをせずに課題解決できる方法があれば最高の仕事です。ただ、自分がプログラムを書くのが楽しいと思っているからこそ余計に、その観点に気がつけず作ることに囚われてしまうこともあると思っています。「作らないと実現できない課題」のために「作る」時間を費やすことが大切だからこそ、本当に「作る」ことが正解なのかを俯瞰してみないといけないと思っています。onigraさんのインタビューブログにも出ていたエンジニアの三大美徳の怠惰の話は私も大切にしています。 なのでいつも立ち返る意味も含めてWhyを常に意識してこだわることは大切だなと感じています。

最後にひとこと

色々話しましたが「こうありたい」という気持ちも含まれているかもしれません(笑) でもそんな思いで今は頑張っていると思っています!常に全てできる訳ではないと思いますが、話したことを体現できるようにできたらと思っています



環境変化を柔軟にキャッチしながら成長し続けている藤田さんでした。次回もお楽しみに!

Classiでは「子どもの無限の可能性を解き放ち、学びの形を進化させる」というミッションに、ともに向き合っていただける仲間を募集しています。ご興味をお持ちの方は、 お気軽にお問い合わせください!

■採用ページ

corp.classi.jp

■各ポジションごとの求人

5日間のハッカソンとフィードバックをもらう重要性

こんにちは。プロダクト開発部の id:tkdn です。本記事では先日チーム合同で行ったハッカソンと、その成果物デモをディレクターや顧客に近いマーケティングのメンバーの前で行い、フィードバックをもらうまでの話を紹介します。

ハッカソンをとおして個人で獲得できた学びもありましたしチームやほかのメンバーとの協働がよりよくなりました。

そして何よりスピード感のあるアウトプットに対してフィードバックをすぐもらうことの大切さを痛感したので、そんなことも踏まえながらお伝えできればと思います。

きっかけ

今回ハッカソンを実施するに至った経緯はいくつかあります。

  • 2022 年度に成果物としたかったプロトタイプのデモアプリに着手できなかった
  • 今のチームだけではパワーが足りないという感覚があり本年度から組織体制の変更を見込んでいた
  • 以上の経緯も踏まえてマネージャーから Slack で以下のような提案があった

私は二つ返事でやりたいと伝えました。

yudai)来週ハッカソンやりますか tkdn)やりたいっすね

担当プロダクトの負の部分から脱却するためにデモアプリで実証したいことはありましたし、守りのプロダクト開発が最近は多かったので個人としてもハッカソンに取りかかりたいという思いがありました。

どうやったか

ハッカソンは 5 営業日使って行いました。もちろん普段担当するプロダクトもあるので、アラートや問い合わせがあった場合は普段のプロダクトを優先するという約束です。とはいえ、5 営業日ハッカソンに全ブッパで OK を出してくれたマネージャーには感謝ですね。

私が普段活動を共にしているエンジニアは 2 名ですが、先にも触れたとおり、平時の運用やアラートを並行しながら「ガッと」やるにはパワーが不足してしまうという懸念がありました。そのため事業として関心のある領域は一緒だが普段は別で活動している、お隣チームのエンジニア 2 名(ブログ執筆でも登場している id:kudoa が在籍しています)を加え、計 4 名のエンジニア体制で取り組むことにしました

またハッカソンでは 「何かを丁寧に教える場にせず自律的にやれることをどんどん見つけていってほしい」といったマネージャーの言葉を強く意識し、特に「丁寧に教える場にしない」ということを徹底しました。

ハッカソン参加メンバーの構成上、相対的にキャリアの長い自分自身がモブプロを主導したり(キャリアに開きがあるメンバー間のモブプロはティーチングになりがちです ※ 諸説ある)主体的に教えに行ったりするのはやめておこうと開始前から意識しています。

初日に最終日の勝利条件を決める

正直初日まで何かを準備するということはしませんでした。
私が Slack チャンネルと空のリポジトリ準備だけをして初日を迎えています。

初日にまずハッカソンで取り組んで作り上げたい成果物のイメージをマネージャーが説明しました。なぜそれが検証すべき機能たりえるのか、取り組むモチベーションは何なのか、ユーザーのターゲット層はどこなのか、それらのイメージを元にエンジニアが作り始めるにあたって前提となるアラインメントを行っていきます。

イメージの共有を終えて最後には「成果物のプロトタイプはフロントエンドのみで動作する Angular を使ったアプリケーションで、それを最終日にはデモできる状態にする」といった勝利条件をその場で決定しています。

4/14(金) 時点の勝利条件を決める
終日の勝利条件も、日々の記録・勝利条件にも GitHub Discussion が利用されました

最終日のゴールイメージ共有後、マネージャーと 4 名のエンジニアで今日の勝利条件を決めていきます。今日の ToDo ですね。

2 日目以降は私が毎朝デイリーで前日のタスク進捗と今日の勝利条件を確認する形で進行していきました。同期的に話す時間は朝のデイリーの時間だけで、あとは必要なタイミングで突発的に同期的に話す時間を作りました。

2 日目の仕切り直し

初日は勝利条件であるそれぞれの ToDo に取り組んでいき、アプリケーションがローカルである程度うごく様が見れるようになったタイミングで壁にぶち当たりました。

ゴールを達成するための How のひとつだった外部プラットフォーム(プラットフォーム A とします)の Web API が、我々が実現したいことにマッチしないとわかりました。

ただそれでも誰もうなだれるようなことはなかった気がします。

これはハッカソン開始前 Slack チャンネルに貼られたツイートですが、初日の段階でピボットできるなんて我々はけっこうやれているんじゃないか・良かったんじゃないか、といった空気が Slack のチャンネルにはありました。私もすぐさま別のプラットフォーム(プラットフォーム B とします)が提供する Web API の使い方を ChatGPT に聞いていました。

ハッカソン参加メンバーがその日のうちに代替となるようなプラットフォームを試したり、次のステップへ進むという動きを見せたりしていたのは、前向きで健全だなとも思いますし驚きでもありました。

メンバーの振る舞い

ハッカソンを通して特徴的だと感じたのは、参加メンバーの振る舞いが自主的でありながらさまざまなバリエーションがあったことです。各人の動きを相互に見る中で、お互いに任せたいタスクの種類が 2 日以降に固まっていたと感じます。

  • Angular アプリケーションを率先してガリガリ進める
  • アプリケーションのレールで実直に画面を作っていく
  • 実現可能性が不明な問題の可否について調査をしつくす
  • 必要だなを思われることを先回りして調べておく

平時活動をともにしているわけではないお隣のチームではありましたが、あまり接点を持たなかったにもかかわらず、短期間でお互いの特性を認知しあえたのはハッカソンだけに限らず平時にも役立てられる旨味でした。

そしてハッカソン中も、普段の担当プロダクトに来るお問い合わせやアラート対応もしていましたし、お隣のチームメンバーはライブラリアップデートのリリースまで済ませていました。そういったことも踏まえると、ハッカソンを始める前に「パワーが不足していた」と感じていたことさえも疑うべきだったのかもしれないと感じます。

年配者としてハッカソンを通じて感じたこと

ピボットした 2 日目の夕方頃にはコミットされていくコードを眺めて改善を考えるくらいには落ち着いた状態になっていました。

3 日目にはガリガリ画面を作ってブラッシュアップや改善をしながら機能を足していきました。やはり形ができていく喜びと実装している楽しさが相まるとテンションも高まります。

はーやっぱフロントエンド実装してんのが一番楽しい〜
生の喜びを感じる様子

それと同時に、2 日目中盤あたりから自ら「ああしたい、こうしたい」を先に Miro で雑な画面設計を書いて共有を始めています。さらにその日のうちに手を伸ばせそうなことを ToDo として追加して参加メンバーにタスクとして取っていってもらうなど促しもしました。振り返って感じますが、スピードを落とさずにハッカソン合同チームを運営する工夫もできたなという実感もありました。

また普段はあまり言わない・書かないようにしているんですが、3 日目後半くらいからメンバーになぜこのコードの方がよいか・どうしてそちらを選んだのかなどを Slack で解説し、後続するコンポーネントにメンバーが反映できるくらいには余裕のある開発ぶりでした。

Slack で Angular v15 から利用できる inject 関数について触れながらコードの書き換えを提案する様子
マウントをとっていく

メンバー間のフィードバックでより良いものへブラッシュアップするということもできています。メンバーそれぞれが「ハッカソン初日に思っていたよりめちゃくちゃ良くなってうれしい」といった気持ちでデモに臨めたのは本当によかったですね。

5 日目途中でインフラチームに許諾のないままパブリックアクセス可能な S3 バケットを作ってしまいセキュリティ警告検出の連絡を受け平謝りするなどのヘマをしてしまいましたが、5 日目の夕方にデモする直前まで改善と機能追加を続けました(もちろん作成時点で検出されているのでバケットにファイルはありませんでした)。

成果物とフィードバック

成果物のデモには、普段のプロダクトチームのディレクターを含んだディレクション部から 2 名とマーケティング部から 1 名参加してもらいました。普段からユーザーのインサイトを得るためにユーザーインタビューの接点を持ってくださったり、学校訪問時に同席していろいろ教えていただいたりとお世話になっているメンバーばかりです。

デモは私の方で画面と機能説明をさせていただき、そのあといくつかフィードバックをいただきました。以下にいくつかフィードバックを紹介します。

開発した画面を Meet で共有しながらデモをする様子
モザイクだらけですが動く画面を見せながらデモにフィードバックをもらう様子

  • 現状の〇〇画面ではたとえば「数学、数 Ⅰ、平方根」と教科や単元を掘っていくと 3, 40 個くらい候補がリストアップされてしまう。ユーザーにどう選んでもらうかは大事なので生徒の判断材料になるものが何なのかは見出して今回のアウトプットをブラッシュアップできるとよい
  • 単元が紐付いているのであれば学トレ(※ 本年度順次リリースされる学習トレーニング機能)での解答後に関連するリンクをつけるという小さな連携からスタートすることも可能そう

最初に画面を見せて「すごい!」と言ってもらえたのは素直にうれしかったです。何より単に「ハッカソンでアウトプットした」にとどまらず、フィードバック内容の吟味や今後について話す中で新しいアイデアや進め方のヒントがでてきたこと、また現実的に前に進められそうだという手応えをフィードバックの中から得られたことは、将来的なプロダクトの方針を見定めていくうえでも重要な対話になったと感じました。

まとめ

ハッカソン前に読んだ書籍だったのですが継続的デリバリーのソフトウェア工学という本の一節そして内容が、妙に今回のハッカソンとリンクします。

ソフトウェア開発は、基本的に学びと発見の分野なので、成功するためには学びのエキスパートにならなければならない。

ハッカソンという短期間のイテレーションで、実験的でかつ漸進的に実行し何よりフィードバックを受け経験主義的に積み重ねを繰り返していくことの重要性に気付かされました。また、そういった現代的なプロダクト開発の営みとしての「当たり前」を普段からできているかといった問いを投げかけられたように感じ、反省も多かったです。

今日はハッカソンとフィードバックをもらうことの重要性について書きました。
長い文章を最後までお読みいただきありがとうございます。

ChatGPTと大規模言語モデルのLT会を開きました

こんにちは、データAI部でPythonエンジニアをしている工藤 ( id:irisuinwl ) です。

最近、ChatGPT を始めとした大規模言語モデル (Large Language Model, 以降 LLM と略す) がホットですね。社会全体でLLMの議論・活用が散見されており、ますます今後重要な技術となるだろうと感じております。

私達はLLMに社会的なポテンシャルを感じ、それを活用してどのように社会を変えていけるかを検討したいと考えるため、

今回、Classi で ChatGPT と LLM の LT ( Lightning Talks ) 会の企画および開催をしました。

この記事では、LT会を通してどのようなアイデアが出たか、LT会をすることで何が分かったかを記載したいと思います。

LT会の目的

このLT会の主な目的として、LLM技術を使って社会にどのようなインパクトを与えることができるかを模索することと設定しました。

参加者は、LLMの活用アイデアを積極的に提案し、その実現可能性や制約を検討することで、LLM技術のポテンシャルをより具体的に把握することを目的としました。

ルールとしては、社外秘情報は Webで提供されている ChatGPT には送らないこととしました。

LT会の内容

LTは計10件と多くエントリーされました。

全てを紹介することは難しいので、LT会で発表された内容をピックアップして紹介します。

続きを読む

テスト自動化〜Autify編〜

こんにちは!Classi QAチームの池田です。 今回は、テストを自動化した話をご紹介したいと思います! (※弊社で使用しているテスト自動化ツールはAutifyです。)

なぜテスト自動化?

①品質の担保

弊社のQAエンジニアは、各開発チームに「専任QA」として配属されています。 私が専任QAとして所属している開発チームのプロダクト領域は「設定・登録」です。

プロダクトの中でもコアな部分であり、不具合や障害が起きればその他の機能にも影響してしまうため、とても重要な機能です。

例えば、「ID・パスワード配布/再発行」という機能があります。 「設定・登録」内でも使用率の高い機能ですが、仮にこの機能が動かなくなってしまった場合ID・パスワードの配布等ができなくなり、状況によっては多くのユーザーがログインすらできなくなってしまいます。

Classi設定・登録画面の一部

しかし、私がチームにジョインした当時は定期的なリグレッションテストが行われておらず、開発/QA側ともに既存の不具合があると認知しつつもすべてを把握してない、という不安定な状況でした。

重要な機能であるからには定期的にリグレッションテストを行い、この状況を改善する必要があると思いました。

②既存不具合の検出(=現状把握)

自動化をするにあたって「既存不具合の検出」をしたいという目的もありました。

上記にも記載した通り、この領域は不安定な状況が続いていました。 開発チームに所属しているQAの立場として、この状況は一刻も早く解消したい問題でした。 そのため、テストを自動化する過程で既存不具合を検出し、現状把握をしていきたいと考えました。

STEP1 計画

まずは自動化の計画を立てるところからスタートしました。 具体的には下記内容を計画、準備しました。

①範囲

まず本番環境の自動化を進めることにしました。

そして範囲については、「メインパスを網羅すること」を基本条件としました。(メインパスについては、公開されているプロダクトのガイド一覧に説明があるパスをメインパス、と定義しました。) 限られた時間やリソースの中でまず優先すべきは本番環境、そしてユーザーが一番通るメインパスであると判断しました。

Classiガイド一覧の一部

②テスターのアサイン

自動化するにあたって、QAチームのテスターの力を借りました。

テスターは開発チームには属さず、専任QAからの依頼ベースで動いています。 専任QAが検証でテスターを必要とした際に、QAマネージャーに手空きかの状況を確認し、一定期間テスターをキープする、という流れです。

もちろんテスターの最優先業務は検証であるため、今回私からテスターを一定期間アサインすることはせず、手の空いている際に自動化に対応していただくことになりました。 そのため直近のテスターの空き状況を確認し、どのくらい動いてもらえそうかを想定しました。

③完了期限

上記を踏まえた上で、大体の完了期限を設定しました。

約50シナリオの作成が必要となり、1日1人ほどはテスターを確保できそうでした。 1日1人で2シナリオ程度は作成可能であるため、期間を1ヶ月と設定しました。

④環境の確保、整備

弊社のプロダクトは学校(主に高等学校)に導入されており、学校単位で機能しています。 そのためQAチームも ”検証学校1"、”検証学校2”のように、本番環境にいくつか検証用の学校を所持しています。 環境についてはQAチームが所持している”学校”の中から、初期状態で1度も検証等に利用されていない"学校"を1つ借してもらいました。

また、最低限必要と思われるアカウントの作成等も行いました。

STEP2 自動化

自動化作業は想定よりもスムーズに進んだため、本番環境に加え検証環境でも自動化を進めることができ、両環境合わせて約1ヶ月半で無事完了することができました!

具体的にこの1ヶ月半での出来事を大きく4点に分けました。

①テスターの進捗管理

テスターの進捗を把握するため、作業してもらった日の終わりに進捗を報告してもらいました。

ただ、やはり難しかったのはテスターのアサイン状況の整理に関してでした。 テスターは直前でQAから検証依頼が入ることもあるため、空き状況が読めないことも多かったです。

しかし、テスターは以前からテスト自動化ツールに触れていたこともあり、私が想定していた以上にスピーディーに進めてくれました。

テスターからの進捗報告

②Weekly MTGでの進捗報告、相談

私は今回テスト自動化が初めて、且つテスターの進捗管理も初めて、と初めてづくしだったため、QAマネージャーが「Weeklyで進捗相談のMTGをしようか」と提案してくれました。

当初は同じチームのQAメンバーとQAマネージャーだけで行なっていましたが、途中からはテスターも招待してMTGを行いました。 テスターとは基本Slackでやりとりしていましたが、Slackのやりとりではなかなか出てこないような些細な事、困っている事などを話せる場があれば良いのではないかと思ったからです。

また、私自身もテスターの意見から何か良い方向に取り入れられることがあればいいな、という思いでした。

③既存不具合の検出

想定していた通り自動化の過程で既存の不具合が検知され、計4件の不具合を起票しました。

どれもクリティカルな不具合ではありませんでしたが、開発側がすぐに改修に着手してくれました。 すぐに不具合改修に対応してくれた開発側には感謝しかありません...!

不具合チケット管理画面

④改善要望チケットの起票

また、自動化の過程で改善要望チケットを2件起票しました。

改善要望チケットを起票した意図としては、正式な改修依頼ではなく、違和感のある、もしくは明らかに使いづらいUI/UXを記録に残しておきたいと思ったからです。

当時私が入社してからまだ数ヶ月だったこともあり、プロダクトへの使用感覚が新鮮だったのもあるかもしれませんが、少なくとも私の感覚ではおかしいな、と感じる挙動がいくつかありました。 QAとしてプロダクトを過信せず、こういった違和感を忘れないようにしたいと思いました。

STEP3 運用開始

当初は、自動化が完了してから運用(定期実行)を開始するつもりでしたが、開発チームから「できてるシナリオからどんどん回していけば?」と提案してもらい、自動化開始数週間目から定期実行をスタートしました!

運用についてはまた別途記事を書く予定ですのでここでは割愛させていただきます!

STEP4 振り返り

この1ヶ月半を振り返り、良かった点と反省点がありました。

良かった点:進捗報告や相談を定期的にできた

QAメンバー、テスターとの定期的なMTGで進捗報告や相談をすることができたお陰で、スムーズに進めることができたと思います。 もし定期的に相談できていなかったらアドバイスを頂いても事後となってしまい、後回しになっていた可能性もあったと思います。

MTGアジェンダの一部

反省点:環境の準備不足

一方反省点としては、環境の準備が不足していたと感じています。

開始前にログイン等に使用する必要最低限のアカウント等は準備していたのですが、作業過程で必要になる細かな設定等を把握できておらず、自動化しながら必要な設定やアカウントに気づき都度追加していく、という流れになってしまいました。

例えば、Classiに登録されている「先生」を検索し、ページネーションの確認をするというシナリオがありました。1ページに表示される「先生」の数は20人のため、ページネーションを確認するには最低21人の「先生」の登録が必要でした。 このようにシナリオで具体的にいくつのアカウントが必要になるか、という想定ができていなかったため、作業中のテスターに余計な作業を増やしてしまう結果となりました。

テスターに指示を出す側の私が、もっと事前に準備に時間を費やすべきであったと反省しています。

まとめ

私は2022年にClassiに入社したのですが、入社以前からテスト自動化に興味を持っており、今回テスト自動化に携われたことがとても嬉しかったです! (私が入社前後で感じたClassi QAチームについての記事もありますので、ぜひご覧ください。)

入社前後で感じたClassi QAチーム tech.classi.jp

自動化の作業はもちろん、テスターの進捗管理等初めて対応する業務が多く勉強になりました。 自動化を進めていく過程で、想定していなかった改善要望チケットの起票など、プラスαでできたこともあり、プロダクトに対する気づきも多かったです。

現在運用中の内容、取り組みについても今後こちらのClassi開発者ブログにて共有していきたいと思っております!

【開発者インタビュー #1】onigra

こんにちは! この度、シリーズ企画としてClassiで働く開発者のインタビューを始めます。 記念すべき第一回目は、プロダクト開発部で部長を勤めているonigraさんです。

まず簡単に自己紹介をお願いします

黒猫のアイコンでお馴染みのonigraさん

onigraです。社内ではyudaiと呼ばれています。

Classiには2019年にソフトウェアエンジニアとして入社して、2022年から開発本部のプロダクト開発部という部署で部長をやっています。 結構色々なことをやったのですが、開発者ブログに書いた内容だとEC2からECSに移行する仕事をやったりしました。

tech.classi.jp

経歴は、20代半ばまでフリーターをやっていたんですが、流れでソフトウェアエンジニアになりました。ソフトウェアエンジニアになってからは、EC、SIer、介護業界の会社に勤めていました。

社内のesa自己紹介ページに記載の経歴

ー フリーターからの流れでソフトウェアエンジニアってとても珍しい経歴ですね?

フリーターをしていた時、元上司に声をかけてもらってローンチ前のサービスのPMOになったことがソフトウェア開発に携わった始まりでした。当時お金もなくて引き受けるしかない感じでした(笑)

そしてその後サービスをリリースしたはいいものの、リリースしたら不具合でトラブルが頻発しました。目の前のトラブルを解決しないといけないけどプログラマーが足りない、トラブルを解決するにはデータベースというものを修正しないといけないらしい、データベースを修正するにはSQLという言語を使う必要があるらしい、それならSQLの書き方を調べてみよう、という感じで勉強していったのがエンジニアキャリアの始まりです。

ー なぜ自分でやるようになったんですか?

お願いして待ってるだけという状況はフラストレーションがたまるので、自分ができるようになりたいと思ったんです。それを繰り返しているうちに、色々な社内の技術スタックに触れたり学んだりするようになりました。なので最初はほぼ独学です(笑)

ー ソフトウェアエンジニアを続けることができた理由は?

純粋にプログラミングが楽しかったからですね。

自分が書いたものが考えた通りに動く、それによってサービスが回っていく、課題を解決していくことが面白かったです。達成感もあったし自分は天才なのかなって思えたりもしました(笑) 問題は大小色々あるし形も変わっていくけれど、ソフトウェアエンジニアの面白さの原点はそこにあって、今でもこの仕事を続けれるのはそういう感覚が味わえるからですね。

Classiへの入社経緯、入社理由は?

転職を考えていた時期にスカウトがあったことが最初のきっかけです。

面談で話をしていく中で、事業内容が自分の今関心があることと一致していること、自分の得意領域が活かせそうなこと、技術に対するスタンスや考え方が食い違わないこと、ビジネスモデルがしっかりしていることなどが決め手となり入社を決めました。

その他に気が合いそうなメンバーがいたことも大きいかもしれません。今のVPoTのしんぺい id:nkgt_chkonkさんのブログは元々見ていて知っていました。

ー 面談の中で特に印象に残っていることはなんですか?

各面談の中で共通で投げかけていた「競合についてはどう考えているのか?」という問いに対して、「同じ課題に立ち向かってる会社だと思っている」と理啓さん(Classi社長)が熱弁してくれたことですね。それを聞いて真摯に社会課題に向き合っている会社だなと思い、共感して入社しようと思いました。

Classiでの仕事内容を教えてください

今は開発本部、プロダクト開発部で部長をしています。元々はソフトウェアエンジニアとしてClassi内に存在するさまざまなレガシーなコンポーネントを修正する仕事をしていました。

ー ソフトウェアエンジニアとして具体的に何をやっていたんですか?

デベロッパーサクセス(組織横断的な技術課題を解決するチーム)として入社したんですが、当時のClassiにはRuby、Railsのバージョンアップという大きなミッションがありました。そういうことが課題の会社はバージョンアップ以外にも色々な課題(インフラや組織など)があることが多いので、目につく課題をひたすら解決しようという感じで仕事をしていて、気がついたら部長になってました。

ー 部長になってからはどんな仕事をしていますか?

肩書がついて役割は変わりましたが、取り組むことは基本的に「課題解決とボトルネックの解消」であり、現場のプログラマとしてやっていたことと基本的に変わってないと思っています。 対象が組織課題や経営課題になっただけで、やっていることは最適化問題なんですよね。これは、故・岩田聡氏のおっしゃっていたことに影響を受けています。

(参考: 【岩田 聡氏 追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。「ゲーマーはもっと経営者を目指すべき!」特別編

部長になろうと思ったのも、「今の会社のボトルネックはマネジメントだ」と考えていた時に部長の打診を受けたからで、課題解決するには自分がマネージャーになるのが手っ取り早いと判断したからなんですよね。 なので、部長という役割にまったくこだわりはなくて、なりたくてなったわけではないんですよ。隙あらば部長をやめたい(笑)

組織というのは、トップの人間が組織力の上限になってしまうと思っているので、自分よりも優秀な人に一刻も早く蹴落とされたいと思っています(笑)

Classiでの仕事の面白さや、やりがいについて教えてください。

学校に向けたサービスというのは、個人的に関心がある社会問題へのアプローチにつながることになり、とても可能性とやりがいがあると思っています。学校へ訪問する機会があるのも楽しいですね。

最近は部長という役割を通して仕事のステージが変わってきたことを実感しています。管理職ならではの仕事の面白さがわかってきました。

ー 学校にアプローチすることはonigraさんにとってどういう意味を持つのでしょうか?

僕は貧困問題や機会の均等に興味があるんですが、教育水準を上げることによってその問題は改善に向かうと考えています。そしてClassiは教育の中でも塾とかアドオンのものではなく、多くの人が通うであろう「学校」にアプローチしている。

それは学校に行く人なら基本的に触れるClassiがよくなれば、その子どもの将来の可能性が広げられるということだと思っています。 それはすごく可能性があることだし面白いと思っています。

ー どういう時に学校に訪問するのですか?

Classiはユーザーヒアリングで直接学校に行く機会があります。 高校生と話す機会なんて社会人になったらなかなかないので、とても新鮮な気持ちになりますし純粋に楽しいです。以前訪問させていただいた学校では生徒さんから、エンジニアになるにはどうしたらいいかを質問されたことがあったんですが、つい饒舌に答えてしまいましたね(笑)

ー 管理職の仕事の面白さややりがいとは?

取り組む課題の質が変わることによって仕事のステージが変わった実感がありますし、それは純粋に面白いですね。

経験したことのない課題に取り組むには、コンフォートゾーンを出て新しい知識を学ぶ必要があります。それは新しく言語や技術を学ぶことと変わらないので、できることが増えていく実感もありますしやりがいも感じます。今後また現場に戻った時にも役に立つことも多いと感じています。

でも、プログラミングの方が楽しいのは今でも変わりません。隙あらば管理職をやめて現場に戻りたいと思っています(笑)

Classiでの仕事の難しさや課題について教えてください。

10年近く運営されてるサービスなので、やはりレガシーなものも多いです。特に、いわゆる「分断されたモノリス」状態によるコンポーネント間を跨った機能の影響で、仕事がコンポーネント内で収まらないことも多く、職能やチームを超える振る舞いが求められることが多いです。

ー レガシーなものがあるとどんな課題があるのでしょうか?

レガシーなものの対応でいっぱいいっぱいになっていて、ビジネスを伸ばすことに注力しきれていないというのが正直なところだと思っています。

レガシーへの対応は色々あるけれど小手先で何か直せるものは終わっていて、残っているのはアプリケーションに手を入れないといけないものが多く難しい課題が多いです。これらをさっさとやっつけて、サービスを成長させるための開発をもっとたくさんできるようにしていきたいですね。個人的にはこれまで所属していた会社でも同じような仕事をやっていたこともあり、技術的には面白い仕事だと思っています。

ー 職能やチームを超える振る舞いについて詳しく教えてください

ある程度規模のあるレガシーなサービスは大体複数のコンポーネントが協調して動いていることが多く、Classiも例に漏れずそういう状態です。自分が普段触るリポジトリの修正だけでは解決できない問題も多く、チームを越境する動きが必要になっていきます。その際、他のチームのことや他のコンポーネントの知識が必要になるためなかなか難しいところだと思っています。

社内で活躍しているメンバーはチームを超えてコミュニケーションしたり、別のチームのリポジトリにプルリクを出したりすることに抵抗がないメンバーが多いと思います。

働く上で大切にしていることは何ですか?

最小限の努力で最大限の結果を出すことですね。

ー そのために具体的に何をやっていますか?

僕は自分のことを怠惰な人間だと思っています。 どうしてもプログラマという職種は作ることを求められますが、「作らずにその問題を解決する方法はないか?」を考えるようにしています。提案されたソリューションは本当にやる必要あるのか?その方法しかないのか?最善策なのか?など現状を疑うところから始めます。 そして、もっと一発逆転できるような、簡単でコスパがいい方法はないのかを常に考えています。

最後にひとこと

カジュアル面談に出ることが多いので、是非Classiに興味を持っていただけましたらお話ししましょう!


Classiでは「子どもの無限の可能性を解き放ち、学びの形を進化させる」というミッションに、ともに向き合っていただける仲間を募集しています。ご興味をお持ちの方は、 お気軽にお問い合わせください!

corp.classi.jp

© 2020 Classi Corp.