KINTOテクノロゞヌズのブログ - TECH PLAY

TECH PLAY

KINTOテクノロゞヌズ

KINTOテクノロゞヌズ の技術ブログ

å…š1132ä»¶

はじめに グロヌバル開発グルヌプのWuです。普段Web/Portalのプロゞェクトマネヌゞメントの仕事をしおいたす。 最近ボクシングゞムにたた通い始めたした。筋トレずダむ゚ットを頑匵っおいきたいです 私たち開発しおいるWebサむトにMicrosoftのClarityずいうヒヌトマップツヌルを導入したので、そちらに぀いおお話したす。 導入背景 モビリティサヌビスKINTOのグロヌバル展開を玹介する Global KINTO Web では、ナヌザヌのペヌゞ滞圚時間が短かったり、盎垰率が高いなどの課題を抱えおいたす。Googleアナリティクスのむベントでスクロヌル率やクリック率を数倀でチェックしおいたすが、ナヌザヌの行動、ナヌザヌの興味関心はどこにあるのかはGoogleアナリティクスだけではわかりたせん。 そこで、ナヌザヌの行動をチェックし、簡単に課題を発芋できるような分析ツヌルを導入するこずになりたした。 Microsoft Clarityを遞んだ理由 前述の通り、Global KINTO Webは珟時点では比范的小芏暡なWebサむトで、たた、サヌビスサむトではありたせん。その費甚察効果を考えるず、できるだけ安䟡でか぀簡単に導入できるヒヌトマップツヌルである必芁がありたした。 人気ツヌルUser Heat, ミ゚ルカヒヌトマップ、mouseflow、User Insightなどのツヌルを怜蚎したしたが、その䞭でもClarityを遞定した理由は耇数ありたす。 たず、KINTOテクノロゞヌズがすでに導入しおいるMicrosoftが提䟛しおいるこず、そしお完党に無料であるこず、たた、チヌムメンバヌに暩限を付䞎しおチヌムで運甚するこずもできるこず。たた、セットアップも簡単で、導入たで゚ンゞニアの工数がほがかからないのも魅力でした。 人気ツヌルの比范衚 ツヌル 機胜 導入方法 プラむス Microsoft Clarity ・むンスタントヒヌトマップナヌザヌがどこクリックしたか、どのぐらいスクロヌルしたか ・セッションのレコヌディング可胜←かなり䜿える ・レコヌディング ・Google Analytics連携 Clarityがが提䟛しおいるHTMLタグをりェブサむトに埋め蟌む 無料 User Heat ・マりスフロヌヒヌトマップ ・スクロヌルヒヌトマップ ・クリックヒヌトマップ ・アテンションヒヌトマップ User Heatがが提䟛しおいるHTMLタグをりェブサむトに埋め蟌む 無料 ミ゚ルカヒヌトマップ ・3぀のヒヌトマップ機胜 ・広告分析機胜 ・むベントセグメント機胜 ・ABテスト機胜 ・IP陀倖機胜 ・カスタマヌ゚クスペリ゚ンス改善チャヌト ・フリヌプラン3,000PV/月 ・有料プランはABテストなど䜿えるのでオプション性 mouseflow ・基本は䞊蚘の機胜があるが、ファネルの蚭定、コンバヌゞョンナヌザヌの分析など充実 ・レコヌディング機胜 ・フォヌムの分析機胜入力時間、送信数、離脱数など现かいみれる mouseflowのトラッキングコヌドを゚ントランスりェブに埋め蟌む Starterプラン11,000/月〜゚ンタヌプラむズプラン Microsoft Clarityずは 2020幎10月29日リリヌスされた、Microsoftが提䟛する無料のヒヌトマップツヌルです。公匏サむトより䞋蚘のずおり玹介されおいたす。 セッション再生やヒヌトマップなどの機胜を䜿甚しお、ナヌザヌの Web サむトずの察話方法を解釈できるようになるナヌザヌ行動分析ツヌルです。 Microsoft Clarity セットアップ Clarityで新しいProjectを䜜成したす Clarityのトラッキングコヌドをペヌゞ内のheaderの芁玠に貌り付けたす Googleアナリティクスを連携したす Dashboard Dash boardはデッドクリックDead click、クむックバックQuick Back、むラむラしたクリックRage clicks、過剰なスクロヌルExcessive scrollingなどの分析ずいったようにサむトの状況がわかりやすく独自の項目がダッシュボヌド化されおいたす。 デッドクリックDead click ナヌザヌがペヌゞ内のどこかをクリックたたはタップしたけれど、応答が怜出されなかったずいう意味です。 Dead Clicks ナヌザヌがどこをクリックしたのかがわかりたす。たた、動画でナヌザヌの動きを蚘録しおいるのでわかりやすいです。 Global KINTO Web の堎合、各サヌビスを玹介するパネルがよくクリックされ、ナヌザヌがより詳现な情報を求めおいるこずが掚枬できたす。 クむックバックQuick Back ナヌザヌがペヌゞを衚瀺した埌、前のペヌゞに玠早く戻ったずいう意味です。ナヌザヌがWebにアクセスした際、タヌゲットではないペヌゞず刀断したらすぐに前のペヌゞに戻っおしたう、たたは誀っおクリックしおアクセスしおしたったケヌスもありたす。どの郚分が利䟿性の䜎いナビゲヌションになっおいるか、たた、誀っおクリックされやすいかがわかりたす。 Quick Back むラむラしたクリックRage clicks ナヌザヌが同じ領域を䜕床もクリックたたはタップしたずいう意味です。 Rage Clicks Global KINTO Webの堎合、通信速床が遅いなどの原因でリンク集をひたすらクリックしおいるナヌザヌが耇数人がいたした。確認するず、同じOSのナヌザヌにこの事象が発生しおいるこずがわかったので、端末怜蚌に繋がりたした。 過剰なスクロヌルExcessive scrolling ナヌザヌが想定以䞊にペヌゞをスクロヌルしたずいう意味です。ナヌザヌがペヌゞ内のコンテンツをしっかり読んでいない割合がわかる指暙です。 Excessive scrolling ヒヌトマップ クリックヒヌトマップClick Heatmap ナヌザヌがペヌゞ内のどこを䜕回クリックしたかがわかりたす。巊偎のメニュヌにクリックされおいる箇所が倚い順でランキングしおいたす。 Click maps スクロヌルヒヌトマップScroll Heatmap ナヌザヌがペヌゞをどこたで芋おるかがわかりたす。赀い郚分は最も読たれおいる箇所から、色がオレンゞ、緑、青に芋られおる割合の少ない順に倉わりたす。 Scroll maps 領域ヒヌトマップClick Area Heatmap 領域ヒヌトマップはクリックヒヌトマップずほが同じ機胜しおいたすが、広い゚リアでクリックされおいる箇所が確認するこずができたす。ペヌゞ内に配眮されおいるコンテンツが読たれおるかはわかりたす。 Area maps レコヌディング ナヌザヌのリアルな行動が蚘録されたす。マりスのカヌ゜ルの䜍眮、ペヌゞのスクロヌル、ペヌゞの遷移、クリックの動きを動画から確認できたす。 たた、端末の情報、地域、クリック数ず芳芧したペヌゞ数、終了のペヌゞ情報も巊偎メニュヌから確認できたす。 ナヌザヌの䞀連の行動履歎を動画でリアルに芋れるのはClarityの䞀番の魅力かもしれたせん。 Recordings overview 最埌に Global KINTO Web はただただ発展途䞊で、改善の䜙地があるWebサむトです。今回、ヒヌトマップの導入を決めおから、Clarityのクオリティずその導入の簡単さから、玄半月0.5人月でリリヌスするこずができたした。珟時点でフル掻甚できおいるわけではないですが、今埌はこのツヌルをベヌスに、よりよいナヌザヌ䜓隓を提䟛すべく動いおいきたいず思いたす。
A sequel article has been posted 🥳🎉 (June 8, 2023): [Sequel! Dev Container] Creating a cloud development environment with GitHub Codespaces . Introduction Hello. Torii here, from the team[^1][^2] Common Services Development Group that develops payment platforms used by multiple services. Finding your IDE doesn't work even though you created it according to the procedure manual; having to check how different-version SDKs work and install them separately for each product; and so on... I suspect a lot of people reading this article have experienced woes like these when creating a local development environment. Creating a local development environment is one of the more tedious tasks that can befall new product development members. In this article, I want to share an example of how Visual Studio Code (from here on, VS Code)'s Dev Container was used to create a development environment, simplify it, and make it the standard one. What is VS Code's Dev Container? A Dev Container environment is a development environment created using the VS Code Dev Containers extension. You can use it if both VS Code and Docker are available. (Windows / Mac / Linux.) As the following figure shows, launching Dev Container lets you use a Docker container as a full-featured development environment from within VS Code. Mount the source code from the host machine, and the VS Code extension will get installed inside the container. That means there's no need to consider conflicts with the libraries that are already installed. For example, when developing on the host machine, if the specified version of node.js for another project is different, you might need to manage the version of node.js with n package and — depending on the situation — possibly switch versions. Cited from Developing inside a Container The details for the Dev Container environment (the VS Code settings, extensions, libraries to install, services to start, etc.) can be defined in devcontainer.json , Dockerfile , and docker-compose.yml . The Dev Container environment will be built automatically using these settings, making things vastly simpler than installing everything separately. The environment creation procedure document also only goes up to building the Dev Container. There's also no need to consider OS differences when multiple people are doing the development work. Procedure for creating a Dev Container environment In this example, we want to create a new React app using Create React App . Environment used PC: Surface Laptop 4 Windows 10: 21H2 (WSL2) WSL2: Ubuntu 20.04 VS Code: 1.73.0 Prerequisites VS Code is installed. Docker is installed (on WSL2 if using Windows). Docker Desktop for Windows/Mac is installed. 1. Install the Dev Containers extension First, open VS Code in the directory you want to use as the workspace. Next, install the Dev Containers VS Code extension. Remote Development (which includes Dev Containers ) is also okay. 2. Start setup with Reopen in Container Click the icon at the bottom left and select Reopen in Container from the menu at the top of the screen. (Create Dev Container will create the Dev Container in another directory.) 3. Select the settings for the Dev Container environment you want to create In this example, we chose Ubuntu. 4. Select the version of the Docker container image 5. Select the features you want to add In this example, we chose Node.js (via NVM) and yarn , which are required to create a React app. Select the features you want to add and click 🆗 to start building the Dev Container. 6. Dev Container build complete When the build is complete, the VS Code connected to the Dev Container will launch automatically. You'll see that a file .devcontainer/devcontainer.json has been created, and Dev Container is shown in the bottom left. (Previously, .devcontainer/Dockerfile also used to be created.) Open the terminal in VS Code ( ctrl + shift + @ ) and run the following command, and you'll see that the required libraries have been installed. console $ node -v v18.12.1 $ yarn -v 1.22.19 Next, run Create React App . console $ npx create-react-app typesript A prompt will appear, showing that you can go ahead and create it as is. (Creating the React app and confirming that it launches aren't the main topic, so I'll skip them.) How do you like that? If you've ever manually installed node.js , yarn , and create-react-app , I think you'll see how much simpler this way is. Next, let’s build the Dev Container environment that we created in this example. Building an existing Dev Container environment Prerequisites The prerequisites are the same as for creating the environment. VS Code is installed. Docker is installed (on WSL2 if using Windows). Docker Desktop for Windows/Mac is installed. 1. Open the Dev Container workspace on the host machine First, open the workspace you created earlier in VS Code on the host machine. Note: If the Dev Containers extension isn't installed If the Dev Containers extension isn't installed, please install it in the recommended way shown in the following figure. 2. Select Reopen in Container If the Dev Containers extension is already installed, a configuration file for the Dev Container like in the following figure will exist, so you'll be asked if you want to reopen in the Dev Container. Select Reopen in Container , and building the Dev Container will start. 2. Environment creation complete! With that, you're all done building the pre-created Dev Container environment. From now on, you can also launch it by selecting Reopen in Container in the same manner. In Windows, you can also open it directly from the taskbar's VS Code context menu, as shown below. A command like the one below is necessary when completing creation for launching the React app, but we'll discuss the setup for it later. console // node.js package installation $ yarn install You can create the pre-created environment this way in very few steps. Sample devcontainer.json Next, I'll show you an example of my own Dev Container setup. The VS Code settings and extensions define a linter, formatter, and so on. There are also settings for other development support functions, so please do check it out if you're interested. json { // Set the Dev Container's name "name": "test-devcontainer", // Specify the container launch options // --name Specify the name of the Docker container to build // If this isn't specified, generate it randomly "runArgs": ["--name=test-devcontainer"], // Docker container image "image": "mcr.microsoft.com/devcontainers/base:jammy", // VS Code settings "settings": { "stylelint.validate": ["css", "scss"], "scss.validate": false, "css.validate": false, "editor.formatOnSave": true, "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.codeActionsOnSave": { "source.fixAll.eslint": true, "source.fixAll.stylelint": true }, // sticky scroll settings "editor.stickyScroll.enabled": true, "editor.stickyScroll.maxLineCount": 5, "workbench.colorCustomizations": { "editorStickyScroll.background": "#00708D", "editorStickyScrollHover.background": "#59A2B5" }, // Settings to import with absolute path in typescript "typescript.preferences.importModuleSpecifier": "non-relative" }, // VS Code extensions to add "extensions": [ "ms-vscode.live-server", "dbaeumer.vscode-eslint", "stylelint.vscode-stylelint", "Syler.sass-indented", "esbenp.prettier-vscode", "ms-python.python", "streetsidesoftware.code-spell-checker", "naumovs.color-highlight", "burkeholland.simple-react-snippets", "formulahendry.auto-rename-tag", "MariusAlchimavicius.json-to-ts", "dsznajder.es7-react-js-snippets", "styled-components.vscode-styled-components", "Gruntfuggly.todo-tree", "42Crunch.vscode-openapi", "mhutchie.git-graph" ], // Settings (recommended) for users running it in the container "remoteUser": "vscode", // Libraries to install "features": { "ghcr.io/devcontainers/features/node:1": { "version": "lts" }, "ghcr.io/devcontainers/features/python:1": { "version": "3.9" } }, // Commands to run when the Dev Container is created "postCreateCommand": "sh .devcontainer/post-create.sh" } If you didn't run yarn install separately in the pre-created environment above, you can get it done automatically when the environment is created, by defining it with the postCreateCommand option. Personally, I create a separate script and run the sequence of commands required after the container has been created. .devcontainer/post-create.sh # Adding supplementary git bash commands echo 'source /usr/share/bash-completion/completions/git' >> ~/.bashrc # Settings to pass through the yarn global path echo 'export PATH="$HOME/.yarn/bin:$PATH"' >> ~/.bashrc # Installing openapi-generator-cli yarn global add @openapitools/openapi-generator-cli yarn install ``` ## Perceived pros and cons of adopting it The following are what I felt to be pros and cons when doing development in the Dev Container environment. ### Pros - It's easy to simplify the environment creation procedure. - You don't have to worry about the host machine's OS when working with multiple developers. - You don't' need to follow a different procedure for each library and package. - For backend work, it makes heavy use of MySQL and Redis, so it offers even more power. - Environment creation can be declaratively defined and standardized, so it won't vary from person to person. - You can also define VS Code settings and extensions. - You won't run into unexpected bugs due to version differences. - It won't contaminate the local environment, or conflict with other workspaces. ### Cons - It can't meet the needs of people who want to use a different IDE from VS Code. - You can't use your preferred terminal. - It requires fairly high system specs. - It's tricky to use while sharing your screen with Zoom. - Using WSL2 with Windows is rather heavy. - The Mac version has issues with file I/O. - These can apparently be resolved by setting up a named volume for `devcontainer.json`[^3]. ## Conclusion What did you think? I hope you got an idea of how handy Dev Container is. I remember having to pick through a long procedure document to create environments in the past, so I think it’s gotten much easier now. Also, I really got a sense of how useful Dev Container is when we actually invited members from other product development teams to join us as guests for some mob programming, and they were able to get it up and running immediately. For my next trial-and-error experiments, I want to try the following: - Tuning Dev Container's performance, referring to the official article. - Putting Docker on Amazon EC2, and using Dev Container via [ Remote Development using SSH](https://code.visualstudio.com/docs/remote/ssh). - Doing development using IntelliJ IDEA's [Remote Development](https://pleiades.io/help/idea/remote-development-starting-page.html#start_from_IDE). - Creating environments on [GitHub Codespaces ](https://github.co.jp/features/codespaces). [^1]: Other Payment Platform Initiatives Part 1. [[About how we incorporated Domain-Driven Design (DDD) into payment platforms, with a view toward global expansion as well](https://blog.kinto-technologies.com/posts/2022_08_30_start_ddd/).] [^2]: Other Payment Platform Initiatives Part 2. [[About how a team of people who'd all been with the company for less than a year successfully developed a new system through remote mob programming](https://blog.kinto-technologies.com/posts/2022-12-06-RemoteMobProgramming/).] [^3]: [ Official article: Improve container performance](https://code.visualstudio.com/remote/advancedcontainers/improve-performance).
Hello, p2sk from the KINTO Technologies DBRE team here. In the DBRE (Database Reliability Engineering) team, we work cross-functionally to solve challenges such as solving database-related issues and creating agile platforms that foster well-balanced governance within the organization. DBRE is a relatively new concept, so very few companies have a dedicated organization to address. Even among those, that do often focus on different aspects of it and take different approaches from one another. This makes DBRE an exceptionally captivating field that continues to evolve and develop. For some great examples of KINTO Technologies’ DBRE activities, check out (@_awache) 's AWS Summit presentation from this year and Tech Blog article about working toward making the DBRE guardrail concept a reality . In this article, I’m going delve into our database problem solving case files and share the details of our investigation into an intriguing issue. We encountered a peculiar situation where Aurora MySQL returned an "Empty set" in response to a SELECT query, despite the presence of corresponding records. The issue We had an inquiry from a product developer about some strange behavior they were experiencing when certain queries were sent from the jump server to the database. The database they were using was Aurora MySQL 2.07.2 (MySQL 5.7.12), and their MySQL client version was 5.7.38 for Linux (x86_64). Below, you can find an image they shared with us at that time, illustrating the observed behavior. As the image shows, even for a table with some records in it, running the query select * from t1; to retrieve all the records produces the response Empty set . In addition, running another query immediately after that results in ERROR 2013 (HY000): Lost connection to MySQL server during query . Then, that’s followed by ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... From then on, the system will be stuck in a loop of Empty set , ERROR 2013 , and ERROR 2006 , as the image below shows. Meanwhile, the query select * from t1 limit 1; returns 1 record as expected. At this point, we had no idea what could be causing the issue, or how we could reproduce it in a different environment. Fortunately, the anomalous behavior was observed in multiple tables, providing us with an opportunity to investigate its reproducibility and explore potential resolutions under various conditions. Investigating the issue Reproducibility Despite the fact that the data (including all records and columns) to be retrieved was identical to the query that triggered the issue, all subsequent queries returned results without any problems: select c1, c2 from t1; -- Specify all columns. SELECT * FROM t1; -- Run the query with the reserved words all capitalized. Select * from t1; -- Run the query with only the first letter capitalized. We also confirmed the following: The problem can be replicated when using the writer instance but not when using the reader one. Even when using the writer instance, the issue is reproduced for certain tables within the same database, but not others. It will not be reproduced if the MySQL client is changed to a client belonging to the 8.0 family There appear to be no particular peculiarities or abnormalities related to the columns in the tables or the data itself. Resolvability Next, we investigated whether changing the data or metadata could resolve the issue. Our findings were as follows: Running “analyze table” on tables that reproduced the issue didn’t resolve it. If we created a new table and imported the same data into it from a dump file, the issue was resolved. Doing the following resolved the issue: create dump files of the tables that reproduce it, then create new tables with the same names using DROP & CREATE, and import the data into them from the dump files. The issue was resolved if we deleted all the records from the tables that reproduced it, then imported the same data into them from a dump file. Isolating the causes in light of Aurora’s architecture In our investigations thus far, the fact that recreating the tables resolved the issue suggested there was a problem with the data, while the fact that switching to an 8.0-family MySQL client resolved it suggested that there wasn’t. So, we checked Aurora’s architecture once again. This official AWS document showed us the following: Aurora’s compute and storage layers are completely separate. The writer and reader instances both reference the same cluster volume. The image cited below shows this in a very easy-to-understand way. — Source: Overview of Amazon Aurora’s architecture In light of this architecture, we created an Aurora clone and used it to check reproducibility, so as to identify whether the issue was related to the compute layer or the storage one. Even when you create a clone, the data doesn’t get copied. Instead, the clone continues to reference the same storage data as the original. As shown in the figure below, new data is only created when data is updated in one of the clusters, but there won’t be any changes in the storage layer unless an update is made. — Source: How Aurora clones are created Connecting to the newly created clone and running the query reproduced the issue, so we concluded that the storage layer probably wasn’t involved. This conclusion was also supported by fact that the issue could be reproduced with the writer instance but not the reader one. Based on this, we inferred that the issue had something to do with Aurora’s compute layer. Thinking it might be related to some kind of data held by the compute layer, we checked the architectural diagrams again. This led us to suspect that the cache management system might be involved. Running the following query to see what the current settings were, we found that the query cache was enabled. select @@session.query_cache_type; Next, we checked to see if the issue was reproduced with the query cache disabled at the session level, as shown below. set session query\_cache\_type = 1; -- Query cache ON. select @@session.query\_cache\_type; -- Check. SELECT * FROM t1; -- Wasn’t reproduced. select * from t1; -- Was reproduced. set session query\_cache\_type = 0; -- Query cache OFF. select @@session.query\_cache\_type; -- Check. SELECT * FROM t1; -- Wasn’t reproduced. select * from t1; -- Wasn’t reproduced (!) This confirmed that disabling the query cache stopped the issue. The query cache has been removed in MySQL 8.0, so this also clears up why the issue wasn’t reproduced with an 8.0-family client. Also, running RESET on the query cache stopped the issue from occurring even when the latter was enabled. Incidentally, if FLUSH QUERY CACHE was run, the issue continued. This suggested that the cache needed to be deleted with RESET. set session query_cache_type = 1; -- Query cache ON. select @@session.query_cache_type; -- Check. RESET QUERY CACHE; -- Reset the query cache. SELECT * FROM t1; -- Wasn’t reproduced. select * from t1; -- Wasn’t reproduced. These results showed that the issue was related to the query cache. Investigating similar examples Having thus narrowed down the cause, we investigated whether any similar cases had been reported, and came across this bug report. As its title suggests, it says that errors occur if 2 versions of the MySQL client try to access each other’s caches. We tried to reproduce the issue based on this report, and succeeded with versions 5.6.35 and 5.7.38. If you’re interested in trying it yourself, the procedure is outlined in the appendix. (Version 5.7.41 is used in the appendix, but the issue will still be reproduced.) We asked the inquirers about whether different versions of the MySQL client might have been used, they told us that the issue had started when they’d created a new jump server. We didn’t know which MySQL client they’d used with their previous jump server so we couldn’t be sure, but the inquirers’ issue matched what was in the bug report. So, we concluded that the issue was very likely happening because select * from t1 queries were being executed and cached by different MySQL clients, leading to an error. Considering countermeasures The easiest way to resolve the issue if it occurs is to run RESET QUERY CACHE , but we also looked into ways to prevent it in the first place. We tried updating Aurora MySQL from version 2.07.2 to a newer one to see if that would resolve it. The issue continued with the latest patch version of the 2.07.x release, version 2.07.9. However, when we also updated to a minor version and tried some 2.11.x ones, the issue stopped with both version 2.11.1 and version 2.11.2. This minor-version update may have included some kind of fix for the query cache. So, it looks like updating Aurora to a 2.11.x version might be a good way to prevent the issue. Summary In this article, I’ve illustrated our DBRE activities with an example from our database problem solving case files in which we investigated a strange issue where Aurora MySQL returned “Empty set” in response to SELECT even though corresponding records existed. The cause was a bug in MySQL that meant that erroneous results were given when different MySQL client versions sent the same query to Aurora MySQL 2.07.x with the query cache enabled. The easiest way to resolve it is to run RESET QUERY CACHE (although you do need to bear in mind that the performance will temporarily drop). We didn’t observe the issue with Aurora 2.11.x, so the best option might be to upgrade Aurora to a newer version. Alternatively, with support for Aurora version 2.x due to end on October 31, 2024, upgrading to Aurora version 3 early might also be a good idea. It’s a pretty rare case in the first place so it might not warrant much attention anyway, but all the same, I do hope this article proves to be a useful reference for some readers. We couldn’t have done the investigation without lots of help from lots of people, so thank you everyone! KINTO テクノロゞヌズ DBRE チヌムでは䞀緒に働いおくれる仲間を絶賛募集䞭ですカゞュアルな面談も歓迎ですので、 少しでも興味を持っおいただけた方はお気軜に Twitter DM 等でご連絡ください。䜵せお、 匊瀟の採甚 Twitter もよろしければフォロヌお願いしたす Appendix: Reproduction procedure We’ve confirmed that the reproduction procedure will work on a jump server whose OS is Amazon Linux 2. It also assumes that a 2.07.x version of Aurora MySQL is used. (We haven’t confirmed whether the issue is reproduced with all patch versions, but have at least confirmed that it is with the latest one, 2.07.9.) First, connect to the jump server and install the MySQL 5.6 client (5.6.35). sudo mkdir -pvm 2755 /usr/local/mysql-clients-56; sudo curl -LO https://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.35-linux-glibc2.5-x86_64.tar.gz; sudo tar -zxvf mysql-5.6.35-linux-glibc2.5-x86_64.tar.gz -C /usr/local/mysql-clients-56/; cd /usr/local/mysql-clients-56/; sudo mv -v mysql-5.6.35-linux-glibc2.5-x86_64 mysql56; sudo ln -s /usr/local/mysql-clients-56/mysql56/bin/mysql /usr/local/bin/mysql56 Next, install the MySQL 5.7 client (5.7.41). sudo mkdir -pvm 2755 /usr/local/mysql-clients-57; sudo curl -LO https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.41-linux-glibc2.12-x86_64.tar.gz; sudo tar -zxvf mysql-5.7.41-linux-glibc2.12-x86_64.tar.gz -C /usr/local/mysql-clients-57/; cd /usr/local/mysql-clients-57/; sudo mv -v mysql-5.7.41-linux-glibc2.12-x86_64 mysql57; sudo ln -s /usr/local/mysql-clients-57/mysql57/bin/mysql /usr/local/bin/mysql57 Connect to the database with MySQL56. mysql56 -h xxx -u xxx -p Create a sample database and a sample table, and INSERT the data. create database d1; use d1; create table t1 (c1 int, c2 int); insert into t1 (c1, c2) values (1, 1); insert into t1 (c1, c2) values (2, 2); insert into t1 (c1, c2) values (3, 3); Enable the query cache at the session level, and set it so that queries will be issued and cached. set session query_cache_type = 1; select * from t1; Next, connect to the same jump server from a different window, then connect to the database with MySQL57. mysql57 -h xxx -u xxx -p Enable the query cache at the session level. use d1; set session query_cache_type = 1; If you run a query that differs from the one from MySQL56 by 1 character, it returns the data successfully. Select * from t1; If you run the same query as the one from MySQL56, it returns Empty set . select * from t1; This procedure enabled us to reproduce the issue. To resolve it, reset the query cache. RESET QUERY CACHE;
はじめに こんにちはKINTOテクノロゞヌズの勉匷䌚事務局スタッフです。 先日、「 KINTOテクノロゞヌズ MeetUp情シスによる情シスのための事䟋シェア4遞 」ずいうタむトルで「コヌポレヌトIT領域に特化した、事䟋発衚座談䌚圢匏の勉匷䌚」を開催したした。 開催に先立ち、「勉匷䌚の䌁画事務局立ち䞊げ」たでのストヌリヌを「 はじめおの「KINTOテクノロゞヌズ MeetUp」が開催されるたで 」ずいう蚘事でご玹介したした。 今回は、その続線ずなる「開催に至るたでの、事務局掻動のあれこれ」をご玹介しおいきたす。 前回に匕き続き、「自瀟でれロから勉匷䌚を立ち䞊げ、掚進しおいきたい」ず考えおいる方のご参考になれば幞いです。 前回の蚘事では、䞻に 勉匷䌚の䌁画立案 事務局メンバヌ・登壇者の募集 未怜蚎事項のディスカッションを実斜 圹割分担ず、アゞャむルな進行管理を開始した ずいった内容たでを蚘茉しおいたした。 ここからは、「具䜓的にどのような圹割分担があったのか」「それぞれどのような掻動をおこなったのか」ずいった内容を掘り䞋げおいきたいず思いたす。 経営局ぞの事前報告 今回の勉匷䌚は「個人や有志」ではなく「䌚瀟の掻動」ずしお実斜するものずなりたす。 適切な䌚瀟の支持を埗るためにも「経営局ぞの報告ず、掻動に察しおの理解やアドバむスをもらう」こずが非垞に重芁です。 そのため、今回は以䞋の流れで経営陣ぞの事前報告を実斜する事ずしたした。 副瀟長兌CIO&CISOぞの報告たずは「開催する事」自䜓のお䌺い支揎願い 瀟長ぞの報告目的やKPI、利甚蚭備や予算に぀いおのお䌺い もちろん、報告ずなるず「報告のための堎のセッティングや事前準備」が必芁になりたす。しかしながら、以䞋のような圢ずするこずで、比范的にコストをかけずに実斜する事ができたした。 副瀟長ぞの報告 実斜タむミング定期実斜される自郚眲の定䟋報告䌚の堎を利甚しお報告 報告資料元々の䌁画曞をほがそのたた利甚。予算に぀いおの詳现は、埌日補足 瀟長ぞの報告 実斜タむミング採甚チヌムの定䟋報告回の堎を利甚しお報告 報告資料䌁画曞を3枚のスラむドに集玄し、「抂芁」「目的」「予算」の点でシンプルに報告 結果ずしお、いずれの堎においおも「たずはやっおみよう」ずいうポゞティブな反応をいただく事ができたした。 䌚堎手配 KINTOの宀町オフィスでは「KINTO TOKYO Junction通称Junction」ずいう、䌚瀟玹介や瀟倖ぞの発信の際に毎回䜿われる「映え」スポットがありたす。 はじめおの勉匷䌚を実斜するにあたっおは、この「映え」スポットを利甚しない手はありたせん。 䌚堎手配 Junctionは「KINTO」の名を冠しおいるのですが、所有は芪䌚瀟の「トペタファむナンシャルサヌビス」なのです。 正匏な利甚の際には、芪䌚瀟の蚱可が必芁ずなりたす。ずはいえ、申請はメヌル䞀本ででき、基本的にOKもらえるものずなっおおりたす。 今回の利甚にあたっおも、特に問題なくOKがでたした。 ビル手配 䌚堎はセキュリティゲヌトのあるビルなので、倖郚のお客様を迎えるにあたっおセキュリティゲヌトの倖偎に受付を蚭ける必芁がありたした。 これにはビル偎に事前に申し入れ、机を眮かせおもらうようお願いしたした。 こちらも、問題なくOKをいただけたした。 たた、ビルに蚱可をいただいた際に、゚ントランスに行くたでの自動ドアも、定時倖18時以降になるず斜錠内偎からは解錠可胜。倖から入るにはIDカヌドが必芁されおしたう。ずいうこずが発芚。 その察策をビル偎に盞談したずころ、小さい看板の蚭眮OKをいただけたした。盞談はするものですね。 䌚堎レむアりト 蚭備利甚はOKずなりたした、あずは䌚堎をどうレむアりトするか 圓初倧型モニタを数台甚いお発衚するこずを考えおいたのですが、プロゞェクタヌのスクリヌンが発芋され、プロゞェクタヌをしたいずなりたした。 ですが肝心のプロゞェクタヌがなかったのですが、今埌の利甚も芖野に入れた䞊で急遜調達したした。 このずきのみんなの動きもたた、OneTeamで玠晎らしかったです プロゞェクタヌを䞻䜓にしお、か぀可胜な範囲で可胜な限り倚くの方に参加いただきたいずしおできたレむアりトはコチラになりたす。 机や怅子の手配 机や怅子は、Junctionにもずもず眮かれおいたものを利甚したのですが、それだけでは足らず。。。 瀟内で利甚できそうな机や怅子をかき集めたした。 䞻には䌑憩スペヌスの机ず怅子をお借りしお、無事必芁数の確保ができたした。 圓日 圓日は運営スタッフがみんな胜動的に動き、ずおもスピヌディに蚭営ができたした たた、片付けも玠早く、これもOne Teamをずおも感じたした。みんなすごい 最埌に Junctionで倖郚のお客さんを招埅するのは、䌚瀟ずしおもはじめおのこずでした。 その䞭で、より倚くの人に、よりよい状態で芋おいただきたい。ずみんながOne Teamずなっお取り組めたした。 勉匷䌚は今埌も組織ずしお進めおいく予定なので、今回の結果をもずに、より滑らかに楜しんでいただけるようにしおいく所存です 軜食手配 勉匷䌚で亀流䌚を行うこずになった 勉匷䌚を開催する流れの䞭で、亀流䌚も行うこずずなりたした。 やはり亀流䌚ずいえば軜食。よし準備だ 軜食だ やはり勉匷䌚ずいえばピザ。今たで参加しおきた勉匷䌚で提䟛される率が䞀番高かったため、その印象が匷く残っおおりたす。 初回からむンパクトを出すものにしたいずいう気持ちはあるのですが、はじめおのこずなので無茶はできたせん。ずいうこずで、倧人しくピザにしたした。カロリヌは正矩。 そしお、ピザずいえばコヌラ。この2぀があればよいなず思っおたのですが、他の飲物も甚意しろ。ずのお達しがあり、その他のアルコヌル類も甚意したした。 どのくらい甚意するか ピザ線 今たで他の勉匷䌚に参加しおる䞭で量たで意識したこずはありたせん。どのくらい甚意すればいいのか。。。 甚意しようず考えおいたLサむズのピザは12切れで䞀般的に34人前ずのこず。 今回、「軜食」ずいう扱いなので1枚で5人前。ずいう扱いにするこずしたした。 参加しおきた勉匷䌚でも、だいたい2切れ皋床食べおたな。ずいう個人的経隓も考慮し。 最終的に、最倧参加者が40人に運営分を10名ずしお50人分で10枚のピザを手配したした。 どのくらい甚意するか 飲物線 こちらも個人的経隓を元に算出したした。1むベントでだいたい23猶を飲んでたな・・・。 ずいうこずで1人あたり3本調達するこずずしたした。 内蚳ずしおは、アルコヌル類ず炭酞飲料を11で甚意するこずずしたした。 40人参加で120本の手配ずなりたす。 ですが、、、炭酞飲料に぀いおは、ペットボトルの方が利䟿性が高い。ずいうこずで倉曎ずなり、たた発泚に郜合のいい数量で泚文したため48本24本が入った箱を2箱ずなりたした。 トヌタルで甚意したのは、アルコヌル60本。炭酞飲料48本の蚈108本甚意したした。 い぀たでに手配するか ピザは前日。飲物は3日前に手配をしたした。 すべお無事トラブルなく玍品受領できたした。 結果はどうなった ピザあたりなし アルコヌル8本あたり →52本消費 炭酞飲料21本あたり →27本消費 圓日参加者20名皋床で、䞊蚘の結果ずなりたした。 この䞭には圓日スタッフの飲食分も含たれおおりたす。 ピザに関しおは量が足らなかった。ず感じおおりたす運営スタッフたでは行き枡らなかったため。ずいうのも、亀流䌚の圢匏が「座談䌚」ずしお、KTCスタッフを囲んでの䌚ずなり、話を聞く時間が長くなる䌚だった食べる時間が倚くなった。ず分析しおおりたす。 たた、飲物に぀いおはアルコヌルに぀いおはちょうど良かったず思うのですが、炭酞飲料が倚すぎた印象です。 「お茶が欲しかった」ずいう声もあり、炭酞飲料の代わりにお茶も甚意しおおくず良かったず感じたした。 最埌に はじめおの勉匷䌚での軜食提䟛。ずいうこずで、わからないこずも倚い䞭でしたが、なんずか倧きな䞍満が出ない圢での提䟛はできたず考えおおりたす。 次回実斜時には、よりよい圢で提䟛できるようにしたいず考えおおりたす ノベルティ補䜜 O・MO・TE・NA・SHI 我々KINTOテクノロゞヌズは2021幎4月に蚭立されたただ新しい䌚瀟です。 そしお今回のむベント開催圢匏はオフラむン、぀たり䌚堎である匊瀟たで足を運んでいただく必芁がありたす。 前述の軜食やドリンクもありたすが、せっかくなので 皆様に持っお垰っおいただけるモノ 䌚瀟を芚えおいただくきっかけになるモノ を準備したいず思いノベルティを補䜜するこずにしたした。 どう実珟するか 事務局メンバヌで話し合った結果満堎䞀臎で「ノベルティを䜜ろう」ずなり、ノベルティ補䜜チヌムが始動したした。 1.䜕を䜜るか たず動いたのが「どんなノベルティにするか」です。 もちろん予算の制玄もあり芋蟌たれる来堎者の方を想定しあヌでもないこヌでもないを話し合いたした ![ノベルティ怜蚎資料](/assets/blog/authors/tomori/ノベルティ怜蚎資料.png =400x) あヌでもないこヌでもないを語り合った資料の䞀郚 そしお今回は「ステッカヌ」を補䜜するこずに決定したした 教蚓: 無限に広がる思いを珟実的な萜ずし所に着地させるこずが倧切 2.どう䜜るか モノはステッカヌに決たりたした。ステッカヌ補䜜自䜓は別の瀟内むベントで䜜成した実瞟があり、ノりハりのあるデザむン郚門ぞむベントの䞻旚、コヌポレヌト゚ンゞニアずは、予想される来堎者の属性・興味ずいった盞談をするこずで出来䞊がったのがこちらです テッテレヌ この2぀のパタヌンから今回のむベントにおけるノベルティずしお䟡倀を発揮する方を議論し、癜ベヌスのコヌポレヌトカラヌバヌゞョンを補䜜するこずに決定したした どうなった そしお粛々ず発泚を進め、決枈を進め、玍品を埅ち・・・ テッテレヌ(2回目) 無事むベント開催たでに補䜜完了いたしたした 様々な郚眲を超えOne Teamずしお補䜜したこのノベルティが今埌もたくさんの堎所で䜿っおいただき、KINTOテクノロゞヌズずいう䌚瀟を知っおもらうきっかけになれば倧倉嬉しく思いたす。 プロモヌションず蚈枬 たずめるず この勉匷䌚の成果をどう枬るのか、そしお勉匷䌚をどうやっお告知するのか、ずいうこずを考えたした。 䌚瀟ぞの報告材料ず、改善のための指暙を集めるこずを目的に、むベントぞの流入ずむベントによる圱響を蚈枬し぀぀、できる限りのプロモヌションを行いたした。 実際に実斜したこず、考えたこず、実斜結果を共有したす。 背景 たず考えたのは、䌚瀟ぞの結果報告です。勉匷䌚の実斜結果を䌚瀟に報告するにあたり、参加人数などの数字もそうですが、勉匷䌚の効果ずしお「KTCの認知床向䞊」を謳っおいたので、それを瀺すようなデヌタを集める必芁がありたした。 そしお勉匷䌚自䜓は2回目・3回目も実斜しおいきたいず考えおいたので、継続的に改善しおいくための指暙は必芁だず考えたした。 䜕より、初めお開催する瀟倖向け勉匷䌚なので䜕人ぐらい参加しおくれるのか正盎たったく想像が぀きたせんでした。「参加者0人」を党力で回避するために、できる限りの告知方法を詊したした。 最終的には、ざっくり以䞋の指暙を集めるこずに決めたした。 どのチャネルからどのくらい流入があったのか 勉匷䌚の結果、どのくらいKTCの認知床は䞊がったのか やったこず、考えたこず 欲しい指暙を可芖化するため、たずは流入の構造をざっくり曞き出したした。 むベントぞの゚ントリヌはconnpassで受け付けるこずにしたので、connpassぞの流入を蚈枬。そしお勉匷䌚・座談䌚の結果がどのように認知アップに繋がったのかを蚈枬するこずにしたした。 情シスのむベントなので、「情シスSlack」で告知させおもらうこずは決めおいたした。加えおKTCは テックブログ やX旧Twitterを運営しおいるので運営チヌムに告知を䟝頌したした。そしお党瀟員に向けお、SNSで拡散・告知の䟝頌を瀟内Slackで呌びかけたした。 勉匷䌚・座談䌚の結果ずしおは、Xのハッシュタグを甚意しおpost件数ずむンプレッション数を拟うこずにしたした。そしお「KTCのこずを知っおいたしたか」ずいうアンケヌトから知らなかった人の割合を枬り、その割合を合蚈むンプレッション数に掛け合わせるこずで、知らなかった人に察するリヌチ数を半ば匷匕に枬りにいくこずにしたした。 最埌に、むベント埌には自瀟のXアカりント、コヌポレヌトサむト、テックブログぞの流入やフォロヌがどのように倉わったか、むベント前埌での掚移を蚈枬しようず考えたした。 結果 たくさんの人に拡散をご協力いただきたしお、环蚈56人の方から参加申し蟌みしおいただき、定員40名は満垭状態。圓日実際には31名の方にお越しいただくこずができたした connpassに察するチャネルごずの流入は以䞋の通りです。 むベント圓日たでのXのpost件数は61件、合蚈むンプレッション数は28608でした。そのうち376アクセスされたので、Xを芋おくれた人の1.31%がconnpassに来おくれた蚈算です。 アンケヌトの結果、むベント参加者の39%は元々KTCを知らなかったこずがわかりたした。connpassぞの蚪問者1356人に圓おはめるず、その39%=箄530人が元々KTCを知らなかったこずになるので、それだけの人数にKTCを認知しおもらうこずに成功したした匷匕 むベント前埌で比范するず、自瀟で運甚しおいるXアカりントのフォロワヌは少し増えたした。コヌポレヌトサむトずテックブログのPVやUUも、むベント圓日はい぀もより少し倚いかな、ぐらいでした。ですが、少しでも確実に効果があるこずがわかったので、2回目以降も匕き続き蚈枬改善を続けおいきたいず思いたす 告知サむト準備 たずめるず むベントを告知する媒䜓ずしおconnpassを遞択し、むベント情報ペヌゞを準備したした。 「どんなむベントが人気なのか」ずいうこずを、ランキング䞊䜍のむベントから孊び、自分達のむベントに実装したした。 connpass自䜓は非垞に簡単にむベントを䜜成できるサヌビスで、ペヌゞ䜜成に苊劎はしなかったので、その分タヌゲットの蚭定ず、䌝えるメッセヌゞに気を配りたした。 想い はじめおの開催むベントなので、参加者0人は怖すぎる。。今の自分達にできる最高のペヌゞを䜜るこずを決めたした。 やったこず、考えたこず たずは倖郚サヌビス利甚のために瀟内申請をしたした。初めお取匕する/利甚する事業者の堎合は担圓郚眲でチェックが必芁なのですが、ここは問題なくクリアしたした。 そしお申請にあたっお管理方法を定めたした。簡単に管理目的・管理察象・利甚目的を定めた䞊で、システムずアカりントの管理者を定め、具䜓的なアカりント管理方法を簡単に決めたした。 申請が降りお実際にconnpassを觊れるようになっおからは、たず蚭定可胜なすべおの項目を掗い出しお確認したした。次回以降のむベント開催時の手匕きずしお残しおおきたかったのず、䞍可逆な蚭定項目がないかを確認したかったのが理由です。「参加費なしのオフラむンむベント」ずいう範囲で確認した結果、倉曎䞍可、もしくは制限のある項目は以䞋の぀だけでした。 グルヌプ倉曎䞍可 参加内容.参加枠参加枠は 申蟌者がいない間だけ 削陀可胜 ほずんどの項目は倉曎可胜でした。でも開催日時や䌚堎などが倉わったら参加者は混乱するので、远加はしおも、倉曎/削陀はしないほうが良いず思いたす。 むベント情報ペヌゞの仕様を確認するのず䜵せお、人気のむベントを分析したした。connpassのむベントランキングを眺めお、自分達のものず同じ属性のむベントのうち「なぜかめっちゃ人気なむベント」を20個ほどピックアップしたした。それらを順番に眺めお、倧切だず感じる芁玠を抜出しお抜象化し、自分達のむベント情報ペヌゞに適甚したした。 仕様ず考慮事項がわかったので、ここで改めお、基本蚭蚈チックな郚分を固めたした。「むベント情報ペヌゞ」ずいう詳现蚭蚈の前に、そもそもの勉匷䌚の意図を具䜓化し、①タヌゲットずなるナヌザヌ、②メッセヌゞ、③コミュニケヌションの基本ルヌルを蚀語化したした。 ①タヌゲットずなるナヌザヌ 「勉匷䌚に積極的なコヌポレヌト゚ンゞニア」をタヌゲットに蚭定したした。「他瀟事䟋を知りたい」「倖の情シスず繋がりたい」ずいうニヌズを仮蚭定し、そこに察しおむベント情報ペヌゞの文蚀を䜜成したした。 ②メッセヌゞ 「他の䌚瀟の情シスっおどんな感じでやっおるの」をざっくばらんに話したしょうずいうメッセヌゞを眮きたした。「勉匷䌚文化を広げたい」ずいうのがKINTOテクノロゞヌズMeetUpの䞻題で、自分達も䌝えたいし、他の人たちの話も聞きたい。それを実珟するために、座談䌚ずいう枠組みを蚭け、内倖問わず語り合う堎を䜜りたいず考えたした。 ③コミュニケヌションの基本ルヌル 「むベントはあくたで勉匷ずしおのむンプットずアりトプットの堎ずする」ずいうこずをルヌルずしお定めたした。せっかく来おもらったんだから、事業のこず、採甚のこず、KTCの良いずころをアピヌルしお蚎求したい。。ずいう想いはグッず抑えお、あくたで「情シスによる情シスのための勉匷䌚」ずいうずころを培底したした。 むベントを公開する段になったらテクニカルな話ずしお、定員数を少なめからスタヌトしお、必芁になったら匕き䞊げる䜜戊にしたした。 枠がギリギリの方が駆け蟌み需芁が芋蟌めそうなので 申し蟌みが少なくおも恥ずかしくないので重芁 結果 こんな感じになりたした 【第1回】KINTOテクノロゞヌズ MeetUp - connpass 人気のペヌゞを眺める䞭で埗た孊びは、以䞋のような芁玠です。 誰に向けたむベントか、参加した結果䜕を埗られるかが明確だず人が来やすい 安心できそうなむベントだず人が来やすい 有名䌁業、有名人など 過去のむベントの雰囲気がわかる画像や動画があっおもいいかも 旬なトピックChatGPTなどは人が集たるようだ 開催日盎前にリマむンドするための通知メヌルも掻甚したした。告知から開催たで期間が空いおしたう堎合には、参加者ず運営サむド双方のモチベヌションを保ち続ける意味合いでも、タむミングを芋おリマむンドするこずをおすすめしたす。 セッション取りたずめ 抂芁 圓日の段取りを包括的にたずめたした。 具䜓的にはむベント圓日のタむムテヌブルの䜜成、座談䌚の䌁画ず䌚堎レむアりト決め、発衚資料の取りたずめ、むベントの進行管理など。 初めおのむベントでしたが、スタッフ党員でプロアクティブに仕事を探したくった結果、倧きなトラブルもなく、楜しくむベントを終えるこずができたした 重芁なポむント 「初めおのむベント」 実斜内容/考慮事項 むベント圓日のタむムテヌブルの䜜成 座談䌚の䌁画ず䌚堎レむアりト決め 発衚資料の取りたずめ むベントの進行管理 実行結果 倧きなトラブルもなく、楜しくむベントを終えるこずができたした。 初めおのむベントで、䜕が起こるか予枬が぀かない䞭で、スタッフ党員アドレナリンMAXで目を光らせおいたした。誰の圹割でもない仕事、タスクにならないタスクを、1人1人が胜動的に探し続けたからこそ成功したむベントだず思いたす 登壇者による「事䟋発衚資料」の準備 「事䟋発衚」は、今回の勉匷䌚におけるメむンコンテンツです。勉匷䌚での登壇経隓も人それぞれであっため、倧枠の流れを揃えた䞊で、定期的に合流するポむントを䜜り、取り残される人が出ないように資料準備を進行したした。 スラむドテンプレヌトの統䞀 「発衚資料の䜓裁は敎えた方が良い」ずいう刀断から、利甚するテンプレヌトの統䞀をおこないたした。自瀟甚のスラむドテンプレヌトは存圚しおいたため、こちらはスムヌズに合意できたした マむルストヌンを区切った締め切り蚭定 ギリギリたで締め切りを蚭定するず、人により進行のムラが出おしたうため、以䞋のようなマむルストヌンを区切り、党員の資料䜜成スケゞュヌルを揃えおいきたした 初回の短期締切ザックリ「2週間埌」を締め切りに蚭定し、そのタむミングで皆の様子を確認 芋せ合いっこ䌚「できおいない」事を責めず、だけども「資料䜜成」を促す盞互確認䌚の実斜 副瀟長レビュヌ事前に副瀟長のお墚付きをもらうべく、そこに向けた「完成版」の締切を蚭定 事前リハヌサル開催の䞀週間前に「発衚者同士でのリハヌサル」を実斜し、完成床を高める 結果ずしお、最埌の「事前リハヌサル」においおは、皆さんほが「資料完成」「時間枠内に収たる」圢での準備を終え、安心しお開催圓日を迎える事ができるようになりたした。 最埌に このような圢で、事務局のメンバヌがプロアクティブに掻動しおくださった結果、無事に圓日の開催を迎えるこずができたした。 これはたさに、私たちがワヌキングスタンスずしお掲げる「 One Team, One Player 」が䜓珟できたひず぀の事䟋かなず思っおいたす。 ご参加くださった皆さた、運営に関わっおくださったすべおの皆さた、ありがずうございたす なお、今回の蚘事以倖にも、「運営スタッフ芖点でのテックブログ蚘事」や「登壇者による事䟋発衚の玹介テックブログ蚘事」が埌日公開される予定です。そちらもどうぞよろしくお願い臎したす
#iwillblog → #ididblog ずいうこずでみなさんこんにちは。モバむルアプリ開発GでiOSを担圓しおいる小山です。iOSDC 2023に参加しおきたので、遅ればせながらその内容を玹介したいず思いたす。匊瀟からは参加した小山ずGOSEOからそれぞれ玹介させおいただきたす。 今幎はiOS゚ンゞニア以倖の匊瀟テックブログ運営メンバヌも参加しおおり、運営目線での蚘事が iOSDC Japan 2023参加レポヌト運営目線 にたずめおあるのでぜひご䞀読ください たた、昚幎のiOSDC参加レポヌトも #iwillblog: iOSDC Japan 2022参加レポヌト にありたす。 Part of KOYAMA 私はiOSDCに初めお珟地参加しおきたした。珟地の各瀟さんのブヌスで玹介されおいた内容や、各セッションを聞いおみお感じた内容をたずめたいず思いたす。 珟地ブヌス 3日間かけおほずんどのブヌスを回るこずができ、実際に働くiOS゚ンゞニアの仲間の話を倚く聞くこずができたした。やはりiOS゚ンゞニアずしおは、LINEさんのコヌドレビュヌチャレンゞや、DeNAさんの脳内SwiftUIレンダリングが楜しかったですね。特に脳内SwiftUIレンダリングは普段SwiftUIを觊っおいる身ずしおプラむドがあったので意地でも解いおやろうず思っお挑戊したしたが、䜿ったこずのないコンポヌネントのレンダリングができず、悔しいですが惚敗でした。その分楜しく孊ばせおいただきたした 他にも、ZOZOさんのブヌスではARメむクを楜したせおもらいたした。顔のパヌツの認識もすぐに実珟できるずいうこずを目の圓たりにしお、ずおも新鮮な気持ちになれたした。どうやら真っ赀リップが䌌合いすぎおしたうようで、新たな発芋もありたした。 䌌合いすぎおしたうのでちょっずだけ顔を隠したした たた、様々なノベルティを甚意しおくださるスポンサヌが倚く、その䞭でもFindyさんずdipさんが䞊んで景品くじをやっおいたのでこちらも挑戊しに行きたした。 しかし結果はこちらも惚敗・・。1日1回のチャレンゞ制限の䞭、特にFindyさんのくじでは2回の挑戊どちらも「倧凶」でした。悔しい・・。前埌に倧吉を圓おおいる人がたくさんいた 倧凶のくじを2日連続で手に入れるのもレアらしい あれ、私普通にむベントを楜しんでないか 参加セッション もちろんメむンであるセッションも芖聎したした。その䞭で気になったセッションに぀いおコメントしたいず思いたす。 Appleにおけるプラむバシヌの党容を把握する @akatsuki174 さんによるプラむバシヌに関するレポヌトでした。Appleはカメラアクセスや䜍眮情報など様々な情報に察しお、OSが制埡をかけおくれたす。そのためうっかりおかしな情報にアクセスするこずがありたせん。この厳密さは私がiOS開発のこずを奜きな理由の䞀぀でもありたす。その分、ストア審査などでよくチェックされる項目なので、゚ンゞニアずしおはしっかりキャッチアップしおおきたいずころです。 セッションの䞭で特に気になったのが、䜍眮情報に関する蚱可状態です。 CLLocationManager を䜿った䜍眮情報の取埗では、「垞に䜍眮情報を取埗」したい堎合に段階を螏んで蚱可しおもらう必芁があるずのこずで、これは初耳でした。 公匏ドキュメントには以䞋のように蚘茉がありたした。 You must call this or the requestWhenInUseAuthorization() method before your app can receive location information. To call this method, you must have both NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription keys in your app’s Info.plist file. なるほどなるほど、垞に䜍眮情報を取る requestAlwaysAuthorization() ためには、先にアプリの䜿甚䞭は蚱可 requestWhenInUseAuthorization() しおもらわないずならないのですね。なんずなく芋たこずのある機胜でしたが、仕組みは初めお知ったためずおも孊びになりたした。 個人的には圓日収録でのご登壇だったakatsukiさんが、マネキンの頭郚のみ投圱されお喋っおいる姿がおもしろくお奜きでした。笑 iPadだけで完結させるiOSアプリ開発の党お こちらはLTの䞀郚の話でしたが、䜕が䜕でもiPadのみでiOS開発をするずいった内容でした。結論ずしお可胜でしたが、GitHubが䜿えないずいうのが倧きな問題であるずのこずで、たさにその通りだず思いたした。 しかしMacBookなくずもアプリの開発がある皋床進められるようになったのは時代ですね。い぀でもどこでも開発できるのぱンゞニアにずっお朗報だず思いたした。 身に芚えのないDeveloper Program License違反を通告されおアプリの怜玢順䜍を䞋げられた時の闘い方 LTからもう1本、おもしろかったセッションです。特定の日時だけアクセス数が激増するアプリを䜜ったずころ、Appleから䞍正を疑われおアプリの怜玢順䜍を䞋げられ珟圚もバトル䞭ずいう、䜕ずも䞍憫な話でした。 アプリの性質䞊、節分圓日に利甚数が倧きく増えるずいうのは玍埗できたしたし、Appleが危険芖するのもよく理解できたした。しかしAppleがなかなか問い合わせに察応しおくれないずいうのは、解決が難しい議題かず思いたす。こちらは個人開発の話でしたが、䌁業ずしお䜜成するアプリでも同様のパタヌンはありうるため、ありがたく今埌の知芋ずさせおいただきたした。 たずめ of KOYAMA 以䞊、小山パヌトずなりたす。お祭り感のあるiOSDC、最高でした今幎は䞉日間終日の参加が難しかったのですが、来幎こそは終日参加しようず匷く思いたした。たた、X(Twitter)で芋かけるiOS界隈の方々ず盎接お話しができたり写真を撮っおいただけお、そういった点でも満足感の高いむベントでした。 Part of GOSEO 私はiOSDCに初めおオンラむン参加したした。開催日前に芖聎しおみたいず思ったセッションを芖聎したフィヌドバックをたずめおみたした。 ノベルティが豪華 他のみんながノベルティゲットしたぜっお蚀っおいる䞭、自分はただかなずりキりキワクワクで埅っおたした。 登録䜏所をミスっちゃっお、運営様から配送できないず蚀う連絡がありたした。運営の方、ご迷惑をおかけしたした。 無事にノベルティゲットした埌、ノベルティで頂いた小さなカップは倧切に掻甚させおいただいおおりたす出瀟日限定 豪華なノベルティボックス 職堎で䜿うのにちょうどいいマグカップ 参加セッション UIのブラックボックスを探る OS提䟛のUIず比べるずカスタムUIの品質は悪くなる傟向があるけど、特定の条件のもずではカスタムUI化は必芁になる時があるずいうお話を聞いお、カスタムUI䜜成ぱンゞニアあるあるなんだず共感したした。 カスタムUI党おが悪いこずではなく、HIGを準拠しお䜜成したり、OS提䟛のUIを分析するずカスタムUIも良くなるずいうお話も聞いお、今埌の実装で心掛けたいず思いたす。 たた、分析するずきにフォヌカスを圓おるべきずころの説明もしおいお、画面のHIGの芁玠を分析し、UIの法則性を芋぀けるこずが倧事である、UIはナヌザヌにずっお圓たり前を実装するのが倧事である、ず蚀っおたした。 ナヌザヌにずっお圓たり前の動䜜や慣れた動䜜を実装するこずでアプリはナヌザヌフレンドリヌさが向䞊しお、ナヌザヌがアプリ䜿甚時に違和感がなくなるずいうこずでした。 自分が凄いず䞀番感じたのは、公開アプリそのもののUIを分析するツヌルでした。 View Hierachy DebuggerはiOS゚ンゞニアであればよく知られるツヌルですが、それはロヌカル内のアプリでしか䜿えない制玄がありたす。 Fridaを䜿うずMapsのようなアプリのUI構造の調査もでき、画面䞊では確認できないUI構造を分析できるよず、ツヌルの玹介しおたした。 導入方法も説明付きで優しいなぁヌず思い、やっおみおぇずいうモチベが䞊がりたした。 旅行アプリでより正確にパスポヌトを読み蟌む技術 ~ MLKit / Vision / CoreNFC ~ MLKitずVisionのSPMぞの察応性、実装の簡易性、およびOCRの粟床を比范説明をしおいたした。 実装もOCR粟床も同等レベルの刀定をしおいたしたが、SPMの察応のしやすさで、Visionが優っおいたみたいでした。その埌はどのようにパスポヌトの文字をVisionを䜿甚しお読み蟌む実装をしおいくのか説明がありたした。 具䜓的にはパスポヌトのNFCを䜿甚しお、OCRの読み取り間違いをどう補完したかのお話がありたした。たた、NFCの実装方法の玹介もあり、すごく内容の濃いセッションでした。 たずめ of GOSEO 以䞊、GOSEOパヌトずなりたす。普段觊らない、気づかない知識に觊れるこずができるiOSDC、Greatでした。来幎も是が非でも参加したいです。自分の立ち䜍眮ずか目指す方向性ずか知らないこずに気づける玠晎らしい機䌚を埗れたむベントでした。 最埌に これにお、 #ididblog ずなりたす執筆が遅くなっおしたったので、来幎はもっず早くアりトプットできるようにしおいきたいず思いたす。 来幎のiOSDC 2024たで埅ち遠しいですね
はじめに こんにちはKINTOテクノロゞヌズの勉匷䌚事務局スタッフです。 先日、「 KINTOテクノロゞヌズ MeetUp情シスによる情シスのための事䟋シェア4遞 」ずいうタむトルで「コヌポレヌトIT領域に特化した、事䟋発衚座談䌚圢匏の勉匷䌚」を開催したした。 開催に先立ち、「勉匷䌚の䌁画事務局立ち䞊げ」たでのストヌリヌを「 はじめおの「KINTOテクノロゞヌズ MeetUp」が開催されるたで 」ずいう蚘事でご玹介したした。 今回は、その続線ずなる「開催に至るたでの、事務局掻動のあれこれ」をご玹介しおいきたす。 前回に匕き続き、「自瀟でれロから勉匷䌚を立ち䞊げ、掚進しおいきたい」ず考えおいる方のご参考になれば幞いです。 前回の蚘事では、䞻に 勉匷䌚の䌁画立案 事務局メンバヌ・登壇者の募集 未怜蚎事項のディスカッションを実斜 圹割分担ず、アゞャむルな進行管理を開始した ずいった内容たでを蚘茉しおいたした。 ここからは、「具䜓的にどのような圹割分担があったのか」「それぞれどのような掻動をおこなったのか」ずいった内容を掘り䞋げおいきたいず思いたす。 経営局ぞの事前報告 今回の勉匷䌚は「個人や有志」ではなく「䌚瀟の掻動」ずしお実斜するものずなりたす。 適切な䌚瀟の支持を埗るためにも「経営局ぞの報告ず、掻動に察しおの理解やアドバむスをもらう」こずが非垞に重芁です。 そのため、今回は以䞋の流れで経営陣ぞの事前報告を実斜する事ずしたした。 副瀟長兌CIO&CISOぞの報告たずは「開催する事」自䜓のお䌺い支揎願い 瀟長ぞの報告目的やKPI、利甚蚭備や予算に぀いおのお䌺い もちろん、報告ずなるず「報告のための堎のセッティングや事前準備」が必芁になりたす。しかしながら、以䞋のような圢ずするこずで、比范的にコストをかけずに実斜する事ができたした。 副瀟長ぞの報告 実斜タむミング定期実斜される自郚眲の定䟋報告䌚の堎を利甚しお報告 報告資料元々の䌁画曞をほがそのたた利甚。予算に぀いおの詳现は、埌日補足 瀟長ぞの報告 実斜タむミング採甚チヌムの定䟋報告回の堎を利甚しお報告 報告資料䌁画曞を3枚のスラむドに集玄し、「抂芁」「目的」「予算」の点でシンプルに報告 結果ずしお、いずれの堎においおも「たずはやっおみよう」ずいうポゞティブな反応をいただく事ができたした。 䌚堎手配 KINTOの宀町オフィスでは「KINTO TOKYO Junction通称Junction」ずいう、䌚瀟玹介や瀟倖ぞの発信の際に毎回䜿われる「映え」スポットがありたす。 はじめおの勉匷䌚を実斜するにあたっおは、この「映え」スポットを利甚しない手はありたせん。 䌚堎手配 Junctionは「KINTO」の名を冠しおいるのですが、所有は芪䌚瀟の「トペタファむナンシャルサヌビス」なのです。 正匏な利甚の際には、芪䌚瀟の蚱可が必芁ずなりたす。ずはいえ、申請はメヌル䞀本ででき、基本的にOKもらえるものずなっおおりたす。 今回の利甚にあたっおも、特に問題なくOKがでたした。 ビル手配 䌚堎はセキュリティゲヌトのあるビルなので、倖郚のお客様を迎えるにあたっおセキュリティゲヌトの倖偎に受付を蚭ける必芁がありたした。 これにはビル偎に事前に申し入れ、机を眮かせおもらうようお願いしたした。 こちらも、問題なくOKをいただけたした。 たた、ビルに蚱可をいただいた際に、゚ントランスに行くたでの自動ドアも、定時倖18時以降になるず斜錠内偎からは解錠可胜。倖から入るにはIDカヌドが必芁されおしたう。ずいうこずが発芚。 その察策をビル偎に盞談したずころ、小さい看板の蚭眮OKをいただけたした。盞談はするものですね。 䌚堎レむアりト 蚭備利甚はOKずなりたした、あずは䌚堎をどうレむアりトするか 圓初倧型モニタを数台甚いお発衚するこずを考えおいたのですが、プロゞェクタヌのスクリヌンが発芋され、プロゞェクタヌをしたいずなりたした。 ですが肝心のプロゞェクタヌがなかったのですが、今埌の利甚も芖野に入れた䞊で急遜調達したした。 このずきのみんなの動きもたた、OneTeamで玠晎らしかったです プロゞェクタヌを䞻䜓にしお、か぀可胜な範囲で可胜な限り倚くの方に参加いただきたいずしおできたレむアりトはコチラになりたす。 机や怅子の手配 机や怅子は、Junctionにもずもず眮かれおいたものを利甚したのですが、それだけでは足らず。。。 瀟内で利甚できそうな机や怅子をかき集めたした。 䞻には䌑憩スペヌスの机ず怅子をお借りしお、無事必芁数の確保ができたした。 圓日 圓日は運営スタッフがみんな胜動的に動き、ずおもスピヌディに蚭営ができたした たた、片付けも玠早く、これもOne Teamをずおも感じたした。みんなすごい 最埌に Junctionで倖郚のお客さんを招埅するのは、䌚瀟ずしおもはじめおのこずでした。 その䞭で、より倚くの人に、よりよい状態で芋おいただきたい。ずみんながOne Teamずなっお取り組めたした。 勉匷䌚は今埌も組織ずしお進めおいく予定なので、今回の結果をもずに、より滑らかに楜しんでいただけるようにしおいく所存です 軜食手配 勉匷䌚で亀流䌚を行うこずになった 勉匷䌚を開催する流れの䞭で、亀流䌚も行うこずずなりたした。 やはり亀流䌚ずいえば軜食。よし準備だ 軜食だ やはり勉匷䌚ずいえばピザ。今たで参加しおきた勉匷䌚で提䟛される率が䞀番高かったため、その印象が匷く残っおおりたす。 初回からむンパクトを出すものにしたいずいう気持ちはあるのですが、はじめおのこずなので無茶はできたせん。ずいうこずで、倧人しくピザにしたした。カロリヌは正矩。 そしお、ピザずいえばコヌラ。この2぀があればよいなず思っおたのですが、他の飲物も甚意しろ。ずのお達しがあり、その他のアルコヌル類も甚意したした。 どのくらい甚意するか ピザ線 今たで他の勉匷䌚に参加しおる䞭で量たで意識したこずはありたせん。どのくらい甚意すればいいのか。。。 甚意しようず考えおいたLサむズのピザは12切れで䞀般的に34人前ずのこず。 今回、「軜食」ずいう扱いなので1枚で5人前。ずいう扱いにするこずしたした。 参加しおきた勉匷䌚でも、だいたい2切れ皋床食べおたな。ずいう個人的経隓も考慮し。 最終的に、最倧参加者が40人に運営分を10名ずしお50人分で10枚のピザを手配したした。 どのくらい甚意するか 飲物線 こちらも個人的経隓を元に算出したした。1むベントでだいたい23猶を飲んでたな・・・。 ずいうこずで1人あたり3本調達するこずずしたした。 内蚳ずしおは、アルコヌル類ず炭酞飲料を11で甚意するこずずしたした。 40人参加で120本の手配ずなりたす。 ですが、、、炭酞飲料に぀いおは、ペットボトルの方が利䟿性が高い。ずいうこずで倉曎ずなり、たた発泚に郜合のいい数量で泚文したため48本24本が入った箱を2箱ずなりたした。 トヌタルで甚意したのは、アルコヌル60本。炭酞飲料48本の蚈108本甚意したした。 い぀たでに手配するか ピザは前日。飲物は3日前に手配をしたした。 すべお無事トラブルなく玍品受領できたした。 結果はどうなった ピザあたりなし アルコヌル8本あたり →52本消費 炭酞飲料21本あたり →27本消費 圓日参加者20名皋床で、䞊蚘の結果ずなりたした。 この䞭には圓日スタッフの飲食分も含たれおおりたす。 ピザに関しおは量が足らなかった。ず感じおおりたす運営スタッフたでは行き枡らなかったため。ずいうのも、亀流䌚の圢匏が「座談䌚」ずしお、KTCスタッフを囲んでの䌚ずなり、話を聞く時間が長くなる䌚だった食べる時間が倚くなった。ず分析しおおりたす。 たた、飲物に぀いおはアルコヌルに぀いおはちょうど良かったず思うのですが、炭酞飲料が倚すぎた印象です。 「お茶が欲しかった」ずいう声もあり、炭酞飲料の代わりにお茶も甚意しおおくず良かったず感じたした。 最埌に はじめおの勉匷䌚での軜食提䟛。ずいうこずで、わからないこずも倚い䞭でしたが、なんずか倧きな䞍満が出ない圢での提䟛はできたず考えおおりたす。 次回実斜時には、よりよい圢で提䟛できるようにしたいず考えおおりたす ノベルティ補䜜 O・MO・TE・NA・SHI 我々KINTOテクノロゞヌズは2021幎4月に蚭立されたただ新しい䌚瀟です。 そしお今回のむベント開催圢匏はオフラむン、぀たり䌚堎である匊瀟たで足を運んでいただく必芁がありたす。 前述の軜食やドリンクもありたすが、せっかくなので 皆様に持っお垰っおいただけるモノ 䌚瀟を芚えおいただくきっかけになるモノ を準備したいず思いノベルティを補䜜するこずにしたした。 どう実珟するか 事務局メンバヌで話し合った結果満堎䞀臎で「ノベルティを䜜ろう」ずなり、ノベルティ補䜜チヌムが始動したした。 1.䜕を䜜るか たず動いたのが「どんなノベルティにするか」です。 もちろん予算の制玄もあり芋蟌たれる来堎者の方を想定しあヌでもないこヌでもないを話し合いたした ![ノベルティ怜蚎資料](/assets/blog/authors/tomori/ノベルティ怜蚎資料.png =400x) あヌでもないこヌでもないを語り合った資料の䞀郚 そしお今回は「ステッカヌ」を補䜜するこずに決定したした 教蚓: 無限に広がる思いを珟実的な萜ずし所に着地させるこずが倧切 2.どう䜜るか モノはステッカヌに決たりたした。ステッカヌ補䜜自䜓は別の瀟内むベントで䜜成した実瞟があり、ノりハりのあるデザむン郚門ぞむベントの䞻旚、コヌポレヌト゚ンゞニアずは、予想される来堎者の属性・興味ずいった盞談をするこずで出来䞊がったのがこちらです テッテレヌ この2぀のパタヌンから今回のむベントにおけるノベルティずしお䟡倀を発揮する方を議論し、癜ベヌスのコヌポレヌトカラヌバヌゞョンを補䜜するこずに決定したした どうなった そしお粛々ず発泚を進め、決枈を進め、玍品を埅ち・・・ テッテレヌ(2回目) 無事むベント開催たでに補䜜完了いたしたした 様々な郚眲を超えOne Teamずしお補䜜したこのノベルティが今埌もたくさんの堎所で䜿っおいただき、KINTOテクノロゞヌズずいう䌚瀟を知っおもらうきっかけになれば倧倉嬉しく思いたす。 プロモヌションず蚈枬 たずめるず この勉匷䌚の成果をどう枬るのか、そしお勉匷䌚をどうやっお告知するのか、ずいうこずを考えたした。 䌚瀟ぞの報告材料ず、改善のための指暙を集めるこずを目的に、むベントぞの流入ずむベントによる圱響を蚈枬し぀぀、できる限りのプロモヌションを行いたした。 実際に実斜したこず、考えたこず、実斜結果を共有したす。 背景 たず考えたのは、䌚瀟ぞの結果報告です。勉匷䌚の実斜結果を䌚瀟に報告するにあたり、参加人数などの数字もそうですが、勉匷䌚の効果ずしお「KTCの認知床向䞊」を謳っおいたので、それを瀺すようなデヌタを集める必芁がありたした。 そしお勉匷䌚自䜓は2回目・3回目も実斜しおいきたいず考えおいたので、継続的に改善しおいくための指暙は必芁だず考えたした。 䜕より、初めお開催する瀟倖向け勉匷䌚なので䜕人ぐらい参加しおくれるのか正盎たったく想像が぀きたせんでした。「参加者0人」を党力で回避するために、できる限りの告知方法を詊したした。 最終的には、ざっくり以䞋の指暙を集めるこずに決めたした。 どのチャネルからどのくらい流入があったのか 勉匷䌚の結果、どのくらいKTCの認知床は䞊がったのか やったこず、考えたこず 欲しい指暙を可芖化するため、たずは流入の構造をざっくり曞き出したした。 むベントぞの゚ントリヌはconnpassで受け付けるこずにしたので、connpassぞの流入を蚈枬。そしお勉匷䌚・座談䌚の結果がどのように認知アップに繋がったのかを蚈枬するこずにしたした。 情シスのむベントなので、「情シスSlack」で告知させおもらうこずは決めおいたした。加えおKTCは テックブログ やX旧Twitterを運営しおいるので運営チヌムに告知を䟝頌したした。そしお党瀟員に向けお、SNSで拡散・告知の䟝頌を瀟内Slackで呌びかけたした。 勉匷䌚・座談䌚の結果ずしおは、Xのハッシュタグを甚意しおpost件数ずむンプレッション数を拟うこずにしたした。そしお「KTCのこずを知っおいたしたか」ずいうアンケヌトから知らなかった人の割合を枬り、その割合を合蚈むンプレッション数に掛け合わせるこずで、知らなかった人に察するリヌチ数を半ば匷匕に枬りにいくこずにしたした。 最埌に、むベント埌には自瀟のXアカりント、コヌポレヌトサむト、テックブログぞの流入やフォロヌがどのように倉わったか、むベント前埌での掚移を蚈枬しようず考えたした。 結果 たくさんの人に拡散をご協力いただきたしお、环蚈56人の方から参加申し蟌みしおいただき、定員40名は満垭状態。圓日実際には31名の方にお越しいただくこずができたした connpassに察するチャネルごずの流入は以䞋の通りです。 むベント圓日たでのXのpost件数は61件、合蚈むンプレッション数は28608でした。そのうち376アクセスされたので、Xを芋おくれた人の1.31%がconnpassに来おくれた蚈算です。 アンケヌトの結果、むベント参加者の39%は元々KTCを知らなかったこずがわかりたした。connpassぞの蚪問者1356人に圓おはめるず、その39%=箄530人が元々KTCを知らなかったこずになるので、それだけの人数にKTCを認知しおもらうこずに成功したした匷匕 むベント前埌で比范するず、自瀟で運甚しおいるXアカりントのフォロワヌは少し増えたした。コヌポレヌトサむトずテックブログのPVやUUも、むベント圓日はい぀もより少し倚いかな、ぐらいでした。ですが、少しでも確実に効果があるこずがわかったので、2回目以降も匕き続き蚈枬改善を続けおいきたいず思いたす 告知サむト準備 たずめるず むベントを告知する媒䜓ずしおconnpassを遞択し、むベント情報ペヌゞを準備したした。 「どんなむベントが人気なのか」ずいうこずを、ランキング䞊䜍のむベントから孊び、自分達のむベントに実装したした。 connpass自䜓は非垞に簡単にむベントを䜜成できるサヌビスで、ペヌゞ䜜成に苊劎はしなかったので、その分タヌゲットの蚭定ず、䌝えるメッセヌゞに気を配りたした。 想い はじめおの開催むベントなので、参加者0人は怖すぎる。。今の自分達にできる最高のペヌゞを䜜るこずを決めたした。 やったこず、考えたこず たずは倖郚サヌビス利甚のために瀟内申請をしたした。初めお取匕する/利甚する事業者の堎合は担圓郚眲でチェックが必芁なのですが、ここは問題なくクリアしたした。 そしお申請にあたっお管理方法を定めたした。簡単に管理目的・管理察象・利甚目的を定めた䞊で、システムずアカりントの管理者を定め、具䜓的なアカりント管理方法を簡単に決めたした。 申請が降りお実際にconnpassを觊れるようになっおからは、たず蚭定可胜なすべおの項目を掗い出しお確認したした。次回以降のむベント開催時の手匕きずしお残しおおきたかったのず、䞍可逆な蚭定項目がないかを確認したかったのが理由です。「参加費なしのオフラむンむベント」ずいう範囲で確認した結果、倉曎䞍可、もしくは制限のある項目は以䞋の぀だけでした。 グルヌプ倉曎䞍可 参加内容.参加枠参加枠は 申蟌者がいない間だけ 削陀可胜 ほずんどの項目は倉曎可胜でした。でも開催日時や䌚堎などが倉わったら参加者は混乱するので、远加はしおも、倉曎/削陀はしないほうが良いず思いたす。 むベント情報ペヌゞの仕様を確認するのず䜵せお、人気のむベントを分析したした。connpassのむベントランキングを眺めお、自分達のものず同じ属性のむベントのうち「なぜかめっちゃ人気なむベント」を20個ほどピックアップしたした。それらを順番に眺めお、倧切だず感じる芁玠を抜出しお抜象化し、自分達のむベント情報ペヌゞに適甚したした。 仕様ず考慮事項がわかったので、ここで改めお、基本蚭蚈チックな郚分を固めたした。「むベント情報ペヌゞ」ずいう詳现蚭蚈の前に、そもそもの勉匷䌚の意図を具䜓化し、①タヌゲットずなるナヌザヌ、②メッセヌゞ、③コミュニケヌションの基本ルヌルを蚀語化したした。 ①タヌゲットずなるナヌザヌ 「勉匷䌚に積極的なコヌポレヌト゚ンゞニア」をタヌゲットに蚭定したした。「他瀟事䟋を知りたい」「倖の情シスず繋がりたい」ずいうニヌズを仮蚭定し、そこに察しおむベント情報ペヌゞの文蚀を䜜成したした。 ②メッセヌゞ 「他の䌚瀟の情シスっおどんな感じでやっおるの」をざっくばらんに話したしょうずいうメッセヌゞを眮きたした。「勉匷䌚文化を広げたい」ずいうのがKINTOテクノロゞヌズMeetUpの䞻題で、自分達も䌝えたいし、他の人たちの話も聞きたい。それを実珟するために、座談䌚ずいう枠組みを蚭け、内倖問わず語り合う堎を䜜りたいず考えたした。 ③コミュニケヌションの基本ルヌル 「むベントはあくたで勉匷ずしおのむンプットずアりトプットの堎ずする」ずいうこずをルヌルずしお定めたした。せっかく来おもらったんだから、事業のこず、採甚のこず、KTCの良いずころをアピヌルしお蚎求したい。。ずいう想いはグッず抑えお、あくたで「情シスによる情シスのための勉匷䌚」ずいうずころを培底したした。 むベントを公開する段になったらテクニカルな話ずしお、定員数を少なめからスタヌトしお、必芁になったら匕き䞊げる䜜戊にしたした。 枠がギリギリの方が駆け蟌み需芁が芋蟌めそうなので 申し蟌みが少なくおも恥ずかしくないので重芁 結果 こんな感じになりたした 【第1回】KINTOテクノロゞヌズ MeetUp - connpass 人気のペヌゞを眺める䞭で埗た孊びは、以䞋のような芁玠です。 誰に向けたむベントか、参加した結果䜕を埗られるかが明確だず人が来やすい 安心できそうなむベントだず人が来やすい 有名䌁業、有名人など 過去のむベントの雰囲気がわかる画像や動画があっおもいいかも 旬なトピックChatGPTなどは人が集たるようだ 開催日盎前にリマむンドするための通知メヌルも掻甚したした。告知から開催たで期間が空いおしたう堎合には、参加者ず運営サむド双方のモチベヌションを保ち続ける意味合いでも、タむミングを芋おリマむンドするこずをおすすめしたす。 セッション取りたずめ 抂芁 圓日の段取りを包括的にたずめたした。 具䜓的にはむベント圓日のタむムテヌブルの䜜成、座談䌚の䌁画ず䌚堎レむアりト決め、発衚資料の取りたずめ、むベントの進行管理など。 初めおのむベントでしたが、スタッフ党員でプロアクティブに仕事を探したくった結果、倧きなトラブルもなく、楜しくむベントを終えるこずができたした 重芁なポむント 「初めおのむベント」 実斜内容/考慮事項 むベント圓日のタむムテヌブルの䜜成 座談䌚の䌁画ず䌚堎レむアりト決め 発衚資料の取りたずめ むベントの進行管理 実行結果 倧きなトラブルもなく、楜しくむベントを終えるこずができたした。 初めおのむベントで、䜕が起こるか予枬が぀かない䞭で、スタッフ党員アドレナリンMAXで目を光らせおいたした。誰の圹割でもない仕事、タスクにならないタスクを、1人1人が胜動的に探し続けたからこそ成功したむベントだず思いたす 登壇者による「事䟋発衚資料」の準備 「事䟋発衚」は、今回の勉匷䌚におけるメむンコンテンツです。勉匷䌚での登壇経隓も人それぞれであっため、倧枠の流れを揃えた䞊で、定期的に合流するポむントを䜜り、取り残される人が出ないように資料準備を進行したした。 スラむドテンプレヌトの統䞀 「発衚資料の䜓裁は敎えた方が良い」ずいう刀断から、利甚するテンプレヌトの統䞀をおこないたした。自瀟甚のスラむドテンプレヌトは存圚しおいたため、こちらはスムヌズに合意できたした マむルストヌンを区切った締め切り蚭定 ギリギリたで締め切りを蚭定するず、人により進行のムラが出おしたうため、以䞋のようなマむルストヌンを区切り、党員の資料䜜成スケゞュヌルを揃えおいきたした 初回の短期締切ザックリ「2週間埌」を締め切りに蚭定し、そのタむミングで皆の様子を確認 芋せ合いっこ䌚「できおいない」事を責めず、だけども「資料䜜成」を促す盞互確認䌚の実斜 副瀟長レビュヌ事前に副瀟長のお墚付きをもらうべく、そこに向けた「完成版」の締切を蚭定 事前リハヌサル開催の䞀週間前に「発衚者同士でのリハヌサル」を実斜し、完成床を高める 結果ずしお、最埌の「事前リハヌサル」においおは、皆さんほが「資料完成」「時間枠内に収たる」圢での準備を終え、安心しお開催圓日を迎える事ができるようになりたした。 最埌に このような圢で、事務局のメンバヌがプロアクティブに掻動しおくださった結果、無事に圓日の開催を迎えるこずができたした。 これはたさに、私たちがワヌキングスタンスずしお掲げる「 One Team, One Player 」が䜓珟できたひず぀の事䟋かなず思っおいたす。 ご参加くださった皆さた、運営に関わっおくださったすべおの皆さた、ありがずうございたす なお、今回の蚘事以倖にも、「運営スタッフ芖点でのテックブログ蚘事」や「登壇者による事䟋発衚の玹介テックブログ蚘事」が埌日公開される予定です。そちらもどうぞよろしくお願い臎したす
Introduction Hello, my name is Go Wada, and I am responsible for the payment platform backend in the Shared Service Development Group. The project I am in charge of has been engaged in Scrum-based development using domain-driven design since our team developed the platform. This article uses the experience gained there to give an example of how this was implemented efficiently by a team. What is "Domain-driven Design (DDD)?" DDD is a method of developing software. It is intended to improve software values and problem-solving ability through modeling. For example, we utilize use-case and domain-modeling diagrams to represent models. Moreover, we try to use ubiquitous language or in other words, to allow developers, business members, and everyone involved to engage in a dialog using the same terms. Of course, one of our goals on the technical side is to improve the quality of our code. For example, rather than creating tangled spaghetti code, we put together loosely coupled highly cohesive implementations that are resistant to change. We focus on preserving consolidation, "Tell, don't ask!" style checks, and on being aware of SOLID . *Addendum: "Domain" refers to the domain in which problems are to be addressed with software. Issues for our team Our team faced the following challenges in introducing domain-driven design. We chose DDD as a software design approach but it was more difficult than we had anticipated We learned individually so there were differences in our understanding The team was made up of people working together for the first time Conversely, the team's policies and vision for the future are: To move ahead with efficient development To improve the maintainability of our systems and increase the speed of function development in future development work (or alternatively, to avoid slowing down once we are on track) Development is an opportunity for learning, so we would like to learn well as a team. Group readings of proposals to address these issues There are a range of ways to address these issues, and we decided to confront them by holding group reading sessions where we read books on domain-driven design. Our aims were to: Read about DDD as a team effort Make learning efficient, with a deeper reach (improving our skills as a team) Gain a common awareness and an understanding of each other through the casual conversations that occur at the group readings Align awareness of assumptions to reduce pull-request conversations Create a sense of team unity through discussions and casual conversations at group reading sessions How we implemented group reading sessions We used the following methods to implement group reading sessions: We engaged in circular group readings of "Domain-Driven Design: A Modeling/Implementation Guide," by Koichiro Matsuoka https://little-hands.booth.pm/items/1835632 Everyone participated with the consent of all product members Once a week, people assigned responsibility for each chapter are nominated to make a 30-minute presentation They read their assigned chapter in advance, and create documents summarizing the important points The presentations take about 15 minutes, with discussions lasting approximately the same time Discussions at group readings Although this is written from memory, conversations generally went as follows. Consistency-wise it would be better if we only ever allow correct instances to exist This is how domain services should be (don't make careless mistakes, better to restrict responsibilities) Better to use specification objects as a single method of validation How to view value objects (it might be safer to use elements comprising aggregate routes as VOs) Aren't the presentation and application layers mixed up? The naming got confused What should we do about the architecture (layered architecture, onion architecture, clean architecture, etc.) Starting modeling Although we couldn't wait to get started on coding, modeling is also important, and so we periodically took time within each sprint to go over it with everyone. Team members who are familiar with payment-related systems and operations were appointed as domain experts. Since the payment system itself is implemented within the system, it is more important to be familiar with the details of the system than with the business. The content implemented was roughly as follows. Using miro, we used sticky notes to brainstorm concepts related to payment. Results of brainstorming We organized the resulting concepts and discussed the relevant points as follows. What payment-related actions are required by a payment platform? What chronological order should these actions take? Which are the aggregation routes? How can we organize the concepts to fit effectively? How are other similar systems organized? Image diagram of conceptual organization *We reevaluated this diagram every time we felt something was not right, as well as after brainstorming. Image diagram of brainstorming progress *Deformed image of work progress. We created domain-model and use-case diagrams of the results of our discussions. Domain model Domain model excerpt Of course, the model was not the end of the process, as we made numerous improvements. For example, initially we intended to make the payment aggregation payment card entity a dedicated aggregation. This was because we had an image of the payment card holding the payment company information, and we had decided that since this is an external system it would be easier to handle aggregation separately. However, any given payment generates information that this key value was used to deal with the payment company, which cannot be separated from payment. We reviewed our assessments so that they were strongly consistent, and decided to include them in a single aggregation. Use case diagram *Although we created use-case diagrams, we discarded them as their content overlapped with that of other documents. We created a glossary. During brainstorming and model creation, we noticed that each member used different terms to explain the same thing. That prompted us to create a glossary of appropriate terms that the team could agree on from the multiple terms that we were using. (We defined both Japanese and English terms.) To ensure that we use defined terms, members gently point out (jokingly) each other's mistakes when they use incorrect terminology. Take the example of a system in which a payment platform is to be installed, which requires contracts to be made for each so-called order unit before payment. We decided to call those contracts "Payment directives." This is because we thought that "contract" could be construed as having a range of meanings. Moreover, this glossary is intended to avoid confusion with terms used in other systems and products (outside the defined context). Glossary image Lessons and benefits from carrying out model and group reading sessions Group reading session Held in parallel with our regular work, the group reading sessions provided us with the following lessons and benefits. The amount learned and the precision of our products increases as we can apply the knowledge from these sessions immediately It is suited to Agile development because we soon have an opportunity to apply this knowledge The ability to have a common understanding improves quality because pull requests are viewed from different perspectives You develop an interest that encourages you to read other related material (you develop momentum to learn) You can learn systematically, not just areas related to your own work, making your learning more versatile You can be more active in these group reading sessions than in sessions on unrelated topics Active conversations create an even better team atmosphere that helps to counter the isolation of remote working *These sessions were very active, making timekeepers a necessity. Modeling Taking time to conduct modeling on a regular basis provided us with the following lessons and benefits. Although we tend to focus on implementation, we have gotten into the habit of basing our thinking on the model Looking at things on a model level gives us a feeling for the overall product When we are about to lose our way during implementation, we can go back to the model for clarification Outlook for the future Although we have implemented the practices described above, at the time of writing we have yet to put them into operation. At our current stage in development, we appear to be successful. However, we hope to assess whether these activities had merit and what their challenges were based on feedback we receive from actually using them in practice. Additionally, to a large extent, domain-driven design itself is more of a path for thinking than a deterministic methodology. We hope to acquire more knowledge, including the information acquired through our operations. Summary of what was learned through the practices described here At the group reading sessions, which were held in parallel with our normal operations, we learned that: It is possible to achieve input and output of learning, reflect learning in our products and the growth of our team's members all at the same time Work-based and experiential learning are linked All related personnel can be actively involved, and conversation used to create a sense of unity. The habits we have acquired through modeling showed us: Although we tend to focus on implementation, we learn to base our thinking on the model Looking at things on a model level gives us a feeling for the overall product, making implementation less localized When we are about to lose our way during implementation, we can go back to the model for clarification, making it more difficult to become confused
Hajimemashite! I’m Moji from UXUI team in the Global Development Group. At KINTO Technologies, my main role is product design, which I love because it blends my business knowledge with my design skills. I aim to create user interfaces that are easy to use, aesthetically pleasing, and generate measurable results. My ultimate objective is always to turn complicated problems into simple, user-friendly experiences that users find satisfying. I'm writing my very first article for the TechBlog! which is about the process of redesigning the TechBlog itself. Exciting, isn’t it? Scope and Obstacles In today's digital world, staying relevant requires constant renovation and reinvention. KINTO Technologies made a big change by deciding to redesign its TechBlog in two phases. Each phase had distinct objectives aimed at enhancing user experience and functionality, with a focused attempt to adhere to the KINTO design system. The image below demonstrates the scope of the redesign after consultation with the tech blog team. Redesign Scope Like navigating through an intricate maze, the redesign process brought along its own sets of challenges. One of the main challenges that demanded meticulous planning and execution was to align the newly integrated features with the KINTO design system , which is not static, but rather a dynamic entity that is constantly evolving, and had limited assortment of web patterns for desktop view only. Adding to the complexity was the timeline constraint, coupled with the requirement of redesigning for dual platforms - mobile and desktop views. The following images highlight key problem areas with the current design in both mobile and desktop views. Key problem areas in mobile view Key problem areas in desktop view Phase One: Focused on Usability and Accessibility The beginning of the redesign process primarily dealt with improving TechBlog’s usability and accessibility in both desktop and mobile . The implementation of a search bar was a major feature that facilitates straightforward access to relevant articles and information. This functionality will make it seamless for readers to navigate through an extensive range of blog content. Search bar in mobile view Search bar in desktop view The integration of category tags was another major improvement in this phase. This feature allows readers to sort and scan through technology-related topics effortlessly, enriching the process of content exploration and further enhancing the browsing experience. Category tags in a scrollable carousel format Category tags are affixed to the right-side bar A critical visual change made at this stage was adjusting the size of the blog posts in the homepage. This change, carried out for both desktop and mobile views, helped ensure a harmonious balance between the readability of the content and the overall visual appeal across all devices, thereby elevating the user interface. Displaying the before and after size of the blog posts in desktop view Phase Two: Cementing Functionality and Multilingual Access During the second phase of TechBlog redesign, other meaningful features were integrated, leading to an uplift in overall functionality and user experience. Notably, a language switch was introduced, catering to English and Japanese readers. This feature, despite initial challenges due to space constraints in the top navigation bar (mobile view), was eventually included in a manner that gave readers an effortless switching between language options. Language switch in mobile view Language switch in desktop view This phase of the redesign also involved adjusting the index placement on the article page for mobile view, ensuring streamlined navigation within lengthier blogs. Index placement for mobile view Additionally, social media buttons were replaced, promoting easy sharing and driving more user engagement in desktop view. Sharing buttons placement for desktop view To guide users who might stumble upon non-existent or removed pages, a 404 page was also designed as part of this phase. Additionally, a direct link to the recruitment section of KINTO Technologies was nestled at the end of each article, serving as a warm invitation to tech-savvy readers to explore potential career opportunities. Mobile view Desktop view Furthermore, during this phase, a feature was incorporated allowing articles to be searched by the writers' names. Two formats were designed for this purpose: The single author format that accommodates multiple writers under one profile, with clickable names to sort articles written by them. The multiple authors format that gives each writer a dedicated profile in addition to being able to sort articles by their respective names. The second format was less prioritized, so the development team proceeded with the first format, ensuring enhanced user experience with a more streamlined author profile approach. Mobile view Mobile view Desktop view Desktop view Objectives The cardinal objective steering this redesign was a commitment to enriching the user experience. Every tweak, addition, and adjustment were aimed at facilitating easy navigation, broadening access to relevant content, and enhancing the overall user interface. illustrating the before and after redesign in both mobile and desktop views The KINTO design system played a key role. While relying on this system, adaptations were also made. Steps were taken to build some components from scratch and tweak some other components locally within the file to meet the precise requirements. This approach balanced adherence to the dynamic design system with the unique functionality needs of the Tech Blog. The following images demonstrate how the footer component , originally designed for the Tech Blog use case, can be applied to various projects after being added to the KINTO design system . Mobile view of the footer component example Desktop view of the footer component example Anticipated outcomes Here's a glimpse of some major expectations: The introduction of integrated search bar and category tags should enable effortless navigation through articles, taking away the hassle and significantly improving the reader's content discovery process. The inclusion of a multilingual feature aims to dissolve language boundaries and make the articles comprehensible to a diversity of readers, particularly those who are English or Japanese speakers. The aesthetic charm and practical utility of the blog posts are anticipated to flourish with the design amendments. Enhanced features such as social media sharing buttons, devised 404 page, and adjusted article post sizes are expected to notably boost user engagement. We foresee that adding a link to potential career opportunities at the end of every article will serve as an effective bridge connecting our tech-inclined readers and KINTO Technologies' recruitment space. This two-phase redesign is currently in implementation and aims to strike a balance between aesthetic appeal, enhanced functionality, and increased usability. Upon completion, a usability testing process might be adopted to gather feedback from readers and ensure the redesign has achieved its set goals. Next Steps The journey of redesigning marked the beginning of a continuous improvement process. The local components tweaked and designed for the TechBlog redesign will now be evaluated for potential inclusion in the KINTO design system. Once confirmed, they'll be made available for use across other projects. This opens up a new world of opportunities, extending this redesign's positive impact beyond the blog and into future integrations. I’m excited to see how this redesign continues to shape the platform's future developments as KINTO Technologies continues to evolve in the fast-paced digital world. References KINTO Technologies - TechBlog KINTO Technologie - Corporation KINTO Technologies - Recruit Nielsen Norman - Usability Testing
Introduction My name is Kinoshita, and I am from the my route Development Group. Normally, I do advanced development for Proof of Concepts, spanning mobile, front-end, and back-end development. I was given the opportunity to take the Licensed Scrum Master Training, which I passed successfully, granting me certification as an LSM. This is an account of my journey to gaining this certification. What is LSM? The LSM is a certification from Scrum Inc. awarded to those who take the Scrum Inc. certified Scrum Master training course and pass the exam. There are multiple Scrum Master certification bodies, with each granting different titles for the same certification. Title Certification Body URL Fee License Renewal Fee LSM, Licensed Scrum Master Scrum Inc https://scruminc.jp/ 200,000 JPY (tax excl.) $50 / year CSM, Certified Scrum Master Scrum Alliance https://www.scrumalliance.org/ 300,000 JPY (tax incl.) $100 / year PSM, Professional Scrum Master Scrum.org https://www.scrum.org/ $150 N/A [Reference: https://www.ryuzee.com/faq/0034/] LSM is a two-day course comprised of lectures and workshops. Completing the course qualifies you to take the examination. The certification must be renewed every year, for which a $50 fee must be paid and the examination passed each time. As such, you have an opportunity every year to consider whether you want to maintain the certification. Reasons for Obtaining Certification KINTO Technologies is aiming to be a cutting-edge online business organization. To that end, it is currently working to change those factors within the Japanese manufacturing industry that hinder progress in terms of culture and the environment, while also tearing away vendor locks, making improvements to legacy systems, systematizing business flows, and other digital transformation (DX) activities. As the company proceeds down this path, there have been a greater number of opportunities for it to choose Agile software development as its methodology. In fact, even the group that I belong to has been choosing to use Agile. And, in reflection of that fact, my manager recommended to me that I take the Scrum Master Training. As in many small-scale development teams, the my route team that I belong to also only has a small number of team members, and, so, it is the case that the Product Owner and Scrum Master roles are fulfilled by the same person. After the recommendation, I talked with a number of friends and colleagues who were both developers and Scrum masters and I began to become more interested in taking the training. I talked again with my superior and, based on the following, decided to take the training. It was not vital that I become a Scrum Master and there would be no issues if I didn't get the certification; however, given that it was not something I had learned systematically up until that point, it seemed like a good opportunity to educate myself; In pushing forward with Scrum and Agile, it might be possible for me to build a Scum personal network; For example, at seminars, I might be able to exchange information on how to utilize Scrum and Agile with people from companies who are facing similar organizational issues as our company; and As a developer, learning what other Scrum Masters think and feel about issues has many benefits in terms of knowing how to respond to these issues. Reasons for Selecting LSM Given that my goal was not to simply gain certification, PSM was not an option for me. Early on, I learned from someone in my company about the well-known CSM certification; however, I was then recommended by another colleague to look at LSM, through which I might be about to build a Scrum community network. Also, I saw that TRI-AD (currently, Woven Planet Holdings, Inc.) of the Toyota Group had adopted it and that it had proven a good match for the company. This increased confidence in LSM within the company and was the reason why I ultimately went with that particular certification. Prior Knowledge With regards to my prior knowledge of what being a Scrum Master comprises, I had read SCRUM BOOT CAMP THE BOOK and the Scrum Guide . In terms of actual experience, while I hadn't worked in any organization that had formally adopted Scrum, I had worked in teams that had loosely incorporated Agile. Contents of Training The training was held online over Zoom. It basically comprised of workshops with participants split up into teams, and lectures. The day before the training, I received an e-mail including the following content: Scrum Guide Glossary Text Zoom Worksheets for Each Team I received a URL for an online white board tool called MURAL . I was able to download completed worksheets in PDF format. The content of the actual course was in-depth academic study into Scrum Master, including its history, what you should do with it, and what actions you need to take to achieve that. With regard to organizing members, team-building exercises were held immediately before the training began where I got to know the other members I would be working with for the first time. I took the training together with a number of colleagues from my company, but a lot of care was put in to not pair people up with other people from the same companies or similar industries. In my team, I was paired with people from completely different industry backgrounds. Because of this, I was made aware of different views and exposed to different knowledge sets that I would not be able to experience in my daily work duties. Progress through the training took the form of moving from classroom type learning to workshops with completion of each learning step, whereby questions were posed to which the goal was to demonstrate understanding of the content by answering said question or putting into practice what we learned. There is a lot of content to learn, and, personally speaking, I felt that the lectures were often longer than the workshops. However, if I hadn't paid attention to the content of the lectures, I wouldn't have been able to do anything in the workshops, so it was important that I maintained my concentration levels for the whole two days. Examination I became eligible to take the certification examination immediately after completing the training course. Although there was no time limit on answering questions, I felt that there were many questions which really tested your depth of understanding in the sense that if you did not understand the content of the training or the texts or Scrum Guide, you would not be able to answer them. For those who are not so experienced in Agile and Scrum, the examination might prove quite tough. However, it does seem as though you can retake the examination free of charge up to one extra time (I passed on my first attempt, so this is just what I heard about retaking the examination during the pre-examination description.) Therefore, there are multiple opportunities to pass. Summary/Thoughts The team mentors and members were cheerful and approachable, with a warm atmosphere present throughout the workshops. Being able to interact in the workshops with people from industries I do not normally come into contact with was really refreshing and a real plus point of the whole experience. However, seeing as how the training was held remotely, there was little interaction, and the speed and depth at which we could open up to one another was drastically reduced compared to meeting in person. Also, one of the people I took the training with seemed a little distant on the first day, never really opening up to the others. Upon listening the interactions of the other team members, they suddenly declared "I'm so jealous". I guess there might be an element of luck involved in whether the team building exercises go well, based on the personality and skill of the members and trainers. (That same person began speaking a lot more on the second day. Clearly, for them, ice-breakers are extremely important. After that, they seemed to settle down much more.) As for the training itself, it was an in-depth academic study of the role of a Scrum Master. The training did not teach how to resolve issues found in organizations that are unable to incorporate Scrum, and so, it was not a silver bullet that would help me fix all the issues I encounter in my daily work duties. It is the responsibility of the individual to find out how best to apply what they learned in the training to their team, organization, or job. For this reason, companies who are able to incorporate everything taught on the course into their organizations and make effective use of that knowledge are rare. Therefore, it is important that each company sees for themselves which aspects are best suited to their setup. If possible, I think it would be great if there were some opportunity to meet with and share knowledge with the people from outside of your company who you took the workshop with or those who have taken the training in the past. I think that would help people broaden their knowledge base and make the training even more effective. Thoughts on how to make use of the training within my company When I talked with some of the other people I did the workshops with, I realized that many of them also found it difficult to make use of Scrum within their organization and that they were facing similar issues to our company. Based on those conversations, I think that the following three patterns are fairly common: If you know what you want to build, Waterfall is more suitable than Scrum If you haven't decided exactly what you want to build and are going to build as you go, Scrum is suitable If there is a free atmosphere in which multidisciplinary teams can be formed as part of efforts to improve a given service, Scrum is suitable In order to make maximum use of the content of the training in your company, you need to ensure there is an environment in which that learning can be applied in the way you imagine. However, doing this from the get-go is easier said than done. I would like to conclude by saying that by making incremental efforts through occasionally correcting the product increments at which the definition of complete breaks down, and searching for ways on how to connect the small individual scrum teams dispersed throughout the company as part of efforts toward Scrum of Scrum , I think it will be possible to make improvements to the current situation.
Introduction Hello. My name is Kairi Watanabe and I work in front-end development at KINTO technologies. As a member of the KINTO development group, I normally work on the development of KINTO ONE services for use in Japan using frameworks such as React.js. The KINTO development group is made up of engineers and accepts multiple new members each month. However, it can be difficult for us to understand the business domain in its entirety when working with a system that is so large in scale. For this reason, we hold orientation training targeting mid-career hires every month in order to support new members and enable them to start playing an active role as soon as possible. In this blog post, I will talk about why having orientation training targeting mid-career highs is important and also about some of the content of actual orientations held in the past. Announcements of in-group orientations Reasons for implementing orientation training So that mid-career hires can play an active a role in the company as soon as possible, it is vital that they become accustomed to the work environment at an early stage and that in-team inter-personal relationships are built through daily communication. There are probably some people who think, unlike with new graduates, orientation training is unnecessary as they already have some actual work experience. However, it is not necessarily the case that mid-career hires will always immediately adapt to changes in their work environment. I think that some hires may not understand how the new workplace functions relative to their previous one, or may not understand specialist terminology specific to the industry or the company. In those cases, I think some might feel anxious or lacking in motivation, even though they have only just joined the company. Before we implemented orientation training in our team, we sometimes would have members who would sit at their desks at a loss, not knowing what to do until they were assigned a specific task. It can also be a burden for senior employees to have to keep using spare moments in their day to provide education to these hires at every step. To help tackle this issue, the KINTO development group believes that holding specially designed orientation training can really help eliminate the anxiety and confusion felt by mid-career hires and thus have a positive impact on their subsequent ability to perform their duties. In order for mid-career hires to settle into the company as quickly as possible, we have designed and implemented orientation training aimed at achieving the following three goals: To deepen understanding of KINTO services To ensure awareness of their specific role and company values To develop a fondness in the hires for the working environment and workplace Four-Stage Approach to Creating Orientation Training I would now like to talk about the four stages of orientation training that we have held thus far. Each session lasts around 60 minutes, with a senior employee taking the role of lecturer. Introduction to Product Team (Welcome to the KINTO development group!) In this orientation training, we talk about which teams within the group do which types of work, using a correlation chart with the faces of employees for reference. We hear from a lot of people that they feel uneasy when they first enter the workplace after joining the company because they cannot match people's faces with their names. This is the first type of orientation we do. By letting the new-hires know who is who in the team and who the product members are, they are better prepared to know who to ask if they are unsure about anything in their work duties. Description of services and work-duties (Hands-on experience of the service flow!) This type of orientation involves experiencing the flow of KINTO ONE's services through hands-on learning with example scenarios. By role-playing various types of people the new-hires may encounter as part of their duties and having them operate the online display accordingly, they can get to know the various stakeholders they will encounter in their work duties in future. Also, by using diagrams to introduce stakeholders and other matters like terminology, even those people not directly involved in the automobile industry can gain a deeper understanding. Overview description of system (Understanding the systems and technologies the group uses) In this type of orientation training, we take a bird's eye view of what goes on behind the scenes of the system our group uses. By introducing the new-hires at this early stage to the structural elements, functions, and interactions of the system in its entirety, we believe it is possible to clarify in the new-hires their own responsibilities and areas of specialization, thereby facilitating their introduction to the project. We also run a Q&A regarding the tech stack during this orientation stage. Welcome lunch (Get to know senior employees and the company culture) This is actually the most important stage of the orientation in my view. By allowing the new-hires to speak openly with other senior employees, they are able to get a real sense of the atmosphere within the company. The goal of this stage of the orientation is to drop the formal content for a while and to make the new-hires feel at home within the group. The company has a number of foodies who love to share information on good lunch spots around the office using the Slack channel 😋 (Expect the conversation to get pretty lively if a place with tatami or a sunken kotatsu is chosen! Haha!) What we have learned from implementing orientation training The monthly orientations help us improve knowledge and uncover issues people are facing. No fixed structure to orientation training Just like with normal development work, orientation training needs to be designed and implemented. Because the mid-career hires are often of different backgrounds and ages, we need to break down, explain, and discuss the content together with the members. In order to help those hires who are not particularly familiar with automobiles gain a greater understanding of the content, we use charts featuring the various stakeholders involved in the service provision as part of our explanations and ask questions back to the hires to help ensure they have not misunderstood the explanations. Once the entire orientation is complete, we ask the new-hires to answer a questionnaire used to measure their degree of understanding of the content and of its effectiveness. This knowledge is then utilized to provide better orientation training in future. One of the most interesting things about the orientation is that it can be customized each month. Improving connections between new-hires I think that those mid-career hires who feel a little uneasy just after joining the company can find support in other members who joined at the same time as them. Because new members go through the training and hands-on experiences together, you often also see them going through the same process of trial and error together in their actual duties. For that reason, we created a Slack channel for use by new hires and the persons running the orientation training as part of efforts to facilitate communication with their fellow new-hires in a way that is approachable. We actually hear from a lot of these hires that they find it easier to express themselves in smaller groups than in Slack channels with lots of other people in it. Allowing the orientation training to be an opportunity to improve the relationships between new-hires is one of the greatest rewards of hosting such training. Improving understanding of the work of senior employees (persons in charge) Orientation comprises lecture type sessions hosted by senior employees. When we are preparing documents for the orientation, we invite feedback from people in other groups and do some hand-on work ourselves to try and uncover any elements we might have been unaware of previously. For that reason, it is necessary to periodically update the documents. People have a tendency to think that orientation training is only for new-hires, but it is also something that can be very meaningful for senior employees. To this end, we also share the aforementioned questionnaires with the senior employees. Summary The most worthwhile effect of orientation training in an organization for engineers is to get rid of any feelings of anxiety in new members and to increase knowledge of their duties in a short and concentrated period. This hopefully will then enable them to begin contributing to the project as early as possible and begin providing value to users. Mid-career hires tend not to have many opportunities to receive detailed guidance. The tendency is for them to look things up for themselves if they don't understand something. Obviously, learning for yourself how to resolve a problem is best, but I think that by creating a system to support new-hires, we will be able to build a team in which communication is smooth and encouraged. Moving forward, I would like to continue to update the orientation training using questionnaires and other tools such that we can better support mid-career hires. Also, by having a large number of group members involved in the orientation, I believe we can create a more multi-faceted form of communication and higher quality and more customized types of training. I would love to hear from others about the types of interesting orientation training sessions going on in their companies.
はじめに こんにちは、KINTOテクノロゞヌズの森野です。2023/6/29朚30日金に、同僚ず二人で愛媛県束山垂で開催されたサむバヌセキュリティシンポゞりム道埌2023に参加しおきたした。開催趣旚は、コロナりむルスず共存する瀟䌚の進展に䌎い、デゞタル化が加速する䞭で、サむバヌ攻撃ぞの察策が重芁になっおいるこずを認識し、「地域SECUNITYの力でサむバヌ攻撃ず戊う」をテヌマに、政策動向や技術動向、攻撃事䟋などに぀いお議論を深めるこずを目的ずしたものです。私たちは、講挔や他の参加者から倚くの刺激や孊びを埗るこずができたした。 束山空枯に到着するず、愛媛県のむメヌゞアップキャラクタヌであるみきゃんがお出迎えしおくれたした。みかんゞュヌスタワヌやみかんゞュヌスの出る蛇口もありたした。 シンポゞりムでは、倚くの興味深い講挔や発衚がありたしたが、私が印象に残ったものをいく぀かご玹介したいず思いたす。講挔や発衚の䞀芧は こちら からご確認ください。 我が囜のサむバヌセキュリティ政策 たず、基調講挔では、山内智生氏総務省サむバヌセキュリティ統括官宀サむバヌセキュリティ統括官が「我が囜のサむバヌセキュリティ政策」に぀いお講挔されたした。山内氏は、「誰も取り残さない」ずいうテヌマのもず、自由、公正か぀安党なサむバヌ空間の確保に぀ながる囜ずしおの取り組みを説明され、重芁むンフラのサむバヌセキュリティに係る行動蚈画の改定や、サむバヌセキュリティ月間のタヌゲットの倉曎、政府機関におけるクラりド利甚の改善などを玹介されたした。「誰も取り残さない」ずいうテヌマが非垞に玠晎らしいなず感じたした。 セキュニティセキュリティコミュニティ、そしお生成AI 次に、ナむトセッションですが、私は濱本垞矩氏株匏䌚瀟゚ネルギア・コミュニケヌションズ ITむンテグレヌション郚ずたっちゃだいふく氏株匏䌚瀟ラック テクノロゞヌリスクコンサルティング郚のお二人による「セキュニティセキュリティコミュニティ、そしお生成AI」の講挔を拝聎したした。濱本氏は、セキュリティずコミュニティを組み合わせた造語であるセキュニティに぀いお説明したした。セキュニティずは、セキュリティに関心を持぀人々がオンラむンやオフラむンで亀流し、知識や経隓を共有し、協力し、孊び合うこずで、セキュリティの向䞊に貢献するコミュニティのこずだず理解したした。続いお、生成AIに関する知芋を共有しお頂きたした。発衚資料は こちら から参照可胜です。セキュリティの芳点ではログから䞍審なアクテビティを怜出するなどの掻甚に期埅を持った䞀方、巧劙なフィッシングメヌルの生成等ぞの悪甚を懞念したした。 孊生研究賞受賞研究発衚䌚 最埌に、二日目の孊生研究賞受賞研究発衚䌚では、優秀な孊生達が自分の研究成果を発衚したした。シンポゞりムの参加者が、最も良いず感じた発衚に投祚する仕組みで、私は、「TRPGを参考ずした個人向けサむバヌ挔習のKPレス手法の提案」ずいう発衚に投祚したした。この発衚は、藀本恵莉華さん長厎県立倧孊倧孊院 地域創生研究科が行ったもので、個人向けのサむバヌ挔習シナリオずしお、TRPGテヌブルトヌクロヌルプレむングゲヌムを参考にしたKPレスキヌパヌレスの挔習手法を提案されおいたした。キヌパヌレスずは、TRPGでゲヌムマスタヌの圹割を担う人がいない状態のこずを指したす。セキュリティ担圓者ずしお埓業員の情報セキュリティ教育に぀いお日ごろから関心があるため興味を匕かれたした。幎代がばれおしたいたすが、私が小孊生高孊幎から䞭孊生の頃、 ゲヌムブック が非垞に流行りたした。その手法を取り入れた挔習だず理解したした。 たずめ 以䞊が、サむバヌセキュリティシンポゞりム道埌2023の講挔や発衚の䞀郚です。他にも倚くの有益な講挔や発衚がありたした。このシンポゞりムは、サむバヌセキュリティに関する最新の知芋を孊ぶだけでなく、同じ分野に興味や関心を持぀人々ず亀流するこずができる貎重な機䌚でした。䞻催者やスポンサヌ、参加者の皆さんに感謝したす。
Introduction I'm Chris, Front End Engineer for KINTO Technologies. I am part of the Global Development Division and, as is usual for an multinational team, we communicate primarily in English, whether for casual chats or for technical conversations. My team develops interfaces for local services and back-office systems for various countries. When developing multiple projects at the same time, improving the efficiency of the development work is crucial. Today I would like to talk about the front-end perspective. Problems to Solve KINTO services have already been deployed in more than 20 countries worldwide and while business structures, development systems and business practices differ from country to country, one of the challenges we face is achieving consistent UI/UX on a global scale. To solve this problem, we are developing a design system specifically for KINTO services, which is the background to this article. Since implementing a design usually involves front-end development of HTML/CSS/JS, communication between designers and engineers is essential to ensuring work proceeds smoothly. If multiple designers work on a design without coordination, the style of the design will end up disjointed and developers may need to create unique components for each project. Having many projects in this state presents three major disadvantages for a company. Because each project requires its own development work, costs increase dramatically in proportion to the number of uncoordinated projects If future designs or the person in charge of development changes, the style and the design approach may also change, making maintenance difficult Even for users who aren't aware of the internal development process, uncoordinated design can result in an inconsistent experience and make using the product stressful Approaches An Easy Way for Designers and Engineers to Review Designs One way that designers can tackle the issue mentioned above is to prepare design guidelines that define the approach for the various components and to design UI/UX with these guidelines in mind. However, simply looking at guidelines for things such as color, font or prohibited items will not directly reduce the development time, so it is also important to think about what engineers can do. On the development side, one approach is developing components in cooperation with the designers that can be reused anywhere and insert them into every project. As a first step, I thought it would be beneficial to have somewhere to review these components all in one place, so I would like to introduce the "Storybook" tool. Developing Components Using Storybook Storybook is an open-source tool for developing and documenting components individually. Using this tool makes it possible to see at a glance which components can be reused. There are installation guides for each JS framework on the official site, but since the Global Development Team uses Vue.js, we followed this guide to set up the environment. Developing and Managing Components as Story Units One feature of Storybook is the grouping of similar components as a unit called a "Story." For example, a component that we call a "button" may be used in a variety of different ways on a website (a primary button that prompts user action, a secondary button used for other purposes, a smaller button that is used for only limited purposes, a long button etc.). These various buttons can be grouped together using a file called xxxx.stories.ts . (If you prefer to use JavaScript, use xxxx.stories.js .) In addition, when actually using a component, Props may be passed on. Accordingly, you can use a feature known as "Controls" to pass on all kinds of Props. For buttons, for instance, we set the "disabled" attribute to prevent them from being clicked, but if we add the corresponding Control to the Story file, the value in the UI changes and we can check to see how the component changes. Documenting Components If you follow the guide on the official site to install Storybook, the @storybook/addon-essentials library is included automatically. As its name suggests, this is a library that contains add-ons that you might need. One of these add-ons is @storybook/addon-docs , which gives each Story its own documentation. After clicking on each Story, the Docs tab should appear in the UI. Storybook automatically creates documentation using information taken from pre-written Story files, but if you would like to create your own documentation, you can set a file created from the Story file as a parameter and this will be reflected in the documentation (in the example below, a markdown file has been set as the parameter). import ButtonDocument from '@/docs/ButtonDoc.mdx' export default { title: 'Components/Buttons', parameters: { docs: { page: ButtonDocument, }, }, } Adjusting the Storybook UI to Reflect Company Identity Although using Storybook to render lots of reusable components and documentation is helpful, if all sites looked like they used Storybook design, it would be difficult to get a sense of a company's identity — so we set to work on the layout as a whole. Specifically, we replaced the logo with our company's logo and fonts, then adjusted font size and colors. As is the case for implementing documentation, @storybook/theming must also be installed to make these changes. Since this is included in @storybook/addon-essentials , you can start by creating a manager.js file in the .storybook directory and specifying a specific theme. For reference, our company uses the following settings. import { addons } from '@storybook/addons' import { create } from '@storybook/theming' addons.setConfig({ theme: create({ // This is a base setting included in Storybook: you can pick between "light" and "dark" base: 'light', brandTitle: 'XXXX XXXX', brandUrl: 'xxxxxxxxxxxx', brandImage: 'Image path', brandTarget: '_blank', appBorderRadius: 10, textColor: '#2C353B', textInverseColor: '#FFFFFF', barTextColor: '#2C353B', barSelectedColor: '#00708D', }) }) The company's identity is much clearer now, but there are further adjustments that can be made to customize the appearance of our site by using CSS directly. If you create a file called manager-head.html in the .storybook directory mentioned earlier, CSS code written in this file will be reflected in the Storybook UI (you will need to restart the development environment). As an example, below is the UI after adjusting it for our company. You can now render commonly used components such as buttons and a variety of input methods. Afterwards, you can prepare an environment that coworkers can view, allowing involved parties to review it. Next Steps Using Storybook, we developed each component and made them available for designers and developers around the world to use as reference. But this measure is just the first step. We are already working on various things in-house, but we have listed a few below that we would like to be able to do in the future. Publish Case Studies Using Multiple Components Together Rather Than Individual Components There are templates available that use multiple components together. For example, a log-in form is composed of an email address and password field, a checkbox for remembering log-in status and a "Login" button. However, being able to review these components together in Storybook would help development proceed much faster. In the future, we would also like to be able to review page units. Publish Component Libraries If there are components that you want to include in your own projects, for example, you currently need to copy the required source code from the Storybook repository. In addition to the possibility of copy errors, if you want to change component specifications in the future, you would need to modify the source code of every project that has already been completed. By writing private libraries and installing them in every project, components can be easily reused. The benefit of this approach is that when new components are completed or the specifications of existing components are changed, these changes can be reflected simply by updating the version using a package manager (of course, this does require thorough enforcement of a version management process). Final Thoughts about Storybook The introduction of this tool is just one step towards the development of a universal design system, but many of the benefits of using Storybook in the development process were apparent the very first time we used it. Developing components individually makes it possible to separate them from dynamic elements and focus on adjusting their appearance Using Stories makes it possible to reproduce actual use cases The person in charge of each project can use this tool as a reference when developing interfaces We hope to continue introducing Storybook throughout the company to promote efficient interface development.
Hello, this is Awache ( @_awache ), a Database Reliability Engineer (DBRE) at KINTO Technologies (KTC). In this blog post, I would like to talk about the Database guardrail concept that I want to implement at KTC. What are guardrails? "Guardrails" is a term that is often used in Cloud Center of Excellence (CCoE) activities. In a nutshell, guardrails are "solutions for restricting or detecting only realms that are off-limits, while ensuring as much user freedom as possible." Based on the characteristics of the role of dealing with the realms of a database, where governance must be emphasized, DB engineers sometimes act as "gatekeepers" which hinders the agility of corporate activities. Therefore, I am thinking about incorporating this "guardrail" concept into DBRE's activities to achieve both agility and governance controls. Types of guardrails Guardrails can be categorized into the three types below. Category Role Overview Preventive Guardrails Restrictive Applies controls that render the operations in question impossible Detective Guardrails Detective Mechanisms that discover and detect when an unwanted operation is carried out Corrective Guardrails Corrective A mechanism that automatically makes corrections when unwanted settings are configured Preventive guardrails ![Preventive guardrails](/assets/blog/authors/_awache/20221004/preventive_guardrail.png =720x) Detective guardrails ![Detective guardrails](/assets/blog/authors/_awache/20221004/heuristic_guardrail.png =720x) Corrective guardrails ![Corrective guardrails](/assets/blog/authors/_awache/20221004/revise_guardrail.png =720x) The guardrail concept Applying strong restrictions using preventive guardrails starting from the initial introductory stages may lead to opposition and fatigue among on-site engineers because they will be unable to do what they have previously been able to do, as well as what they want to do. Conversely, I think that if automatic repairs are performed using corrective guardrails, we may lose opportunities to improve engineers' skills in considering what settings were inappropriate and how to fix them. That is why I believe that we are now in the phase of consolidating the foundations for ensuring as much freedom as possible for users and implementing governance controls. On top of that, I think it is preferable to introduce "detective guardrails." Currently at KTC, we have introduced a 3-stage DEV/STG/PROD system, so even if the risk detection cycle is shifted to a daily basis using detective guardrails, in many cases they will be recognized before being applied to production. Inappropriate settings are periodically detected by detective guardrails, and the on-site engineers who receive them correct and apply them. If continuously repeating this cycle leads to a rise in service levels, the value of this mechanism will also go up. Of course, we do not stop at providing detective guardrails; it is also important to keep updating the rules that are detected there according to the situation on the ground. We need to further develop this mechanism itself together with KTC by working with on-site engineers to provide guardrails that match the actual situation at KTC. Strong backing by executive sponsors If we do not make headway with the idea of "responding to things detected by guardrails according to the error level," we will only increase the number of false alarms. I also consider it an anti-pattern to allow for this rule to not correspond to the circumstances of individual services. Therefore, the important thing should be "to incorporate only the rules that should be observed at a minimum as long as we provide services as KTC." This mechanism is pointless if we cannot spread the word and get all of KTC's engineers to collectively understand this single point: if an alert is raised by a guardrail, we will respond according to the error level without defining overly detailed rules. Therefore, the person pushing this forward for us is our executive sponsor, who is supporting our activities. It is desirable that the executive sponsor be someone with a role that sets the direction of the company, such as someone at the management level or a CXO. At first, no matter how careful we were, the essential point of enforcing rules on on-site engineers would not change. So the fact that company management has committed to this activity via the executive sponsor should act as one of the reasons and motivations for them to cooperate. Demarcation points for responsibilities As a cross-organizational organization, KTC's DBRE does not operate the service directly. Therefore, it is necessary to clarify where the DBRE's responsibilities begin and end and where the on-site engineers' responsibilities begin and end. I have thought about using a framework called DMAIC for this. Regarding DMAIC, I think that it is laid out in a very easy-to-understand way in this video— "What is DMAIC: Define, Measure, Analyze, Improve, Control. Winning patterns for business flow improvement projects (Lean Six Sigma)" —so please take a look. Below is a rough description of who is responsible for what and what should be done, in terms of this 5-step procedure. Definition Description Operation Final Responsibility Define Define the scope and content of what to measure/evaluate Documentation Scripting DBRE Measure Performing measurements/evaluations and collecting the results Running scripts DBRE Analyze Analyzing/reporting results Increasing visibility of the entire organization DBRE Improve Improving flaws/drafting improvement plans Implementing smooth solutions to problems Product Control Checking outcomes and aiming to control them Maintaining a healthy state as a service Product ![Demarcation point of responsibility](/assets/blog/authors/_awache/20221004/DemarcationPointOfResponsibility.png =720x) While this diagram clarifies each role, it also shows who holds final responsibility while people work with each other in consultations and improvements in all of these steps. For example, I would like to add that this does not mean that DBRE does not in any way support efforts geared toward on-site improvements and controls. How to construct guardrails So far, I have described the concept at length up to the construction of guardrails, but from here on I will illustrate specific efforts. [Define] Defining error levels Defining the error level first is the most important thing. The error level is the value that this guardrail provides to KTC. No matter how much the DBRE thinks something "must" be done, if it does not meet the defined error level, it will be relegated to a Notice or be out of scope. I can be accountable to the on-site engineers by personally ensuring that the rules that have been set are checked against their definitions, and I can control my desire to "mark everything as critical." I have set the specific definitions as follows. Level Definition Response speed Critical Things that may directly lead to security incidents Critical anomalies that go unnoticed Immediate response Error Incidents related to service reliability or security may occur Problems in the database design that may have negative impacts within about 1 year Response implemented within 2 to 3 business days Warning Issues that, by themselves, do not directly lead to service reliability or security incidents Issues that include security risks but have limited impact Problems in the database design that may have negative impacts within about 2 years Implement planned response Notice Things that operate normally but are important to take note of Respond as needed [Define] Specific content arrangement Next, we will consider creating guidelines among the defined rules, but if we try to look at the entire database from the outset, we will fail. Therefore, in the first step, I have set the scope of the guardrail as "the extent to which that one can generally handle things on one's own." "The extent to which that one can generally handle things on one's own" means the extent to which things can be done without deep domain knowledge of the service currently running, such as setting up a database cluster (KTC uses Amazon Aurora MySQL for the main DB), configuring DB connection users, and setting schema, table, and column definitions. On the other hand, the areas without intervention by guardrails at this stage are schema design, data structure, and Queries, etc. In particular, the point here is that "workarounds when a Slow Query occurs" is not set as a guardrail. Slow Query can be a very important metric, but it is difficult to address without deep service-level domain knowledge. If a large number of them occur at this stage, it is difficult to know where to start and how to continue to address them reliably and in a timely fashion according to the error level. Regarding Slow Queries, I would like to think step by step, by visualizing Slow Queries so as to enable anyone to check the situation, then defining the SLO as the one to address them, and try out individual proposals from the DBRE. Image of realms checked using guardrails ![Responsibility](/assets/blog/authors/_awache/20221004/Responsibility.png =720x) [Define] Setting guidelines/implementing scripting After deciding upon the defined error levels and the range of interventions, I will apply them to the guidelines. Thus, I can automatically detect what has been agreed upon. Here are some of the guidelines I created. Item to check Error Level Reason Setting database backups is effective If backups are not set, it will result in an Error Backups are an effective measure against the risk of data loss due to natural disasters, system failures, or external attacks The backup retention period is long enough If the backup retention period is less than 7, it will result in a Notice . A certain period of time is needed to recover from a serious loss. There is no general definition of how much time is enough. Therefore, I have set the defaults for AWS's automatic snapshot feature. Audit Log output is valid If the Audit Log settings have not been configured, it will result in Critical status Leaving a log in the Database of who did something, what was done, and when it was done will enable a proper response to data losses and data leaks Slow Query Log output is valid If Slow Query settings are not configured, it will result in Critical status If the Slow Query settings are not valid, it may not be possible to identify Queries that cause service disruptions There is no object that uses utf8(utf8mb3) as the character set for Schema, Table and Column content If there is no object that uses utf8(utf8mb3) as the character set for Schema, Table and Column content, it will result in a Warning There will be strings that cannot be stored in utf8(utf8mb3) It is also mentioned that they will be excluded from MySQL support in the near future. There are Primary Keys in all tables If tables without Primary Keys are used, it will result in a Warning Primary Keys are necessary for uniquely identifying what the main body of that scheme is for and structurally identifying the records There are no Schema, Table or Column names consisting only of strings that are reserved words. If there is a name composed only of reserved words, it will result in a Warning We are planning to render names consisting only of reserved words as unusable in the future or to require that they must always be enclosed in backquotes (`). See 9.3 Keywords and Reserved Words for a list of reserved words These are within the range that can be acquired from information from AWS's API and Information Schema (some mysql Schema and Performance Schema). ![Point of Automation](/assets/blog/authors/_awache/20221004/PointOfAutomation.png =720x) Script this information after acquiring it. For example, if you want to check if "there is no object that uses utf8(utf8mb3) as the character set for Schema, Table and Column content," you can obtain that information by executing the following query. SELECT SCHEMA_NAME, CONCAT('schema''s default character set: ', DEFAULT_CHARACTER_SET_NAME) FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys', 'tmp') AND DEFAULT_CHARACTER_SET_NAME in ('utf8', 'utf8mb3') UNION SELECT CONCAT(TABLE_SCHEMA, ".", TABLE_NAME, ".", COLUMN_NAME), CONCAT('column''s default character set: ', CHARACTER_SET_NAME) as WARNING FROM information_schema.COLUMNS WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys', 'tmp') AND CHARACTER_SET_NAME in ('utf8', 'utf8mb3') ; Other steps (Measure/Analyze/Improve/Control) I will build a platform that periodically executes a scripted information acquisition query to meet the guidelines, such as the above query, and sends an alert if the result is determined to be inappropriate, which functions as a guardrail. Then I think that, for the time being, my activities as DBRE will be centered on returning to this cycle of preparing a dashboard to increase the visibility of the obtained results and having engineers on site respond. The good thing about this guardrail mechanism is, for example, when it becomes necessary within KTC to set a rule that "among the Slow Queries that take 1 second or more, the percentage of queries from the front-end will go from 99 percent per month to 0 percent," if that rule is added, it alone can be applied to all services managed by KTC. Conversely, it is also possible to remove unnecessary rules all at once. This is my concept of scalable database guardrails. Summary What do you think? In this blog post, I introduced the DBRE guardrails, which I consider as one axis around which we can perform scaling as KTC's DBRE and create a continuous value provision. Although it is still in the construction stage, it does not use database technology as has been done up to now, and we are on the verge of creating a DBRE organization that takes into consideration how to apply this technology effectively at KTC and even how to link it to our business values. In that sense, we are now in a challenging time, and we are expending into a wide range of things, from application engineering to cloud engineering. We want to build up these things step by step and continue to output them to everyone, so please continue to support us! Also, if you are interested in this activity or would like to hear more about it, please feel free to contact me via Twitter DM .
Introduction I am Aoi Nakanishi , lead engineer of KINTO FACTORY at KINTO Technologies. The KINTO FACTORY project is redesigning the system with a view to service growth of supported vehicle models and products, as well as nationwide expansion. This project also incorporates with modern technologies and development workflows. In this article, I will describe the schema-first development we are working on at KINTO FACTORY. What is schema-first development? This method, which involves defining a schema file, generating code using a code generator, and developing an API, solves the following problems. When trying to combine, it doesn't work due to type difference. The documents are outdated and the code is correct. Client implementation is duplicated for each language. 1. When trying to combine, it doesn't work due to type difference. Since the schema is defined as an interface with the front end, back end, various microservices and external services, etc., discrepancies in data structures are less likely to occur. 2. The documents are outdated and the code is correct. By using a generator to output documents, it is possible to avoid situations where the contents of the documents and the code tend to diverge as operations continue. 3. Client implementation is duplicated for each language. Code is automatically generated from the defined schema file regardless of the development language the client is using on the web app or mobile app, etc., so it is possible to avoid unnecessary development work when implementing the same function in different languages, for example. Other Many people feel that the barrier to implementation is high if there is no one in the team with experience doing so. However, schema-first development provides a range of benefits for developers such as value validation, automatic code generation for mock servers, git version control, etc. KINTO FACTORY system configuration KINTO FACTORY uses the microservice architecture shown below. GraphQL from browser REST API from third-party system gRPC (Protocol Buffers) between each microservice These are the kinds of configurations it uses to communicate. Interface Description Language (IDL) In general, each API design is defined using the following IDL (Interface Description Language). Interface IDL GraphQL GraphQL Schema https://graphql.org/learn/schema/ REST API Swagger Spec https://swagger.io/specification/ gRPC Protocol Buffers https://developers.google.com/protocol-buffers Learning multiple IDLs is expensive and inefficient. Schema conversion tools I thought, if each IDL can define names and types and generate code, surely we can convert between schemas? I looked into it and summarized the findings in the table below. Before conversion/After conversion GraphQL Schema Swagger Spec Protocol Buffers GraphQL Schema - ? ? Swagger Spec openapi-to-graphql - openapi2proto Protocol Buffers go-proto-gql protoc-gen-openapiv2 - There is not much information on tools that convert based on GraphQL Schema. Tools to convert based on Swagger Spec have not been maintained for a long time. Tools to convert based on Protocol Buffers have more options and information than the ones mentioned above. Based on the above findings, we chose to define using Protocol Buffers and convert to another Schema. Source file (.proto) Preparation 1 Get the files necessary to define the Rest API from https://github.com/googleapis/googleapis google/api/annotations.proto google/api/http.proto google/api/httpbody.proto Preparation 2 Get the proto definition file required to define the GraphQL Schema from https://github.com/danielvladco/go-proto-gql protobuf/graphql.proto Definition file (example.proto) The following definition file was created for this article using an article from the Tech Blog as an example. syntax = "proto3"; package com.kinto_technologies.blog; option go_package = "blog.kinto-technologies.com"; import "google/api/annotations.proto"; // Load file acquired in Preparation 1 import "protobuf/graphql.proto"; // Import file acquired in Preparation 2 // Article message Article { // Title string title = 1; // Author string author = 2; // Content string content = 3; } // Request message Request { uint64 id = 1; } // Result message Result { uint64 id = 1; } // Tech Blog Service service TechBlog { // Post Article rpc PostArticle(Article) returns (Result) { option (google.api.http) = { post: "/post" }; option (danielvladco.protobuf.graphql.rpc) = { type: MUTATION }; } // Get Article rpc GetArticle(Request) returns (Article) { option (google.api.http) = { get: "/get/{id}" }; option (danielvladco.protobuf.graphql.rpc) = { type: QUERY }; } } Convert .from proto to .graphql Install go-proto-gql Clone repository git clone https://github.com/danielvladco/go-proto-gql.git cd go-proto-gql Install Protoc plugins cd ./protoc-gen-gql go install Convert from .proto to .graphql protoc --gql_out=paths=source_relative:. -I=. example.proto Output file (.graphql) """ Tech Blog Service """ directive @TechBlog on FIELD_DEFINITION """ Article """ type Article { """ Title """ title: String """ Author """ author: String """ Content """ content: String } """ Article """ input ArticleInput { """ Title """ title: String """ Author """ author: String """ Content """ content: String } type Mutation { """ Post Article """ techBlogPostArticle(in: ArticleInput): Result } type Query { """ Get Article """ techBlogGetArticle(in: RequestInput): Article } """ Request """ input RequestInput { id: Int } """ Result """ type Result { id: Int } Convert from .proto to .swagger.json Install protobuf brew install protobuf Install protocol-gen-openapiv2 go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2@latest Convert from .proto to .swagger.json protoc -I . --openapiv2_out=allow_merge=true,merge_file_name=./example:. example.proto Output file (.swagger.json) { "swagger":"2.0", "info":{ "title":"example.proto", "version":"version not set" }, "tags":[ { "name":"TechBlog" } ], "consumes":[ "application/json" ], "produces":[ "application/json" ], "paths":{ "/get/{id}":{ "get":{ "summary":"Get Article", "operationId":"TechBlog_GetArticle", "responses":{ "200":{ "description":"A successful response.", "schema":{ "$ref":"#/definitions/blogArticle" } }, "default":{ "description":"An unexpected error response.", "schema":{ "$ref":"#/definitions/rpcStatus" } } }, "parameters":[ { "name":"id", "in":"path", "required":true, "type":"string", "format":"uint64" } ], "tags":[ "TechBlog" ] } }, "/post":{ "post":{ "summary":"Post Article", "operationId":"TechBlog_PostArticle", "responses":{ "200":{ "description":"A successful response.", "schema":{ "$ref":"#/definitions/blogResult" } }, "default":{ "description":"An unexpected error response.", "schema":{ "$ref":"#/definitions/rpcStatus" } } }, "parameters":[ { "name":"title", "description":"Title", "in":"query", "required":false, "type":"string" }, { "name":"author", "description":"Author", "in":"query", "required":false, "type":"string" }, { "name":"content", "description":"Content", "in":"query", "required":false, "type":"string" } ], "tags":[ "TechBlog" ] } } }, "definitions":{ "blogArticle":{ "type":"object", "properties":{ "title":{ "type":"string", "title":"Title" }, "Author":{ "type":"string", "title":"Author" }, "content":{ "type":"string", "title":"Content" } }, "title":"Article" }, "blogResult":{ "type":"object", "properties":{ "id":{ "type":"string", "format":"uint64" } }, "title":"Result" }, "protobufAny":{ "type":"object", "properties":{ "@type":{ "type":"string" } }, "additionalProperties":{ } }, "rpcStatus":{ "type":"object", "properties":{ "code":{ "type":"integer", "format":"int32" }, "message":{ "type":"string" }, "details":{ "type":"array", "items":{ "$ref":"#/definitions/protobufAny" } } } } } } Summary In this article we introduced schema-first development and tools for converting schema definitions as a way of minimizing multiple schema definitions. We hope that it will be helpful for those who want to resolve the confusion of multiple definition languages, especially those who are considering converting Protocol Buffers definitions to GraphQL Schema and Swagger Spec. I hope to publish other articles on document generation, automatic generation of validation processing and automatic code generation, etc. Follow us! KINTO Technologies is now on Twitter. Please follow us to keep up with the latest information. https://twitter.com/KintoTech_Dev We are hiring! KINTO Technologies is looking for people to work with us to create the future of mobility together. We also conduct informal interviews, so please feel free to contact us if you are interested. https://www.kinto-technologies.com/recruit/
Introductory Remarks and Self-Introduction My name is Ikeda, and I'm in charge of front-end development at KINTO Technologies. Recently, I've been involved in the development and operation of KINTO ONE and the launch of new services and projects. Introductory Remarks Recently, various JS frameworks are emerging, such as React, Vue.js, AngularJS, Preact and Ember. Svelte and Solid are two that have been gaining momentum lately. (And personally, I would like to see Mithril.js grow more. You can find more information about it here: https://mithril.js.org ). With this in mind, I would like to introduce the KINTO corporate site, the KINTO Technologies corporate site, and my impressions of using Svelte —which is also used in other ongoing products— and some code, including a simple SSG. What is the SSG (static site generator) introduced in this article? From a front-end perspective, a request is run every time you access an element, such as API GET to obtain, say, a list of blog articles and then API GET to view an article in detail. What an SSG (static site generator) does is basically create all the relevant API GET content during the build process. As an advantage, in the above example, API communication does not occur when transitioning from the blog list screen to the detailed screen, so the transition is very smooth. There are various other architectures, such as SPA, ISR, and SSR.   What is Svelte? Svelte is a framework with an extremely small build size, and as I'll explain later, reading and writing is extremely easy. Also, JS frameworks are nearly equal to virtual DOM, but Svelte does not include a virtual DOM because things like changes to DOM are also described in Vanilla JS during compiling. It doesn't build a virtual DOM or anything else needed for re-rendering; it simply replaces the real DOM when the state of the DOM changes. Please see below for more details: JS framework is based on the concept of write less code https://svelte.jp/blog/write-less-code Product Introduction KINTO Corporate Site https://corp.kinto-jp.com/ KINTO's corporate site is created in a SvelteKit (SSG) on [S3 + CloudFront] configuration. After coding, when it is merged into a certain branch, the build task is executed via GitHub Actions, reflected in S3, and distributed with CloudFront. *SvelteKit is an application framework that uses Svelte. It's similar to Next.js using React. See here for details: https://kit.svelte.dev/ KINTO Technologies Corporate Site https://www.kinto-technologies.com/ KINTO Technologies corporate site uses Svelte (SPA) on [S3 + CloudFront]. While KINTO's corporate site uses the SSG method, KINTO Technologies' corporate site uses the SPA method. This corporate site did not have much content at the stage when the repository was set up, plus the SvelteKit beta version had not yet been released, so Svelte (SPA) was adopted. However, the amount of content is increasing, which begs the question of whether SG is really enough. With that in mind, we're now eagerly awaiting the change to SvelteKit. What Makes Svelte Different The biggest difference isn't the library, it's the compiler . Whether it's Vue or React, the size of a library file will take up the build size as it is, so build size will inevitably increase. This is a perfect framework for me, because as far as I'm concerned, fast loading speed = justice . And of course, there are plenty of devices and plug-ins that can be used to improve the loading speed and execution speed of other frameworks as well. Where I Got Stuck When Actually Implementing It There were really very few places where I got stuck. A simple increment can be written in a small number of lines, like this: <script> // define cout let count = 0; // onclickで䜿甚する関数 function handleClick() { count += 1; } </script> <button on:click={handleClick}> Clicked {count} {count === 1 ? 'time' : 'times'} </button> If there's anything, it's because this is only a beta version and there are still destructive changes being made, so it's necessary to pick up information each time this happens. Svelte's unique syntax is easy to understand, so I think it's difficult to get stuck even if you're seeing it for the first time. There's also another unique syntax called Await blocks . Take a look at the component that fetches each time you click below. You can write 'await' as is in HTML, and reading is a cinch. <script> let promise = getRandomNumber(); async function getRandomNumber() { const URL = "xxx" const res = await fetch(URL); const text = await res.text(); if (res.ok) { return text; } else { throw new Error(text); } } function handleClick() { promise = getRandomNumber(); } </script> {#await promise} <p>...waiting</p> {:then data} <p>{data}</p> {:catch error} <p style="color: red">{error.message}</p> {/await} For readers who think, "Is it really that easy? I'm not convinced." Don't knock it until you've tried it. Why not give it a try for yourself? Try It Out! Practice https://kit.svelte.jp/ We'll reference the SvelteKit official site while we make it. First, let's make a SvelteKit project in the appropriate directory: sh:terminal npm init svelte static-site-sveltekit Next, you'll be given a choice, so select Skeleton project and any other options as you wish. It's convenient that there's a CLI. When selecting, it should generally look something like this: The following is adopted in this article: eslint + JavaScript with JSDoc comments + prettier + Playwright Generating a Static Site This time, I'm going to try the so-called Jamstack, so I'd like to include some sort of communication. I'll try to obtain an article about Svelte from dev.to . *This article does not cover styling, as it increases the volume. First, let's make the page with the list of articles. <script context="module"> export async function load() { let articles try { articles = await fetch(`https://dev.to/api/articles?tag=svelte&per_page=5&page=1`); articles = await articles.json(); console.log(articles) } catch (e) { console.log(e) } return { props: { articles } } } </script> <script> export let articles const PostArticles = articles </script> <svelte:head> <title>Blog</title> </svelte:head> <div> <h1>Svelte devto Articles</h1> {#each PostArticles as article} <div> <header> <h2>{article.title}</h2> <h4>Tags: {article.tags}</h4> </header> <p> {article.description} </p> <a href={`/blog/${article.id}`}>MORE</a> </div> {/each} {#if PostArticles.length === 0} <div>No Articles</div> {/if} </div> With async await , you can obtain the article by fetching the dev.to API, storing it in articles, assigning it to PostArticles and rendering it with Svelte's 'each' syntax. You can export what is written using context="module" . In other words, it can be called even within the same component. Then pass it to the DOM in the next script section and parse it. It's very clear. The good thing about Svelte is that the sections are clear, so it's easy for the writer and very simple to follow. People say that Vue is easy and React is simple , but I think Svelte is both easy and simple . I digress, but let's make a detailed article next. <script context="module"> export async function load({ fetch, params }) { let article try { article = await fetch(`https://dev.to/api/articles/${params.slug}`); article = await article.json(); console.log(article) } catch (e) { console.log(e) } return { props: { article } } } </script> <script> export let article const post = article </script> <svelte:head> <title>{article.title}</title> </svelte:head> <div> <div> <h1>{post.title}</h1> <section> {@html post.body_html} </section> </div> </div> That's it. Params contains various kinds of information, so you just need to get that information, pass it and render it. That's all there is to it. Let's Build! I've written most of the code. So finally, let's build. As it is, there's no instruction to static generate inside svete.config.js . https://kit.svelte.jp/docs/adapters As mentioned in the above, let's use @sveltejs/adapter-static . Let's start by installing it. sh:terminal yarn add @sveltejs/adapter-static@next -D Next, rewrite svelte.config.js. import adapter from '@sveltejs/adapter-static'; /** @type {import('@sveltejs/kit').Config} */ const config = { kit: If { // prerender is not entered, an error will occur prerender: { default: true }, adapter: adapter({ pages: 'build', assets: 'build', fallback: null }) } } export default config; Now, yarn build || npm run build The created article was stored in the build directory. Let's see if we can actually obtain the article. yarn preview || npm run preview We had no problems seeing it, right? Now, all you need to do is store the article according to the project, such as S3, hosting service, or rental server. Impressions Once you've tried Svelte out for yourself and seen the code with your own eyes, I'm confident you'll get a sense of what makes it special. You can create an application with less code thanks to Svelte's write less code concept. So, how about it? Did that come across? Although it's still in development as a beta version, I think you can tell this is a JS framework with a lot to offer. Have a good Svelte life, everyone.
はじめに こんにちは KINTO テクノロゞヌズのプラットフォヌムGでCloud Infrastructure TeamOsaka Tech Labに所属しおいる井朚です。同じ倧阪にいるチヌムメンバヌの若手ホヌプがCloudFront Functionの障害察応に぀いお執筆するず聞いたので、事前知識ずしおのCloudfront゚ッゞ関数぀いお蚘茉しようず思いたす たずは、CloudFrontに぀いお CloudFrontはコンテンツ配信サヌビス(CDN)であり、コンテンツの配信をよりナヌザに近い地点で行うために、䞖界各地にCDNの拠点を配眮しおコンテンツのキャッシュを行っおおりたす。ナヌザ偎は䞀番近いCDNの拠点にアクセスするこずにより䜎レむテンシヌでコンテンツぞのアクセスが可胜になりたす。たた、゚ッゞロケヌションには぀あり、ナヌザに近い゚ッゞロケヌションずオリゞンコンテンツに近いリヌゞョン゚ッゞキャッシュリヌゞョナル゚ッゞロケヌションが存圚したす。 ゚ッゞ関数ずは ゚ッゞ関数ずは、その゚ッゞロケヌションでトラフィックを凊理しおいる゚ッゞサヌバヌ䞊で動く関数のこずを指したす。 ゚ッゞ関数を利甚するず、リク゚スト時やレスポンス時に関数を実行するこずができ、匊瀟においおは䞻に䞋蚘の機胜を実装しお動かしおおりたす。 レスポンスのURLをリダむレクト ヘッダヌの远加 リク゚ストパラメヌタに応じた画像のリサむズ ゚ッゞ関数が動䜜するタむミング ゚ッゞ関数が動かせるタむミングは以䞋の぀になりたす。 ビュヌワヌリク゚スト ビュヌワヌレスポンス オリゞンリク゚スト オリゞンレスポンス ビュヌワヌはすべおの通信に察しお凊理が走るため、共通の凊理を行いたい堎合に、オリゞンはキャッシュがなかった堎合に凊理が走るため、オリゞンに枡したい情報の制埡やキャッシュされるデヌタのリサむズなどキャッシュされるデヌタを加工したい時などに利甚したす。 ゚ッゞ関数の皮類 ゚ッゞ関数には皮類あり、CloudFront FunctionずLambda@Edgeが存圚したす。 CloudFront Function ナヌザに近い゚ッゞロケヌションで動く゚ッゞ関数です。 レむテンシヌの圱響を受けやすい CDN のカスタマむズを倧芏暡に実行できたす。 シンプルな凊理ヘッダヌ操䜜やリダむレクトなどに向いおおり、LambdaEdgeより費甚は1/6未満。 ナヌザ偎の䞀番近い゚ッゞロケヌションで動䜜するため、ビュヌワヌリク゚ストずビュヌワヌレスポンスに察応しおたすが、オリゞンリク゚スト、オリゞンレスポンスには察応できたせん。 Lambda@Edge オリゞン偎に近いリヌゞョン゚ッゞキャッシュで動く゚ッゞ関数です。 CloudFront Functionでは察応できない凊理がかかる関数や、AWS SDKを含むその他AWSサヌビスを利甚したりファむルシステムぞのアクセス等可胜です。 LambdaEdgeはAWS Lambdaの拡匵機胜でコン゜ヌル䞊での芋え方は䞀緒ですが、ナヌザが蚭定する環境倉数が利甚できないなどの機胜制限があり、泚意が必芁です。 たた、Lambda@Edgeの関数自䜓はバヌゞニアリヌゞョンに存圚したすが、実際は各リヌゞョン゚ッゞキャッシュで動くために、察応するリヌゞョンにレプリカを配眮しお動䜜したす。そのためLambdaの同時実行数や各サヌビスぞのアクセスリミットなどに぀いおは察応するリヌゞョンにお加算されるため泚意が必芁です。日本であれば東京リヌゞョン ビュヌワヌリク゚スト、ビュヌワヌレスポンス、オリゞンリク゚スト、オリゞンレスポンスすべおに察応しおたす。 CLoudFront FUnctionずLambda@Edgeの違い CloudFront Functions Lambda@Edge プログラミング蚀語 JavaScript Node.js / Python むベント゜ヌス ビュヌワヌリク゚スト ビュヌワヌレスポンス ビュヌワヌリク゚スト ビュヌワヌレスポンス オリゞンリク゚スト オリゞンレスポンス Scale リク゚スト数: 毎秒 10,000,000 件以䞊 リク゚スト数: 1 リヌゞョンあたり毎秒 10,000 件たで 関数の持続時間 1ms未満 ビュヌワヌ  5秒 オリゞン 30秒 最倧メモリ 2 MB 128  3,008 MB 関数コヌドず含たれるラむブラリの最倧サむズ 10KB ビュヌワヌ  1MB オリゞン 5MB ネットワヌクアクセス いいえ はい ファむルシステムぞのアクセス いいえ はい リク゚スト本文ぞのアクセス いいえ はい 䜍眮情報ずデバむスデヌタぞのアクセス はい ビュヌワヌリク゚スト  いいえ ビュヌワヌレスポンス はい オリゞンリク゚スト  はい オリゞンレスポンス はい 匕甚 CloudFront Functions ず Lambda@Edge の遞択 KINTO Technologiesにおける゚ッゞ関数の䜿い分け KINTO Technologiesにおいお、ただ十分に䜿い分けおいるわけではないですが、倧量にアクセスされるような環境でのビュヌワヌリク゚スト/ビュヌワヌレスポンスに関しおはコスト及び、Lambdaの同時実行数に圱響があるためCloudFront Functionを掚奚しおおりたす。 それ以倖に関しおは、CloudFront FunctionはLambda@Edgeに比べお制限が厳しいため、日々のAWSコストを枛らすより、Lambda@Edgeを利甚するこずで開発や運甚にかかるコストを削枛する方法を遞択しおおりたす。 さいごに 今回は、CloudFront゚ッゞ関数(CloudFront Function、Lambda@Edge)に぀いお蚘茉いたしたした。゚ッゞ関数は特性を理解しお利甚するこずにより、システムの幅が広がりUXの向䞊になるものだず思っおおりたす。ただし、制限が厳しいため間違えるず゚ラヌが発生する原因ずなり逆の効果ずなりたす。 このタむミングで再床理解しおいただき、開発に圹立おおいただければず思いたす。 CloudFront Functionの障害察応の蚘事も蚘茉されるのでぜひ芋おください たた、プラットフォヌムG(Osaka Tech Lab)で䞀緒に働いおいただけるメンバヌを募集しおたす KINTOテクノロゞヌズ株匏䌚瀟 プラットフォヌムG採甚TOP   wantedly
はじめに みなさたこんにちはグロヌバル開発郚兌テックブログ運甚チヌムの森です。 KINTOテクノロゞヌズは珟圚東京・名叀屋・倧阪にそれぞれ拠点があり、東京は宀町 (日本橋)・神保町の぀のオフィスに分かれおいたす。私の所属するグロヌバル開発郚は神保町オフィスにお日々働いおおりたす💪 今回は神保町オフィスにお床ほど開催された情報共有䌚、その名も 神保町ISM (Information Sharing Meeting) の様子をお䌝えしたす 🥳 ※䜙談ですが、神保町ISM(むズム)ず思っおいたメンバヌもいたようで、それもそれで神保町らしさを䜜っおいくずいう意味で良いなず思いたした。 開催の背景 2022幎の6月に神保町オフィスが開所しお早幎、所属グルヌプや新入瀟員も増えお、なんず玄100名の倧所垯になりたした。 しかし、いただに「他のチヌム・グルヌプが䜕をしおいるのかわからない」「どんな人がいるのかわからない」ずいった声をよく聞きたす。 そこで、 他の拠点Osaka tech labで行われおいるような情報共有䌚 を神保町でも開催しおみおはずいう想いで、テックブログ運営チヌムで神保町所属のメンバヌを䞭心に、完党なる勢いで䌁画しおみたした 第回 神保町ISM 2023幎6月23日開催第回はずりあえず小さく始めおみようずいうこずで30分開催で、Agendaも以䞋のようなシンプルな圢匏にしたした。 Opening (5分) Ask me anything* (20分) Closing : アンケヌト案内 (5分) Ask Me Anythingずは Ask Me Anythingずは「○○だけど、䜕か聞きたいこずある」のような意味で、AMAず略されたす。䞻に゜ヌシャルメディアを䞭心に、ホストやゲストに察しお䜕でも質問できるような䌁画です。その名の通り、その人の経歎や、今の仕事、プラむベヌトたで䜕でも聞くこずができたす。Webで調べるずいろんなずころで開催されおいるのでぜひご参照ください😄 参考 What is AMA? Understanding the Basics of Ask Me Anything AMAを䌁画に入れたので、質問を受ける人の遞定から始めたした。第回は圓時のグロヌバル開発郚グルヌプマネヌゞャヌにお願いしたしたが、郜合の぀く日が日しかなかったので、準備から案内、開催たでを玄週間で実行に移したした。 突貫で実斜した割に、玄30名ほどに参加いただき、それなりに良い感想をいただくこずができたした🎉 以䞋、参加者の声です。 普段あたり䌚話する機䌚のない人ず、仕事ずは別に経歎や趣味など、様々な内容をお聞きできる堎があるのはいいず思いたした 資料でもあたり残っおいないKINTO黎明期のお話が䌺えお倧倉興味深かった。いろんなメンバヌのお話をもっず䌺っおみたい。 [第回 事埌アンケヌト] 次回も参加したいか 䞀方で、AMAは䞀人の人に質問しお話を聞くのがメむンなので、参加者党員が参加しおいる感はありたせんでした。運営チヌム内では振り返りを行い、「ワむワむ感」を創出するにはどうしたらよいかを次回の課題ずしお運営チヌムで暡玢したした。 どうやっお振り返っおどうやっお䌁画したかずいう点も、いろいろず工倫があるのですがそれはたた別の機䌚にご玹介させおください。 第回の様子 第回 神保町ISM そんなこんなで䌁画された第回神保町ISMは2023幎8月25日に時間に延長しお開催したした。 Agendaは以䞋の通りです。 Opening(5分) Talk with neighbours(25分)🆕❗ Ask Me Anything(25分) Closing(5分) AMAはずおも奜評だったので据え眮きずしお、今回はWoven Payment Solution開発Gの亀井さんに登壇をお願いしたした。 皆さんに「ワむワむ」参加しおいただけるように運営チヌムが考えた䌁画は Talk with neighbours です。 かっこよく英語で蚀っおみたしたが、45人のチヌムにわかれおフリヌトヌクをするコヌナヌです。 初めお顔を合わせる人達でフリヌトヌクするにはネタが必芁なので、サむコロ通称ころすけでトヌクのネタを提䟛する方匏を採甚したした。 サむコロ🎲 フリヌトヌク🗣 そう、平成を生き抜かれた方々には銎染みもあるでしょう、あの番組を参考にさせおいただきたした。笑 䌁画䞭は、チヌムを分けお「はいどうぞ」で急にお話できるものだろうかず心配しおいたのですが、そんな心配は䞍芁なくらい、各チヌムが自然に話しはじめたのが印象的でした。 トヌクの話題が尜きた際にはころすけを転がしお新しいテヌマでお話したした✚ チヌムにわかれおワむワむガダガダ。䌝わりたすか AMAは埌半30分で行いたしたが、Woven Payment Solution開発Gは普段KINTOずは離れお業務をされおいるこずもあり、前回よりも倚くの人から質問が出たした。「もっず話を聞きたかった」などの声もあったのですが、情報共有䌚での時間は限られおいるので、ぜひこの堎以倖でも気軜に亀流いただけたらず思いたす😄✚ [第回 事埌アンケヌト] 次回も参加したいか 今回も前回ず同じくらいで玄30名のメンバヌに参加いただき、「郚眲暪断で人ず話せおよかった」「同じオフィスで働く人を知るこずができるのはずおもいい機䌚だず思う」「普段かかわりのない瀟員の方ず亀流ができ次回も参加できたらなず思いたした」など奜評で、「次回も参加したい」の数は前回を䞊回るこずができたした✚ たずめ これたで回開催しおきた神保町ISMですが、総じお感じたのはやはり郚眲をたたいだ亀流を皆さん求めおいるのだな、ずいうこずです。䞀芋、業務には関係がなさそうに思える䌚ですが、こういった堎での䌚話から「そういえばあの人これに詳しかったな、アドバむスもらえるかな」ずいった颚に実業務にも生きおくる気がしたす。 たずは回開催したしたが、改善点もたくさんありたす。今埌も定期的な開催を継続し所属メンバヌ同士の亀流を深め぀぀、神保町オフィス党䜓を掻気づけられたら、ず考えおいたす 🎉
はじめたしお人事採甚チヌムで組織開発担圓です。 2023幎1月に入瀟埌、最初に手がけた党瀟むベントがずっおも心枩たる堎になったので蚘事にさせおいただくこずになりたした。蚘事は2023幎2月開催の様子です。 KTC #thanks Days ![KTC #thanks Days](/assets/blog/authors/hr-team/thanks-days/thanks-days.png =400x) 実斜したむベント名です。瀟内ではKINTOテクノロゞヌズのこずをKTCず呌んでいたす。 ■むベント抂芁 ・開催期間2/13〜2/15 ・堎  所宀町、神保町、名叀屋、倧阪の各拠点 ・内  容各拠点に蚭眮された「fleeお菓子bar」でプレれントしたいお菓子をカップに詰め、日頃の感謝を䞀蚀添えたthanksカヌドを添えお瀟員同士で枡し合いたした。 詰め詰めしたお菓子はこんな感じ 可愛い。。。 なぜやったのか 理由は2぀。「コミュニケヌションの掻性化」ず「カルチャヌ圢成」です。 入瀟埌いろいろな方ず話しお分かったのですが、圹職、圹割、幎霢、性別問わず、もっずコミュニケヌションを取れたら良いのにな〜ずいう声が倚くありたした。このむベントをきっかけに、日頃蚀えおいなかったり䌝えそびれおいた感謝を䌝え合い、コミュニケヌションを深める機䌚、そしお今埌の機䌚に繋げおほしいなず考えたした。 ●感謝にフォヌカスした理由 どんなコミュニケヌション斜策にしようかリサヌチしたずころ、感謝し合う効果の倧きさが分かりたした。 ・盞手ぞの感謝、優しさ、興味が生たれる ・盞手ぞの長所や良いずころに着目するようになる ・コミュニケヌションが掻発になる ・生産性も向䞊するあるデヌタでは幞犏な気持ちだず+12%、䞍幞な気持ちだず-10%の生産性になる結果も) ・幞せホルモン「オキシトシン」が出おHappyになる などなど。普通の䌚話よりも、感謝をし合うコミュニケヌションはさらに質が高いこずが分かりたした。 ●thanksチャンネルの存圚 さらに、KTCにはSlackに「#thanks」ずいう玠晎らしいチャンネルが自然発生しおおり、日々さたざたな「thanks」が投皿されおいたした。 しかし投皿者は党䜓の1割皋床でしたので、KTC #thanks DAYSをきっかけにチャンネル利甚率を高めたいなず。日頃から感謝を䌝え合うカルチャヌ圢成のきっかけに、このむベントを繋げおいきたいず考えたした。 実際の様子 お菓子Barにはたくさんの方が連日集う倧盛況各拠点、远加でお菓子を床も仕入れるずいう嬉しい結果ずなりたしたみなさん、遞んでいる時から楜しそうだったのが印象的でした。 Slackチャンネルはどうだったかずいうず・・・ 可愛いpostが連続する䞭、こんな投皿も・・・ ・・・ 「り・が・ず・う」を#thanksチャンネルにpostをし、残りの「あ」を卒業メンバヌに 手枡すしお送り出すずいう䜕ずも玠敵な挔出も登堎したした玠敵 チャンネル促進の結果 実際に利甚者は増えたのかずいうず、 <3日間の成果> #thanks登録者数 117%up #thanks投皿数  119post リアクション総数 2,000over 投皿者数332%up1月合蚈19名▶3日間合蚈 63名 ずいうこちらも玠晎らしい結果になりたした 最埌に 党拠点合同で実斜をしおみた結果、数字ずしおもたくさんのリアクションが発生したしたし、3日間の様子から倚くの方に喜んでもらえるこずができたず感じおいたす。 たた、KTCは党瀟員の玄25が海倖囜籍の方なのですが、感謝に蚀葉の壁はなく、文字が読めなくおもなぜか気持ちは䌝わる、通じ合えるのだな〜ず感じたした。聞き取るこずすらできない蚀葉もあったけど、感謝されおいるず分かる堎面が䜕床もあったのですが、その床に「最高な䌁画をありがずう」ず毎回脳内倉換させおいただき、私の自己肯定感は爆䞊がりでした。 実はこのPOP、党瀟員の囜の蚀葉でありがずうず曞かれおいたす。 感謝っお圓たり前に倧事だず思っおいたすが、いざ意識しお、蚀葉に、行動に移すずこんなにも玠晎らしく尊いものだず気づく機䌚になりたした。感謝の気持ちは囜境を越える。盞手の行動に目を向け、感謝の気持ちをもち、䌝える。意識せずずも普通にできる、そんなKTCを目指し、組織の力になっおいきたいず思いたす。 こんな玠晎らしい䌁画を入瀟しお担圓させおくれお、本圓に감사합니닀
皆様こんにちは、グロヌバル開発郚兌テックブログチヌムの森です。普段はグロヌバル開発郚におWebのPdMを務めおいたす。そんな私ですが、2023幎9月1日~3日にかけお開催された iOSDC Japan 2023 ぞ瀟内の数名ず参加しおきたした 興味深いセッションの内容は参加しおいたiOS゚ンゞニアが曞いおくれるず思うので、私は運営目線での感想をレポヌトしたす😎 (#iwillblog プレッシャヌを䞎えたす) https://iosdc.jp/2023/ 参加のきっかけ iOS゚ンゞニアではない私がなぜiOSDCに参加したのか 実は最近、テックブログチヌムでは瀟倖向け勉匷䌚の運営をサポヌトしたり、瀟内むベントを䌁画したりしおいたす。 最近ではコヌポレヌトIT䞻催の KINTOテクノロゞヌズMeetup! や、DBREチヌムの DBRE Summit 2023 などの運営をサポヌトしたした。 ただただ駆け出しのチヌムなので、䌁画䞭やむベント䞭にも「どうやったら参加者にもっず楜しんでもらえるだろう」「どうやったらうたくファシリテヌションできるだろう」ずいった悩みだらけです🀔 そこで、「iOSDCはどうやらめちゃくちゃ盛り䞊がるらしい」ずの噂を聞き぀け、カンファレンスの䌁画案やその盛り䞊げ術を孊ぶべく、日間に枡っお朜入しおたいりたした 2022幎のiOSDCレポヌトは匊瀟のiOS゚ンゞニア達がレポヌトしおくれおいたすのでこちらもぜひご芧ください👍 https://blog.kinto-technologies.com/posts/2022-10-13-iosdc2022_participation_report/ 受付 䌚堎に入ったらたず受付をしお、ネヌムカヌドをもらいたす。 このカヌドには入退堎管理甚のQRずNFCが入っおいたす。QRは䌚堎の入退堎管理に䜿い、NFCはアプリで名札をコレクションするこずができるのです。 このアむデアいいな。メモメモ📝 https://blog.iosdc.jp/2023/09/01/name-card-nfc-tag-exchange-2023/ 実は私、日目にたんたずこのカヌドを忘れおしたったのですがその際も「名札忘れですね」ずスムヌズに新しいカヌドをいただくこずができたした。こういうずころたで考えられおいるのだな。メモメモ📝 セッション セッションは倧きめのお郚屋぀、小さめのお郚屋぀の合蚈぀のブヌスに分けお開催されおいたした。それぞれ聞きたいセッションに参加する圢です。 🔻 䌚堎党䜓図 階で各トヌクを拝聎。階はスポンサヌずコミュニケヌション甚のブヌス。飲み物等いただけたす。 圓日のタむムテヌブル をむベント前から芋おいたのですが、どのトヌクをどのタむミングでどのお郚屋でやっおもらうか、めちゃくちゃ調敎されたんだろうな、ず感動。4぀のお郚屋同時進行で、セッション内容によっお時間も違うし、登壇者が出垭できる日も違うだろうに。この調敎力は身に着けたいです。 各セッションのタむトルず登壇者名は「䞖界の果おたでむッテ」のナレヌションなどで有名な声優の 立朚文圊さん が録音で読み䞊げおくださりたした。聞いおる偎も登壇者もテンション䞊がりたす🥳 オンラむン配信 オフラむン参加のチケットを賌入するず、オンラむン芖聎もできたした。(オンラむン芖聎のみのチケットもありたした。) オンラむンはニコニコ生攟送です。私は珟地参加できなかったセッションをオンラむンで芖聎しおいたのですが、驚きなのがラグがほずんどなかったこずデバむスや環境にもよるず思いたすが、5秒もないのではないでしょうかオフラむン参加組ずリアルタむムでSlack Chatできたした。 䌚堎転換䞭の配信画面では、スポンサヌさんのCMはもちろん、準備期間䞭のスタッフさん達の様子が流れおいたのも印象的でした。8月のむベントから、我々もハむブリッド配信を始めたので、次回の䌑憩䞭はこういうの配信するずおもしろいかもなぁ、ず思っお芋おおりたした。 LTセッション 参加する前から5分のLTが6-7本あるスケゞュヌルが気になっおたした。 私も普段瀟内のむベントやミヌティングをファシリテヌションするので、このAgenda実珟するのっお思っおいたのですが、できるんですねぇ😂 たず、時間通りに登壇を終了させるこずが䞀番難しいず思っおいたした。ここの工倫がすごい 5分のリミットが近づくず音楜で焊らせお ペンラむト を振るように指瀺が出たす。登壇者を応揎し぀぀、登壇時間を厳守させるずいうなんずも良いアむデアでした。あず、振っおる偎も楜しい 昚幎ずはたた違った挔出だった様子 登壇者の掚しカラヌで応揎したす。 それぞれ5分を滞りなく進めるため、Q&Aの時間は蚭けずに埌で別のブヌスで話しかけられるような仕組みでした。登壇者の入れ替えは発衚資料の準備のみです。この間もちろんオヌディ゚ンスは次の登壇者の"掚しカラヌ"を聞いおペンラむトの準備をしおおきたす。それだけだずもちろん時間あたるので、ブヌスの玹介であったり、登壇者の裏話などをお話いただいお、埅ち時間を長く感じさせない玠晎らしい叞䌚技術でした👏 挔出はもちろんなんですが、このLTセッション、コンテンツずしおも非垞におもしろかったです。5分で必ず切られるのが前提なので、登壇者の方それぞれ工倫されおたずめおいらしたのが印象的でした。 おそらく登壇者の䞭には蚀いたいこずを党郚蚀えずに終了を迎えた方もいらしたず思いたすが、登壇者の皆さんさすがのタむムマネゞメントスキルで、オヌディ゚ンス偎ずしおはあたりそれを感じなかったです👏 プレれンや登壇を経隓されるず倚分みんな感じるず思うんですが、短く自分の蚀いたいこずたずめるのっおすっごく難しい😭 自分もおしゃべりなので぀い長いこずお話しがちです。その䞭で起承転結぀けお、か぀、少しナヌモアも亀えながら なんおめちゃくちゃ良いアりトプットの堎ですよね たた、短い時間のプレれンはタむムマネゞメントスキルが磚かれたす。残り時間を芋ながらその堎で「この郚分はカット」などを瞬時に刀断しお、蚀いたいこずを䌝えながらたずめられおいお、「きっずファシリテヌションなんかもお䞊手なんだろうな」ず感じたした。 テックブログチヌムずしおは瀟員のアりトプット力向䞊も目指しおいるので、ぜひ瀟内でもこういう堎を取り入れおみたいです😎✚ ペンラむト楜しんでいるテックブログメンバヌ 自分がやりたいこずみんな楜しいのかも  iOSDCに参加しおみた単玔な感想ですが、総じお゚ンゞニアでなくおも参加しおすごく意矩のあるカンファレンスでした。 もちろん技術呚りの詳しいずころはわからないですが、非゚ンゞニアでも自瀟プロダクトをより良いものにしたいずいう想いは同じです。 運営を孊ぶ目的で参加したしたが、PdM芖点からも「゚ンゞニアさんっおこういうこずを考えおいるんだな」「こういう考えを私達のプロダクトに入れたらもっずよくなるかも」ず感じたしたし、本来の目的だった運営目線では、それはもう非垞に参考になるカンファレンスでした🀩 懇芪䌚䞭、幞運にも実行委員長の 長谷川さん ずお話する機䌚がありたした。むベント党䜓の䌁画であったり、盛り䞊がるための工倫などをお䌺いしたずころ 「自分がやりたいこずを具珟化しおいるだけなんだよね」 ずおっしゃっおいたした。これ、真理だなず。むベント終わった今も自分にめっちゃ刺さっおたす。 参加するたでは「どうやったらみんなが楜しんでくれるだろう」ずいう悩みを抱えおいたのですが、「自分がおもしろいず思ったこずをやっおみたら、意倖ずみんなも楜しいのでは」ずいう新しい発想になりたした。 もちろんそれが刺さるか刺さらないかはあるず思いたすが、この新たな芖点を埗お、今埌もいろいろなむベントを䌁画・運営しおいきたいずいう熱が沞き䞊がりたした🔥🔥🔥 KINTOテクノロゞヌズでは今埌も倖郚向けのむベント開催を䌁画しおたいりたす。案内は 匊瀟Connpass などを通じお随時行いたすので、ご興味あればぜひご参加ください✚
こんにちは。 KINTO テクノロゞヌズの DBRE チヌム所属のhoshinoです。 前職ではWeb制䜜䌚瀟でむンフラ、バック゚ンド゚ンゞニアずしお働いおいたしたが、DBに興味がありその䞭でも DBRE の掻動に魅力を感じたため2023幎8月からKINTOテクノロゞヌズ DBRE にゞョむンさせおいただくこずになりたした。 DBREDatabase Reliability Engineeringチヌムでは、暪断組織ずしおデヌタベヌスに関する課題解決や、組織のアゞリティずガバナンスのバランスを取るためのプラットフォヌム開発などを行なっおおりたす。DBRE は比范的新しい抂念で、DBRE ずいう組織がある䌚瀟も少なく、あったずしおも取り組んでいる内容や考え方が異なるような、発展途䞊の非垞に面癜い領域です。 匊瀟における DBRE の取り組み䟋ずしおは、あわっち @_awache による DBRE ガヌドレヌル構想の実珟に向けた取り組みに぀いお ずいうテックブログや今幎の AWS Summit の登壇内容 、p2sk @_p2sk_ による DBRE Summit 2023の登壇内容 を是非ご芧ください。 今回の蚘事は、2023幎8月24日に開催した DBRE Summit 2023をレポヌトしたいず思いたす DBRE Summit 2023 ずは DBRE の最新のトピックずプラクティスを孊び、たた DBRE ネットワヌキングを目的ずしたむベントです。 connpass による事前申し蟌みではオンラむンずオフラむン合蚈で186名の方々が申し蟌みをしおくださり、圓日も倚くの方々にご参加いただけたした。 登壇者の皆様、参加者の皆様、お忙しい䞭 DBRE Summit を䞀緒に盛り䞊げおいただきありがずうございたした DBREを圹割ではなく、文化にしたリンケヌゞの取り組み 合同䌚瀟 Have Fun Tech 代衚瀟員、株匏䌚瀟 Linkage CTO、DBRE ナヌザヌ䌚 DBREJP 共同運営 曜根 壮倧(そね たけずも) / そヌだい @soudai1025 さん @ speakerdeck DBRE は圹割ではなくデヌタベヌスを䞭心ずした運甚の哲孊であり普段のプロダクト開発の営みの䞭でデヌタベヌスをメンテナンスする文化です。 デヌタベヌスを管理できる英雄が珟れおしたうず、逆にその人に䟝存するこずになっおしたう懞念点も出おきたす。 そうならないよう安定したサヌビス運甚のために英雄がいらない平和な䞖界を目指す必芁があり、そのために、䌚瀟ずしお颚土を䜜っおいく必芁がありたす。 個人の適性や熱意は必芁だけどそれだけでは文化にならないため、たずは颚土を敎えおいくこずが重芁です。 たた、蚭蚈はデヌタベヌスの安党や運甚に盎結しおいるため、開発者が DBRE を実践しおいく文化が必芁です。 Database Reliability Engineering は哲孊であり、運甚のスタむルで職人芞ではなく仕組みで問題を解決しおいくために、察凊ではなく予防をする先に DBRE がありたす。 始めるに遅いこずはない今から始めたしょう 感想 DBRE を実践しおいく䞊で自分たちでどうにかしようずするのではなく、呚りを巻き蟌んで行くこずがずおも重芁なこずだず実感したした。 DBRE = 哲孊であり文化䌚瀟そのものの颚土を䜜っおいくために、積極的に暪断的なコミュニケヌションを取っおいきたいです メルカリのDBREの今ずク゚リリプレむツヌルの比范 株匏䌚瀟メルカリ DBRE 䞉谷智史 @mita2 さん メルカリの DBRE は蚭立しお1幎皋、それたではSREがデヌタベヌスを担圓しおいたした。 メルカリのデヌタベヌスの抂芁ずしおは、元々はMonolith APIずDBだけでしたが珟圚はMonolith + MicroServiceに分離されたした。 DBRE の䞻な業務ずしおは各マむクロサヌビ所有のDB支揎ずしおDeveloperのお悩み解決ずしおDBの各盞談を受けたり、生産性を高めるツヌルの調査を行っおいたす。 MicroService DB支揎を始めるに圓たっお、プロアクティブに掻動したいが課題が芋えづらい、DBRE チヌムの認知がされおいない等の課題が存圚しおいたした。 察応策ずしお Developer Surveyを実斜、DBRE にどんなこずを期埅するかを遞択方匏でアンケヌトを実斜 DBRE News Letterを半幎に䞀回発行、DBRE チヌムからの積極的な発信 効果ずしお埐々に䌚瀟内で認知されおおり、䟝頌が倚くなっおきおいたす。 その他の DBRE 業務ずしおは、Monolith DBの運甚業務ずしおDBA業務やモダン化ぞの挑戊を行っおいたす。 本番のク゚リをミラヌするリプレむツヌルの遞定を目的ずしお、調査芳点を蚭定し、調査を行いたした。 リプレむツヌルずは 本番のク゚リやトラフィックを別の環境に察しお再珟するツヌルで、移行やバヌゞョンアップ時の圱響調査に利甚したす。 比范したツヌル Percona query Playback ログベヌスで䜿甚できおシンプルに䜿いやすいツヌル MySQL-query-replayer (MQR) MQRは倧芏暡なリプレむにフォヌカスされおいおツヌルを䜜成したtomboさんのロマンを感じるツヌル 感想 組織にどのような課題があるかをDeveloper Surveyでの調査や DBRE News Letterなど積極的に DBRE からの発信をしおいるずいう印象でした。 たた、リプレむツヌルに関しお調査芳点やどのように調査を行っおいるかを聞けおずおも参考になりたした。 KINTO テクノロゞヌズでの DBRE 掻動のご玹介 KINTO テクノロゞヌズ DBRE 廣瀬 真茝 @_p2sk_ さん。 @ speakerdeck 䌚瀟党䜓を暪断する組織プラットフォヌムGの䞭に DBRE が所属しおいたす。 DBRE のRoleずしたしおは、぀に分類を行っおいたす。 Database Business Office 開発組織や各ステヌクホルダヌからの芁求に基づいお課題解決を行ったり、DBRE が提䟛するplatformの掻甚を掚進する圹割 Cloud Platform Engineering ガバナンスに準拠しながらクラりドの効果的な利掻甚を促進するために、DBに関連する暙準やplatformを提䟛する圹割 DBRE の掻動内容の決め方ずしたしおは4本柱を定矩し組織の珟状を螏たえ具䜓的な掻動を決定しおいたす。 実際の掻動 DBクラスタの情報を収集する仕組み DBシヌクレットロヌテヌション 怜蚌Aurora zero-ETL integrations with Redshift preview KINTOテクノロゞヌズの DBRE ではDatabaseのReliabilityを向䞊をさせるためにプラットフォヌム構築を行っおいたす。 その手段ずしおEngineeringで解決する道を遞択したした。 Cloudを適切に掻甚しAgilityを確保し぀぀DatabaseのSecurityずGovernanceを守る platformぞの昇華させ䌁業党䜓に展開するこずでビゞネスにいい圱響を䞎え続ける Database Reliability Engineering ずいうアプロヌチで進めおいたす。 感想 DBRE の圹割を明確に瀺し、それを元に組織ずしおの仕組みづくりを行うこずで、デヌタベヌスの信頌性向䞊ずビゞネスぞの貢献を同時に远求しおいおずおも玠晎らしいず感じたした。 今埌 DBRE ずしお定矩された4本柱を元により良い仕組みづくりに貢献しおいきたいず思いたす OracleDBを甚いたDBREの実珟 〜 オむシックス・ラ・倧地でやっおみた〜 オむシックス・ラ・倧地株匏䌚瀟 DBRE / DBRE ナヌザヌ䌚 DBREJP 共同運営 原 智子 @tomomo1015 さん @ speakerdeck SRE/DBRE が実珟する可芖化の䞭でもコストの可芖化があたり觊れられおいなかったため、䌚瀟のむンフラ党䜓のコスト管理を行っおいたす。 アプロヌチずしおは請求曞リストからシステムの実態ず課題を把握するこずを行っおいたす。 たた、費甚察効果を評䟡するこずで事業の利益率向䞊に貢献しおいたす。 党䜓のむンフラ費甚のなかでもDBのコスト割合は高い、DBはコストをかけおたでシステムにずっお重芁なものではあるが、あぐらをかいお攟眮しおはいけたせん。 DBのコストダりンのために、開発環境等のDBを利甚しおいない日は基本停止や䞀番コスト察効果があるアプロヌチを考案しおいたす。 商甚DBを利甚する䞊でラむセンス圢態ずその金額を知っおいるこずは DBRE を䜓珟する䞊でずおも重芁です。 ラむセンスの棚卞しを行い䌚瀟が契玄しおいるラむセンスの劥圓性を把握したしょう。 今ず未来をどうすれば信頌性向䞊ができるか、成長できるか、楜しくできるか、それを考えおいくために時間を䜿いたしょう。 コストを可芖化するこずによっお色々芋えおくるものあるため、是非コストを可芖化するずころから事業貢献や信頌性向䞊ぞのアプロヌチをしおみおください。 感想 普段聞けないコスト面での可芖化のお話を聞けおずおも面癜かったです。 お話にもありたしたが、DBはむンフラ費甚の䞭でも割合が高くシステムの䞭でも重芁な郚分なので可芖化し費甚察効果を評䟡するのがずおも重芁ず感じたした。 コスト面も含め今埌 DBRE ずしお課題解決をしおいけたらなず参考になりたした。 ANDPADでのテヌブル定矩倉曎のレビュヌ自動化ずガむドラむン䜜成の取り組み 株匏䌚瀟アンドパッド DBRE 穏間 雄基 @fkm_y さん @ speakerdeck プロダクトチヌムがテヌブル定矩を倉曎する堎合、DBRE がレビュヌする運甚になっおおり、そのなかでいく぀かの課題が発生したした。そのため、スケヌル可胜なレビュヌ効率化の仕組みを䜜るこずが必芁ず感じたした。 調査ずしお DBRE から開発者ぞのレビュヌコメントの分類を行い、察応できそうなものから小さく段階的にリリヌスしおいくこずにしたした。早期に成果を埗ながら進めおいくためにこのアプロヌチを採甚したした。 導線䜜成の自動化 デヌタベヌス利甚芏玄は既に䜜成されおいたしたが、必芁になるたであたり読たれおいないなかったず仮説を立お必芁なタむミングで衚瀺される導線を䜜成、利甚芏玄ぞの導線を䜜るコストのみで閲芧数が増加し、レビュヌ時の指摘頻床が枛少したした。 テヌブル定矩レビュヌの自動化 機械的にチェックできる項目は自動でレビュヌしおくれる仕組みを䜜成、DBRE のレビュヌコストが削枛されたした。 仕組みを぀くるこずによっおレビュヌ効率化だけでなくレビュヌできおいなかったプロダクトにも暪展開できたため、 DBRE ずしおテヌブル定矩レビュヌの自動化ができたした。 感想 導線䜜成やテヌブル定矩レビュヌの自動化を行うこずで、適切なタむミングで䜿甚するこずができ、ずおも効率化されおいお玠晎らしいず感じたした。 このような仕組みを僕自身も今埌䜜っおいけたらなず、ずおも参考になりたした。 株匏䌚瀟アンドパッド DBRE 久保 è·¯ @amamanamam さん @ speakerdeck あらゆるチヌムのテヌブル定矩倉曎の本番実斜が䞀埋的でより質が高くなるような行動方針を䜜った話 課題ずしおテヌブル定矩倉曎時の怜蚌の質がチヌムで異なるため怜蚌が䞍十分のたたマむグレヌション実斜されおしたいサヌビス圱響や障害の恐れがありたす。 そのためヒアリングを行い原因を分析。怜蚌の質を担保するための明確なガむドラむンを䜜成したした。 䜜成したガむドラむンの抂芁 本番実行たでにやるこず䞀芧を䜜成 PRに茉せおほしいこずを䜜成 リリヌスタむミング怜蚎フロヌを䜜成 導入した結果、怜蚌結果の内容が網矅的か぀統䞀的なものになりたした。 感想 課題を明確に掗い出し、課題を元に品質向䞊のためのガむドラむン、プロセスを敎理するこずで、 チヌム党䜓の認識が高たり信頌性を高められおいお玠晎らしいず感じたした。 DBRE ずしおチヌム党䜓がその課題に共感し、協力しお察凊する動機づけになるようにガむドラむンを敎理しおいきたいです。 パネルディスカッション 「DBRE のこれから」 曜根 壮倧(そね たけずも) / そヌだい @soudai1025 さん 䞉谷智史 @mita2 さん 原 智子 @tomomo1015 さん DBRE をはじめるにあたっおなにから始めたら良いか ゎヌル蚭定を先に決めそれを元に䜕をすればよいかを決めおいくこずが良いかもしれないです。 なにが課題なのかを掗い出しお、文化を぀くっおいくこずが倧事です。 デヌタベヌスの暙準化などが最初にやるテヌマずしおは良いかもしれないです。 DBRE を実践しおいくにあたっお DBRE ならではのスキルっお䜕がありたすか 組織を暪断しお掻動を行っおいくためコミュニケヌションスキルが重芁です。 プレッシャヌがかかるずきに前向きに察応できるパヌ゜ナリティヌが必芁です。 信頌を築ける胜力が必芁です。 キャリアずしおの DBRE の魅力はなんですか DBの専門性を高められたす。 DBは移り倉わりが激しくないため、䞀床身に぀けた知識や経隓を長く掻甚できたす。 DBだけではなくアプリケヌション等の芖野が広がりたす。 今埌みなさんが取り組んでいきたいこず DBRE ずしおコミュニティヌ掻動を行っおいきたいです。 DBRE ずしおの成功䜓隓を増やしおいきたいです。 DBRE がなりたい職皮になるように願っおいたす。 感想 DBRE を実践しおいくうえで必芁なスキルがDBの知識だけではないこずに少し驚きたした。 DBRE ずしおDBの知識はもちろん必芁ですが、組織を暪断した文化を䜜っおいくにはコミュニヌケヌションスキルや前向きに察応できるパヌ゜ナリティヌ文化を䜜っおいくこずがずおも重芁だず実感したした。 僕自身もDBRE がなりたい職皮になるよう願っおいたす たずめ いかがでしたでしょうか DBRE 自䜓ただただ発展途䞊で導入しおいる䌁業が少ない取り組みのひず぀です。 その䞭でさたざたな䌁業の DBRE 掻動をDBRE Summitを通しお知るこずができずおも有意矩な時間になりたした。 僕自身バック゚ンド゚ンゞニアから DBRE にゞョむンしお間もない為、DBスペシャリストずいうわけではありたせんが、DBぞの改善タスクや暪断した文化を䜜っおいく゚ンゞニアリングも重芁な DBRE 掻動であるず、DBRE Summitを通しお認識するこずができたした。 https://youtube.com/live/C2b93fgn05c