【イベントレポート】“エンジニアのキャリア分岐点”マネジメントで見える世界とエンジニアとしての生存戦略

 

こんにちは!TECH Street編集部です!

今回は2021月12月22日(木)に開催した、 「エンジニアのキャリア分岐点”その時どうする? マネジメントで見える世界とエンジニアとしての生存戦略」のイベントレポートをお届けいたします。

キャリアや年齢を重ねていく中で「エンジニアとしてこれから自分はどうあるべきなのか」と考え始める方も多いのではないでしょうか。キャリアの分岐点に立っているエンジニアの皆さんにとって、今後のヒントとなるような内容を盛りだくさんでお送りします!

登壇者はこちら◎

久松 剛さん/株式会社LIG
大谷 祐司さん/ミイダス株式会社
岡本 邦宏さん/パーソルキャリア株式会社
吉次 洋毅さん/パーソルキャリア株式会社

 

テーマ①:パネラーの分岐点について

f:id:pcads_media:20220218183646j:plain

吉次さん:今日のイベントは、ミイダスの大谷さんがキャリアについてFacebookで投稿しているのをきっかけに企画したのですよね。大谷さんのキャリアの分岐点やきっかけは何だったかお聞かせください。

大谷さん:サイバーエージェントにいたときに、3年ほどプレイヤーとしてものづくりを経験しました。そこでマネージャーにチャレンジしたこともあるのですが、「みんな自分と同じくらいできるものだ」という意識で接してしまい、失敗した経験がありました。

自分はマネージャーではなくプレイヤーが向いているのかと思っていたところ、子会社に出向。そこで、当時社長だった菊池さんからマネジメントの温かさや、マネジメントと管理の違いなど色々なことを教えていただきました。ここで自分も、頑張ればマネジメントができるのだなと思い始め、マネージャーとしてのキャリアもいいなと思うようになりました。

吉次さん:プレイヤーからマネージャーに移る時、プレイングマネージャーみたいなものを経由することも多いと思いますが、どのようなアプローチをしていましたか?

大谷さん:初めの頃は「何日でできる?」「いやそんなにかからないでしょ、1日でやってよ」のようなダメなコミュニケーションをしてしまっていました。そこから、メンバーの立場に立ち、今彼らが持っている知識はどういうもので、このタスクを通してどう成長できるのか、そのためにはどういう時間の使い方をしてもらうのが適切なのかなどを考えるようになりました。短絡的な結果ではなくメンバーが成長することによって組織の力も上がっていくという視点で考えるようになり、これが自分の中のターニングポイントだった気がします。

吉次さん:ありがとうございます。では、岡本さんはどうでしたか?

岡本さん:僕は、サイバードでの経験がターニングポイントでした。先ほど吉次さんがおっしゃったように、僕はプレイングマネージャーを一回経由しているのですが、当時調子に乗っていたのでしょうね。(笑)

各事業部にPLがあるのですがトップラインを達成するためにはボトム(コスト)を合わせるしかないという状況。自分はエンジニアだったので、自分がやりさえすればコストが浮くと考えていました。レベニューシェアでやっているビジネスなので、トップラインが達成できなくてもボトムを合わせれば評価されるのですよね。自分がサイバード初のプレイングマネージャーとしてなんでもやってやろうと思っていました。

しかしある時、自分が開発のボトルネックになってしまいました。出張に行ったり、企画書を書いたりPLを見たり...全く開発に時間を使えない状況。結果的にお客さんにとても迷惑をかけてしまう出来事がありました。

自分が求められることを考えた時に、自分の時間をマネージャーとして使ったほうがいいと決断したのが私のターニングポイントでした。自分のレスポンシビリティをちゃんと理解する、という良いきっかけになりましたね。

久松さん:LIGでいうと、エンジニアがフィリピンに100人、ベトナムに15人、日本人のテクニカルディレクター10人というチームでしたが、得意不得意がわかりやすいチームでした。toBが得意・toCが得意、ドキュメントがないとダメ・なくても大丈夫など、様々なキャラクターの存在する状況でした。本人たちのWill・Can・Mustや志向性、これまでの実績を見ながらチーム編成をするようになりました。

このような考えに至るきっかけを考えると、博士の時に研究していたP2Pの世界が一つのきっかけだったと思います。今だと、例えばYoutubeという確固たるサーバーが並んでいます。この確固たるサーバーによって構成された状態を人に置き換えると、新卒でまっさらな人が一人前になって一人月として捉えられるようになった、というような状態に似ていると思います。一方でP2Pの世界では、受信しながら転送する、PCのスペックの良し悪しやネットワークの良し悪しに左右される、コンテンツの詐称ができる、再構築が必要になるということを繰り返していくのですが、これがまさにベンチャーの人事だなと思いました。

人事領域はあまりシミュレーションできないと思っていたのですが、実は誰よりもシミュレーションをしていたのですよね。重要な人がパッといなくなってしまった時に、次の人を立てるかなども、事前にシミュレーションしておかないと乱れてしまうのでそういう意味でも面白いと思います。

大谷さん:ピンポイントにすごく興味を持ったことがあるのですが、抜けそうな兆候はどうやって見つけていたのですか?

久松さん:P2Pの世界だと「突然いなくなる」可能性は前提として計算に入れるのが一般的でした。今、人材がどんどん流動的になる中で、最終出社の2週間前に連絡してくる、なんてこともよくありますよね。そういう時のために、横軸に繋がりを作って絶えず情報交換をする必要があると思っています。例えば、我々の拠点のあるフィリピンのセブ島は、大きな台風が来てライフラインが切断、発電機を使って仕事をしないといけないような状況になったのです。数日間ブランクが空いてしまうような状況が発生したのですが、セブ島以外に住んでいる人を集めたり日本のメンバーでカバーしたりして、ある意味P2Pのアルゴリズムの応用ができたような経験だった気がします。

吉次さん:ここで質問が来ています。

Q:教えるよりも自分が手を動かしたほうが早い時のジレンマをどうやって乗り越えましたか

f:id:pcads_media:20220218184142j:plain

岡本さん:自分で動かすには限界があります。短期目線でいうとめちゃくちゃ早いかもしれないけれど、中長期的に見ると問題を先送りしているだけなので、いかに中長期目線で考えられるかどうかだと思いますね。

吉次さん:ありがとうございます。大谷さんも、チームメンバーが自分と同じくらいできるものだと思ってしまったジレンマもあったと思うのですが、いかがですか?

大谷さん:チームが成長するという目線で考えるようになりましたね。短期的に、自分が目の前のことを解決するということよりも、支援してあげて、その人ができるようにしてあげることで、チームとして戦力をあげるという方向に意識を変えていきました。

吉次さん:なるほど。長期的に見て、自分以外の組織のキャパシティという視点で見ることが大事そうですね。こんな質問もいただきました

Q:マネジメントの考え方やスキルをどう学びましたか。また、学ぶためにどういう環境が最適なのかの見分け方を教えてください

久松さん:マネジメントにはいくつか種類があります。このうち、プロダクトマネジメントとプロジェクトマネジメントの二つは、お金になります。エンジニアリングマネジメントはお金にならない=営業利益で儲かるという話ではない分野ですよね。

最近noteで「曖昧ロール型雇用の難しさ」という話をしたのですが、エンジニアマネジメントは非常に重要なのですが、組織全体で考えた際、過剰に営業利益や粗利率、売上貢献にこだわりすぎると、余裕がなくなってくることに気がつきました。マネージャーや中間管理職をする上では、粗利に余裕がある企業を選ぶほうがいいのではないかと思っています。

吉次さん:数字を追わないといけない環境だと、マネジメントのスキルを学ぶということに集中できないですよね。

では、次の質問です。

Q:SIerを経験された方に質問です。私も現在SIerをしているのですが、コーディングする機会が全くなく、技術力が身につく未来が全く見えません。SIerでは、マネジメント力が主に身につくかと思いますが、自分で開発できない人間に将来はないでしょうか

大谷さん:私もいわゆる二次受け、三次受けのようなことが多く、上流工程は経験できなかったのですよね。自分で開発できない人間に将来はない、という質問ですが、そんなことないと思います。
例えば、ITの知識がある人が、レガシー産業に行き、最先端の知識ではなくてもITの知識を用いて課題解決するということもあると思いますし、開発ができないから将来がないと過度に悲観する必要はないと思います。

その一方で、最新の技術が目まぐるしく出てくるので、面白い技術の部分を知りながら、裾野を広げていくために自分で勉強していかなければいけないと感じることはすごくあります。手を動かせるほうが、新しい技術への理解を進めやすいので、そういう意味では手を動かせることのメリットも多いのではないかなと思います。

久松さん:マネジメントは見える景色が変わってくるのが面白いなと思います。りんごの木に例えてみます。開発者は、美味しいりんごの実がなるように面倒を見る人です。アウトプットとしてはりんごの実があります。そのりんごの実を、営業側に渡したり、マーケターなどに任せたりして売ってもらうというような形でお金を作っていくのですが、マネジメントは複数のりんごの木がある中でどうやって売り上げを出していくのか、来シーズンの収穫はどうするか、長期的なビジョンで来年も美味しいりんごを作るにはどうすればいいのかなどを考えながら、全体を俯瞰しながらみていくという世界です。全ての木に対して、全てを把握することは難しいと思います。マネージャーの持つ技術力という点においては「概念のキャッチアップ」が重要だと思います。新しい技術の細かいところはメンバーに任せていても、概念を追いかけていくことは大切だと思います。ですので、別のプロセスを立てる感覚で、他の人を育成するというのがいいと思います。

 

テーマ②:マネジメントで見える世界と中間管理職の魅力

f:id:pcads_media:20220218183725j:plain

吉次さん:プレイヤーの立場から見ると調整することが多くて勉強する時間がなくなるというようなネガティブなイメージや、成長イメージがつかめないなど、キャリアとして選びづらいポジションと感じている方もいらっしゃるのではないかと思います。皆さんはいかがでしたか?

久松さん:前提として、フリーランスの人たちが増えていますよね。フリーランスのプロジェクトマネジャーはいるにはいますが、基本的にはメンバーとして稼ぎたい、よく言えばスペシャリスト思考の人が多いと思います。また、出世するより副業した方が稼げるという世界線もある中で、マネージャーの何がおもしろいのかを説明する必要がありますよね。

「自分の給与ってどこからくるの」という話をするととてもわかりやすいと思います。自分の手取りの給料がこれくらいで、そこに社会保険や教育費用など様々なコストが乗ってきて、そのうちの一部が給料だという話をするのです。いわゆるフリーランスや副業をしたいという思考の人は、自分の手取りを最大化したいと思ってフリーランスになる方が多いのですが、手取りを構成するような要素をどれだけ自分でカバーできるか、という問いかけをします。そうすると、やっぱり会社ってすごいね、という着地になりやすい。そこを理解してもらった上で、大きな会社を動かすには中間管理職になっていくしかないよね、という話をすると納得してもらいやすいですね。

岡本さん:僕の場合だと、中間管理職の話をする時は大きな会社やベンチャーを船に例えることが多いです。大きな会社=豪華客船だと、例えば右に曲がりたい時も、航海士や船長など様々なカウンターパートの意思決定が必要で、そこがそれぞれの中間管理職の腕の見せ所のようなイメージです。自分一人ではできないような影響力を持って、産業にレバレッジをきかせるという経験ができる、それがいないと大事故になるかもしれないという状況でパワーを発揮できるというのが中間管理職だと思いますね。

大谷さん:マネージャーのやりがいみたいなところにフォーカスすると、メンバーが成長し、自分が想像もしなかった成果をチームで出してくれるのを見られた時はすごくマネージャーをやって良かったなと思いましたね。

過去に、技術的な課題を解決する方法を考えるところからメンバーにお願いしたことがありました。そうすると、自分が名前を知っているけど触ったことがない仕組みを提案してきてくれたんです。聞いた時は「本当にそれ大丈夫なの?」と思ったのですが、期待値よりも本当に大きな成果を出してくれました。その時に、自分が知っている範囲、自分の経験の中だけで組織の成果を最大化するということは老害化しているのだろうなと思ったんです。もっと、若い力やチャレンジングな部分を伸ばしてあげるほうがいいなと思いました。

久松さん:フリーランスから正社員に転向される方もよく言われるのですが、一人の仕事ってたかがしれているのですよね。そこに対して、数百万、数千万円の大きい仕事や海外人材とのタイアップのチャンスも正社員ならではだと思います。中間管理職になって、大きく動かしている実感がないと抱きづらい魅力だと思いますね。

吉次さん:ありがとうございます。ここで質問が来ています。

Q:マネージャーになると、上からの要求に答えるのに必死になってエンジニアの自由を奪ってしまったり、板挟みになったりするのではないかと思っています。そんな経験はありますか?ある場合はどのように調整しましたか?

これは僕もすごく気になりますね。いかがでしょうか?

久松さん:最近だと、営業職の強い組織のエンジニアチームのプレゼンス改善などの依頼が増えてきました。営業職は売り上げの貢献がすごくわかりやすい一方で、エンジニアってコストセンターだよねと言われることもあります。それに対して、エンジニアの給料を上げるとどうなるとか、エンジニアの視座を上げることがどうなるかを言語化します。マーケターに、この施策を実施するとどれくらい売上が上がるか等を試算してもらった上で、現在の人員での工数見積をセットにして事業部長と施策の優先順位を握りに行くコミュニケーションを取ったりしたことがあります。こうすることで、エンジニアの優秀さがどのように売上貢献してくれるかを理解してもらえるようにしています。共通言語でマネージャーが話に行くというのも大事だと思います。

岡本さん:先程の営業の話でいうと、結局ゴールが一緒で言っていることも同じでも、話すコンテキストが合わないことが多々あります。

コンテキストをどう表現するか、どう握りに行くかをうまく機能させないと、組織はうまくいかないと思います。中間管理職は、組織のケイパビリティがわかっているはずなので、今できる限界を、コンテキストを合わせて伝えることで、わかってもらえたりしますよね。

久松さん:私もnoteで何回か取り上げたのですが、ベイカレント・コンサルティングの方々が書いた「エンジニアがビジネスリーダーをめざすための10の法則」という本があります。共通言語を話すトレーニングはとても役に立つので、ぜひ試してみてほしいです。

大谷さん:要求がきた時に、なんの課題を解決してほしいのだろうということを要求した側と同じ目線で理解するために、視座をあげたり、言語のトレーニングをしたりするのは普段から必要だと思います。自分が腹落ちしない状態でメンバーに話しても、メンバーも絶対腹落ちしないので、適正な要求かどうかも含めてしっかりと要求する側と話すのが大事だと思っていますね。

久松さん:それでいうと私も、この前BizDev研修をやったのですが、Bizの人とDevの人を同じチームにして4時間くらいの研修をやりました。その中で非常に好評だったコンテンツは「一緒に障害報告をしよう」というもの。エンジニアって、障害報告する時に時系列で長々と書いちゃうことが多いのですが、これって経営層からするといらなかったりするのですよね。結論、どれくらい止まっていて、どれくらいビジネスに影響があって、次の発生確率がどの程度で、抜本対応にどのくらいかかるのかがわかれば良いため、それらをエンジニアではない経営層に報告しましょう、というワークをしました。

吉次さん:続いて、こちらも難しい質問ですね。

Q:プロジェクトのマネジメントと、組織のマネジメントの両立が難しいと感じています。転職を考える場合、ポータビリティなスキルとしてどちらに注力したら良いでしょうか?

岡本さん:いくつかケースはあると思うのですが、プロジェクトマネジメントも組織マネジメントも大事で、両方持っていればベストですよね。ただ、向き不向きもあると思います。プロジェクトのプロセスを積み上げて行くのが得意な人は、組織マネジメントで情報の粒感を合わせてくのが苦手なことも...まずは、自分の適性を客観的に周りから聞いてみることもいいと思います。そして、そのスキルを求められている会社に転職したらいいと思います。

久松さん:需要はどちらもありますが、人が好きか、コンピューターが好きか、だと思っています。僕も、インターネットの基盤をずっといじっていたのですが、最終的に人の方がよくわからなくて面白いというところに行き着きました。

やはり、市場にマネージャーがいないので、どこも欲しがっていますよね。今日本のエンジニアが引く手数多な理由は、少子化によって人が減っていることもあると思います。海外人材の供給がされるようになったら、需要は無くなってしまう。プログラミングは海外人材に任せられても、企業がやりたいことを言語化していける人の需要はあると思うので、ここのマネジメントをできるようになるのが生存戦略上良いかと思いますね。

岡本さん:もう少しすると、英語が話せるようなプロジェクトマネジメントや組織マネジメントはめちゃくちゃ重宝しますよね。その国の文化のことを知っているとか、それだけでもすごいアドバンテージだと思います。

>>次のページへ


 

テーマ③:組織を作って行く立場からみて、どんなエンジニアに活躍してもらいたいか。組織づくりの狙いは?

f:id:pcads_media:20220218183944j:plain

吉次さん:ちょうど質問で「中間管理職向きだなと思うエンジニアはどういうエンジニアですか」という質問が来ていますね。エンジニアでいうとどうですか?

久松さん:他人に興味があるかどうか、ではないでしょうか。自分の持ち場だけやればいい、という人はフリーランスに向いていると思います。

