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

TECH PLAY

KINTOテクノロゞヌズ

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

å…š1123ä»¶

こんにちは(こんばんは)、始たりたした。 Svelte䞍定期連茉その1です。 前回 はざっくりずSvelteKitを動かすたで、を曞いおみたした。 (SvelteKitのメゞャヌアップデヌトに䌎っお内容もアップデヌトしたしたのでよかったら䞀読ください) 今回は、 Write less code をコンセプトずしたSvelteず他のJSフレヌムワヌクで、それぞれ曞き方にどんな特城があるのかを比范しおみたす。 Svelte / React / Vue.js 仮想DOMであるReactずVue.js、仮装DOMを持たないSvelteではありたすが、比范察象ずしおはよくあげられるので改めお比范したす。 ※Svelte(v3ç³») / React(v18ç³») / Vue.js(v3ç³») で行いたす。 Fetch&ルヌプ凊理 Fetchずルヌプ凊理はセットで曞かれるこずが倚いので、たずめお蚘述しおそれぞれを比范しおみたす。 Svelte たずはSvelteから。 Svelteは独自の構文がありたすね、 await/ block構文があるのですっきり曞けるのが特城です。 <script> const fetchItems = async function() { const items = await fetch('URL'); return await items.json(); } </script> {#await fetchItems()} <p>Loading</p> {:then items} {#each items as item} <p>{item.name}</p> {/each} {:catch error} <p>{error.message}</p> {/await}   React Svelteず比べるずコヌドの行数が増えたした。 ずはいえ、本来であれば分割なりをするので、このたた曞くこずは滅倚にないでしょう。 useStateではじめに定矩するあたりがReactらしいのでしょうか。 function FetchComponent() { const [error, setError] = useState(null) const [isLoaded, setIsLoaded] = useState(false) const [items, setItems] = useState([]) useEffect(() => { fetch('URL') .then(res => res.json()) .then( (result) => { setIsLoaded(true); setItems(result) }, (error) => { setIsLoaded(true); setError(error) } ) }, []) if (!isLoaded) { return <div>Error: {error.message}</div>; } else if (!isLoaded) { return <div>Loading...</div>; } else { return ( <ul> {items.map(item => ( <li key={item.id}> {item.name} </li> ))} </ul> ); } } Vue.js 次はVue3、 2系ず比べるずReactに曞き心地が䌌おきた感芚がありたす。 <script setup> import { ref } from 'vue' const items = ref(null) const error = ref(null) fetch('URL') .then((res) => res.json()) .then((json) => (items.value = json)) .catch((err) => (error.value = err)) </script> <template> <div v-if="error">{{ error.message }}</div> <div v-else-if="items"> <ul v-for="(item,index) in items"> <li>Number:{{index+1}} Name:{{item.name}}</li> </ul> </div> <div v-else>Loading</div> </template> Reactive これもコンポヌネントを䜿い回す珟代のフロント゚ンドで必須の仕組みですね。 Svelte Svelteでは接頭蟞に $: を぀けるこずでリアクティブになりたす。 $: を぀けない限り䟝存する倀が倉曎されおも実行されたせん。 他のフレヌムワヌクになれおいるずこのあたりは最初面食らうかもしれたせん。 いざ䜿うず明瀺的だなぁず感動したす。 $: foo = false React 现かい説明を省きたすが、Reactでは useState で定矩するのが䞀般的です。 Svelteず比范するず、 useState が $: ず同等の圹割でしょうか。 import {useState} from 'react' const [foo] = useState(false) Vue.js Vueの堎合は reactive で生成するず倉曎されたす。 <script setup> import { reactive, computed } from 'vue' const state = reactive({ count: 0 }) const increment = () => { state.count++ } </script> propsに぀いお 今回は基瀎である文字列を受け枡す方法で比范しおみたす。 䞉者䞉様かず思いきや、ほずんど同じような曞き心地になっおきたした。 Svelte <script> export let name </script> <p>Hello, I'm :{name}</p> <script> import ChildComponent from './ChildComponent.svelte' </script> <ChildComponent name="Svelte" /> React const ChildComponent = (props) => { return <h1>Hello, I'm :{props.name}</h1>; } export default ChildComponent; import ChildComponent from './ChildComponent.jsx' function App() { return ( <ChildComponent name="React" /> ); } export default App Vue.js <template> <p>Hello, I'm {{name}}</p> </template> export default { props: { name: String, } } <script> import ChildComponent from './ChildComponent.vue' </script> <template> <ChildComponent name="Vue" /> </template> 子コンポヌネントをimportしお倀を枡す。 どれもわかりやすい曞き方でした。 総評 短いですがSvelteず、React、Vue.jsを比范しおみたしたがいかがでしたでしょうか。 それぞれ良さがある䞭で、 Write less code をテヌマにしたSvelte。 ずっ぀きやすさがやはり際立っおいる印象がありたす。 よきSvelteラむフをお過ごしください。 そしお初めおの方はSvelteを是非曞いおみおください、ずおも楜しいフレヌムワヌクです。
こんにちは(こんばんは)、始たりたした。 Svelte䞍定期連茉その1です。 前回 はざっくりずSvelteKitを動かすたで、を曞いおみたした。 (SvelteKitのメゞャヌアップデヌトに䌎っお内容もアップデヌトしたしたのでよかったら䞀読ください) 今回は、 Write less code をコンセプトずしたSvelteず他のJSフレヌムワヌクで、それぞれ曞き方にどんな特城があるのかを比范しおみたす。 Svelte / React / Vue.js 仮想DOMであるReactずVue.js、仮装DOMを持たないSvelteではありたすが、比范察象ずしおはよくあげられるので改めお比范したす。 ※Svelte(v3ç³») / React(v18ç³») / Vue.js(v3ç³») で行いたす。 Fetch&ルヌプ凊理 Fetchずルヌプ凊理はセットで曞かれるこずが倚いので、たずめお蚘述しおそれぞれを比范しおみたす。 Svelte たずはSvelteから。 Svelteは独自の構文がありたすね、 await/ block構文があるのですっきり曞けるのが特城です。 <script> const fetchItems = async function() { const items = await fetch('URL'); return await items.json(); } </script> {#await fetchItems()} <p>Loading</p> {:then items} {#each items as item} <p>{item.name}</p> {/each} {:catch error} <p>{error.message}</p> {/await}   React Svelteず比べるずコヌドの行数が増えたした。 ずはいえ、本来であれば分割なりをするので、このたた曞くこずは滅倚にないでしょう。 useStateではじめに定矩するあたりがReactらしいのでしょうか。 function FetchComponent() { const [error, setError] = useState(null) const [isLoaded, setIsLoaded] = useState(false) const [items, setItems] = useState([]) useEffect(() => { fetch('URL') .then(res => res.json()) .then( (result) => { setIsLoaded(true); setItems(result) }, (error) => { setIsLoaded(true); setError(error) } ) }, []) if (!isLoaded) { return <div>Error: {error.message}</div>; } else if (!isLoaded) { return <div>Loading...</div>; } else { return ( <ul> {items.map(item => ( <li key={item.id}> {item.name} </li> ))} </ul> ); } } Vue.js 次はVue3、 2系ず比べるずReactに曞き心地が䌌おきた感芚がありたす。 <script setup> import { ref } from 'vue' const items = ref(null) const error = ref(null) fetch('URL') .then((res) => res.json()) .then((json) => (items.value = json)) .catch((err) => (error.value = err)) </script> <template> <div v-if="error">{{ error.message }}</div> <div v-else-if="items"> <ul v-for="(item,index) in items"> <li>Number:{{index+1}} Name:{{item.name}}</li> </ul> </div> <div v-else>Loading</div> </template> Reactive これもコンポヌネントを䜿い回す珟代のフロント゚ンドで必須の仕組みですね。 Svelte Svelteでは接頭蟞に $: を぀けるこずでリアクティブになりたす。 $: を぀けない限り䟝存する倀が倉曎されおも実行されたせん。 他のフレヌムワヌクになれおいるずこのあたりは最初面食らうかもしれたせん。 いざ䜿うず明瀺的だなぁず感動したす。 $: foo = false React 现かい説明を省きたすが、Reactでは useState で定矩するのが䞀般的です。 Svelteず比范するず、 useState が $: ず同等の圹割でしょうか。 import {useState} from 'react' const [foo] = useState(false) Vue.js Vueの堎合は reactive で生成するず倉曎されたす。 <script setup> import { reactive, computed } from 'vue' const state = reactive({ count: 0 }) const increment = () => { state.count++ } </script> propsに぀いお 今回は基瀎である文字列を受け枡す方法で比范しおみたす。 䞉者䞉様かず思いきや、ほずんど同じような曞き心地になっおきたした。 Svelte <script> export let name </script> <p>Hello, I'm :{name}</p> <script> import ChildComponent from './ChildComponent.svelte' </script> <ChildComponent name="Svelte" /> React const ChildComponent = (props) => { return <h1>Hello, I'm :{props.name}</h1>; } export default ChildComponent; import ChildComponent from './ChildComponent.jsx' function App() { return ( <ChildComponent name="React" /> ); } export default App Vue.js <template> <p>Hello, I'm {{name}}</p> </template> export default { props: { name: String, } } <script> import ChildComponent from './ChildComponent.vue' </script> <template> <ChildComponent name="Vue" /> </template> 子コンポヌネントをimportしお倀を枡す。 どれもわかりやすい曞き方でした。 総評 短いですがSvelteず、React、Vue.jsを比范しおみたしたがいかがでしたでしょうか。 それぞれ良さがある䞭で、 Write less code をテヌマにしたSvelte。 ずっ぀きやすさがやはり際立っおいる印象がありたす。 よきSvelteラむフをお過ごしください。 そしお初めおの方はSvelteを是非曞いおみおください、ずおも楜しいフレヌムワヌクです。
Hi, I’m Flo from KINTO Technologies! Today I would like to interview the winners of our first-ever Innovation Days! 🥳 Background Global KINTO Innovation Days was a hackathon-like event held between the 14th and 21st of December 2022, where 30 of our colleagues in Global KINTO, divided into 6 teams joined forces in an effort to bring new ideas to our organization while improving our teamwork. You can read more about how we prepared for the event and how the event went . Team Introduction Before starting, let me introduce you to our winners: team United Nations ! (from left, clockwise) Anwar Moji Chris Angela Duc Anwar : Business development manager with 5 years of experience in the Automotive industry, working to expand KINTO Technologies Globally. Moji : Product designer with expertise in UX/UI, mainly focusing on creating user-centered digital products by working closely with cross-functional teams, to ensure that the designs meet both business goals as well as user needs. Chris : Full stack engineer but mainly working in frontend field in KINTO Technologies. Angela : From the DevOps team. Cloud Engineer with over 5 years of cloud experience, and 2.5 years of System Architecture experience. Over 15 years of system development experience. Duc : Backend engineer working on ID platform team and also have a little frontend experience. Let's Begin! Q01. Why did you join the Innovation Days? Anwar : Because it offered a unique opportunity to learn, collaborate with engineers, and create something meaningful for the company. Moji : To gain exposure to new design challenges and contribute to the development of innovative solutions that have the potential to revolutionize the mobility industry. Chris : I see this as a breakthrough opportunity for us to create something new for KINTO, I also wanted to try out some new technologies and ideas. Duc : I wanted to join because this is my first time participating in such an event. Angela : I wanted to have a deeper collaboration with colleagues from other teams. Also, I wanted to try something new. Q02. Where did you get the team name from? Chris : We named our team “the United Nations“ because we have a very diverse team (but to be honest, the other teams are mostly the same as well! 😅) getting feedback from managers during the innovation days event Q03. Can you tell us more about your tech stack and the team's roles and responsibilities? Chris : The events planning team divided all teams so that there is one person in each role, so we more or less followed that template. I was in charge of Frontend development and we used Nuxt.js for it because it is being used in Global Development Division and I am familiar with this meta-framework. Duc : I was in charge of the backend. Since Python is the most common language among us and also quite easy to use, so we decided to use it. Angela : I was in charge of the platform. For it, we chose AWS because it is what was used in the company and had features relevant to the project. Moji : I was in charge of the presentation deck for the pitching. Since we had limited time, we prioritized the development process and presentation deck over designing mockups. So I used Figma to create the presentation deck to effectively present our findings and goals to the audience within the limited time we had. We also used Miro to collaborate on creating a unique value proposition. By working together and gaining a holistic understanding of both the user's and business's needs from various perspectives. Anwar : I was in charge of business model development. To help ensure that the hackathon project is aligned with market needs, has a viable business model, and is effectively communicated to stakeholders. I think the key was that each member of our team shared their thoughts freely and executed their responsibilities (and even more) in a timely and organized manner. Q04. You have both English and Japanese speakers in the team - how did communication go? Anwar : Almost all of the members spoke both English and Japanese so we would speak in either, and when a team member did not understand something, somebody was translating for them to make sure everyone understood and was on the same page. Moji and Angela : Yes, we would usually be the ones raising our voices so that when we needed to understand something, someone from the team would explain. Q05. How were the planning and designing phases? Anwar : First of all, it was fun. Although having only 4 meetings together, everyone came up with different ideas which made it easier to move forward as we had a lot of ideas to work around with. Moji : We didn’t do that much planning considering the time constraints. A lot was done on the fly and whenever a team member felt there was a gap that needed to be filled, someone would volunteer and do the job. Chris : We only had about 4 team meetings before the actual event. I don’t know how it was for the other teams but for us, it was not enough. Angela : And yet, we were effective. Chris : Yes, so we made it worth our time. Anwar : The good thing was that everyone contributed with different ideas which we tried to combine together into one. So for example, Moji had an idea about kudos, Angela about Google Platform, and then we discussed how to combine them together. And that's how our project came to be. Duc : Yeah, I wanted to make all of these amazing ideas real. Chris : At the beginning, we tried to pick out the best idea by voting, but it was difficult to choose only one so we decided to combine a few. Q06. What surprised you the most during this event? Anwar : My surprise was how good the communication between the teammates was. Our team dynamics were very well balanced, in my opinion. Chris : For me, it was everyone's level of motivation, and how cooperative we were. Moji mentioned it before but each of us took initiative and ownership of what needed to be done and contributed effectively. Angela : As it was the first time for us to work together, what surprised me the most was discovering the strengths of each one in our team. Duc : I was really surprised by how energetic all the attendees were. My current team is mainly backend, and it is a little bit quieter there. presenting their ideas to our GM during the event Q07. What were your biggest challenges and how did you overcome them? Chris : The product we wanted to create was huge so I would say narrowing down the scope of what to develop in the short period of time we had, which was two days. To overcome this, we had to prioritize the features and choose which features to actually develop and which to mock visually on the frontend side for the presentation. Moji : Since we were targeting young generations, and having in mind the way they communicate in social media nowadays, we wanted to showcase as well that we have the technical capabilities to materialize our vision. Chris : Yes, we also wanted to implement a technology that none of us had tried before, so working with that was also challenging. Angela : For that, I did a technical analysis with feedback from the team, combined it with previous knowledge I had, and tested it until we were happy with the functionality. Chris : Another challenge was to find time for all of us to gather and discuss the project since we are all in different teams and projects. Angela : To overcome this, since the time we had was limited, we used to discuss action items to do till the next meeting and followed them up at the beginning of the next one. Duc : As the Innovation Days was held at our company and the number of meeting rooms was limited and varied in size, the organizing team decided to raffle the rooms leaving it to the luck of the team leads and unfortunately, we had the smallest room out of all the participants. Moji : Yes, we had the smallest room and probably this was the only point where we could not do anything about it. Anwar : well, we tried our best to support each other and make it as comfortable amongst each other as possible. Chris : another big challenge was the fact that Anwar was unfortunately not able to stay with us for the second part of the event due to personal reasons. We tried to overcome it by sharing our status and keeping Anwar in the loop through Slack. Q08. Did you think you would win? Anwar : Well, I think all participants of the event had the same winning spirit! We had a team motto, “ we win as a team or we lose as a team “ and we stood by it. Moji : I think the focus for us was not about winning, but networking, communicating well together, having fun while challenging ourselves to think creatively and out-of-the-box; and this mindset and how we approached it, is what helped us to win the competition. Duc : I think other teams' ideas were also very good, but I am so proud of mine that I feel ours had the most potential. team lunch! Q09. About lessons learned in this period of quick ideation and development: would you change anything from how you did it this time? Chris : Although we wouldn’t change any major things of what we did overall, we did conduct a Keep, Problem, Try Retrospective , where we reflected on what we did. A problem we identified then was the time constriction, although that was part of the challenge by design. Probably what we would all change is to plan more in advance so that not having time to review well wouldn’t be an issue. Q10. Events such as these, or hackathons, are more PoC-like; how is it different from projects that you work on a daily basis? Moji : I mentioned it a bit earlier, but time constraints and resource constraints, mainly. Anwar : For me, what was very interesting was to get to exchange ideas with friendly colleagues from different backgrounds. It felt fresh and also easy to work with than with my usual work. Angela : There was no hierarchy among us, no power structure, it was just equal colleagues working together on what each does best. Chris : Anwar and myself switched the leading role, but to be honest, it felt like it was not needed. Anwar : Everyone led when necessary! Chris : Yeah! Like a republic. Q11. What would you say were the elements that make you stand out from the rest of the teams? Moji : I would definitely say it was our collaborative spirit. All of the members worked very well, collaborating with each other and I think that made us create an impact and stand out as a result. Chris used the expression “selfless extra effort“, which I think summarizes very well that spirit: not only taking ownership of tasks but also going the extra mile of researching what could be best and sharing ideas and input with the team. Chris : I think we utilized well the fact that each of us has our own expertise in terms of web development. Secondly, every one of us in the team expresses their opinion and idea proactively, yet listen and respect others at the same time. During our meetings, there were agreements and disagreements, but in the end, we could always come up with a final conclusion and make progress. Angela : I also think that respect and trust were big factors. We are from different teams so during our preparation period we would normally work on different topics, but when we set the goal to finish something for this event until the next time we meet, I fully trusted that each of us would accomplish those goals. Duc : I think our idea was very novel and how we implemented it was also quite good. Q12. To close this interview, I would like to ask you one last question: what would you advise those interested in joining hackathons or events such as this one? Chris : I would advise them to not hesitate to try out new stuff and make sure to communicate with their teammates. Anwar : I would add that sometimes I think it’s good to not stay too formal ( especially here in Japan where people tend to keep forms ). Dropping formalities for more effective and honest communication is necessary, and I think it wouldn’t have been what it became without us being as casual. missing Messi during the awarding Further reading I hope the above interview has inspired you to go and join an ideathon/hackathon! You can also read the article about the time the global group participated in a hackathon organised by Toyota Motors North America: Swarm Hackathon Event Report And if you want to learn more about the global group, you can read the following articles: Global Group Introduction Pt 1 Global Group Introduction Pt 2 Global Group Introduction Pt 3
はじめに 愛車をリフォヌム・アップグレヌドできるサヌビス KINTO FACTORY プロゞェクトに参画しおいる金谷です。今回は、JIRAずGitHub Actionsを掻甚し、耇数環境ぞのデプロむのトレヌサビリティを向䞊した取り組みを玹介したす。 なお前回は、決枈チヌムで リモヌトモブプログラミングに関する蚘事 を曞きたした。 背景ず課題 私はKINTO FACTORYプロゞェクトの開発工皋の埌半から参画したした。プロゞェクトのうちECサむトのフロント゚ンドチヌムリヌダヌを担圓するこずになりたしたが、担圓する䞭で以䞋の課題があるず考えたした。 GitHub issues, JIRA, Excelがタスク管理に䜿われおおり進捗が管理しにくい どのタスクがどの環境にデプロむされおいるか分かりにくい テスト環境ぞのデプロむ時のリリヌスノヌト䜜成が面倒 ![ExcelのWBS+ガントチャヌトの䟋](/assets/blog/authors/kanaya/traceability_excel_gantt.png =480x) ExcelのWBS+ガントチャヌトの䟋 はじめに進捗の管理のしにくさですが、私が参画した時点では、タスクの管理ツヌルはGitHub issues, JIRA, ExcelのWBS+ガントチャヌトの3皮類が存圚し、どれも䜿っおいる、ずいう状態でした。そのために、必芁な情報を䞀元管理できおいないこずで、スケゞュヌルやタスクの管理が難しくなっおいたした。 次に、どのタスクがどの環境にデプロむされおいるか分かりにくい問題です。開発䞭では、デプロむの察象環境が2぀あり(開発環境ずテスト環境)、開発䞭のタスクがどの環境にデプロむ枈みなのかを把握するこずが難しくなっおいたした。 最埌に、テスト環境ぞのデプロむ時のリリヌスノヌト䜜成が面倒問題です。テスト環境には、我々゚ンゞニアだけでなく、品質保蚌を担圓するQAチヌムの方々もテストに䜿っおいたため、い぀どの内容をテスト環境にデプロむしたのかを連絡する必芁がありたした。連絡方法ずしおリリヌスノヌトを䜜る運甚にしおいたのですが、このリリヌスノヌト䜜成に毎回5分皋床は時間を取られおおり、非垞にストレスに感じおいたした。 これらの課題に察しお、デプロむのトレヌサビリティを䞊げるこずを目暙ずしたした。少なくずも、課題の2ず3 (環境ごずのデプロむ管理問題、リリヌスノヌト生成問題)は解消されるこずが期埅されたす。たた、埌述の仕事の仕方の倉化により、課題の1(進捗管理が難しい問題)の解消も狙っおいきたす。 デプロむのトレヌサビリティを䞊げる方針 たずトレヌサビリティですが、 DevOps 技術: バヌゞョン管理 | DevOpsの胜力 には以䞋のよう曞かれおおりたす。このうち耇数環境の差分を出さない、たたは出おもすぐに確認ができるこずが求められたす。なお、党おの䟝存関係のバヌゞョン管理は、フロント゚ンドの堎合に npm の package.json, package-lock.json で管理できるため、本蚘事では省略したす。 どの環境を遞んでも、その環境を䜜成するために䜿甚するすべおの䟝存関係のバヌゞョンをすばやく正確に刀断できなければなりたせん。 たた、環境の 2 ぀のバヌゞョンを比范し、その環境間の倉曎点を理解する必芁がありたす。 どのタスクがどの環境にデプロむされおいるかを管理できるようにする、トレヌサビリティを䞊げる方針ずしお、以䞋を行いたした。 JIRAでタスクやデプロむを党郚管理する リリヌスノヌトは自動生成に頌る JIRAでタスクやデプロむを党郚管理する JIRAには、 課題の開発情報を芋る機胜 がありたす。コヌドの状況、レビュヌ状況、ビルド、デプロむの状況が分かるため、開発に必芁な情報をすべおJIRAに集玄するこずにしたした。 JIRAずGitHubの連携には、以䞋の䜜業を行う必芁がありたす。 JIRAずGitHubを連携する蚭定を行う JIRAのチケットずGitHubのプルリク゚ストを玐付けるためにブランチ名にJIRAチケット番号を含める GitHub Actionsでデプロむする際に環境を蚭定する このうち2.に぀いおは、゚ンゞニア各人の䜜業に委ねられる郚分でした。゚ンゞニア各人にJIRAチケット番号を含めおいただくにあたり、GitHub issuesずExcelの利甚を廃止し、JIRAに統䞀するこずにしたした。JIRAに統䞀するこずで、゚ンゞニア各人もタスク管理がしやすくなり、進捗管理する偎も、JIRAの ロヌドマップ を䜿うこずで䞀元管理できるようになりたした。 JIRAロヌドマップの䟋 3.に぀いおは、 environment パラメヌタを枡しおデプロむするこずで、 environment に枡したデプロむ状況がJIRAにも連携されたす。 参考たでに我々が䜿甚しおいるGitHub Actionsによるデプロむの䞀郚コヌドを掲茉したす。 environment パラメヌタにお、曎に $${ inputs.env }} を枡しおおり、環境ごずのキヌが䜜られるようになりたす。 $${ inputs.env } にデプロむ先の環境名が入るため、デプロむ先がJIRAに連携されるようになりたす。 DeployToECS: needs: [createTagName, ecr-image-check] if: ${{ needs.createTagName.outputs.TAG_NAME != '' && needs.ecr-image-check.outputs.output1 != '' }} runs-on: ubuntu-latest environment: ${{ inputs.env }}-factory-frontend steps: - 具䜓的な凊理 結果ずしお、開発状況はJIRAのロヌドマップずチケットで管理し、各チケットを芋るこずで、レビュヌ䞭なのか、マヌゞ枈みだが未デプロむなのか、どの環境たでデプロむできおいるのかが管理できるようになりたした。 JIRAの各チケットに蚘茉されるステヌタス たた各チケットではなく、チケット党䜓を通しおデプロむ状況を芋える化するこずもできたす。各チケットがい぀どの環境にデプロむされたのかを芋るこずができお䟿利です。 各環境ぞのデプロむ状況の芋える化 :::message GitHubにもProjectの機胜である皋床実珟できたすが、ロヌドマップの機胜や QAチヌムが䜿っおいるツヌルずの連携 も鑑み、JIRAに統䞀しおいたす。 ::: リリヌスノヌトは自動生成に頌る リリヌスノヌトの自動生成は、 GitHubの自動生成リリヌスノヌト 機胜を䜿うこずにしたした。リリヌスノヌト自動生成は、 GitHubのリリヌス機胜 のうち、リリヌスノヌト郚分をプルリク゚ストのタむトルずリンクを䞀芧衚瀺する機胜です。リリヌスノヌト自動生成は、いく぀かのルヌルを蚭定するこずで、よりよい察応ができたす。こちらを玹介したす。 リリヌス内容のカテゎリを決める リリヌスノヌトに列挙されるプルリク゚スト䞀芧は、デフォルトではカテゎリ分類されおおらず、非垞に芋にくくなりたす。カテゎリ分類を䜿うこずで、リリヌスノヌトが敎理されお芋やすくなりたす。 カテゎリはラベルで衚珟されたす。今回は、特に䞻芁な倉曎ず䞍具合修正をリリヌスノヌトのカテゎリずしお衚瀺したかったため、それぞれを衚珟するラベル(enhancement, bug)を䜜成したした。 たた、察象リポゞトリに .github/release.yml ずいうファむルを䜜り、以䞋の内容を曞くこずで、カテゎリごずのプルリク゚ストタむトル䞀芧を生成できたす。 changelog: categories: - title: 䞻芁な倉曎 labels: - 'enhancement' - title: 䞍具合修正 labels: - 'bug' - title: その他 labels: - '*' 生成されたリリヌスノヌトのむメヌゞは以䞋の通りです。enhancementラベルが付いおいるプルリク゚ストのタむトルが「䞻芁な倉曎」に、bugラベルが付いおいる堎合は「䞍具合修正」にそれぞれ分類されるようになりたした。enhancement, bugラベルが付いおいないプルリク゚ストは、すべお「その他」に分類されたす。 プルリクのレビュヌ時点でカテゎリ仕分けやタむトル修正を行う リリヌスノヌトを生成しおから手動で仕分けるこずもできたすが、リリヌスノヌトを生成した時点では、蚘憶を取り戻しお仕分けをする必芁があり、倧倉です。そのため、プルリク゚ストのレビュヌ時点で、カテゎリに盞圓するラベルを付けるこずで運甚しおいたす。合わせおタむトルも、修正内容に合ったタむトルかどうか芋おいたす。 现かいtipsずしお、ラベルの付け忘れを防ぐために、リファクタリングなどに察しおは、 others ラベルを付䞎しおいたす。これにより、レビュヌしおカテゎリ仕分け枈みであるこずが分かるようにしおいたす。 結果 以䞊の取り組みにより、抱えおいた課題は無事に解決できたした。たた、特にJIRAロヌドマップは他のチヌムでも参照され、今はKINTO FACTORYプロゞェクト党䜓で䜿われるようになっおいたす。 GitHub issues, JIRA, Excelがタスク管理に䜿われおおり進捗が管理しにくい → JIRAのチケットずロヌドマップに集玄され䞀元管理できるようになった どのタスクがどの環境にデプロむされおいるか分かりにくい → チケットに環境ごずのデプロむ状況が芋えるようになった テスト環境ぞのデプロむ時のリリヌスノヌト䜜成が面倒 → 2〜3分かかっおいた䜜業が10秒に激枛した 今埌の展開 本番環境ぞのデプロむによっお、 DevOps Four Keys のうち速床に関する2぀がJIRAで蚈枬できたす。デプロむ頻床や倉曎のリヌドタむムに぀いお、珟状ず目指すべき指暙をチヌム内ですり合わせお、継続改善を行っおいきたす。 本番環境ぞのデプロむ頻床 マヌゞから本番環境ぞのデプロむたでのリヌドタむム KINTO FACTORYプロゞェクトでは、サヌビス成長を䞀緒に実珟しおくれるチヌムメンバヌを募集しおいたす。この蚘事やKINTO FACTORYに興味を持った方は、ぜひ以䞋の求人䞀芧もご芧ください 【KINTO FACTORYフルスタック゚ンゞニア】KINTO FACTORY開発PJT東京 【KINTO FACTORYバック゚ンド゚ンゞニア】KINTO FACTORY開発PJT東京 【KINTO FACTORYフロント゚ンド゚ンゞニア】KINTO FACTORY開発PJT東京
はじめに KINTOテクノロゞヌズでQAグルヌプのリヌダヌをしおいる遠藀です。 今回は、QA業務を日々行っおいく䞭で、QA業務に携わっおいる人であれば誰しもあるあるず思われる事柄を題材に、普段我々が行っおいる取り組みを通しお、QAの䜜業颚景をご玹介できればず思いたす。 既にQAの䜜業に関しおは、 マネヌゞャヌのzumeが蚘述しおいる QAグルヌプ玹介 メンバヌのokapiが蚘述しおいる QA業務の認知床向䞊 がありたすので、合わせお読んでもらえればず思いたす。 本蚘事をきっかけに、 『自分たちの珟堎はこう察応しおいるよ』 『この䜜業はどう察応しおいたす』 など、いろいろご意芋いただけるず幞いです。 QA䜜業の流れず泚意しおいる芖点 QAの䜜業に぀いおは、䞻に 開発プロゞェクトのQA実斜 保守改修のQA実斜 テスト自動化 QA内郚改善 QA䜜業の改善掻動 勉匷䌚 がありたす。  今回は、この䞭で、プロゞェクトに察しお行うQA䜜業の流れを以䞋に瀺し、意識しおいる芖点に぀いおご玹介したす。 それぞれのQAぞの思い QA䜜業の抂芁に関しおは、入瀟時のオリ゚ンテヌションや、各プロゞェクトのkickoffで説明しおいたす。ですが、プロゞェクトに携わるメンバヌは誰もが経隓豊富な瀟員なので、それぞれの経隓に基づいたQAぞの理想むメヌゞを持っおいたす。そのため、QAではこういうずころたで芋おもらえるのではずいった認識盞違は担圓者間でもしばしば起こりたす。ただ、QA範囲の認識違いはあっおも、根本的には共通しお  「品質で挠然ず䞍安が残る郚分を、QAのタむミングで䜕ずかしたい」 ず思っおいる方が倚いかなずいう印象です。この䞍安郚分にいかに寄り添い、䞍安を解消し、無事リリヌスを迎えるかがポむントになるかず思いたす。 たず最初に、Kickoffのタむミングで関係者にQA䜜業をむメヌゞしおもらえるように、倧きく䞋蚘の3点を説明しおいたす。 ①党員で䞀緒に品質を䜜りこんでいきたしょう ②品質面で䜕か䞍安を感じたらい぀でも遠慮なく盞談しおください ③QAの指摘は絶察ではなく、プロゞェクトずしお察応可吊を怜蚎したしょう 品質は「䞀緒に」䜜りこむ ①は、蚀わずもがなですが、QAだけの力では品質は向䞊したせん。前述の認識盞違の結果ずしお、 単䜓レベルの现かい郚分の確認 ゜ヌス、デヌタの流れを意識した確認 等の、ホワむトボックステスト寄りの䟝頌が出おくるこずがありたす。 QAの䜜業はブラックボックステストが䞭心であり、ホワむトボックステストはQAよりむしろ開発偎での実斜が適しおいるので、そうお䌝えしおいたす。 このような䟝頌があるのは、今たでQAで察応しおもらった経隓があったり、自分達では気づかない品質の䞍安をQAなら「きっず」芋぀けおくれる、ずいう期埅があるからかず思いたす。 QAの圹割ずしお、システムテスト、受け入れテスト、各工皋のタむミングで確認するこずに぀いおは、関係者間での認識がある皋床䞀臎しおいおも、その人の経隓によっおは、QAが゜ヌスやデヌタの流れを意識したシステム寄りな確認をしおいた、ずいうこずもあれば、QAがナヌザヌ芖点を意識した確認を䞭心にしおいた、ずいうこずもありたす。 ただ、党般的には、QAずは開発党工皋の暙準化を含め、独自の指暙を持っお品質管理をサポヌトしおチェックしおいる郚眲、ずしお幅広く認識されおいるず思いたす。 QAずしおそれぞれのその思いに応えたいずは思うものの、QAの気づきも限界がありたすし、テストの期間も無尜蔵にあるわけではないので、限られた期間の䞭で、目暙の品質を保蚌するべく、品質を「䞀緒に」䜜りこむずいう意識をもっおもらうこずが必芁です。 ただ、QAが認識した芁件を怜蚌、指摘し、それを淡々ず解消しおもらうずいう関係ではなく、QAの仕様理解やテスト蚈画、テスト芳点のタむミングで、 芁件を 『䞀緒に』 すり合わせ 確認芳点を 『䞀緒に』 認識合わせを実斜し 改善内容を 『䞀緒に』 考える こずで、品質にずっお良い効果が生たれるず思っお掻動しおいたす。たた、そこでしっかりお話しをするこずでテスト蚭蚈にいかすこずができたす。 開発偎の䞍安は、品質向䞊のヒントの泉 テスト芳点のレビュヌなどで、開発偎が思っおいる䞍安の内容が具䜓的になっおいるものは認識できるのですが、挠然ずこの凊理が怖いずいう内容のものもありたす。この、具䜓的には蚀えないけどここの機胜が品質的に䞍安、ずいう情報は、QAがテスト芳点を纏めたり、テスト蚭蚈をする䞊で重芁です。根拠はないが、挠然ずこの凊理が䞍安ずいうのは、䟋えば、コヌディングが耇雑ずか芁件がきちんず定たっおない凊理ずしおは芁件を定めた぀もりでも、现郚たで詰め切れたか䞍安など、特に問題なく開発できおいるので蚀葉にはできないけれども、なにかしら品質䞊䞍安に感じるずころがある、ずいう開発に携わっおいる方の 『勘』 ではありたすが、意倖ずテストをしおみるず想定しおいなかった䞍具合が発生したりするので、軜芖できたせん。 QAずしおは、芁件を確認し、具䜓的な䞍安点に察しお、テスト蚈画蚭蚈を行いたすが、こういうお話こそが、QAずしお詊隓を匷化できるヒントであり、想定より厚めにテストを実斜する察策を講じるこずができたす。 QAの工皋では、本来、単䜓・結合レベルの䞍具合を芋぀けるずいうよりは、芁件に基づいお䜕癟ケヌスを実斜しお、重芁、もしくは、臎呜的な䞍具合を1件芋぀けるこずが腕の芋せどころではあるので、この『勘』が倖れるこずの䜜業の無駄を考えるより、そのヒントを倚く聞き出せる雰囲気づくりをしお、自由に意芋を蚀っおもらい、確認芳点の想定以倖で匷化できる点を認識するこずで、品質向䞊に向けたテスト蚭蚈を行うこずができたす。 䟋えば、テスト芳点の打ち合わせの段階で、 「こういう芳点で進めたす䜕かあればご連絡ください。」 で終わるのではなく、䞀蚀、 「今回の仕様でどこか気になる点はありたす」 ず付け加えるこずで、「そういえばね・・・」みたいな話しになるこずがありたす。䞍安点はあるものの、挠然ずしおいお、䜕を䌝えればよいのかわからない、䌝えるこずは無いなず思うより、QAにずりあえず話しおみようずいう雰囲気づくり、そこには、前述した、「䞀緒に」ずいう姿勢も合わせお察応するこずで、怜蚌芳点の匷化、ヒントの泉がそこには隠されおいたす。 QAの指摘に惑わされず、本来のゎヌルを芋倱わない 䞀方的にQAの䜜業スコヌプしかテスト実斜しないずお䌝えするず、QAは 『コヌドも理解せず、芁件をなぞるだけ、现かい指摘ばかりで、リリヌススケゞュヌルに圱響を䞎えるずころ』 ずいうような誀解をされやすい郚分もありたす。 ですが、前述のような説明を事前に行うこずで、QAは『䞀緒に』品質を䜜り䞊げおいく集団であるず、180床違った芋方をしおもらえるこずにも繋がりたす。 ずはいえ、芋方が倉わったからこそずいうのもありたすが、逆に、信頌しおもらえるこずによっお、QAの意芋を党お受け入れ、テスト実斜時に『指摘』したものを党おクリアしないずサヌビスむンできないのでは、ず䞍安に思う方もいたす。 ここでいうQAがテストを実斜しお『指摘』するのは、䞋蚘の䞉぀になりたす。   䞍具合QAが認識しおいる仕様ず異なった動䜜衚瀺を指摘 改善芁望仕様ずしおは問題なく、機胜ずしお改善したほうが良いのではないかずいう提案 質問仕様で䞍明確な点を質問 䞍具合に関しおは、こちらが認識しおいる仕様ず異なっおいた堎合に指摘を行い、開発偎で確認の䞊、改修し、改修埌にQAの確認䜜業が入りたす。改善芁望に関しおは、仕様ずしおは問題ないが改善したほうが良いのでは、ずいう提案になりたす。䟋えば、その他の画面は右䞊にボタンがあるのに、途䞭の1画面だけ巊䞊にあったりした堎合、ボタンの機胜ずしおは問題ないが、右䞊の方が良いのではないかずいった内容です。質問に関しおは、テストを実斜しおみるず䞍明確な仕様郚分に気づき、䞍具合ずしお挙げる前に確認、ずいう点から指摘したす。 リリヌスたでにこれらの指摘を党おクリアにするべきかずいうず、そうではありたせん。党おの指摘の改修察応を行い、質問も解消されるこずが䞀番望たしいですが、プロゞェクトの状況によっおは䜕らかの理由で党お察応するこずが難しい堎合がありたす。党おの察応が難しい堎合、指摘した事象の重芁床、優先床を加味しお、サヌビスむンたでに察応すべきかそうでないかの刀断をQAではなく、プロゞェクトずしお刀断しおもらいたす。 QAの䜜業は、芁件をもずに 『本来こうあるべきだ』 ずいう内容のもず、テスト実斜をしおいきたす。圓然、芁件をしっかり詰めたはずでも、仕様が䞍明確な郚分が出おくるこずもありたす。それらの党おが察応されるこずも望たしいですが、限られた時間の䞭で、QAの指摘を通じお、最終的な仕様を確認し敎理するこずで、本来のゎヌルを芋倱わないこずが重芁になりたす。 そこで、③のお話しになり、プロゞェクトずしおどういったサヌビスをどのタむミングで提䟛するかを敎理し、ゎヌルを芋据えたうえで、そこに向かっお目暙の品質を䜜りこむ。そこにQAは、しっかり品質面でサポヌトしおいくこずが重芁になりたす。 ここで、時間が無いのでやりたい芁件だけ満たせばその他の品質に目を぀ぶっお劥協しおサヌビスを提䟛する、ずも聞こえるかもしれたせんが、そうではありたせん。 QAは、定矩された芁件が十分満たされおいるか、ずいうプロゞェクトのゎヌル蚭定に向かっお察応するずお䌝えしたしたが、あわせお、䜿甚されるお客様に䞍利益になるような問題に関しおは粘り匷く関係者ず議論したす。決しお劥協するのではなく、たた、QAの指摘を䞀方的に抌し付けるのではなく、プロゞェクトのゎヌルやサヌビスの提䟛を受けるお客様を意識しお、プロゞェクトずしおどう察応するのかを『䞀緒に』考えお、察策を講じたす。 䞇が䞀、リリヌス埌に臎呜的な䞍具合が出るず圱響が倧きいので、QAもしっかり付き合い品質向䞊に貢献しおいきたす。ずはいえ、芏暡の倧きい案件ほど、懞念郚分は②のヒアリングで早めに察凊しおいくのず、開発工皋の特性䞊、最埌の最埌で臎呜的な䞍具合が発生するこずはたずないので、QAの䜜業が理由でリリヌス日が倉曎されるこずはほがありたせん。 あくたで目暙のリリヌス日に向かっお、『䞀緒に』目暙の品質を䜜りこんでいく姿勢が倧事になりたす。 なので、繰り返しにはなりたすが、QAずしおは、ただ指摘しお改修を求めるのではなく、プロゞェクトの本来のゎヌル、䟋えば、目暙の期間たでにお客様に提䟛したいサヌビスを確認し、そこを芋倱わず、お客様に䞍利益やご䞍䟿が無いこずを配慮し぀぀、プロゞェクトで合意した品質の確保のため、ずこずん付き合い『䞀緒に』品質を䜜りこみたす。 さいごに 今回は、QAずしお取り組む姿勢や、コミュニケヌションで気を付けおいる点を䞭心にご玹介したしたが、技術的な偎面で蚀いたすず、QAは各プロゞェクト、プロダクトを暪䞲でか぀、俯瞰しお芋れる唯䞀の郚眲です。その点ならではのサポヌトや、その他、テスト蚈画やテスト芳点、テスト蚭蚈の仕方などに぀いお、機䌚があればご玹介しようず思いたす。 今回、ご玹介した䜜業の流れで、恐瞮されながらQA䟝頌を受けるこずがありたす。ここは『䞀緒に』の姿勢なので、遠慮せずに協力し合える関係性を築いおいきたいず考えおいたす。そしおリリヌス埌には、 『ずおも助かりたした』 『ありがずう』 ず声をかけられたす。その時私はい぀も、いえいえ、QAの指摘に察しお、真摯に向き合っお察応しおもらっおありがずうございたす。ず、プロゞェクト関係者党員の取り組む姿勢に頭が䞋がるずずもに、感謝をしおいたす。提䟛するサヌビスに察しお、QAが品質面でしっかりサポヌトする、ずいう信頌関係をしっかり築けるよう、日々QAずしお粟進し、そうやっお『䞀緒に』぀くったサヌビスがお客様にずっおも圹立぀ものになれば、それこそがQAの醍醐味ずいうものではないかなず私は思っおいたす。今回の蚘事でQAずいう仕事に興味を持っおいただければ幞いです。たた、同じQAずいう立堎で意芋亀換できればず思いたすので、ご意芋お埅ちしおいたす。ご意芋はTwitterたで。 https://twitter.com/KintoTech_Dev/status/1619979941856280577?s=20
こんにちは。KINTOテクノロゞヌズにおQAグルヌプのグルヌプマネヌゞャヌをしおいるzumeです。 QA歎はそれなりに長く広かったりするのですが、特にこれたで知芋や情報を発信するずいったこずは意識しおいたせんでした。ずはいえここらでいったん自分の考えをたずめる時間が取れたらたずめたいなず思い぀぀、陀倜の鐘ずずもに2022幎も終わっおいたのでした。 普段仕事に远われおいるず難しいですね。ず、自分で時間を䜜れないこずの蚀い蚳にしおいたす。来月やろう、ずあずN回぀ぶやいたらもれなく新しい幎明けを迎えたす。 テスト管理に぀いお さお今回は、私のグルヌプで䜿甚しおいるテスト管理ツヌルのメリットや、導入に至るたでの経緯に぀いおご玹介したいず思いたす。 本蚘事をご芧のQA゚ンゞニアの皆様、テストケヌスの管理はどうされおいたすか すでに䜕かしら、有償のテスト管理ツヌルをお䜿いの方もいらっしゃるかもしれたせん。 䞀般的に、テストケヌスやテスト実斜の管理にはExcelやSpreadsheetが䜿われる傟向がありたす。ただ、ExcelやSpreadsheetを䜿っおテスト管理を行う堎合、以䞋のような課題がありたした。 テストプロセスの課題 - 課題 - ⇒懞念ずしお起こり埗るこず テストケヌスの構成は、テスト蚭蚈者によっお属人化しがちであり、ケヌスの項目分類や圢匏も異なる ⇒蚭蚈担圓者が倉わった堎合に䜜業匕き継ぎが倧倉 ⇒フォヌマットが共通化されおいないため、プロゞェクトが倉わるずケヌスの解読に時間が掛かる ケヌスを確認するには、郜床ファむルを開いお䞭身を芋なければいけない ⇒チヌム内でのドキュメントやノりハりの共有が難しい 関係者QA以倖のステヌクホルダヌがテスト内容、結果を俯瞰しづらい ⇒QA偎で報告甚にレポヌトを敎える必芁がある リグレッション実斜の際、テストサむクルの床にファむルを新しくする必芁がある ⇒どのケヌスを再利甚したのかが把握しづらい テストケヌスの倉曎履歎や曎新経緯を远いにくい ⇒ケヌス内容の曎新等、メンテナンスの際に時間が掛かる加えおExcelはonlineでの耇数同時線集に向かない テストの実行結果が手入力のため、正確な実斜時間たでは分からない ⇒䞍具合発生時刻の特定がしにくい テストケヌスずバグレポヌトの玐付けが出来おいない ⇒機胜毎の䞍具合発生率などの集蚈ができないがんばれば手集蚈で出来なくもない。けどしんどい などなど。 これらの課題を解決する手段ずしお、テスト芁件管理、テストケヌス䜜成、テスト実行、テストレポヌト など、䞀連のテスト掻動を支揎するツヌルの導入を怜蚎したした。 ずいうか、はなからExcelやSpreadsheetを䜿うこずは考えおいたせんでした。 なぜなら䞀床Excel運甚が浞透しおしたうず、そこから脱华するのに時間が掛かるのも経隓則で分かっおいたからです。 導入するツヌルの怜蚎 圓初、候補に挙げおいたのは以䞋 TestLink オヌプン゜ヌスのWebベヌステスト管理ツヌル。無償。 TestRail Webベヌスのテスト管理ツヌル。有償。 Zephyr for JIRA JIRAのプラグむン。有償。 2021幎にZephyr Squadずいう名称に替わっおいたした[^1] [^1]: Zephyr for Jira is now Zephyr Squad , SmartBear Software., 2021 TestLinkは、元々自分がこれたで過去の職堎でも䜿っおいた実瞟があった、ずいうのが理由のひず぀。 ロヌカル環境でもDocker立おおむンストヌルすればずりあえずすぐ詊せる、ずいう利点もありたす。 実際、怜蚌甚のMac1台をTestLink兌甚にしおいたこずもありたした。 ですが、私がKINTOテクノロゞヌズに入瀟したのが2020幎3月圓時は株匏䌚瀟KINTO圚籍、ツヌル導入のタヌゲットずなるプロゞェクトのリリヌス予定は2か月埌の5月、ずいうスケゞュヌル。しかも新型コロナりむルスの感染拡倧による最初の緊急事態宣蚀が、その間の4月に発什される。 ずいうなかなかしびれる状況の䞭、その時最も適した遞択肢ずしお採甚したツヌルはどれでしょうか 実は、 Zephyr for JIRA なのでした。 すでに瀟内で䜿われおいたJIRAのアドオンですぐ導入できた、たた、コロナ犍で予期せず発生したリモヌトワヌク=瀟倖からの利甚を考慮しおも䟿利、ずいうのが倧きかったです。 有償ずはいえ、5月のリリヌスさえ乗り切ればそのあずの利甚継続に぀いおは再怜蚎する、ずいう考えの元、運甚を開始したした。 圓時のメモ芋るず JIRAプラグむンだから蚀語蚭定倉えればいけるかず思ったら日本語は䞀郚のみ察応っぜい や、 Zephyrのレポヌトはシナリオ単䜍であっお、ケヌスステップ数単䜍でのレポヌト機胜無いんやなやっぱり など ^2 、 詊行錯誀しおいた圢跡が残っおいたしたね。懐かしい。 すぐ導入できたずいい぀぀も、䜿う偎の慣れやスキルも必芁䞍可欠ではありたす。そういう意味でも、圓時の混沌ずした時期を柔軟に乗り切っおくれたメンバヌには今でも感謝しかありたせん。 Zephyrを䜿っおみお もう3幎近く(!)昔の話にはなりたすが、Zephyr for JIRAを䜿っおみた感想ずしおは。 JIRAのプラグむンなので、テストケヌスは任意の課題タむプを遞択する手順で通垞の課題ず同じ様に䜜れたす。 ケヌスの項目には、ステップず期埅倀、結果、ステヌタス、コメントの他にファむル添付があり、ステップごずに画面のキャプチャを蚌跡ずしお残せるのは䟿利だなず感じたした。 䞀方で、プラグむン自䜓の読み蟌みに結構な時間が掛かっおいたした。画面を遷移するたびに、数秒掛かるずいうのが悩みでした。こちらもAtlassianのコミュニティに同様の お悩み盞談 が投皿されおいたので、Zephyr固有の問題なのかもしれたせん。 そしおTestLinkぞ さおどうにか圓時のリリヌス予定スケゞュヌルを乗り切っお、2020幎5月にプロゞェクトが手を離れたあずのテスト管理に぀いおですが。 あらためお費甚面も螏たえお怜蚎したした。 JIRA連携が前提なのず、ツヌルの利甚者数は10~20人皋床、ずした堎合に 2020幎圓時の䟡栌は以䞋で、 Zephyr for JIRA11-100 Users ï¿¥510/user/month ⇒20人利甚で¥10,200/月 TestRail1-20 Users $32/user/month ⇒20人利甚で$640玄¥83,200/月 2023幎珟圚の䟡栌は以䞋です。 Zephyr Squad11-100 ï¿¥570/user/month ⇒20人利甚で¥11,400/月 TestRail1-20 Users $37/user/month ⇒20人利甚で$740玄¥96,200/月 圓時ずは料金䜓系が若干倉わっおいたのず、やはり倚少倀䞊がりしおたすね。 ※いずれも1ドル130円ずしお換算 ぱっず芋、Zephyrはお埗にみえたすが、JIRAのプラグむンずいうこずもあり、実はJIRAの既存ナヌザヌラむセンス数ず同数分が必芁になりたす。 そこに関しおは瀟内でも開発郚眲党員が䜿うわけではなく、QAメンバヌのみの利甚ず考えるず、組織拡倧に䌎っお費甚がかさんでいくのは避けたい。 にしおもTestRailはお高いですね。コストを考えるず、フリヌのTestLinkに勝る遞択肢が芋圓たりたせん。 TestLinkに関しおはUIがむマむチずいうのはありたすがオヌプン゜ヌスだから莅沢蚀わない、テスト管理ツヌルずしお、少なくずも先述の課題はそれぞれ以䞋のように解消できたす。 テストプロセスの課題ずその解決策 テストプロセスの課題 ツヌルを導入した堎合 懞念に察しお 1. テストケヌスの構成は、テスト蚭蚈者によっお属人化しがちであり、ケヌスの項目分類や圢匏も異なる テストスむヌトやテストケヌス、テストステップ等を、䞀定のフォヌマットか぀適切な现かさで蚘茉するこずで、ある皋床粒床が揃う 匕き継ぎもケヌスの解読も楜 2. ケヌスを確認するには、郜床ファむルを開いお䞭身を芋なければいけない 実斜項目の芖認性が高く、テスト芁件ずのトレヌスもずりやすいため、カバレッゞがわかる チヌム内倖でのドキュメント共有が楜 3. 関係者がテスト内容、結果を俯瞰しづらい テストの進捗状況をリアルタむムで把握できるのず、結果をレポヌトで䞀芋できる QA偎でレポヌト䜜成する必芁なし 4. リグレッション実斜の際、テストサむクルの床にファむルを新しくする必芁がある テストスむヌト単䜍での再利甚が可胜 再利甚の察象が぀かみやすい 5. テストケヌスの倉曎履歎や曎新経緯を蚘録に残しづらい テストケヌスの远加・倉曎に加えお、その履歎が残せる ケヌスのメンテナンスが楜 6. テストの実行結果が手入力のため、正確な実斜時間たでは分からない バグレポヌト、実行時間、実行者の蚘録も正確にロギングされる 実斜時間垯を絞り蟌める 7. テストケヌスずバグレポヌトの玐付けが出来おいない テスト進捗率や䞍具合発生率など、芁件/リリヌス毎のトラッキングがしやすくなる 機胜毎の䞍具合発生率等、集蚈がしやすい ずいうわけで、2020幎6月以降はTestLinkを導入するこずにしたした。 たあ、楜ず曞いおしたうずメンバヌからは怒られそうですが、実際のずころツヌルも䞇胜ではないので、Excel等のデヌタファむルを䜿うよりかはだいぶ楜ですよ、ずいう感じでしょうか。 远蚘 フリヌずいっおも、運甚に䌎うむンフラコストは掛かりたす。TestLink甚にAWSのむンスタンスを䜿わせおもらっおいるのですが、幎間数䞇くらいの費甚感です。なお利甚開始から3幎近く経ちたすが、これずいった倧きな問題もなく今のずころ運甚出来おいたす。 今回は、QAグルヌプにおけるテスト管理ツヌルずしお、TestLinkの導入たでをお䌝えしたした。 実際のプロゞェクトでのTestLinkの利甚䟋、JIRAずの連携等に぀いおは、次回以降でたた機䌚があればお話できればず思いたす。
こんにちは、たたはこんばんわ。 矎味しい玅茶を飲みながら機械の分解をするのず写真を撮るのが倧奜きなグロヌバル開発 UIUXチヌムのazがお送りしたす。 UIガむドラむンずは そもそもUIガむドラむンずは䜕でしょうか どんな人が䜿うものでしょうか 誰がHappyになれるのか 少しず぀玐解いおいきたいず思いたす。 ブランドガむドラむンずUIガむドラむンの違い 䞀般的なブランドガむドラむンずUIガむドラむンの違いに぀いお説明したす。 KINTOにも䞀般には公開しおいたせんが、ブランドガむドラむンは存圚しおいたす。 ブランドガむドラむンずは 䞻に「ブランディング」ずしお守るべき、以䞋のようなルヌルが提瀺されおいたす。 ブランドの思想、理念 ブランド名やラむティングの衚蚘ルヌル 利甚するカラヌやむメヌゞ 求めるべきナヌザヌ䜓隓 ※画像はむメヌゞです このルヌルをベヌスにデザむナヌ達が衚珟方法やデザむンを考えおいきたす。 参考 ブランドガむドラむンずは UIガむドラむンずは 䞀方UIガむドラむンはデザむンシステムなどを甚いお「これを䜿えばOK」ずいう具䜓的な事䟋を提䟛したす。 ボタンやテキストなどに䜿う色や圢 画面レむアりトの比率 アむコンやむメヌゞの䜿い方 基本的にデザむンも実装もそのたた䜿えばいい状態のパヌツやスペックが茉っおいたす。 芁件から実装するず䜕が起こる 䟋えば「KINTOらしい」ボタンを䜜るにはどんな条件があるでしょうか。 決たっおいる色を䜿っお 四角くお 読みやすいラベルがあっお ボタンだず分かるもの むメヌゞできたしたね。 出来䞊がったものがこちら。 どれも条件は合っおいたすが、思っおいたボタンず違っおる郚分が出おしたいたした。 1段目 4方の角䞞がない 2段目巊 ボタン内の䜙癜の瞊暪比がおかしい 3段目巊 他では䜿わない圱が入っおいる 同じ条件で同じものを䜜っおいるのになぜ现かい郚分で揃わないのでしょう 䜕が違っおいたのでしょうか それは 共通認識 です い぀ものメンバヌがい぀ものように制䜜できれば同じものができる可胜性が高いですが、実際にはメンバヌもチヌムも流動的です。 出来おから「あぁ 思っおたのず違う 」ずなるず䜜り盎しが発生するのは時間も気持ちもロスが倧きいです。 UIガむドラむンではメむンボタンは「角䞞:30px、䞊䞋䜙癜:10px、幅画面比1/12 」ずいった现かい数倀たで蚭定しおいるのでアりトプットにずれが生じなくなりたす。 UIガむドラむンの考え方・䜿い方 フォヌマットに則っおデザむンすれば、デザむナヌもフロント゚ンドもラクになりたす。 実際によくある䟋で説明しおいきたいず思いたす。 デザむナヌがいなくおもガむドラむンに沿えばOK 避けおは通れないテキストサむズやスタむルの蚭定も、䜿われるスタむル数が決たっおいるので现かい蚭蚈に悩む必芁が少なくなりたす。 サむズや䜙癜が適切に蚭定されおおらずクオリティの安定しないケヌスもよくありたすが、 ガむドラむンで蚭定された䜙癜に沿っおいればデザむナヌが調敎しなくおも、芋た目が厩れるこずなく画面が構成しやすいです。 画面サむズ問題が枛る デザむンファむルの立ち䞊げ時によく起こる「スクリヌンサむズ䜕pixelにするか」問題。 ガむドラむンで比率やブレむクポむントの蚭定しおいるのでそこで差異がでないようになっおいたす。 「い぀もの仕様」で䜜れるものが倚い 入力フォヌムの配眮 同じような内容や項目が倚い代衚䟋が入力フォヌムですが、項目远加や順番の倉曎も圧倒的に倚いです。 最近のプロゞェクトでも倉曎が䜕床もありたしたが、ガむドラむンを䜿ったデザむンだったためデザむンファむルの修正ず実装を䞊行で行うこずができたした。 メッセヌゞの出し方 結果画面や゚ラヌ画面のように文蚀や組み合わせが倚数ある堎合はずおも倚いです。 ステヌタス毎のアむコン、テキスト間のレむアりトが決たっおいるので、特殊な䟋をのぞけば党おのパタヌンを網矅しお準備する必芁がありたせんでした。 困る人が少なくなヌれ 経隓倀やスキルの差があっおも最䜎限同じアりトプットを出せるこず 口頭や文字での䌝達ロスを枛らし共通認識を保぀ この぀がガむドラむンの倧きな圹割です。 困ったらここ芋ればいい解決 ずなれるようにこれからも拡充しおいきたいず思いたす。
Hello! 👋 This is Ruoyang Wen from Global Group, KINTO Technologies . I work as a full-stack engineer in Global KINTO App team. You can read more about the Global group here. Objective As a startup company, there are a lot compromises within our first generation product. For the greater benefits, apart from the service we provide, workflow is also where we need to improve. This article shares why and how we changed our workflow from Git-flow to GitHub-flow. Attempt As part of the Toyota group companies, we implement the principle of improvement (or kaizen in Japanese) in our daily work. With customer feedback and analytical data, there are numerous amount of improvements that we can do to better serve our customers. Through automation, the process of kaizen can be sped up rapidly. Committing source code is a daily job for engineers, it’s not just about handing over our daily work but also testing the code in our server environment. We introduced Continuous Integration and Continuous Deployment (CI/CD) practice into the team to help us reduce repetitive work. CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. ^1 We were following Git-flow to manage our source code and development progress. Soon after CI/CD was implemented we found that our work process did not get any faster. Reasoning git flow diagram It was a mess to use or manage the CI/CD scripts. We have so many different branches, when merging branches from one category to another different scripts are needed: feature-to-develop , develop-to-release , release-to-main , hotfix-to-main , main-to-develop , develop-to-feature , etc
 Conflicts would show up everywhere! And they cannot be solved via automation scripts. The automation increased our daily workload, why?! After some research we found that: Git-flow, by definition, is a manual/time delayed integration workflow. OK, we need a new workflow then. Reattempt Among several workflows we found during previous research, we decided to give GitHub-flow a try as we store our source code on GitHub. github flow diagram This time we only have two type of branches: the main and the 'change-of-anything' , and we block any commits to main directly, the only way to update main is to do a Pull Request towards main . As a result, there is only one CI/CD script required and any conflicts can be discovered and resolved during Pull Request . New Issue We have simplified our branching strategy; we have only one script to do CI/CD; we have Pull Request to help managing conflicts. All happy? Yes, but no. Let’s check the pros. We have handed over the repetitive work to automation scripts, so everyone can do more productive work. The release and deploy process is handled by scripts, so any change we made locally can be deployed to server within 2 minutes. However, there are the cons. We lost feature/version control of our system. As features are no longer stored in individual branches but in main directly after Pull Request , we cannot decide for next version which features may be on-hold and which may be released. Also, the main branch just kept updating with latest source codes, version number can ramp up hundreds in a single day. Next Step Fortunately we are not alone. There are people who already faced these issues, and we can follow their journey and see their solutions. Feature toggle can be used to enable/disable any feature at any time. It can be stored in parameters, so no new release/deploy needed; even better than Git-flow which is to release different versions with different combinations of features. Version number only ramps once we deploy a specific commit to the production environment. For the rest of the environments, we use the commit hash as the version number. This helps us to locate any bug or defect to that commit instantly. Summary Undoubtedly there is no perfect solution to solve all problems. GitHub flow has its flaws as well, my team and I are still working together to kaizen not just our products but also the way we work. Personally, Git-flow is like a web portal: it categorizes everything with defined rules; if no one makes any mistake it will work just fine. On the other hand, GitHub-flow is like a search engine: we tag the version number to the commit we release/deploy to the production environment, with other environments having the commit hash as version numbers; so if there is any issue, those versions can be easily found through search. References トペタ生産方匏 What is CI/CD? What is Continuous Integration? Git flow for agile teams is a no no Please stop recommending Git Flow! Git Flow vs GitHub Flow GitHub flow - GitHub Docs Continuous Integration Contradicts Features Branches! How to Achieve Continuous Deployment with Feature Flags
抂芁 グロヌバル開発G業務゚ンハンスチヌムの森、把原、Floです。グロヌバル開発G䞻催のKINTO Global Innovation Daysの連茉蚘事本目ずなりたす。 前回の蚘事はこちら 👈 本蚘事では、12/14~12/19の4日間で行ったプレむベント3本ず、Innovation Days圓日の様子をお届けしたす。䞀連のスケゞュヌルは以䞋の日皋で行いたした。 Design Dash Workshop 組織が拡倧するに぀れ、メンバヌのタスクが现分化されるため、同じチヌム内であっおも圹割が異なるずどういった考えでタスクをこなしおいるのか芋えにくくなっおきたす。この課題を螏たえ、タヌゲットの抱える課題を解決するための゜リュヌションを怜蚎するワヌクショップを行いたした。 あるお題に基づいおむンタビュヌを行い、むンタビュむヌの悩みを解決するプロダクトを䌁画、提案、デモする圢匏です。 このワヌクショップの目的は以䞋の぀ Ideation Rapid Desision Making Discovery Practice Improve Communication 孊びを参加者自身に感じおもらいたかったので、あえお目的を蚀わなかったのですが、埌日行ったアンケヌトでは72%の参加者に満足いただき、「課題発芋力を埗られた」「限られた時間内でどのように゜リュヌションを芋぀け出すかを知った」「ナヌザヌセントリックな商品蚭蚈の仕方を孊べた」「チヌムワヌクがずおも重芁だず理解した」などの声をいただき、自然ず目的を達成するこずができたした。 Communication Workshop 各自のタスクが现分化されおくるず、プレれンやアりトプットの機䌚も枛っおきたす。参加者の䞭にも普段はほずんどそういった機䌚が無いメンバヌもいたした。「機䌚」を䞎えるこずは本むベントの最終ピッチで実珟できたしたが、その事前準備ずしお「盞手が求めおいるものを把握する力」が必芁だず考えたした。盞手の立堎によっお求めおいるものは異なり、それを把握できないず的倖れなアりトプットをしかねないからです。事前準備ずしお、ステヌクホルダヌの立堎ず状況をしっかりず把握し、䜕を求めおいるのか、盞手は今䜕を欲しおいるのかを把握できるようなコミュニケヌションのワヌクショップを蚭けたした。 コピヌラむタヌ、デザむナヌ、開発者、ダむレクタヌ、セヌルスずいう別のロヌルに分かれ、プロゞェクトの各自の悩みを螏たえお共有し、それぞれのTO DOに萜ずし蟌んでいくずいうような圢匏でした。 こちらも56%の満足床を埗られ、「必芁な情報を盞互ぞシェアする重芁さ」「それぞれ違うずころにフォヌカスがある人たちの意芋を集玄し、どのようにDeliverableずしお出すか孊んだ」「異なるロヌルの芖点を芋るこずができた」のような声をいただきたした。 Toyota Way Workshop Innovation DaysをKINTOテクノロゞヌズで行うベネフィットずしお、トペタグルヌプならではの孊びを埗たいずいう理由から、アゞャむルの由来でもあるトペタ生産方匏を孊べる機䌚を蚭けたした。 具䜓的な方法に぀いおは割愛したすが、トペタりェむやトペタ生産方匏に぀いおトペタ自動車史や創業者の粟神に沿っお孊べるセッションを蚭けたした。ただ䞀方的なむンプットではもったいないので、各自感じたこずをチヌムで共有しあい、翌日からのInnovation Daysで倧切にしたいマむンドを宣誓しおいただきたした。 これも72%ず非垞に高い満足床を埗るこずができ、「トペタりェむが蚀葉ずしおだけでなく歎史を通じお理解できた」ずいう声がありたした。 Innovation Days 前日たでのワヌクショップで孊んだこずを螏たえ、いよいよInnovation Daysの圓日です。 圓日のスケゞュヌル🔻🔻 Opening Ceremony 事前収録した瀟長からのメッセヌゞや现かいルヌル説明、アむスブレヌクを行いたした。 Code of Conduct ルヌルはいろいろな事䟋を参考にしながら以䞋を芏定。Code of conductを遵守するこずを匷調したした ✹ 発衚コンテンツ プレれン時間の芏定pitch 5分 + Q&A 2分 開発に䜿甚しお良いツヌル Deliverables提出方法 評䟡方法・ポむント 運営チヌムからのアドバむス ![code-of-conduct](/assets/blog/authors/M.Mori/20230314/code-of-conduct.png =450x) Icebreaker IcebreakにはTelestration = お絵描き䌝蚀ゲヌムを䜿いたした。けっこう難しかった様子。 Ideathon もずもず怜蚎いただいおいたアむデアの皮を育おおもらうずころから始めたした。自分たちのアむデアに察しおValue Proposition Canvasを甚いおタヌゲットず課題、そこに察する゜リュヌションが提䟛する䟡倀を怜蚎しおもらいたした。 普段、グロヌバル開発Gではこういった怜蚎はPdMが担圓しおいたすが、゚ンゞニアも含めおチヌムで怜蚎できる、滅倚にない機䌚ずなりたした。 Hack Start!!! さお、実際の開発スタヌトです。各チヌム、オフィス内の郚屋にわかれおそれぞれの開発をスタヌトしおいただきたした。様々なメンバヌがいるのでコヌドを曞くだけでなく、翌日のPitchに向けた準備や、デザむンなどを担圓するメンバヌもいたす。 2日間の内、実際の開発時間は7.5時間皋床でした。限られた時間の䞭で、どこに優先床を眮いおどこたで開発し、たた、Final Pitchではどのようなポむントを蚎えるかを怜蚎しおもらいたした。 2日間のInnovation Daysではランチセッションもありたした。Day#1はチヌムでランチに行っおもらうこずで、アむデアを深めたした。Day#2はチヌムの1人が別のチヌムに亀じっおランチをするこずでアむデアや開発内容に察するフィヌドバックをしおもらいたした。亀流の目的もありたすが、雑談の䞭で生たれるアむデアはInnovation Daysのみではなく、実業務に察しおも良いものが生たれたようです。 Final Pitch!!! Day#2の倕方、党員で集たっおPitchをしおもらいたした。持ち時間は各チヌム5分QA2分です。 それぞれ詳しいアむデアは割愛したすが、既存プロダクトの改善提案や新しい機胜の提案、新サヌビスの提案など、各チヌムナニヌクなPitchずDemoを行っおくれたした。 尚、公平を期すために発衚順はその堎でくじ匕きにしたした。自分の番がい぀来るかわからないのでドキドキです Judgement 党おのPitchが終了しおから、グルヌプマネヌゞャヌずアシスタントマネヌゞャヌ4名による評䟡の時間です。うち2名はリモヌト参加だったので、4人で集䞭しおJudgeされおいた姿が印象的でした。 Judgementの評䟡軞は以䞋 🔻🔻 評䟡軞 / Evaluation axis 割合 / Ratio オリゞナリティ / Originality 10% UIUX 10% 技術力 / Tech Skill 30% チヌムワヌク / Team Work 20% 実甚性、事業性 / Practicality, Feasibility 20% ワクワク感 10% 評䟡の結果、優勝したチヌムにはオリゞナルスマホスタンドずケヌキの賞品を莈呈したした。優勝したチヌム以倖も楜しそうに参加いただいたのが印象的で、䌚堎内はずおもいい雰囲気でした。 ※撮圱のタむミングだけマスクを倖したした。 たずめ KINTOテクノロゞヌズ初のむベントずしおグロヌバル開発Gが䌁画したむベントでしたが、もずもず目的ずしおいた「コミュニケヌション掻性化」はもちろん、KINTOに察する新しいアむデアや普段の業務では䜿うこずのできなかった新しい技術の利甚など、様々な結果を出すこずができたした。 参加者はもちろん、マネヌゞャヌや圹員など、党おのステヌクホルダヌにずっお奜評なむベントずなりたした。我々は運営偎でしたが、ハプニングぞの察応、ファシリテヌション、タむムマネゞメントや倚方面の調敎力など、運営チヌムずしおも様々なスキルを埗られたした。そしお䜕より、チヌム内の絆が深たりたした ✹ さお、ここたで運営チヌム目線で䌁画段階の様子ず圓日の様子を蚘事にしおきたしたが、参加者目線ずいうこずで優勝チヌムのむンタビュヌ蚘事を掲茉予定です。乞うご期埅
抂芁 グロヌバル開発G業務゚ンハンスチヌムの森、把原、Floです。グロヌバル開発Gでは12/14 21の6日間にわたり、「KINTO Global Innovation Days」ず称した瀟内Hackathonのようなむベントを開催したした。12/14 19たでの4日間でセミナヌを3本ず、実際の開発は2日間の構成です。このようなむベントを開催するのはKINTOテクノロゞヌズ内でも初めおのこずでした。本蚘事では本むベントに関する連茉蚘事の本目ずしお開催に至るたでの様子をお䌝えしたす。 きっかけ KINTOテクノロゞヌズは珟圚玄300名で構成され、2幎ほどでおよそ倍の人数になりたした。その䞭で、グロヌバル開発Gも珟圚60名の倧所垯です。組織ずしおは5~10名皋床のチヌムに现分化され、それぞれタスクをこなしおいたすが、チヌムを暪断したコミュニケヌションは垞に課題でした。同じグロヌバル開発G内でも顔ず名前が䞀臎しないこずもしばしば 。たた、コミュニケヌションずスキル向䞊のために内郚で勉匷䌚を䌁画・運営しおいたものの、どうしおも䞀方的な知識共有になっおしたっおいたした。 ゚ンゞニア自身が手を動かしお孊べる機䌚を暡玢しおいたしたが、7月にグルヌプ内の数名が Toyota Motor North America (TMNA) のHackathon に参加したこずもあり、これを我々グルヌプ内で開催するこずで、䞊蚘の課題解決に繋がるのではず考えお、8月末から蚈画をはじめ、提案に移すこずにしたした。 目的ず開催時期 䞀般的にHackathonむベントから埗られるベネフィットは様々ですが、今回我々は「コミュニケヌション掻性化」を第䞀目的ずしたした。ビゞネスに寄りすぎないこずである皋床自由な発想が埗られたず思いたす。 たた、開催時期に぀いおは遅くずも2022幎内開催を目暙ずしたした。グルヌプ暪断で携わっおいた倧きなプロゞェクトが11月に目途が着きそうなこず、4Qたで差し掛かるず先のタスクが読めないこずが理由です。 調査ずコンテンツ怜蚎 初めおのむベント開催だったため、実際のむベントがどうあるべきか怜蚎すべくたずは䞖界䞭のHackathon事䟋を調べたした。調査担圓は把原です。 他瀟のテックブログやHackathonのむベントサむトを䞭心ずしお様々なお手本を調べおいるうちに、パタヌンが芋えおきたした。そのパタヌンの芁玠をピックアップし、最も我々の組織や目的に則したポむントを組み合わせるこずによっおInnovation Daysの内容を組み立おる事ができたした。調査結果の䟋はたくさん取り䞊げるこずができるのですが、その䞭から3点解説したす。 調査結果ベネフィット むベントの準備を進めるに぀れお、参加者や関係者、ステヌクホルダヌに察しお、参加するこずによっおどういった効果が芋られるかを䌝える必芁性を感じたした。䟋えば、組織ぞのベネフィットは知的財産暩になるアむデアを埗る機䌚であるこずや、メンバヌの゚ンゲヌゞメントを高め、新たな匷みの発掘ができる機䌚であるこずを挙げられたす。たた、個人ぞのベネフィットは、普段の業務では取り組めないアむデアを考えたり、あたり関わるこずのない業務工皋やメンバヌず接するこずによっお、いろんな面での孊びずなるこずを蚎えかけたした。 調査結果2コンテンツのアむデア 䞊蚘のベネフィットを螏たえ、コンテンツずしお取り入れたのがセミナヌです。Hackathonのようなむベントが開催される際には、ゲストを招いおトヌクを行ったり、Hackathonのテヌマや目的に沿った講矩やワヌクショップが開催されるこずがあるこずを知り、今回Innovation Daysでは普段経隓しない䞊流工皋のworkshop、コミュニケヌションworkshop、そしお「KINTOテクノロゞヌズが開催するHackathon」なので、トペタりェむのworkshopを準備したした。 IT䌁業が開催するむベントずいえばノベルティヌずいう方も少くはないかず思いたす。今回我々はステッカヌ、パヌカヌずクリアファむルを参加者ずサポヌトメンバヌぞお枡ししたした。他にも、最終ピッチや成果物の刀定基準やルヌルの蚭定、コヌドに付䞎する時間、アむスブレむクやプラむズ等も様々なむベントからアむデアを拝借したした。 ※むベントの名称が決たっおからグロヌバルG内のUIUXチヌムにロゎも䜜成いただきたした。おかげで玠敵なノベルティヌができたした。Appreciate it a lot!!!! 調査結果3テヌマ蚭定 最埌に取り䞊げたいポむントが「テヌマの蚭定」です。倚くのHackathonでは開催偎からテヌマや目的が絞っお掲げおあり、各皮テヌマをスポンサヌする存圚もいる堎合もあるこずからヒントをもらい、我々のむベントではマネヌゞャヌが「チャレンゞテヌマ」を1぀決め、各テヌマのスポンサヌずしお「チャレンゞオヌナヌ」ずなっお参加者にテヌマの説明を実斜したした。こういったテヌマの蚭定によっおマネヌゞャヌから参加者ぞのサポヌトも瀺すこずができ、゚ヌルも送るこずができたした。 参考 Council Post: Four Tips For Running A Successful Hackathon Urban Mobility Hackathon Find & Organize Hackathons Worldwide - Mobile, Web & IoT Hackathon Guide テヌマの怜蚎 テヌマの内容に぀いおは、実際に圓日評䟡をするマネヌゞャヌ名グルヌプマネヌゞャヌ+アシスタントマネヌゞャヌ名にテヌマを遞定いただきたした。 テヌマ 1-2 テヌマ 3-4 Encouraging members 瀟内で初めおの詊みずいうこずもあり、䌁画を始めおから調査、コンテンツ怜蚎、テヌマの遞定を経おメンバヌ募集するたでに3ヶ月ほどかかりたした。最終的にテヌマが決定した11月頭にグロヌバル開発G党員を集めた䌁画説明を行い、11月8日にメンバヌ募集を実斜したした。この際、公匏むベント名を「KINTO Global Innovation Days」ず題したした。 尚、参加者に぀いおは党員匷制で参加させる案もありたしたが、自䞻性を尊重するために参加したい人に挙手する圢匏ずしたした。実際に募集したSlack 🔻🔻 説明䌚でマネヌゞャヌからも゚ヌルの蚀葉をいただいたり、CEOやCIOのサポヌトもいただいおいる旚を䌝えたりしたしたが、圓初はなかなか参加者が集たりたせんでした。 そこで、ベネフィットなどをメンバヌに盎接蚎えかけるようにしたした。担圓はFloです。オフィスで盎接䌚話する際やDMなどでベネフィットを䌝えるこずにしたした。それによっお、参加できないメンバヌにその理由を聞いお改善できるからです。 たず、本むベントに参加するこずで、どのような䜓隓ができおどのようなスキルが埗られるか䌝えたした。普段䜿えないプログラミング蚀語を詊せる、新しいツヌルを提案できる、優先床が䜎かった改善案を提案できる、など様々な䜓隓が埗られるず蚎えたした。 たた、むベント内での提案はグロヌバルGでのプロセス改善に掻甚されたりテヌマ 3、新サヌビスずしお補品化されたりテヌマ 1, 2、もしくは他のHackathonむベントぞの参加も怜蚎され埗るなど、圓事者意識ず投資意識にも蚎えかけたした。 䞭でも、我々が䞀番に心がけたのはサポヌト環境です。アむデアは評䟡されお衚地されたすが、あくたで切磋琢磚するむベントなので、こういったむベントに参加したこずがない、技術者ではないから貢献できない、自分は圹に立たない、ず思っおいる方にも、「普段䜓隓しないこずを経隓できるむベントだからこそ参加しおほしい」ず説明したした。 䌚話の䞭で気づいたこずもありたす。開催日皋がクリスマス前だったため、連䌑を予定したり母囜ぞ垰省したりする方が耇数名いたした。そのため、むベントを数日前倒しするこずにしたした。各workshopの講垫ずスケゞュヌルを調敎し、最終的に12/14-19をプレむベント、12/20-21をInnovation Daysずしたした。これによっお参加できるメンバヌが少なくずも2-3名増えたした。 䜙談ですが、運営メンバヌはたったの3名サポヌト1名だったため、土日を挟んだのは我々にずっおは奜郜合でした。1週間ぶっ通しでのむベント開催だったら䜓力的に厳しかったず思いたす。 グルヌピングず事前ワヌク リクルヌトの甲斐もあっお、実際の参加者は30名ずなりたした。グルヌプマネヌゞャヌやアシスタントマネヌゞャヌ、我々運営メンバヌは参加察象倖なのでグロヌバル開発グルヌプの半数以䞊が参加しおくれたした。 Business development, PdM, UIUX, Frontend, Backend, Testing, DevOpsなど様々なチヌムから参加者が集たったので、それぞれを①できるだけ普段業務䞊関わらない人②パワヌバランスを取るためにチヌムリヌダヌは分けるこずを条件ずしお配分したした。5名×6チヌムです。30名ずいうキリの良い人数だったのでちょうどいい感じのメンバヌ数に分けられたした 😊  チヌムメンバヌは11/18に発衚、その埌2週間で以䞋を怜蚎・提出しおもらいたした。 Team name Theme of choice Team leader 普段、グルヌプ内で最もいろんな人ず関わる我々チヌムずしおは、参加メンバヌがうたくコミュニケヌションを取れるか積極的にむベントに参画しおくれるかなど芪心的に心配しおおりたしたが、その心配は無甚でした。参加者は自䞻的に参加しおくれおいるこずもあり、それぞれのチヌムがSlackの独自チャネルを䜜ったり、ミヌティングを開催したり、思った以䞊に積極的に動いおくれたので、今埌のむベントにも期埅が持おたした 🎉 事前準備の振り返り 瀟内はもちろん、前職での経隓も完党に䜕もないずころからスタヌトした䌁画だったので、いろいろな調査や様々な方からのアドバむスを受けながら準備を進めおきたした。特に承認プロセスは時間がかかりたしたが、CIOや瀟長たで巻き蟌めたこずは成果の䞀぀であり、今埌のむベントにも繋がる倧きな芁玠だったかず思いたす。 たた、アむデア出し(調査含む)、䌁画䞊䜍局ぞの報告、状況把握ずメンバヌの錓舞、ず業務゚ンハンスチヌムメンバヌそれぞれが埗意なこずを組み合わせおうたくタスクを分散できたこずで、構想から玄4ヵ月の短期間で実行に移せた芁因です。 プレむベント期間や圓日も様々な課題がありたしたが、その様子は次回の蚘事に蚘茉いたしたす。 最埌に 䜙談ですが、KUDOSや本むベントなどの䌁画は業務゚ンハンスチヌム内の日垞䌚話から生たれおいたす。我々チヌムは䌚話をずおも倧事にしおいたすが、「 この課題を解決するにはこういう手があるかも 」「 こういうのあったらいいよね 」「 前職ではこういうこずしおいた 」などのカゞュアルな䌚話から䌁画・実行・結果に残すこずたでできる力を持った業務゚ンハンスチヌムを誇りに思いたす。
はじめに みなさたはじめたしお。KINTOテクノロゞヌズのIT管理チヌムでコヌポレヌト゚ンゞニアをしおおりたすT.S.ず申したす。 こちらに IT管理チヌムの玹介蚘事 がございたすので合わせおご芧ください。 私たちIT管理チヌムは日々KINTOテクノロゞヌズずいう゚ンゞニア組織の生産性を高められる瀟内IT環境を目指しお奮闘しおおりたす。 瀟内IT環境は様々な芁玠で構成されおいお䞀床に党おをご玹介するのは難しいので、本蚘事ではデバむス管理に぀いおご玹介できればず思いたす。 デバむス管理っお 前提 KINTOテクノロゞヌズでは党スタッフに1台ず぀ ノヌトPC(Windows or Mac) スマヌトフォン を貞䞎しおおりたす。そのため瀟内の誰がどのデバむスを利甚しおおり、デバむスの状態はどうかずいった把握・管理ができるこずで「快適な開発環境を支える」を実珟しやすくなる蚳です。 MDMずは 前提の通り、党スタッフがモバむルデバむスをご利甚されるずいうこずで、「Mobile Device Managementモバむル・デバむス・マネゞメント」ツヌルを導入しおおりたす。 そうです。䞀般的にMDMツヌルなどず呌ばれおいるものです。 MDMで䜕ができるの そもそもMDMずはノヌトパ゜コンやスマヌトフォン、タブレット端末ずいったモバむル端末に察しおデバむスの蚭定を実斜したり、アプリケヌション配垃を行ったりずいった管理・運甚を行うツヌルです。 それだけならそこたで頑匵っお管理する必芁があるのず思われる方も倚いず思いたすが・・・ KINTOテクノロゞヌズにオンプレはありたせん よっお日々業務に利甚するSaaS(※)から芋お信頌できるデバむス(≒管理されたデバむス)であるかどうかはセキュリティ的に重芁事項です。しかしセキュリティがガチガチなだけでなく開発環境ずしお利䟿性を萜ずさないためには、デバむスの䜕を管理しどこをお任せするか、きちんず考え運甚する必芁がありたす。 ※SaaS = 「Software as a Service」 クラむアントに導入むンタヌネットなどネットワヌク経由で利甚するサヌビス デバむス管理ずしおここは管理したい、利甚者にお任せし端末利甚の利䟿性を䞋げない区分けはこんなむメヌゞでした 管理できた方が良さそう お任せできるず玠敵 ・セキュリティ関連ツヌルの動䜜 ・デヌタ挏えい措眮 ・玛倱時等のデヌタ消去手段 ・䞍正な接続先ぞの通信 ・資産管理 ・業務に必芁なアプリケヌション ・利甚者ごずの環境蚭定 ・キヌボヌド、マりス等の呚蟺機噚 ・物理的な端末の保管、管理 KINTOテクノロゞヌズのデバむス管理 抂芁 結論ずしおKINTOテクノロゞヌズのMDMはこのような構成です。 項目 利甚サヌビス IdP(※) Azure Active Directory Windowsデバむス スマヌトフォン Microsoft Intune Macデバむス Jamf Pro ※IdP = 「Identity Provider」認蚌サヌビスの提䟛、アカりント情報管理を行う仕組み 課題 KINTOテクノロゞヌズは急成長フェヌズずいうこずで毎月倚くのスタッフが入瀟されおおり、スタッフの数だけデバむスは増加しさすがに人力で管理運甚し続けるの厳しい状況になりたす。 そこで以䞋の課題解決をするため、デバむス管理のシステム化に至りたした。 デバむスキッティング工数 デバむス情報の管理 むンストヌルするアプリケヌションの管理 OSアップデヌトサむクルの制埡 暗号化の適甚、回埩キヌの管理 リモヌトロック、リモヌトワむプ 導入 改めお業務環境を考えるず・・・ 業務環境 PC -> WindowsずMacが遞択可胜 スマヌトフォン -> 党員支絊 環境 -> フルクラりド グルヌプりェア -> Microsoft 365 ずいう前提から、WindowsデバむスずスマヌトフォンはMicrosoft 365ず芪和性の高いAzure Active Directory + Microsoft Intuneです。 MacもMicrosoft Intuneで管理し、MDMプラットフォヌム統䞀ずいう手段もありたすが、こずApple補品運甚においおは圧倒的な実瞟もあり、蚭定の同期が早く管理ポリシヌ・項目の柔軟性からJamf Proで管理するこずずしたした。 構成はこのようなむメヌゞです デバむス管理の抂芁 結果 No. 項目 結果 1 デバむスキッティング工数 →蚭定呚りを含めキッティング時の工数は䞋がった △ 2 デバむス情報の管理 →さらば台垳、管理コン゜ヌルようこそ ○ 3 むンストヌルするアプリケヌションの管理 →個別管理が䞀元管理に △ 4 OSアップデヌトサむクルの制埡 →デバむス利甚者任せから䞀元管理に ○ 5 暗号化の適甚、回埩キヌの管理 →1台1台の䜜業からシステム管理に、特にキヌ管理のシステム化は嬉しいポむント ○ 6 リモヌトロック、リモヌトワむプ →察応可胜に ○ 以䞊の結果から圓初の課題に察しおは抂ねクリアでき、ようやくデバむス管理のスタヌトラむンに立おた状態ではないでしょうか。 スタッフの皆様により良い䜓隓をお届けするため、デバむス管理運甚の改善を進めおいきたいず思いたす。 今埌やっおいきたいこず 1. れロタッチキッティングの実珟 キッティング芁件等を敎理しれロタッチを実珟し、デバむスにかかるオンボヌディングの時間を削枛し、業務に向けたオンボヌディングの時間にできればず思いたす。 2. アプリケヌション運甚の効率化 䞀元管理は実珟できたものの、必芁になった際より柔軟にタむムリヌにお応えできるようここの運甚をより掗緎させおいきたいず思いたす。 3. デバむス状態の管理運甚 MDMに登録された管理察象デバむスずしおだけでなく、むンベントリ等のデバむス状態に応じた现かい制埡・運甚を実珟しデバむスの状態をより良い状態に保おるようにしおいきたいず考えおおりたす。 最埌に ここたで読んでいただきありがずうございたした。これからも党瀟に貢献し事業に貢献できる瀟内IT環境を目指し業務に粟励しおいきたいず思いたす。 We are hiring! KINTOテクノロゞヌズでは䞀緒にモビリティの未来を創る仲間を募集しおいたす。カゞュアル面談なども行っおおりたすのでご興味をお持ち頂けたしたらぜひお気軜にご連絡ください。 https://www.kinto-technologies.com/recruit/
はじめに みなさたはじめたしお。KINTOテクノロゞヌズのIT管理チヌムでコヌポレヌト゚ンゞニアをしおおりたすT.S.ず申したす。 こちらに IT管理チヌムの玹介蚘事 がございたすので合わせおご芧ください。 私たちIT管理チヌムは日々KINTOテクノロゞヌズずいう゚ンゞニア組織の生産性を高められる瀟内IT環境を目指しお奮闘しおおりたす。 瀟内IT環境は様々な芁玠で構成されおいお䞀床に党おをご玹介するのは難しいので、本蚘事ではデバむス管理に぀いおご玹介できればず思いたす。 デバむス管理っお 前提 KINTOテクノロゞヌズでは党スタッフに1台ず぀ ノヌトPC(Windows or Mac) スマヌトフォン を貞䞎しおおりたす。そのため瀟内の誰がどのデバむスを利甚しおおり、デバむスの状態はどうかずいった把握・管理ができるこずで「快適な開発環境を支える」を実珟しやすくなる蚳です。 MDMずは 前提の通り、党スタッフがモバむルデバむスをご利甚されるずいうこずで、「Mobile Device Managementモバむル・デバむス・マネゞメント」ツヌルを導入しおおりたす。 そうです。䞀般的にMDMツヌルなどず呌ばれおいるものです。 MDMで䜕ができるの そもそもMDMずはノヌトパ゜コンやスマヌトフォン、タブレット端末ずいったモバむル端末に察しおデバむスの蚭定を実斜したり、アプリケヌション配垃を行ったりずいった管理・運甚を行うツヌルです。 それだけならそこたで頑匵っお管理する必芁があるのず思われる方も倚いず思いたすが・・・ KINTOテクノロゞヌズにオンプレはありたせん よっお日々業務に利甚するSaaS(※)から芋お信頌できるデバむス(≒管理されたデバむス)であるかどうかはセキュリティ的に重芁事項です。しかしセキュリティがガチガチなだけでなく開発環境ずしお利䟿性を萜ずさないためには、デバむスの䜕を管理しどこをお任せするか、きちんず考え運甚する必芁がありたす。 ※SaaS = 「Software as a Service」 クラむアントに導入むンタヌネットなどネットワヌク経由で利甚するサヌビス デバむス管理ずしおここは管理したい、利甚者にお任せし端末利甚の利䟿性を䞋げない区分けはこんなむメヌゞでした 管理できた方が良さそう お任せできるず玠敵 ・セキュリティ関連ツヌルの動䜜 ・デヌタ挏えい措眮 ・玛倱時等のデヌタ消去手段 ・䞍正な接続先ぞの通信 ・資産管理 ・業務に必芁なアプリケヌション ・利甚者ごずの環境蚭定 ・キヌボヌド、マりス等の呚蟺機噚 ・物理的な端末の保管、管理 KINTOテクノロゞヌズのデバむス管理 抂芁 結論ずしおKINTOテクノロゞヌズのMDMはこのような構成です。 項目 利甚サヌビス IdP(※) Azure Active Directory Windowsデバむス スマヌトフォン Microsoft Intune Macデバむス Jamf Pro ※IdP = 「Identity Provider」認蚌サヌビスの提䟛、アカりント情報管理を行う仕組み 課題 KINTOテクノロゞヌズは急成長フェヌズずいうこずで毎月倚くのスタッフが入瀟されおおり、スタッフの数だけデバむスは増加しさすがに人力で管理運甚し続けるの厳しい状況になりたす。 そこで以䞋の課題解決をするため、デバむス管理のシステム化に至りたした。 デバむスキッティング工数 デバむス情報の管理 むンストヌルするアプリケヌションの管理 OSアップデヌトサむクルの制埡 暗号化の適甚、回埩キヌの管理 リモヌトロック、リモヌトワむプ 導入 改めお業務環境を考えるず・・・ 業務環境 PC -> WindowsずMacが遞択可胜 スマヌトフォン -> 党員支絊 環境 -> フルクラりド グルヌプりェア -> Microsoft 365 ずいう前提から、WindowsデバむスずスマヌトフォンはMicrosoft 365ず芪和性の高いAzure Active Directory + Microsoft Intuneです。 MacもMicrosoft Intuneで管理し、MDMプラットフォヌム統䞀ずいう手段もありたすが、こずApple補品運甚においおは圧倒的な実瞟もあり、蚭定の同期が早く管理ポリシヌ・項目の柔軟性からJamf Proで管理するこずずしたした。 構成はこのようなむメヌゞです デバむス管理の抂芁 結果 No. 項目 結果 1 デバむスキッティング工数 →蚭定呚りを含めキッティング時の工数は䞋がった △ 2 デバむス情報の管理 →さらば台垳、管理コン゜ヌルようこそ ○ 3 むンストヌルするアプリケヌションの管理 →個別管理が䞀元管理に △ 4 OSアップデヌトサむクルの制埡 →デバむス利甚者任せから䞀元管理に ○ 5 暗号化の適甚、回埩キヌの管理 →1台1台の䜜業からシステム管理に、特にキヌ管理のシステム化は嬉しいポむント ○ 6 リモヌトロック、リモヌトワむプ →察応可胜に ○ 以䞊の結果から圓初の課題に察しおは抂ねクリアでき、ようやくデバむス管理のスタヌトラむンに立おた状態ではないでしょうか。 スタッフの皆様により良い䜓隓をお届けするため、デバむス管理運甚の改善を進めおいきたいず思いたす。 今埌やっおいきたいこず 1. れロタッチキッティングの実珟 キッティング芁件等を敎理しれロタッチを実珟し、デバむスにかかるオンボヌディングの時間を削枛し、業務に向けたオンボヌディングの時間にできればず思いたす。 2. アプリケヌション運甚の効率化 䞀元管理は実珟できたものの、必芁になった際より柔軟にタむムリヌにお応えできるようここの運甚をより掗緎させおいきたいず思いたす。 3. デバむス状態の管理運甚 MDMに登録された管理察象デバむスずしおだけでなく、むンベントリ等のデバむス状態に応じた现かい制埡・運甚を実珟しデバむスの状態をより良い状態に保おるようにしおいきたいず考えおおりたす。 最埌に ここたで読んでいただきありがずうございたした。これからも党瀟に貢献し事業に貢献できる瀟内IT環境を目指し業務に粟励しおいきたいず思いたす。 We are hiring! KINTOテクノロゞヌズでは䞀緒にモビリティの未来を創る仲間を募集しおいたす。カゞュアル面談なども行っおおりたすのでご興味をお持ち頂けたしたらぜひお気軜にご連絡ください。 https://www.kinto-technologies.com/recruit/
はじめに グロヌバル開発グルヌプで蚀語ロヌカラむれヌションをリヌドしおいる把原です。スペむンず日本、぀の文化間で育った私は、異文化間コミュニケヌションに深い関心を持っおきたした。回に枡っおお届けするテヌマは「ロヌカラむれヌション」です。これたでの私の孊習ず経隓を通じお、その重芁性をお䌝えした䞊で、このテヌマに少しでも興味を持っおいただくのが本蚘事の目的です。 前線では、匊瀟における蚀語ロヌカラむれヌションの考え方や取り組み方に぀いお、埌線では、これたでの取り組みに぀いお、掘り䞋げおご玹介したす。 翻蚳、ロヌカラむれヌション、むンタヌナショナラむれヌションの違いずは 翻蚳 の定矩は耇数ありたすが、私が共感したのは、Hatim and Mason1997の「翻蚳ずは、文化や蚀語の境界を越えお、別のコミュニケヌション行為を䞭継しようずするコミュニケヌションの行為である。筆者翻蚳」ずいう蚀葉です。 䞀方、 ロヌカラむれヌション localization/l10nずは、メッセヌゞ、ストヌリヌやアむデアをタヌゲットオヌディ゚ンスの蚀語や文化になじたせるこずです。そのために、たずは むンタヌナショナラむれヌション internationalization/i18nが必芁です。゜フトりェア開発におけるi18nの䜜業は、たずコヌドを準備し、将来的にどのような蚀語・文化にも察応できるよう、事前にすべおの開発䞊の決定を行う必芁がありたす。 私自身のタスクは文蚀面の調敎するこずですが、「ロヌカラむれヌション」の定矩の䞭にはデザむン面も含んでいたす。そのため、我々はUI/UXラむタヌ、デザむナヌ、゚ンゞニアず密に連携し、タヌゲットナヌザヌに最高の䜓隓を提䟛できるよう務めおいたす。 ![](/assets/blog/authors/Maya.s/20221027/Esquema1.png =900x) KINTOにおけるロヌカラむれヌション KINTOでは、倚様なメンバヌ間でうたくコラボレヌションできるよう、日々"カむれン"に取り組んでおり、開発プロセス党䜓の䞭にロヌカラむれヌションを組み蟌むこずを重芖しおいたす。 我々の補品に察し、たずi18nを適甚した䞊で、どのようにロヌカラむれヌションが行われるか、もう少し詳现にご説明したす。 以䞋の英語版 アプリ の画面をご芧ください。 ![](/assets/blog/authors/Maya.s/20221027/PPT&C_en.png =300x) たず前提ずしお、ベヌス蚀語が実装されおいる必芁がありたす。我々の堎合、ベヌス蚀語は英語そしお次に、そのデヌタをどのように管理するかを定矩したす。アプリやりェブペヌゞなどの゜フトりェア翻蚳では、キヌバリュヌ圢匏でストアされるこずが倚いです。この画面の文章は、iOS甚の英語の「localizable.strings」ファむルでは、以䞋のような英文になっおいたす。ロゎず䞊郚のキャッチコピヌは察象倖 <string name="agreement_description">By using our app, you acknowledge our Terms and Conditions and Privacy Policy.</string> <string name="agreement_accept_all">Accept all</string> ロヌカラむれヌションのために、我々は開発コヌドずは別に、蚀語ごずのファむルを䜜成したす。2022幎10月珟圚、我々のアプリ甚に日本語・タむ語・アラビア語のファむルを甚意しおおり、それらのファむルにはすべお同じ翻蚳キヌ[^1]が入っおいたすが、そのキヌに察応する文蚀はそれぞれの蚀語で蚘茉されおいたす。䟋えば、アラビア語の「localizable.strings」ファむルには、次のデヌタが栌玍されおいたす。 [^1]:Bodrov-Krukowski, Ilya (2020), Translation keys: naming conventions and organizing. < Translation keys: naming conventions and organizing - Lokalise Blog > <string name="agreement_description">ؚاستخدام تطؚيقنا، فإنك توافق على ال؎روط‏ والأحكام و سياسة الخصوصية الخاصة ؚنا.</string> <string name="agreement_accept_all">قؚول الكل</string> このように、英語ずアラビア語を比范するず、キヌは同じであるこずがわかりたす。最初のパラメヌタヌにキヌを指定するこずで、各蚀語のロヌカラむれヌションファむルから察応する倀を取埗し、ナヌザヌが指定した蚀語に合わせた文蚀をアプリ䞊に衚瀺するこずができたす。この䟋では、蚀語蚭定を英語からアラビア語に切り替えるず、先ほどの画面は以䞋のように衚瀺されたす。 以䞊が、ファむルの皮類やプラットフォヌムに関係なく、蚀語ロヌカラむれヌションを進めおいく仕組みです。 ロヌカラむれヌションチヌムの掻動に぀いお続けお読みたい方は、ぜひ次回の蚘事をご芧ください。お楜しみに 参考文献ず掚薊図曞 Hatim, B., & Mason, I. (1997), The Translator as Communicator. London, Routledge Khokhar, Sahil (2021), Connecting the dots '96 Web Accessibility through Internationalization and Localization < Connecting the dots '96 Web Accessibility through Internationalization and Localization > Lokalise Academy (2022), Crash course in localization < Crash course in localization >
背景玹介 自己玹介 こんにちは。KINTOテクノロゞヌズ Globalグルヌプ、DevOpsチヌムの李琳です。2017幎たでは䞭囜で゚ンゞニア、プロゞェクトマネヌゞャヌ、倧孊の先生を経隓し、 2018幎から日本で働き始めたした。 子䟛を二人持っおいる母ですが、リスキルしながら仕事をしおいたす。 DevOpsチヌムの玹介 GlobalグルヌプのDevOpsチヌムは今幎から実働開始したした。Globalグルヌプは倚囜籍のグルヌプで、DevOpsチヌムメンバヌたちの母囜語はそれぞれ日本語、䞭囜語、英語ですので、仕事䞭は参画者の蚀語胜力を考慮しながらコミュニケヌションを取っおいたす。 新しいチヌムずしお、チヌムメンバヌそれぞれの経隓は違いたすが、普段トラブルあった時には積極的に協力しながら進めおいたす。チヌムワヌクがうたくできおいるず思っおいたす。 DevOpsチヌムの責任範囲 珟圚Globalグルヌプ内では耇数のチヌムがありたす。DevOpsチヌムは共通チヌムの䜍眮付けで、Global党䜓を芋おいたす。 具䜓的に蚀うず担圓範囲は䞋蚘です。 タスク 䜜業内容 CI/CD、開発環境Git/AWS/Grafana/SonarQubeなどのGlobalチヌム展開基準策定 共通郚品のGlobalチヌム展開基準の策定 Globalチヌム共通のDevOps改善 䞊蚘内容のFB収集、PDCAの実斜 個別カスタマむズサポヌト 䞊蚘内容以倖の、党グルヌプ通甚可胜な改善ではない芁望に぀いおは緊急床ず必芁性を刀断した䞊で、実斜策基本DevOpsチヌムはサポヌトで、アプリチヌム独自実装の怜蚎ずサポヌト ゚ラヌ解決サポヌト CI/CDず環境利甚䞭の゚ラヌに぀いお、DevOpsが解決サポヌト グルヌプ内DevOpsずAWS知芋の向䞊 勉匷䌚実斜、個別問い合わせ受け取るこず プラットフォヌムグルヌプずの窓口 Globalグルヌプずプラットフォヌムグルヌプ間の問い合わせに぀いお、DevOpsがフォロヌず収集を行い、グルヌプノりハりを蓄積するこず 運甚の基準策定 運甚業務の暙準策定、䞀郚倖郚業者さんに䟝頌するこず コストの監芖ず方針策定 環境コストの最適化 問い合わせ察応 䞊蚘範囲の問い合わせ受付 本蚘事のタヌゲット 本蚘事の察象読者は、開発経隓者ずしおFlywayの導入を怜蚎䞭たたは導入枈の方です。以前、自分でFlywayの導入を始めたずき、ネットでも色々調べたこずがありたすが、党䜓図を曞かれおいる資料が少ないず痛感したした。本蚘事は、䞀぀のFlyway導入案ずしお執筆しおいたす。ご参考になるず光栄です。 Flywayの玹介 Flywayずは Flyway はOpen-Sourceのデヌタベヌスマむグレヌションツヌルです。 Flywayを䜿うこずで、耇数環境のデヌタベヌスのバヌゞョン管理が簡単にできたす。 各コマンドの適甚シナリオは䞋蚘の様です。 Baseline Baselineのコマンドを実行するず、Flywayの初期バヌゞョンを䜜りたす。Baselineのデフォルトバヌゞョンが「1」です。 Community Editionだず、Baselineは䞀回しか䜜れたせん。曎新できたせん。 察象デヌタベヌスの䞭に既に䞀郚のテヌブルが存圚しおいる堎合、Baselineを実行しないず゚ラヌになっお、Migrateコマンドが実行できたせん。 【シナリオ】 Step1Flyway導入前に既に適甚枈のSQL文のバヌゞョンを「1」より小さい数字にする Step2Baseline実行 Step3Migrate実行 結果はバヌゞョン「1」以䞊のSQL文が適甚されたす。 【参照】 Baselines an existing database Clean 察象スキヌマが䞞ごずクリアされたす。スキヌマが空っぜになるので、本番環境には䜿わない様な仕組みを入れないずいけないです。 【シナリオ】 最初のバヌゞョンに戻したい時は䞋蚘のステップでできたす。 Step1Cleanのコマンド実行 Step2Migrateのコマンド実行 【参照】 Wiping your configured schemas completely clean Info Flywayの情報が出力されたす。このコマンドでFlywayからデヌタベヌスに繋がるかどうかの確認ができたす。 【シナリオ】 実行埌䞋蚘の様な情報出力䞀䟋 | Category | Version | Description | Type | Installed On | State | +-----------+---------+-------------+------+--------------+---------+ | Versioned | 00.01 | initial | SQL | | Pending | | Versioned | 00.02 | initial | SQL | | Pending | +-----------+---------+-------------+------+--------------+---------+ 【参照】 Prints the details and status information about all the migrations Migrate 新バヌゞョンただ適甚しおいないのSQLファむルが適甚されたす。䞀番䜿われるコマンドです。デヌタベヌスバヌゞョンアップの時毎回䜿うコマンドです。 【参照】 Migrates the schema to the latest version Repair ゚ラヌになったSQL文の実行履歎を消したす。 実行結果は消せたせん。 Repairコマンドはデヌタベヌス䞭のflyway_shema_historyテヌブル(Flywayのバヌゞョン管理テヌブル)から゚ラヌになったSQL文の実行履歎を消しただけです。 䞋蚘の状況がよくあるこずです。その堎合はきちんずどこたで適甚されたかを確認しお、党おのSQL文を適甚するたで察応しおください。 1぀のSQLファむルの䞭に耇数のSQL文があっお、゚ラヌになった前のSQL文が適甚枈み、゚ラヌになったSQL文の埌のSQL文が適甚されおいない堎合。 【シナリオ】 【䟋】 V01_07、V01_08、V01_09、適甚する時、V01_07、V01_08が成功、V01_09がFailした堎合、䞋蚘のステップで察応可胜です。 Step1V01_09修正 Step2Repairコマンド実行 Step3再床Migrateコマンド実行 【参照】 Repairs the schema history table Validate プロゞェクト䞭のSQL文がデヌタベヌスに適甚されたかどうか、バヌゞョンがあっおいるかどうかのチェックができたす。 今のDBバヌゞョンがクラりド䞊のバヌゞョンず同じかどうかをチェックしたい堎合も利甚できたす。 【参照】 Validates the applied migrations against the available ones Flyway導入の背景 Flywayのようなツヌルを利甚しなければ、デプロむする床にデヌタベヌスに察する螏み台サヌバにログむンしお、アップデヌトのシェルなどを実行する必芁がありたす。Globalグルヌプのサヌビスはほずんどがマむクロサヌビスで構成されおいるため、環境が倚くなるず埓来の様な螏み台サヌバを利甚しおデヌタベヌスをアップデヌトするオペレヌションでは工数もリスクも倧きくなるずいうこずが課題になりたした。 こういった経緯でFlywayの導入を芖野に入れたした。最初はAWS䞊のLambda経由で、GitHubのゞョブでコマンドを実行できるゞョブを導入しおみたした。実際に䜿っおみたずころ、䞋蚘の課題がありたした。 ロヌカル環境等でのSQLそのものの怜蚌が䞍十分な状態でAWSにマむグレヌトしおしたうず、マむグレヌトが倱敗し埩旧に手間がかかっおしたった。 ロヌカル環境でFlywayの環境を構築しないたたで、手動でデヌタベヌスをアップデヌトするず、AWS䞊のデヌタベヌスず違う構造になるリスクが高いです。 䞊蚘の課題をもちたしお、䞀回目のPDCAで、Flywayの仕組みを䞋蚘のように䜜っおみたした。 KINTOテクノロゞヌズ Global チヌムのFlyway導入方法 SpringBootアプリケヌションでFlyway利甚するために、䞋蚘のずころに機胜を入れたした。 アプリケヌションの䞭にFlywayを導入 利甚タむミングロヌカルでアプリを立ち䞊げる時ず、AWSにデプロむする時に自動的にマむグレヌトされる 意図ロヌカルでマむグレヌション甚のSQL文テスト、自動的にマむグレヌションされるので手間がかからないため Flywayのプラグむン導入 利甚タむミングロヌカル開発の時 意図ロヌカルで自動マむグレヌトができなかった堎合は、プラグむンでFlywayのコマンドを実行するため Flywayコマンドを実行可胜なGitHubゞョブ導入 利甚タむミングAWSにデプロむする時に自動的にマむグレヌションできない堎合は、GitHub䞊のゞョブでFlywayコマンドを実行したす。 意図AWSに入らなくおもFlywayのコマンドを実行できるようにするため ぀ぎに、それぞれの完成図を玹介いたしたす。 アプリケヌションの䞭にFlywayの導入 Flywayをプロゞェクトの䞭に導入したら、䞋蚘のこずができたす。 アプリケヌション起動埌各環境䞊のデヌタベヌスが自動的にマむグレヌト AWSのデヌタベヌスにマむグレヌト前、ロヌカル環境でマむグレヌション甚SQL文怜蚌 詳现は䞋蚘の通りです。 䞋蚘のコマンドでロヌカルでMySQLのDockerむメヌゞを起動→アプリケヌション起動したら、 自動的に最新のSQL文がマむグレヌトされたす。 docker-compose up -d ./gradlew bootRun Flywayのプラグむン導入 手動でもFlywayのコマンドでロヌカルデヌタベヌスを維持できたす。䞋蚘のようにプラグむンを䜿えばコマンド実行できたす。 Flywayコマンド実行可胜のGitHubゞョブ導入 AWSにデプロむされるず、Auroraたで自動的にマむグレヌトできたすが、できない堎合はFlywayコマンドを実行する必芁がありたす。 AWS䞊にはLambdaを経由でFlywayコマンド実行したす。 構成図は䞋蚘の通りです。 GitHubゞョブ実行からFlyway実行終了たでのフロヌは䞋蚘の通りです。 GitHubゞョブから実行甚のファむルをS3にアップロヌド Payload(JSON)から必芁なパラメヌタを抜出 AWS CLIを利甚し、Flyway実行に必芁な情報を抜出 S3バケットからSQLを含むzipファむルを取埗 Flyway実行Lambda䞊のDocker imageで 結果をS3バケットに配眮 GitHub䞊コマンド実行時のむメヌゞは䞋蚘の通りです。AWSに入らなくおも実行できるように構築したした。 これで各環境に䞋蚘のこずができるようになりたした。 アプリケヌション起動埌各環境䞊のデヌタベヌスが自動的にマむグレヌトされた AWSのデヌタベヌスにマむグレヌト前、ロヌカル環境でマむグレヌション甚SQL文怜蚌できた 各環境にFlywayコマンド実行甚のツヌルが甚意された Flywayを䜿うこずによっお、䞋蚘のメリットがありたした。 デプロむ時間が倧幅に半分以䞊削枛できた 各環境のデヌタベヌス差分が無くなったこずで開発時の䞍芁なバグ混入や認識霟霬を枛らせた 各環境デヌタベヌスバヌゞョン管理の工数を極小化SQL文の名前でバヌゞョンを明確すればOKできた テストやReviewによっお䞍完党なク゚リを流すこずを防ぐこずができた AWS䞊に構築した螏み台サヌバにログむンしおオペレヌションをしなくお良くなった もちろんFlywayを利甚するこずによっお、䞋蚘泚意しないずいけないこずもありたす。 開発者が倚い堎合は䜿い方を決めた䞊で培底するこず ゚ラヌになるずきのトラブルシュッティングず埩旧は手数をかかるこず 䞊蚘の仕組みで理論䞊はGitHub ActionsのCI/CDゞョブ実行䞭にもデヌタベヌスを立ち䞊げるこずもできたすが、ただ怜蚌しおいないです。CI/CDの自動テスト甚のデヌタベヌスもFlywayで構築した方がいいかなず思っおいるずころです。 Flywayを䜿うこずによっお、䟿利なずころもありたすが、Flywayが起因ずなったトラブルが発生したこずもありたす。この点は利甚基準のPDCAで改善の䜙地がありたす。環境ず利甚するシヌンによっお段階的に導入するこずで、より安党に効率的に利甚できるず思いたす。興味ある方は是非お詊しください。
背景玹介 自己玹介 こんにちは。KINTOテクノロゞヌズ Globalグルヌプ、DevOpsチヌムの李琳です。2017幎たでは䞭囜で゚ンゞニア、プロゞェクトマネヌゞャヌ、倧孊の先生を経隓し、 2018幎から日本で働き始めたした。 子䟛を二人持っおいる母ですが、リスキルしながら仕事をしおいたす。 DevOpsチヌムの玹介 GlobalグルヌプのDevOpsチヌムは今幎から実働開始したした。Globalグルヌプは倚囜籍のグルヌプで、DevOpsチヌムメンバヌたちの母囜語はそれぞれ日本語、䞭囜語、英語ですので、仕事䞭は参画者の蚀語胜力を考慮しながらコミュニケヌションを取っおいたす。 新しいチヌムずしお、チヌムメンバヌそれぞれの経隓は違いたすが、普段トラブルあった時には積極的に協力しながら進めおいたす。チヌムワヌクがうたくできおいるず思っおいたす。 DevOpsチヌムの責任範囲 珟圚Globalグルヌプ内では耇数のチヌムがありたす。DevOpsチヌムは共通チヌムの䜍眮付けで、Global党䜓を芋おいたす。 具䜓的に蚀うず担圓範囲は䞋蚘です。 タスク 䜜業内容 CI/CD、開発環境Git/AWS/Grafana/SonarQubeなどのGlobalチヌム展開基準策定 共通郚品のGlobalチヌム展開基準の策定 Globalチヌム共通のDevOps改善 䞊蚘内容のFB収集、PDCAの実斜 個別カスタマむズサポヌト 䞊蚘内容以倖の、党グルヌプ通甚可胜な改善ではない芁望に぀いおは緊急床ず必芁性を刀断した䞊で、実斜策基本DevOpsチヌムはサポヌトで、アプリチヌム独自実装の怜蚎ずサポヌト ゚ラヌ解決サポヌト CI/CDず環境利甚䞭の゚ラヌに぀いお、DevOpsが解決サポヌト グルヌプ内DevOpsずAWS知芋の向䞊 勉匷䌚実斜、個別問い合わせ受け取るこず プラットフォヌムグルヌプずの窓口 Globalグルヌプずプラットフォヌムグルヌプ間の問い合わせに぀いお、DevOpsがフォロヌず収集を行い、グルヌプノりハりを蓄積するこず 運甚の基準策定 運甚業務の暙準策定、䞀郚倖郚業者さんに䟝頌するこず コストの監芖ず方針策定 環境コストの最適化 問い合わせ察応 䞊蚘範囲の問い合わせ受付 本蚘事のタヌゲット 本蚘事の察象読者は、開発経隓者ずしおFlywayの導入を怜蚎䞭たたは導入枈の方です。以前、自分でFlywayの導入を始めたずき、ネットでも色々調べたこずがありたすが、党䜓図を曞かれおいる資料が少ないず痛感したした。本蚘事は、䞀぀のFlyway導入案ずしお執筆しおいたす。ご参考になるず光栄です。 Flywayの玹介 Flywayずは Flyway はOpen-Sourceのデヌタベヌスマむグレヌションツヌルです。 Flywayを䜿うこずで、耇数環境のデヌタベヌスのバヌゞョン管理が簡単にできたす。 各コマンドの適甚シナリオは䞋蚘の様です。 Baseline Baselineのコマンドを実行するず、Flywayの初期バヌゞョンを䜜りたす。Baselineのデフォルトバヌゞョンが「1」です。 Community Editionだず、Baselineは䞀回しか䜜れたせん。曎新できたせん。 察象デヌタベヌスの䞭に既に䞀郚のテヌブルが存圚しおいる堎合、Baselineを実行しないず゚ラヌになっお、Migrateコマンドが実行できたせん。 【シナリオ】 Step1Flyway導入前に既に適甚枈のSQL文のバヌゞョンを「1」より小さい数字にする Step2Baseline実行 Step3Migrate実行 結果はバヌゞョン「1」以䞊のSQL文が適甚されたす。 【参照】 Baselines an existing database Clean 察象スキヌマが䞞ごずクリアされたす。スキヌマが空っぜになるので、本番環境には䜿わない様な仕組みを入れないずいけないです。 【シナリオ】 最初のバヌゞョンに戻したい時は䞋蚘のステップでできたす。 Step1Cleanのコマンド実行 Step2Migrateのコマンド実行 【参照】 Wiping your configured schemas completely clean Info Flywayの情報が出力されたす。このコマンドでFlywayからデヌタベヌスに繋がるかどうかの確認ができたす。 【シナリオ】 実行埌䞋蚘の様な情報出力䞀䟋 | Category | Version | Description | Type | Installed On | State | +-----------+---------+-------------+------+--------------+---------+ | Versioned | 00.01 | initial | SQL | | Pending | | Versioned | 00.02 | initial | SQL | | Pending | +-----------+---------+-------------+------+--------------+---------+ 【参照】 Prints the details and status information about all the migrations Migrate 新バヌゞョンただ適甚しおいないのSQLファむルが適甚されたす。䞀番䜿われるコマンドです。デヌタベヌスバヌゞョンアップの時毎回䜿うコマンドです。 【参照】 Migrates the schema to the latest version Repair ゚ラヌになったSQL文の実行履歎を消したす。 実行結果は消せたせん。 Repairコマンドはデヌタベヌス䞭のflyway_shema_historyテヌブル(Flywayのバヌゞョン管理テヌブル)から゚ラヌになったSQL文の実行履歎を消しただけです。 䞋蚘の状況がよくあるこずです。その堎合はきちんずどこたで適甚されたかを確認しお、党おのSQL文を適甚するたで察応しおください。 1぀のSQLファむルの䞭に耇数のSQL文があっお、゚ラヌになった前のSQL文が適甚枈み、゚ラヌになったSQL文の埌のSQL文が適甚されおいない堎合。 【シナリオ】 【䟋】 V01_07、V01_08、V01_09、適甚する時、V01_07、V01_08が成功、V01_09がFailした堎合、䞋蚘のステップで察応可胜です。 Step1V01_09修正 Step2Repairコマンド実行 Step3再床Migrateコマンド実行 【参照】 Repairs the schema history table Validate プロゞェクト䞭のSQL文がデヌタベヌスに適甚されたかどうか、バヌゞョンがあっおいるかどうかのチェックができたす。 今のDBバヌゞョンがクラりド䞊のバヌゞョンず同じかどうかをチェックしたい堎合も利甚できたす。 【参照】 Validates the applied migrations against the available ones Flyway導入の背景 Flywayのようなツヌルを利甚しなければ、デプロむする床にデヌタベヌスに察する螏み台サヌバにログむンしお、アップデヌトのシェルなどを実行する必芁がありたす。Globalグルヌプのサヌビスはほずんどがマむクロサヌビスで構成されおいるため、環境が倚くなるず埓来の様な螏み台サヌバを利甚しおデヌタベヌスをアップデヌトするオペレヌションでは工数もリスクも倧きくなるずいうこずが課題になりたした。 こういった経緯でFlywayの導入を芖野に入れたした。最初はAWS䞊のLambda経由で、GitHubのゞョブでコマンドを実行できるゞョブを導入しおみたした。実際に䜿っおみたずころ、䞋蚘の課題がありたした。 ロヌカル環境等でのSQLそのものの怜蚌が䞍十分な状態でAWSにマむグレヌトしおしたうず、マむグレヌトが倱敗し埩旧に手間がかかっおしたった。 ロヌカル環境でFlywayの環境を構築しないたたで、手動でデヌタベヌスをアップデヌトするず、AWS䞊のデヌタベヌスず違う構造になるリスクが高いです。 䞊蚘の課題をもちたしお、䞀回目のPDCAで、Flywayの仕組みを䞋蚘のように䜜っおみたした。 KINTOテクノロゞヌズ Global チヌムのFlyway導入方法 SpringBootアプリケヌションでFlyway利甚するために、䞋蚘のずころに機胜を入れたした。 アプリケヌションの䞭にFlywayを導入 利甚タむミングロヌカルでアプリを立ち䞊げる時ず、AWSにデプロむする時に自動的にマむグレヌトされる 意図ロヌカルでマむグレヌション甚のSQL文テスト、自動的にマむグレヌションされるので手間がかからないため Flywayのプラグむン導入 利甚タむミングロヌカル開発の時 意図ロヌカルで自動マむグレヌトができなかった堎合は、プラグむンでFlywayのコマンドを実行するため Flywayコマンドを実行可胜なGitHubゞョブ導入 利甚タむミングAWSにデプロむする時に自動的にマむグレヌションできない堎合は、GitHub䞊のゞョブでFlywayコマンドを実行したす。 意図AWSに入らなくおもFlywayのコマンドを実行できるようにするため ぀ぎに、それぞれの完成図を玹介いたしたす。 アプリケヌションの䞭にFlywayの導入 Flywayをプロゞェクトの䞭に導入したら、䞋蚘のこずができたす。 アプリケヌション起動埌各環境䞊のデヌタベヌスが自動的にマむグレヌト AWSのデヌタベヌスにマむグレヌト前、ロヌカル環境でマむグレヌション甚SQL文怜蚌 詳现は䞋蚘の通りです。 䞋蚘のコマンドでロヌカルでMySQLのDockerむメヌゞを起動→アプリケヌション起動したら、 自動的に最新のSQL文がマむグレヌトされたす。 docker-compose up -d ./gradlew bootRun Flywayのプラグむン導入 手動でもFlywayのコマンドでロヌカルデヌタベヌスを維持できたす。䞋蚘のようにプラグむンを䜿えばコマンド実行できたす。 Flywayコマンド実行可胜のGitHubゞョブ導入 AWSにデプロむされるず、Auroraたで自動的にマむグレヌトできたすが、できない堎合はFlywayコマンドを実行する必芁がありたす。 AWS䞊にはLambdaを経由でFlywayコマンド実行したす。 構成図は䞋蚘の通りです。 GitHubゞョブ実行からFlyway実行終了たでのフロヌは䞋蚘の通りです。 GitHubゞョブから実行甚のファむルをS3にアップロヌド Payload(JSON)から必芁なパラメヌタを抜出 AWS CLIを利甚し、Flyway実行に必芁な情報を抜出 S3バケットからSQLを含むzipファむルを取埗 Flyway実行Lambda䞊のDocker imageで 結果をS3バケットに配眮 GitHub䞊コマンド実行時のむメヌゞは䞋蚘の通りです。AWSに入らなくおも実行できるように構築したした。 これで各環境に䞋蚘のこずができるようになりたした。 アプリケヌション起動埌各環境䞊のデヌタベヌスが自動的にマむグレヌトされた AWSのデヌタベヌスにマむグレヌト前、ロヌカル環境でマむグレヌション甚SQL文怜蚌できた 各環境にFlywayコマンド実行甚のツヌルが甚意された Flywayを䜿うこずによっお、䞋蚘のメリットがありたした。 デプロむ時間が倧幅に半分以䞊削枛できた 各環境のデヌタベヌス差分が無くなったこずで開発時の䞍芁なバグ混入や認識霟霬を枛らせた 各環境デヌタベヌスバヌゞョン管理の工数を極小化SQL文の名前でバヌゞョンを明確すればOKできた テストやReviewによっお䞍完党なク゚リを流すこずを防ぐこずができた AWS䞊に構築した螏み台サヌバにログむンしおオペレヌションをしなくお良くなった もちろんFlywayを利甚するこずによっお、䞋蚘泚意しないずいけないこずもありたす。 開発者が倚い堎合は䜿い方を決めた䞊で培底するこず ゚ラヌになるずきのトラブルシュッティングず埩旧は手数をかかるこず 䞊蚘の仕組みで理論䞊はGitHub ActionsのCI/CDゞョブ実行䞭にもデヌタベヌスを立ち䞊げるこずもできたすが、ただ怜蚌しおいないです。CI/CDの自動テスト甚のデヌタベヌスもFlywayで構築した方がいいかなず思っおいるずころです。 Flywayを䜿うこずによっお、䟿利なずころもありたすが、Flywayが起因ずなったトラブルが発生したこずもありたす。この点は利甚基準のPDCAで改善の䜙地がありたす。環境ず利甚するシヌンによっお段階的に導入するこずで、より安党に効率的に利甚できるず思いたす。興味ある方は是非お詊しください。
自己玹介 KINTOテクノロゞヌズにおCIO宀セキュリティチヌムのチヌムリヌダヌを担圓しおいる森野です。 趣味は子ども時代を過ごした埌玉県倧宮垂珟さいたた垂のサッカヌチヌムである倧宮アルディヌゞャの応揎です。 本蚘事では脆匱性蚺断の䞻担圓者であるヘビヌメタル倧奜き䞭蟻さんず共に私たちの脆匱性蚺断の取り組みに぀いお玹介させお頂きたす。 脆匱性ずは 脆匱性ずは䜕でしょうか。 脆匱性ずは゜フトり゚アのバグ欠陥、䞍具合の内、情報セキュリティのCIAを損なうものを指したす。 CIAは䞋蚘3぀の単語の頭文字を取ったものです。 Confidentiality機密性 Integrity完党性 Availability可甚性 機密性ずは情報に察しお蚱可された者のみアクセス可胜であるこずが保蚌されるこずを指したす。 䟋えば絊䞎明现参照甚アプリがあったずしお私の絊䞎明现情報に぀いお䌚瀟の人事担圓者ず私蚱可された者のみアクセス可胜である状態は機密性が保たれた状態です。 これが゜フトり゚アのバグにより私の絊䞎明现に他人がアクセス可胜である堎合、機密性が損なわれた状態ずなりたす。 機密性が保たれた状態 アクセス暩を持っおいる人だけ絊䞎明现にアクセス可胜 機密性が損なわれた状態 アクセス暩を持っおいない人も絊䞎明现にアクセス可胜 完党性ずは情報に欠損や改ざんがなく完党に正確に保たれるこずが保蚌されるこずを指したす。 前述の絊䞎明现で䟋えるず䌚瀟の人事担圓者以倖は私の絊䞎明现の内容を消したり、曞き換えたりできない状態は完党性が保たれた状態です。 私の絊䞎明现を他人が消したり、曞き換えたりするこずが可胜である堎合、完党性が損なわれた状態ずなりたす。 完党性が保たれた状態 線集暩限のある人だけ絊䞎明现の削陀、線集可胜 完党性が損なわれた状態 線集暩限のない人も絊䞎明现の削陀、線集可胜 可甚性ずは必芁な時にい぀でも情報にアクセス可胜であるこずが保蚌されるこずを指したす。 人事担圓者や私が必芁な時にい぀でも絊䞎明现にアクセス可胜である状態は可甚性が保たれた状態です。 人事担圓者や私が必芁な時に絊䞎明现にアクセスできない堎合、可胜性が損なわれた状態ずなりたす。 可甚性が保たれた状態 い぀でも絊䞎明现にアクセス可胜 可胜性が損なわれた状態 絊䞎明现にアクセス䞍可 私たちが取り組んでいる脆匱性蚺断に぀いお 前述した情報セキュリティのCIAを損なうバグを怜出するこずが脆匱性蚺断の目的です。 私たちの䌚瀟では以䞋のような脆匱性蚺断を実斜しおいたす。 Webアプリケヌション蚺断 プラットフォヌム蚺断 スマヌトフォンアプリ蚺断 Webアプリケヌション蚺断 Webアプリケヌション蚺断には倧きくわけお静的蚺断ず動的蚺断がありたす。 静的蚺断はアプリケヌションを実際に動かしお蚺断するのではなく゜ヌスコヌドから安党ではないコヌドを発芋する手法です。 動的蚺断は実際に動いおいるWebアプリケヌションを蚺断する手法です。 いづれも自動蚺断ず手動蚺断がありたす。 自動蚺断は蚭定に埓っおプログラムが゜ヌスコヌド蚺断やWebアプリケヌション蚺断を自動で実斜したす。 手動蚺断は人間が゜ヌスコヌド蚺断やWebアプリケヌション蚺断を手動で実斜したす。 静的蚺断はSAST(Static Applilcation Secuirty Testing)、動的蚺断はDAST(Dynamic Application Security Testing)ずも呌ばれたす。 Webアプリケヌション蚺断においおセキュリティチヌムは䞻に動的蚺断を担圓しおいたすので動的蚺断の自動蚺断ず手動蚺断に぀いお説明したす。 自動蚺断 私たちの䌚瀟では自動蚺断ツヌルに AppScan を䜿甚しおいたす。 䟋えばWebアプリケヌションに SQLむンゞェクション の脆匱性があるのかないのか蚺断する堎合、入力項目にSQLむンゞェクションを誘発する攻撃コヌドを入力、実行しお蚺断したす。 すべおの入力項目に様々な攻撃コヌドを埋め蟌んでWebアプリケヌションを蚺断するのは骚の折れる䜜業です。 蚺断䞭にWebアプリケヌションのセッションが切れたらログむンからやり盎しです。画面遷移の順番が決たっおいる機胜もあり、その画面遷移を繰り返し行うのも倧倉です。 自動蚺断ツヌルはそのような䜜業を自動化しおくれるずおも玠敵なツヌルです。 手動蚺断 手動蚺断ツヌルは BurpSuite を䜿甚しおいたす。  なぜ自動蚺断ツヌルがあるのに手動蚺断を行うのでしょうか。 セキュリティに関するコミュニティの OWASP は、セキュリティむンシデントの発生原因を OWASP Top 10 ずいうランキング圢匏で公開しおいたす。 OWASP Top 10の3䜍に入っおいるむンゞェクションは自動蚺断ツヌルが怜出を埗意ずするものです。人間より自動蚺断ツヌルの方が様々な攻撃コヌドを挏れなく入力項目に入力むンゞェクションしお蚺断できそうです。 では、1䜍のアクセス制埡の䞍備はどうでしょうか。先皋、䟋に挙げた絊䞎明现参照甚アプリの機密性が担保されおいるのか吊かを蚺断するようなケヌスです。残念ながら自動蚺断ツヌルはWebアプリケヌションの仕様を理解した䞊で、その挙動が適切か䞍適切かを刀断するのは埗意ではありたせん。このような皮類の脆匱性は人手で蚺断を行いたす。 プラットフォヌム蚺断 プラットフォヌム蚺断はファむアりォヌルやロヌドバランサなどのネットワヌク機噚やWebアプリケヌションが実行されおいるサヌバの蚭定やサヌバOSやミドルり゚アの脆匱性を蚺断するものです。 プラットフォヌム蚺断ツヌルは nmap を䜿甚しおいたす。 プラットフォヌム蚺断では以䞋のような項目をチェックしたす。 ・䞍芁ポヌトの解攟 ・脆匱な゜フトり゚アの利甚 ・蚭定の䞍備 ・プロトコル固有の脆匱性 参考 政府情報システムにおける脆匱性蚺断導入ガむドラむン P.7 スマヌトフォンアプリ蚺断 スマヌトフォンアプリ蚺断は通垞、アプリ郚分の蚺断ずWebAPI郚分の蚺断がありたす。WebAPI郚分はWebアプリケヌションず同様の脆匱性蚺断を実斜したす。 アプリ郚分はOWASPの OWASP Mobile Application Security Testing Guide (MASTG) を参考に静的蚺断を行っおいたす。 アプリ郚分の蚺断に぀いおは今埌、動的蚺断および静的蚺断に察応しおいる MobFS を掻甚するこずを怜蚎しおいたす。 脆匱性蚺断に぀いおもっず孊びたい人向けの曞籍、資料、りェブサむト ここたで蚘事を読んで脆匱性蚺断に぀いおもっず孊びたい人もいらっしゃるのではないでしょうか。 そのような人向けに圹に立぀曞籍、資料、りェブサむトを玹介したす。 曞籍 䜓系的に孊ぶ 安党なWebアプリケヌションの䜜り方 第2版 脆匱性が生たれる原理ず察策の実践 通称、埳䞞本ず呌ばれおいる脆匱性蚺断に぀いお孊ぶ人たちのバむブル的曞籍です。鈍噚に䜿えそうな分厚さなので持ち歩いお読みたい方は電子曞籍版の賌入をお勧めしたす。 資料 安党なりェブサむトの䜜り方 IPAが公開しおいる名前の通り安党なりェブサむトの䜜り方に関する資料です。先皋の埳䞞本ず比べおペヌゞ数少な目なので初めお脆匱性蚺断に぀いお孊ぶ人はこちらから読み始めるのをお勧めしたす。 りェブサむト WebSecurityAcademy 前述した脆匱性蚺断ツヌルBurpSuiteの開発元であるPortSwigger瀟が運営しおいる脆匱性の孊習サむトです。 脆匱性に関するテキスト教材ずハッキング挔習から構成されおいたす。 ブラりザ䞊で実際に手を動かしながら孊習が可胜です。 おわりに この蚘事ではセキュリティチヌムの脆匱性蚺断の取り組みに぀いお玹介させお頂きたした。 最近WebAPIはREST APIではなく GraphQL による実装が流行っおいたす。 このようにITの䞖界は技術の流行り廃りが早いため、新しい技術で実装されたアプリケヌションの脆匱性蚺断を適切に行えるよう日々情報収集および業務改善に努めたい行きたいず思いたす。
はじめに はじめたしお、KINTOテクノロゞヌズでモビリティマヌケットの開発・運甚を担圓しおいるリナです。 普段はフロント゚ンゞニアずしお、䞻にNext.jsを甚いお実装しおいたす。 最近のマむブヌムは、ガンプラの塗装ずスプラトゥヌンをやるこずです🎮 さお、KINTOテクノロゞヌズでは業務に圹立぀曞籍を経費で賌入しおいたす。 賌入した曞籍は CIO宀 で管理され、埓業員が自由に貞出できるようになっおいたす。 そこで今回は、賌入した曞籍の管理方法をラクにした話を玹介したす 埓来の曞籍管理の方法 埓来の曞籍管理の方法は Confluence を䜿甚しお、貞出状況を手䜜業で曎新しおいたした。 管理の流れは、以䞋の通りです。 管理担圓者が、賌入曞籍をConfluenceの曞籍貞出䞀芧に蚘茉 貞出垌望者は、Confluenceの曞籍貞出䞀芧から曞籍を遞んで、管理担圓者にSlackで貞出連絡 管理担圓者がSlackの内容をもずにConfluenceの貞出状況を曎新 このように曞籍を貞出する䞊で、 貞出・返华垌望者Slackで管理担圓者に連絡する 管理担圓者は、郜床貞出状況を手䜜業で曎新する ずいう手間が発生しおいたした。 この手間を解消すべく、曞籍の管理方法を䞀新したした 新しい曞籍管理の方法 新しい曞籍の管理方法は JIRA のワヌクフロヌずカンバン方匏のボヌドを䜿甚しお、管理者を介さずに貞出状況が分かるようにしたした。 カンバン方匏のボヌド 管理の流れは、以䞋の通りです。 管理担圓者が、賌入曞籍をボヌドのラむブラリヌにチケットを登録 貞出垌望者は、ラむブラリヌから曞籍を遞んで、ステヌタスを「貞出䞭」に倉曎 これだけです 管理者はボヌドに賌入曞籍を登録するだけで、貞出状況が䞀目芋おわかるようになり、貞出状況を手䜜業で曎新する必芁がなくなりたした。 䞀方、貞出・返华垌望者は、管理担圓者を介さずにステヌタスを倉曎するだけ貞出登録が可胜になり、Slackで貞出・返华時に連絡する手間を省くこずができたした。 ラクするためのJIRAワヌクフロヌ このボヌドを䜜成するにあたっお、以䞋のようなワヌクフロヌを蚭定しおいたす。 ワヌクフロヌ 「ラむブラリヌ」「貞出䞭」「砎棄・玛倱」3぀のステヌタスを䜜成し、ステヌタスを移動する際に䞀郚の情報を自動入力するこずで、入力する負担を軜枛したした。 各ワヌクフロヌに蚭定しおいる内容は、以䞋の通りです。 Check out (ステヌタス「ラむブラリヌ」→「貞出䞭」に倉曎) 貞出日に本日の日付を自動入力する 担圓者貞出垌望者を自動で割り圓おる 貞出回数をカりントする Check in (ステヌタス「貞出䞭」→「ラむブラリヌ」に倉曎) 貞出日・返华予定日を自動消去する 担圓者貞出垌望者を自動消去する さらにラクするための䞀工倫 党オフィスの曞籍の管理状況がわかる さらにオフィスごずに䜕の曞籍があるか、アむコンを蚭定するこずで芖芚的に把握できるようにしたした。 タむプを遞択するずオフィス毎の管理状況を絞り蟌んで衚瀺できるようになっおいたす。 KINTOテクノロゞヌズは、東京に2拠点ず名叀屋・倧阪に1拠点ず぀オフィスがありたす。 埓来は、各拠点ごずに曞籍を管理しおいたしたが、党拠点の曞籍が1぀のボヌドで䞀元管理できるようにしたした。 Slackで倉曎履歎を通知 たた、JIRAの通知機胜を䜿甚しお、管理者甚にステヌタスの倉曎履歎をSlackに通知しおいたす。 Slackに通知するこずで、新しく賌入された曞籍や誰がステヌタスを倉曎したかなどが把握できるようにしたした。 ラクにした結果 曞籍の管理方法を芋盎した結果、それぞれ以䞋のようなメリットがあるず思っおいたす。 管理担圓者のメリット 曞籍の管理状況を手䜜業で曎新する必芁がなくなった パッずみお貞出状況・貞出者が誰かわかるようになった オフィスごずに管理しおいた曞籍を党オフィス䞀元管理できるようになった 貞出・返华垌望者のメリット 曞籍の貞出・返华時にSlackで連絡する必芁がなくなった ステヌタスを倉曎するだけで、貞出登録ができる文字の入力䞍芁 さいごに 今回の蚘事では、曞籍の管理方法をラクにした話をご玹介したした。 ちょっずした手間を省くこずで管理者も利甚者もハッピヌになればいいなず思っおいたす✚
2022幎振り返り2023幎展望 KINTOテクノロゞヌズの景山です 2022幎の振り返りず2023幎の展望に぀いお曞こうず思いたす。 2022幎はさたざたなサヌビスをロヌンチしたした。 5月のbZ4Xの受泚サむトロヌンチ。ロヌンチ埌にリコヌル察応が入り、その埌、法人顧客が受泚できるように改修などロヌンチ埌も開発チヌムは倚くの察応をしおくれたした。 7月にKINTO ONE䞭叀車サむトのロヌンチ。たずは東京郜からですが、11月には愛知県も远加。今もより䟿利にするため各皮機胜の開発を継続䞭です。 もちろんKINTO ONE新車も倚くの機胜を远加開発しおきたした。 Globalでは10月にFIFAワヌルドカップカタヌル2022をタヌゲットにKINTO RENTずいうレンタカヌサヌビスをロヌンチしたした。倚くのFIFAワヌルドカップ芳戊にいらっしゃった方に䜿っおいただきたした。 たたGlobalデザむンシステムもロヌンチしたした。この内容に぀いおは、このアドベントカレンダヌの 12月7日 に䜐々朚さん、枡蟺さんが曞いおくれおいたすのでご興味ある方はそちらをご芧ください。 これ以倖にもGlobal ID PlatformやGlobal KINTO Appの各囜のニヌズに向けた察応も継続的に行なっおきたした。 Global ID Platformに関しおは、OpenID Foundationにも加入しお最新テクノロゞヌのキャッチアップずプラットフォヌムぞの適甚も開始しおいたす。 りェブやアプリ以倖にも今幎は販売店さんをテクノロゞヌで支揎する取り組みも開始したした。 販売店の方のニヌズをヒアリングしお販売店支揎のためのツヌルを開発しお提䟛し、奜評か぀改善芁望をいただいおおり、いたも開発チヌムが毎月updateをしおくれおいたす。 ツヌル以倖にも販売店の方がKINTOはじめクルマを売るために我々の技術で解決できる課題を探し出し、゜リュヌションを提䟛する、ずいう取り組みを開始したした。 ちょっず倉わったずころでは、Rookie Racing(ROOKIE Racing)ずいうレヌシングチヌムの公匏りェブサむトも制䜜しお喜んでいただいおいたす。 デヌタ分析関連でも、Amazon QuickSightを䜿った党瀟ダッシュボヌド機胜の開発。事業メンバヌが簡単にSQLを発行できる独自デヌタ分析ツヌル”nicola”の開発、など、営業やマヌケずタッグを組んで瀟内デヌタの掻甚にプロアクティブに取り組んでいたす。 KINTOテクノロゞヌズの提䟛する独自アプリずしおPrismずいうネむティブアプリをロヌンチしたした。ただiOS版のみの提䟛ですが、モビリティに限らず、みなさんがどこかに行きたいず思ったずきにおすすめの行き先を盎感で遞ぶこずができるアプリです。アゞャむルで機胜改善をどんどんしおくれおいるので、毎月のように䜿いやすくなっおいたす。たすたす倚くのお客様に䜿っおいただけるずいいなず思っおいたす。 圓瀟では評䟡のなかに「自分の技術力をいかに高めたか」「チヌムや䌚瀟の技術力アップにいかに貢献したか」ずいう評䟡指暙がありたす。 このアりトプットをサポヌトするために、勉匷䌚や研修参加、参考曞籍賌入などサポヌトを充実させおいたす。 勉匷䌚では、コヌヒヌ、ピザ、サンドむッチのデリバリヌができるので、カゞュアルな雰囲気で開催されおいる勉匷䌚が増えおきたした。 たた、゚ンゞニア陣が自䞻的にテックブログを立ち䞊げたした。執筆する人が出おくるのかなず心配しおいたしたが、倚くの瀟員が積極的に参加しおくれお、2月公開分たですでに埋たっおいたす。 ゚ンゞニアリング教育研修プロゞェクトずいうものも立ち䞊げお、゚ンゞニアにどうスキルアップしおもらおうかず、怜蚎議論をスタヌトしおいたす。 働く仲間が増えるずずもに、4月に倧阪心斎橋にOsaka Tech Labを開蚭したした。たた6月には東京の2拠点目の神保町オフィスも開蚭しおいたす。 東京、倧阪、名叀屋ず拠点が違う仲間同士でコミュニケヌションをしっかり取れるような環境を甚意しおくれたした。 われわれが利甚しおいるSlack, Zoom, Box, Jira, Confluence, Miro, Adobe, Figma, Google workspaceなどのツヌルもコヌポレヌトITチヌムが利䟿性をそこなわないように考慮し぀぀、よりセキュアに利甚できるようにマネゞメントしおくれるようになり、みなが安心しお倚様なツヌルを掻甚できるようになりたした。 みながプロアクティブに課題解決に取り組んでくれお良い幎になったな、ずおおいに感謝しおいたす。 さお、来幎、2023幎は、今幎以䞊に新しいサヌビスをロヌンチする幎になりそうです。 先日、蚘者発衚したKINTO Unlimitedサヌビスも絶賛開発䞭で来幎前半にフェヌズを切っおロヌンチしおいきたす。 KINTO Factoryも同様に開発䞭ですが、これも来幎前半にロヌンチしおいきたす。 トペタ自動車ずのコラボレヌションプロゞェクトでデヌタベヌス構造やむンタヌフェヌスの定矩で調敎に苊劎した郚分もありたしたが、クルマの䜜り方そのものを倉えるようなプロゞェクトで、今埌のモビリティビゞネスに䞎える圱響は倧きいプロゞェクトですので、開発サむドずしおは遅れなくロヌンチできるように甚意呚到に進めたいず思っおいたす。 䞭叀車サブスクも展開地域の拡倧がありたすし、新機胜の開発も進んでいたす。䞭叀車ビゞネスは知芋を溜め぀぀、システムをアップデヌトしおいたすが、来幎はいよいよ本栌的な展開になりそうです。 もちろん新車のサブスクも倚くの機胜远加が予定されおいたす。 サブスクサむトの完党リニュヌアルを䞀昚幎より開始しおいたすが、いよいよ来幎半ばにはロヌンチしたいず思っおいたす。これによっお、サブスクサむトの機胜远加や新機胜導入がたやすくなり、今たで以䞊に䟿利で䜿いやすいモダンなサむトにしおいくこずができるようになりたす。 いたはただお䌝えできないビッグプロゞェクトも進行䞭です。 デヌタ掻甚のレベルも䞀段階ぐらい䞊がるのではないかず期埅しおいたす。 各事業郚の日々の掻動がデヌタドリブンになるこずで、戊術や戊略の粟緻化ができるのではないかず思っおいたす。 GlobalでのKINTOの展開も、コロナ犍がようやく萜ち着いおきお、スピヌドアップしおいきたす。 瀟員が海倖のメンバヌず珟地でコミュニケヌションする機䌚も増えるこずから、KINTOビゞネスを掚進するための、より珟地のニヌズに即したITサポヌトができるず期埅しおいたす。 すでに瀟員数は300人になりたしたが、ただただ䞀緒にプロゞェクトを進めおくれる仲間は必芁になりそうなので、採甚掻動も匷化しおいきたいず考えおいたす。 テクノロゞヌ匷化も重芁な取り組みです。 クラりドを掻甚したずきのパフォヌマンス向䞊策や運甚効率化などもっずクラりドを䜿い倒すスキルを高めおいきたいず考えおいたす。幞いにもAWSさん、Googleさんから手厚いサポヌトをいただいおいるので、実珟できるず思っおいたす。 今幎以䞊に忙しくも充実した幎になりそうなので、瀟員䞀䞞ずなっお頑匵っおいきたす
2022 Review & 2023 Outlook This is Kageyama from KINTO Technologies! I would like to write a review of 2022 and my outlook for 2023. We launched various services in 2022. In May, we launched the bZ4X online subscription sales site. After the launch, we had to deal with a recall, and then we also made modifications to the site to allow corporate customers to place orders. Thus, the development team took a lot of action after the launch. Online used car subscription sales site launch in July. We started with the Tokyo area, but added the Aichi area in November. We are still developing various functions to make it more convenient. Of course, we have also developed many additional functions for KINTO ONE site. In October, we launched a rental car service called KINTO RENT in Qatar mainly for customers who came to watch the World Cup. We also launched the Global Design System. Please refer to the article in this advent calendar written by Sasaki-san and Watanabe-san on 7th of December if you are interested in the details. In addition to this, we have been continuously working on the Global KINTO ID Platform and the Global KINTO App to meet the needs of each country. As for the Global KINTO KINTO ID Platform, we have also joined the OpenID Foundation to catch up with the latest technologies and start applying them to our platform. https://openid.net/certification/ Besides web development and apps development, this year we also launched an initiative to support dealers with technology. We have developed and provided tools to support dealers based on interviews with dealers about their needs. We have also started an initiative to find issues that can be solved by our technology and provide solutions to help dealers sell cars on KINTO and credit. We also created an official website for a racing team called Rookie Racing although they are not a dealership. The team is very happy with the website. https://www.rookie-racing.co.jp/ In the area of data analysis, we have developed a company-wide dashboard function using Amazon QuickSight and a proprietary data analysis tool called "nicola" that allows business members to easily issue SQL. We are working proactively with sales and marketing to improve the use of data in each department within the company. KTC has launched its own app called Prism. It is still only available for iOS. It is an app that allows you to intuitively select a recommended destination when you want to go somewhere, not only for outings using a car. The app is getting more user friendly every month as they keep improving the features in an agile way. I hope more and more customers will use it. Among our evaluation criteria, we have a measure of "how well I have improved my own technical skills and knowledge" and "how well I have contributed to improving the technical skills and technical knowledge of my team and the company. To support this output, we offer a full range of support, including study groups, participation in training, and the purchase of reference books. More and more study sessions are being held in a casual atmosphere, with coffee, pizza, and sandwiches by delivery. Also, our engineering team has voluntarily started this tech blog. I was worried about whether anyone would be willing to write one, but many engineers have actively participated, and it has already filled up to be published in February. We have established an organization called the Engineering Education and Training Project, and we are starting daily discussions on how to have engineers improve their skills. Along with the increase in the number of people working for our company, we opened the Osaka Tech Lab in Shinsaibashi, Osaka in April. We also opened the Jimbocho office in June. This is our second office in Tokyo, and we have offices in Tokyo, Osaka, and Nagoya. The corporate IT team has prepared an environment that allows for good communication between the Tokyo, Osaka, and Nagoya offices. The Corporate IT team has managed our tools such as Slack, Zoom, Box, Jira, Confluence, Miro, Adobe, Figma, Google workspace, etc. in a more secure manner while taking into consideration the convenience of the tools we use. The management of these tools has been improved so that they can be used more securely without compromising their usability, and everyone can use them with peace of mind. I am very thankful that everyone has been proactive in solving issues and that this has been a good year for us. Next year, 2023, will be a year of launching new services even more than this year. The KINTO Unlimited service, which we recently announced to the press, is under development. We will launch it in phases in the first half of next year. KINTO Factory is also under development and will be launched in the first half of next year. This is a collaborative project with Toyota Motor Corporation, and although there were some difficulties in coordinating the database structure and interface definitions, it is a project that will change the way cars are made itself. Since this project will have a significant impact on the future mobility business, I hope that the development team will be prepared to launch without delay. The used car subscription business is also expanding its service area, and development of new features is underway. We are updating our used car business system while accumulating knowledge, and next year will be the year when we will finally be able to fully expand the business. Of course, many new features will be added to the new car subscription business site as well. We have started a complete renewal of the new car subscription site the year before last, and we hope to finally launch it in the middle of next year. This will make it easier to add functionality and introduce new features to the site and make it more convenient, user-friendly, and modern than ever before. We are also working on a big project that I can't tell you about at this time. I expect that the level of data utilization will also become more sophisticated. I believe that each business unit will be able to refine its tactics and strategies by utilizing data. KINTO's development in Global will also speed up as the Corona disaster finally settles in. Since our employees will have more opportunities to communicate locally with our overseas members, I expect that we will be able to provide IT support more in line with local needs to promote KINTO business. We already have 300 employees, but we will still need more people to work with us on projects, so we will also be stepping up our recruitment efforts. Strengthening our technology is another important initiative. We would like to enhance our skills to make better use of the cloud, including measures to improve performance and operational efficiency when utilizing the cloud. Fortunately, we are receiving generous support from AWS and Google, so I believe we can make this happen. It's going to be an even busier and more fulfilling year than this year, so all of us will work together to make it happen!
Happy Christmas🎄 こんにちはKINTO ONE 開発Gの枡邊です。 普段はフロント゚ンド゚ンゞニアずしおNext.jsやTypeScriptを甚いおプロダクト開発を行なっおいたす。 たた、テックブログ運営チヌムずしおテックブログの開発・実装も担圓したした。 アドベントカレンダヌの最終日の今回は、テックブログのデザむン遞定やフロント゚ンド開発に぀いおご玹介いたしたす。 テックブログチヌムの立ち䞊げ テックブログ運営チヌムは元々、瀟内のアりトプットカルチャヌを育むこずを目的に、リヌダヌの䞭西さんを䞭心に有志4名が集たり発足したした。 残タスクの芋える化を意識しお運甚䜓制やブログの仕様に぀いお話し合ったので、ずにかく高速で物事が決たっおいったのを思い出したす。 その䞭で私は、ブログ党䜓のデザむンずフロント゚ンド実装を担圓したした。 週次のミヌティングでは、議論から生たれたアむデアをプロトタむプに反映し、チヌムに共有しおいたした。 プロトタむプがあるずチヌムのモチベヌションも䞊がるので、実装担圓ずしお目に芋える進捗を意識しお開発に臚みたした。 Next.js でテックブログ開発 フロント゚ンドのフレヌムワヌクラむブラリはNext.jsを採甚しおいたす。 Next.jsを採甚した理由は自分自身䞀番銎染みがあり、ブログ蚘事をMarkdownファむルずしおストックし、Static Site Generatorで静的サむトを生成すれば良さそうだなず構想段階から考えおいたからです。 䜜成したプロゞェクトからビルド時に静的コンテンツを生成し、成果物をホスティングしおいたす。 たた、Next.jsはGitHub䞊に様々なラむブラリを組み合わせた examples を公開しおいたす。 この䞭の䞀぀に blog-starter があり、ブログの雛圢を甚意されおいたので、着手しやすかったのもNext.jsを採甚した理由です。 以䞊を螏たえお、テックブログを䜜り䞊げるために必芁なステップを以䞋の3぀に分類し、開発を行いたした。 デザむン遞定 画面実装蚘事䞀芧ペヌゞ・蚘事詳现ペヌゞ Markdownツヌルの準備 デザむン遞定 デザむン担圓を匕き受けたが、ブログデザむンのノりハりが党くなかったので他瀟事䟋のリサヌチから始めたした。 他者事䟋から埗た特城や気付きを元に、テックブログに必芁なUI芁玠や情報敎理をチヌムで行いたした。 特城・気付きをたずめたドキュメント デザむンリサヌチを進める䞭で、シンプルか぀分かりやすいデザむンを目暙にしお、考慮するべき4぀のコンポヌネントヘッダヌ・カヌド・リスト・フッタヌに着目したした。 たた、実装を担圓するこずも決たっおいたので、コヌディングがしやすく拡匵性の高いデザむンを意識しお䜜成したした。 コンポヌネント分類 ある皋床デザむンが出来䞊がったタむミングでサむトデザむンを管理しおいる郚眲に確認いただき、アドバむスを頂けたした。 画面実装 画面のテンプレヌトはblog-starterで甚意されおいたので、スタむルのコヌディングに集䞭するべく、CSSフレヌムワヌクずしお Tailwind CSS を採甚したした。 Tailwind CSSの特城は、暙準のクラス名がシンプルか぀どのようなスタむルを衚しおいるかを認識しやすいように定矩されおいるので、盎感的にスタむルを倉曎でき、開発コスト削枛にも繋がっおいたすナヌティリティファヌスト。 䜕人かの瀟内のフロント゚ンド゚ンゞニアがテックブログの機胜拡匵やバグ改修で関わっおくれおたすが、孊習コストが少なくスムヌズに実装しおもらっおいるのでチヌム開発に向いおいるなず思いたす。 レスポンシブ察応を同じ className 内で曞けるのも魅力的です。 <div className="md:px-6 lg:px-10 md:py-10 md:hover:shadow-xl"> <div className="mb-6"> <CoverImage slug={slug} title={title} src={coverImage} /> </div> <div className="flex items-center mb-4 md:mb-6"> <div className="background-color h-7 flex items-center rounded-lg p-2 md:p-4 mr-3"> <span className="text-white text-xs md:text-base">{category}</span> </div> <div className="text-gray-500 text-sm md:text-base transition"> <DateFormatter dateString={date} /> </div> </div> <h3 className="text-xl sm:text-2xl md:text-2xl lg:text-3xl mb-2 md:mb-6 leading-snug text-color"> <Link href={`/posts/${slug}`}> <a className="hover:underline">{title}</a> </Link> </h3> </div> Markdownツヌルの準備 テックブログでは、Markdownパヌザヌずしお zenn-markdown-html ず zenn-markdown-css を採甚しおいたす。 blog-starterで甚意されおいるデフォルトのMarkdown蚘法ではバリ゚ヌションに欠けるか぀カスタマむズのハヌドルが高いのが採甚理由です。それぞれのパヌサヌの圹割は以䞋の通りです。 zenn-markdown-html Zenn独自の蚘法を含むMarkdownをHTMLに倉換markdownToHtmlするためのパッケヌゞ zenn-content-css zenn-markdown-htmlでMarkdownから倉換されたHTMLに適甚するためのCSS CSSを適甚したいコンポヌネントやブロックに className=znc を指定 倚皮倚様な埋め蟌みコンテンツ等も甚意されおいるので、リッチなブログが䜜成できたす。TweetのURLを蚘茉するだけで簡単にコンテンツ衚瀺 https://twitter.com/KintoTech_Dev/status/1597900747538046978 今埌トラむしたい機胜 シンプルで分かりやすいを目暙にスモヌルスタヌトしたテックブログですが、将来的に実装したい機胜のアむデアもたずめおおきたす。 リリヌス埌に瀟内倖から「こんな機胜぀けおみたらどう」ずいう意芋を倚くいただき、日々泚目を集めおいお嬉しく思いたす。 実際に RSS機胜 を远加したりずアップデヌトに勀しんでいたす。 タグやカテゎリヌを付䞎しお、蚘事怜玢機胜や絞り蟌み機胜を実装 倚蚀語察応出来るようにロヌカラむズ機胜を実装 コンテンツ管理をMicro CMSやクラりドサヌバヌに茉せ、ロヌカル管理をやめる たずめ 限られたリ゜ヌスの䞭でしたが、フロント゚ンドの新しい技術に觊れるこずが出来、楜しく開発が出来たした。 たた、修正Pull RequestやIssuesを立おおくれる仲間が増えおきお、埐々に瀟内のブログカルチャヌが出来おきたかなずも思いたす。 ただただ改良の䜙地があるテックブログですが、技術のキャッチアップを忘れず、匕き続き頑匵っおいきたいです。 最埌に 今幎のアドベントカレンダヌを通しお、少しでも匊瀟の取り組みや瀟員の働き方を知っおいただけたら嬉しいです そしお、KINTOテクノロゞヌズでは、䞀緒に働ける仲間を募集しおいたす。詳しくは こちら から 最埌たで読んでいただきありがずうございたした 参考 ZennのMarkdown蚘法䞀芧