こんにちは。BIGLOBE Style編集部です。 今回は、2021年7月にリリースしたモバイルサービス「donedone（ドネドネ）」のシステム開発から運用・保守までを担う濱野 桂のインタビューをご紹介します。 ※ 「donedone（ドネドネ）」は2023年8月31日をもってサービスの提供を終了しました。 月額利用料の一部を継続的に社会貢献団体に寄付（ドネーション）するサービスとして注目を集める「donedone」は、新たな組織体制で日々進化を続けています。その挑戦をリーダーとして支える濱野は、この環境を「宝の山」と表現します。 その言葉の背景とは？ そして、この仕事のやりがい、BIGLOBEの働く環境・カルチャーなどを伺いました。 エンジニアの枠を越えて仕事ができる、自社サービスの魅力 課題はある。だからこそ、エンジニアとして挑戦できることがある 組織がより良く変わるための準備ができている 何があっても「楽しむ」ことを大切に   エンジニアの枠を越えて仕事ができる、自社サービスの魅力 濱野 桂（はまの けい） 基盤本部　基盤系システム部　システム戦略グループ　グループリーダー 2000年から業務委託先（NECグループ会社）としてBIGLOBE事業へ携わる。 2019年10月ビッグローブ株式会社へ中途入社。現在に至る。 ※撮影時のみマスクを外しています。   —— 今回は主にBIGLOBEのモバイル事業に関わるポジションを紹介したいと思います。まずは、どんな方に向いてる仕事なのかを教えてください。   システム開発の経験を活かして、エンジニア視点で自社サービスを一緒に盛り上げてくれる仲間を求めています。 私が関わっているサービス「donedone」は、ドネーション型モバイルサービスという新しい領域で事業を展開しているので、現場で言われたモノだけを作るのではなく、エンジニアとして自らの意見やアイデアをどんどん発信していけるような方と一緒に仕事がしたいですね。 コロナ禍のリモートワークやオンライン対応で通信インフラはより身近なモノになりました。業務知識やISP・モバイル分野の経験があるに越したことはありませんが、それよりも、新しい自社サービスを一緒に盛り上げていこうという気持ちを共にしてくれると嬉しいです。   —— 現在はどんな方がdonedone事業で活躍していますか？   BIGLOBEがNECの一部門だった頃から携わってきた人も多いのですが、中途で入ってきたメンバーも多く、出身業界は多岐にわたります。例えば、自社サービスに携わりたいという想いを持ったSIer出身者や、不動産業界出身者などもすぐにフィットしてくれました。多少なりともPMやリーダーのイロハを知っていれば問題なく入っていけると思っています。   —— 濱野さんはどういう経緯で入社されましたか？   私はもともと業務委託先という形でBIGLOBEのプロジェクトに携わっていました。BIGLOBEの中のことを知っていたからこそ、ここで働きたいと思ったのがきっかけで、2019年10月に入社しました。   —— 外からBIGLOBEを見ていて、そして実際に入社してみて印象は変わりましたか？   外部のパートナーと社員が一緒に連携しながら仕事を進める会社だったので、社員になった後でもいい意味で印象の違いはありません。ただ、私自身の責任感ややる気はだいぶ変わりましたね。パートナーとして請負の仕事をしていた時は、要件通り言われたことを納期に納めることが役割だったのと、私は社員ではないからと一歩引いた立ち位置で動いていたかもしれません。しかし、自社サービスを持っているBIGLOBEに入ってからは、サービスを良くしていこうと自分を奮い立たせたり、より自分のやりたいことを表現するようになりました。   —— そこは、外部パートナーと社員の働き方の違いでもあるかもしれませんね。   Slerさんに今いる方ならわかってくれるかもしれませんが、請負の仕事だとあまりニーズがないものでも依頼されたら作らないといけないケースがありますよね。もちろん、作ってみたら売れることもありますが、せっかく開発者でいるなら、自分が欲しくなるモノを作りたいというのが本音です。BIGLOBEにはそれができる環境があると言っても過言ではなく、安定的な事業基盤がありながら新しいことにチャレンジしていく企業文化と、それを理解してくれる周りの人たちがいます。特に私が在籍しているような新しいモバイル事業開発に携わる部署では企画段階から話をはじめ、エンジニアサイドなのに販促についても議論するなど開発者の枠を越えて仕事ができるのもやりがいにつながります。   課題はある。だからこそ、エンジニアとして挑戦できることがある —— 濱野さんは入社後、どんなプロジェクトに関わってきたのでしょうか？   基本的には開発プロジェクトのマネージャー、アーキテクチャー設計などの業務を担当し、プロジェクト全体を俯瞰して見るような役割を担っていました。入社後は今とは別のプロジェクトに入っていましたが、新規サービスである「donedone」の運用・保守が私の所属する基盤本部の管轄になり、関わることになりました。   —— 「donedone」に関わることになり、濱野さんはどう感じましたか？   最初は、「どんな人が買ってくれるんだろう？」と心配だったのが正直な感想でした（笑）。でも、サービスの中身を知ると、お客さまへのメリットや「donedone」の企画意図が見えてきて、とても興味深いコンセプトだとわかりました。具体的には、モバイルの月額利用料の一部を継続的に社会貢献団体に寄付＝ドネーションする仕組みや、通信は大容量を使いたいけど高すぎると感じているお客さまにミドルの価格帯で提供できる点などです。 弊社は今まで培ってきたBIGLOBEモバイルとしての強みがあります。その基盤を活かしながらエンジニアとして「donedone」をもっと活用して新しいことができるんじゃないかと私自身も考えるようになりました。 2021年7月にリリースしたばかりのサービスなので、運用・保守をいかに効率的にやっていくかという課題はありますが、逆に言うと「宝の山」なんですよね。 どの改善に優先的に取り組めばプロダクトの価値が上がるかを考えながら、 一番上流のコンセプト設計含め、ゼロベースでアイデアを出せる。極論、自分が欲しいモバイルサービスを作るという気持ちで仕事ができる環境です。   —— 「宝の山」という表現が素敵ですね。課題があっても、そこをクリアしていけばきっといいサービスになるという感じが伝わってきます。   私は「自分が納得いくまで作る」くらいの気持ちで仕事をしています。他社にマネできないサービスだと思うので、皆さんともそこを一緒に考えたいですね。   組織がより良く変わるための準備ができている —— 現在BIGLOBEでは、新しい組織体制を作り、より良いサービスを生み出すための環境整備を進めています。その点はどう感じますか？   新しいサービスについて皆で一緒に考えること自体が、 Agility を高める手法の1つです。   組織体制についてはこちらの記事もお読みください。 style.biglobe.co.jp   昔からときどきアジャイル的に開発をしていたので、必要なエッセンスは揃っていると思います。よく言われる朝会、業務の振り返り、タスク管理の手法など、コミュニケーションを重視することも当たり前のように行っていました。   でも、意見を言える環境があっても、伝えたときにはすでに遅しということもありました。例えば、「このサービスを売るためにこんな販促をやりたい」と話が出たとします。それに対して開発サイドが「作るのが複雑な割に効果が薄くコストパフォーマンスも悪い」と思ったとしても、以前では納期が決まっていて後戻りできない段階だったなんてことも。 今回進めているプロダクト中心の組織では早い段階で話が来るので、「この販促はやめよう。こちらの方法なら効果が出る上に、作るのが早いよ」みたいなことを一緒に考えられて、関わる皆がお互いにハッピーになれたということがありました。逆に、エンジニアの方から「自分たちが大変になるけど絶対こっちの方が売れるからやろう」と提案したこともあります。社内にはいろいろなエキスパートがいて、その人たちが議論を交わし、ダメ・悪いも正直に言える環境になったかなと思います。 あと、2019年に ビッグローブマインド が導入されたこともプラスに働いています。   —— どういうことでしょうか？   どの企業も行動指針がありますが、言葉があってもいざやろうとするとできないケースはあると思います。いや、その方が多そうです。しかし、BIGLOBEは、必要とするマインドを会社がただ言っているだけではなく、実現できる組織になってきているところがいいですね。 www.biglobe.co.jp   例えば、BIGLOBEでは「トガる」というマインドを大事にしていますが、チャレンジを推奨してくれる傾向が強いので、トガッたサービスを考えさせてくれる土壌ができてきました。また、「チームビッグローブ」というマインドは、皆でいいプロダクトを考え議論をすることを大事にすることができてきています。 まとめると、組織を変革している時期で大きなチャンスがあり、そのための自社サービスもあるし、組織体制の強みもある。課題はあれど、至るところに「宝の山」があるので、このタイミングで加わることは、とても面白いと思います。   何があっても「楽しむ」ことを大切に   —— 濱野さんご自身は今後どのようなビジョンをお持ちですか？   私が一番大事にしているのは「楽しむ」ことです。どんな困難なことがあっても笑っていられるのが強みかもしれません。例えば、トラブルや障害があっても笑って対応できるんです（笑）。もちろん怒られることもありますが、なんか燃えるんですよね。 BIGLOBEでも障害が起こってしまうことはあります。しかし、いかにそれを改善していくかが重要なので、大変なときこそ落ち込むのではなく、前を向いて笑ってやろうという周りの先輩やメンバーからの教えに救われました。だから、私もそのマインドを継承できたらなと思っています。   —— 最後に、この記事を読んでいただいた方にメッセージがあればお願いします。   エンジニアと企画者が一緒に考えるサービスを私は最高だと思っています。今回は、それを一緒に考える仲間を募集しています。この活動を楽しくワクワクしながらやりたい、他社にはマネできないサービスを作りたいのです。今まで自分の好きなモノを作れなかった開発者で、内に秘めている想いがある人はきっとやりがいを持って働けるはずです。   —— 本日はありがとうございました！   当社では一緒に働く仲間を募集しています。 ご興味のある方はこちらの採用情報をご覧ください。 （当部門の募集は終了しました） hrmos.co   「donedone」関連記事はこちら。 style.biglobe.co.jp style.biglobe.co.jp   ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部です。   企画したプロダクトの機能や性能を決める要件定義は、サービス開発プロセスの中でも重要な工程の一つです。数多くいるステークホルダーが要件に合意することは、とても難しいことだと知られています。そこで、BIGLOBEでは「RDRA（ラドラ）」というモデルベースの要件定義手法を導入しています。   今回の記事では、「プロダクト全体像を把握」し「社内ステークホルダーとの合意形成」を実現したRDRA導入の効果を、DX推進部サービス戦略グループ主任の勝田 隆弘が紹介します。   ステークホルダーには、もちろん社内のエンジニアも含まれます。基盤系システム部 基盤横断システムグループ グループリーダーの西 秀和も加わり、エンジニア目線での「これまでの課題」「RDRA導入の現場における効果」「さらに良くしていくために取り組むこと」について、対談形式でまとめました。ぜひご覧ください。   ※撮影時のみマスクを外しています。   要件定義を、早く・漏れなく・誤解なく関係者と合意する 業務設計の属人性を無くし、議論するベースを作る RDRAができれば、どの領域に行っても活躍できる人材になれる RDRAを組織文化として根付かせていく   要件定義を、早く・漏れなく・誤解なく関係者と合意する   —— 勝田さんは昨年10月に「BIGLOBE RDRA導入後の要件定義の変化」というテーマでセミナーに登壇されています。まずは、その内容も踏まえRDRAについて教えてください。   勝田 ：RDRA（Relationship Driven Requirement Analysis）とは、株式会社バリューソースの神崎善司さんが提唱されている柔軟で精度の高いモデルベースの要件定義手法です。詳しくは神崎さんのサイト（ http://rdra.jp/ ） をご覧ください。   BIGLOBEのプロジェクトの多くは、自社が提供しているプロダクトの成長・維持を目的とした改修案件です。その要件定義フェーズにおいて「プロダクトの変更点をいかに早く・漏れなく・誤解なく関係者と合意できるか」は重要なテーマの1つでした。   それを解決する手法として最適だと思い導入したのが、RDRAです。 勝田 隆弘（かつだ たかひろ） DX推進部　サービス戦略グループ　主任 2009年に日本電気株式会社（NEC）へ入社、NECビッグローブ配属。 2021年3月まで業務設計チームで個人向けインターネット接続サービスの販売契約管理、会員管理を中心とした業務要件定義に従事。 同年4月よりDX推進部へ異動。2025年の崖対策を目的としたサービス戦略策定に取り組みながら、並行して業務設計チームの支援を担う。   勝田 ：導入の狙いやその後の効果としては、大きく2点挙げられます   ■プロダクトの全体像を把握   私が担っていた業務設計のチームでは、5年くらい前までプロダクトの要件定義のプロセスやノウハウはメンバーによって異なっていました。さらにはプロダクト全体像を管理するためのドキュメントが確立されていない状態で進められ、いわゆる属人化が進んでいました。組織が大きくなり人事異動などが発生するとブラックボックス的にわからない部分ができてしまい、プロダクトの全体像を把握するのが困難という課題が発生していたのです。そこで、プロダクト毎にRDRAモデルによる仕様マスタを作成することで、効果的な業務管理を実現しました。   ■要件定義を取り巻く社内のステークホルダーとの合意形成   プロダクトの要件定義は、関わる他部門のメンバーと協議することが大切です。その点、先ほども触れた通り、過去には属人的な課題があり、確認資料や合意形成ツールがバラバラで悪循環を生むこともありました。RDRAモデルにしてからは、記法を統一することで「業務プロセスの中のこの部分が今回変わるんですよ」など、変更や改善点を指差しで示して確認できるため理解が早くスムーズになりました。   —— ありがとうございます。それを踏まえ、エンジニア目線で何が今まで課題だったのか、何が良くなったかなどを基盤系システム部の西さんにも入っていただき聞いてみたいと思います。 西 秀和（にし ひでかず） 基盤本部　基盤系システム部　基盤横断システムグループ　グループリーダー   西 ：まず、勝田さんが担っていた業務設計チームについて知りたいです。他社さんではあまりない部門なのかなと思うんです。   勝田 ：私も入社してから配属された部署だったので、最初は何なんだろうと思いました。しかし、今となって感じるのは、ここがBIGLOBEの強みのひとつなのではということ。本来この領域はSIerなどの外部エンジニアが要件をヒアリングして開発するというパターンが多いのですが、それだと何かを変えるたびにSIerにお願いする必要があります。その結果、自社サービスプロダクトなのに私たちの中にノウハウや知識がたまらないという課題ができてしまいます。本来は自社のプロダクト企画側で、このフェーズができれば望ましいのですが、そうはいかないケースも多いですよね。   西 ：システムも業務も全部任してしまうとベンダーロックインですね。自分たちの会社のプロダクトなのに、自分たちが知らない状態になってしまう。   勝田 ：そこで、今は自分たち業務設計チームが要件を作って開発しているので、何か改善しようと思った時にすぐに対応できるのです。組織内に、この部門がある価値はそこかなと思います。   業務設計の属人性を無くし、議論するベースを作る 西 ：RDRAを導入したのは、その業務設計部門をより機能させるためですか。 　 勝田 ：そうですね。昔の業務設計フェーズはその道のベテランの頭の中だけに「こうすればいい」というのがありました。だから、その人たちの見解を聞いたり、過去に行った案件のことを思い出したりといった方法に頼っていると、管理するサービスが増えたときに大変な状態になってしまいます。   また、BIGLOBEは業務フローを重視する会社ではあったので、RDRA導入前から業務フローを中心にどうプロダクトを管理していくべきかという課題意識もありました。   西 ：業務フローさえしっかりあれば「ここは何をやりたいんですか」と質問ができますよね。勝田さんは実際にRDRAの導入をどう感じていますか？   勝田 ：自分たちのやりたいと思っていることがしっかり要求通りに実現できているのかどうかは、今までは見えにくいところがありました。それをリリースする前に確認して意識を合わせられること自体に価値があると感じています。   西 ：エンジニアサイドからすると、今までの経験上、要件が矛盾した資料が出てくることが一番の困りごとでした。最後の最後で「すみません、この仕様だと実現できません」みたいな話で。その点、RDRAだと全体の関係性がわかるので、とてもいいなぁと思っています。   勝田 ：おっしゃるとおり、 要件の関係性についての表現力は強みですね。   RDRAができれば、どの領域に行っても活躍できる人材になれる   西 ：RDRAを導入してから、新しい人が来たときの対応の仕方などは変化がありましたか？   勝田 ：昔に比べると、話を進めやすくなりましたね。以前は、新人が入ってこの仕事をしますとなったときに、担当するプロダクトのことを伝えるベースになるものがなかったので教えるのが大変でした。そのため、初期導入の勉強も現場で案件を進めるのも、過去の事例を出して参考にしながら要件定義を進めていました。しかし、それでは人が育ちません。RDRAがあることで要件を理解する基礎ができ、その後の進め方もある程度システマチックに説明できる状況になったことは成果なのかなと思います。   西 ：その点、ベテラン社員への影響はいかがですか？   勝田 ：課題やリスクの洗い出しを経験だけに頼る、といった場面が減りましたね。結局、RDRAは頭の中にあることを都度アウトプットさせられるので、個々人の本能的な危機察知能力みたいなものだけに頼らず、論理的かつ網羅性を持ってまとめられるからです。結果、上司や案件を遂行する人への説明がとてもしやすくなり、納得感も得られやすい共有ツールとして効果的に機能するようになりました。   西 ：業務フローでマスター化されたものがあるのは、いいですよね。昔はホワイトボードを使って説明していて、その人の好みによって書く記号や説明の仕方が変わったりしましたから。でもその点、RDRAの表記方法も独特ですよね。最初、抵抗感はありませんでしたか？   勝田 ：最初は抵抗感だらけでしたよ（笑）。情報量も、やるべきことも急に増えたので。ただ、そのフェーズを乗り越えられたのは、RDRAを使うことでメリットがあるとわかったからです。こういうふうに書けば自分たちの言いたいことをうまく伝えられる、議論が深まるということを根底で理解できました。だから、新しく入ってくる方も最初は“やるべきことの壁”にぶつかるかもしれないので勉強は必須です。   西 ：何でも直感でできればいいのですが、基礎が理解できれば要件定義をより正確に進められるようになりますよね。   勝田 ：そうなんです。あとは、RDRAができると自身のキャリアにとっても有効だと思っています。例えば、私はDX推進部に異動になって「DXって何をするの？」となって調べていく過程で、要件定義や要求分析などの進め方やまとめ方の知見が活かせると感じました。対象領域の専門知識を入れ換えさえすれば、要件を整理するところのプロセスはあまり変わらないからです。   また、自分がこういうことをできるんですよということを、自信を持って言う根拠にもなります。例えば転職するときに「私、業務設計できます」と言ったとしても何ができるんだろうってなりますが、「RDRAができます」と言えばわかりやすいですよね。   西 ：エンジニアは「こんな言語ができます」「こんなプロジェクトをやりました」と、わかりやすいのと同様に、業務設計もRDRAがわかると言えることで自信になりますね。   勝田 ：RDRAを実践することは、どの領域に行っても活躍できる人材になる可能性があるという道筋を示していると思います。   RDRAを組織文化として根付かせていく   西 ：勝田さんご自身が今後やりたいことはありますか？   勝田 ：要件定義のさらに上流領域の、何が目的で何をやりたいんだっけといったことを考える機会を増やしたいと思っています。要求分析を整理してアウトプットし、RDRAモデルを繋げて、私たちがやりたいことはこういうことですと話せるようなイメージです。今ある強みを発揮し組織の力になれればいいですね。   西 ：本来やりたかった企画と開発の橋渡しの部分にもさらに集中できそうですね。その他に個人的に「これは本当はもう少しやりたいんだけど、できていない」といったことはありますか？   勝田 ：業務設計チーム内でRDRAを通じてさらに理解を深め、同じ目線で会話できるようになることです。結局、良い結論を下せるか否かは最終的にその人のスキルに依存してしまうところがまだあります。そのため、同じレベルで議論ができる人を増やすことが重要で、社内でそのような環境を作っていくことはずっと気にかけているところです。   西 ：議論のベースができてしまえば、理解するのに使った時間を「考えること」に使えるので、頑張ってRDRAを広めていきたいですね。組織文化として根付いていくまで。現在、サービス開発の”Agility”にこだわっていくために、企画・推進・設計・開発を一体化できるよう組織体制を見直しているところなので、私もRDRAの普及活動をしていきたいと思います。   —— 組織文化として根付くと、より良いプロダクト作りにも活かせそうですね。本日は素敵なお話、ありがとうございました。     BIGLOBEでは、共に挑戦し成長してくれる仲間を募集しています。 ご興味のある方はこちらの採用情報をご覧ください。 （本募集は募集は終了しました） hrmos.co ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。 style.biglobe.co.jp  

