Classi開発者ブログClassi開発者ブログ教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。id:aerealです。今回はGraphQLのスキーマ管理を工夫している点について紹介します。エンドユーザ向けを含む複数のサービスから呼び出されます。内部CMSを開発するチーム内には主にサーバサイドを担当するメンバーと、主にクライアントサイドを担当するメンバーとがおり、どちらもGraphQLを用いた開発経験があります。この内部CMSはスクラッチから開発を始めており、目指すリリース予定日に対してやることは山積みなのでうまくタスクを分担したい状況にありました。時と場合によってはクライアントサイドのチームの手が空いていたりあるいは逆になったり、状況は目まぐるしく変わります。手が空いた方がスキーマの設計に手をつけられるような分業体制を整えるモチベーションが強くあります。ようにすることを狙って設計しました。この点を指してタイトルにあるように「中立的な管理」と表現しています。Clientを採用し、TypeScriptで書かれています。Generatorを使っています。サーバサイドはGoで書かれておりフレームワークの類は採用せず、標準のnet/httpのみでHTTPサーバを書いています。GraphQLのサーバサイド実装およびコード生成はgqlgenを使っています。スキーマの配置クライアントサイド・サーバサイドのどちらからも中立させるためにスキーマは独立した単体のリポジトリに配置します。簡便のため以後の文中では単に「スキーマリポジトリ」と呼びます。介してスキーマファイルを含んだNPMパッケージを配布し、スキーマを利用するリポジトリはこのNPMパッケージを利用します。後述するリリース関連のスクリプトや各種設定ファイルを除けばスキーマファイルのみが置かれています。Requestを送り、関係者のレビューを経てマージされたあと新しいNPMパッケージがリリースされます。スキーマのリリース前述の通りスキーマはNPMパッケージとして配布されます。Requestを送りマージするだけで新しいスキーマが配布されるようになっています。Registryへの公開を自動化しています。Commitsに従ったコミットメッセージを書くだけです。Commitsを内部向けリポジトリに採用することへの懐疑や批判を抱かれる読者もいるかもしれません。versioningに従うものではないということを合意しています。使う」というルールしか強制しません。いずれにせよシステムに変更を加える際には動作確認をすることを前提としているので「後方互換性を保つかどうか」といった含意を重視してないということです。Registryは対応するリポジトリ自体の公開範囲とは別にパッケージ自身の公開範囲を定義できます。許可する......といった風です。我々の内部CMSにおいてはクライアントサイド・サーバサイドそれぞれのリポジトリに読み取り権限を許可し、スキーマリポジトリに管理権限を許可しています。権限を与えると、リポジトリが読み取りを許可されているパッケージをインストールすることができます。Docsを参照してください。Actionsないし類似のCIサービスでは、より複雑かつ潜在的な危険性を孕んだ構成が求められます。Registryを採用しています。いう疑問をお持ちかもしれません。答えとしては「Goで書かれたサービスのリポジトリであってもpackage.jsonを置けば良いじゃない」というものになります。gqlgenの設定ファイルでスキーマのパスをこれに揃えておけば、問題なくコード生成もできます。サーバサイドのリポジトリを扱う際にもNodeやNPM/Yarnが必要になりますが、Classiの開発者はWebアプリケーションエンジニアですから大した支障にはなりません。Docsというドキュメントに従います。PATを使え」という設定を既述することで認可されインストールできます。PATsは対応していません。PATsは大雑把な権限付与しかできないので漏洩したり誤用した時のリスクは大きくなります。相対的にリスクはあるものの、classic/Fine-grained共にPATの利用を追跡する仕組みがGitHubにより提供されていることもあり、利用を渋るほどではないと評価して呑んでいます。PATsは若い機能で継続的に改善されているので、今後の改善に期待したいところです。PATsはセキュリティ上の懸念があるということは既に述べた通りです。PATsに対応させるしか本質的解決を望めないので座して待っています。Registryでホストされているパッケージの更新にはPATが必要です。user]のPAT管理という新たな問題も生じます。Registryの認可の仕組み上、仕方のないことではあります。Actionsワークフロー内でRenovateを実行するとこの制約を回避できます。Actionsで実行するということは、managedにせよself-hostedにせよrunnerの計算機資源を消費することになり、SaaS版と比べてクレジット消費増加やインフラコストの増加に繋がります。我々はスキーマの利用者と密にコミュニケーションできる体制なのでRenovateによる自動アップデートを諦めています。スキーマの利用規模が大きい組織ではこの問題はより深刻になるかもしれません。むすび我々が開発・運用している内部CMSで扱うGraphQLスキーマの管理・運用について紹介しました。意外と普通だなと感じましたか?実際、筆者としては特別新規性のあることはやっていないと考えています。実はこうしたワークフローの設計・整備は特にOSSではよく見られるものです。Registryなどの登場により、内部向け固有の要求を満たしつつ慣れ親しんだワークフローを実現しやすくなったと感じます。自動化されたワークフローとはワークフローがコード化されていることとほぼ同義です。ソフトウェアエンジニアにとってコード化されたソフトウェアほど雄弁な文書はないというのが持論ですが、コード化されていれば変更を提案しそれを直ちに普及させることは、素朴な慣習や自然言語によるルールより、圧倒的に省力で済むのは間違いありません。この記事で紹介したワークフローを提案し実装したのは主に筆者自身ですが、自動化されて考えることが少ないワークフローが整備されていることによって、実際に慌ただしい時にそのありがたみを感じることができました。なにより便利さと「やりすぎなさ」のバランスをとりながらワークフローを設計するのはとても楽しい時間です。エコシステムの成熟に感謝しながら、ぜひ身近なワークフローを自動化してみませんか?*1:また、今回は深く触れませんがスキーマ駆動開発の実践として、モックレスポンスの生成・利用もしておりサーバサイドの実装を待たずにクライアントサイドの実装を進める余地があったことも手伝っての判断です。16:33Tweet2023-05-26SRE留学で体感したプロダクトチームとSREチームの違い振り返りTweetこんにちは。SRE留学という社内制度を利用して、SREチームに所属しています。弊社のSRE留学制度については以下のliaob88さんの記事に詳しいので興味がある方は御覧ください。あるとき上司にSRE留学をしてみない?と提案されたのをきっかけに、自分でもできるのか?と不安を抱きながらもおもしろそうだなという感情が勝り、SRE留学を希望しました。この記事では、実際に日々の業務を行っていくなかで感じたプロダクトチームとSREチームの違いや、ソフトウェアエンジニアとSREの業務の性質の違いについてなどを挙げていきたいと思います。普段プロダクト開発に従事しているけれど、SREはどのようなことをしているのか?興味はあるけど専門知識が必要でハードルが高いのでは?といった疑問に対してなにかヒントになれば幸いです。日々の仕事の進め方は、プロダクトチームとSREチームでほぼ差異はないと言っていいでしょう。今はカンバンでタスク管理をしていて、毎朝優先度の高いものを確認し、上から順に取り組むというスタイルで進めています。月に一度タスクのリファインメントを行い、優先度の見直しも行います。隔週で振り返りを行い、2週間で起こったできごとをベースに次の2週間でトライすることを定めて、業務のカイゼンにつながるように努めています。タスクの性質SREチーム特有の性質として、各プロダクトチーム、あるいは他部署からの依頼やシステムアラートなど、リアクティブに反応するようなタスクが比較的多いということが挙げられるでしょう。各チームから依頼を受けて行う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チームの違いを列挙してみました。違いについて深堀りしていくと、そこには共通性があり、両チームは断絶されたチームというよりは地続きであるという視点が得られました。開発者インタビューTweetこんにちは!Classiで働く開発者インタビューシリーズ企画の第二弾は、プロダクト開発部の藤田さんです。簡単に自己紹介をお願いします藤田勇希と申します。仕事でもプライベートでも「ゴリラ」か「ハシビロコウ」の画像をアイコンにすることが多く、社内でも「ゴリラアイコンの人だ」というような認識をされているかもしれません。藤田さんといえばゴリラのアイコン経歴は、音楽・書籍・コミックのようなコンテンツ配信サービスのバックエンドの開発に、新卒から約5年間携わりました。その後、スペースシェアのCtoCサービスのバックエンド開発・運用を2年ほど行ってきました。2021年7月にジョインして、この4月にリリースされた「学習トレーニング」のコンセプト検証を目的とした前身サービスの開発に関わりました。これまでどんな軸で転職をしてきたのですか?それぞれの転職のタイミングで大切だと思う軸が変化しています。1社目から2社目はエンジニアとしてもっと挑戦的な立場で、スタートアップでの青春を味わいながらエンジニアとしての力量をプロダクトに直結させたい、という思いが強かったです。Classiへの転職の際は、スタートアップでの青春の卒業をし、次なるチャレンジをしたいと思っていました。あとは待遇や働く環境というところも気にしていたと思います。は?最初は転職エージェントを経由してClassiに出会いました。EdTechという難しい業界でマネタイズができている点や「学校教育」という社会貢献性が高い問題に携われることに魅力を感じて入社を決めました。ジョイントベンチャーとしての土台があってスタートダッシュができた結果、成長してきたという納得感もありました。教育に興味があったのですか?EdTechは前々から面白そうだと思っていました。勉強はもちろん大切だし今にも繋がっていますが、勉強以外にも大事なことって沢山あったなと。一度やり直して自分を変えられるとしたら教育なのでは思っています。将来の子どもたちには、私の数倍の効率で学力を得ることができて、残った時間を勉強以外にも使って有意義に過ごしてほしいなと思います。自分と同じように学生時代を後悔する人が少しでも少なくなるような教育にすることが出来たらいいなと思っています。前回のonigraさんのインタビューブログの中で機会の均等化の話があってすごく共感しました。貧富の差によって教育の優劣がつく状況を打破したいですね。Classiでの仕事内容を教えてください学習領域のプロダクトのバックエンドを中心に機能開発・運用を担当しています。ユニットリーダーとして、学習領域のエンジニアが抱えるテックイシューへの取り組み、メンバーのコーチングなども行っています。業務の割合としては、大体、9割が開発業務で、1割がユニットリーダーとしての仕事だと思います。学習領域についてもう少し具体的に教えてください。提供するサービスや機能の中でも生徒に取り組んでもらう問題コンテンツを提供する生徒の苦手・得意に応じておすすめの問題を提供する模試に向けての対策テストを提供するといったように、「学習」の体験を高めることを目的とした領域です。サービスを使って取り組めるような機能の開発などをしています。提供するこの大事な問題コンテンツを、高い品質で制作できるように支援する社内サービスの開発を行っております。ユニットリーダーとしてどんなことをやっているのですか?ユニットリーダーとしてはメンバーと1on1をしたり日々のケアをしたりしています。メンバーにはグレードが上がっていくのを支援したいと思っていて、「ちゃんとグレード上げていこう!」と日々伝えるようにしています。どんなことを意識してユニットリーダーをやっていますか?「自分が関わる人が動きやすくなるように、成長していけるように動く」ということを念頭に他者貢献に振って動くようにしています。それが結果的にチームとしてのアウトプットに繋がっていくと思っています。チームで仕事をする時に私のように動く人は必要だと思うし、そういった自分のムーブはいい方向に行っているんじゃないかなーと思っています。Classiでの仕事の面白さや、やりがいについて教えてください。プレイヤーとして非常に優秀なエンジニアの人と一緒に仕事をできること。あとは、教育現場の先生・生徒といった、ある意味コンテキストが限定されたユーザーの生の声に触れられて、フィードバックをもらいながらプロダクト改善を進められる環境があること。一緒に仕事ができてよかったと感じるエンジニアは?何人もいるのですが...まずはlacolacoさんですね。エンジニアとしてスキルが高いことはもちろんですが、それ以外のもっと抽象的な能力が高いなと感じています。課題を抽出したり物事を捉えたりが上手で、「社会人として強い」という感じです。その産物としてエンジニアリングができるという印象があります。別の領域に置かれてもすぐに色々とキャッチアップできていて、コーポレート部門の課題解決に携わっていた時もとても活躍していたので本当に流石だなと思います。優秀だと思うエンジニアと一緒に働くことで変わったことはありますか?だいぶ横暴になったと思います(笑)横暴というとあんまり表現がよくないかもしれないですが、意見をはっきり言うようになったり、意見をつっぱねたりするようになったと思います。チームメンバーが良い意味ではっきりと物事をいう人ばっかりで、「いかにシンプルに情報を正しく伝えられるか」というコミュニケーションがされていました。私はこれまでは「忙しいだろうなー」とか「伝えたらどう思うんだろう?」とか、「シンプルに情報を正しく伝える」こと以外に気を取られることが多くありました。いった思考に邪魔されてはっきりと伝えられなかった結果、アウトプットが出せない状態の方がよくないということを学びましたね。徐々にそう言った思考が入らなくなっていき、今思うと気にしすぎていてあまり意味がないものだったなーとも感じています。チームに価値を出していきたいと思っている中で、これまでになかったコミュニケーションを取り入れていって変化をしていると感じています。自分を変化させていくことに痛みを伴うと感じることもありますが、本当に良い影響だと思っていて成長を感じます。「ある意味コンテキストが限定されたユーザー」の生の声があることの面白さをもう少し教えてください!ICT化された学校を経験していないので「今ってこんな教育業界なんだ、こんな風に勉強をしているんだ」と自分の時代とのギャップが面白いです。そのギャップや学校という文化に触れることでカルチャーショックもありますが、生の声をいただきながらプロダクト改善を進められる環境があることはとても良いなと思っています。Classiでの仕事の難しさや課題について教えてください。業界の文化に慣れる必要があることだと思います。今の学校教育の抱える現状や、先生・生徒の事情の理解が必要になります。必要な点も難しさだと思います。目的を達成するために必要な衝突に臆せず向かえる強いマインドを持つことが求められます。先生の要望を伺って「印刷して紙で見たい!」というアナログなニーズがあるんです。話を聞いて実際に授業で使うことを想定して考えてみると、その場でペンで書き加えたり、その加筆したものをコピーしたりなどが求められていることがわかりました。それは「紙でやる方法に慣れている」ということでもあります。Webサービス業界の「最新のかっこいいスマートなものをつくる」と衝突して、ナウいものを作りたいエンジニアからすると「なぜ紙??」となるんです。今後はWebでやることにも慣れていけるように先生も徐々にUnlearnは必要になるとも思いますが、今はそこに向かう過渡期としてのバランスが大切だと思っています。バランスを大切にしながらしっかりとニーズを汲み取って、機能を改善してWebでできるようにしていきたいですね。「目的を達成するために必要な衝突に臆せず向かえる強いマインド」とは?ある意味どこに行っても求められるものだとは思いますが...より良いものを作りたいという目的達成の過程では、適切な衝突をする必要があると思っています。それは元々気にしいな自分にとってはなかなか難しいことでもありました。全てを受容していたら良くないことが起こってしまう可能性もあるし、考えや意見を言わないことは責任放棄になると思っています。いろいろな目線があるなかで、みんなプロダクトをよくしたいと思っているからこそ、必要な衝突をしないといけない。言った目的を達成するために必要な衝突に臆せず向かえる強いマインドや志を持つ人が活躍すると思います。Whyにこだわるようになったのですか?エンジニアがプログラムを書いて作ることは課題を解決する上でのHowの1つだと思っています。仕事は納期もあるので、工数をかけて作るということをせずに課題解決できる方法があれば最高の仕事です。自分がプログラムを書くのが楽しいと思っているからこそ余計に、その観点に気がつけず作ることに囚われてしまうこともあると思っています。「作らないと実現できない課題」のために「作る」時間を費やすことが大切だからこそ、本当に「作る」ことが正解なのかを俯瞰してみないといけないと思っています。onigraさんのインタビューブログにも出ていたエンジニアの三大美徳の怠惰の話は私も大切にしています。いつも立ち返る意味も含めてWhyを常に意識してこだわることは大切だなと感じています。そんな思いで今は頑張っていると思っています!常に全てできる訳ではないと思いますが、話したことを体現できるようにできたらと思っています環境変化を柔軟にキャッチしながら成長し続けている藤田さんでした。次回もお楽しみに!Classiでは「子どもの無限の可能性を解き放ち、学びの形を進化させる」というミッションに、ともに向き合っていただける仲間を募集しています。勉強会・イベントTweetこんにちは。本記事では先日チーム合同で行ったハッカソンと、その成果物デモをディレクターや顧客に近いマーケティングのメンバーの前で行い、フィードバックをもらうまでの話を紹介します。ハッカソンをとおして個人で獲得できた学びもありましたしチームやほかのメンバーとの協働がよりよくなりました。何よりスピード感のあるアウトプットに対してフィードバックをすぐもらうことの大切さを痛感したので、そんなことも踏まえながらお伝えできればと思います。きっかけ今回ハッカソンを実施するに至った経緯はいくつかあります。以下のような提案があった私は二つ返事でやりたいと伝えました。担当プロダクトの負の部分から脱却するためにデモアプリで実証したいことはありましたし、守りのプロダクト開発が最近は多かったので個人としてもハッカソンに取りかかりたいという思いがありました。営業日使って行いました。普段担当するプロダクトもあるので、アラートや問い合わせがあった場合は普段のプロダクトを優先するという約束です。出してくれたマネージャーには感謝ですね。名ですが、先にも触れたとおり、平時の運用やアラートを並行しながら「ガッと」やるにはパワーが不足してしまうという懸念がありました。名のエンジニア体制で取り組むことにしました。「何かを丁寧に教える場にせず自律的にやれることをどんどん見つけていってほしい」といったマネージャーの言葉を強く意識し、特に「丁寧に教える場にしない」ということを徹底しました。諸説ある)主体的に教えに行ったりするのはやめておこうと開始前から意識しています。初日に最終日の勝利条件を決める正直初日まで何かを準備するということはしませんでした。チャンネルと空のリポジトリ準備だけをして初日を迎えています。初日にまずハッカソンで取り組んで作り上げたい成果物のイメージをマネージャーが説明しました。それが検証すべき機能たりえるのか、取り組むモチベーションは何なのか、ユーザーのターゲット層はどこなのか、それらのイメージを元にエンジニアが作り始めるにあたって前提となるアラインメントを行っていきます。使ったアプリケーションで、それを最終日にはデモできる状態にする」といった勝利条件をその場で決定しています。名のエンジニアで今日の勝利条件を決めていきます。日目以降は私が毎朝デイリーで前日のタスク進捗と今日の勝利条件を確認する形で進行していきました。同期的に話す時間は朝のデイリーの時間だけで、あとは必要なタイミングで突発的に同期的に話す時間を作りました。取り組んでいき、アプリケーションがローカルである程度うごく様が見れるようになったタイミングで壁にぶち当たりました。我々が実現したいことにマッチしないとわかりました。それでも誰もうなだれるようなことはなかった気がします。アイデアの段階では「こうすれば目的が達成できる思う」にすぎません。プロトタイプを作ってみると思った通りになりません。これによって、そのアイデアの改善すべきところが見えるようになります。見えれば、さらに改善できます。チャンネルにはありました。ハッカソン参加メンバーがその日のうちに代替となるようなプラットフォームを試したり、次のステップへ進むという動きを見せたりしていたのは、前向きで健全だなとも思いますし驚きでもありました。メンバーの振る舞いハッカソンを通して特徴的だと感じたのは、参加メンバーの振る舞いが自主的でありながらさまざまなバリエーションがあったことです。日以降に固まっていたと感じます。アプリケーションを率先してガリガリ進めるアプリケーションのレールで実直に画面を作っていく実現可能性が不明な問題の可否について調査をしつくす必要だなを思われることを先回りして調べておく平時活動をともにしているわけではないお隣のチームではありましたが、あまり接点を持たなかったにもかかわらず、短期間でお互いの特性を認知しあえたのはハッカソンだけに限らず平時にも役立てられる旨味でした。ハッカソン中も、普段の担当プロダクトに来るお問い合わせやアラート対応もしていましたし、お隣のチームメンバーはライブラリアップデートのリリースまで済ませていました。いったことも踏まえると、ハッカソンを始める前に「パワーが不足していた」と感じていたことさえも疑うべきだったのかもしれないと感じます。日目の夕方頃にはコミットされていくコードを眺めて改善を考えるくらいには落ち着いた状態になっていました。日目にはガリガリ画面を作ってブラッシュアップや改善をしながら機能を足していきました。形ができていく喜びと実装している楽しさが相まるとテンションも高まります。雑な画面設計を書いて共有を始めています。して追加して参加メンバーにタスクとして取っていってもらうなど促しもしました。振り返って感じますが、スピードを落とさずにハッカソン合同チームを運営する工夫もできたなという実感もありました。解説し、後続するコンポーネントにメンバーが反映できるくらいには余裕のある開発ぶりでした。マウントをとっていくメンバー間のフィードバックでより良いものへブラッシュアップするということもできています。メンバーそれぞれが「ハッカソン初日に思っていたよりめちゃくちゃ良くなってうれしい」といった気持ちでデモに臨めたのは本当によかったですね。日目の夕方にデモする直前まで改善と機能追加を続けました(もちろん作成時点で検出されているのでバケットにファイルはありませんでした)。名参加してもらいました。普段からユーザーのインサイトを得るためにユーザーインタビューの接点を持ってくださったり、学校訪問時に同席していろいろ教えていただいたりとお世話になっているメンバーばかりです。デモは私の方で画面と機能説明をさせていただき、そのあといくつかフィードバックをいただきました。以下にいくつかフィードバックを紹介します。個くらい候補がリストアップされてしまう。本年度順次リリースされる学習トレーニング機能)での解答後に関連するリンクをつけるという小さな連携からスタートすることも可能そう最初に画面を見せて「すごい!」と言ってもらえたのは素直にうれしかったです。何より単に「ハッカソンでアウトプットした」にとどまらず、フィードバック内容の吟味や今後について話す中で新しいアイデアや進め方のヒントがでてきたこと、また現実的に前に進められそうだという手応えをフィードバックの中から得られたことは、将来的なプロダクトの方針を見定めていくうえでも重要な対話になったと感じました。まとめハッカソン前に読んだ書籍だったのですが継続的デリバリーのソフトウェア工学という本の一節そして内容が、妙に今回のハッカソンとリンクします。ソフトウェア開発は、基本的に学びと発見の分野なので、成功するためには学びのエキスパートにならなければならない。ハッカソンという短期間のイテレーションで、実験的でかつ漸進的に実行し何よりフィードバックを受け経験主義的に積み重ねを繰り返していくことの重要性に気付かされました。いった現代的なプロダクト開発の営みとしての「当たり前」を普段からできているかといった問いを投げかけられたように感じ、反省も多かったです。今日はハッカソンとフィードバックをもらうことの重要性について書きました。長い文章を最後までお読みいただきありがとうございます。