岡本さん:組織の規模によっても求められ方は異なりますが、僕の組織でいうと、エンジニアそれぞれが技術を伸ばしていってほしいというのが大前提です。その上で、ユーザーにいいものを早く届けたいという視点を持っていることも大切です。その視点や意識がチーム作りに影響すると思いますし、そういう意識を持っている人には任せやすいし権限委譲もしやすく、信頼関係も生まれやすいですね。

吉次さん:なるほど。大谷さんはいかがですか?エンジニアの組織を作って行く中で、リーダーやマネージャーを育てて行く経験があったと思うのですがどうでしょうか。

大谷さん:ミイダスの組織でいうと、多様な人材を受け入れるような思想でやっています。技術は好きだけど、サービスやユーザーにあまり興味がないという人も活躍してもらっていいと思っています。そんな中で中間管理職をお任せしたい人でいうと、「チームで成果を出していこう、助け合っていこう」という振る舞いをしてくれる人だとか、人のいいところを見つけて褒められる人がいいなと思っています。

久松さん:前向きな提案が最初からできる人って少ないのですが、そのような働き掛け方ができるようになってくると、リーダーとしていいな、と思いますね。

提案って結構エネルギーがいるのですよね。私の後輩も、週4で働きたいからフリーランスになった方がいるんですが、フルタイムで働いている時に比べて、提案するエネルギーが減ってしまったといっていました。これもリーダーシップの素養と逆の話なのですが、提案はエネルギーが必要なのでそれを乗り越えてもやろうと思うというのがリーダーの素養だと思いますね。

大谷さん:何かを変えようと思う提案は、それなりに熱量が必要になりますし、熱量って伝わるので、そこまで熱量を持ってやりたいなら組織もやろうと思いますよね。

吉次さん:ここでも質問を拾っていこうと思います。

Q:会社の規模によっては、マネジメントになるとこれをやる必要があるのか?というような管理系の仕事が増えて行くようなイメージです。パネラーの皆さんがマネージャーになった時に、これ、本当に必要なのかなと思う仕事はどれくらい増えましたか?また、それにどのように向き合ってきましたか?

岡本さん:大量のスプレッドシートに囲まれたりもしますが、仕事をするための仕事も、大事だと思います。それが本当に必要なのかと疑問に思うならば、例えば、GASでスクリプトを書いて自動化するなど、自分でソリューションを提案すれば良いし、役割をどう考えるかをもう一歩踏み込んで捉えるのがいいと思います。マネージャーとしての視座をあげることが必要だと思います。

久松さん:最近、DXコンサルという言葉も流行っていますが、自社で本当に必要なの?という仕事があったりするんですよね。この仕事いらないよね、というのは簡単ですがなんのためにやっているのかとか、こう改善しようとかをコミュニケーションして行くのも管理職の仕事かなと思いますね。

大谷さん:インテリジェンスに一人目の社員として入った時はめちゃくちゃありましたね。面倒くさいやつだと思われたかもしれませんが、結構ガシガシ言いに行きましたね。どこにいったらそれを変えられるのか、改善できるのかなども聞いてアプローチして行きました。

久松さん:相手の立場を思いやりながら提案して行くと結構人って動くんですよね。この仕事って無駄ですよねと否定するのではなく、根気よく目線を合わせながら改善して行くのが良いと思いますね。

吉次さん:立場が違う人同士だと、知らないから無駄になっているけど、知ったらすんなり解決するなんてこともありますよね。

続いて、こんな質問もいただきました。

Q:管理職として長く仕事をしていると、リスクを気にしすぎてしまうバイアスがあると思います。先ほど老害というワードが出ましたが、そのバイアスをどのように意識して取り払っているのでしょうか?

大谷さん:新しい技術に対して、それって本当に今必要か?と思うことが多くありました。しかし、ここ数年反省して、自分であえて新しい環境で作るように意識しています。始めてみると、思ってみたより便利だし工夫次第でスケールするなと実感できるようになりました。新しい技術は、概念として理解するだけでなく、手を動かして便利さを理解することが必要だと気が付きました。

岡本さん:最低限キャッチアップはできるようにします。リスクを気にしすぎてしまうという発言は、技術がおろそかになってしまうのでは、という不安もあると思うのですが、それはキャッチアップすることで精神衛生を保つことができると思います。あとは、マネージャーは役割なので、市場から見ると求められているので、不安に思うことはないと思いますね。

久松さん:若手が新しい仕組みを導入したいと提案した時に、「自社の現状のものでいいじゃん」と潰すマネージャーがいますが、自社の手札を増やすというイメージで追加して行くと、そんなに苦痛じゃないと思うのです。今までの知識でやってきたもので戦えないのではないかと思って保守的になってしまうと手札は増えないです。自社の手札を増やすために新しい技術をやらせてみる、自分も理解する、そして責任を持つという姿勢があれば良いと思います。

Q:エンジニアとしての経営者目線はどう持つべきか悩んでいます。メンバーとしても持つためにはどうしたら良いでしょうか

大谷さん:SIerの時、自分でシステムを作ってネットで公開していたのですね。そうしたら
サイバーエージェントの人から連絡が来て、うちの会社で使いたいと言われました。それまで、自分で見積書を書いて出して、というのをやったことがなかったのでめちゃくちゃ緊張したのですが、その経験からとても視座が上がりました。もし、今の会社の中でできることが限られているのであれば、副業を通して、ベンチャーに参画してみる、仕事を見つけて作って納品することを経験すると経営者目線というのはかなり持てるようになると思います。

岡本さん:商流を理解するというのが大事だと思います。自分の給料がどうやって発生しているのかを理解するためにフリーランスでやってみるのも一つの手ですね。自分が自分を雇った時に、これだけの活躍をしたんだっけ、と自分ゴト化して考えてみるのもいいと思います。

久松さん:顧客に会ってみるのもいいかもしれないですね。お客さんは何を考えているのか、なぜそれを作りたいと思ったか、なぜ自分たちに頼もうと思ったのかなど、意思決定がみられると新しい気づきがあるかと思います。実際に渡しも営業さんと一緒にお客さんのところに行くのはかなり視座を上げるいい経験でした。想定されるシステムがどうやって使われるのかを実際に見に行くのもいいと思います。

 

当日のトークは内容は以上になります◎

今回は、キャリアに迷うエンジニアの皆さんの参考になるお話が盛り沢山だったのではないでしょうか。フリーランスエンジニアが増えるが故、市場にマネージャーがいない状況になっている、というのも興味深かったですね…!
自身のエンジニアとしての市場価値を上げていくために、何を選んでいくのか、どのようなキャリアを築いていくのかの参考になれば幸いです。

次回のイベントレポートもお楽しみに!

【イベントレポート】実務で使えるGAS(Google Apps Script)ライブデモ勉強会vol.2

 

こんにちは!TECH Street編集部です!

今回は2021月11月11日(木)に開催した、 「実務で使えるGAS(Google Apps Script)ライブデモ勉強会vol.2」のイベントレポートお届けいたします。

前回も大好評だったGAS勉強会の第二弾!今回はライブデモ2本立てでお送りいたします。

登壇者はこちらのお二人!(登壇順に記載)

伊藤 勇斗さん/吉積情報株式会社
吉積情報株式会社にて、Google Workspace関連の開発業務に従事。Google Cloud Platformを活用したシステム開発の他、Google Apps ScriptやAppSheet等を用いたアプリケーション開発が得意。

Apachanさん/某通信会社
会社員、●業共に業務改善に関わる活動をされています。SaaS全般、RPA、GAS、VBA、Python、Power Queryなど幅広く活用していて、ここ最近はAsanaやノーコードツールにハマっているそうです。

それでは早速ご紹介してまいります!

 

たくさんあるフォームの回答数を自動収集する君をゼロから作成!

伊藤さんからはGoogleフォームで回収したGoogleスプレッドシートから、定期的に情報を取得する方法をご共有いただきます。 

f:id:pcads_media:20220107104821p:plain

複数のフォームを同時に運用していると情報の管理が煩雑になってしまいますよね…!そんなお悩みも、この方法で解決することができます◎
まずは通常通りGoogleフォームを作成。回答のタブからスプレッドシートを開き、回答が記録されるスプレッドシートを生成します。このフォームとスプレッドシートが複数ある想定で、GASを組んで行きます。

まず準備から。

f:id:pcads_media:20220107104842p:plain

①新規スプレッドシートを作成
②管理したい項目を追加(イベント名や開催日時、受付数など) 

この方法で、情報の一覧シート(今回は「イベント参加確認くん」という名称のスプレッドシートを作成、以下、「情報一覧シート」と記載)を作成しましょう。ただ、これらを毎日手動で更新していくのは大変なので、ここからは、GASを使って自動でシートが更新されるようにコードを書いていきます。

まずはツールから「スクリプトエディタ」を選択します。次に、各Googleフォームの回答スプレッドシートのURLを、情報一覧シートから参照するように設定します。

f:id:pcads_media:20220107104908p:plain

該当のスプレッドシート(情報一覧シート)からスクリプトエディタを開いているので、「getActiveSpreadsheet」と記載すれば、特にURLを指定せずとも、このスプレッドシートを指定しているのだとわかってくれます。また、シートの名前も「getSheetByName( ‘ ’ )で指定することで正確に情報を取得できるようになります。

f:id:pcads_media:20220107105809p:plain

次に、情報一覧シート内の、各フォームのURLを取得します。今回は情報一覧シートのD列に記載されている情報を取得したいので、listSheet.getRrange(‘D2:D’)と記載します。何行目まで該当になるかわからない場合は、(‘D2:D’)のように記載するとD列の2行目以降すべてを該当範囲とすることができます。

次に、指定のURLがきちんと取得できているかを確認してみます。console.logの中にrowListを入れて、実行をしてみましょう。

f:id:pcads_media:20220107105107p:plain

実行してみると、情報一覧シートのD列に記載された必要なURLがきちんと取得されていることがわかります。

ここまででURLを取得する準備ができましたが、ここからは各スプレッドシートのURLごとにその中にある行数(=フォームの回答数)も取得できるようにしていきます。

f:id:pcads_media:20220107105353p:plainまずは、繰り返しの処理を行うためにconsole.log (row)を追加し再度実行。この段階だと、実行ログのURLに[ ] がついていることがわかります。この[ ] は不要なので、配列の0番目だけ取れば良い、という指示を記載し、URLのみを取り出せるようにします。

f:id:pcads_media:20220107105512p:plain

const url = row [0] ; を追加して実行すると、上記のように[ ] はなく、URLのみ取り出せるようになりました。

ここから、各URLのスプレッドシートにアクセスしていきます。

f:id:pcads_media:20220107110014p:plain

SpreadsheetApp.openByUrl(Ur1) . getSheets () [0] ; を追加すると情報一覧シートのD列に記載してある各フォームのスプレッドシートにアクセスし、そのスプレッドシートの一番左のシートにアクセスしてくれます。

f:id:pcads_media:20220107110057p:plain

answerSheet.getLastRowで最後にデータが入っている行の数値を取得します。1行目は回答データではなく回答項目の行になっているので、 -1 することで正しい行数(=フォームの回答数)を取得できるように工夫しましょう。

f:id:pcads_media:20220107110129p:plain

ここで出てきているエラーは、情報一覧シートでURLが記載されていない行があった場合、URLがないのにURLを開くように指示を出しているため発生しています。この場合は「空欄でない場合はURLを開く」という指示を入れればエラーが解消されます。

f:id:pcads_media:20220107110147p:plain

ここまでで①各フォームの回答スプレッドシートのURLを取得する②取得したURLにアクセスし、スプレッドシートの行数(=フォームの回答数)を取得するところまで完成です。この後は、情報一覧シートの受付数に、スプレッドシートの行数(=フォームの回答数)を更新するようにプログラムを組んでいきます。

f:id:pcads_media:20220107110211p:plain