基盤本部（開発部門）の木下です。Java 17 の新機能を使って、ドメイン駆動設計（Domain Driven Design: DDD）のモデリングの表現力を高める例をご紹介します。 皆さんは「事前条件が OK ならデータベースを更新する」というロジックを、クリーンアーキテクチャのどのレイヤーに実装していますか？ 事前条件はドメイン知識なのでドメインサービスに実装したいところですが、リポジトリーを操作するアプリケーションサービスの中に書かれることも多いのではないでしょうか。 クリーンアーキテクチャー。 https://style.biglobe.co.jp/entry/2020/02/13/150709 より引用 この記事では、ドメインサービスとアプリケーションサービスをきれいに分離するために、Java 17 で正式導入された interface の sealed と permits を活用する方法を実例を使いながら段階的に説明していきます。 ポイントは「条件チェック OK の型」と「NG の型」を一つの型として扱う代数的データ型（Algebraic Data Types）の導入です。さらに Java 17 のプレビュー機能である switch のパターンマッチングを使えば、代数的データ型を使った分岐を、安全かつ分かりやすく記述できることも示します。 まずは、ちょっとイケてない実装例から見ていきます。 ドメイン知識がアプリケーションサービスに漏れ出すイケてない例 ドメイン層 イケてないアプリケーション層 ロジックをドメインに寄せる ドメインで受付処理を実装する fold を使ってアプリケーションサービスを実装する switch のパターンマッチングでアプリケーションサービスを実装する まとめ ドメイン知識がアプリケーションサービスに漏れ出すイケてない例 例として、モバイル契約の料金プラン変更をするユースケースを考えてみます。以下のような仕様だったとします。 3GB, 6GB, 12GB のような複数の料金プランがある 契約していなければプランを変更できない 同じプランには変更できない ドメインとアプリケーションサービスの実装はこんな風になるでしょう。雑ですが簡単のため値オブジェクトやサービスの戻り値の型は String にしています。 ドメイン層 Java 16 で正式導入された record 型を使うことで、イミュータブルなドメインクラスをボイラープレートコードなしで実現しています。 package com.example.domain; // プラン変更のビジネスロジック。プランが同じかどうか判定します。 public record PlanChangeApplication(String contractNumber, String changedPlan) { public boolean isSamePlan(Contract existingContract) { return plan.equals(existingContract.plan()); } } package com.example.domain; // プラン変更イベント。契約番号とプラン名を持っています。 public record PlanChangedEvent(String contractNumber, String changedPlan) {} package com.example.domain; // 契約。プラン名を持っています。 public record Contract(String plan) { public PlanChangedEvent changePlan(PlanChangeApplication application) { return new PlanChangedEvent(application.contractNumber(), application.plan()); } } イケてないアプリケーション層 package com.example.applicationservice; // プラン変更のアプリケーションサービス。事前条件を確認してOKならデータベースへ保存します。 public class PlanChangeService { public String change(PlanChangeApplication application) { Optional<Contract> existingContract = contractRepository.find(application.contractNumber); if (existingContract.isEmpty()) { return "Error: 契約がありません" ; } if (application.isSamePlan(existingContract.get())) { return "Error: 同じプランに変更できません" ; } PlanChangedEvent event = existingContract.get().changePlan(application); contractRepository.persist(event); return "Ok: " + event.changedPlan() + " に変更されました" ; } } アプリケーションサービスである PlanChangeService の change メソッドでは、ドメインオブジェクトである PlanChangeApplication や Contract のメソッドを使ってエラーチェックし、エラーがなかった場合には ContractRepository を使ってイベントを永続化します。 この change メソッドは比較的長いロジックになっていて良くない匂いがします。どういうときにプラン変更が可能かはドメインの知識であるべきですが、アプリケーションサービスに漏れ出していることが課題です。 ロジックをドメインに寄せる ドメインで受付処理を実装する アプリケーションサービスからドメインの知識を追い出し、ドメインサービスで事前条件チェックと適用まで一気にやってしまうことを考えます。そのようなドメインサービスは戻り値に何を返せば良いでしょうか？ やりたいことは、チェックに失敗した場合にはエラーコードを返し、成功した場合には PlanChangedEvent を返すことです。その両方を包含する一つの型が作れればそれがドメインサービスの戻り値の型にできます。 Java ではそのような型は interface によって表現できます。 package com.example.domain; public sealed interface PlanChangeResult permits PlanChangeResult.Changed, PlanChangeResult.Error { record Changed(PlanChangedEvent event) implements PlanChangeResult {} record Error(PlanChangeError error) implements PlanChangeResult {} } Java 17 で正式導入された sealed と permits によって、PlanChangeResult を実装する型はここに出てくる Changed と Error しかないことを表現しています。 このような、いくつかの異なる型を組み合わせてできる型を代数的データ型と呼びます。 またここでの Changed や Error のように代数的データ型が取り得る値の種類をデータ構築子と呼びます。 代数的データ型によって、このような「チェックに失敗した場合はエラーコードを持ち、成功した場合には PlanChangedEvent を持つ」型を表現できます。 なおエラーコードは PlanChangeError という enum で表現することにします。 package com.example.domain; public enum PlanChangeError [ CONTRACT_NOT_FOUND( "契約がありません" ), SAME_PLAN( "同じプランに変更できません" ); private final String message; PlanChangeError(String message) { this .message = message; } String message() { return message; } } 受付をイメージした PlanChangeReception というドメインサービスを作り、PlanChangeResult を返すようにしてみます。 ドメインサービスではリポジトリにアクセスすべきでないため、リポジトリから取得していた existingContract は引数で受け取るようにします。 package com.example.domain; public class PlanChangeReception { public PlanChangeResult apply( PlanChangeApplication application, Optional<Contract> existingContract) { return existingContract.map( contract -> application.isSamePlan(contract) ? new PlanChangeResult.Error(PlanChangeError.SAME_PLAN) : new PlanCHangeResult.Changed(contract.changePlan(application)) ).orElseGet( () -> new PlanChangeResult.Error(PlanChangeError.CONTRACT_NOT_FOUND) ); } } これによって、アプリケーション層にあったチェックのための分岐がなくなります。 fold を使ってアプリケーションサービスを実装する 次にアプリケーションサービスの実装です。 ドメインサービスを呼び出した結果が成功だったときだけイベントの永続化をするというロジックが必要です。 代数的データ型では fold (畳み込み) と呼ばれる操作を使うことでデータ構築子の単位で振り分けることがよく行われます。 PlanChangeResult に fold メソッドを追加します。 package com.example.domain; public sealed interface PlanChangeResult permits PlanChangeResult.Changed, PlanChangeResult.Error { <R> R fold( Function<PlanChangedEvent, ? extends R> handleChanged, Function<PlanChangeError, ? extends R> handleError ); record Changed(PlanChangedEvent event) implements PlanChangeResult { @Override public <R> R fold( Function<PlanChangedEvent, ? extends R> handleChanged, Function<PlanChangeError, ? extends R> handleError) { return handleChanged.apply(event); } } record Error(PlanChangeError error) implements PlanChangeResult { @Override public <R> R fold( Function<PlanChangedEvent, ? extends R> handleChanged, Function<PlanChangeError, ? extends R> handleError) { return handleError.apply(error); } } } これを使ってアプリケーションサービスを実装します。 package com.example.applicationservice; public class PlanChangeService { public String change(PlanChangeApplication application) { Optional<Contract> existingContract = contractRepository.find(application.contractNumber()); PlanChangeResult status = reception.apply(application, existingContract); return status.fold( event -> { contractRepository.persist(event); return "Ok: " + changed.event().changedPlan() + " に変更されました" ; }, error -> "Error: " + error.message() ); } } fold を使うことで変なキャストもなく結果に応じた分岐が記述できました。 しかし fold に 2 つの関数を渡す形になるため PlanChangedEvent に対する処理なのか PlanChangeError に対する処理なのかが若干わかり辛いと言えます。 switch のパターンマッチングでアプリケーションサービスを実装する Java 17 でプレビュー機能となっている switch のパターンマッチングを使うと、より分かりやすく分岐が記述できます。 package com.example.applicationservice; public class PlanChangeService { public String change(PlanChangeApplication application) { Optional<Contract> existingContract = contractRepository.find(application.contractNumber); PlanChangeResult result = planChangeReception.apply(application, existingContract); return switch (result) { case PlanChangeResult.Changed changed -> { contractRepository.persist(changed.event()); yield "Ok: " + changed.event().changedPlan() + " に変更されました" ; } case PlanChangeResult.Error error -> "Error: " + error.error().message(); }; } } switch 式の対象になっているクラスに sealed を指定しているので網羅性のチェックもしてくれます。例えば Error のハンドリングを忘れるとコンパイルエラーにしてくれます。 Scala 等と比べると Java 17 のパターンマッチングは弱いですが、この例程度の用途であれば十分実用的と言えるでしょう。 なお、switch のパターンマッチングはプレビュー機能であるため、コンパイルオプションの --enable-preview で有効にしておく必要があります。 また将来のバージョンで仕様が変更される可能性もあります。 正式導入が待ち遠しいですね。 まとめ Java 17 で正式導入された interface の sealed と permits を活用して代数的データ型を作り、ドメインサービスとアプリケーションサービスを分離する例を紹介しました。 代数的データ型はパターンマッチと組み合わせると安全に分岐を実現でき非常に強力です。ぜひ Java 17 の新機能を活用して代数的データ型を使ってみてください！ www.biglobe.co.jp ※ Javaは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。

BIGLOBE Styleをご覧のみなさま、いつもありがとうございます！ 基盤本部（開発部門）の”中の人”見える化を推進している、基盤統括部の吉川です。 先日開設したBIGLOBE Technology Channel（YouTube）にて、新しいコンテンツが公開されました。その名も「教えてDDD！」 ドメイン駆動設計（Domain Driven Design：DDD）を始めたばかりの初心者から、ある程度わかっている中級者まで、BIGLOBEで働くエンジニアが持っている疑問に、シニアエンジニアがズバッと回答していく様子を、みなさまにもお届けしようという試みです。 今回は、DDDに取り組み始めたエンジニアからの質問「ドメインモデルのつくりかた」と「バリューオブジェクトはいちいちつくるべき？」の2つです。 異なる経歴を持つ3名のシニアエンジニアが、それぞれ質問に対して回答しています。1つの質問に対して約3分で回答していますので、ぜひ、スキマ時間などにご覧いただければと思います。 教えてDDD！で回答するシニアエンジニアの紹介 1人目のスペシャリスト：「BIGLOBEをどうにかする漢」西 1人目のエンジニアは、当ブログにも何度か登場しており、YouTubeでDDDに関するプレゼンテーションを行ったこともある西です。新システム開発はもちろん、DDDを活用して多数の基盤系システムの置き換えを進めています。 ・プログラミング歴20年 ・DDDと出会ってから8年 ・DDD + Java/SpringをBIGLOBEへ導入する 1stプロジェクト を主導 ・DDDを用いた0→1のシステム設計経験(計10システム) ・大手SIerが導入した出来の良くないシステムを置き換え ひとこと 「DDDチョットデキル」 2人目のスペシャリスト：「BIGLOBEのDDD伝道師」村上 2人目の村上は、業務だけでなく自宅のIoT化など、すぐにプログラミングを始める「手を動かすタイプ」のエンジニアです。レガシーシステムのDDD化の取り組みにおいて、プログラミングの実践を数多く経験しており、デザインパターン、アンチパターンなどを、メンバーに伝えています。 ・プログラミング歴19年 ・DDDと出会ってから7年 ・社内外含め4つの組織でDDDメンバーの育成を実施 ・DDD + Java/SpringをBIGLOBEへ導入する 2ndプロジェクト を主導 ・独自言語で作られたレガシーシステムのDDD化も実践 ・データモデル中心の設計に限界を感じていたところDDDに出会い感銘を受ける ひとこと 「成功も失敗もいっぱい経験してるので、泥臭いことまでなんでも答えられますw」 3人目のスペシャリスト：「みんなをDDDに巻き込みたい人」藤田 3人目の藤田は、新しいことに挑戦するのが大好きで、スマートフォンアプリから業務システムまで幅広い技術スタックに精通しています。DDDについてもBIGLOBE初の取り組みを数多く主導してきました。社内エンジニアによる部門を超えたライトニングトーク大会を主催するなど、エンジニアにとって働きやすい環境づくりにも取り組んでいます。 ・プログラミング歴15年 ・100万DL超えのスマホアプリ開発者 ・DDDと出会ってから6年 ・DDD + Kotlinを社内で最初に導入 ・DDD + 委託開発を社内で最初に実施 ・実はJavaよりもJavaScriptが得意 ひとこと 「早く行きたければ、ひとりで行け。遠くまで行きたければ、みんなで行け」 BIGLOBE Technology Channelで公開中！ BIGLOBEでDDDに取り組んできたシニアエンジニアたちが、質問に答えていく「教えてDDD！」 ぜひ一度、ご覧ください！ youtu.be youtu.be youtu.be youtu.be youtu.be ※ YouTubeは、Google LLC の商標です。 ※ Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。 ※ Kotlin は Kotlin Foundation の登録商標です style.biglobe.co.jp style.biglobe.co.jp

BIGLOBE鈴木(研)です。 今回は、久々のリアルイベントに参加したので、レポートしたいと思います。 ■はじめに コロナ禍でVMwareユーザ会（VMUG）のイベントもほとんどがリモートとなり、会員の方とお会いする機会がなくなりましたが、約2年ぶりくらいにイベントが開催されることになりました。 ※UserConというのは、VMUGの1年に1回の総会のようなものです。 参加にあたり、ワクチン2回接種後、1週間経過していることが条件とされました（これを満たさない方はリモートでの参加は可）。 私は、UseConのちょうど1週間前に2回目のワクチン接種をしていて、ギリギリ条件を満たせたので、リアルイベントの方に参加しました。 受付でワクチン接種証明を見せて会場に入ることが出来ました。 下記、イベント情報です。 日時：10/27（水曜日）　13:00-17:00 会場：日比谷国際ビル コンファレンス スクエア 開催形式：会場定員40名＋オンラインのハイブリッド形式で行います。 ※会場への参加に関しては別途案内いたします。 ※会場参加の方は、ワクチンを2回接種後に1週間経過している人が対象となります。（ワクチン接種証明、ワクチン接種証明をスマホで写した物を持参ください。） アジェンダ： 13:00-13:10　会場参加者への案内＋皆さまのオンライン接続確認 13:10-13:30　JAPAN VMUG User/Con開催の挨拶 13:30-14:30　VMware様登壇 14:30-14:40　休憩 14:40-15:10　イベントサポータ様プレゼンテーションPart1（1社5分） 15:10-15:30　ユーザLT１ 15:30-15:50　ユーザLT２ 15:50-16:10　ユーザLT３ 16:10-16:15　休憩 16:15-16:40　イベントサポータ様プレゼンテーションPart2（1社5分） 16:40-16:55　VMUG2021年ユーザ＆サポーターアワード発表 16:55-17:00　閉会の挨拶 18:00-20:00 vBeer ※vBeerとは、VMUGの飲み会のことです ■ユーザLTで発表 ユーザLTの3人目として、私が発表する時間をいただきました。 大勢の人前で話すのが随分と久しぶりで、とても緊張しました。 リモートの方もいるので、Zoomで画面共有をしつつ、会場のモニタにもスタッフのPCのZoom画面を出して発表をする感じになりました。 発表内容は、「仮想基盤の変動費型への移行」というタイトルです。 弊社の仮想基盤の一部を所有→利用モデルにしており、その導入に置いて苦労したことなどを発表しました。 以下で概要を述べたいと思います。 登壇する私 １．なぜ変動費型か？ 一言で言えば、 所有から利用へのシフト です。 会計的な視点でのオフバランス化　※会社の会計の考え方による 上位のアプリに人・物・金の経営資産を集中したい 仮想基盤の維持コスト低減（人、設備、ソフトウェア） ２．変動費型への道のり ２．１．変動費型の検討ポイント 下記があると思います。 利用した分だけを支払う 不良在庫と言う名のリスクは持たない 仮想基盤の運用は、フルマネージドが理想 （とはいえ）価格は外せない パートナ選定のポイント 変動費型のビジネスモデル/ファイナンスプランに対応可能か？ 仮想基盤「利用」のパターンとして、外部リソース型と持ち込み型があると思います。 利用のパターン ２．２．選定結果 弊社は、インフラ持込型の某SIerに決定しました。理由は下記のとおりです。 価格がリーズナブルだった RFIに対して柔軟な提案をしてくれて寄り添ってくれた NetAppHCI（リソース増強の柔軟性） 現行基盤と同じDCにハウジングエリアを持っているベンダで、VM移行がDC内で可能　←インフラ持ち込み型の理由 ハウジング＋仮想基盤をまとめてワンストップ対応可能 ただ、運用はフルマネージドとはいきませんでした。 フルマネージドだと、どのベンダもかなりのバッファを積んでコストが高くなってしまった vSphere/NSXレイヤの管理は、まずは弊社で行って、やることを明確にしつつ、追々ベンダに任せていく ⇒まずは、フルマネージドにこだわりすぎずに 始める ことを優先 ※外部リソース型（VMC on AWS）は運用フルマネージドで良いけど、弊社にとってはオーバースペックでした ３．ハマったこと ３．１．NetAppHCIのEOL 年明け早々に新規にコンピュートノードが買えないという状況になってしまいましたorz NetApp HCI end-of-life timelines https://blocksandfiles.com/2021/03/02/astra-takeover-netapp-hci-eol/ 増設コンピュートノードはNetApp以外から調達することにしました。 もはやHCIではない コンピュートノードの月額は別HWに変更でも据え置きにしてもらった NetApp製サーバ以外との組み合わせテストを、SIerにしっかりしてもらうことにした（HCIと同等の品質の担保） ⇒最小構成で構築中のタイミングで、HWベンダのはしご外しに遭うとは、運が悪すぎた… ３．２．NSX-TでPVLANが使えない 現状、PVLANで複数サービス（お客様）のプライベートLANのマルチテナンシーを実装、さらにNSX-Vの分散Firewall機能で、お客様のFirewall機能を提供しています。 PVLANでのマルチテナンシー確保 当初は新基盤はNSX-Tで行こうと思ったが、現行基盤のVMを新基盤に移行する際に、VM通信断なしでの新基盤への移行は困難と判明し、新基盤もNSX-Vの構成とし、VM移行完了後にPVLANを使っていない状態にしたうえで、NSX-V→NSX-Tに移行する方式としました。 ⇒まさか、NSX-Vで使えていた機能が、NSX-Tで使えなくなっているとは思っていなかった… ⇒某SIerさんが構築前に気づいてくれて助かった NSX-V → NSX-Tの移行方式概要 ※NSX-Vの保守期限が2023/1/16のため、VM移行をNSX-V保守期限までにやる必要があり、タイトなスケジュールとなりそうですorz ４．まとめ 仮想基盤の変動費化は、 会社の会計の考え方次第（自社所有も選択肢の1つ） まだこなれてはいないので、現時点ではそれなりにチャレンジング（SIerの経験もまだ浅い） 上層部を巻き込んだ戦略的なアライアンスモデル、相互の強みを活かして補完し合えるパートナーシップが重要 収容しているお客様のVMへの影響を最小限にするのは大前提となる（お客様は変動費型かどうかに興味無し） と言うところでしょうか。 ■vBeer イベントが終わって、15人くらい（だったか）と別の会場に移動して飲み会に参加しました。 リモート飲み会とは違い、場の空気を楽しめました。VMUGの仲間とは、今まで会えなかった分も含め、いろいろと話をしました。 結局、この日は数人で2次会まで行き、親睦を深めることが出来ました。 飲み屋もちゃんとコロナ対策されていて、飲んでいても安心はできました。 ■おわりに やはり、対面でのイベントは良いですね。リモートイベントとは臨場感が違います。 また、ちゃんと時間を確保して外出するので、リモートイベントの時のように裏で内職したり（強いられたり）しないので、イベントに集中できます。 VMUGの仲間とも会うことができ、元気にしているのが分かり嬉しかったです。その際、ワクチン接種証明は条件になっていくのかなぁと思いました。 今後は、新型コロナが収まって、こういった機会が増えていくことを期待したいと思います。 ※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。 ■お知らせ VMwareユーザ会（VMUG）に興味のある方は、 https://www.vmug.com/membership/membership-benefits から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。 以上です。

開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 基盤本部ではさまざまな勉強会を開催しています。先日も、BIGLOBE Styleでその様子をご紹介しました。 style.biglobe.co.jp 「クラスを増やすの、怖くないですか？」 オブジェクト指向プログラミング（OOP）を学んでいた時に聞かれたことです。業務ではJavaやドメイン駆動設計を活用しているので、クラスベースのOOPが題材になることが多いのです。OOPに慣れていない人からすると、クラスの数が増えることで全体を把握しづらくなったり、適切なクラスを見つけるのが大変になりそう、と感じるそうです。 「大丈夫！クラスを増やしたほうが楽になることがあるよ！」 と伝えたくて、この記事を書かせていただきました。何が楽になるのでしょう？それは、ソースコードを読むこと、です。「クラスを増やすと、ソースコードを読むのが楽になる？？？」とハテナマークがたくさん出てきそうですが、背景を含めて説明していきます。 成長し続けるのがソフトウェアの宿命 繰り返し起こる機能追加を再現してみる 機能追加 1回目（リファクタリングしない場合） 機能追加 1回目（リファクタリングする場合） リファクタリングで構造を直す 機能を追加 さらにリファクタリングをして構造を見直す 機能追加 2回目（リファクタリングしない場合） 機能追加 2回目（リファクタリングした場合） クラスを増やしたメリット・デメリット 書いたソースコードの行数 読んだソースコードの行数 まとめ 成長し続けるのがソフトウェアの宿命 ソフトウェア開発は建築の例えを用いて説明されることがありますが、まったく違うことが1つあります。それは、ソフトウェアは成長し続けることです。建築物は物理的な制約があるので、一度建てたら大きく変更することはできません。その一方、ソフトウェアは作り変えることができます。使ってみて、はじめてやりたかったことが分かったり、どんどん変化するビジネス環境への追随が求められるため、常に作り変える必要に迫られます。 成長を前提とすると「新しい機能をすぐに追加できるかどうか」はソフトウェアにとってとても大事な性質になります。そこで一昔前は、どんな機能が追加されるか先に予測して設計しておく、という戦略が取られました。しかし、未来予知は外れるものです。その結果、ムダな拡張性を持つ複雑なソフトウェアがたくさん生まれてしまいました。その失敗を教訓として、YAGNI（You ain't gonna need it：そんなの必要ないって。必要になったら作ろうぜ）という標語も生まれました。結局は、追加したい機能が明らかになったタイミングで、それをどう実装するか？がとても大事になります。 そして、機能を追加するタイミングでエンジニアの力量の差がハッキリと現れます。ひよっこエンジニアは「スピード優先！」でいきなりコーディングを始めてしまいます。しかし先ほども述べた通り、ソフトウェアは成長し続けるので機能追加は終わりません。今後も機能追加は続きます。今のソフトウェアの構造を見直すことなく、ただ単に建て増しを重ねていくと、複雑さは増す一方です。その結果、後に続く機能追加はどんどん難しくなっていきます。 できるエンジニアは、機能追加をする前に、リファクタリングするのがクセになっています。リファクタリングとは、ソフトウェアが実現する機能は変えずに、内部構造を作り直すことです。できるエンジニアは、これ以降も機能追加が続くことを知っています。なので今後の機能追加が楽にできるよう、一度ソフトウェアの中身を作り直した上で、新しい機能を追加するのです。 リファクタリングをすることでクラスの数は増え、ソースコードの総量も多くなります。しかし、内部構造が整理されてソースコードを読みやすくなるので、結果的に新しい機能を追加しやすくなります。ここからはソースコードを使って具体的な例を示していきます。あくまで簡単な例のため、リファクタリングの有無による効果の違いは微々たるものです。しかし、これが重なっていった結果、大きな違いになっていきます。 繰り返し起こる機能追加を再現してみる 例題として取り上げるのは、とあるデータをHTMLとしてコンソールに表示するプログラムです。first, second, thirdという文字列リストをHTMLで表示します。 期待する出力結果： < ul > < li > first </ li > < li > second </ li > < li > third </ li > </ ul > 最初はメインプログラムにすべてのロジックを書き込んでいきます。 メインプログラム： import java.util.*; import java.lang.*; import java.io.*; import java.util.stream.*; class Main { public static void main(String[] args) { List<String> items = List.of( "first" , "second" , "third" ); System.out.println( "<ul>" ); for (String item: items) { System.out.println( "<li>" + item + "</li>" ); } System.out.println( "</ul>" ); } } 機能追加 1回目（リファクタリングしない場合） 長年、出力するのはHTMLだけで十分だったのですが、JSON記法でも出力できるようにして欲しい！という要望があがりました。 期待する出力結果： [ " first ", " second ", " third " ] ひよっこエンジニアはスピード最優先でメインプログラムに機能を追加します。Mainクラスのソースコードを全部読んだ上で、実装に取り掛かります。コマンドライン引数に--jsonと指定した場合に、JSON形式で出力することにしました。 class Main { public static void main (String[] args) { List<String> items = List.of( "first" , "second" , "third" ); if (args[ 0 ].equals( "--json" )) { System.out.println( "[" ); String output = items.stream() .map(item -> String.format( " \" %s \" " , item)) .collect(Collectors.joining( "," )); System.out.println( " " + output); System.out.println( "]" ); } else { System.out.println( "<ul>" ); for (String item: items) { System.out.println( "<li>" + item + "</li>" ); } System.out.println( "</ul>" ); } } } でき上がったソースコードはMainクラス1つのままですが、機能を追加した分、行数は長くなっています。 機能追加 1回目（リファクタリングする場合） できるエンジニアは、機能を追加するまえにリファクタリングをして構造を直します。複数のステップで見直すため、いきなり機能を追加するのに比べると多くの手間がかかります。けれど経験上、その手間が後々自分を助けることになることを知っています。 リファクタリングで構造を直す まず「これから追加する新しい機能は、既存の機能とどう関係しているのか？」を考えます。今回は、既存の表示機能にバリエーションを加えたい、という要望です。Mainクラスを読み直し、まずは既存の表示機能をHtmlPrinterクラスに切り出してみます。 class HtmlPrinter { void print(List<String> items) { System.out.println( "<ul>" ); for (String item: items) { System.out.println( "<li>" + item + "</li>" ); } System.out.println( "</ul>" ); } } Mainクラスは、切り出したHtmlPrinterを使って次のようになります。 class Main { public static void main(String[] args) { List<String> items = List.of( "first" , "second" , "third" ); HtmlPrinter p = new HtmlPrinter(); p.print(items); } } メインプログラムを、MainとHtmlPrinterという2つのクラスに分けました。HtmlPrinterを切り出したので、Mainの行数は少なくなっています。 機能を追加 リファクタリングが終了したので、JSON形式を出力するJsonPrinterを新しく追加します。 class JsonPrinter { void print(List<String> items) { System.out.println( "[" ); String output = items.stream() .map(item -> String.format( " \" %s \" " , item)) .collect(Collectors.joining( "," )); System.out.println( " " + output); System.out.println( "]" ); } } メインプログラムからJsonPrinterを使えるようにします。 class Main { public static void main(String[] args) { List<String> items = List.of( "first" , "second" , "third" ); if (args[ 0 ].equals( "--json" )) { JsonPrinter p = new JsonPrinter(); p.print(items); } else { HtmlPrinter p = new HtmlPrinter(); p.print(items); } } } さらにリファクタリングをして構造を見直す さて、これでHTMLもJSONも出力できるようになったのですが、もう一度、構造を見直してみます。 HtmlPrinterとJsonPrinterは、リストを画面に出力する、という機能は共通で、出力形式がHTMLかJSONかで異なります。 「リストを画面に出力する」という共通項をPrinterインターフェイスにまとめて、それを実装したのがHtmlPrinter、JsonPrinterである、と定義しなおしてみます。 interface Printer { void print(List<String> items); } class JsonPrinter implements Printer { public void print(List<String> items) { ... } class HtmlPrinter implements Printer { public void print(List<String> items) { ... } その上で、メインプログラムをPrinterを使って書き直します。 class Main { public static void main(String[] args) { List<String> items = List.of( "first" , "second" , "third" ); Printer p; if (args[ 0 ].equals( "--json" )) { p = new JsonPrinter(); } else { p = new HtmlPrinter(); } p.print(items); } } このリファクタリングにより、インターフェイスがPrinterの1つ、クラスがMain、JsonPrinter、HtmlPrinterの3つになりました。 機能追加 2回目（リファクタリングしない場合） HTML、JSONに続き、さらにMarkdown形式を出力することになりました。 期待する出力結果（Markdown）： - first - second - third ひよっこエンジニアは、リファクタリングせずにそのまま機能を追加します。 class Main { public static void main(String[] args) { List<String> items = List.of( "first" , "second" , "third" ); if (args[ 0 ].equals( "--md" )) { for (String item: items) { System.out.println( "- " + item); } } else if (args[ 0 ].equals( "--json" )) { System.out.println( "[" ); String output = items.stream() .map(item -> String.format( " \" %s \" " , item)) .collect(Collectors.joining( "," )); System.out.println( " " + output); System.out.println( "]" ); } else { System.out.println( "<ul>" ); for (String item: items) { System.out.println( "<li>" + item + "</li>" ); } System.out.println( "</ul>" ); } } } クラスの数はMain 1つのままですが、行数はさらに長くなりました。 機能追加 2回目（リファクタリングした場合） 1回目の機能追加で構造を見直しておいたので、今回はMarkdownPrinterクラスを追加すれば終了です。 class MarkdownPrinter { void print(List<String> items) { for (String item: items) { System.out.println( "- " + item); } } } そして、MainでMarkdownPrinterを使えるようにします。 class Main { public static void main(String[] args) { List<String> items = List.of( "first" , "second" , "third" ); Printer p; if (args[ 0 ].equals( "--md" )) { p = new MarkdownPrinter(); } else if (args[ 0 ].equals( "--json" )) { p = new JsonPrinter(); } else { p = new HtmlPrinter(); } p.print(items); } } 結果的に、インターフェイスがPrinterの1つ、クラスがMain、MarkdownPrinter、JsonPrinter、HtmlPrinterの4つに分かれました。 クラスを増やしたメリット・デメリット さて、スピード優先でリファクタリングをしなかった場合と、リファクタリングでクラスを増やしてから機能を追加した場合で比較してみます。 書いたソースコードの行数 リファクタリングしない リファクタリングする Main 23行 14行 Printer - 3行 HtmlPrinter - 7行 JsonPrinter - 10行 MarkdownPrinter - 7行 合計 23行 34行 ソースコードは、リファクタリングをしない方が、リファクタリングをした場合よりも11行短くなりました。 リファクタリングしない リファクタリングする 2回目の機能追加で書いたソースコードの行数 Main 5行 MarkdownPrinter 7行、Main 3行 合計 5行 10行 Markdownによる出力を追加した2回目の機能追加ですが、書いたソースコードの行数はリファクタリングをしない方が、リファクタリングをした場合よりも5行少なくて済みました。 書く量が少ないので、実はひよっこエンジニアのアプローチが優秀なのでは？と思ってしまいますが、機能追加をするときの大事な視点が抜けています。それは、ソースコードを読む量です。 読んだソースコードの行数 リファクタリングしない リファクタリングする 2回目の機能追加前に読んだソースコードの行数 Main 19行 Printer 3行、Main 12行 合計 19行 15行 機能追加前に調査するソースコードの量は、リファクタリングしない場合の方が4行多くなっています。これはとても重要なことです。書籍「 Clean Code 」によれば、プログラマーがソースコードを読む時間は、書く時間の10倍と言われています。つまり、読む量を少なくすれば大きな効果が得られます。今回の例題は簡単なのでよいのですが、通常のプログラムはもっともっと複雑です。少しでも調査を間違えば即障害につながってしまうため、ソースコードの調査は細心の注意が必要な作業です。できるだけ負担を下げたいものですね。 さらにパッケージ構造も以下のようにすれば、このプログラムには、Html、Json、Markdownの3つの出力形式があることもすぐに分かります。 appパッケージ Mainクラス Printerインターフェイス printerパッケージ HtmlPrinterクラス JsonPrinterクラス MarkdownPrinterクラス もし3回目の機能追加でYAML形式の出力を増やすことになれば、YamlPrinterを作ればいいこともこのパッケージ構造から直感的に分かります。 まとめ ソフトウェアは成長し続けます。開発が終わることはなく、後から新しい機能が追加されるものだと考えておく必要があります。 この記事では、新機能を追加する直前にリファクタリングすることで、クラスの数を増やしたとしても、読まなければならないソースコードの量を減らせる例を示しました。簡単な例を用いたのでその差はわずかなものでしたが、普段の仕事でソースコードを書いている時間の10倍は読んでいる時間なのだと考えると、得られる効果はとても大きなものです。 ソフトウェアにおいては、品質とコストはトレードオフではく両立するものだと言われています。普段の生活では「高品質なものほど高価である（コストが高い）」ことに慣れているので、おや？と思いますよね。ソフトウェアアーキテクチャーの大家であるマーチン・ファウラーさんが書かれた、とても素晴らしい記事の中で紹介されています。 bliki-ja.github.io 記事の中ではたとえ話を使って、ソフトウェアでは高品質と低コストが両立することを説明しています。台所が片付いていないまま次の料理を始めれば、効率が悪く、次の料理を作るまでに時間がかかってしまいますよね。それは、リリースを優先して、とりあえず動けばOKのままにした状態です。台所を片付けることがリファクタリングで、台所を片付けた後が高品質な状態です。すぐに料理を作り始められるので、低コストを実現できます。 高品質を保つ秘訣がリファクタリングですが、リファクタリングの指針を与えてくれるのがデザインパターン 1 です。デザインパターンはOOPが目指す「高凝集・低結合」な設計のサンプル集として使えます。今回の例題ではデザインパターンの1つであるStrategyパターンを適用して、利用される側（Printerインターフェイス）を切り出し、利用する側（Mainクラス）のソースコードを再利用できるようにしました。OOPのポリモーフィズムが役立つ例ですね。詳しく知りたい方は @hyuki さんの書籍「 Java言語で学ぶデザインパターン入門 」が入門書としてオススメです（第3版が出版されるとのことで、今から楽しみです！）。また @iwashi86 さんのテック系ポッドキャストfukabori.fmで @t_wada さんがリファクタリングとデザインパターンの関係についてとても分かりやすく解説されています。 fukabori.fm fukabori.fm また、高凝集・低結合を目指しつつデザインパターンを適用してリファクタリングする過程は、書籍「 オブジェクト指向のこころ 」にも例があります。 さて、この記事は「クラスを増やしたほうが楽になることがある」例になっていたでしょうか？追加する機能が恣意的だった点や、リファクタリングをする上でとても大事になる自動テストについて端折ってしまった点についてはどうぞご容赦ください🙇‍♂️ BIGLOBEでは、勉強会や業務を通じて、若手とベテランがお互いを高めあっています。私たちが大事にしている行動指針である ビッグローブマインド にあるように、これからも「世の中をみて、世の中から学ぶ」ことで「プロフェッショナルであれ」を目指していきたいです。ご興味のある方は、採用ページもご覧になっていってください。 www.biglobe.co.jp デザインパターンを学ぶと、どんな場面にもとにかく学んだことを適用したくなる「デザインパターン厨」になりがちです。くれぐれもご注意ください。 ↩