スプレッドシートへの書き込み処理は上記のように記載します。C列2行目以降に記載したい内容をlistSheet.getRange (‘C2:C’),setValues(を使って [ ] で指定すると、スプレッドシートのC列に指定した数字が反映されます。

f:id:pcads_media:20220107110256p:plain

f:id:pcads_media:20220107110358p:plain

この[ ] の数字が先ほど取得した各フォームの回答スプレッドシートの行数数値になれば良いので、push関数を使って配列に数値を入れるように記載します。加えて今回は、数値があれば数字を記載する、なければ0と記載する(answeList.push( [0] )、というような指示も追加で記載します。

f:id:pcads_media:20220107110419p:plain

これで、手動で更新せずともプログラムが実行されれば受付数が自動で反映されるようになりました。

最後に、プログラムの実行を定期的に行えるように設定します。

スクリプトエディタからトリガーを開き、実行する関数を選択します。イベントのソースは時間主導型を選択し、1時間おきに情報を取得するように設定して保存します。

この設定をしておくと自動で1時間おきにプログラムを実行してくれるようになります。

f:id:pcads_media:20220107110511p:plain

これだけでなく、スプレッドシートを誰かが開いた時にプログラムが実行される関数も追加することで、

f:id:pcads_media:20220107110539p:plain

スプレッドシートに「スクリプトメニュー」が追加されて、手動でリアルタイムの数値がわかるようにすることもできます。

参加者からは「伊藤さんの仕組み色々応用できそうですね!」というコメントも!完全初心者でも、この流れの通りで実行すればGASのプログラムを作ることができます。ぜひ、お試ししてみてください◎

続いて、Apachanさんからの発表です。

 

ライブラリを活用してGAS利用者を増やそう!

今回のテーマはライブラリ。

f:id:pcads_media:20220106185253p:plain

ライブラリとは、作成した関数を他プロジェクトから利用できる仕組みのことです。ライブラリ登録をしておけばどんなに複雑な処理も1行で呼び出すことが可能に◎

例えばGASを使って休日(土日祝+会社の祝日)の判定をしたい場合。

f:id:pcads_media:20220106185329p:plain

通常であれば左側のコードを書かなければなりませんが、ライブラリを利用するとたった1行で完結することができます。IT初心者であってもこれくらいならできるのでは!と思わせられるような簡潔さですよね。

それでは早速、ライブラリについての前提知識をインプットしましょう。

f:id:pcads_media:20220106190250p:plain

基本的にはライブラリを識別するためにはLibraryという識別子がisBusinessDayのメソッドを呼び出しtodayの引数に指定されたものを入れるとなんらかのresult(戻り値)が出てくるような形になります。

ライブラリは、毎月利用者が増えているのだとか…!ライブラリをマスターすればより快適なGAS生活を送れそうですね◎

f:id:pcads_media:20220106190315p:plain

案件があるたびに、汎用性の高い処理を少しずつライブラリに登録していき、現在は50処理がライブラリに登録されているのだそうです!

実際に書いたコードをライブラリに登録する様子も、デモでご紹介いただきました。

f:id:pcads_media:20220106190336p:plain

今回のデモはスプレッドシートで管理しているシフトのデータが毎朝Slackに投稿されるようなプログラムを作成します。

f:id:pcads_media:20220106190752j:plain

まずは、上記のように管理されているシフトをプログラムで情報が取りやすいように加工します。

f:id:pcads_media:20220107151845p:plain

シフトシートの他に、配信用の別シートを作成し、today関数とHLOOKUPで今日のデータを抽出します。この「配信用」の情報を取得してSlackに流すようにプログラムを組んでいきます。

(メンバーリストには11月11日生まれの芸能人が並んでいることに気づき、ちょっとくすりw)

f:id:pcads_media:20220107103543p:plain

はじめに、拡張機能から「Apps Script」を開きます。

f:id:pcads_media:20220107103558p:plain

スプレッドシートの操作の際にはgetActiveSpreadsheetを使用してスプレッドシートを指定、getSheetByNameでシートの名称(今回の場合は「配信用」)を指定します。そしてgetDateRangeを使って値の入っている部分のデータだけ取り出せるようにし、getValuesで複数のセルを指定します。

ここで一旦ログを取ってみましょう。

f:id:pcads_media:20220107103638p:plain

プログラムを実行すると上記のようなデータが取り出せました。この状態だと、日付の部分の数字が長くなっていますね。この場合は、getValuesをgetDisplayValuesに変更してあげましょう。

f:id:pcads_media:20220107104013p:plain
そうすると、上記のように11月11日とシンプルな表示に変更することができます。続きまして[ ] を外して、1行ずつデータを取得できるようにしていきます。

f:id:pcads_media:20220107104050p:plain

ここではfor文を使い record of recordsで1行ずつのデータを取り出せるように指定します。ここでも一旦実行して、きちんと記載できているか確認しましょう。

f:id:pcads_media:20220107104148p:plain

続いて、hakoを使って配列の状態だったものをみやすい文字列に変換していきます。ここまで準備ができたら、このデータをSlackに送れるように連携していきます。

f:id:pcads_media:20220107104215p:plain

投稿するのでmethodはpost、contentTypeはapplication/jsonと記載します。payloadの記載はSlackの指定によるものなのだとか。事前に連携ツールの規定はチェックする必要がありますね。

f:id:pcads_media:20220107104241p:plain

これで実行してみると、外部ツールへの権限認証のポップアップが表示されますが、これを許可して実行します。

f:id:pcads_media:20220107104304p:plain

すると、Slackに連携されて当日のシフトを送るスクリプトが完成しました。ここでもトリガーを時間で設定すれば、毎日決まった時間にSlackに通知されるようになります。

デモはここで終わりではありません…!ここからは、初心者には少しハードルが高いこのスクリプトを、ライブラリを使って簡単に使えるようにします。

f:id:pcads_media:20220107104333p:plain

今回は二次元配列を文字列に変換するプログラムと、Slackにメッセージを投稿するプログラムを、ライブラリを用いて実装します。手始めに、プロジェクトの設定からスクリプトのIDをコピーします。

f:id:pcads_media:20220107104429p:plain

そして、ライブラリの追加でスクリプトIDを記入し、検索、追加。これでライブラリは使えるようになります。

f:id:pcads_media:20220107104450p:plain

二次元配列を文字列に変換する指示は、text = TECHStreet . change2dArrayToStr ( records ) ; の1行だけで完了しました!(ここのTECHStreetは保存したスクリプトの名称で、変更することができます)

f:id:pcads_media:20220107104515p:plain

続いて、Slackにメッセージを送る指示は、TECHStreet.sendSlackMsgの1行のみで完結。非常に簡潔になりました。

このようにライブラリを用いると、「自分でもできるかも」と思える簡潔さでGASに取り組むことができます。このライブラリのおかげで、GASにチャレンジする人も増えてきたのだとか!GASに興味があるけどまだ試したことがない…という方はまずはライブラリを使って第一歩を踏み出してみるのもオススメです◎

 

まとめ

イベントレポートは以上になります。「GASってなんとなくハードルが高いのでは」…と思っていた方も多いかと思いますが、本日紹介したライブデモで、まずは一歩踏み出してみませんか◎ぜひ、感想もTwitterで #テックストリート などでシェアしてくださいね。

続いて当日のQ&Aを紹介します♬

参加者からのご質問

(Q)このまえのGoogle Cloud Next の最新情報とか聞きたいです(GAS関連)

伊藤さん:なかったような気がします…
Apachanさん:一部サービスの名称が変わったのは気づいていましたが…最近社畜気味なので追えていません。

(Q)GASでシステム作った時の一番良い点とイマイチな点、聞いてみたいです。

伊藤さん:1番良い点は、思い立ったらすぐにブラウザで作れるところ。イマイチな点は、規模が大きくなると管理が大変になってしまうところですね。
Apachanさん:予想外の広がりがあった時は、社内で受けたときが嬉しいです。
期待値が上がっていって、もっと大規模で運用したいと言われたときにそれはGASでは・・・となってしまうのがイマイチといった点です。

(Q)たしかに、Googleフォーム貯まっていきますね、、 ちなみにGoogleフォームで取得した回答データとGoogle以外で取得した回答データをあわせて統合することもできますか? Googleフォーム以外で取得した回答データはどこかのスプレッドシートに管理すればいけるかな。。

Apachanさん:Googleフォーム以外で取得した回答データはどこかのスプレッドシートに管理すればいけると思います。
伊藤さん:フォームと連携しているように見せかけて、スプレッドシートと連携しているだけなので、スプレッドシートさえあれば割と何でも使えると思います。

(Q)業務で一番活用されるのはやっぱスプレッドシートですかね?他におすすめ活用ってありますか?導入したいのだよなぁ。

伊藤さん:スプレッドシートがほとんどです。これが便利すぎるというのが理由です。ただ、誰でもいじれてしまうのでスプレッドシートをベースにしながらも、データポータルで表示して閲覧専用の画面を用意するという方法をとったりするとデータ改ざんの防止という点で良いかもです。
Apachanさん:基本的にはスプレッドシートが軸足になって、メール内容を収集したり、チャットツールに通知したりという作りをしていきます。なので、スプレッドシートをまずは抑えておけば良いかと思います

(Q)なるほど、ノーコードではないのですね。実は初めて見ました。エンジニアじゃなくても扱えますか?完全にIT初心者でも。

伊藤さん:今日の内容に関しては全く同じ操作をしてもらえれば作ることができます。しかし、実際に自分で作るとなるといつもと違う作業になるので、つまずくことはあると思います。ただ、ブラウザ上でできるという点でコードを書いて実行という流れがやりやすいです。ここのハードルが下がるという意味では、初心者でも入りやすいと思います。

(Q)今回のプログラムコード、コピペできるような状態でもらえたりしますか? 自分でも試してみたいですm(_ _)m

伊藤さん:スライドを共有するのでそこからコピー&ペーストできます。

(Q)変数とかって命名規約あるのですか?すみません、初心者なもので。

伊藤さん:大体こうするというのが分かってある程度のルールがあれば問題ないと思います。
Apachanさん:開発現場によって違いますが、基本的にはキャメル形式が採用されます。

(Q)初めて見るのですが、すごく勉強になります。文法はある程度覚えるしかないですね。でも楽しそうなのでやってみます。講師様はエンジニア職でしたでしょうか?

伊藤さん:エンジニアです。
Apachanさん:元々は10年くらい家電量販店で営業職をしていました。

(Q)APIは簡単に扱えるのですね。なにか気を付けるべき点ってありますでしょうか?

伊藤さん:API側の規約をしっかり見た方がいいです。間違いやすい点もあるので、実行する前にしっかりと確認しましょう。
Apachanさん:トラブルにならないように利用するAPIのドキュメントは確認することや、リクエスト間隔を2秒ほどあけるなど…いっぱいあります。

(Q)社内講師なのですか?どこで情報仕入れたり勉強されたりしていますか?

伊藤さん:会社として案件があるときもあるし、自分で作っているときにやりたいことを調べて学んでいくことが多いです。やりたいことベースです。ひと息ついてから本を読んで網羅的に勉強しました。
Apachanさん:connpass で興味あるイベントに参加したり、YouTubeで良いコンテンツを見たり、Udemyでコンテンツを購入したりしています。

(Q)ライブラリの公開はどのように行っているのでしょうか?

Apachanさん:デプロイっていうところからやります。[画面表示での説明あり]

(Q)Slack以外でも簡単に行けますか?事例もありますか?

伊藤さん:FreeeやSalesforceなど会社で使っているサービスもAPIが結構あります。ただ、ポリシーで使えるかどうかはまた別問題ですが…。その辺の連携を使って何か作ってみるのはいいかもしれないです。
Apachanさん:何に依存しているかによりますが、LINEやTwitterも連携できます。ある程度APIが提供されているものであればできます。

今回のイベントレポートは以上となります。次回のイベントもお楽しみに!

【イベントレポート】Javaエンジニア勉強会 ~Java最新トピックスと活用ユーザーLT~

 

こんにちは!TECH Street編集部です!

今回は2021月11月4日(木)に開催した、 「Javaエンジニア勉強会~Java最新トピックスと活用ユーザーLT~」のイベントレポートお届けいたします。

前回も大好評だったJavaエンジニア勉強会の第2弾!ITエンジニアの保有スキルランキング第1位(※)のプログラミング言語「Java」についてJavaチャンピオンとJava活用ユーザーが集まり、最新トレンド共有や活用事例を語る勉強会イベントを開催いたしました!

登壇者はこちらのお二人!(登壇順に記載)

Hayateさん/パーソルキャリア株式会社
パーソルキャリアでコンサルを経験して昨年エンジニアの道へ!
前職は電機メーカーでオフラインソフトウェア設計開発に従事。

寺田 佳央さん/マイクロソフト・コーポレーション
2016 年 7月、日本人で 2人目となる Java Champion に就任。2018年7月より、マイクロソフト・コーポレーションで日本人初のクラウド・アドボケイトとして活動を開始。

それでは早速ご紹介してまいります!


エンジニア勉強会-Webアプリ、Spring Framework-

Hayateさんは、Javaを学び始めて1年!今回は社内で行われている内製エンジニアによる勉強会の事例をご共有いただきました。

社内勉強会の始まり

f:id:pcads_media:20211220145411j:plain

パーソルキャリア社内での勉強会は「Webアプリ勉強会」としてスタート。Webアプリの基本やフレームワーク、Webセキュリティのような一般的な内容はもちろんのこと、dodaを開発する上で配慮すべきポイントも抑えたコンテンツが含まれていて、エンジニアだけでなく、ディレクターなど、誰でも参加できるスタイルの勉強会から始まったそうです。

Spring Frameworkの導入

Spring Framework導入のきっかけは、dodaで使用されるフレームワークがSpring Frameworkに刷新されたことでした。

開発のベースとなるフレームワークが変わることで、当然実装のお作法も変わってくることから、正しいお作法を押さえ、開発効率をあげられるようにすることを目的にエンジニア向けの勉強会をスタートしました。

この勉強会は、初期の勉強会とは異なり、下記のテーマ別に各担当者が「調べ」「発表し」「教えあう」構成としました。

・Spring概要、Springbootについて
・MVC(Annotated Controller、Request Mapping、Handler Methods)
・Validation
・MVC Exceptions、MVC Config
・AOP
・Junit5、Mockito

このように、ほとんどのテーマで実演パートがあり、テーマによってはdodaにおける使われ方の事例も紹介し、相互理解を深められるように工夫したのだとか。

AOPについて

勉強会内容の一例として、Hayateさんが取り組んだAOPパートの詳細をご共有いただきました。

AOPとは、Aspect Oriented Programming(アスペクト指向プログラミング)の略称。コンピュータプログラムの特定の振る舞いを「アスペクト」と呼ばれる昨日単位として分離して記述し、プログラム中の様々な対象に適用できるようにする手法です。

この、AOPを使うと、オブジェクト指向ではできないオブジェクト内に散財した機能をひとまとめにすることができます。

例えば、ログ出力について。
横断的な書き方をすると、品質欲求自体は満たすことができてもプログラム全体の見通しが悪く、開発効率や保守性が低下する恐れがあります。

f:id:pcads_media:20211220145515p:plain

このような場合、アスペクトを使うと、アスペクトが横断的なコードをまとめてくれているので、モジュールごとに見に行かずともログ出力ができるようになります。

勉強会ではSpring AOPを用いてコンソール上で任意のメソッド実行前後にメッセージを出力するという実演も行いました。方法は以下の通り。

①pom.xmlにAPOライブラリーを追加
<dependency>タグを追加することでAOP関連のライブラリが使用可能となります。

②AOPを利用するBeanクラスを作成(AopBean.java)

f:id:pcads_media:20211220145558p:plain

③AOPを挿入するクラスを作成(Method Advice.java)

f:id:pcads_media:20211220145653j:plain

f:id:pcads_media:20211220145842j:plain

④AOP用のbean.xmlを作成(beanAop.xml)

f:id:pcads_media:20211220145930j:plain

⑤Mainクラスを作成(Main.java)

f:id:pcads_media:20211220150002p:plain

この①〜⑤までを実行すると、下記のような結果で出力されます。

f:id:pcads_media:20211220150238j:plain

また、アノテーションを使用してさらに簡略化することもできます。まずは、pom.xmlにaspectjライブラリーを追加し、Aspectクラスを作成。

f:id:pcads_media:20211220150341p:plain

次に、PointCutを設定します。

f:id:pcads_media:20211220150429j:plain

以上を踏まえてAdviceを作成し、PointCutを記載してみると上記のようになります。これで、全てのメソッドで発生した例外に対する例外処理を定義することができます。

このような内容でAOPに関する勉強会を開催したそうです。勉強会では人に説明できるくらい自分が詳しくなる必要があるため、理解を深めることができたのだとか。

まとめ

開発チームには勉強会文化が根付いており、勉強会は頻繁に行われていますが、特に実際に手を動かし触りながら学ぶことや、教えあうことの重要性を感じたそうです。

上記のAOPの内容も、自分が調べて理解し、他のメンバーに教えた内容とのことですが、このようにメンバー一人一人が発表者になることで、受け身の勉強会から脱却することができます。

また、「dodaではこうやって使われている」など実業務との関連性を意識して勉強会を行うのもポイント。

皆さまも社内勉強会を実施される際は、「メンバー同士で教えあう」「実業務と関連づける」といったポイントをぜひ意識してみてください◎

 

最新の Java 動向とクラウド環境における Java の利用について

今回は、Java SE 9 から先日リリースされた Java 17 の新機能の概要及び、クラウド環境で Java を活用する際の便利なツール群を、リアルホワイトボードを使ったご説明や、デモを交えながら紹介いただきました!

f:id:pcads_media:20211220150534j:plain

まずはJavaのマスコットキャラクターDukeのご紹介!絶対覚えて帰ってほしいとのことでした◎

Java17の新機能概要

Java9以降、Javaのバージョンアップが頻繁に行われるようになりました。特に言語に関するアップデートについてはこちらを参照してほしいとのこと。以前よりもより使いやすく、楽にかけるようになっています。

また、Java17までのアップデートの詳細が知りたい場合は寺田さんのGitHub上のこちら。細かなアップデート情報がまとめられています。アップデートの中からVariable Handlesをピックアップしてご紹介いたします。

Variable Handlesについて

Java 9 で Variable Handles と呼ばれる新しい API が追加されました。これは Java 7 の MethodHandle を拡張し、クラス java.lang.invoke.VarHandle でフィールドの変数や配列に対して強い型付けを持って参照ができます。ただし変数の参照だけでなく、Atomic 操作やリフレクションなどの操作に利用可能です。(引用:JEP 193: Variable Handles について

このVariable Handlesは、全ての方にとって必要なものではないですが、ハイパフォーマンスを求められるようなプロダクトを作っている場合には活用できるもの。もし、ライブラリーやフレームを作っている方がいれば、この知識をきちんと持っておいた方が良いとのこと。特に、sun.misc.Unsafeが使えなくなり、これに置き換えるためのクラスという位置づけとなることに注意が必要です。

Enterprise

ここからは、Cloud環境においてJavaをどのように使っていくのかをデモを通してご紹介していきます。

ここでまず重要になるのはフレームワークの選択。下記のような様々なフレームワークが用意されています。

・Spring Boot (非常に多く使われている)
・Microprofile系(旧JavaEEの陣営)
・Quarkus
・OpenLiberty
・Payara
・Helidon

また、統合開発環境も下記のように様々。

・IntelliJ IDEA (JetBrains)
・Eclipse(Eclipse Foundation)
・NetBeans(Apache)
・VSCode(Microsoft)
・GidHub Codespaces(Microsoft)

今回はVSCodeを用いてデモを行います。このほかにもCI/CD環境や実行環境においても様々な選択肢があります。

f:id:pcads_media:20211220150822j:plain

実行環境についてはリアルホワイトボードを使用してご説明いただきました!

・IaaS
物理サーバーの上に仮想環境があり、その上にOS、JDKやTomcatのようなランタイムがありその上にアプリケーションを作ってデプロイする構成となります。今までオンプレミスで作っていたものをクラウドに持っていきたいというシチュエーションではIaaSを使うことができます。

・PaaS
構成はIaaSと似た物理サーバーの上に仮想環境があり、その上にOS、JDKやTomcatのようなランタイムがありその上にアプリケーションを作ってデプロイします。これらすべてをプロバイダがカバーするもののこと。

・Container
サーバーレスで使うことができるContainer Instanceと、Container Apps(*11月2日プレビュー版リリース)、PaaSで使うことができるApp Service Container、Kubernetes Serviceなどがあります。

・その他
Azure Spring CloudはSpringの開発者専用のソフトとしてマイクロソフトがリリースしました。

キーワードはKubernetes Service。これらすべてがKubernetes Serviceに関連しています。

デモ:Spring Initializr

f:id:pcads_media:20211220152413p:plain

このサイトでは、JavaのSpringプロジェクトを簡単に作ることができます。必要事項を記載してGENERATEを押下するとコードが作成されます。

f:id:pcads_media:20211220151640j:plain

上記はJavaの基本的なコード。これを書いた後に > mvn clean package コマンドでソースコードをビルドし、テストコードをテストして成果物ができます。次に > mvn spring-boot:run コマンドを実行すると今作った成果物が動かせるようになります。

f:id:pcads_media:20211220152535j:plain

GitHubのprivate repositoryにソースコードをアップデートすることもできます。ここからは、GitHubのCodespacesを使った便利なTipsをご紹介。

f:id:pcads_media:20211220152634j:plain

GidHub Codespacesを使うと、ブラウザ上でそのままコードを書けるようになります。これを使えば、たとえば急に出先で何かの作業をしなければいけない!となってしまった時に便利。

さらにこちらは、ただブラウザで開発できるようになっただけではありません。

f:id:pcads_media:20211220152725j:plain

ローカルで編集したコード内容がブラウザにも自動リアルタイムで反映されます。この機能を使うとリアルタイムでコードを共有しながら開発ができるようになります。

続いて、これをPaaS環境に持っていきます。

f:id:pcads_media:20211220152816j:plain

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.2.0:config を叩くと、Azure上にデプロイをするためのいくつかの項目が聞かれるようになります。

f:id:pcads_media:20211220152906j:plain

このコマンドを叩くとpom.xmlにAzure にデプロイするための設定項目が追加されます。どこに、どういう名前でインストールするかなどをカスタマイズし、実行。そして、mvn clean package, mvn azure-webapp:deploy のコマンドを入力すると自動的にAzureの環境上にデプロイされます。

また、CI/CDの場合は、GitHub Actionsを活用できます。
GitHubの管理画面 Setting の中から Secret を選択、ここにアクセスするための機密情報を記載し、GitHubのworkflowを作成、yamlファイルを作成して実行したいもののイメージを作ります。

f:id:pcads_media:20211220152955j:plain

この中に記載されているaz containerapp updateは、先日リリース先日リリースされたばかりのAzure Container Appsの中にデプロイされています。

f:id:pcads_media:20211220153059j:plain

このContainer Appsにおいては、CI/CDの設定を行うことや、Revision管理の項目では古いバージョン、新しいバージョンを選んで管理することもできます。また、シークレット情報やIngressを使うことも◎

このようにGitHub Actionsを使うことで、GitHubにソースコードをプッシュするとビルドし、デプロイするというところまでをすべて自動化させることができるようになります。

寺田さんは、自分たちにとって何が重要でどのツールを使うことが最適なのかを考えながら、ツールを選んでいってほしいと締めくくりました。

 

まとめ

今回は、新人エンジニアによる勉強会事例のご共有やJavaの最新トレンドをご紹介いただきました!

次のページでは、当日のQ&Aを紹介します◎

>>次のページへ


 

参加者からHayateさんへのご質問

“(Q)こんな質問、お門違いならごめんなさい。エンジニアになりたてでまだ実はJavaできません。何から手を付けるべきか、学んでいく上でのポイントなどもご教授いただけますと幸いです。”
Hayateさん:実際に私が壁にぶち当たったのは、その質問でした。本を読んでも実業務に即活かせるっていうわけではなかった。オンラインで受講できるテックキャンプ等に参加して実際に手を動かして誰かにレビューもらえた経験がよかったと思いました。

“(Q)勉強会の仕組みは外部講師ですか?内製ですか?”
Hayateさん:内製です。みんなで持ち寄って勉強しました。

“(Q)開発しているのは社内システムですか?”
Hayateさん:toC向けのシステムで、dodaというサービスになります。

“(Q)どのくらいの人数規模感で勉強会開催されたのでしょうか? 勉強会が頻繁に開催される文化すごいです。うちはなかなか長続きしない・・・”
Hayateさん:規模的には10人程度です。ほぼ全員参加という感じです。ちょうどいい規模感だと感じています。前職でも勉強会主導していた方がリードしてくれました。

 

参加者から寺田さんへのご質問

“(Q)寺田さんはどこで情報収集していますか?”
寺田さん:ネット上が基本で、特に私は海外からの情報が主です。開発フレームワークやツール関連であれば、その Web サイトから直接情報を仕入れますし、また海外のJava チャンピオンからの情報なども見ています。Twitter なども見ています。

“(Q)おすすめのJDKディストリビューションを教えて欲しいです。 各ディストリビューションの違い等も。”
寺田さん:会社的にいうと、Microsoftです(笑)
実際には、どこで動かすかによって変わってきます。開発で使うのであれば、無料で使えるものを使ってもいいと思う。本番環境で使うときは「サポート」という視点からしっかり吟味すべき。

“(Q)せっかくならAzureの話も聞きたい。Igniteが熱いし。笑”
寺田さん:今日Azureの話もしました。時間があれば最近リリースした機能を使ってデモで披露したかったのですが、時間が足りませんでした…。またの機会に!

“(Q)ウチ5年位全然更新していないのですよね。まずいでしょうか?”
寺田さん:もしそれが社内システムで外部からのアクセスがそんなにないのであればそのまま放っておいてもいいかもしれません。一方で、外部に公開しているサービスである場合は絶対に変えた方がいいです。セキュリティの脆弱性に関わることになるので、大きなトラブルのもとになる可能性は高いです。

“(Q)エンジニア2年目です。こういった勉強会はじめてです。CI/CD、Jenkinsしか知らないのですが(社内でそれつかっていた)、他オススメありますか?>寺田様。そしてパーソルさんは何使っていますか?”
寺田さん:GitHub Actions もそうですし、CircleCI など最近は色々なものがありますので、会社で使いやすいものを使ってみてください。

Hayateさん:私もJenkinsが主流です。

“(Q)すごく個人的な質問なのですが、寺田さん開発機ってどんなPCなのか気になる。”
寺田さん:昔は Solaris とか Linux を使っていました。今現在は Mac Book Pro 16 inch を使っています。UNIX 系 OS が好きです。

“(Q)マイクロソフトでMac?!自前PC?”
寺田さん:会社で購入しています。目の前にMacが3台あります。Windowsのことほとんど知りません!(笑)

“(Q)MavenとGradleとAnt、寺田さん的評価?を聞いてみたいです。”
寺田さん:これは宗教戦争になります・・・(笑)これも本当に好みです!

“(Q)Webでペアプロ最高ですよね。やっています。さっきおっしゃっていましたが、寺田さんも今でも実際にやる事ありますか?”
寺田さん:今ピン芸人的な活動をしているので、人と一緒にコードを書く機会はあまりありません。お客様と PoC をするときはペアプロ・モブプロをすることがあります。

“(Q)Duke は何をモチーフに作られたのでしょうか?”
寺田さん:Java の生まれた歴史になりますが、Java は元々組み込み機器用、今でいう IoT デバイス用の開発言語として作られました。そして、最初のデモ用の組み込み機器 (Start7という名前) の画面のヘルプツールとしてできたのが Duke でした。後に Java のマスコットキャラクターになりました。

“(Q)Azure DevOpsとGitHub Actionsだったらどちらがおすすめでしょうか? ランナーはセルフホステッドにする予定です。”
寺田さん:場合にもよるので一概には申し上げにくいのですが、最近は GitHub Actions で実施される方が増えてきています。

“(Q)FWの使い方を学ぶには、最終的にはAPIDocを見るしかないのでしょうか。 なにかお勧めの学び方とかありましたらご教授下さい。”
寺田さん:そうですね、基本的には API Document を見て学ぶことが多いのですが、フレームワークの使い方を学ぶ場合は、フレームワーク側で用意されているドキュメントやサンプル・コードを見て、動きを確認します。

“(Q) Javaは今後、将来性があると思いますか?Microsoftに行かれたのは、何か思うことがあったのでしょうか?”
寺田さん:Javaは今でも大好きですし、将来性もあると思います。世界的な Java コミュニティもとても盛り上がっています。Javaを盛り上げていこうという想いを持っている方がいっぱいいるので、今後すぐに廃れるってことはないと思います。マイクロソフトに移ったのは、タイミングが大きく影響しています。Java の 20周年のイベントを無事終了したのと、そしてマイクロソフトが新しい道を切り開こうとしているタイミングが重なり、新しい道で何かできるのではないかと考えるようになりました。所属当時一緒に活動をしていた元同僚は皆素晴らしい方々ばかりでしたので離れるのは寂しい気持ちもありました。

イベントレポートは以上となります。次回のイベントもお楽しみに!

【イベントレポート】エンジニアの秋の自由研究発表会

 

こんにちは!TECH Street編集部です!

今回は2021年9月16日(木)に開催した、 「エンジニアの秋の自由研究発表会」のイベントレポートお届けいたします。大好評のエンジニアによる、エンジニアのための自由研究発表会第4弾!業務外でITエンジニアが個人的に本気で取り組んだ内容をご紹介いただきました。

登壇者はこちらの皆様。(登壇順に記載)

とは(towa)さん
発明家の小栗さん
ニッチほそかわさん
ななみんさん
木戸 康平さん

それでは、早速ご紹介させていただきます!

 

「転生したらスマートスピーカーだった件」/とは(towa)さん

最新技術やガジェットが好きなバーチャルマーケターとは(towa)さん。前回の自由研究イベントでは、家を建てるために必要な情報を管理するDXアプリを制作したお話をしていただきましたが、今回は家を買った後の新生活を管理するbotを作ってみた!というテーマで発表いただきした◎

通常のスマートスピーカーの機能といえば、音楽をかける、天気を調べるなど・・・これだけでは物足りなくなったとはさん。今回のテーマは、人間の意思決定のほとんどはルーティン化できると気づき、スマートハウス化を進めたいと思うようになったことがきっかけだそう。

そこで、まずはルーティンを作ることから始めます。実は、ケンブリッジ大学のBarbara Sahakian教授の研究によると、人間は1日に約35,000回決断をしているそうです。さらに、それらの決断は自由意志で決める前に、脳は自動的に何かの判断を下しているのだとか。自分が考えて何かをしていることは、ほとんどがルーティン化できる決断の繰り返しなのだそうです。

f:id:pcads_media:20211117152720p:plain

今回はGoogleフォームのアプリを使いルーティンを作成します。こちらは下記5つの手順で簡単に作成することができます。

①要件を整理
②トリガーを設定
③アクションを設定
④テスト
⑤完了

例えば、朝起きて「おはよう」というとスマートスピーカーからニュースや天気を読み上げてくれるなど、日々繰り返しおこなっていることをルーティンとして作成していきます。

次に、チート能力を実装します。IoT家電やデバイスを連携させDialogflowを使ってできることをどんどん増やしていきます。

f:id:pcads_media:20211117152833p:plain

Dialogflowを使うと下記流れで、ノーコードでチャットボットを実装することができます。

プロジェクトを作成する

どんなトリガーで呼び出すことができるかを指示するInvocationを作成

その後はどんどんActionを追加

テストして動作確認できれば完了

f:id:pcads_media:20211117153605p:plain

Actionは様々な種類があり、テンプレートを使って簡単に実装することができます。

f:id:pcads_media:20211117153647p:plain

とはさんはこれを使って自動応答するインターホンを作成。訪問販売の方が来た時に自動で応答してくれています。Dialogflowで作っているのでLINEやSlackに通知するなどの拡張も実施することができます◎

その他にも、Google Nest Hub MaxやIFTTTを使うとさらに拡張の幅を広げることができます。

まとめ

f:id:pcads_media:20211117153726p:plain

今回のスマートスピーカーの効能により、下記のような良いことがありました。

・ルーティンで意思決定の負担減
・話し相手ができたみたいでふれあい増
・忘れ物が減る
・時間見てなくてもスケジュール守れる
・自動化されて時間に余裕ができる
・音楽のある生活で優雅な気分になる
・行動範囲が狭いままでも偶発的な気づきが得られる
・笑いが増える

本当に簡単に作ることができるので、ぜひ試して欲しいとのこと!とはさんからは、非エンジニアでも作れる!をテーマにお話しいただきましたが、挑戦のハードルも低くチャレンジしやすそうですね。ぜひみなさまお試しください◎

 

「UIが自由に作れるUIクリエーターって何よ?」/発明家の小栗さん

ロボットやゲームなど様々なものを発明されてきた小栗さん。今回はUIが自由に作れるUIクリエーターについてお話をいただきました!

f:id:pcads_media:20211117153821j:plain

小栗さんは、過去にトーキングエイド(携帯用会話補助装置)の開発に携わった経験をもとに、今回の研究をされたそうです。

f:id:pcads_media:20211117153906j:plain

小栗さんは、体を動かすことや言葉を発することができない方が、トーキングエイドやオートスキャン、そして呼気センサーを使って、コミュニケーションができるようになった姿に立ち会ったご経験があるそうです。

障がいの度合いや必要とする機能も様々はありますが、UIをうまく使うことで、障がいを持つ方のコミュニケーションを手助けするツールを作ることができます。

今回開発されたUIクリエーターは、PCを操作する新しいUIを誰でも作ることができるガジェット。

f:id:pcads_media:20211117153931p:plain

キーボードやマウスやゲームパットで使える操作内容を、UIクリエーターで操作できるようにしました。こちらは、光、画像認識、振動、音声認識、におい、人感、動態、時間、温度、色、電波、湿度、煙、磁気、スマートスピーカー、AIなど様々な外部センターやスイッチにより操作できるのだそうです。

今回はブラウザからブロックを積むだけのノーコードでこちらのRPAボタンを作成。

f:id:pcads_media:20211117154016p:plain

ハードの構成はこのような形に。

f:id:pcads_media:20211117154032p:plain

このUIクリエーターは下記のような様々な使い道があります。

・通常のRPA/RBAと同じような使い方
・アプリのコンソールボタン
・障がいをもつ方がPCを使える
・PCの苦手な人でもPCを使える
・多人数でのPC利用
・キッティング
・PCのI/O
・いたずら、スパイ活動

現在、小栗さんはこちらの製品化を進める準備をはじめているそう…!今後の開発にさらに期待が膨らみます◎

 

「本当にわらっている?笑顔判定カメラを作った」/ニッチほそかわさん

無人島生活をしてみたりニッチな人を見つけて取材したり、とにかくマニアックなことがすきなニッチほそかわさん。プログラミングに興味をもちプログラマーアイドルのメンバーになった経験もあり、卒業後はITライターとしてIoTエンジニアを取材や、電子工作系YouTubeに出演されています。

今回は、笑顔判定カメラを作ってみたようです!

f:id:pcads_media:20211117154104p:plain

ニッチさんは、メッセージでは「わろた」「ウケる」と送られてきた際、本当に笑っているのだろうか...と疑問に思う経験があったのだとか…(笑)

そんなとき、「せめて自分だけでも、本当に笑った時しか笑っていると伝えないようにしよう!」とひらめき、笑顔判定カメラの開発を始めました。

手順は以下の通り。

①自分の笑った顔や声を学習させてAIモデルを作成
②笑顔や笑い声が出ていたらmicro:bitにマークが出る
③マークが出たら、人に笑ったことを伝えてもいい

こちらは、ベータ版のScratchとmicro:bitエディタを利用して開発。

f:id:pcads_media:20211117154139p:plain

まずはTeachable Machineで、笑顔や笑い声を学習させ、共有リンクを取得。Scratchの拡張機能を使ってBluetoothでPCとつなげます。

Scratch×マイクロビット×ティーチャブルマシーンで笑い判定機をつくった

無事成功したでも動画はこちら!

youtu.be

製作中はmicro:bitにファイルを転送するために転送用のUSBケーブル(転送用と記載されている)が必要になり、困ったことも。転送用と書いてあるUSBケーブルかはチェックが必要です!

顔が見えにくい今だからこそ、言葉や笑顔を大切にしていきたい、という思いのもと考えついた発明でした◎お子さんでも挑戦しやすい自由研究となりますので皆さま是非挑戦してみてください!

>>次のページへ


 

「サウナIoTのための最初の0.5歩」/木戸康平さん

続いて、IoTシステムobnizを制作しているCambrianRoboticsのCo-Founderである木戸さんからの発表です。早稲田大学 総合機械工学研究科にてロボットの研究を行い、ハードウェア/ソフトウェアの複合領域エンジニアとしても活動。

今回のテーマは「サウナIoT」。サウナが好きすぎて「サウナ・スパ健康アドバイザー」の資格まで取得してしまったという木戸さん。サウナーエンジニアの皆さま必見です!

f:id:pcads_media:20211117154219p:plain

サウナはただ熱いだけのものではなく、サウナの入り方には上記のようなお作法があります。まずは熱めのサウナに入った後に、水風呂に入って外気浴をする温冷交代浴を1セットとしてこれを何回か繰り返します。繰り返しているうちに交感神経と副交感神経の働きがサウナの「ととのう」を生み出します。

今回は、自分に最適なサウナを見つけるためにIoTを使います。

サウナ、水風呂、外気浴にも様々な種類があり、それらを組み合わせて「ととのう」を感じますが、何が一番自分に合うのかを見つけていきます。どの工程においても重要な要素は「温度」。ここでIoTを使って温度を計測することに挑戦してみます。

ところがサウナ施設に回路を持っていくことは難しい、そして高温多湿の環境にも気を使わなければいけない。ということで木戸さんは自宅のお風呂場をサウナにするおうちサウナに行き着きました!!

f:id:pcads_media:20211117154309j:plain

そこで、プローブ式のBLE湿温度計を購入。AC電源は怖いので乾電池のものを使います。また、心拍数も測り、それらのデータをスプレッドシートに記録していきます。

f:id:pcads_media:20211117154337p:plain

データを見てみると、アクティブなゾーンとリラックスのゾーンがなんとなくわかってきます。このアクティブとリラックスが重なる部分が「ととのい」のタイミングとなります。

このように、ととのうタイミングがわかるようになれば、自分にとって最適な温度や最適な時間、最適なサウナの楽しみ方がわかるようになるかもしれません。サウナにすでにハマっている人だけでなく、興味はあるけどまだ試したことがないというかたは是非、サウナIoTを試してみるのはいかがでしょうか◎

 

「キャンプIoTに挑戦!vol.2」/ななみんさん

通信会社に勤務し、自転車シェアサービスの立ち上げやFintechサービスの立ち上げなどを経験されてきたななみんさんですが、前々回に引き続き、キャンプIoTのご紹介です!

前回のキャンプIoTでは、「冬キャンプ×IoT」で寒い環境でも快適にキャンプを楽しむためのIoT温度計、そしてBBQ肉用のスマート温度計に挑戦。今回はライトに注目してキャンプIoTに挑戦したお話を紹介いただきました。

f:id:pcads_media:20211117154407p:plain

ライトに注目する理由は以下の通り。

・キャンプ場は暗く、作業のために光確保が必要
・消灯時間が決まっており、夜は消灯、トイレに行くなどのためにはクイックに点灯・消灯する機動性が必要
・最近キャンプ場で盗難もあるため、人が近づいたら点灯するなどして抑止力が欲しい

そこで、今回は、①IoT照明②IoTイルミネーション③応用編:人が近づいたらライトが点灯する仕組みの3つを開発!

IoT照明

f:id:pcads_media:20211117154436p:plain

まずはIoT照明から。Amazonで購入したスマートプラグとコンセント型ライトを使います。こちらは光量7000ルクスと、暗闇でも十分明るく、タイマーやスマホで操作することができます。

IoTイルミネーション

f:id:pcads_media:20211117154505p:plain

次にIoTイルミネーション。こちらもAmazonで購入した電池式のLEDイルミネーションキットにMaBeeeを組み合わせスマホで操作ができるイルミネーションを作ります。

この2つを試してみて気づいたこと

①IoT照明:ライト自体に「転倒時消灯機能」がついているのでテントが動くと消灯してしまうため、揺れるものに設置するときはこの機能ががないものを選ぶ必要がある。
②IoTイルミネーション:予定通りうまくいったが、設置するのが面倒だった。
③ライトをつけていたら蚊がきてしまう…!
蚊については、Amazon Alexaの超音波アプリを使う、扇風機とスマートプラグで物理的に飛行できないようにしたり、複数の対策を検討しました。

蚊対策を考慮したIoTランタン!

f:id:pcads_media:20211117154557p:plain

夏場のキャンプは蚊がきてしまう、ということで、ななみんさんの考える最適なIoT照明はこちら:
テントから遠いところにIoTランタンを設置しておき、テントの中で過ごしているときにもし蚊が発生したら、テントの照明はOFF、テントから遠い位置のIoTランタンの照明をONにすると、蚊がライトの点灯している明るい方向に移動してくれるだろう、というもの!

今回の自由研究のまとめ

・冬キャンと夏キャンそれぞれ別の課題がある
・電源(+Wi-Fi)があれば、試せることの幅が広がる
・キャンプにおいては、設置や設定に時間がかからない、防水性の高いものに勝機がある
・自然界でのIoTハックは楽しい

自然とIoT、一見相反するものに見えて組み合わせると可能性が広がるのは面白いですね。サウナやキャンプはコロナ渦でさらに盛り上がりを見せていますが、エンジニアならではの楽しみ方を追求してみるのも良いかと思います◎

 

まとめ

今回も、創意工夫に富んだ自由研究の数々をご共有いただきありがとうございました!
ここからは、登壇者へのご質問を紹介いたします♬

ビデオオンの参加者の皆さまとの記念撮影

f:id:pcads_media:20211117154747j:plain

 

参加者からとはさんへの質問

“(Q)スマートスピーカーは多様性に対する支援技術にもなるかと思いますが、あまり支援技術とは言われているのをみたことがありません。なぜだとおもいますでしょうか?”
例えば、音声なので視覚障害者用も考えられるとは思いますが、ユーザビリティのところまで考えられてないことが多いのではないでしょうか。(※そもそもそこにスマスピがおいてあるということを視覚障害者に認知させることができていない等)

“(Q)なんのツールでヴァーチャルになっているの?!やってみたい!”
reality(https://reality.app/)というスマホのアプリを本日は使っています。スマホでそのまま映すだけでVtuberになれます!

“(Q)会社でもスマスピ活用していますか??”
最近オフィスに人がいないので使われていないですが、受付や通知をスマスピが音声で伝えるということはあります。

 

参加者から小栗さんへの質問

“(Q)ナムコそんなの作っているのですね、すごいな。”
今は撤退してしまいましたが、当時はその業界で有名でしたよ。

“(Q)小栗さんがナムコ時代に発明したということですか?”
外部からの持ち込みで、ナムコの方で製品化しようと開発しました。

“(Q)ブロックのアプリ、既存のものですか?使ってみたいです”
BlocklyというGoogleのサービスをカスタマイズして、改造したものです。ベースはGoogleのものを使っています。

“(Q)Arduinoに落ち着いたのはどうしてですか?”
Raspberry Pi Picoなどが出て浮気したこともありましたが、キーボードやマウスを使うための機能を使うのに、もっさりとダサくならずちょうど良いのがArduinoでした。

 

参加者からニッチほそかわさんへの質問

“(Q)笑いの思想、今こそ大事ですよ、素晴らしい。どこから発想生まれたのですか?!”
私は笑いにストイックで、人を笑わせたいという欲求があるのです。ですが、友達に「わろた」って冷たく返されると「ムッ」としちゃいます。なので、将来的にはちゃんと友達が笑っているというのも分かるようにしたいです。

“(Q)声も判定に入るの?!”
画像認識で判定して、音認識でも判定しています。顔と声の2軸で判定するシステムにしました。

“(Q)プログラミングは必要でしょうか?”
スクラッチなので、ノーコードでできます。

 

参加者から木戸さんへの質問

“(Q)Raspberry Piとかで使うセンサーってサウナの部屋の温度に耐えられるのですか?素人でごめんなさい。”
センサーにしてもいろいろな種類があります。今回は、耐性が90度くらいあるやつを選んでいます。

“(Q)サウナやったこと無いんだよなぁ、交流が苦手で。でも気になる。”
交流はそんなにしないと思います!黙々と一人で入っている人が多い印象です。

“(Q)ハード機器って、可動温度の範囲ってどの程度でしたっけ?”
大体80度までってパターンが多いので、本体は外に置いてセンサー部分だけ持って行くなどの工夫が必要です。

“(Q)ととのいゾーン、これお金になるのではないですかね?”
本当にやるのだったら、本格サウナを買って、その人にあった(ととのう)サウナにするっていうのはいいかもしれませんね(笑)

 

参加者からななみんさんへの質問

“(Q)ソロキャンでも楽しめるIoTを作ってほしい!”
基本、ソロキャンでやっています。確かにさっきのイルミネーションとか1人でやっていると何やっているのかと思われるかもしれませんが、「こういうのやったよ~」って発信すると1人じゃないですよ!

“(Q)キャンプとサウナとIoT、コラボネタも良いのではないですか?!”
良いですよね。実はマイサウナ買おうと悩んでいます。

“(Q)IoT照明いいな。こういうのってどこで見つけるの?やっぱアマゾン?”
Amazonは次の日に届くのがいいので、使っていますが、時間に追われていなければアリエクスプレスを重宝しています(アリエクスプレスは購入しても届くのに時間がかかるため)。

“(Q)MaBeeeって通信方式はなんでしたっけ?”
Bluetoothです。

 

参加者から皆さまへの質問

“(Q)せっかくだから何か面白い事質問してみたいけど、思い浮かばない。えーっと、自由研究のような楽しみが仕事になった(お金になった)お話あれば聞かせて。”
とはさん:仕事になったこと…ある気も…します…。アイデアの引き出しとして役立つことは結構多いです。
発明家の小栗さん:このスイッチに関しては、興味を持った人にほぼ原価に近い価格で10個ほどお渡ししたことはあります。
ニッチほそかわさん:まだないです。これから発売できたらいいですね!YouTubeは収益化しています!
木戸さん:obnizを発売している会社で働いています。周りの人もそういうことやっているので、その方から面白いキットみつけたら買うっていうことはよくあります。
ななみんさん:私もあります。IoTやっているっていうと、こういうの作ってって言われて、作ったことがあります。また、おうちハックを取材させてとTV局から連絡がきたこともあります。

“(Q)自由研究のテーマってどうやって決めていますか?(自然に決まっていくのかな。自由だし)”
とはさん:新しいもの好きなので、注目のサービスをとりあえず触ってみてというところが多いです。
発明家の小栗さん:先に作って、後付けで無理やりテーマをつけているような気がしています。
ニッチほそかわさん:まだ駆け出しなので、既に例があるものを真似して自分でも作るという方法をとっています。
木戸さん:日常生活でこれ便利かな~と思ったら、作っているという感じです。
ななみんさん:広い戸建てに住んでいると結構課題があるのでいろいろと浮かんできます。あとは、家族にこういうの作れないの?と言われることもありますね。路地に面した庭で犬のフンを片付けない人がいるので、その対策として、時間になったらスプレーをかけるガジェットを作ろうかなと思っています。それ出来たら売れるかもしれないです(笑)

“(Q)みなさん、情報収集とかどこでやっています?研究の勉強とか!”
とはさん:一番多いのは、"やってみた系の記事をみて、ドキュメントを確認して、最新情報を確認する"という流れです。
発明家の小栗さん:必要になったらそれを調べてみる、日常で送られてくるメルマガなどで気になるものはWebで調べています。
ニッチほそかわさん:「ラズパイ」の情報が流れてくるように設定しているので、それを見たり、電子工作のYouTuberを見たりしています
木戸さん:基本的にはネットです。Twitterもよくみます。自分で調べるときはQiitaも多いけど、公式のドキュメント見ていることが多いです。
ななみんさん:私は作りたいものが頭に浮かんで、何センサーかな?→Qiitaで沼にはまっていきます(笑)

“(Q)自由研究者のお互いの研究に対する感想を聞きたいですな。”
とはさん:皆さん、いつもニッチなのですよね。このニッチ同士をくっつけて自分でもやってみたいと思います。
発明家の小栗さん:皆さんの話と発想を聞いていて「あ~そうか」と思って聞いています。めちゃくちゃ凄い発想ではなくても、もっとこうできたら面白いとか聞いていてどんどん発想が出てくるので、楽しく聞いています。
ニッチほそかわさん:私はまだまだなので、私は実用的なものを作っているつもりなのですけど、皆さんのを見ると、こんなに実用的なものが作れるのだとびっくりしています。
木戸さん:全然違う思考でその過程を見るのが楽しいなと思います。製品だと出来上がったものだけど、それができるまでのアプローチが面白いです。
ななみんさん:私はめんどくさがり屋で、コードを書くのを回避しているので、今の流行りはノーコードだし皆もそういうのをどんどん作っていて嬉しいです。みんなクイックに作ってフィードバックして改善する、というサイクルを回しているのがいいなと思いました。

イベントレポートは以上となります!次回のイベントレポートもお楽しみに♪

【イベントレポート】 UXデザイン勉強会 〜UXデザイン事例と業務効率化ネタ共有〜

 

こんにちは!TECH Street編集部です!

今回は2021年9月9日(木)に開催した、 「UXデザイン勉強会 〜UXデザイン事例と業務効率化ネタ共有〜」のイベントレポートお届けいたします。今回は大好評のUXデザイン勉強会の第二弾。ITテクノロジーに関するサービスのUXデザイン事例やTIPSを共有しあう勉強会を開催いたしました。

登壇者はこちらのお二人!(登壇順に記載)

亀田 重幸さん/ディップ株式会社
羽山 祥樹さん/日本ウェブデザイン株式会社

それでは、早速当日の発表を紹介してまいります。

 

「ビジネス視点から考える新しいUXデザイン」亀田 重幸さん/ディップ株式会社

今回は、使いやすいだけでなく、ビジネスで成果の上がる、UXデザインを活用した新しいフレームワークを紹介していただきました。

UXデザインとビジネスの関係性

f:id:pcads_media:20211108163702p:plain

デザインとは、美しい見た目を作るためのものではなく、課題解決の思考方法の一つ。全てのデザインの範囲をあげると、「見えるデザイン」から、経営理念やビジョンなどの「想い」まで様々なフェーズで用いられていることがわかります。

f:id:pcads_media:20211108163716p:plain

次に、UXデザインという言葉を要素分解するとUX(作り手の心地よい体験)を作り、デザインする(課題解決する)こと、と説明することができます。

「課題を解決する」ことは、ビジネスとイコールでもあります。何かの課題を解決したいからお金を払い、それがビジネスになります。そのため、ビジネスそのものはデザインであるというように考えることができます。

DX時代においては、ユーザーが使いやすいだけのUXデザインではなく、ビジネスで売上を上げるためのUXデザインが求められるようになってきています。

サービスデザインシステムとは

サービスデザインシステムとは、下記4つの軸でビジネスを考えて行く方法です。
今回はバイトルを題材に、既存機能をサービスデザインシステムで解説いただきました。

①ビジネスロジック
②ユーザー体験
③仮説設計
④プロダクト

①ビジネスロジック

f:id:pcads_media:20211108163750p:plain

まず、ビジネスロジックでは目標達成のためのKPIを整理します。バイトルの場合は売上を上げるためには「案件数」と「応募数」が重要なので、この二つの数を増やすためのKPIを設定していきます。

ここで重要なのが、どのKPIをあげたいのか、優先順位をしっかりと立てることになります◎

②ユーザー体験

f:id:pcads_media:20211108163819p:plain

次に、バイトルにおいて重要なKPIである「応募数」を増加させるためのユーザー体験を整理していきます。

ユーザーが応募するにあたり、何をしたいかという気持ちを想像し、ユーザーの体験やアクションを書き出して整理していきます。この際、バイトルにおいては一般的な応募の流れだけでなく「職場体験があったほうがいい」というユーザーのニーズを新しい価値として取り入れることを検討したそうです。

③仮説検証

f:id:pcads_media:20211108164213p:plain

次に、ユーザー体験に関するアイデアの仮説検証を実施します。
検証内容

課題

解決策

計測KPI
この項目に沿って検証内容を整理していきます。

バイトルの職場体験については下記のように整理しました。

<検証内容>職場体験の応募数を増やすために仕事詳細で効果的な内容を検証したい
<課題>職場体験という聞き慣れない言葉にどう反応して、理解してくれるのか明らかにしたい
<解決策>職場体験OKの求人案件を用意して、ボタンクリック、応募時の体験選択有無を評価する
<計測KPI>職場体験コンテンツのクリック数・応募時の項目選択数

このとき、Flylを用いて仮説検証の管理をしました。

④プロダクトのワイヤー

最後は、プロダクトのワイヤーを検討します。

f:id:pcads_media:20211108164307p:plain

実施に、この「職場体験」というユーザー体験がバイトル全体の中でどのポジションに位置しているのかをワイヤーを使って整理します。これをすることで、どこの機能に影響して何を変えなければいけないのかがわかるようになります。

上記が、サービスデザインシステムの一連の流れですが、これを活用することは下記のようなメリットがあります。

・ユーザー体験(UX)の向上がKPIと繋がり数値も上がる
・仮説が立てやすくなり検証の精度が上がる
・無駄な機能開発をする時間を削減できる

f:id:pcads_media:20211108164353p:plain

UXは、UXフレームを使ったワークをやっただけで満足しがちになってしまうため、ビジネスにおける課題解決を意識したい人は、このサービスデザインシステムを活用するのがオススメです。

サービスデザインシステムは、UXを中心に使いやすいサービスを作れるだけでなく、しっかりサービスをグロースできるフレームになっています。

サービスデザインシステムの活用

f:id:pcads_media:20211108164419p:plain

サービスを開発する工程においては、戦略的UXを考えた後にサービスデザインシステムを活用するのがおすすめ!本当にこのビジネスが成功するのか、この機能は使われるのかを整理しておくことがその後の開発に大きな影響を与えます。

UXデザインには様々なフレームやワークがありますが、ぜひ一度亀田さんからご紹介いただいたサービスデザインシステムも、試してみてください◎

登壇資料

https://miro.com/app/board/o9J_lytMDK8=/?moveToWidget=3074457363668186511&cot=14

 

「もしプロダクトマネージャー・プロダクトチームにUXリサーチのメンターがついたら」羽山 祥樹さん/日本ウェブデザイン株式会社

プロダクトチームから成長につながる「決定的な一手」が出てこない...これはじつはプロダクトチームのユーザー理解が浅いときの典型的な症状。

「決定的な一手」は真に深いユーザー理解からしか生まれません。今回は、プロダクトマネジメントにおいて、プロダクトマネージャー・プロダクトチームにUXリサーチのメンターがつくことで、強いチームへと成長することができる、というお話をしていただきました。

f:id:pcads_media:20211108164446p:plain

例えば、人事の担当者から「応募者へのメッセージに「テンプレートの挿入」をできたらいいな」と相談を受け、一生懸命作ったのに「決まり切ったテンプレートしか使えないのでは使い物にならないよ」と言われてしまった…このようにユーザー側からの要望を受けて作ったプロタグトが、ユーザーの本来の要望を満たすことができなかったという経験はありませんか?

f:id:pcads_media:20211108165240p:plain

これは、ユーザーの発言を受け取ったプロダクトチームがユーザーの要望をどこまで理解していたか、という点が問題になっています。

ここで、プロダクトチームは「テンプレートを挿入したい」という発言の表面的な理解だけではなく、その背景にある「メッセージを効率よく捌きたい」という意図を理解し、さらにその先にある「たくさんの応募者に気配りある対応をしたい」という真のニーズを理解する必要があります。

f:id:pcads_media:20211108165300p:plain

真のニーズの理解まで達することができていれば、ユーザーのペインを解決する改善を多方面から的確にリリースすることができます。

つまり「決定的な一手」は、「真のニーズの理解」無くしては生まれないということです。

f:id:pcads_media:20211108165348p:plain

たとえば、人材採用サイトにおいては、ユーザーは二人存在します。一人は人事担当者、もう一人は転職者です。

どちらのユーザーも、転職サイトだけをずっとみている訳ではありません。ユーザーにとって、転職サイトを使うことは「目的」ではないのです。そのため、プロダクトチームが自分のプロダクトのユーザー体験だけを考えているのでは、ユーザーを取り巻く世界を断片的に切り取っただけとなってしまい、真のニーズを満たすプロダクトを生み出すことが難しくなります。

では、プロダクトチームが、真の意味でユーザーに出会うにはどうしたら良いでしょうか。
あてずっぽうにプロダクトを増築するのでは成功率は低くなります。そのため、ユーザーの真のニーズがどこにあるのかを見極めてから、プロダクト開発をする必要があります。

f:id:pcads_media:20211108165427p:plain

ここで、ユーザーを知るための専門技術である、UXリサーチが活躍することになります。これを、プロダクトチームが習得することができれば、ビジネスとしても成功するより良いプロダクトを生み出すことができます。

f:id:pcads_media:20211108165518j:plain

まずは、ユーザーインタビューやユーザビリティテストを使ってユーザーの価値観を明らかにしていきます。

f:id:pcads_media:20211108165626j:plain

次に、定性分析(質的分析)の専門技法でユーザーのインサイトを探っていきます。

このようにして、チームで徹底的にユーザー心理を考えていきます。この、「ユーザー心理を徹底的に考えること」がチームの文化になっていくことが大切です。

f:id:pcads_media:20211108165703j:plain

プロダクト視点ではなく、ユーザー視点を持ってプロダクトを開発することを意識することが大切で、現状のプロダクトにとらわれず、ユーザーの真のニーズを理解していくために考え抜くことが必要です。

このようなチームを作る上で、外部のUXリサーチャーに委託するのも一つの手ではありますが、最終的にはユーザー理解をチームの文化に浸透していく必要があるため完全に委託するのではなく、チームで取り組むことがオススメです。

f:id:pcads_media:20211108165729j:plain

とはいえ、チームにノウハウがない、ということも考えられると思います。そんな時は、チームにユーザー視点が文化になるまで伴走してくれる、経験豊かなUXデザイナーのメンタリングを活用してみるのもオススメです。できれば、CXO(Chief eXperience Officer)の設置をし、経営レベルにまで盛り込むことが好ましいと思います。

ビジョンのある革新的なプロダクトは、天才のジャンプした思いつきから生まれるのではなく、ユーザーに対する深い洞察から生まれます。

世の中に価値をもたらすプロダクトを生み出すために、ユーザーの理解をチームの文化にしていきましょう◎

登壇資料

まとめ

参加者の方からは、「精神論っていうかなんていうか、根本的にすごく大事なことを教えていただいた気がします。」などのコメントもいただきました!みなさまが抱えている、UXリサーチ、UXデザインという分野においての様々な悩みを今回のイベントで少しでも解消できていれば嬉しく思います!

 

参加者の皆様からもたくさんのご質問をいただきました!

続いて当日回答しきれなかったご質問含めて紹介いたします◎

参加者からのご質問

“(Q)お客様向けのプロダクト作成で、UXの意識はどの段階で持ち始めると良いでしょうか?”

亀田さん:一番最初からです。まずは誰向けの何をやりたいのか、そこからUXだと思います。

羽山さん:亀田さんに同意です。UXデザイン・UXリサーチは「何をつくるか」を決める作業なので、要件定義の話なんです。それも要件定義の前の要件整理をやる技術です。だからいちばん最初です。

“(Q)UXってセンスと技術どちらが大事なんだろう。”

亀田さん:誰かをマネして、自分でやることが大切です。そして誰にでもできる、困っている人をみつけてそれをどう解決できるかっていうことなので、センスというより誰でもできることだと思います。

羽山さん:僕は、センスという言葉はあまり信じていません。「センス」と言われると「いま言ったセンスとは何を示していますか?」と聞いてしまいます。一つ一つ言語化してみましょう。「ユーザーインタビューはセンスだよ」→「それは何をしているということですか?」、「ユーザーとの信頼感をつくるんだ」→「信頼感をつくるってどうやるんですか?」、→「まずは最初に明るく挨拶をする」→「なるほど、つまりセンスを言語化すると、最初に明るく挨拶することなのですね」というように「センス」を言語化しましょう。センスというものは存在しなくて、つまりは技術しかないのではないでしょうか。

“(Q)まずは何をすべきか悩みます。サービスを利用するユーザーを見るか、それとも同じ形態のサービスから成功事例をみるか。”

亀田さん:どちらでもいいと思います。競合調査もしますし、僕はユーザー(課題)をみます。何に困っているかをみます。

羽山さん:亀田さんに同意です。ユーザーをみましょう。他社をみてもそれが間違っていたりもすると思います。たとえば、業界のリーダーが「社内事情」ではじめた機能が、競合他社がみんな真似をして、しかしユーザーには刺さっていない事例もあります。

“(Q)五感の中で一番UX、感動体験にうったえかけやすい感覚ってどれなんでしょうか?”

亀田さん:難しいですね。視覚かなと思います。目に入るものは大きいと思います。体験を自分の中に植え付けるような役割ではないでしょうか。

羽山さん:人を感動させたいというご意図の質問でしょうか。もしそうならば「五感」と考えるのではなく、「ストーリー」をユーザーに渡してください。人間はストーリーに感動します。たとえば「犬が飼い主を待っている。飼い主が戦争に行く。飼い主は帰らない。しかし犬は毎日飼い主の帰りを待ち続けている」というように「五感」ではなく「ストーリー」に人は感動します。

“(Q)バイトルさんのWebエンジニアはUX意識させてますか?内製でしょうか?”

亀田さん:内製と外注は機能によって分かれてます。すごく内製できてるかというとそういうわけでもないです。

“(Q)UXを学ぶにあたって、何をされましたか?うまくできなくて悩んでまして。”

羽山さん:1. 実案件で、高度なノウハウのあるUXデザイナーに参画してもらって、一緒に仕事をするのが学びになりました。羽山の場合はネットイヤーグループさん(当時、坂本貴史さんが羽山のプロジェクトを担当)とのプロジェクトで思考方法を学びました。
2. 産業技術大学院大学 履修証明プロクグラム「人間中心デザイン」に通い、体系的な知識、手法、哲学を学びました。

“(Q)UXについてPoCって取り入れられますかね?”

亀田さん:チームにもよりますね。バイトルでもやっていたりします。プロトタイプで検証することが多いです。

羽山さん:「MVPをつくってユーザーに受け入れられるか検証する」というのが、UXのPoCそのものだと思っています。

“(Q)ディップさんのつかってるITツールしりたい。イケてるのたくさん使ってそう。”

亀田さん:最近はmiroとNotionを使ってます。

“(Q)UXデザインにおすすめのツール教えてほしいです。”

羽山さん:僕も知りたい!(笑)。僕はPowerPointで心理マップをつくっています。僕のクライアントで、大手のお客様だと、クラウドツール禁止、フリーソフト禁止、という会社もあります。そうするとデータを共有するには、絶対にどの会社でも入っているパワポ・Excelを使うことになります。

“(Q)このサイト(企業)のデザイン、うまいなー、って思うのありますか??”

羽山さん:ビービット(beBit)のUXデザインが好きです。彼らは「成果(売上やコンバージョンなど)」に徹底的にフォーカスしたデザインをします。UXデザイナー視点でみたときに、ビービットのデザインは、一切の無駄なくユーザーの課題をまっすぐ撃ち抜く設計をしているなと思います。

“(Q)miroの他に、スプレッドシートも駆使して 情報を洗い出すことはありますか?”

亀田さん:もちろんあります。色んなものを使います!

“(Q)ユーザーニーズをプロダクトチームがきちんと理解するには、どのくらいすり合わせる必要がありますか?”

羽山さん:僕が関わっているプロダクトチームでいうと、僕自身がプロダクトマネージャーなんです。プロダクトマネージャー=UXデザイナーなので、擦り合わせというのはやっていません。
そうでないチームの場合、よく言われるのは、ユーザー調査の段階で、関わる人(エンジニアやデザイナー、ビジネスサイド、営業など)を交えて、ユーザーが何に困っているのかを目の前でみせることで、腑に落ちてものがつくれるようになります。

“(Q)UXと話が変わってごめんなさい羽山さんのスライドの絵が可愛すぎる。どこのサイトにありますか?”

羽山さん:じつは https://hermie.jp/ で無料素材として配布していたり・・・。

“(Q)掘り下げるレベルは3段階なのが羽山さまの一般的なやりかたですか?”

羽山さん:プレゼンとして分かりやすく説明するために3段階の図で紹介してます。現実には明確に段階を分けることはできませんが、いずれにしてもポイントは深く深くヒアリングすることが大切だと思います。

“(Q)ユーザーニーズの掘りさげにかける時間(かけられる時間)と予算はどのように考えればよいでしょうか?”

亀田さん:ひたすら営業にインタビューしたり、ヒアリングに時間をかけることはあります。

羽山さん:これは難しいですね。ユーザーニーズを理解することの大切さが分かっている企業は、予算も時間もかけられると思います。スタートアップなどスピード重視の場合もあります。

“(Q)技術者ってユーザーの気持ちを考える工程を面倒に思っている印象…技術ありきの人に考えてもらうコツを聞きたい。”

羽山さん:そういう方も、ユーザーがプロダクトをぜんぜん使えていない場面を生で目の前でみると衝撃をうけるので、ユーザビリティテストなどに同席していただくとよいです。

“(Q)そういう素敵なプロダクトチーム作りたい。なのですが、社内の壁があるんです。特に上司。”

亀田さん:僕はお土産をもって仲良くなろう作戦をやっています。そのチームが困っていることを解決するよっていうのが「お土産」です。

羽山さん:お察しします…ゲリラ的にやる、という方法があります。たとえばユーザビリティテストにしても、お金をかけずに呼べる人、たとえば社内の別チームの人を呼んできて、プロダクトを使ってもらい、その様子を上司に見せるような方法です。

“(Q)UXリサーチにはどんな手法がありますか?”

羽山さん:ユーザーインタビュー(ユーザーがどんな課題を抱えているか聞く)、ユーザビリティテスト(具体的なプロダクトを使ってもらいその様子を観察する)がとくに多いです。
ほかにビジネスエスノグラフィ(現場にいってユーザーと一緒になって観察する)をすることもあります。もう1点、リサーチしたあとに、きちんと結果を「定性分析(質的分析)」することが大切です。分析方法は親和図法、KA法(本質的価値抽出法)といったものがあります。

“(Q)UXデザインのメンタリングおすすめありますか?”

羽山さん:ベテランのUXデザイナーに教わるのがいいと思います。ただ、ここまでお話して、じゃあその人とどこで出会うのかって問題がありますね(笑)。社内にそういう方がいれば弟子入りしたらいいと思いますが、社内にいないパターンもあります…。昔だと社外勉強会で懇親会で仲良くなるという方法がありましたよね。今のこのご時世、出会い難しいですよね…😢 人脈づくりとしては、このイベント運営をされているミッツさんがプロです。
ミッツさんはどうされていますか?

ミッツさん:「これは!という方には、SNSでコミュニケーションをつくり、ダイレクトメッセージで相談してつながりをつくります。みなさんはぜひ羽山さんとつながるとよいと思います」

“(Q)UXリサーチの法則ってありますが、あくまで仮説だし当てはまらないことや背反する法則もあると思うのですが、どうグルーピングして仮説を整理してますか?”

亀田さん:法則は意識したことなかったです。課題は、グルーピングももちろんやります。重たい課題からみつけていって、それをいかに解決するかにアプローチしていくと効果が大きいです。

羽山さん:「UXリサーチの法則」とはユーザビリティ原則のことでしょうか? ユーザビリティ原則として、一般的にこうつくると使いやすくなる、という指針はいろいろ公開されています。ただ、そこをUXデザインするときにあまり意識してません。というのは、UXデザインは「インターフェースのデザイン」をしている時間より、「ユーザーを調査すること」と「何をつくるべきか整理すること」にかける時間のほうがずっと多いのです。UXデザインは要件定義フェーズの技術だからです。(羽山後日談:質問者の方は「UXデザインの法則」という書籍に書かれた心理学の法則のことをおっしゃりたかったのかもしれません。いずれにしてもユーザビリティ原則と同じで、UIデザインをする以上にユーザー調査に時間をつかいます)

“(Q)アプリエンジニアです。 自社開発だと、UXリサーチを取り入れやすいですが、受託開発だと難しいですよね? 発注側からのアクションを待つしかないのですよね...。 何か事例はありますか?”

羽山さん:受託であれば、営業活動のなかで「UXデザイン・UXリサーチをしませんか」と訴求して、案件をつくる、ということが必要になります。発注側のアクションを待っていてもなかなかチャンスは来ないので、自分から案件を取りにいきましょう。

“(Q)技術系の開発だと社内/社外のおえらいさんに体験してもらって、ユーザーからの意見を収集したと勘違いしている人が多い。”

羽山さん:社内政治は社内政治でプロジェクトを円滑にまわすために必要だと思っています。ただ社内政治のための意見収集と、ユーザー理解のための調査をまぜてしまうと混乱するようであれば、どちらかを諦めるのではなく、両方するのがいいと思います。

“(Q)我が強い人の意見に流されてしまう部署が多いのが現状で、UXデザインが間違った方向に行ってしまいます。そんなときの解決策ってありますか?”

羽山さん:ユーザーがプロダクトをぜんぜん使えていない場面を、みんなで目の前でみて、みんなで衝撃をうけるとよいです。それ以後のミーティングでは、「この前のAさんだったら、この機能をどうおもうだろうか」と、かならず「Aさん」を主語にするようにします。そうすると、チーム全員の意識が「Aさん」という具体的なユーザーを中心に思考するようになります。

“(Q)リサーチしてユーザインサイトを踏まえながら企画したいけど、組織の理解が得られないっていう相談毎回でるなぁ お金かからないゲリラ調査をまずしましょう、と私も回答することが多いのだけどゲリラ出来ないケースとかもあるのかな〜 きになる。”

羽山さん:上司がUXリサーチを理解しない。しかし、部下が上司の知らないところで活動するとプライドが傷ついて怒り出す上司、というケースがあります。この場合、ゲリラ活動も内容以前に活動していたこと自体で反感を買うことがあります。
そのような場合、まずは上司に可愛がられる部下になり、ある程度の裁量をもらえるまで社内政治をすることがスタートになります。年単位がかかることもあります。UXデザインプロジェクトの半分は組織論なので、覚悟を決めてがんばってください。
羽山の例をいうと、部署でたったひとり、誰も「UX」という単語を知らないところからスタートし、10年かけて事業部の年間方針にUXが含まれるところまでしました。長期戦、心が折れないように、じっくりとがんばってください。

“(Q)ユーザーに直接会うことができないときはどんな方法で理解を深めたら良いですか。私はIT部門ですが営業の人と会うことが出来ません。”

羽山さん:ゲリラ的にやる、という方法があります。たとえばユーザビリティテストにしても、お金をかけずに呼べる人、たとえば社内の別チームの人を呼んできて、プロダクトを使ってもらうような方法です。
直接のユーザーでなくても、人間は「同じ目的」のために行動するとき、おおむね同じような行動をする傾向があります。似た行動をする、間接的なユーザーへの調査で代用します。

“(Q)ユーザー心理マップを詳しく見たいのですが共有いただくことは可能でしょうか?”

羽山さん:本日のプレゼンでご紹介した「ユーザー心理マップ」は、実物をダウンロード配布しております。以下のnoteで配布しているので、ぜひご参考ください。
https://note.com/storywriter/n/n7e362be9c956
https://note.com/storywriter/n/n9f84eb25f8c8
https://note.com/on_inc/n/n48fa96374313

“(Q)ベネフィットが出ない改修に予算が出ません🥺使いやすくなることでベネフィットをどのように算出して予算を取得していますか?”

羽山さん:まずベネフィットが明確なところのユーザー体験の改善から取り組んでみてはいかがでしょうか。ユーザーのゴールとビジネスのゴールが一致するところにおいて、ユーザーがよりゴールを達成しやすくなるための投資であれば、引き出しやすいのではないかと思います。

“(Q)企画業務に携わっておりUXの勉強をしているのですが、自分のことをUXデザイナーと名乗って良いのか迷っています、”

羽山さん:世の中が期待するUXデザイナーのスキルとして幅はあれど、「ユーザーインタビュー」と「ユーザビリティテスト」はできる、というところは、比較的多くの人の同意が得られそうに思います。まずはその2つが、最初から最後まで独力でできるようになったら、UXデザイナーと名乗ってみたらいかがでしょうか。

イベントレポートは以上です!次回のイベントレポートもお楽しみに◎

【イベントレポート】AWSエンジニア勉強会 ~今おさえておきたいAWS最新トピックスとユーザーLT~

 

こんにちは!TECH Street編集部です!

今回は2021年9月7日(火)に開催した、 「AWSエンジニア勉強会 ~今おさえておきたいAWS最新トピックスとユーザーLT~」のイベントレポートお届けいたします。
今回はインフラエンジニアやクラウドエンジニアがおさえておきたい2021年上半期のトピックス情報そして最新情報をはじめAWS活用ユーザーによる事例LT発表をしていただきました。

登壇者はこちらのお三方!(登壇順に記載)

増田 健吾さん、宮本 太一さん/パーソルホールディングス株式会社
亀田 治伸さん/アマゾン ウェブ サービス ジャパン株式会社


それでは、早速ご紹介して行きます!

目指せプロキシ運用からの脱却!最近リリースされたネットワークFWを検証してみた
増田 健吾さん、宮本 太一さん/パーソルホールディングス株式会社

日系SIer、日系エンタメ企業、外資系コンサル企業を経て、パーソルグループのAWSクラウド基盤を運営するチームのマネジメントや基盤サービスのオーナー、クラウド戦略の考案などを担当している増田さん。そして、新卒でパーソルグループに入社し、増田さんのチームの一員としてPMを担当されている宮本さん。

今回は、フォワードプロキシにいくつか課題が存在していたため、マルチアカウント基盤で共通の出口を作り改善を図ることにチャレンジしましたが、結論としては構想していた構成は見送ることになったそうです。では、具体的になぜ見送る結論に至ったのかを紹介していきます!

現状と課題

f:id:pcads_media:20211022134720p:plain

まずは、パーソルのマルチアカウント基盤について。基本的には1アカウント1システムで構成するマルチアカウント基盤を採用。SharedアカウントにあるTransit Gatewayをハブとして、環境間でのプライベートアクセスを実現しています。

f:id:pcads_media:20211022134813p:plain

これまで各アカウント内にプロキシを設置していたため、下記2つの課題がありました。
①基盤内で同じ機能が重複する為コスト増大(構築・運用コスト、システム維持費用)
②フィルター運用が適切に行われないリスク

そこで、「共通のフォワードプロキシを作成し、基盤を運用するチームでこれを運用する」というソリューションを検討し始めました。

f:id:pcads_media:20211022134921p:plain

■As-Is
各アカウントの中にプロキシサーバーが1台以上稼働しており、構築と運用は各システムの開発・運用保守部隊が実施しています。

■To-Be
Security Accountのなかに共通のプロキシサーバーをたてたて、構築と運用は基盤の管理チームが実施します。このプロキシサーバーのざっくりとした要件は以下の通り。

・接続元:宛先ドメインのフィルター機能
・ドロップしたトラフィックのログ取得
・複数のシステムの通信に耐えうる拡張性・可用性
・基盤管理チームでも扱える程度のメンテナンス性

今回は、マネージドサービスの可用性とメンテナンス性に期待し、AWS Network Firewallの導入を検討しました。

f:id:pcads_media:20211022135026p:plain

To-Beの構成詳細は上記の通り。赤線が、外部(インターネット)へのアウトバウンド、青線が内部のクロスアカウントアクセス、緑線が外部(インターネット)からのインバウンドを示しています。

f:id:pcads_media:20211022135046p:plain

また、URLフィルターについてですが、AWS Network Firewallのファイアウォールポリシーは大きく2種類のルールグループで構成されており、上記の図にまとめています。
今回、全ての要件を満たすのはsuricataのみとなりましたが、suricataは設計可能な人が必要になる為難易度が高く、メンテナンス性の部分は△の評価となりました。

■使ってみてわかったこと(できること)

・システム側はEC2を立ち上げるだけでインターネットとセキュアに通信ができる
・意外とシンプルなルーティングになった
・ルーティングで全ての回線を持ってくる為、ガバナンス観点では最高

■使ってみてわかったこと(できないことと困りそうなこと)

・今回の構成では、システム担当者からすると通信経路が複雑で、結局システム側の開発スピードが下がってしまう
・通信経路が非対称になってしまう為、パブリックサブネットは少し困る
・接続元を絞ったURLフィルタリングはsuricataを1から書かないといけない為、優先度の設計などを含め基盤管理チームのスキルではハードルが高い…!

この結果として、構成は見送るという結論に。

今後は、ステートレスルールグループのdomein list形式に、接続元を指定する機能の追加や適用する制御ルールのグループ化と管理の機能の追加に期待したいとのことでした◎

 

今おさえておきたいAWS最新トピックス
亀田 治伸さん/アマゾン ウェブ サービス ジャパン株式会社 

アマゾン ウェブ サービス ジャパンの亀田さんからは、「今押さえておきたいAWS最新トピックス」をご共有いただきました!

AWSのコンテナについて

f:id:pcads_media:20211022135122p:plain

まずは、AWSが提供しているコンテナのオファリングのおさらいから。コンピューティングリソースは年々抽象化が進んでいます。仮想マシンのEC2があり、その上にコンテナを配置するオーケストレーションサービス(ECS,EKS)が配置されています。次のフェーズとして、サーバーレスの要望が生まれ、結果としてLambdaやFargateというサービスも誕生してきました。

f:id:pcads_media:20211022135203p:plain

コントロールプレーンが、コンテナを良いかんじにサーバー上に配置してくれ、実際にコンテナが動作するのがデータプレーンとなっています。

f:id:pcads_media:20211022135222p:plain

コンテナの実行環境としては、先ほどご紹介したAWS Fargate、Amazon EC2を始め、AWS Local Zones、AWS Wavelength、AWS Outposts、EKS Anywhere、 ECS Anywhereなどがあげられます。

f:id:pcads_media:20211022135241p:plain

コンテナの実行環境が多様化するのと同時に、ネットワークも多様化していきます。例えば、Amazon VPC、AWS App Mesh、AWS Cloud Map、Elastic Load Balancingなど。

最新アップデート情報

■AWS Copilot

f:id:pcads_media:20211022135305p:plain

まず、2020年7月に、AWS Copilotがリリースされました。こちらは、AWSが開発したOSSのCLIツール。Amazon ECSでのコンテナアプリケーションの構築・リリース・運用・デプロイメントを容易にすることができ、インフラだけでなくアプリケーション開発に集中できるようになります。

f:id:pcads_media:20211022135328p:plain

従来、コンテナのシステムは普通のサーバーのシステムより、設定が大変でした。ロードバランサーの設定も必須で、ECS,EKSを設定しようとすると設定項目が多いことにうんざりしてしまったことがある方もいるのではないでしょうか。それを抽象化してくれるのがAWS Copilotです。

f:id:pcads_media:20211022135409p:plain

こちらは、宣言的マニフェストによって「アーキテクチャ」を定義しています。

マニフェストファイルとは、サービスの詳細をyamlファイルで定義したものであり、この設計図を元にAWS CopilotはCloudFormationテンプレートを作成してデプロイします。この、マニフェストファイルというものさえ作成しておけば、誰がいつマニフェストを実行してもおおよそ毎回同じような基盤が出来上がってくるというメリットがあります。

■ECS Exec

f:id:pcads_media:20211022135437p:plain

ECS Execは、AWS Systems Manager (SSM) Session Managerを使ってクライアントとターゲットのコンテナの間にセキュアなチャンネルを作成します。

f:id:pcads_media:20211022135507p:plain

ECSを使った場合と Copilotを使う場合とでexecする際の事前準備が異なることは注意が必要です。

■Bottlerocket AMI

f:id:pcads_media:20211022135526p:plain

Bottlerocket はコンテナを実行するために構築されたオープンソースの Linux ベースオペレーティングシステム。コンテナの実行に必要なソフトウェアのみが含まれており、SSH,Pythonなどのインタープリター、シェルは排除されています。SELinux Projectを活用して、Bottlerocket自体への変更も可能。/etcはブートごとに再生成されるメモリバックアップの一時ファイルシステムが搭載されています。

元々AWSが提供するコンテナは普通のLinuxで動いていましたが、コンテナベースで開発が進めていくと、不要なLinuxの機能も出てきます。最初から不要なLinux機能を持たないものを作ったのがBottlerocketです。

■ECS Anywhere

f:id:pcads_media:20211022135548p:plain

今年6月にはECS Anywhereというサービスもリリース。こちらはお客様が管理するオンプレミスのサーバーでコンテナを実行させるものです。

■AWS App Runner

f:id:pcads_media:20211022140313p:plain

コンテナ環境を実行させる基盤を作るのは結構大変ですよね。従来のコンテナの導入障壁を下げるために、2021年5月にAWS App Runnerというサービスもリリースされました。

■AWS App2Container(A2C)

また、AWS App2Container(A2C)へのアップデートも2021年7月に実行されました。AWS App2Containerは.NET及びJavaアプリケーションをコンテナ化されたアプリケーションに最新化するためのコマンドラインツール。コンテナ化するアプリケーションを選択するだけで、A2Cがアプリケーションアーティファクトと識別された依存関係をコンテナイメージにパッケージ化してネットワークポートを設定、ECSタスクとKubernetes pod定義を生成します。

f:id:pcads_media:20211022140352p:plain

2021年7月のアップデートでは、Windowsの複合多層アプリケーションのコンテナ化をサポートする機能が追加。個別にコンテナ化された多層アーキテクチャで動作するIISアプリケーションやWindowsサービスを、同一ホスト上で動作する複数のアプリケーションを単一のコンテナに入れてコンテナ化します。

■AWS X-Ray 

f:id:pcads_media:20211022140423p:plain

通信及びアプリケーションパフォーマンスの監視も問題になってきます。一つのアプリケーションが複数のサービスから構成され、ログが別々に出てくるため、監視が従来の仕組みで提供できなくなっています。さらに、オンプレミス環境も監視しなければいけないため監視の仕組みはどんどん複雑化しています。そこで最近は、オブザーバビリティという概念がHOTなトピックスとして取り上げられています。

■Grafana

f:id:pcads_media:20211022140449p:plain

AWSでもオンプロミスのGrafanaをそのまま実行できるサービス(AMG)もつい先日リリースされました。

まとめ

どんどんアップデートが進んでいくAWSですが、より効率的に活用して業務の効率化も進めていければと思います!

 

ここからは、当日のQ&Aを紹介します♪

 

参加者から増田さん、宮本さんへの質問

“(Q)クラウドサービスが複数ありますが、どのサービスを選定するかお客様に説明するのに苦労しています。AWS利用がオススメとなるソリューションや業務モデルなどがありましたら伺えますとありがたいです。”

増田さん:持論になりますが、各社から沢山クラウドサービスが出ていますが、AWSがデファクトスタンダードだと思っていて、ナレッジの量が多いのが一番です。できることの差はあまりないと感じていますが、圧倒的なシェア率による事例があるところも嬉しいことや、誰かが通った道を通れるというところも"日本的な企業"としては有難いところです。

“(Q)「好きなサービス」AWSエンジニアなら定番だよね笑、今人気のサービスって何なんだろ?ずっと古いサービスばっか使ってるから、今流行り!これはオススメ!みたいなのを聞いてみたいです!”

増田さん:Network Firewallはオススメです。会社のニッチなセキュリティポリシーにより見送ることになりましたが(笑)

“(Q)セキュリティのポリシー厳しそう・・・”

増田さん:エンタープライズ企業ならではかもしれないですが、セキュリティポリシーにあらがって、自走をしていきたいとは思っています。

“(Q)NAT Gatewayってプロキシとして使えないんでしょうか?”

宮本さん:プロキシという意味だと使えます。自社のセキュリティ要件で見送りとなりました。URLフィルタリングなど、賄えない部分があったので…

“(Q)アカウントとはVPCを指しているのでしょうか。”

宮本さん:今回は使わない構成にしているので、異なるものと思っていただければと思います。

“(Q)ToBeいいですね。こういうのは現場で策定してスマートに実現できる感じですか?”

増田さん:チームの体制としてはスクラムを採用しているので、やりたいと思ったら自由にできる制度にはなっていますが社内のポリシーに振り回される部分もあります。

“(Q)色々情報部門からの制限や制約が多いのですが、パーソルさんはどのように戦っていますか?”

増田さん:ときには、喧嘩(笑)することもあります。何故それをやるのか?上流に立ち返ることをしています。また、代案を出しつつ、対策しています。

宮本さん:セキュリティ要件は何だっけ?防ぎたい事項は何だっけ?を大切にコミュニケーションしています。

“(Q)基礎的な質問でしたらすみません。 先ほどの設計で、機能別にアカウント(VPC)を作成されていましたが、これは一般的によくある設計なのでしょうか。”

増田さん:VPCではなく、アカウントという前提でお話させていただいており、アカウント毎で管理していく概念「マルチアカウント構成」を採用しています。最近では、この概念が浸透してきていると思います!

 

参加者から亀田さんへの質問

“(Q)所属先の兼ね合いというか何というかで、Backup Audit Manager気になってます。”

亀田さん:8月にリリースされた機能で、バックアップのログをオーディット用に管理する機能です。ぜひ、機能をオンにして試してみてください。

“(Q)運用手順の改修と費用の問題でなかなかコンテナ化に辿り着けないのですが、こういうのってウチだけでしょうか?”

亀田さん:コンテナはDevOpsと似ていて、システムというよりはカルチャーです。組織的に分離しているところだと、必要性は認識されづらい。アプリ側は便利だけど、運用側はめんどくさいかもしれません…。
運用と開発が分かれていれば、運用チームとしてはメリットを感じづらいと思います。

“(Q)従来のコンテナの作り方では出来た設定が、App Runnerでは出来ないところはありますか?”

亀田さん:現時点では、VPCの中身に入れないのが課題で、​​Auroraなどに入れません。ここが最大の注意点ですが、改修予定はあります。

“(Q)コンテナについてはコンテナセキュリティをどのようにすればよいのか悩んでいます。 ざっくりした質問で恐縮ですが、コンテナセキュリティのトレンドは昨今どのようになってますか? ベストプラクティスを知りたい!”

亀田さん:まず、セキュリティについて話をする際は、データセキュリティなのかネットワークセキュリティのどちらの話なのかを確認してから話しています。データセキュリティだとすると、コンテナは基本イミュータブルであるべきという大原則があるので、コンテナの中に個人情報を蓄積していくのはバッドプラクティスです。AWSが提供しているECRはイメージスキャンの機能がデフォルトでついていますので、こちらもぜひ試してみてください。

“(Q)亀田さんからしてエンタープライズ企業でコンテナが導入しづらい要因って何だと思いますか?”

亀田さん:カルチャーだと思っています。ネットワークのチーム、インフラチーム、Javaチーム、のようにチームを分けているとメリットが感じづらいと思います。大企業はすでに大きな収益を持っているため、大きくそのシステムを変える必要はありません。しかし小さいところだと陰りがでてきたら、大きく体制を変える必要があり、コンテナを導入することになったりする。

DevOpsだと、作った人が前提になるので、設計思想まで伝わらず使いづらいものになってしまう。SIモデルが日本全体の遅れを引き起こしているとよく言われていますので、海外と比べて遅いのはこういう理由に起因しているのかもしれません。

イベントレポートは以上です◎今後のイベントもお楽しみに!

【イベントレポート】“エンジニア向け”オンボーディングについて各社の取り組みを学ぶ会

 

こんにちは!TECH Street編集部です!

今回は2021年7月29日(木)に開催した、 「“エンジニア向け”オンボーディングについて各社の取り組みを学ぶ会」のイベントレポートお届けいたします。今回は各社のエンジニア組織におけるオンボーディングについて、実際に組織内で活躍しているエンジニアに発表共有していただきました!

登壇者はこちらの3名!

・堀端 大輔さん/ミイダス株式会社
・田口 雄一さん/パーソルキャリア株式会社 クロスオーバーディレクター
・今村 雅幸さん/株式会社BuySell Technologies 取締役CTO
※ご登壇順に記載

それでは早速紹介してまいります!

 

開発組織の人事としてオンボーディングで意識していること
堀端 大輔さん/ミイダス株式会社

Webデザイナーとしてキャリアをスタートし、制作会社などでサイトデザインやコーディングなどを経験されてきた堀端さんは、2015年のミイダス立ち上げ時にフロントエンドエンジニアとして入社。2019年5月からエンジニア人事として、エンジニア採用や1on1などをメインで担当されています。

ミイダスではコロナを機にフルリモートでの働き方が主流となっているため、フルリモートでのオンボーディングについてお話しいただきました!

一緒にはたらく人や組織にいかにスムーズに馴染んでもらうか

①VPoEとの顔合わせ

f:id:pcads_media:20210916181112p:plain

組織のことや開発のことについて、スムーズにコミュニケーションを取れるようにするため入社時には必ずVPoEとの顔合わせを行います。

②月初共有会での紹介

リモート環境下においても、コミュニケーションの敷居を下げるために実施。受け入れる側も拍手👏のリアクションをするなどウェルカムな雰囲気で受け入れてもらえるように意識しています◎

③週一の人事面談

ギャップの把握・解消、早期離職の抑止を目的として、週一の人事面談も実施しています。具体的には下記のような項目をヒアリング。

・やりがいを感じられているか
・カルチャーはあっていそうか
・スキルは追いつけているか
・プロダクトはあっていそうか
・困っていることはないか

「困ったらいつでも聞いてね」と言われても、なかなか聞きづらいなんてこともありますよね...そういった不安は週一の人事面談で解消していける仕組みにしているそうです。

業務に必要な組織内ルールや知識をいかに早く身に付けてもらうか

社内ルールや業務フロー、リリースサイクルなどに慣れてもらうことを目的に、入社後1〜3ヶ月間を目処に受入チームを設けて、メンターをつける制度も実施しています。

f:id:pcads_media:20210916181238p:plain

また、新しい人ができるだけ早く疑問を解決できるように、新しい人専用のSlackチャンネルも用意して、オンボードをサポートしているのだとか。特にメンションをつけずに、気づいた人がいち早く回答するということを意識しています。

受け入れ側のエンジニア組織メンバーが意識してほしいこと

初日からリモートということも多くなっている状況のため、受け入れる側のメンバーにも、下記のようなことを意識してもらい、オンボードしやすいような環境を意識的に作っています。

・チームのミーティングやはじめましての場合などはリモートで顔を見せる
・紹介の場面など積極的に盛り上げる(過剰なくらいに盛り上げてもらう!)
・当たり前に使っている社内用語は困惑されてしまうので、意識してフォローする
・何かしらのフィードバックを積極的にする

制度を整えるだけでなく、人事としては「話す場」を作ることを大切にしているそうです。自由な風土で風通しも良い環境ではありますが、やはり新しくジョインした人からすると、「質問する」「疑問を解消する」を自由にするというのもなかなかハードルが高いですよね。そのような状況を理解し、制度や仕組みだけではなく、きちんと「場」を作ることでオンボードをサポートする環境を整えているそうです。

また、入社後早い段階でしっかりとフォローすることが、その後の戦力化や組織への馴染み方に大きく影響するとのこと。モチベーション高く入社されてきた方が、いち早くオンボードし戦力となっていくためには、「制度」「仕組み」「場」そして「スピード」が大事なのですね。

堀端さん、ありがとうございました!続きまして、パーソルキャリアの田口さんからのご共有です。

 

「数年で人数1ケタ→70名弱」の部署はオンボーディングで何をしているのか
田口 雄一さん/パーソルキャリア株式会社

プロジェクトマネージャーとして、既存事業の売り上げ向上やコスト削減を目的とした部署の主要プロジェクトを担当するかたわら、オンボーディング業務を始めとした部署メンバーのサポートに携わっている田口さん。数年で規模が大幅に拡大した組織におけるオンボーディングの工夫をご共有いただきました◎

オンボーディングとは

f:id:pcads_media:20210916181316p:plain

そもそも、人事用語における「オンボーディング」とは、企業が新たに採用した人材を職場に配置し、組織の一員として定着させ、戦力化させるまでの一連の継続的な受け入れプロセスを意味し、採用した人材が職場で成果を出せるようになったとき、その採用が初めて意味を持つという考え方に基づいています。

では、従来型の受け入れ対応とオンボーディングのさっくりとした違いを見てみましょう。

f:id:pcads_media:20210916181355p:plain

オンボーディングが重要視されている背景には、新入社員の早期離職を防ぎ、早期戦力化するために、継続的なサポートの実施が効果的であるというポイントがあります。 これまでの受け入れ対応では、即戦力としてコストをかけて採用した人材が、企業文化等になかなかなじめず、 期待されたパフォーマンスを上げるまで時間がかかる事が問題視されていましたが、そのソリューションとしてオンボーディングに注力している企業が増えているのだそうです。

オンボーディング成功のポイント

次に、新入社員と受入組織、それぞれが期待することは何でしょうか。 

f:id:pcads_media:20210916181422p:plain

新入社員側は、「新しい職場で活躍したい」「仕事で自己実現したい」などの希望に加えて「自分が業務に馴染むまでのサポートをしてほしい」という期待があるものです。一方で、受入組織側としては、新入社員に対して「会社と部署になじんでもらって成果を上げてもらいたい、長く勤めてもらいたい」という期待があります。この、双方の期待を満たすために、オンボーディングの体制を整えることが非常に重要です。

短期的にも、中長期的にも、新入社員と受入組織の双方の期待値が満たされることがオンボーディングの成功といえます。 採用担当者とオンボーディング担当者はその道筋を作ることが役割、と言えるのではないでしょうか。

オンボーディングにおける3つのキーワードは下記の通り。

・「なじむ」 一緒にはたらく人や組織にスムーズに馴染んでもらう 
・「みにつける」 業務に必要な組織内ルールや知識を身に付けてもらう 
・「たすけてもらう」 受け入れ側の組織のメンバーにも意識してもらい助けてもらう 

離職理由の上位にあるのが人間関係と言われています。 一人にしない、孤独を感じさせない環境作りが重要だと認識しているそうです。

f:id:pcads_media:20210916181455p:plain

田口さん所属部署の組織変遷のプロセスは上記図の通り。中期にさしかかってくると、古くからいた方と新しい方の断層が目に見えてくるのだとか。組織のフェーズにより採用される方も変わってくるため、オンボーディングのやり方そのものや、課題、各アクティビティの中身も変わっていくもの、と考えられます。フェーズによって柔軟に内容を組み替えていきたいと田口さんはいいます。

田口さんは、受入担当として、もし自分が新入社員だとしたら、何をしてもらえたら嬉しくて安心して業務に取り組めるか、何があったら助かったかなどを、入社時を振り返って考えつつ、上長の方とコミュニケーションを取りながら対応を進めていったそうです。

f:id:pcads_media:20210916181520p:plain

実際に実施したオンボーディングは上記図の通り。

・全社オリエン 
入社1営業日目から3日間は全社オリエンをしています。会社ルールなど幅広い内容を学ぶ場を設けます。

・部署オリエン 
プロジェクトと参加者、他部署関係者、情報置き場、など情報量多め。 俯瞰と分かりやすさ、がポイント。 

・1on1 
パーソルキャリアでは1on1が推奨されています。「お時間空いていますか?」的に、 気軽に相談が可能。雑談OKです。

・フォロワー 
何かあったら聞ける相手として、メンターのような立ち位置のメンバーを配置。新入社員の方にも、自走して欲しいので、メンターではなくフォロワーという呼び方にしているそうです。 最大2か月なので途中終了OKです。 

・OJT 
データの特徴、基盤利用ルール、コンプラ注意点、などを習得頂きます。順番はアサイン次第。

 ・技術や知識の研修 
組織と新入社員の方それぞれの課題と照らし合わせて研修を組みます。出来るだけ固定化しないように意識しているそうです。

特に、部署オリエンでは、全体像をある程度みせることが重要。新入社員の方の役割に合わせて、誰が何をしているのか、 何を見ればよいのか、というフックを作ることを意識しているのだとか。 何より大事なのは、受入組織として新入社員の方を中心とした人間関係作りとフォローアップを面倒くさがらない事です。

f:id:pcads_media:20210916181550p:plain

オンボーディング関連アクティビティの流れは上記のようなイメージ。オファー面談をする時点からオンボーディングは始まっているという意識を持っているそうです。配属後、1on1やフォロワーによるサポートで受入組織へのなじみを感じてもらえれば、新入社員の方もやりやすくなります。 また、採用担当者が継続的に月1回の1on1を実施することで、新入社員からのフィードバックを受けつつ、プロアクティブにミスマッチの解消を図ることができます。

まとめ

オンボーディングで大切なポイントは以下の4点。

・新入社員の方と受入組織、双方の成功がオンボーディングの成功 
・新入社員の方にとっての安心を考えて各アクティビティを行う 
・アクティビティは組織の課題やフェーズに合わせて新しくする 
・他の人や他の部署に怖がらずに聞きにいく

受入側が、自分が新入社員だった時の気持ちを思い出し、新入社員・受入組織の双方の期待を満たすような仕組みと制度を整えていくことで、スムーズなオンボードを実現しているそうです。

続いて、BuySell Technologiesの今村さんからお話いただきます!

 

心理的安全性を意識したオンボーディングでの取り組み
今村 雅幸さん/株式会社BuySell Technologies

2006年ヤフー株式会社に入社。2009年に株式会社VASILYを創業し、取締役CTOに就任。2017年にVASILYをスタートトゥデイ(現ZOZO)に売却し、会社統合とともに2018年4月、ZOZOテクノロジーズの執行役員に就任。CTOとして幅広くZOZOのDXを推進されてきました。2021年4月株式会社BuySell Technologiesの取締役CTOに就任され、日本CTO協会理事も務めています。

今村さんからは「心理的安全性」をテーマにオンボーディングについての取り組みをご共有いただきました!

効率的なチームづくりで必要なこととは

f:id:pcads_media:20210916181700p:plain

Googleが効果的なチームの要因はなにかを突き止めるために、社内の180のチーム(エンジニア115/営業65)を調査対象とし、実施したProject Oxygenでは、「誰がチームのメンバーであるか」よりも「チームがどのように協力しているか」が影響していることがわかりました。その中でも、「心理的安全性」が最も重要な要素であることを突き止めたそうです。

では、「心理的安全性」はどのように醸成すれば良いのでしょうか。大切なのは2つの「知る」。

・人を知る:一緒にはたらく人や組織にいかにスムーズになじめるか
・業務を知る:業務に必要な組織内ルールや知識をいかに早く身につけてもらうか

スムーズに心理的安全性を醸成し、組織にオンボーディングしてもらうため、BuySell Technologiesでは、様々な工夫をしています。今回のイベントでは実際に導入している5つの工夫を紹介いただきました!

①「入社したらまずここをみるページ」を作成

新入社員向けに、初日にやるべきことなどを網羅したページを作成。各種ツール、勤怠、案内、心構えなども合わせて説明するようにしています。

②Slackでの案内

f:id:pcads_media:20210917145100p:plain

Slackに新しいメンバーがJOINしたら、メンバーに紹介されるような仕組みを作っています。新入社員本人には、さきほどの「入社したらまずここを見るページ」の案内が出るようになっています。

③人に知ってもらう

受入側のメンバーに知ってもらうために下記のような工夫もしています。

・チーム内顔合わせ
・歓迎会(ランチ /  Zoom飲み)
・部内定例(業務に関わらない内容も書くことで、その人の人となりを知れるように工夫)
・コンフルの自己紹介ページを作成

④日報

ある程度フォーマットに沿って書いてもらい、メンターとは日報でコミュニケーションを取れるようにしています。例えば、下記のような内容を記載しています。

・やったこと
・できなかったこと、ハマったこと
・今日の感想 / メモ
・個人的なこと
・聞きづらいこと、困っていることなどについてアドバイス

⑤Discordの活用

f:id:pcads_media:20210917145122p:plain

基本的には、チームメンバー全員がDiscordで待機している状況をつくっているそうです。こちらは、帰属意識の醸成に加え、オフラインに近い状況をオンラインで整えるために活用しているのだとか。何か疑問が生じた時や、必要な時に気軽に話しかけられるように常にメンバーがDiscordに集合するような仕組みを整えています。

その他にも、業務を知ってもらうためにも、下記のような取り組みを実施しています。

・バイセルのビジネスフローの説明
・組織目標の共有(本部、部、チーム目標の共有)
・組織の説明

また、新卒向けにはトレーナー・メンターの配置を実施し、技術的な面での支援をするトレーナーとキャリア面での支援をするメンターの2人体制で、オンボーディングをサポートしています。

まとめ

BuySell Technologiesでは、オンボーディングにおいて下記の3つのポイントを大切にしています。

f:id:pcads_media:20210917150339p:plain

①「心理的安全性」の醸成
→相互理解を深める
→コミュニケーション接点をとにかく多くもつ

②どんなに優秀な人材でもオンボーディングが大事
→スーパーマンだから勝手に活躍する、は基本的に無く、誰にとってもオンボーディングは大切

③1ヶ月~3ヶ月を目安に1つ目の成果を出せるように意識
→周囲の人が、この人は何をする人かを認識することができる
→この成果が、その後のパフォーマンスに影響してくる

「心理的安全性」はオンボーディングにおいて最も重要なキーワードの一つなのではないでしょうか…!「心理的安全性」が確保されてはじめて、安心して質問をしたり、業務に取り組んだりできるようになりますよね。受入側は、このような視点も持って受入準備を進めるのが良さそうですね。

まとめ

イベントレポートは以上となります!登壇者の皆さま、ご参加頂いた皆さまありがとうございました◎リモートワークが当たり前となった環境において、いかにスムーズに新メンバーをオンボードさせるか、は各社が課題に感じているところではないかと思います!ぜひ、今回ご紹介いただいた制度や仕組みをお試しいただければ幸いです。
ここからは、当日のQ&Aを紹介します♪

>>次のページへ


参加者からの質問

“(Q)オンボーディングにおいて、リモートワークになって難しくなったこと、逆に上手く進んだこと。お聞きしたいです。”

堀端さん:難しくなったことの方が多いです。最初は気軽に聞けるというのが大切。チャットだとタイムラグがあるので、そこが困るところですね。初日だけは出社して、すぐ隣でメンターに聞けるようにする工夫をし、最初のつまずきをなくすようにしています。うまく進んだことは、開発全体の共有会が増えたことです。発信が増えました。

田口さん:難しくなったこととしては、気軽な相談やアイデア出しがしづらくなった事が挙げられます。とりわけ、コロナ以降の入社社員とのコミュニケーションの難しさを感じています。うまくいったことは、自己の業務に集中しやすくなりました。プロジェクトマネジメントはリモートの方がやりやすいかもしれないです。

今村さん:帰属意識の醸成が難しくなりました。一人一人の表情・健康状態(メンタル面含む)を確認するのが大変になりました。うまく進んだこととしては、会議において事前にアジェンダがしっかり設定されるようになったことや、議事録も残されるようになったことです。

“(Q)オンボーディング方針や推進は全社横断?部署毎?”

堀端さん:完全に部署毎です。開発組織で「こうやる」というのが多いです。営業だと研修もします。

田口さん:全社と部署の2本立てでやっています。また、部署毎にミッションが違うので、そもそものスキル要求が異なります。

“(Q)ちゃんとオンボーディングできているかどうか、何かしら評価の指標を設けているようであればお伺いしてみたいです。”

堀端さん:離職に関しては設けています。短期離職は減りました。

田口さん:具体的な指標は設けていませんが、定量ベースでは離職数、定性ベースではメンバー動向などが考えられるかもしれません。

“(Q)オンボーディングに前向きじゃない組織の考え方を変えるにはどうしたらいいですか?”

堀端さん:課題がどこにあるのかにもよります。短期離職が増え、戦力になるまで時間がかかっている等の観点ごとに考えています。課題ごとにアプローチをするとよいかもです。

田口さん:組織にとってのゴールやミッションをどう捉えているのか、ここを論理的に説明できることや具体的なコストで話せることが大事かと思います。組織なりの課題があると思うので、忖度しつつうまく取り組むことが大切です。

“(Q)田口さん>非常にしっかりした取り組みですね。完全にルール化されていますでしょうか?部署や職種ではなく、極論、その人その人の性格によって対応も異なるのかなとも思いまして。”

田口さん:完全なルール化はしていません。私の裁量でやっているところもあります。その人にあわせたメニューを考えています。

“(Q)田口さん>その人にあっているかどうかはどのように判断されていますか?”

田口さん:地道にコミュニケーションするのみ。関係者からも話を聞いてみることと臨機応変に対応することが大事だと思います。

“(Q)今村さん>CTOの立ち位置でオンボーディングに携わるのは珍しく感じます(良い意味で)トップダウンだからこそ進めやすい点(ボトムアップだったら難しかっただろうなっていう点)はありますでしょうか?”

今村さん:色んな導入はトップダウンがやりやすいです。ボトムアップだとセキュリティや費用対効果の説明が大変だろうなと思うので。トップが新入社員へ気配りする姿をみせることが大切だと思います。

“(Q)これ(入社したらまずここを見るページ)うちもあるのですけど、情報詰め込みすぎていて結局読みきれないでしょみたいな状態になってしまっています。どう整理しているのか知りたいです。”

田口さん:「入社後見るページ」、私共も用意しています。内容は出来るだけ「配属後初日に目を通しておいて欲しいこと」に絞っています。それ以外の内容はカテゴリ別に別ページに切り出しておいて、前述の初日に見るページからリンクを張り、後から辿れるようにしています。コンパクトにする事がポイントかもしれません。

今村さん:いくつかカテゴリ分けしています。入社初日にみるので、「今日やって欲しいこと」項目があります。その次に会社のルール(勤怠や座席表)など大カテゴリにしています。最後に「業務」に必要なリンク集など。カテゴリ・優先度順に見やすい工夫をしています。

“(Q)Discordの空間をつくるコツってなんなのだろう?環境?雰囲気?作りのコツが知りたい。”

堀端さん:Discordについては、エンジニアメンバーの提案からスタートし、いきなり開発組織全体に適用せず、とあるチームで、お試しでやってみました。
そこから、使いたいチームは使ってみてくださいと言った感じで任意にしています。
使ってみたメリットやデメリットなどの感想を、みんなが見える場(Slack)で共有したりしています。

“(Q)成果の定義を知りたいです。数字的な面でしょうか。”

田口さん:オンボーディングの成果って確かに見えづらいですよね。①長期的には事業の成長(いわゆる経営数字)と認識していますが、②短期では離職率や人数が分かりやすいかも知れません。(ただしミスマッチ以外の理由による離職も一定の割合ありますよね)

イベントレポートは以上となります!次回のイベントレポートもお楽しみに◎

Community Members

さまざまなテーマで事例や知見を学ぶ
IT・テクノロジー人材のための勉強会コミュニティ

①上記ボタンをクリックするとTECH PLAY(外部サイト)へ遷移します。

②TECH PLAYへ遷移後、アカウントをお持ちでない方は、新規会員登録をお願いいたします。

③TECH PlAY会員登録後、TECH Streetページよりグループフォローをしてください。

今後のイベント参加・メンバー登録に関する重要なお知らせはこちら