こんにちは。BIGLOBE Style編集部の吉田です。 日々新しい技術が生まれるIT業界では、いかにして学び続けるか、が大事になります。継続のポイントは一緒に学ぶ仲間がいること。今回はエンジニア部門のとあるグループに潜入し、若手エンジニアによる勉強会をはじめとする日々のスキルアップ活動について取材してきました。 若手勉強会 朝の学び デモの日 参加メンバーの声 まとめ 若手勉強会 お邪魔したのは、基盤本部  基盤系システム部  基盤横断システムグループの若手エンジニア勉強会。 （2021年9月下旬にオンラインで実施） 今年9月から開始したというこの勉強会は、あえてベテランエンジニアは呼ばずに、若手同士が教え合うのが特徴だそう。教える、教わるの関係性ではなく、「教え合う」機会を創出しています。 若手勉強会「神7」 参加メンバー：7人（全員20代） 開催頻度：週に1回、発表は持ち回り 内容：発表者は自分が分からないこと、スキルアップしたいことを勉強して発表する。そしてフィードバックをもらう。 勉強会のタイトルが「神7」なのは、7人で始めたからだそうです。この部署では積極的に中途採用をしているので、新しい仲間が増えたら神8、9へとバージョンアップしていくのだと思われます！ さて、今回の発表者は今年8月に入社したばかり…！オブジェクト指向プログラミングにおけるデザインパターンについての発表です。 目的 ・プログラム設計の良いパターンを知ること ・実装の引き出しを増やすこと ・ 開発者間での共通言語として使えるようになること 発表者は、この発表で一番大事な目的は「 開発者間での共通言語として使えるようになること 」だと話していました。共通言語として使えるようになると、「こっちのパターンの方がいいんじゃない？」という一言で設計の意図が伝わるようになるので、より良いシステムにするための議論も生まれやすくなりますね。   発表者 「23種類あるデザインパターンの中からState、Strategy、Template Methodの3つの違いについて発表します。」 ゲームのキャラクターが進化やレベルによって「姿、能力」が変わることに例えて、パターンのメリット、デメリットを分かりやすく説明してくれました。身近なものに例えながら、複数のパターンを関連付けると理解しやすいですね。 ひと通り発表が終わり、参加メンバーからフィードバックをもらいます。   参加者 「パターンはまだ自分で意識して書くことはできなくて、こんなパターンで書いたらどう？とアドバイスをもらうレベルです。今回のことを参考にしたい！」 参加者 「パターンはJavaを始めた時に勉強したけど、実践で活かせるようになりたいです。」 参加者 「デザインパターンってライブラリやフレームワークで使われていることが多いんですよね。Java SDKやSpring Frameworkの中身を見にいくと、このパターン使ってたんだってことが多いです。書籍を読んで理解した気になるのは簡単ですが使うのは難しい。経験上、業務のコードでデザインパターンを使うことは多くはないですが、設計をする時にはパターンが適用できないか意識するようにしています。」 すでに知見のある人、ない人とさまざまだからこそ「教え合う」事が可能で、 チームとしてスキルの底上げ をしているんですね。   このグループでは「若手勉強会」の他にもスキルアップのためのさまざまな施策を行っています。   朝の学び   朝の学び 参加メンバー：グループ内の開発チーム毎 開催頻度：毎朝15分 内容：最近、話題になったブログやドキュメント、YouTubeをみんなで共有し合う。   「朝の学び」はチーム全員が参加する短時間の勉強会です。継続期間は開始してからなんと2年。やっている様子は地味(笑)とのことですが、継続は力なりですね、かなりの手応えがある様子！ それぞれのチームではどんなことをしているのでしょう？   参加者 「Codewarsというコーディング練習問題サイトで一問解いているのですが、難しい問題が解けるようになった時に成長を感じます！たまに難しすぎて心が折れることもありますが(笑)」 参加者 「セキュリティ周りのYouTubeを見たり、デザインパターンの話やブログを読んだり。ドメイン駆動設計（DDD）に取り組んでいるので、その知識の読み合わせもします。それに、新しく中途で来られた方や新入社員はBIGLOBEならではの用語やシステムが分からないですよね。仕事をしながら感じた疑問は、なんでも聞ける「朝の学び」の時間に解消して、どんどん業務に活かして欲しいと思っています。知識を持ち合わせた仲間がワイワイと発表やフィードバックをしながらインプットすることで、スキルの底上げをしています。」   デモの日   デモの日 参加メンバー：グループ内メンバー 開催頻度：月に1回 内容：グループ内で開発チームが分かれているため、お互いが作っているシステムや技術を知る機会として、1カ月の成果を共有し合う。     （デモの進め方） 「デモの日」の狙いは、学んだことをただの知識に終わらせず、業務に適用し、得られた知見を共有することです。業務で大事になるのは、ただ言われたことをやるのではなく、何のためにやるのかを考えること。なので、組織に与えられたミッションや、それに対するアクションを再確認した上で、選定した技術の正しさなどについても議論します。 例えばこんなことを質問し合います。 目的 ・プロダクトの価値の追求 　 何のために作っているのか？ 　 誰がよろこぶのか？価値は変わっていないか？ ・実現手段の追求 　実現手段は正しいか？ 　手段の選択に一貫性はあるか？ グループ内には複数の開発チームがあり、それぞれ別のプロダクトを作っています。たとえプロダクトが異なっても、技術的な知見が応用できる場面は多いそうです。   グループリーダー 「 勉強会で学んだ知識を、実際の仕事に使ってみてはじめて分かることがたくさんあります。学んだときには良さそうと思った技術でも、ビジネス価値を出すまでに至らないことも。お飾りではなく動くデモを使うのがポイントで、体験から得た貴重なノウハウを共有できています。 」 （Amazon Web Services CodePipelineでリリース前テストを自動化するデモ） 新入社員や中途で入られた方は特に、メンバーのスキルも隣のチームが何をしているかも見えづらいですよね。このような機会があると、そんな課題も解決できそうです！   参加メンバーの声   参加者 「 自分で調べたり、実際にアウトプットして気づきを得たりする部分はもちろん沢山あります。ですが、 参加者から感想やフィードバックをもらうことでさらに大きな気づき を得られます 。 勉強会で 知見を共有することで成長 を感じてい ます。 」 参加者 「 業務での課題を発表の題材として取り上げることが多いです。それは他の開発者も抱えている課題だったりするので、 共通認識を作れるのは強い です 。 」 参加者 「 他人の関心ごとを、自分の業務に関係ないからと別事として捉えるのではなく、別のチームであろうと解決策を自分の中で持って発信していきたいです。チーム意識を高めてどんどん開発を進めていって、 BIGLOBEを盛り上げるエンジニア になりたいですね。 」   まとめ   BIGLOBEでは、今回紹介した部署以外にも、さまざまなところで自主的に勉強会が実施されています。入社後間もなく参加するのは躊躇するのでは？と思いましたが、意外にも、参加することで雰囲気を知ることができるし、一度参加してしまえばハードルは高くないということでした。 このような勉強会は在宅勤務中のコミュニケーションとしても有効ですし、積極的に 自ら勉強する意識が持てる ため、ゆるくても、細々とでもいいから 継続することが大事 ！だと思いました。   BIGLOBEでは、全社員が一丸となり、同じ思いを持ち、同じベクトルで、ひとつの目標に向かって進むために「 ビッグローブマインド 」を定めています。 BIGLOBEの全社員が大切にしているこれらのマインドの中から、今回編集部が感じたマインドはこちら。 「世の中をみて、世の中から学ぶ」 「継続的に成長する」 「チームビッグローブ」   今回ご紹介しました部門では一緒に働く仲間を募集しています。ご興味のある方はこちらの採用情報をご覧ください。 （2022年2月追記：本募集は終了しました。） hrmos.co   ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ YouTubeは、Google LLC の商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部です。 BIGLOBE 基盤本部主催で “熱い” 講演会を、社内イベントとして開催しました。テーマは、「魂のエバンジェリスト常盤木龍治さんが語る、マーケットバリューの高いエンジニアとは」。 イベント後半の部では、BIGLOBEの取締役執行役員常務であり、開発部門（基盤本部）の責任者でもある鴨川 比呂志との対談も行いました。 主に自社のエンジニア向けでしたが、“トッキー”こと常盤木さんの熱量と、BIGLOBEの技術部門のトップの想いを届けることで勇気づけられる方も多いと思い、BIGLOBE Styleでもその内容の一部を公開します。 エンジニアの仕事の醍醐味、学ぶことの楽しさ、これから何をすべきかまで、常盤木さんと鴨川のクロストークから、その想いを感じとっていただけると嬉しいです。 【目次】 激動の時代を前向きに生きるヒント 昨今は新型コロナウイルス感染症の影響で、社会状況は大きく変わっています。BIGLOBEも、その変化においては例外ではありません。激動の時代の中で、働き方やキャリアについていろいろと思いを巡らせているエンジニアも多くいるはずです。 講演会の事前アンケートでも以下のような要望があがっていました。 BIGLOBEの外部から見た強みを知りたい 社外のロールモデルを知りたい スキルアップの方法やポイントを知りたい そこで、今回はエンジニアの皆さんに、これからの時代を前向きに生きるヒントや、マネタイズ（収益化）できるエンジニアを目指す上での考え方を伝え、会社を使い倒してもらいたい。そんな想いからイベントを開催しました。 そして、「前向きに生きるヒントを伝える」という目的にふさわしいゲストスピーカーが“トッキー”こと常盤木さんだったのです。 ※（編集部注記）このイベントは本来、会場開催を予定しておりましたがコロナ禍の状況を考慮し、オンラインにて開催しております。 ※（編集部注記）常盤木さんには今回のイベントのためだけ特別にBIGLOBEのTシャツを着用いただきました。 常盤木さんは定時制高校を卒業後、入学した大学を中退。数学好きを活かしてエンジニアとしてのキャリアをスタートしたものの、最初は「底辺エンジニアだった」といいます。しかし、常盤木さんは努力と情熱で道を切り拓いていきました。 例えば、“仕事のための仕事”だった膨大なドキュメント作成業務に違和感を覚えたところから、ドキュメントを簡単に作成できるツール「Dojo」をチームとゼロからつくりあげ、売れる仕組みまで構築。他にも、日本において基幹業務領域でのクラウドの普及が進む前からクラウド化を実現など、その実績が業界内で注目され、日本の有力ベンダーが集う「MIJSコンソーシアム」の副委員長にも抜擢されました。 そして、その地位に満足せず「世界一」を目指し、基幹業務システムで世界トップレベルのシェアを誇るSAPでエバンジェリストとして採用されるなど、まさに「魂のエバンジェリスト」と呼ばれるにふさわしい実績を残してきました。 .box1 { padding: 0.5em 1em; margin; 2em 0; color: #5d627b; background: white; border-top: solid 5px #5d627b; box-shadow: 0 3px 5px rgba(0, 0, 0, 0.22); } .box1 p { margin: 0; padding: 0; } 常盤木 龍治 No.1シェア請負人。パラレルキャリアエバンジェリスト/プロダクトデザイナーとして“差別化要素をもち市場提供価値/社会的意義が明確にある仕事のみ”を軸とし活動中。さまざまな企業の最高戦略責任者/最高技術責任者/エバンジェリスト Developers Summit KANSAI 2019 ベストスピーカー1位 MIJSコンソーシアムプレゼンコンペ 2011 2012 優勝 TECH PLAYER AWARD 2020審査員 16,000人を超えるFBカレー愛好家コミュニティ カレー部キャプテン エンジニアに伝える、常盤木さんの熱いメッセージ では、いよいよ講演会の内容を見ていきましょう。今回の講演会は「日本とBIGLOBEの明日を変える　エンジニアの本気が “できない” を無くす～オーナーシップを皆で持とう！～」と題され、常盤木さんの経験をもとに熱いメッセージが届けられました。 野心を持つこと。自分の価値を言語化していくこと まず、冒頭で強調されたのは「エンジニアには野心が欠かせない」ということ。 会社を変える主役はエンジニアで、「エンジニアが野心的にならないと組織は埋没する」と、常盤木さんは語ります。 実際、昨今はコロナ禍の影響で、全世界が同じ課題に直面し、オンライン化が急速に進んでいます。現状、BIGLOBEの業績は順調に伸びていますが、常盤木さんはダーウィンの名言を引き合いに、「生き残れるのは変化できる者である」と説きます。 ※（編集部注記）複数の説があります。 そして、価値あるエンジニアになるためにはこの2つが必要だと。 自分には何ができるのかを言語化して伝えること 特定の領域で認知される存在になること 他者に認知されないと声がかからなくなり、愚痴が増え、給料が下がっていくケースが多い……と。こういったことに心当たりがありドキッとしてしまう人もいるかもしれません。 課題解決の本質的な価値に目を向けること 常盤木さんは長くIT業界で働く中で、日本中の中小企業の課題に目がいくようになり、そこでもエンジニアとして培ってきた価値を提供しようと考えました。伊勢神宮のお膝元として知られる三重県伊勢市の老舗飲食店・ゑびやの差別化を成功に導いた事例では、このように語ります。 「正直に言って、グルメサイト上での評価もいま一つな普通の老舗飲食店だったのですが、私たちがAIによる来客予測システムの導入を支援し、システムを外販したところ、この分野では極めて高い知名度を誇る企業に急成長できました。その結果、ゑびや｜EBILABの取り組みは世界中のパートナーが集うMicrosoftのイベントでサティア・ナデラCEOのコアノートでとりあげられ、数多くのメディア掲載や講演依頼が殺到するようになりました。」 ここで大事なポイントは、課題の改善こそが価値という点です。 EBILABが提供しているのは、「来客予測」という機能ではなく、あくまでデータを活かした廃棄ロスの抑止やメニュー提供の高速化といった課題の改善です。お客様の課題解決の本質は、データ活用の先にあるのです。 学ばない人には明るい明日は訪れない エンジニアとして、誰かを救うための「能力」はどう鍛えればいいのか。常盤木さんは学びの中でも「読書」の重要性を強調し、「人生の時間を1とすると、良書を読めば0.05が手に入る。つまり、20冊の良書と出会うと人生は1＋1で2になる」とまで言います。実際、今でも月に30～40冊は読んでいる常盤木さんは、読書は多様な価値観を受容することにも役立つといいます。 「様々な開発言語や手法、エンジニアを取り巻く世界は、時として価値観が異なる場合があります。そうした他者の価値観を受け入れることは、コミュニケーションのハブ的な役割を担うエンジニアの成果に直結します」 そして、これからの社会で、自らの所得水準の維持だけを考え逃げ切るのは困難という真実がある中で、自分の知見とチームの知見でどう稼ぐかを考えることが必須である。そんなメッセージを送られました。 「外」から見るBIGLOBEと、「内」から見るBIGLOBE 講演会の後半では、常盤木さんとBIGLOBE開発部門（基盤本部）の責任者である鴨川との対談を行いました。内容を一部お届けします。 鴨川 比呂志 1987年　国際電信電話株式会社（KDD）入社 2006年　同　IPソリューション商品企画部長 2007年　株式会社KDDIウェブコミュニケーションズ代表取締役副社長 2009年　KDDI株式会社アプリケーション推進部長 2015年　同　グローバルコンシューマビジネス本部長 2017年　ビッグローブ株式会社執行役員常務 2018年　同　取締役執行役員 　基盤ライン長 2019年　同　基盤本部長 ＜鴨川＞ 常盤木さんから見て、BIGLOBEの強みは何だと思いますか？ ＜常盤木＞ 同規模の売上のISP (Internet Service Provider) に比べて、自由度がとにかく高いことです。社風を強要されない会社だと思っています。ただこれは長所でもあり短所でもあって、自分自身でキャリアパスを設計したり、ロールモデルを探せない人は成長しにくい環境かもしれません。 ＜鴨川＞ 同感ですね。私も4年前に外部からBIGLOBEに来ていますが、同じことを思っていました。なんだかんだ言いながら自由な会社。でも、自ら動かないと何にも起こらないんですよ。 また、経営サイドの人間として聞いてみたいのですが、常盤木さんは会社の「中期経営計画」ってどんなものだと思いますか？ ＜常盤木＞ あくまで中期経営計画は骨子に過ぎないと思いますが、会社が一定の方向性を示し、そこに向けた意見を吸い上げ、会社を育てるための「幹」としての役割は重要です。会社の方針と自分の想いとのギャップを感じても、形がなければそれをぶつけられないので、その箱を与えてくれるようなイメージです。 ＜鴨川＞ それはいい意見ですね。確かに想いを想いのままにしておいても、形にならない。だから、中期経営計画のように「形」をつくらないとダメですね。 ＜常盤木＞ 中期経営計画に対して意見を集めて肉付けし、あるいは削っていくことで会社はよくなるので、そうした意見交換の場は積極的につくるべきです。 ＜鴨川＞ ありがとうございます。多くの会社は経営層だけで計画を作りがちですが、BIGLOBEでは現場エンジニアを中心に作り、最終的に私がまとめました。 そして決まった中期経営計画のテーマは「あくまでも自身のマーケットバリューの最大化とマネタイズできるエンジニアを目指し、その結果、会社への貢献も最大化する」です。まさに本日の講演会で学んだことが活かせそうで嬉しいですね。 さらに、講演会開催の目的でもある、エンジニアが「会社を使い倒す」についても常盤木さんにお聞きしたいです。どうしたらいいと思いますか？ ＜常盤木＞ 既存の顧客層に重ねて、自分が提供できる価値を逆算するのが手っ取り早いです。自分の実現したい夢を、そもそもなぜ実現したいのか棚卸し、そのために会社をどう使うか。ただ、これは自分がなぜエンジニアになったかを自覚することと同じなので、現場のエンジニアからこの質問が出るとすれば、その人は自分が何者になりたいかを定義できていないのかもしれません。 ＜鴨川＞ 常盤木さんにとって「稼げるエンジニア」が稼ぐのは「お金」でしょうか？というのも、以前ある社員から「年収に興味はないけど、後世に作品を残したい」と言われたことがあり、お金以外の価値を求めているエンジニアもいるのかなと。 ＜常盤木＞ 「信用」と「愛情」を得られるエンジニアが稼げるエンジニアです。ポジティブな気持ちが循環すると、副次的に仕事も増えます。感謝の上にお金は乗ってきますから、まず感謝が先ですね。 ＜鴨川＞ なるほど、参考になります。今回は、リアルタイムで数百人のBIGLOBE社員がオンラインで参加しています。常盤木さんへのQ&Aもたくさん来ていますので、ご回答いただけますか？ 常盤木さんの野望は？ いまは15社くらいにかかわっているのですが、ゆくゆくは渋沢栄一さんのように100社の企業にかかわってみたいです。その理由は、100個の組織内のチームをメンタリングしてみたいから。自らの意思決定能力が、どこまで情報を処理できるのかを試してみたいんですよ。あと、海外展開を目指しているので、日本を救えるようなエンジニアになりたいです。 エンジニアは何歳まで活躍できますか？ 自分の魂が学ぶことがしんどくなったり、社会課題解決のために魂を燃やせなくなった時が辞め時だと考えます。それは20歳かもしれないし、70歳かもしれない。つまり、年齢の問題ではないんです。そのために学び続け実践し続けています。 人と話すときに気を付けていることはなんですか？ 相手を追い詰めないよう、愛をこめて接するようにしています。理由は、相手が言語化している内容が、誰も傷つけないことばかりになってしまわないためです。お客さんはそれを言うと誰かが傷ついたり、タスクが増えることは言わない傾向にあります。だから、私は相手が言語化していることが真なるゴールではないことを前提にしているのです。 自分が話しているときは、あえて弱点をさらけ出しています。若いうちは難しいですが、昔の闇に葬った「マンホールの下にいる汚い自分」と一体化してからが人生のスタート。自分の闇に目を向けると、他人の想いに目を向けられる人間になります。社会に目を向ける前に、まず自分に目を向けましょう。 新たな強みをつくるためにはどうしたらいいですか？ 私は自分の嫌いなタイプの人を遠ざけないようにしています。その人を嫌いな理由は、たいてい自分の過去のトラウマに重なってしまうことが原因です。でも、目の前にいる人は過去に出会った人ではない。それに目を向けず、同じく嫌いと決めつけて、相手を勝手に区分する失礼な振る舞いをしているケースが多いんです。その嫌いを「なぜそう思っているのか」と棚卸することは、強みの創出につながります。 ＜鴨川＞ 熱いメッセージ、ありがとうございます。私からエンジニアの皆さんに伝えたいのは、社内が愚痴ではなく、改善の要求で満たされてほしいということ。究極の目標ではありますが、ついつい社員には期待してしまいます。できないではなく、こうすればできるという心持ちで「そうかそうか、そうだよね」と活発な話し合いが生まれる会社になったら最高ですね。 まとめ 最後に、常盤木さんから以下のメッセージがありました。 「エンジニアは第三者に褒められる機会が少ない職業ですが、確実にこの国を生きている人たちを支えています。エンジニアは、未来を切り拓き、未来への道を照らす光になれる存在です。私も、社会課題解決のために魂が燃やせなくなるまで、エンジニアとして活動を続けていきます」 たいへん熱く、参考になるメッセージがつまっている講演会だったので、この記事を読んでいるエンジニアの皆さんの心にも火が灯ったのではないでしょうか？ また、「会社全体を改善要求で満たしてほしい」と言う鴨川の懐の広さは、自由度が高く意見を上司に伝えやすいBIGLOBEそのもの。それが、今回のこの講演会を社内で開催することにも繋がりました。 そんなBIGLOBEは、ただいま絶賛 エンジニアを募集 しています。皆さんもBIGLOBEに入社し、一緒に社内を改善要求で満たしてみませんか？ ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。 document.addEventListener('DOMContentLoaded', function () { var contentsList = document.getElementById('toc'); // 目次を追加する先(table of contents) var div = document.createElement('div'); // 作成する目次のコンテナ要素 // .entry-content配下のh2、h3要素を全て取得する var matches = document.querySelectorAll('.entry-content h2, .entry-content h3'); // 取得した見出しタグ要素の数だけ以下の操作を繰り返す matches.forEach(function (value, i) { // 見出しタグ要素のidを取得し空の場合は内容をidにする var id = value.id; if(id === '') { id = value.textContent; value.id = id; } // 要素がh2タグの場合 if(value.tagName === 'H2') { var ul = document.createElement('ul'); var li = document.createElement('li'); var a = document.createElement('a'); // 追加する タイトル を準備する a.innerHTML = value.textContent; a.href = '#' + value.id; li.appendChild(a) ul.appendChild(li); // コンテナ要素である の中に要素を追加する div.appendChild(ul); } // 要素がh3タグの場合 if(value.tagName === 'H3') { var ul = document.createElement('ul'); var li = document.createElement('li'); var a = document.createElement('a'); // コンテナ要素である の中から最後の を取得する。 var lastUl = div.lastElementChild; var lastLi = lastUl.lastElementChild; // 追加する タイトル を準備する a.innerHTML = value.textContent; a.href = '#' + value.id; li.appendChild(a) ul.appendChild(li); // 最後の の中に要素を追加する lastLi.appendChild(ul); } }); // 最後に画面にレンダリング contentsList.appendChild(div); });

BIGLOBE Styleをご覧のみなさま、いつもありがとうございます！ 基盤本部（開発部門）の”中の人”見える化を推進している、基盤統括部の吉川です。 先日開設したBIGLOBE Technology Channel（YouTube）で取り上げている動画の中から、「BIGLOBEで1年間業務をするとどれだけDDD（ドメイン駆動設計）のスキルが上がるのか？」をご紹介します！ 当ブログの中でも人気があるDDDに関する記事2本 「DDDくらいできるようになりたいよねって話」 「BIGLOBEで1年間業務をすると、どれだけDDDのスキルが向上するか」 を執筆した小野田さんによるプレゼンテーションになります。 既存システムのリニューアル業務に1から携わったことで、DDDの全工程を経験し、理解を深めることができたと語る小野田さんに、1年前に自分が作ったモデルと、業務経験を経てたどり着いた今のモデルのBefore/Afterなどについて、お話ししていただきました。（所属は撮影時点のものになります） www.youtube.com コンテキストの境界を意識してモデリングすることで高凝集・低結合を実現したり、ドメインオブジェクトの振る舞いを豊かにすることでコンパイル時に誤課金に気がつけるようにしたり、確かな手ごたえがあったそうです。 さらに、こうした手ごたえを得るためにDDDをどうやって勉強していくと良いのか、についても語っています。 14分という短い時間の間に、たくさんのエッセンスが詰まっています。 ぜひ、ご覧ください！ 過去の記事2本はこちら style.biglobe.co.jp style.biglobe.co.jp ※ YouTubeは、Google LLC の商標です。

BIGLOBE Styleをご覧いただいているみなさま、いつもありがとうございます！ 基盤本部（開発部門）の中の人見える化を推進している、基盤統括部の吉川です。 今日は、社員の素顔が見えるメディア「BIGLOBE Technology Channel」というYouTubeチャンネルの開設のお知らせ＆紹介になります。 BIGLOBEエンジニアが自らの言葉で、自分たちが使っている技術などについて発信していますので、ぜひ一度、のぞきに来てください！ BIGLOBE Technology Channelとは？ 第1回はDDDの「はじめかた」に関するプレゼンテーション システム刷新を牽引するメンバーが、DDDについてのホンネを語った座談会 BIGLOBE Technology Channelとは？ BIGLOBEの技術や社員について紹介してきたBIGLOBE Styleですが、テキストと写真の情報だけでは、実際のコミュニケーションが行われている雰囲気が伝わりづらいところがありました。 そこで、BIGLOBE Technology Channelでは ・社員が今使っている技術や、これからやりたいことなどについて、自身の言葉で思いを語る プレゼンテーション ・ 社員同士の座談会 など、実際にコミュニケーションをしている様子 といった動画コンテンツを通じて、BIGLOBEの技術や社員について、より深く知っていただければと思っています。 第1回はDDDの「はじめかた」に関するプレゼンテーション 記念すべき第1回プレゼンテーションは、 BIGLOBEのシステムをどうにかする漢 による「DDDを始めるには成長するドキュメントから始めよう」です。 　2013年から始まったBIGLOBEのドメイン駆動設計（Domain Driven Design：DDD）に対する取り組み。現在も、DDDとAmazon Web Services（AWS）で基幹システムを刷新中です。 　そのスタートから携わり、基盤システム刷新のリーダーを務める西さんが、その経験をもとに、DDDに取り組む際のステップや周りの巻き込み方についてプレゼンします。 youtu.be 「DDDって興味あるけど、小難しくて結局よくわからん」 「DDDやってみたいけど、上司が納得してくれないから進められん」 「エンジニアがDDDに取り組むメリットがわからない」 そんなかたにおすすめの動画（前後編）になっています！ システム刷新を牽引するメンバーが、DDDについてのホンネを語った座談会 開発現場で業務を行う中で、日々、DDDと向きあっているエンジニアが、ホンネを語り合い予定時間を大幅にオーバーするほど盛り上がった座談会。 現場のエンジニア同士が、どんな雰囲気でコミュニケーションしているのかがわかる動画になっています。（所属は動画収録時点のものになります） youtu.be 全4話に及ぶ座談会の一部コメントを抜粋します！ぜひ、ご覧ください！！ 第1話「DDDってホントに楽しいの？」 第1話「DDDってホントに楽しいの？」～BIGLOBE社員によるDDDに関するパネルディスカッション～ - YouTube 「インターフェース仕様書に書いていないデータを本当に送り付けてくるw」 「そこで、Unknownというクラスを作って入れる」 第2話「ある日突然、腹落ちするのがDDD？」 第2話「ある日、突然、腹落ちするのがDDD？」～BIGLOBE社員によるDDDに関するパネルディスカッション～ - YouTube 「DDDをやってよかった瞬間がいつ来るかわからない」 「いままで書いてたコードのほうがいいんじゃないの？と思う瞬間が多々ある」 第3話「AWS LambdaでDDDをやってみた」 第3話「AWS LambdaでDDDをやってみた」～BIGLOBE社員によるDDDに関するパネルディスカッション～ - YouTube 「AWS移行、マイクロサービス化とDDDの相性はいい」 「DDDをやっているとなんでもかんでもドメインにしたくなる」 第4話「DDDを通じて、エンジニアとして成長したい 」 第4話「DDDを通じて、エンジニアとして成長したい」～BIGLOBE社員によるDDDに関するパネルディスカッション～ - YouTube 「SQL頑張りたくなる病気が発症する」 「都市伝説のように聞いていたDB層が変わる日が来たときは感慨深い」 style.biglobe.co.jp style.biglobe.co.jp style.biglobe.co.jp ※ Amazon Web Servicesは、米国その他諸国における、Amazon.com, Inc.またはその関連会社の商標です。 ※ YouTubeは、Google LLC の商標です。

こんにちは、BIGLOBE 基盤本部 基盤統括部にて、新サービス創出活動推進を担当している吉川です。 2021年4月より「技術を通して、もう1つの通信を考える」をテーマに、多摩美術大学 情報デザイン学科の永原教授、清水講師、学生の皆さんとの産学共同研究プロジェクトを実施しました。 今回の記事では、今までの集大成として作品を発表した多摩美術大学オープンキャンパスの模様に加えて、有志の学生4名とBIGLOBE社員とのオンライン意見交換会をレポート形式でご紹介します。 学生はどんな想いで作品を作り上げたのか？ 大学と企業が連携した半年間の取り組みを通じて、どんな化学反応が起こったのか？ など、ぜひご覧ください。 多摩美術大学オープンキャンパス2021 多摩美大生 × BIGLOBE社員 意見交換会 酒井 優実さん「Language of Nature（自然言語）」 大浦 彩さん「記憶の海（死者との通信）」 JUNG JIEYUNさん「あなたの言語はどんな模様をしていますか？（マルチリンガルから見た言語による内面の変化をビジュアライズする）」 井川脩人さん「イシ疎通（感情に触れる、思う）」 意見交換会を終えての感想 最後に 多摩美術大学 × BIGLOBE　産学共同研究プロジェクトとは 「技術を通して、もう1つの通信を考える」というテーマに沿って、多摩美術大学の学生が課題作品を制作。 　インプットの講義や学生のアイデア発表を含めた創作活動の過程をBIGLOBE社員がオンラインでリアルタイムに参加及び録画視聴できる環境を作っています。 　学生の作品制作のプロセスへの参加を通じて、Z世代が通信というものをどのように考え、認識しているのかといったことへの気づきや、学生のアイデアからインスパイアを受けることで、BIGLOBE社員が将来の新サービス検討などの新しい取り組みにつなげていくことを目的に取り組んでいます。 多摩美術大学オープンキャンパス2021 7月17日、18日、多摩美術大学 八王子キャンパスにてオープンキャンパスが開催されました。2021年度は、新型コロナウイルス感染症の影響もあり、両日とも1500人の「完全予約制」となった当日の様子を写真でご紹介します。 各学科別の作品展示が行われ、BIGLOBEとの産学共同研究プロジェクトを実施した情報デザイン学科の作品も展示され、学生が自身の作品について発表を行う機会がありました。 当初はBIGLOBE本社オフィスで、感染対策を徹底しながら成果発表会を行い、作品展示やプレゼンテーション、学生と社員の直接対話を計画しておりましたが、新型コロナウィルスの感染拡大状況悪化に伴い、やむなく中止することになりました。 その後、学生から作品解説シート（作品制作の背景や狙い、どのようなモノなのかの説明をまとめたもの）を提出していただき、そちらをBIGLOBE社員が見たうえで、オンラインで意見交換会を呼びかけたところ、有志の学生4名とBIGLOBE社員8名に参加いただきました。 「技術を通して、もう1つの通信を考える」というテーマから生まれた作品について、学生とBIGLOBE社員の間で活発な意見交換が行われました。 多摩美大生 × BIGLOBE社員 意見交換会 【学生の参加メンバーと作品】 ■酒井 優実さん 「Language of Nature（自然言語）」 ■大浦 彩さん 「記憶の海（死者との通信）」 ■JUNG JIEYUNさん 「あなたの言語はどんな模様をしていますか？（マルチリンガルから見た言語による内面の変化をビジュアライズする）」 ■井川脩人さん 「イシ疎通（感情に触れる、思う）」 酒井 優実さん「Language of Nature（自然言語）」 学生：この作品は、植物が私たちに提供している言語をアートにした作品です。植物は目の前にありながらも日常生活では通信することが不可能ですが、生物学なども引用した新たな言語を制作する作品を試みました。 【文字の読み方】 連続する波状の線の上部が太陽が出ている時間、下部が太陽が出ていない時間とし1往復を1日とする。よって時期による日照時間で波の大きさが変化する。そして、その時々で起こる外的要因にそれぞれ形を与え、波状の線上に置いていく。気温はその日の平均気温に比例した大きさの円を中心に配置した。例）20℃ =20mm 学生：最終的なアウトプットは、説明を読まないとわかりづらいかもしれませんが、アナログながら新しい通信の形をBIGLOBEの社員の方がどう感じたのか聞いてみたいです。 社員A：植物の連続性がよく現れていて、自然の本質を捉えた作品だと個人的には感じました。同時に私自身、子供の頃に地球外にいる生命体でも理解できる言語にロマンを感じたのですが、ここで表現しようとした自然の本質がそこに繋がって面白いなと思いましたね。 学生：作品と照らし合わせて、そう言っていただけて嬉しいです。作っていて、植物の言語を表現できたことに私もロマンを感じました。 社員A：同じ作品を同じ会社の人と見たらどういう会話が生まれるのかや、その会話を聴きながら作者がどう感じるのかを楽しみにしていました。今回はオープンキャンパスに参加できず、オンラインでの意見交換会になりましたが他の方がどう感じたか、私も聞いてみたいです。 社員B：植物の言語をデザインしようという発想にまずびっくりしました。しかも、できあがった作品は訳のわからないものではなく、本当にありそうなリアリティまで感じました。 学生：植物がこんな滑らかに変化しているのは、作品を作っているうちに気づき、私自身も驚きました。音楽や楽譜のようなものになっているなって！ 社員A：目に見えないけど、そこにあるものを捉えたというのは素敵ですね。 社員C：私は講義の初期フェーズから構想を聞いていたのですが、この作品は最終的にどういうふうになるのか正直想像もつきませんでした。できあがって作品を見たとき、植物が何を言おうとしているのか人間にもわかるように変換してくれるようなツールは全くないので面白いと思ったし、それを強い意思を持って形にしているのがすごかったですね。 社員A：今、IoTのセンサーで農作物をどうやったらより良く育てられるかという分野の研究も進んでいます。この作品を見て、どうすれば植物が気持ちよく育つのか？という視点で考えると、そうした研究も受け入れられやすくなるのではないかと感じました。 学生：IoTに関しては以前から興味があり、私も改めて勉強してみたいと思いました。 清水講師：植物の声をリスペクトを持って聞いていたと思います。そして、自然言語は人間の声だけなのか、植物の声も聞くとどういうことができるのか、SDGsなども含めて、もっと大きいこともできそうだと感じました。 永原教授：説明を読まないとわかりづらいかもと冒頭に言っていましたが、そんなことはなく、この作品はグラフィックの表現力がとても優れていて、毎日コツコツ調べることができるのも才能です。こういう作品は説明しがちになるところを、説明を抑制しても形になっているところが素晴らしいですね。 大浦 彩さん「記憶の海（死者との通信）」 学生：もし死者からメッセージを受け取った時、生きている私たちは相互的に通信することはできません。しかし、お線香をあげたりお花を活ける弔いによって、死者と心を通わせられると考えられてきたことからも、この作品は死者の国に最も近い波打ち際で、鑑賞者が言葉に出会い、思い、海の先に無事還れるように願うという想いがこめられています。 社員D：現代版精霊流しですね。実際にこの作品を会場で見ることができなかったので、どんな言葉が書かれているのか知りたいです。 学生：友達の口癖とかSNSに寄せている文章に目を通して、思い出深そうな言葉を拾ったり、いろいろな人が最後に言いそうなことをまとめたのです。 清水講師：コロナ禍で法事がオンラインになったという話を聞いたのですが、亡くなった人に思いを馳せるような割り切れない気持ちを処理するような通信は今までありませんでした。大浦さんのように、その感情を処理しないように処理する、漂わせるみたいな通信が作品として表れているなと思いました。 社員A：最初この作品の写真を見たときに、正直辛いなと思いました。強さがある作品で、死に向き合った際の感情を思い出させるようで、会場で実際に見たら泣いてしまうかもと。でも、死について語り合うのが減った現代であっても、こうした「感情を動かす作品」を目の前にすればより深い対話ができるのかも、と思いました。 社員E：私が亡くなるときは私のTwitterつぶやきを、このように表示してもらえると嬉しいと思いました。くだらないつぶやきばかりですが、私が言いたかったこともいくつかあり、それを改めて伝えたいというか、認識してもらえる機会ともなるなと感じました。 学生：私自身も、自分の身近な人が亡くなったのをベースに発想した作品でした。でも、一般的に死のテーマは怖いし思い出したくないものかもしれませんが、死に対するテーマでポジティブになりたいという想いが昔からあり、それも表現してみました。 社員C：早い段階で文字を動かすデモを流していたので、気になっていた作品の1つでした。しかしビジュアルだけではなく、こういう深いテーマがあるのが一番驚きました。日本文化にある、尽くしきれない想いみたいなものが表現できていたかなと思います。 JUNG JIEYUNさん「あなたの言語はどんな模様をしていますか？（マルチリンガルから見た言語による内面の変化をビジュアライズする）」 学生：私自身、韓国からの留学生で、ある日ふと、言語によって変化している自分の姿に気づきました。言語によって違う姿が表れるのは、すなわち言語というトリガーを通して潜在していた無数の自分の中の一部を引き出しているからなのではないかと思います。この経験を、皆さんにも是非感じて欲しいと思います。 【グラフィックの意味】 画面に映っている3つのグラフィックは、左から韓国語、日本語、英語の順になっていて、真ん中にあるマイクでその言語を発すると、画面が変わります。言語に関してのグラフィックや色には、JIEYUNさんが今までこの言語を使いながら感じた経験、思い、その言語への理解度などが含まれています。 社員A：これは会場で実際に体験したかったですね。JIEYUNさんのように、言語を深いレベルで理解しているマルチリンガルの方を思考法を、そうでない自分が体験できる作品だなと感じました。 社員F：私は海外で仕事をすることもあったので、母国語ではない言葉をしゃべる場合は、語彙力がない分ストレートな表現になってしまいました。JIEYUNさんのこの作品では、さらに言語によってキャラクターまで変わることが表現されていたので興味深かったです。 学生：そうですね。たとえば、地元の友達や家族としゃべる時はラフな性格で、会社の面接などでは尊敬語などを使うなどのように、環境やシチュエーションによって性格も変わりますよね。 社員A：たしかに同じ日本語でも、会社の日本語と家での日本語は違うかもしれないですね。 社員D：日本語に無いけど、英語にあるという単語が、どういう意味や感情を持つのかがわかる、そのためのツールの1つにもなりそうですね。 清水講師：そういったいろいろな言葉をマイクを通じて発してみた時に、それがビジュアルで表現されるのは面白いです。まだ答えがない世界だとも思うので、今後もJIEYUNさんのライフワークのように取り組んで欲しいなと思いました。 学生： 実はこの作品はまだ完成したとは思っていません。違う表現もあるんじゃないかなと常に問いながら、これからもブラッシュアップしていきたいです。 井川脩人さん「イシ疎通（感情に触れる、思う）」 学生：通信技術が発達した時代に、通信できづらいものを探して参考にしたのが「石文」というコミュニケーションです。日本の映画「おくりびと」にも出てきますが、言語がなかった時代に自分の気持ちに似た石を探して相手に贈り、相手はその石の感触や重さから相手の気持ちを読みとくというものです。 　この石文の要素を取り入れたアナログで時間をかけたコミュニケーションで、相手の気持ちを深く考えることができるワークショップと装置を制作しました。 清水講師：これは会場で体験して欲しかったですね。ワークショップでは、まず、ショートムービーの映像を見てから、その感想にぴったりの石を目をつぶって探します。最後に石にビジュアライズした布の中にあるアクリル箱の中に入れる……相手も箱に手を入れ石を触りながら、どんな感情を得たのかを感じとるという仕組みです。 社員A：石はどこにでもあるし、たくさんある。そんな石でも、相手を思いやる気持ちや考えを伝えることができる。それこそが通信の本質ですし、そこに気づいたのがすごいと思います。また、私自身BIGLOBE側の人間として、アナログなコミュニケーションに価値を置いているのが発見でした。質感を捉えるというのはデジタルでは失われがちだからです。 学生：今までは100％で伝えようとしていましたが、曖昧な情報でもいいんだな、曖昧なコミュニケーションだからこそ広がるものもあるんだなと感じ、その時に石を見てこの作品を思いつきました。 社員D：現代の通信の本質に対するアンチテーゼとして面白いなと思いました。相手を思いやること、気持ちを込めることが大事だと。 清水講師：今の通信は読み取りやすいし、伝えやすいことを目指している。けれどこの作品は、さぁ石から内容を読み取ってみようと思っても、一瞬何も浮かばない。けど読み取ろうと試行錯誤してると、段々と自分の持っている語彙では表せないような感情が出てくる… 社員D：体験してみたかったです。 社員A：石を触っている間はオフライン。マインドフルネスのような感覚になりそうですね。 社員C：相手のことをどれだけ理解するか、考えてもらえるかがこの作品にはありますよね。“石で意思を伝える”とあったので単なる語呂合わせかと最初は思いましたが、とても深い意図があったことを感じ驚きました。 社員G：コミュニケーションで私が大事だと考えているのは、何か新しいギャップを感じる（新たな知恵を得る）こと、本能的に人間はそういうことが好きなのだと思っています。この石を使ったコミュニケーションは、皆さんがおっしゃるように、画一的に言語や映像で届けるのではないので、さまざまなギャップ（考えを）得るきっかけになりそうだと感じました。 意見交換会を終えての感想 学生1：私は難しいことが苦手で、最初は企業と一緒にやるのかぁという偏見もありましたが、完全に払拭された会でした。世界の見方が変わる貴重な機会をいただき、ありがとうございました。 学生2：私もはじめは偏見を持っていたなと思い至りました。否定的なことを言われしまったら嫌だなと思いましたが、本当に歩み寄ってくれた上でアドバイスをしていただけたので嬉しかったです。 学生3：産学連携プロジェクトを通じて、多摩美術大学の関係者だけではなく外部の方々の声も大事だと改めて思いました。同時に、最初はBIGLOBEはどんな作品を求めているのかなと思ってしまいましたが、結果的に嬉しいコメントをいただけて良かったです。 学生4：自分の作品を一人でも多くの人に届けたかった。それを事業として通信を考えているBIGLOBEさんに、「もうひとつの通信」という形で届けてみて、共感いただけたので、今回の意見交換会に参加できて本当によかったです。 永原教授：私は講義の課題を通じて学生に向けてサーブを打っているつもりでいます。さまざまに考えて今回のテーマは「もうひとつの通信」にしました。たとえば「未来の通信」としたら、もっとコミュニケーションスピードが速い作品を打ち返してきたでしょう。結果として「ちょうどいい」や「スロー」のような広がりがある作品が生まれ、学生たちが考える「オルタナティヴ」をみることができました。 清水講師：BIGLOBE の社員さんは、いつもは最先端で効率的なシステムを構築する仕事が多いと思うのですが、今回の共同研究では、仕事での価値観と真逆の作品も多かったと思います。その中で、アートを受容する姿勢や、いろいろな角度からのアドバイスをいただけたのが良い意味での驚きでした。ありがとうございました。 最後に 後日、産学共同研究の活動に参加してくれた社員に直接インタビューしたところ、 「美術大学生という触れ合ったことのない人たちの考え方を聞いて、とても刺激を受けたし、参考になった。また、同じような機会があれば、ぜひ参加したいと思っている」 といったコメントがありました。 学生との共創という初めての取り組み、なおかつコロナ禍という環境もあり、難しいこともありましたが、最終的に、学生、社員の双方からポジティブなコメントをいただくことができました。以上で、多摩美術大学とBIGLOBEの産学共同研究「もう1つの通信」の活動は終了となります。 私も学生の授業に参加させていただく中で、普段接することのない美大生のアイデアを聞くたびに、多くの学びがありました。また、作品制作のスピード感やアイデアを形にする力についても大いに刺激を受けました。 新サービス創出活動を推進する立場として、得られた学びを活かしながら、さらに新しい取り組みを進めていきます。 この産学共同研究活動のテーマ作りや講義はもちろん、BIGLOBEの活動に対して理解いただき、多大なサポートをいただいた多摩美術大学 情報デザイン学科の永原教授、清水講師及びたくさんの関係者の皆様、本当にありがとうございました！ style.biglobe.co.jp style.biglobe.co.jp style.biglobe.co.jp

BIGLOBEのゲーマー平澤です。ファミコン時代から四半世紀ゲームしています。好きなゲームはスプラトゥーンと、ドラゴンポーカーです。 今や社会インフラとなったインターネットですが、BIGLOBEはお客さまが安心してインターネットをご利用いただけるよう、業界を横断してさまざまな課題解決に取り組んでいます。 そんな活動の一つに、インターネットを使ったゲームやエンターテインメント分野の課題に取り組んでいるJAIPA（一般社団法人日本インターネットプロバイダー協会）のゲーム・エンタメワーキンググループ（WG）があります。 このWGで、BIGLOBEが固定回線で世界で初めて商用化（※）したNAT64/DNS64という技術が話題になりました。そこで新卒2年目のホープ、川口さんに声をかけ、WGで技術紹介をしてもらうことになりました。 ※ 2019年10月28日時点、MM総研調べ この記事では、WGでの発表の様子を紹介しながら、BIGLOBEが業界横断で課題解決に取り組んでいること、また、仕事として自分が好きなことに関われることをお伝えできれば、と思います。 ここからは、川口さんにバトンタッチします。川口さんよろしく！ JAIPAゲーム・エンタメWGでNAT64/DNS64を紹介してきました 川口です。BIGLOBEのエンジニアです。 私もゲーム好きで、中高生のときは鉄拳（遊んだのは鉄拳5、6）をやってました。友達とプレイしたり、ゲームセンターに行ったり、オンライン対戦など楽しんでました。 今はスマホのプロスピA（プロ野球スピリッツA）を遊んでいます。 オンラインゲームを快適にする事もネットワークエンジニアの大切な仕事です。仕事でゲームを評価することもあります。 平澤さんに声をかけてもらって、JAIPA主催のゲーム・エンタメのネットワーク接続性に関する課題検討WGに参加し、BIGLOBEのNAT64/DNS64の取り組みをオンラインゲーム関係者へ共有してきました。 JAIPA JAIPAは、インターネットに関わる会社が集まり協力して、インターネットに関わるさまざまな課題に取り組んでいく団体です。 ゲーム・エンタメのネットワーク接続性に関する課題検討WG インターネット上のゲームとエンタメのために活動しているワーキンググループです。さまざまな業界のゲーム好きな人たちが集まって、ゲームを快適にするための活動をしています。 講演の様子 たくさんのゲーム、エンタメとネットワークの関係者が聞いてくれました。Zoomで36名参加です。 開始直前 BIGLOBEは川口と平澤で参加しました。 ※ 他社の方は猫にしています。 BIGLOBEがNAT64/DNS64を導入した理由 NAT64/DNS64を導入した理由は、誰一人取り残さない、人に優しいIPv6化を目指したからです。 BIGLOBEは、IPv6/IPoE方式で大容量化されたネットワークを推奨してます。IPv6で快適なインターネットがご利用できます。 BIGLOBEで従来採用していたMAP-Eでは、IPv4 over IPv6 に対応したブロードバンドルータが必要です。より多くのお客さまに負担なくIPv6をご利用いただきたいという思いから、ブロードバンドルーターを買い替えずに済むNAT64/DNS64を導入しました。 NAT64/DNS64とは NAT64/DNS64の仕組みは弊社の 会員サポート ページや、TechBlogの記事でご紹介しています。 style.biglobe.co.jp 運用の様子 ISP側でIPv6に変換することで、ブロードバンドルーターを買い替えずともIPv6が使えるNAT64/DNS64ですが、利用するサービスによっては不正な通信だと判別され、通信できなくなる不具合が起きる場合があります。特に、VPNやゲームの不具合申告が多いです。 不具合申告のあったサービスは1つずつ確認し、必要に応じてIPv6に変換しない設定を入れて対処しています。 老舗ISPの看板を守るためにも、丁寧な調査と対策が大事だと考えているので、不具合申告には1つずつ丁寧に対応しています。 質疑応答 質問やコメントを通じて、NAT64/DNS64の未来について考えるいい機会となりました。一部を抜粋してご紹介します。 Q. IPv6シングルスタックにはしないのか？ A. 評価の結果、一部で不具合があり、デュアルスタックにしました。 Q. 将来的にNAT装置がボトルネックになるか？ A. ロードバランスやクラスタリングで対処可能です。 所感 川口 2021年7月に開催された Infra Study 2nd #3「いまさら聞けないIPv6ネットワーク」 のライトニングトークでNAT64/DNS64を社外に紹介しました（ YouTube 、 ログミーTech ）。会社として社外発表することが初めてだったので、資料作り・発表のやり方など経験を積めたこと、エンジニアの生の感想・意見をいただくことで新たな知見や気づきを得ることもできました。勇気を出して社外発表に取り組んだことで、多くのフィードバックをいただけたことが嬉しかったです。 そのことを社内のイントラブログで報告したところ、平澤さんに声をかけていただいて、今回のJAIPAでの社外発表につながりました。 BIGLOBEのIPv6推進の取り組みをより多くの方に知っていただけたと思います。 コメントや質問では、不具合回避の運用が大変そう、どういう方法で不具合の調査をしているのか？と聞かれました。 NAT64/DNS64 はゲームが使用できなくなった という不具合報告が多いのですが、ゲーム会社のエンジニアの方から、「こういう実装しているゲームもあるから対応が難しい」 といった現場の声も直接伺うことができ、大変勉強になりました。 これからもBIGLOBEの取り組みや技術をより多くの人に知っていただけるよう、社外への情報発信を積極的に行っていきます。 平澤 ゲーム好きのつながりで参加していたWGでNAT64/DNS64が盛り上がっていたので、後輩の川口さんにお願いしたところ、快諾してくれて今回の講演ができました。川口さんありがとうございます🙏 「世界初」というと華々しいですが、その裏で繰り広げられている日々の苦労をうまく伝えてくれて、質疑応答ではベテランの方々からの鋭い指摘にもきちんと回答してくれました。 今後も川口さんの活躍に期待します。 今回のゲームのように、温泉でもスポーツでも動画でも、好きなことに関わっていきたい、好きなことをやっている人たちを支えたい人と、BIGLOBEで一緒に働けると嬉しいです。 hrmos.co ※ 鉄拳は、株式会社バンダイナムコエンターテインメントの商標または登録商標です。 ※ プロスピ、プロ野球スピリッツは、株式会社コナミデジタルエンタテインメントの商標または登録商標です。 ※ ファミコン、スプラトゥーンは、任天堂株式会社の商標または登録商標です。 ※ ドラゴンポーカーは、株式会社アソビズムの商標または登録商標です。 ※ YouTubeは、Google LLC の商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは、BIGLOBEの谷山です。 こちらの内容は、以下の記事からの続きとなります。 style.biglobe.co.jp オンプレの何十台ものサーバから構成されるRADIUSシステムをAmazon Web Services（AWS）に移行するプロジェクトを行っていました。 2021年度上期に、一旦認証機能の中核となる部分と一部のバックエンド（監視機能等）の移行が完了しました。 GitOpsを実際に使って開発を終えて、やってよかったなと思うことがたくさんあったので、GitOpsのメリットや、上手く続けていくために守るべきことをまとめておきたいと思います。 そもそもGitOpsって何、という話等については、前述の記事をご覧になっていただければと思います。 GitOpsをやって得られたメリット 改善(1) : 開発フローの改善 改善(2) : IssueBoardでタスク管理の利便性向上 改善(3) : 業務情報の集中化による効率向上 改善(4) : あらゆる設定ファイルをGitLabで管理する文化を醸成 改善(5) : Deploy作業をこれまでより意識しないで済む 他にもGitLabのいいところ 失敗したことと、それを防ぐための方法 失敗(1) : ついつい手動でAWSリソース作成 失敗(2) : Terraformのリファクタリングも結構手間 まとめ 今後の予定 採用情報 GitOpsをやって得られたメリット GitOpsによって、得られたメリットについていくつか以下に書いていきたいと思います。 改善(1) : 開発フローの改善 GitLabのMerge Request機能を中心に、開発を進める業務フローに変えたことで、レビュー用の資料作成を個別に作成する等を行わずに済むようになり、業務が効率化しました。 一部修正を加えていますが、前回の記事でも貼り付けたGitOpsの運用イメージが以下です。Deployの流れも含めてわかりやすいように、Terraformの場合を一例として記載しています。 上記の図に記載の通り、 環境に追加するものに問題はないか コードの書き方に問題はないか 等のレビュー、および承認を、GitLabのMerge Request（MR）機能を使って行うことができます。 だいぶ黒塗りしてしまっていますが、以下はMRのPipelineページで、 以下はMRの差分ページです。 Pipelineのページではエラーが起きてないかすぐわかり、実際のログも緑チェックをクリックすれば見に行くことができるようになっています。差分のページではどこに更新があったかを赤背景（削除）と緑背景（追加）でわかりやすく表示してくれています。 ユニットテストの実行をPipelineに組み込んでおくことで、「確実に単体テストを通過していること」を担保することもできます。また、コメントの部分に画像の貼り付けも行うことができるので、外部からのテスト結果のグラフ等も追加で証跡として残すこともできます。 GitLabに限らずほかのプラットフォームでもそうですが、MRの中にこれらの情報が紐づいてまとまるので、何か問題が起きたときに情報追いかけやすいです。 開発フローごと大きく変えたので、これまでGitLabを触ったことが無かったメンバーにもある種強制的に触ってもらうようになったので、メンバーのgit関連のスキル向上につながりました。 改善(2) : IssueBoardでタスク管理の利便性向上 GitLabにはIssueBoard（カンバン）機能があるので、外部のタスク管理ツールを別で用意する必要がありません。Issue内にコメントもどんどん追記できるので、状況管理もしやすいです。また、IssueからbranchとMRを作成することができ、相互に紐づくのでIssueがどういう経緯でCloseまで至ったかの流れを残すことができます。 ほかにもIssueをさらに便利に使える機能（Milestones等）もたくさんありますが、そのあたりはIssueBoard単体での利用が慣れてからでも大丈夫かと個人的には思います。 改善(3) : 業務情報の集中化による効率向上 前述の通り、Pipelineの実行結果等、開発にかかわるものが全てGitLab上に集まります。そのため、ほかのメンバに聞きたいことがあった時にPipelineのリンクなどを添えて聞くことで、前提条件の説明をある程度省くことができたり、ログを別途保存したりしないで済みます。同じことを口や文字で説明しなおす必要がないため、ミスコミュニケーションも起きにくいです。 リモートワークにより文字でのコミュニケーションが増えているため、そこの部分のコストを下げることができるのは大きなメリットでした。確実に同じものを見て作業を進められるのがSaaSのメリットだと思います。 改善(4) : あらゆる設定ファイルをGitLabで管理する文化を醸成 GitOpsを行うことで、GitLabを利用するのが「当たり前」となり、オンプレサーバ内の設定ファイル等、これまでそのサーバ内で日付バックアップを取っているのが主だったものもGitLabで管理するようになりました。 日付バックアップと異なり、過去の状態との差分を比較するのも容易ですし、変更履歴とコミットメッセージが残るので、何故設定を変えたのか、いつ変えたのかが見える化しました。 改善(5) : Deploy作業をこれまでより意識しないで済む 実際にDeployする仕組みは全てPipelineに定義してあるので、Deployのために実サーバにログインしたり、といった作業がなくなります。なので、開発者はGitLabを使ってコード開発、MR作成、承認の流れを淡々とこなしていけば自然と環境が出来上がります。 手順書を使った環境構築の場合、手順書を見ながら操作を進めていく都合上作業時間の調整等に手間がかかることもありますが、Terraformであれば基本的には数分で作業が終わるので作業調整、実作業（実行ボタンを押すだけ）も各段に楽になりました。 TerraformでDeployするLambdaのコードも、GitOpsでビルド、テスト、S3への配信を自動で行っています。自動的に命名規則（コードにつけたtag情報等を付与）に従ってS3に配置されるので、コード作成者はどこにビルドされたファイルが置かれているかを意識する必要はないようになっています。 他にもGitLabのいいところ MRの画面に色々と集約されているという話は前述した通りですが、GitLabにはWebIDEも存在するので、ちょっとした変更であればWebGUIでbranchを作成して、WebIDEで編集してMR作成、という一連の流れも簡単にできます。 これは完全に個人的な好みですが、ほかのGit系SaaSの中では色合いや画面レイアウトがすっきりしてて見やすいのもいいところです。 失敗したことと、それを防ぐための方法 GitOpsをやっている中で、失敗したことがいくつかあった（特にTerraform周り）ので、それらについて記載します。プログラム等と違って、AWSコンソールなど、ほかの設定手段も存在してしまうこと（自分も含めて、人は皆目先の楽さに吸い寄せられてしまう）や、AWSのリソースで後更新できる設定・できない設定が多様にあることが大きかったです。 失敗(1) : ついつい手動でAWSリソース作成 最初の頃は、どうTerraformで書いていいか困ったのもあって、とりあえず手動でリソース作成を行ったことがありました。Terraformにはterraform importという既存リソースを取り込むコマンドがあります。ただ、実際に使ったことがある人ならわかるかもしれませんが、自分が思った通りの構造でtfstateに読み込まれてくれるとは限りません。特にセキュリティグループは顕著でした。 上手く解消する方法はあったのかもしれませんが、既存リソースの取り込みに関しては自分はとにかく愚直にやる（つらい）しか解決法が見つからず、辛い（ほんとうにつらい）思いをしました。 他にも、手動で作ったリソースのセキュリティグループにTerraformで作ったセキュリティグループを適用すると、Terraform側でそのセキュリティグループの削除が依存性のせいでできなくなるなど、Terraform管理外のリソースを作るデメリットは多々ありました。 これを解決する方法は、システムの分界点を意識してシステム設計を行い、GitOpsやる部分・やらない部分を明確に切り分け、GitOpsやる部分の手動設定を禁止することです。できるのであれば、管理者/運用者以外にはAWSの読み取り権限のみあるアカウントを払い出す、等権限で制御してもいいと思います。 RADIUSシステムの場合、以下のようにTerraformの分離を行いました。 base環境のGitLab RunnerをGitOpsで管理すると、自己崩壊を起こす可能性があるので、こちらはTerraformを手動実行して管理しています。また、パラメータ情報の部分はGitにコードとして書いておきたくないので、手動設定する部分としています。 小さい範囲からやりたくなると思いますが、新規でシステムを立ち上げる場合できる範囲は全て一気にGitOpsで立ち上げるのがいいと思います。手動で建てた領域は、terraform importを愚直に頑張るか、新規に同じリソースをTerraformで並行して立ち上げて移行する方法が考えられます。 例えば、サブシステムA-Cのうち、サブシステムBだけTerraform化ができていなかったとします。 サブシステムBと同じ機能を持ったサブシステムB'をできる形で新規に起こします。 可能なタイミングで、BからB'に接続点を切り替えて完了です。 移行の容易性を確保するためにも、サブシステム間は疎結合に作り込んだり、AWS Kinesis Data Stream等マネージドで接続しやすいプロトコルで分界点を作っておくのも重要です。 失敗(2) : Terraformのリファクタリングも結構手間 最初の頃に作ったTerraformは、module化等も行われておらず、書き方もこなれていなかったので構成がぐちゃぐちゃになってしまいました。Terraformにはリソース名を変更する時に使うterraform state mv等、Terraformのコードをリファクタリングするときのためのサポートコマンドは存在していますが、terraform importほどでは無いものの、やはり手間です。 これを解決する方法は、最初からある程度設計指針を決めた上でterraformのmodule設計をしておくことが必要だと思います。 module化する moduleは複数のterraformでgitのsubmoduleの仕組みを使って共有し、同じポリシーが全てのサブシステムで共有されるようにする terraform registryの書き方を参考にmodule設計する 命名規則を決める 等です。チーム全体で納得ができる指針作りをするのが良いです。作った指針はもちろんGitLabのwikiにまとめて誰でもいつでも見れるようにすると良いです。すぐに見せられる指針があることで、チームに新しく参画するメンバーの立ち上がりスピードが上がります。 まとめ GitOpsを取り入れたRADIUSシステムのAWS移行が無事完了しました。 失敗から学んだことは、機械でやっている作業に人手を介入してはいけないということです。失敗に書いた通り、手動で設定を行うと様々なデメリットがあります。また、GitLab上で管理しているものが本当に現在の最新の状態を表しているものかわからなくなるので、GitOpsで運用しているコード、その他資材が信用ができなくなります。 また、数々のメリットをここにまとめる中で考えたこととしては、１つのツール・開発手法のみを取り入れて全てが解決する、というわけではなく、GitLab、Terraform（IaCツール）、テストツール（pytest等）を組み合わせて開発フロー全体の見直しもかけることで業務効率が大きく上がるということです。せっかく新しいツールを導入しても既存の業務フローはそのままにしてしまった場合、新しいツールを導入して必要になった作業が既存の業務に上乗せされるだけだからです。 GitLabでREADME.mdを書く代わりに、別のこれまで作っていたドキュメントを廃止する等、何が何を担保しているのかを考えて業務の棚卸することも成功のコツです。 今後の予定 前回の記事から、この記事を書くまでの間にこの構築スキームを使った別のProjectをリリースしました、徐々にこれらのスキームを社内に横展開していければと思っています。 また、RADIUSシステムにおいてはオンプレに残っているバックエンドの残りの機能をAWSに移行することが次期の予定です。今後も新たな知見があったら記事にするかもしれません。皆様も良いGitOpsライフを。 採用情報 弊社は引き続き採用を進めてます。興味がございましたら以下のリンクを参照してください。 hrmos.co ※ Amazon Web Servicesは、米国その他の諸国における、 Amazon.com ,Inc. またはその関連会社の商標です。 ※ GitLabは、GitLab B.V.の米国およびその他の国における登録商標または商標です。 ※ Terraformは、HashiCorp,Inc.の米国およびその他の国における商標または登録商標です。 ※ fluentdは、米国及びその他の国における The Linux Foundation の商標または登録商標です。

こんにちは。 2021年4月に新卒入社した小泉です。 5月からサービス開発部に配属になり、慣れない業務に苦戦しています。 配属先では開発で使用する言語として、Javaを採用しています。 しかし、今までJavaを触ったことがなく、ゼロから勉強する必要がありました。 にもかかわらず、OJTコーチが設定してきた課題はSpring Frameworkを使ってAPIを完成させるというとても高いもの。開発に参加するのは一筋縄ではいきません。そんな高いゴールに向かいつつ自分で工夫しながら学んで、なんとか開発に参加できるレベルになれました。 今回は、新人が配属されてから2カ月でどのようにJavaを勉強したかを紹介したいと思います。 本で学ぶ ゴールを明確にして手を動かす ありのままを学ぶ まとめ 参考図書 スッキリわかるJava入門 スッキリわかるJava入門　実践編 Java言語で学ぶデザインパターン入門 オブジェクト指向でなぜつくるのか 本で学ぶ プログラミング言語の勉強方法は、大きく分けてネットで学ぶ方法と本で学ぶ方法の2つあると思います。 好みの問題もあるとは思いますが、自分は本で勉強しました。 理由としては以下の3点です。 体系的に学べる 信頼できる 勉強してる感がある ネット上には多くの情報が溢れていますが、それゆえに、どれから手をつけてよいか分からなくなることがあります。 また、ネットは情報が散乱しているので最初に学ぶべきものを見落としてしまい、学習が非効率になる恐れがあります。 その点、本は情報がまとまっていて、順序立てて学ぶことができるため非常に効率が良いと思います。 自分が配属後の2カ月で読んだ本を最後に紹介しているので、参考になれば幸いです。 ゴールを明確にして手を動かす プログラミング学習の挫折要因の一つとして、ゴールが明確になってないことが挙げられます。 プログラミングは、ゴールを達成するための道具に過ぎないので、勉強する際に先に何をしたいかを決めたほうが良いと思います。 自分は 新幹線の料金計算 APIを作ることをゴールとしました。 後、週に1回チームで Codewars をやりました。 Codewarsとは、簡単な競技プログラミングの問題を解きながらアルゴリズムやコーディングを学ぶWebサービスです。 コードに慣れる意味ではやって良かったと思います。 ただ、競プロ系は書き方が業務とかけ離れているので気を付けたほうが良いです。 プログラミングの学習に限らないのですが、最初に入門書を完璧にしてから実際に動くものを作ろうと考える人は少なくないと思います。 手を動かさずに本だけで学習を進めると、ものを作るゴールのつもりが本を読むことがゴールに変わってしまったり、分かったつもりになって満足したりする恐れがあります。 自分の例でいうと、大学でオブジェクト指向を学んだのですが、実際にコードを書いてみると知っているだけで全く使うことができないことが分かりました。 実際にやってみると自分が何を理解していないかが分かり、ゴールが明確になってモチベーションにもつながると思います。 ありのままを学ぶ Java学習のロードマップの一つに こんな記事 があります。 HelloWorldから始まって言語の基礎を学び、WebフレームワークやRelational Databaseなどの周辺技術に知識を広げていくロードマップが紹介されています。勉強すべきことは非常に多いと感じます。 しかし、これらのツールは開発を便利にしてくれるものに過ぎず、ツールやフレームワークを使ったからと言って別の言語になるわけではありません。 そのため、基礎となるJava自体を深く学ぶことは非常に重要だと思います。 自分のいるグループでは、JavaのフレームワークであるSpring Frameworkを開発で使用しています。 初めてSpring Frameworkを触った時はその便利さがよく分かりませんでした。 しかし、素のJavaをしっかり勉強したことで、フレームワークを使うとどう便利になるかが理解出来ました。 これらの便利なツールをなぜ使うのかを理解するために、一見遠回りですが一度何も使わない状態を学んだ方がいいと思っています。 まとめ Javaを文法などの基礎から積み上げて勉強したことで、プロダクトコードを読んで開発に参加できるようになりました。 Javaは古い言語というイメージがあると思いますが、世界的に見てもまだまだ利用率は上位ですし、使いこなせれば何でもできる万能な言語だと思います。 まだまだ知らないことがあるので、これからも勉強を続けていきたいと思います！ 参考図書 スッキリわかるJava入門 オススメ度：★★★★★ AmazonでJavaと検索したら一番上に出てくるほど売れてる本です。 絵が多く、文章も硬すぎず非常に分かりやすいと思いました。 本がかなり嫌いな自分でもスラスラ読めました。 しかし、プログラミング経験者からすると少し物足りなさを感じると思います。 重要なことは大体書いてあるので、この本を読めば開発で使われているコードも読めるようになると思います。 スッキリわかるJava入門　実践編 オススメ度：★★★☆☆ 上で挙げたすっきりわかるJava入門の続編です。 入門編よりも使いどころが限られるようなものが多く、内容も難しくなっています。 この本の前半はJavaの説明ですが、後半は開発手法(アジャイル、リファクタリング、CI/CDなど)を説明しています。 この本のおかげで関数オブジェクト、ラムダ式、StreamAPIを理解できました。 しかし、後半の開発手法の話は内容が薄く、この本で学ぶべきことではないと思うので、無理してこの本を読む必要はないと思います。 この段階でJavaのドキュメントが読めるようになってくると思います。 Java8ドキュメント : https://docs.oracle.com/javase/jp/8/docs/api/ Java言語で学ぶデザインパターン入門 オススメ度：★★★★★ GoFの23個のデザインパターンを 1つ1章使って丁寧に解説しています。 難しい表現もなく、クラス図やコードがかなり分かりやすいと思いました。 また、デザインパターンに慣れていない人が読むことを想定して書かれているので、かなり読みやすいと感じました。 しかし、手続き型プログラミングに慣れていた自分からすると、使いこなせるようになるには時間がかかりそうだと思いました。 オブジェクト指向でなぜつくるのか オススメ度：★★★★☆ タイトルの通り、オブジェクト指向が何で生まれたかの歴史について書かれています。 どういった経緯でその考え方に至ったのかを知ることで、理解がより深まると思います。 ヒープ領域やスタック領域でもメモリの挙動も解説されていたので、理解の助けになったと思います。 オブジェクト指向の概要を知るにはいい本だと思います。 ※ Amazonは、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。 ※ Amazonのアソシエイトとして、ビッグローブ株式会社は適格販売により収入を得ています。 ※ Javaは、オラクルおよびその関連会社の登録商標です。 ※ Spring Framework は、米国Pivotal Software, Inc. の米国またはその他の国における商標または登録商標です。

こんにちは、ビッグローブ株式会社 基盤本部 基盤統括部にて、新サービス創出活動推進を担当している吉川です。 「技術を通して、もう1つの通信を考える」をテーマに、多摩美術大学 情報デザイン学科の永原教授、清水講師、学生の皆さんとの産学共同研究プロジェクトを2021年4月から実施しています。 今回は、ビッグローブ株式会社 取締役執行役員常務であり、開発部門（基盤本部）の責任者でもある鴨川 比呂志に、この産学共同研究プロジェクトになぜBIGLOBEが取り組んでいるのか、基盤本部をどのような組織にしていきたいか、またエンジニアにとってどんな働く場所でありたいかについて熱く語ってもらいました。 尚、取材は合同会社スゴモン代表でインタビューライターの松田然さんにお願いしています。 開発部門（基盤本部）内に新サービス創出活動推進等をミッションとした組織を作った狙い 産学共同研究プロジェクトを起案されたときのファーストインプレッション 「多摩美術大学 × BIGLOBE」産学共同研究プロジェクトに抱く、今後の期待 多摩美術大学 × BIGLOBE　産学共同研究プロジェクトとは 「技術を通して、もう1つの通信を考える」というテーマに沿って、多摩美術大学の学生が作品やそのプロトタイプなどを制作します。 　インプットの講義や学生のアイデア発表を含めた創作活動の過程をBIGLOBE社員がオンラインでリアルタイムに参加及び録画視聴できる環境を作っています。 　学生の作品制作のプロセスへの参加を通じて、Z世代が通信というものをどのように考え、認識しているのかといったことへの気づきや、学生のアイデアからインスパイアを受けることで、BIGLOBE社員が将来の新サービス検討などの新しい取り組みにつなげていくことを目的に取り組んでいます。 開発部門（基盤本部）内に新サービス創出活動推進等をミッションとした組織を作った狙い ーー2018年の就任時に、基盤本部に対して課題を感じられたとお伺いしました。 私が本部長として基盤本部へ来たとき、「エンジニアが手を動かしてモノをつくることが少なくなっている」と感じました。本来はモノづくりを担うはずのエンジニアですが、大きな会社になればなるほど、予算管理や人集めが業務の中心になり、開発は外注し「現場監督」のような存在になるのはよくある話。BIGLOBEもこうした状況に陥っていたのです。 もちろん、業務の外注も適切にできる人材が会社には必要です。しかし、ほとんどのエンジニアがこうした人材では、業務が「外注頼み」になってしまいます。外に頼りきりになると、自分たちで成果物を直したり、改善したりができなくなり品質に対する責任の所在も曖昧になりますし、コストも自分達でコントロールできなくなります。そして何より、最新技術を活かして成長していくのは外注先になり、社内のエンジニアが成長できません。外注先であるパートナーの皆さんと社内のエンジニアが一緒に成長できるような環境が作れれば最高だと思います。 もともとBIGLOBEはモノをつくって、トライ＆エラーを繰り返してインターネット接続事業という新たな業界を切り開いた会社だったはずです。そうしたDNAが薄れていくことに、当時は強い危機感を覚えていました。 ーーそこで新しく基盤統括部を立ち上げられたんですね。その役割についてお聞かせください。 基盤本部内の「ヒト・モノ・カネ・情報」を統括してエンジニアの皆さんが働きやすい環境をつくる「司令塔」のような役割を担っています。 具体的には、BIGLOBE StyleのTechBlogの作成・運営、産学共同研究プロジェクトなどの開催等を通じた社内人材育成や社外人材の採用促進、新サービス創出活動の推進、本部内の適切な予算執行を目指した活動、品質管理活動など多岐にわたります。 また、エンジニアの皆さんに外部の知識を手に入れて技術をアップデートしてもらうキッカケづくりや、外部人材に対して「BIGLOBEは面白い取り組みをしているし、成長できそうな会社だ」と感じてもらえるような仕掛け、入社後のギャップをなくすための取り組みも重要なミッションとして考えています。 鴨川 比呂志　経歴 1987年　国際電信電話株式会社（KDD）入社 2006年　同　IPソリューション商品企画部長 2007年　株式会社KDDIウェブコミュニケーションズ代表取締役副社長 2009年　KDDI株式会社アプリケーション推進部長 2015年　同　グローバルコンシューマビジネス本部長 2017年　ビッグローブ株式会社執行役員常務 2018年　同　取締役執行役員 　基盤ライン長 2019年　同　基盤本部長 ーー実際に基盤統括部を立ち上げて、どんな手ごたえを感じましたか？ まず、社員の考え方が変わってきたのを感じています。例えば、エンジニアのアイデアをキッカケに、 世界で初めて（※）固定回線で「NAT64/DNS64」と呼ばれる技術を商用化した事例 があります。こうしたチャレンジングな取り組みは、ここ数年のBIGLOBEにはなかったものです。 ※ 2019年10月28日時点、MM総研調べ また、社員としてBIGLOBEに入ってきてくれる人数が増えてきました。BIGLOBEの強みは「通信技術習得もソフトウェア開発もできること」。どちらの領域もカバーする超大手企業はありますが、そこでは業務が細分化していることも多く、自分の担当領域は狭くなりやすいんです。さらにBIGLOBEではAmazon Web Services（AWS）などのクラウド関連の取り組みにも積極的なので、「通信、インターネットの構造に関する技術取得・クラウドでの開発・ベーシックなソフトウェア開発」をすべて経験し、フルスタックエンジニアを目指せる環境が揃っています。 上記を採用時に言語化することで、入社後のミスマッチを防ぎつつ「BIGLOBEの進むべき道に共感してくれる人」に入社してもらえるよう心がけています。 産学共同研究プロジェクトを起案されたときのファーストインプレッション ーーそもそも、最初に社内で「産学連携」の活動が生まれてきたことをどう感じていましたか？ 正直、最初はみんな恐る恐るで捉えていると感じていました。「自分の貴重な時間を割くのはどうなんだろう……」と。しかし、いきなり全員が飛びつくのもおかしな話だと思うので、取り組みに納得して少しずつ参加者が増えてくれればいいと思います。 ーー今回の「産学共同研究プロジェクト」では多摩美術大学さんと連携されています。情報・工業系大学ではなく美術大学がパートナーということに驚きました。 このプロジェクトを基盤統括部のメンバーから提案されたときですが、学校名を聞いた瞬間に「ドンピシャだ」と思いました。なぜなら、今後ITの世界で大切になってくるのは「デザイン」だと感じているからです。 従来は、「回線速度が速い」「どこでもつながる」など、優れた機能を持つサービスが勝者になりました。しかし、昨今は機能面で各社に大きな差はなくなりつつあり、サービスの使い勝手やアプリやWebなどの目に見えるデザインの良し悪しが勝敗を分けるポイントになってきています。例えば、本年7月にお支払い頂く通信料金の一部が社会貢献事業に寄付される「donedone（ドネドネ）」というモバイルの新ブランドをリリースしたのですが、実はアプリの使い勝手やデザインをめぐって社内で相当議論になりました（笑）。アプリの完成度がサービスの成否に大きくかかわることをみんなが認識しているからこそです。 ※ 「donedone（ドネドネ）」は2023年8月31日をもってサービスの提供を終了しました。 こうした背景もあり、デザインやアーティスティックな感性を持つ学生さんの意見を聞ける機会は本当に貴重になっているので、多摩美術大学さんとの連携は私だけでなく社長もかなり乗り気のプロジェクトでした。 ーー昨今は、社会貢献への姿勢を積極的に発信する企業が注目を集めています。そうした風潮の中で、BIGLOBEも変わってきているのですね。 はい。最近、知り合いのキャリアカウンセラーから、会社選択の際に事業規模や労働条件よりも、社会貢献への取り組み方やリモートワークなどの働き方の柔軟性を重視している学生さんが増えてきたと聞きました。働くことに対する感覚が変わりつつあるのを感じます。 その点、弊社は1つの軸として「三方よし」を目指していきたいと思っています。あくまで企業として利益を上げていくことは考えながら、それだけではない形で社会に貢献していきたい。困っている方への支援やSDGsの活動を通じていろいろな人とのつながりを築くことが大事になります。例えば、温泉地でテレワークすることで働きながら健康になることを目指す 「ONSEN WORK」 というサービスでは、お客様はもちろん地域貢献もできる取り組みとして企画が生まれています。 「多摩美術大学 × BIGLOBE」産学共同研究プロジェクトに抱く、今後の期待 ーー産学共同研究プロジェクトの活動に、どのような効果を期待しますか？ 多摩美術大学さんの知見も借りて、「BIGLOBEらしさ」を出せる新たなサービスや事業を生み出したいですね。ただし、この取り組み単体で「成功」「失敗」と評価するつもりはなく、こうした活動をやり続けていくことが重要だと考えています。1、2年後に、潜在的にこうした活動へ関わりたいと思っていた社員が、自分の殻を破ってくれればいいんです。 社員を巻き込んで考え方を変えられた例に、毎年AWSが世界中のエンジニアを集めてラスベガスで開催しているイベント「AWS re:Invent」への参加があります。2018年時点でも、社員はみんなここに参加すれば最先端技術に触れ、 学習できると解っていたのですが、実際に行く踏ん切りがついていませんでした。 そこで、私が毎年イベントに参加することで「俺も行くからお前も来い」と言える体制をつくりました。毎年若い社員を何名か連れて行った結果、外国との関わりが薄かった社員が、帰国すると意識をガラッと変えたのです。彼は、いまや社内きってのAWS通になっています。こういう人材を一人でも増やしていきたいですね。 ーーでは、最後に今後の基盤本部が目指す姿を教えてください。 あえて言えば「XX本部という仕切りが無くなるくらいがいい」と思っています。現状の社内では、まだ「売る人・つくる人」といった役割分担が残っていますが、それでは革新的なサービスを生み出すことはできません。 だからこそ、全員が同じような知識を持ち、エンジニアが営業やマネタイズもできるような体制を構築できたら最高です。幸い、最近ではクラウドを活用すれば最小限のリスクでチャレンジができるようになってきています。社員には積極的にトライ＆エラーを繰り返してもらい、新しいサービスを多く創出してもらいたいですね。 いかがでしたか？今回は、鴨川 基盤本部長のインタビューをレポートさせていただきました。 次回は研究発表の内容をレポートする予定です。ぜひ、楽しみにしていてください。 関連記事はコチラ style.biglobe.co.jp style.biglobe.co.jp style.biglobe.co.jp https://style.biglobe.co.jp/entry/2020/01/29/130000 style.biglobe.co.jp style.biglobe.co.jp ※ Amazon Web Servicesは、米国その他の諸国における、 Amazon.com ,Inc.またはその関連会社の商標です。

こんにちは、BIGLOBE 基盤本部 基盤統括部にて、新サービス創出活動推進を担当している吉川です。 2021年4月より「技術を通して、もう1つの通信を考える」をテーマに、多摩美術大学 情報デザイン学科の永原教授、清水講師、学生の皆さんとの産学共同研究プロジェクトが始まっており、vol.1の記事では、多摩美術大学の学生が通信史やデータセンターのオンライン見学などの講義内容をメインにレポートしました。 今回のvol.2の記事では、5月28日に多摩美術大学にて行われた学生の構想発表会を通じて、BIGLOBEの社員が気づいたこと・思ったことを座談会形式で語り合った内容を中心にご紹介します。 学生の柔軟なアイデアを受けて、さまざまな意見が飛び出した社員の本音トークをぜひご覧ください。 7月の展示本番に向けて、学生の構想発表会を実施　 BIGLOBE社員座談会 「情報ってこれほど自由なんだ！」学生の豊かな発想に刺激を受ける 表現力あふれる発表の中で、印象的だった作品は 社会人が理解できないものにこそ価値があるかもしれない 多摩美術大学 × BIGLOBE　産学共同研究プロジェクトとは 「技術を通して、もう1つの通信を考える」というテーマに沿って、多摩美術大学の学生が作品やそのプロトタイプなどを制作します。 　インプットの講義や学生のアイデア発表を含めた創作活動の過程をBIGLOBE社員がオンラインでリアルタイムに参加及び録画視聴できる環境を作っています。 　学生の作品制作のプロセスへの参加を通じて、Z世代が通信というものをどのように考え、認識しているのかといったことへの気づきや、学生のアイデアからインスパイアを受けることで、BIGLOBE社員が将来の新サービス検討などの新しい取り組みにつなげていくことを目的に取り組んでいます。 7月の展示本番に向けて、学生の構想発表会を実施　 情報デザイン学科の学生たちは7月のオープンキャンパスでの作品展示に向けて、5月7日に発表内容の方向性を発表し、その後、2回の相談会を経て、考えをブラッシュアップしていきました。 そして、5月28日に本番に向けての構想発表会を実施。1人3分でプレゼンテーションを行いました。学生の自由な発想とクリエイティビティあふれる構想に対して、永原教授と清水講師からのフィードバックにより、構想が進化していきます。そして、BIGLOBE社員からも、学生に対してコメントさせていただきました。 BIGLOBE社員座談会 構想発表会の様子はオンライン配信でBIGLOBE社員もライブ視聴できる環境を用意しました。 学生たちの発表を見て、社員はどう感じたのか……今回は2つのグループでオンライン座談会を開催し、本音を語り合いました。 【第1グループ】 松村 憲和：マーケティングプラットフォーム部　メディアシステム開発グループ 空久保 充弘：マーケティングプラットフォーム部　メディアシステム開発グループ 佐藤 駿：マーケティングプラットフォーム部　メディアシステム開発グループ 【第2グループ】 西 秀和：基盤系システム部　基盤横断システムグループ 福田 敏則：サービス開発部　ISP開発グループ 川口 永一郎：ネットワーク技術部　開発グループ 「情報ってこれほど自由なんだ！」学生の豊かな発想に刺激を受ける ーー 学生の発表を聞いて、率直な感想をお聞かせください。 佐藤駿 ： ほんとにいろいろな発表があり、通信と一言で言ってもいろいろな捉え方ができることが驚きでしたね。とくに、「心の通信」のようなコミュニケーション手法をテーマに話されていた方が多かったのが印象的でした。 松村 ： 私も非常にいい発表だったなと思いました。社会人になると、何か企画するにもどこにでもあるような二番煎じなアイデアになることが多いですよね。守りに入ってしまうというか。でも、学生さんは自由な発想がある。例えば、通信はどんどん速く便利になっていますが、より遅く不便になることにも価値を感じていたり。そういったところを私たちは思いつきづらい。 空久保 ： 私も学生のことがわかっていなかったので、いろいろ新鮮でした。企画の意味がはっきりと理解できないものもありましたが、それが逆にいいと思いましたね。発表に際して、すでに試作品（モノ）を作っている人がいたのも驚きました。 松村 ： 正直、最初はもっとぼやっとしたアイデアが多いのかなと思っていましたが、あと1つ2つ要素を加えれば本当に売れるんじゃないかというアイデアがありましたね。しかも、学生個人の力でそこまでたどり着いていたのはすごいですね。 西 ： 学生はとにかく発想が自由。会社では出てこないアイデアが多くて、情報ってこれほど自由なんだと感じましたね。 福田 ： 発想が何かに縛られていないので、本当に思ったことを表現するのは面白い。いいと思ったら試しに作ってみるフットワークの軽さがあったのも良かったです。 川口 ： 試しに作ってみるのは、デザインシンキング的なアプローチですよね。学生の発表は、今までありそうでなかったのもあったので面白かったです。 西 ： 就職すると”会社のルール”がありますが、学生にはあのフットワークをいつまでも持ち続けて欲しいですね。 例えばBIGLOBEでも、温泉でワーケーションをする「ONSEN WORK」みたいなサービスは、 ビジネス的成功からではなく、SDGsや地域貢献など課題解決から生まれた企画です。他にも、若手の社員が「社長室」に入って、社長とともに新しいプロダクトのアイデアを出し、作っていくという制度もありますね。 川口 ： インフラサービスを担っている会社なので、社員がいろいろと勝手に取り組むのは難しいけど、日々の業務改善や自動化などは自由裁量でもやれますよね。学生のフットワークの軽さは見習いたいです。 表現力あふれる発表の中で、印象的だった作品は ーー 面白いと思った発表はどれでしたか？ 空久保 ： 伝書鳩で想いを伝える発表がありましたが、あえて時間がかかる通信は面白いと思いましたね。実体験として、LINEの人工知能（AI）とのやりとりはレスポンスが高速すぎて、人っぽくないのが嫌になる時がありました。これからの時代、AIが人の代わりをするというサービスは増えると思いますが、どれだけ人間らしく振る舞えるかというのは大事かなと思います。 佐藤駿 ： 最近は、若い人の間で不便を楽しむサービスが流行っていますよね。1日経たないと写真が見られない画像共有アプリ「Dispo」や、撮った写真をわざわざプリントアウトする「写ルンです」にまたスポットライトが当たったり。 私自身は、チャットは速くすぐ届くに越したことはないのですが、あえて遅くするのは面白いなと思いましたね。 松村 ： その人に合わせた選べる通信が世の中に必要かもしれませんね。例えば、BIGLOBEでもAIチャットbotのサービスがありますが、まだ機能が幼いので私たちが成長させていかないといけません。ふるまいが人間らしく、冗談が言えたり、メッセージだけではなく表現・表情を送れる通信など、ユーザーに合わせていろいろな可能性があると思います。 また、コミュニケーションの表現方法といえば、花を送ることを通じて想いを伝える企画がありましたね。私はBIGLOBEブログで、花で感情を伝える企画を担当していたことを思い出しました。投稿したブログの内容を解析して感情を花の色で伝えるような仕組みだったのですが、面白いことに、参加者は性格が穏やかな方ばかりが集まる傾向に。花で感情を伝えると、人は穏やかになる（そんな人が集まる）は発見でしたね。 佐藤駿 ： 人の気配を感じられるデバイスの発表も面白かったですね。今はコロナ禍で帰省できないですし、在宅勤務で社員にも会いづらいので、気配を感じるというのは良かったです。 空久保 ： 私が所属していた研究室でも、存在感を伝え合うような研究をしていた人がいたんですが、それに似ていて面白いなと感じました。おやじのくしゃみとか洗濯機や掃除機の音など、ノイズから気配を感じるデバイスなどもできるのかなと。 松村 ： 本当に2-3個アイデアを足せば売れるんではないかと感じますよね。 西 ： 方言の企画は面白かったですね。方言のオープンデータにして公開して欲しい。方言が集まる場所「方言ぺディア」みたいなところで、芸能人とかも自分の生まれた地域の方言を登録したら盛り上がりそう。 あと、膨大なインターネット空間そのものを可視化する表現も面白いなぁと感じました。ネットは自分から情報を取りにいきますが、自分が欲しい情報だけにかたよると分断社会という課題も生まれます。その解決策として、いろいろな情報や言葉が降ってくるような。 福田 ： たしかにインターネットは言葉を知らないと検索できません。例えば、子供は知っていることが少ないので検索はできなくても、本屋を歩いているだけで「あっこれいい」ってなる出会いがある。それが物理空間の良い点だと思いますが、インターネット空間でも「あっこれいい」という出会いが作れるような仕組みはいいですね。 川口 ： なるほど。私も最初は全く理解できなくて、まさに美大生は芸術家だなと感じました。 福田 ： 人の気配を伝えるデバイスや、感情変化を共有できるデバイスもありましたね。コロナ禍で在宅勤務になって失われた感覚は人の気配だったりするので、家でも会社と同じような働き方をしたいなら、こういったデバイスで補えるのかな。 西 ： 匂いと記憶は結びつきやすいですよね。懐かしい匂いがしたら、その記憶を思い出す。 12時にカレーの匂いを出してくれたら腹が減りますし（笑）。そんな匂いでコミュニケーションするデバイスもあれば面白いですね。 社会人が理解できないものにこそ価値があるかもしれない ーー 産学共同研究は自分たちの活動にどのように応用できそうでしょうか？ オンライン座談会の終わりにみんなで撮影。司会は基盤統括、堀内さん（右下）でした。 佐藤駿 ： 学生の意見を聞くことで、若い人がどんな価値感で動いているかわかったので、若い人向けのサービスを考えるときに有効だと感じました。 空久保 ： 学生のアイデアを生かし、私はプログラミングができるので技術力を提供することで協力できますし、やりたいことがあったときに事業会社の組織や人脈を紹介して、学生と連携・実践していくこともできます。 松村 ： 同じく、今回のプロジェクトを通じて私たちはいろいろと情報や刺激をいただい上で、私たちの得意としていることを提供することで、もう1歩先に踏み出せると思います。 佐藤駿 ： 学生の柔軟な発想を知ることができましたが、BIGLOBEにも言えることで、社内にも自由な発想を持っている人はいます。しかし、やりたいことを発信した時に後押ししてもらったり、実際にやれる環境があるかどうかがこれから大事だと感じました。今も新サービス創出に関わっている人がいますが、みんなが活動しているわけではないので。 空久保 ： 若い社員のやりたいことを上司が理解できなくても、「こんなことをやりたい」と言ったときに後押ししてあげるのは大事ですよね。 松村 ： そうですね。あと、承認者はなるべく少ない方がいいし、手軽な企画はとにかく出してしまう。これはいけるなというものは、いかに作って実績を作るかが大事なんだと、学生の発表を通じて感じました。 オンライン座談会の終わりにみんなで撮影。BIGLOBEの「B」に挑戦。「B」に……見えるかな！？ 西 ： 産学共同研究はシリコンバレー的な発想ですよね。学生はアイデアを考えられるけど、実現可能性を考えるのは難しい。逆にビジネスの観点や実現性を考えることは私たちはできる。その連携ができれば、新しいプロダクトにつながると感じました。 川口 ： たしかにそうですね。しかも、今回はエンジニアに関係ある大学ではなく、美術大学と組むというのが、どういう成果になるのか楽しみに感じています。自分が理解できない発表もありましたが、社会人が理解できないものにこそ価値があるのかもしれません。 福田 ： 理解できるものはすでに世の中にあるものが多いですよね。一見価値が理解できないものの方が、ビジネスとしてのポテンシャルがあります。BIGLOBEでも、新規事業を立ち上げるなら、予算内である一定の制約を守れば何を企画してもいいなど緩めのルールを作って、自由にできるという枠組みがあればいいですね。そういった企画を学生と一緒に取り組めるといいなとも感じました。 今回は、学生の構想発表を通じてBIGLOBE社員がトークする座談会の内容について、レポートさせていただきました。多摩美術大学とBIGLOBEの産学共同研究取り組みは、7月の作品展示、発表に向けて、現在も進行中です。 このBIGLOBE Styleでは、今後も取り組みの様子を随時公開していきますので楽しみにしていてください。

こんにちは。BIGLOBE Style編集部の吉田です。 今回は、弊社へ入社後間もなくして副業をスタートしたエンジニアの河野宇朗へのインタビューをお届けします。 「時代の流れや生活スタイルにあった多様な働き方を模索していきたい」という河野に、副業のきっかけやメリットについて聞いてみました。   Ｑ１：普段の仕事について Ｑ２：副業について Ｑ３：副業を始めたきっかけや背景 Ｑ４：副業を始めるとき、不安はなかったですか？ Ｑ５：周りの反応はいかがでしたか？ Ｑ６：本業と副業、相互にどう生かしているか教えてください Ｑ７：副業で得られる経験やメリット、魅力とは Ｑ８：ある日の一日スケジュール Ｑ９：今後の展望   Ｑ１：普段の仕事について 私は2020年8月にBIGLOBEへ中途入社しまして、「ビッグローブ光」の販売管理システムの開発・運用業務に従事しています。現在はシステムのAmazon Web Services（AWS）移行や、改善業務を行っています。 前職でAWSを使ったSaaSを開発していたので、BIGLOBEでもそのスキルをどんどん発揮したいと考えています。 サービス開発部 河野 宇朗（かわの たかお） 2020年8月中途入社   Ｑ２：副業について 副業ではAWSやGoogle CloudでのSaaSのバックエンド開発をしています。具体的にはPythonやGo言語を使用してAPIやバッチを作っています。言語は違いますが、本業とやっていることは同じです。   Ｑ３：副業を始めたきっかけや背景 BIGLOBEに入社して間もなくの頃に、前職の同僚から紹介を受けたのをきっかけに始めました。 当時、担当サービスではAWS移行がまだ始まっていなかったため、「これまで培ったAWSの知識を忘れたくない」という思いがあったんです。 他にも、これからの時代の働き方を考えた時に、副業やマルチワークというのを自分でも考慮に入れるべきではないかと考えたこと、新型コロナウイルスの影響から、ほぼ在宅ワークになって往復の通勤時間が余ったことも副業をしようと思った理由です。   Ｑ４：副業を始めるとき、不安はなかったですか？ 副業の業務内容については、使用したことのある技術スタックを使っていることや、経験のあるSaaSの開発ということで不安はあまりなかったです。 一番不安だったのは確定申告や請求書作成といった事務手続きができるかということでしたが、意外と上手くこなせています。   Ｑ５：周りの反応はいかがでしたか？ 副業申請するにあたって上司に相談してみましたが、「制度があるんだから問題ないんじゃない」との反応でした。実際、申請してみたところ、すんなり承認されて拍子抜けしたのを覚えています（笑）。チームメンバーについても批判的な意見は皆無で、「どんなことやってるの？」くらいです。 BIGLOBEでは、2018年4月から制度として副業が可能となっているので、社内でも浸透しています。そのため、抵抗感なく受け入れられる環境になっているのではないかと思います。   Ｑ６：本業と副業、相互にどう生かしているか教えてください 本業と副業では作っているサービスが全く異なりますが、バックエンドというくくりでは同じなので、自分の得意な分野で成長する機会を2倍得られているという認識です。 本業では販売管理システムの実装をしており、業務知識を理解する能力や、数多くある社内システムと外部インターフェースの仕様を理解する能力が求められています。一方、副業では、アーキテクチャを自分で設計してから実装することも多いため、AWSとGoogle Couldの様々なサービスを検証して実装まで落とし込むスキルを磨いています。 一方で得た知識を他方に生かすというよりは、双方から得た知識でスキルアップすることにより相乗効果を得ることができているのではと思います。   Ｑ７：副業で得られる経験やメリット、魅力とは 金銭的なメリットはもちろんありますが（笑） 、エンジニアとしての副業の話をしますと、やはり経験が多くなるというのは大きなメリットです。AWSやGoogle Cloud、JavaやPythonやGo言語とひとつの業務だけでは経験することができない技術スタックのスキルを、同時進行で磨いていくことができるのは副業の魅力だと思います。その分頭の切り替えが大変ですが。 Ｑ８：ある日の一日スケジュール よくあるパターンはこんな感じです。 6時起床～9時本業開始～19時本業終了～21時副業開始～23時副業終了 夜に集中して副業をするので、朝の方が余裕があります。非常にまれに業務が長引いた場合は、副業を諦めて休日に回します。 副業では１週間単位でタスクを切ってもらっているため、１週間の間で業務量が調整出来るのでありがたいです。 Ｑ９：今後の展望 より優秀なエンジニアになりたいとかもありますが、いろいろな働き方を模索していきたいという気持ちが強いですね。例えば、場所を選ばない働き方など、より柔軟な働き方ができるようになるといいなという期待を持っています。BIGLOBEでは ONSEN WORK に力をいれているので、私も温泉地で仕事ができるのを今から楽しみにしています！   最後までお読みいただきありがとうございました。   BIGLOBEでは、各種休暇の時間単位取得も導入。子どもの学校行事、家族の通院の付き添いなど短時間で済む用事の場合は半日休暇を取らずとも1時間単位の取得が可能です。 今後も社員の生活スタイルに合った働き方が実現できるよう、取り組んでいきたいと思います！   副業関連の記事はこちら。 style.biglobe.co.jp style.biglobe.co.jp   ※ Amazon Web Servicesは、米国その他の諸国における、 Amazon.com ,Inc.またはその関連会社の商標です。 ※ Googleは、Google Inc. の商標または登録商標です。 ※ Javaは、オラクルおよびその関連会社の登録商標です。

こんにちは。BIGLOBE Style編集部の吉田です。 みなさんは、仕事で仲間に助けてもらった時、その感謝の気持ちをどうやって伝えていますか？ BIGLOBE社内には、感謝の気持ちを伝えあう、素敵なシステムがあるんです！ そんな社内の感謝がつまったシステムでしたが、人事システムの刷新にうまくフィットせず、今年4月に廃止されることに…。 そこで、 「内製でシステムを作ろう！」 と立ち上がってくれたのが、当時新人だった5人のエンジニアたち。 入社してから1年間、実践と共にみっちり 新人研修 で鍛えられた彼ら。その 新人研修最後のミッション「チーム開発演習」 の一環として、これまでの成果を発揮してくれました。 「Scrum（アジャイル開発の手法の１つ）」で取り組んだこの開発演習。チームで作るメリットや楽しさについてこの2人に話を聞いてみました。   （2021年4月取材／撮影時のみマスクを外しています） 左： フロントエンド 大谷 優多（おおたに ゆうた） 基盤本部   マーケティングプラットフォーム部 2020年4月新卒入社 学生の頃はAI機械学習の分野で画像の認識を学ぶ。入社後は社内のオンプレミスをAmazon Web Services （AWS）へ移行する業務に従事。今年度からは、AWS上でのシステム構築を担当する。 右： バックエンド 川口 永一郎（かわぐち えいいちろう） 基盤本部   ネットワーク技術部 2020年4月新卒入社 学生の頃はグラフ理論やSDN（Software Defined Networki ng ）領域を学ぶ。 入社後はDNS（Domain Name System）サーバの運用を担当。   なぜScrum（スクラム）なの？ 新人エンジニアたちが社内に貢献 チームで作るということ 実践的な研修での学び 入社2年目の抱負     なぜScrum（スクラム）なの？   本題に入る前に、なぜ Scrum（スクラム）なのか、「Scrumで作ろう！」と決めたプロダクトオーナーの人事部長・ 杉森（元エンジニア） に話を聞いてみました。    今は、最終的な仕上がりを計画して作るという時代ではなくなったと思っています。 ものづくりって、Scrum が効率いいんです。 短期間で区切って作ったものをみんなで確認しながら軌道修正を繰り返す、といったやり方のほうが最短で作れますから。 当時の新人が取り組んでくれたこのシステムも、ある程度のイメージはありましたが、どれが最適なのかまでのイメージが出来ていなかったので、Scrum が適していました。 プロダクトへの要望はバックログにまとめて、優先順位の高いものから実装。バックログの中には実装しなかったものも多くありますが、最終的には短期間で理想のカタチに仕上げてくれました。 実際の画面イメージから一部抜粋 感謝の気持ちをポイントとして送り合います。もともとは、「 ビッグローブマインド 」を発揮している仲間を顕彰するこのシステム。 マインドが発揮されると、結果的に周りの仲間を助けて、感謝が集まるという仕組み。   新人エンジニアたちが社内に貢献   ────　リリースおめでとうございます！お2人とも、現在は新卒入社2年目となりましたが、1年目から社内に貢献できたことをどう思いますか？   大谷 ：素直に嬉しいです。みなさんからのフィードバックもあるので、実際に利用してくれているんだと実感しています。 外部のシステムを利用するにはかなりの費用がかかってしまうので、これからもこのような社内システムを内製で作っていけたらいいなと思っています。   川口 ：タイムラインを実装したので、ポイントをおくった人、もらった人が見られるようになっています。それを見ると、リリース後から多くの方が利用してくれているのが分かり、嬉しいですね。   ────　周りの反応はいかがでしたか？   川口 ：以前のシステムより使いやすくなった、という嬉しい声をいただきました。   大谷 ：ほめ上手な方が多くて（笑）。1カ月で作ったとは思えないとも言っていただきました。   ────　1カ月で作ったんですか!?   大谷 ：はい。この4月に旧システムが廃止されると決まっていたので、2月中旬からスタートして3月末にカタチにし、4月頭にリリースしました。 ────　そんな短い期間でどのように進めたのでしょうか？   大谷 ：仕事の合間を見つけながら、結構過密スケジュールでしたね。フロントエンドとバックエンドに分かれて進めるので、まずは共通の仕様を作るところからスタートしました。   川口 ：それから、プロダクトオーナーとスクラムマスター、開発メンバーが週1で集まり、デモ・振り返り・計画を立てるというスプリントを繰り返しました。   チームで作るということ   ────　チームで作る良さって何ですか？   川口 ：普段の仕事ではScrumのような開発手法を用いていないので、直接体験できて良かったです。 デモのあとに、うまくいったこと、できなかったこと、これからやるべきこと、学んだこと、楽しかったことなどをみんなで共有できたのが面白かったですね。 また、バックエンドでは基本的にスクラムマスターの先輩社員とペアプロ（ペアプログラミング）をして、作っている横でアドバイスをくれたりバグを見つけてくれたりするので、それも効率的で勉強になりました。   大谷 ：そうですね、普段の業務は個々が別の作業をしていることが多くて、みんなで何かを一緒に作っていくことがありませんでした。今回、オンライン上で雑談を交えながら一緒にコードを書いたりするのが楽しかったです。 デモの前日にはオンラインで集まって、「ここがバグってる！」「エラーが起きた！ヘルプ！」とか言いながら助け合っていました（笑）。   ────　難しかった点を教えてください。   川口 ：技術的には、Google Spread Sheetsでポイントやコメントの管理をするという特殊な開発の部分は難しかったですね。   大谷 ：フロントエンドは、みんな画面を作る知識がないところから始めたので、どうしたらうまく開発していけかるかというところ。みんなのスキルを考えて、共通して開発できるベースとなるプログラムを整えるのが非常に苦労した点でした。     実践的な研修での学び ────　かなりの成長がうかがえますが、この1年間で学んだことは何ですか？   川口 ：Scrumでも優先順位や期限を決めて自立的に動くということが求められますが、普段の業務からもタイムスケジュールや優先度の付け方などは身についたと思います。 Amazon Web Services （AWS）も入社してから勉強をして、認定資格（ソリューションアーキテクト）を取得しました。 また、GitHubの実践的な研修をきっかけにチャレンジしたのが、オープンソースソフトウェア（OSS）へのコントリビュートです。OSSにプルリクエストを送ってみようという研修だったんですが、実際にやってみたら自分でもOSSに貢献できたんです。この実践的な研修のおかげで大きな発見ができました。これからもこの活動を続けて、スキルアップしていきたいですね。   大谷 ：僕はこの1年でDX改革やAWSのセミナーなど、いろんなものに触れさせてもらって、考えが広まったと思っています。 クラウドについては、知識ゼロのところから勉強を始めて、AWS認定資格のアソシエイトを3つとも取得しました。AWSに移行する業務で実際に触る機会があるので、勉強したことを活かすことが出来たと思います。 あとは、参考書を読みながらプログラミングもしています。   ────　これまでに、つまずいたことはありましたか？   大谷 ：それが…入社後すぐ（笑）。アプリケーションは触ったことがあったのですが、いきなりサーバのレイヤーで頑張ろう！ってことになって。 何をどう聞いたらいいかもわからない状態だったので立ち上がりが遅かったですね。それからAWSの勉強をして知識をつけて「ここが分かりません！」と聞けるようになりました（笑）。   川口 ：僕の場合はサーバのOSを切り替える作業で、問題がないか試験をするんですけど、その方法を聞くのに手間取りました。在宅勤務でなければ気軽にすぐ聞けるんですが、チャット上でいかに状況を分かりやすく伝えるか工夫をしながら解決していました。   ────　入社後1番の成長エピソードを教えてください。   川口 ：Linuxのコマンドをかなり覚えましたね。おかげで、今ではサーバの構築も先輩に頼らずできるようになりました。あとは、シェルスクリプトで作業の自動化とか。実践しながら覚えていきました。   大谷 ：僕はクラウドの引き出しが結構増えたと思います。最近、半年前に自分が書いたコードを見返してみたんですが、「いったい何を書いているんだ…？」という感じだったんです（笑）。 そこから現在までの半年間で、AWSのサービスを勉強したり実際に構築していく中で、どんどん洗練されていってるなと感じています。   入社2年目の抱負    ────　それでは最後に、入社2年目の抱負をお願いします！   川口 ：僕の所属するチームでは、今年の秋位から本格的にAWS移行が進むので、AWSのスキルを実践でもっと伸ばしていきたいと思います。   大谷 ：この4月に所属が変わったので、熟練された先輩方に追いつけるよう、新しい業務を必死に覚えていきたいです。 個人的にはAWSのプロフェッショナルを2つ取得するのが目標です。 勉強は習慣になっているので苦じゃないんです。在宅勤務の日は朝起きてから始業までに2時間あるのでそこを勉強の時間にあてたり、通勤の場合は通勤時間に勉強しています。 毎朝AWSです（笑）。 情報処理安全確保支援士というセキュリティの国家資格を取得した同期もいるので、僕もいずれチャレンジしたいですね。 いろんな知識をどんどんつけて、究極的にはどこででもやっていけるプロフェッショナルなエンジニアになりたいと思っています。   最後までお読みいただきありがとうございました。 1年間の新人研修をベースに、同期同士が切磋琢磨しながら成長し続けている雰囲気を感じ取っていただけたら嬉しいです。 BIGLOBEではこのように共に成長し、インターネットを支えてくれる仲間を募集しています。採用情報はこちらをご覧ください。 www.biglobe.co.jp hrmos.co ※ Amazon Web Servicesは、米国その他諸国における、Amazon.com, Inc.またはその関連会社の商標です。 ※ Googleは、Google LLCの商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは、BIGLOBE 基盤本部 基盤統括部にて、新サービス創出活動推進を担当している吉川です。 2021年4月より「技術を通して、もう1つの通信を考える」をテーマに、多摩美術大学 情報デザイン学科の永原教授、清水講師、学生の皆さんとの産学共同研究プロジェクトが始まりました！ 多摩美術大学 × BIGLOBE　産学共同研究プロジェクトとは 第1回講義：世界と日本の「通信史」について 第2回講義：BIGLOBE事業紹介 第3回講義：通信の過去・現在・未来のサーベイ 現在（2021年5月時点）は、毎週積極的な意見交換やアイデア出しが行われています。講義の様子をBIGLOBE社内に向けてオンライン中継しており、学生のアイデアを見て、BIGLOBE社員も「こんな視点でも考えてみると面白いかも」「この考察はすごく共感できます！」といったコメントや新しい気づきを得ることができています。 vol.1の記事では、4月16日、23日、30日に多摩美術大学にて行われた講義の模様について、ご紹介させていただきます。 多摩美術大学 × BIGLOBE　産学共同研究プロジェクトとは 「技術を通して、もう1つの通信を考える」というテーマに沿って、多摩美術大学の学生が作品やそのプロトタイプなどを制作します。 　インプットの講義や学生のアイデア発表を含めた創作活動の過程をBIGLOBE社員がオンラインでリアルタイムに参加及び録画視聴できる環境を作っています。 　学生の作品制作のプロセスへの参加を通じて、Z世代が通信というものをどのように考え、認識しているのかといったことへの気づきや、学生のアイデアからインスパイアを受けることで、BIGLOBE社員が将来の新サービス検討などの新しい取り組みにつなげていくことを目的に取り組んでいます。 第1回講義：世界と日本の「通信史」について 4月16日（金）の初回講義は、多摩美術大学の永原教授より、「通信史」についての講義が行われました。 まずは紙とカラフルなペンが生徒一人ひとりに配られ、ノートテイキングの方法のレクチャーから。普段はパソコンやスマホ、iPadなどデジタル製品になれている生徒たちに、あえて講義の内容を紙に絵で視覚的にまとめるグラフィックレコーディングに挑戦させる試みです。 講義内容は、「そもそも通信とは何か？」という、辞書的な意味の説明からはじまり、“のろし”、“旗”、“矢文”、“鳩”といった手段がとられていた歴史を振り返りました。 また、聴覚で物事を伝えるために“法螺貝”を用いた歴史に触れ、動画で「ぶぉぉぉ～」という音と映像を教室に流すことも。法螺貝に馴染みのない学生が興味津々に映像を眺める様子が伺えました。 その後は時系列に…… 1667年：⽷電話（ピンと張った⽷を使って、遠いところに⾳を同時に伝えることができる恋⼈たちのテレフォン） 1684年：イギリスの天⽂学者ロバート・フックによる信号伝送⼿段の考察「⾃分の考えを遠隔地に伝える⽅法」 1690年：フランスの物理学者ギョーム・アモントンがリュクサンブール庭園で信号の伝達に成功 1790年：電気・音・望遠鏡を利用した信号伝達方式（政府が最短時間で遠隔地に命令を伝達する構想）が生まれる 1846年：腕木通信機が通信網として完成し、この頃にネットワークという概念も生まれる 1876年：グラハムベルが電話の実験に成功（1875年 〔Alexander Graham Bell〕⾳響通話装置の特許申請 出典：WIkipedia アレクサンダー・グラハム・ベル（更新日 2021年4月30日版） https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%AC%E3%82%AF%E3%82%B5%E3%83%B3%E3%83%80%E3%83%BC%E3%83%BB%E3%82%B0%E3%83%A9%E3%83%8F%E3%83%A0%E3%83%BB%E3%83%99%E3%83%AB 日本でも1743年の文献、戯曲『⼤⾨⼝鎧襲〔おおもんぐちよろいがさね〕』に、旗振り通信が初めて登場しています。 出典：Wikipedia 旗振り通信（更新日 2021年4月6日版） https://ja.wikipedia.org/wiki/%E6%97%97%E6%8C%AF%E3%82%8A%E9%80%9A%E4%BF%A1 通信史の最後には、海底ケーブルや無線通信技術の発展の歴史なども振り返りました。まさに、通信を主力事業にしているBIGLOBEでも知っておくべきことだなと感じる講義でした。 そして、前半で通信の”過去”を学んだあと、後半の講義では”未来”を考えます。「2070年。今から50年後、70歳になったときにどういう通信をしているのか」というテーマで、アイデアソンを実施。30分ほどの時間を使って考えた内容について発表していきました。 「人が物質転送されてくる。本物ではなくても3Dで、歌手が目の前に現れ歌っているなども実現可能になる」 「言葉やテキストではなく、感情が機器につながり、自動でエアコンなどが動く」 「電動脳が開発され、言葉を発しなくてもテレパシーのように、会話・通信ができる」 「他の人が実際に見ている映像や景色を、その場にいなくてもリアルタイムで共有できる」 この記事では、その一部のみの紹介になりますが、全生徒が想い想いのアイデアを発表し、Z世代の豊かな発想にハッとする瞬間がたくさんありました。 第2回講義：BIGLOBE事業紹介 4月23日（金）の第2回講義のテーマは、ビッグローブ株式会社がインターネットサービスプロバイダー（ISP）として果たしている役割についてです。 通信の過去と未来についての講義に続いて、通信の現在、そのリアルについて、ISPとしての視点から紹介しました。 インターネットが電気や水道のような、あたりまえの生活インフラとして認識している学生たちに、BIGLOBEの歴史とインターネットの仕組みとそれを支える技術や設備について紹介していきます。 「BIGLOBEの歴史は、インターネットの歴史そのものです」 そんな説明から、インターネットの前のパソコン通信の時代から、インターネットの高速化とサービスの拡大がはじまり、スマートフォンの登場とSNSの拡大などを紹介していきます。Amazonやmixiなどの2000年代初頭に出てきた当時のサービスや、インターネットによって無くなった駅の伝言板や百科事典などを紹介すると、学生さんたちが今は当たり前のように使っているIT機器やWebサービスの便利さを改めて感じていました。 また、講義の途中では、「インターネットで今日の天気を調べてみてください。この情報はどういう流れで、最終的に自分のスマホやパソコンに結果が表示されているのか想像してA4の紙に図で表現してみましょう」というミニワークショップも設けました。 さすが美術大生、表現力豊かに、インターネットの世界をイメージしていました。 このワークショップの回答は、基盤本部の佐長から説明を行いました。 「インターネットがつながるということは、通信回線がデータセンターの中にあるDNSサーバにつながり、その後、コンテンツが格納されているさまざまなデータセンターとも接続しそこから情報を取得し、スマートフォンに表示させている」天気予報を見るという行為だけでも、非常に多くの場所と物理的につながってやり取りしていることを知り、学生たちもあらためてデータセンターの重要性を理解したようでした。 そして、今回の講義のメインは「オンライン」データセンター見学。インターネット上にコンテンツが増加すると同時に、コロナ禍の巣篭もり需要などからも通信のトラヒックは近年増大しています。その背景から、データを素早く遅延なく届けることをミッションにしているインターネットプロバイダの影響は大きく、機械が故障したり、電力供給が断たれたり、差し込むケーブルの場所を間違えたりすると、インターネットはつながらなくなってしまいます。 そんな背景を知った上で、本来なら実際にデータセンターを見学する予定でしたが、コロナ禍の影響もあり、オンラインでデータセンターから生中継という手法を採用しました。 学生たちには電気や水のような当たり前の存在になっているインターネットについて、物理的にケーブルと機械がつながっていて、それを保守、メンテする人たちによって支えられていることを伝える貴重な機会になりました。 また、配信の途中では「マシン室に入っているネットワーク機器の数は？」などクイズを出し、学生一人ひとりにマイクを渡して答えていただく時間を設けました。 いろいろな答えが返ってくると同時に、「データセンター内のケーブルコードの色は何を意味するの？」「データセンターを引っ越しする際はどのようにしているの？」といった質問も出てきて、データセンターからリアルタイムで回答するような交流シーンも見られました。 第3回講義：通信の過去・現在・未来のサーベイ 4月30日（金）の第3回講義は、通信の過去・現在・未来について学生一人ひとりが興味を持ったテーマを事前に調べてきて、3分程度のプレゼンを行いました。 中世ヨーロッパの暗号（ホーボーサインなど）という伝達方法から、江戸時代の飛脚、昭和・平成時代のポケベルや雑誌など、スマホの絵文字など、各自興味のあるテーマを掘り下げながら、学生ならではの率直な疑問や鋭い意見も数多く聴くことができました。 この記事では全てをご紹介できませんが、毎回一方的に講義を聴くだけではなく、生徒一人ひとりが主体的に学びアウトプットし、その発表に対して講師陣や現場にいたBIGLOBE社員からも感想やフィードバックがあるため、より学びを深めています。 また、生徒の発表をオンラインで見たBIGLOBE社員も、自身が得た学びや気づきをコメントしていました。今後、こういった意見交換・交流を深めていきたいと思います。 これから、7月までこの取り組みは続いていきます。このBIGLOBE Styleで、取り組みの様子を随時公開していきますので楽しみにしていてください。 Amazonおよび関連するすべてのロゴは、Amazon.com, Inc.またはその関連会社の商標です。 「mixi」は、株式会社ミクシィの商標または登録商標です。

はじめまして！ BIGLOBE 基盤本部 クラウド技術部 2020年度新入社員の佐藤 竣介です。(今年で2年目です) 私は現在業務として、Amazon Web Services (AWS)の利活用を推進するために、社内でさまざまなAWS勉強会を開催しています。 知識が足りないことが多々あるので、先輩方に何度も質問しながら勉強会の運営をしています。 私が運営してきた勉強会の中で、特に好評だった障害対応訓練×エンジニア交流会について紹介します！ 最近はクラウドの利活用を全社的に推進している弊社ですが、オンプレミスとクラウドでは考慮すべき点が異なるので、古い知識に引きずられて障害発生時の原因特定に時間がかかってしまう可能性があります。 またコロナ禍でリモートワークが増え、エンジニア間の交流が減少し、いざという時に相談すべき相手を把握しづらくなってきています。 そこで上記の課題を解決するために、AWSを使った障害対応訓練を実施したうえで、訓練での対応を題材にして参加者がディスカッションをするエンジニア交流会を開催することで、相互理解を深めました。 障害対応訓練 目的 障害対応の方法を学んでいただくこと（もし、今後同じような障害が発生しても対応できること） 内容 AWS上の本物っぽい障害に対し、ペアで障害復旧を目指す 時間 1時間30分 実施方法 2人1組 参加者の技術レベル 技術力問わず もちろん、コロナ禍なのでオンライン開催です！ 環境の準備や資料作成、当日の司会を、当時新人だった私が担当させていただきました。その中で感じた、障害対応訓練×エンジニア交流会を行う4つのメリットについてご紹介します！ 準備した環境 4つのメリット AWSなら簡単に準備できる AWS CloudFormationで環境構築 AWS Cloud9を使用し複数環境に障害を発生させる 障害について理解している人が増える 横のつながりができる ゲーム感覚で楽しみながら安全に障害を体験できる アンケート結果 最後に 準備した環境 今回の訓練では、下記のような一般的なWebサービスの構成を準備しました。 EC2上にはWordPressをインストールし、ウェブブラウザーから見られるように設定した後、わざと障害を発生させ、見られない状況にしてあります。参加者のゴールは、障害対応を実施しWordPressの画面を見られるようにすることです。 過去の事例をもとに、今回は下記の障害を発生させました。 EC2 t系インスタンスのCPUクレジット枯渇 RDSのSecurity Groupの設定を全て削除 RDSへのコネクション数増加による、コネクション溢れ 過去の障害事例とまったく同じ状況を再現することはとても難しいのですが、本物の障害のようだと感じられるように設定を工夫しました。 例えばRDSのコネクション溢れの原因はRDSへのコネクション増加としていますが、複数環境の全てのRDSに対してコネクションを増加させるのは大変です。 そこでコネクション数を増加させるのではなく、RDSの同時接続数の設定を1にして、すぐにコネクションあふれが発生するように工夫しています。 4つのメリット 私が実際に企画から運営まで担当した中で感じた4つのメリットについてご紹介します！ AWSなら簡単に準備できる 勉強会を実施する上で地味にとても大変なのが、参加人数分の環境を準備することです。 AWS CloudFormationとAWS Cloud9を使えばたちどころに環境を作成できるだけでなく、障害を発生させることまでできてしまいます。 なおCloudFormationには複数アカウントに環境を作成するStackSetsという機能がありますが、今回は環境作成後に障害を発生させる必要があったのでCloud9を使っています。 AWS CloudFormationで環境構築 CloudFormationはテンプレートファイルを事前に作成しておくことで、簡単に環境を構築できるサービスです。 テンプレートファイルの書き方は勉強する必要がありますが、一度書いておけば何度でも使いまわせるので後々大変楽になります。 CloudFormationはAWSマネジメントコンソール、もしくはCLIから起動します。 AWS Cloud9を使用し複数環境に障害を発生させる 参加者はペアになって障害対応に取り組みます。他のペアの環境に影響が及ばないようにするために、ペアにつき1つのAWSアカウントを準備し、環境を構築しました。 今回は環境構築後にあえて障害を発生させる必要があります。障害を発生させるために、外部からそれぞれの環境にログインすることもできますが、 参加人数が増えるほど、運営の手間が増えてしまいます…。 AWSアカウントに何度もログインし直すのは少し面倒ですよね。そこで、Cloud9を活用することにしました。 まず管理アカウントのIAM Userが複数のハンズオンアカウントにスイッチできるように設定します。その後Cloud9のプロファイルを設定し、他の環境にスイッチして作業できるようにします。 こうすることで、Cloud9から複数のAWSアカウントに対してCloudFormationや障害を発生させるためのCLIコマンドを実行できるようになります。 この設定をするとしないとでは作業効率が全然違いました。 少し面倒ですが、事前に設定しておくと便利です。 以上のようにAWSでは参加者用の環境の準備が簡単に行えます！ 障害について理解している人が増える 弊社では障害の発生原因やその対処について積極的に共有しています。しかし、実際に自分が体験していないと、同じ障害が発生した際に自分がうまく対応できるか不安が残ってしまいます。 そこで、今回のような障害対応訓練を実施することで、障害を他人事ではなく自分事に昇華させ、障害について深く理解をしている人を増やすことがとても大切です。 実際に参加者から、障害事例について知っていたのに対応できなかった、という感想がありました。障害を自分で体験することはとても大切であると感じました。 横のつながりができる コロナ禍になる前はオフラインで勉強会が盛んに開催されたり、全員が出社していたので、誰が何について詳しいかなんとなく把握できていたそうです。 いざというときに頼れる人を知っておくことがとても重要です。コロナ禍の影響によりリモートワークが増えている状況では、部署を超えた交流をあえて作っていく必要があります。 今回はペア作業で障害対応に取り組むだけでなく、訓練後にエンジニア交流会を開催し、誰がどのような対応をして、どのような知識を持っているかについて理解する場を設けました。 障害に限ったことではなく、日々の業務を行う中でも部署を超えたつながりがあることはとても大切だと感じました。 ゲーム感覚で楽しみながら安全に障害を体験できる 今回実施したのはあくまで障害対応 ”訓練” であり、間違った対応をしてしまったとしても事業に影響が出るわけではありません。 よって、自由にトライ＆エラーができる環境の中で、障害について学ぶことができます。 復旧の重圧がなく実施できる障害対応は、いわば「謎解きゲーム」のようなものかなと思います。 過去にあった障害について、安全に楽しく障害の発生原因を突き止めながら、障害についての理解を深めることができます。 以上が障害対応訓練、エンジニア交流会を開催して私が感じたメリットになります。 アンケート結果 ここまでで4つメリットをご紹介させていただきましたが、参加者が満足していなければ成功とは言えません。 そこで参加者にアンケートを実施したところ、下記のように高い満足度を得ることができました！ また、たくさんの嬉しいコメントがありました。 大変有益な内容だったので、継続的に実施して欲しい！ リモートだと部門外の方との関わりが少なくなるので、非常に有益でした ノーヒントだったのがよかった 理不尽さの無い課題で手ごたえがあった！ クレジットなど普段は気を付けてるのにいざとなると気が回らないことがわかり　良い反省点となった 特に、最後のコメントに障害対応訓練の手ごたえを感じました。訓練の目的の1つが、今後同じような障害が発生しても対応できることです。「事例については知っていたものの、障害について気づけなかった」という経験が、実際の障害対応に役立つことは間違い無いと思います。 今後もさまざまな障害を取り入れ、こうした訓練を行うことで、BIGLOBEの品質向上に貢献できるように日々精進していきたいと思います。 最後に 高い満足度に強い手ごたえを感じています。改めて障害事例を実際に体験してみることやコロナ禍ではより密接にコミュニケーションを取る必要があると感じました。 今回新人として障害対応訓練に携わらせていただきましたが、環境の準備から障害を発生させるまでの間に、たくさんの知識を深めることができました。最初から教える側に回ることは大きな苦労もありますが、その分自分に足りていない知識が浮き彫りになるので、大変勉強になります。 障害対応訓練は開催する側も、受講する側もとても学びが多い勉強会です。 メリットがたくさんの障害対応訓練×エンジニア交流会の開催をぜひぜひ検討してみてはいかがでしょうか？ 「まず先に、AWSのことをもっと知りたいな」と感じられた方は、以前ご紹介させていただいた記事を参考に、AWSのハンズオンを行ってみることをオススメします。 ぜひこちらも覗いていってください！ style.biglobe.co.jp ※Amazon Web Servicesは、米国その他の諸国における、 Amazon.com ,Inc. またはその関連会社の商標です。