BIGLOBE鈴木(研)です。今日は、少し時を遡り、2019/10/24～25でVMUGの皆さんと沖縄に行ってきた際のレポートをしたいと思います。 www.facebook.com 宜野座ITオペレーションパーク、OIST(沖縄技術大学院大学)の見学をしつつ、LTでスポンサー企業やVMUG会員が発表しました。 私もLTで発表したので、その内容は後述したいと思います。 ■宜野座ITオペレーションパーク www.ginoza-sf.jp 国際通りで待ち合わせ、宜野座村の担当の方が迎えに来てくれました。 バスで1時間くらい高速道路を走り、到着しました。 中の写真撮影はNGとのことで、文言だけのレポートとなります（2019/10時点の情報です）。 大きくは、サーバエリア、コンタクトセンターエリア、事務所エリアに分かれています。 事務所は、2～3名から利用可能、部屋をパーティションで区切って30㎡～利用可（スモールスタート可） 10社（沖縄県外9社）が入っている 村の採用者数は30名ほど 企業の人を含め、7:3で女性なので、女子トイレしかないフロアがあるのはびっくり 海抜24mで、津波が来ても安心 空調設計はちょっと古そう、天井が妙に高かった 免震は震度6～7まで耐えられる（沖縄は地震が少ない） 蓄電池は10分持つ 電力2秒断で発電開始、200kVAで3日間持つ 台風が多くて、電力会社からの電力供給が止まったことがあったが、3日耐えたことはある（その後、近くの変電所からの送電は地下埋設） 築17年でそろそろ設備更新だが、夏の工事は無理（台風が多いので） VMUGリーダの方のDRサイトがあったので、そのラックをちょっと見学させてもらいました。 近くに、阪神タイガースのキャンプ地がありました（バスで横を通過しただけでしたが）。 見学後、事務棟の屋上で、バーベキューをふるまってもらいました。 屋上からの写真です。絶景を見ながらのバーベキューは最高でした。 変わり種で、ヤギ汁をいただきました。結構癖がありました。 ■OIST(沖縄技術大学院大学) 沖縄科学技術大学院大学 OIST 国際通りで待ち合わせ、バスとハマーに分乗して向かいました。やはり高速道路を1時間くらい走った気がします。 順番でハマーに載せてもらいました。 外国の大学のキャンパスのような雰囲気（アメリカのドラマに出てくるような）でした。 8割以上は外国人の学生（出身地60か国）とのことで、公用語は英語とのことです。 学生含め教職員合わせて1100名以上が在籍しているそうです。 最初の学長が医学系の方のようで、見た感じ、医学/生物系の色が強いように思いましたが、 物理学、海洋科学、化学、数学・計算科学などの研究も行っているそうです。下の写真の方々は学生さんではなく、VMUGメンバです。 OISTのITディビジョンについて、担当の方から説明をしてもらいました。概要はこんな感じでした。 約30名で1100名の面倒を見ている OIST内にDCがあり、宜野座や奈良先端科学技術大学院大学とDRを組んでいる 学術情報ネットワーク（SINET）で大学間を連携 AWS、Azure、Salesforce等々を積極的に活用 VDIとクリティカルなシステムはオンプレ ■私のLTの内容 一応、登壇した時の証拠写真を他のVMUGメンバに取ってもらいましたｗ タイトルは IaaS基盤の所有→利用へのシフト です。 弊社のIaaS基盤を、今後利用した分だけ支払うモデルに切り替えていくことを検討しており、その中で私自身が会計的な知識が無いためにいろいろ勉強したことを、まとめてみました。 目的は、 VMUG会員の企業の方においては、同様の検討をしているかもしれないので、私が検討した内容を情報共有をさせていただく スポンサー企業の方に対しては ユーザ企業はこういうことを気にし始めているよ ということを把握いただく です。 １）利用と所有 利用と所有について、まずは整理してみました。 色々の比較軸はありますが、オフバランスかオンバランスか、という違いに着目してみます。 オフバランスとオンバランス オンバランス　→総資産が増える　　→自己資本比率が下がる オフバランス　→総資産が減る 　　→自己資本比率が上がる https://www.kessansho.com/general/study/04_05.html ２）長期前払費用とは？ 会計知識の乏しい私が悩まされたのが、 長期前払費用 です。一般的な会計の費目のようなので、これを機に勉強してみました。 期間が1年を 1日でも 超えると、資産計上しなければならない 長期前払費用が嫌がられるケース 何でそんな先までの費用を今払わなければいけないのか？キャッシュフローの悪化は避けたい会社もある 払うのは、その都度が良い https://keiriplus.jp/tips/cyoukimaebarai_hiyou/ オフバランスにしたいなら、長期前払費用にならないようにする必要があります。 ※複数年間でのトータルコストが下がればよいという場合もあり、企業ごとにポリシーは異なる ３）IFRS16号とは？ もう1つ気にしておかなければいけないのが、 IFRS16号 のようです。必ずしも「リースならオフバランスに出来る」という訳ではなくなったってことのようです。 現時点でIFRS未適用企業でも、2023年くらいには強制適用になる可能性もあるとのことです。 2019年1月1日以後に開始する事業年度からは、国際財務報告基準IFRS16号による新リース基準が強制適用 新基準では、全てのリースがオンバランス処理（＝資産計上）となる これまでは「売買か賃貸か」でオンバランスとオフバランスが判断されていたところが、今後は「リースか否か」がそれに代わるということになる ※長期前払費用にならなくても、リースで調達したものは、全て資産計上が必要になるそうです https://keiriplus.jp/tips/ifrs_lease/ https://www.itmedia.co.jp/business/articles/1909/09/news005.html ４）この設備、資産計上しないといけないの？経費処理でOKなの？ このあたりは、会社の会計に詳しい方にヒアリングをして教えてもらいました。ただ、この基準は、それぞれの会社の会計ポリシーによって変わるようですね。 「占有」しているかどうかがポイント 基本的には、各会社の会計処理のポリシー次第 クラウドだろうが、オンプレだろうが関係はない 例えば、 AWSの利用料は、どのラックのどのハードを占有しているとは言いづらい（VMがどこにいるのか流動的） ⇒現時点では、経費処理でOKと判断する会社もある オンプレに導入する機器は確実に 占有 するので、資産計上する場合が多いようです。 ５）IaaS基盤「利用」のパターン 弊社で検討している「利用」のパターンとして下記2つがあります。 オンプレ持込型 各SIerさんの提案 個別SI案件の色が強く、割高 VCFベース管理なので、管理クラスタ分でコストが下駄を履く サーバ増設で初期費を取るベンダも・・・ リースでの提案をしたところもある・・・ VMC on DellEMC 日本リリースはまだか？ マルチテナントでの利用は現時点ではNGっぽい 外部リソース型 VMC on AWS 最低4ノード（マルチAZは8ノード） VMC on AWSの制限（現時点） マルチテナントが現時点でNG ⇒近々でこの制限は解除される見込み NSX Edge Load Balancer、Third Party Service Insertionがオプションで「ホスト利用量の約6％の金額」とのこと ⇒標準にしない＝AWSのELBを使う前提か？ IBM Cloud 責任範疇がHWまで vSphere/NSX/vSAN等の運用保守は別（将来的にはIBMも自営でやるかも、とのこと） ⇒運用保守する会社と組んでもらう必要あり ※ 記載されている会社名、製品名は、各社の登録商標または商標です。 ６）まとめ 仮想基盤も所有→利用の流れに オフバランスにしたい会社も増えてきた キャッシュフローを気にする会社は多い リースはNG（IFRS16号） 1年を超える費用は要資産計上（長期前払費用） ⇒期間の縛りはあっても、年払いが望ましい 外部リソース型がよさそう（規模次第で要資産計上） 運用保守やリニューアルの工数を外出ししたい いずれにせよ、 各企業の会計ポリシー次第 で、オンバランスのほうが良いのかオフバランスが良いのかは変わってくるということは、留意しておく必要があります。 ■番外編 私自身、人生初の沖縄でしたので、結構ワクワクしてました。 飛行機を降りて、いきなり夏に戻った感じでした。 ソーキそばを飛行機を降りてすぐに食べました。 懇親会で生ライブ。結構盛り上がっておりました。 最終日の夜に、てびちそばを食べました。 これが豚足かと。結構骨っぽいんですね。ぷるんぷるんでおいしかったです。 東京に帰ってきて週明けすぐに、首里城が燃えたというニュースを聞いて、「あぁ、燃える前に見れるチャンスだったのに、行けばよかった」と後悔しました。 ドラクエウォークのお土産も首里城にあったようなので、行けばよかったです。。。 ■まとめ ちょっと外国っぽい雰囲気に浸りつつLTに参加するというのも、いつもと違って新鮮な気分になりました。私にとっては、初沖縄ってのもありましたので。 参加者の皆さんも、沖縄の雰囲気でハイになっていて、LTでのテンションも上がっていたように思いますし、私の発表後もすぐに「ここはこうだよ、ああだよ」って教えてくれたりと有意義でした。 他の参加者のLTの内容も、とても興味深く拝聴させていただきました。 参加者の皆さんとの連帯感も醸成できた気がして、Japan VMUGがさらに盛り上がる予感もしております。 ■お知らせ VMwareユーザ会（VMUG）に興味のある方は、 https://www.vmug.com/membership/membership-benefits をご覧いただいて、もしよろしければ入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。 以上です。

はじめに BIGLOBEの西です。 まずは、12/14(土)の レガシーをぶっつぶせ。現場でDDD！2nd に、 ご参加いただいた皆様、ありがとうございました 今日はイベントの中で開催した、 1-B:モデル・コードの変更が互いにどう表現されるか体験するためのハンズオン のセッションについて解説と狙いを書いてみました。 この記事を読む前に、ぜひハンズオンを実践してみてください。 記事の解説がより理解できるようになります。 なぜハンズオンなのか？ 有名な格言があります。 「百聞は一見にしかず」「百見は一考にしかず」「百考は一行にしかず」 要するに、1ハンズオンは100万回 (100聞 × 100見 × 100考) 聞くのと同じ効果があります (単なる誇張です。 最近はDDDに関する記事も増えてきました。 基本的な知識や考え方を得る手段は多くなってきたと感じています。 それと同時に、 「どうやって導入・実践するのかが分からない」 という悩みも増えて来ていると感じています。 そのハードルを下げるために、 「とりあえずやってみた」 を経験してもらいたいと思いハンズオンを用意しました。 ハンズオンの概要 ターゲット層 DDDを知っているけどやった事はない or やってみたい。 コードを書いている人。 チームで開発をしている人。 体験できる事 サービス仕様からドメインモデルを作成する。 ドメインモデルからソースコードを作成する。 ドメインモデルとソースコードの関係性がちょっと分かる。 体験できない事 Entity : 状態の管理などライフサイクルの考え方。 Aggregates : トランザクションなど整合性の考え方。 Repository : 情報が永続化/コンテキスト外へ依存してる場合の考え方。 DDDモデリングハンズオンの資料 説明用資料 DDDモデリングハンズオン - レガシーをぶっつぶせ。現場でDDD！2nd from BIGLOBE Inc. www.slideshare.net ソースコード github.com DDDモデリングハンズオンの流れ 仕様の把握 ドメインモデルの作成 ソースコードの作成 (テストが通る事を目標にがんばる) ドメインモデルへのフィードバック 1. 仕様の把握 まずは何を作るのか仕様が分からなければ何も始まりません。 スライドでは説明のため図を用いていますが、可能な限り先入観を与えないように配慮しています。 仕様はマトリクス表など用いた説明の方が伝わりやすいですが、先入観も与えやすいです。 今回のセッションでも、説明後はテキストベースの仕様を紙で配布して仕様を把握してもらうようにしています。 (仕様＝ソースコードの readme.md ) 2. ドメインモデルの作成 名詞と動詞を探して、ValueObjectの候補を考えてみましょう。 ユースケースを当てはめてみて、モデル上で処理や依存が正しそうか考えてみましょう。 当日は名詞や動詞を付箋に書いて、シートに貼りながらモデルを作りました。 (みんなでドメインモデルを見る & 誰でも編集ができる状態を作るため) サラッと書いてますが、この作業を始めることが最もハードルが高いです。 (しかも、当日の参加者は初めて会った人たちと一緒にやるというハードルもありました) ドメインモデルを作ったことがないとゴールが見えないので、何のために名詞を探すのか見えてきません。 ただ、ここでも説明より体験です。 思いつく限りの名詞と動詞を集めてみましょう。 あと、採用されなかった、名詞、動詞も残しておくと後で議論に使えます。 このフェーズは一番議論が発散しやすいです。 「まずは〜のドメインだけを考えてみませんか？」 など、議論をファシリテートする人を置いて議論のターゲットを誘導した方がスムーズに進みます。 3. ソースコードの作成 ドメインモデルを忠実にソースコードへ落とし込み、まずはテストコードが通る事を目標にします。 この後の議論でモデルとコードを変更する可能性が高いため、 テストコードが動く状態(=動作が変わらない事が保証された状態)で、 リファクタリングをできるようにしたいためにです。 メソッドの引数、戻り値にプリミティブ型(String, int, long... etc)を使っていないか意識的に探して下さい。 使っていたら、その値は何のドメインなのかを考えて、ValueObjectにできないか検討してみましょう。 4. ドメインモデルへのフィードバック まずは、新しく見つかったドメインやメソッドがあればドメインモデルへ反映しましょう。 その上でドメインモデルが適切であるのかを議論してみて下さい。 議論が行き詰まった場合、ビジネス的にありえそうな仕様変更を考えて、モデルとコードにどう影響が出るのか考えてみると良いです。 変更するクラスやメソッドが少なければ、それはいいモデルです。 多くの変更が必要になるのであれば、モデルに良くない点があるのかもしれません。 この先の議論はゴールはありませんので、時間は区切ったほうが良いです。 社内でお試しで開催した時は議論が発散して2時間以上かかりました。 このハンズオンで一番体験してもらいたかったこと ドメインモデル ⇔ ソースコードを往復する意味を知ってもらう ドメインモデルからソースコードへ落とし込む事で、今まで見えていなかったドメインが見つかったり、理解が一気に進みます。 この事実が一番伝えたかった事で、 それは、理屈より体験する方がより実感できると思いハンズオンという形式にしました。 なぜ、モデルをソースへ落とし込むと理解が進む？ ドメインモデルとは？ ドメインモデルはソースコードに比べると抽象的なモノです。 仕様からドメインモデルを作成する時に、細部はあいまいなままでも作る事ができます。 (モデルではコンパイルエラーは発生しません。) しかし、初めはドメインへの理解が浅いため、細部は分かりません。 つまり考えても無駄です。前に進みましょう。 ソースコードとは？ ソースコードは厳格であいまいさや間違えを許してくれません。 あいまい=即コンパイルエラーです。 そのため、ドメインモデルの段階で残っていたあいまいさを、具体的に解消しなければいけません (例: 引数に渡すクラスを明確にする、料金を合計するためには新しいクラスが必要なった、など)。 依存関係も矛盾があれば気づく事ができます。 これらは、ドメインへの理解不足が表面化したために発生しています。 そして、その問題点を解決する事でドメインへの理解が深まります。 そして、再びドメインモデルへ ソースコードを作成したら、その知識を持ってドメインモデルを見直してみましょう。 その時のあなたは、昔のあなたよりドメインを理解しています。 強くてニューゲームです。 初めにドメインモデルを作成した時には気づかなかった新しい観点が見つかり、ドメインが磨かれます。 モデルという 抽象 とコードという 具象 を往復する事で、頭の中が整理されてドメインの理解が深まっていく。 これが、DDDモデリングハンズオンで体験してもらいたい狙いです。 まとめ 今回のお題は仕様としては単純でしたが、ハンズオンを開催すると、参加いただくチームごとに異なるドメインモデルができ上がります。 ドメインモデルには正解はありません。そのビジネス/システムで何を重要視するのかによって変わります。 そして、何を重要視するのか？それは、深いドメインへの理解でしか判断ができません。 DDDモデリングハンズオンでは、その活動をドメインモデルとソースコードを往復する事で体験してもらいました。 この体験がみなさんの、DDDへの理解の手助けになれば幸いです。 以上です

BIGLOBE鈴木(研)です。今日は、先日開催されたVMUG部会のLTで発表した内容を共有させていただきます。 部会の概要は、下記をご参照ください。 www.facebook.com テーマは、 VUM（vCenter Upadate Manager）のTips です。 弊社では、vSphere4.Xの頃から使っていますが、意外とVUMを使っていない会社が多いのにびっくりしました。 下記では、当日の発表内容に加え、その場で出た話や、話足りなかったことを補足しております。 ■弊社のVUM利用シーン ESXiのパッチ適用 下記は利用していない ESXiのアップグレード HW Verのアップグレード VMware Toolsのアップグレード アップグレードは、結構バグが多くてうまく行かないケースが多数報告（リリースノートの情報）されてきた歴史があり、弊社では手を出していません。 HW VerやVMware Toolsについても、VMを停止する必要があり、VMの利用者ごとに個別調整が必要になるため、VUMでやるメリットはあまりなく、手動で実施してます。 ■弊社のVUM構成 ■VUMで実施するタスク ベースライン管理 ベースラインのアタッチ スキャン ステージ 適用 下記では、弊社のベースライン管理について解説します。 ■ベースライン管理 ベースライン管理をする目的 弊社で検証したパッチだけをESXiに適用する クラスタ内のESXiのパッチレベルを合わせる（後から足したESXiのパッチレベルが高くなって、異なるパッチレベルのESXiが混在した状態でDRS運用は望ましくないため） ベースライン管理の流れ ダウンロードされたパッチの中からESXへ適用したいパッチリストを定義 例えば、VMSA-2019-0020に対応した2019/11/12までにリリースされたパッチは適用したいけど、VMSA-2019-0022に対応した2019/12/05のリリースされたパッチはまだ適用したくない等 そのリストを、 baseline_20191112 という名前で作成 ベースラインの作成単位 vCenter毎にVUMが存在し、各々ベースライン管理 vSphereバージョン（基本ベースライン） ESXiの機種（オプション） セキュリティパッチ適用する/しない（オプション） 性能影響するCPU脆弱性対応等でバリエーションが発生 オプション扱いではなく、基本ベースラインに取り込む場合もある ベースラインのアタッチは フォルダ に実施 H社のフォルダにメンテナンスモードにしたESXiをドラッグ＆ドロップで移動してくると、上位の基本ベースラインと、H社にアタッチしたベースラインの両方が適用範囲になります。 フォルダにベースラインをアタッチするメリットとしては、アタッチするのは1か所のみで良いという点でしょうか。 クラスタ毎にアタッチすると、クラスタの数分アタッチが必要です。クラスタによってはアタッチするベースラインが異なったりと、管理も煩雑になります。 その代わり、VUMの標準機能で自動でローリングアップデート（要DRS）の機能は使えません。 ■ESXiへのパッチ適用 手作業でどのフォルダへESXiを移動させるか判断するとミスが起こる可能性がある 弊社で作成したパッチ適用スクリプトにて、ESXiのベンダ情報等を確認して移動先フォルダを自動選択する仕組みにしている ■まとめ VMUGのほかの登壇者からの情報で、VUMでパッチのコンフリクトが発生した場合の対処についてお話がありました。 こういったノウハウを v民間療法 と呼んでいたのは面白かったです。 弊社では、ほとんどコンフリクトは起きたことが無いのですが、よくよく考えてみると、今までesxcli等のCLIでパッチ適用してきたESXiを後からVUMでベースライン管理しようとしたからではないかなと、思いました。 弊社では、vSphereのインストール直後にベースラインのパッチ適用をVUMで実施します。最初からVUMでパッチ適用していれば、パッチのコンフリクトが発生する危険性は非常に少ないように思いました。 ただ、パッチを当てていくにつれ、そういった状況に陥る可能性もあります。 その場合は、弊社にも下記のような v民間療法 があります。 そのESXiを一旦運用から外す vSphereを再インストール 最新のベースラインまで一気にパッチ適用する ■おまけ 夜の部では一足早くクリスマスパーティーをしました。 会場提供してくれたNetAppさんが用意してくれたケーキ。とてもおいしかったです。 スポンサー企業が用意してくれた乾杯のシャンパン系 某MADなvEXPERTさんｗの手料理 クイズ大会でゲットしたウナギ。名古屋ので 焼き らしい。後日届くとのこと。 地元静岡は 蒸し なので、食感が楽しみです。 各自1000円程度でプレゼントを持ち寄り、（ほぼオジさん同士でｗ）プレゼント交換などもしました。 ■お知らせ VMwareユーザ会（VMUG）に興味のある方は、 https://www.vmug.com/membership/membership-benefits をご覧いただいて、もしよろしければ入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。 以上です。

BIGLOBE鈴木(研)です。今日は、ちょっと前の話ですが、10/11にVMUGの部会がありましたので、共有させていただきます。 JAPAN VMUG OCTOBER MEETING 2019 https://community.vmug.com/events/event-description?CalendarEventKey=64889cef-3756-4672-8085-c5283b225ec3 community.vmug.com 台風19号が近づいていたものの、何と30人くらい集まりました。 ■テーマ 事前に与えられたテーマはこんな感じでした。 　御用達ツールの紹介，ツール自慢，ツールに関するお悩み相談． 　加えてアップデートに関する経験や情報も募集します！ BIGLOBEからは、VMware基盤の管理に役立つ3つのツールを紹介しました。 ■BIGLOBEからのツール紹介 PowerShell Server https://www.nsoftware.com/powershell/server/ 弊社のインフラの管理サーバはLinuxベース Windows版vCenterがあったので、PowerShell Serverを使ってインフラの管理サーバと連携させて、VMware基盤を管理 主な仕事は、 ESXホスト構築時の、パッチ適用のps1の呼び出し 全vCenterのロール/権限設定のバックアップ 近々で、Windows版vCenterが全部廃止になる予定なので、Linux版PowerCLIに移行予定 vRealize Orchestrator https://www.vmware.com/jp/products/vrealize-orchestrator.html vSphere新バージョン検証時の性能試験の自動化 テスト環境の自動セットアップ テストのワークフロー化 結果ファイルへの出力 下記、ワークフロー作成画面の抜粋です。 下記、作成したワークフローのウィザード画面（一部抜粋）になります。 ※ストブイ：弊社でのStorage vMotionの略称   性能試験としては、平常時だけでなく、スナップショットを作成した状態/削除中の状態、vMotion/ストブイ/クロスホストvMotion中も計測しています。 WinMerge https://winmerge.org/?lang=ja 作業手順書の差分チェックの機械化 目視は信じない！ 手順書改版時の、前回Verとの差分チェック 作業対象機器の差分チェック 作業ミスや手順書の修正ミス、作業対象機器の間違え等を未然に防ぐため、WinMergeを使用しています。 ■Intelさんからの発表 Optane紹介 Optaneというパーシステントメモリ/SSDの紹介がありました。メモリとSSDの間に、Optaneシリーズが入ってきてます（下図の黄色とオレンジの部分）。   Optaneパーシステントメモリのモード Optaneパーシステントメモリには2つのモードがあるそうです。   Intel VMDとは 従来のNVMeはデバイスのホットプラグが出来なくなっていたそうですが、Skylake以降のCPUではVMDというものが実装されていて、ホットプラグが出来るようになったとのことです。   NSX-TとDPDK NSX-TとDPDK対応のNICを組み合わせれば、パフォーマンスがアップするとのことでした。ただし、DPDKの処理オーバヘッドで1コアは持って行かれるそうです。NSX-Vのサポート期限もだんだん見えてきているので、将来的にNSX-V → NSX-Tにバージョンアップする時には、DPDKとの組み合わせを検討するのも良さそうに思いました。   Optane SSDと3D NAND Optane SSDと3D NANDの違いについても説明があり、理解が深まりました。どちらかが良いというわけではなく、うまく使い分けていく必要があります。 Optane 3D NAND left-aligned column left-aligned column left-aligned column ブロックの変更 可能（ガーベージコレクション不要） 不可（空き領域に追記、開放した領域は後でガーベージコレクションで回収） メモリセル構造 積層（大容量化を実現） 単層 利用シーン 高パフォーマンス向け 大容量向け ■感想 各社で使っている運用ツール、便利ツール、中にはデータセンターで使う物理的なツールを紹介する方もいらっしゃいました。色々な人が集まると、予想していない角度からの話を聞けるので、いろいろ刺激的で興味深かったです。 また、Intel/VMware社からの発表でOpteneの紹介をいただき、今後Optaneをどのように活用していくのが良いのか理解が出来ました。OptaneをvSANのR/Wキャッシュにすることで性能アップが期待できるとのことです。 以上です。

BIGLOBE 鈴木 研一です。初投稿です。 まずは自己紹介させていただきます。 氏名 鈴木 研一（すずき けんいち） 所属部署 基盤本部 クラウド技術部 業務内容 BIGLOBEの仮想基盤、LinuxOSの標準化、運用保守 私、今年の3月に vEXPERT 2019 になることができました。と言っても、もうすぐ1年たつのでvEXPERT 2020の申請をしているところです（1年ごと査定を受けて更新が必要）。パスすれば、★2つになります。 vEXPERTはVMware製品の技術をCertifyするものではなく、VMwareユーザ会（VMUG）のコミュニティ活動や、VMwareユーザに対しての情報共有等による貢献を認めていただいたものになります。vEXPERTの人数は、ワールドワイドで2000名未満、日本では100人未満とのことです（2019年3月現在）。 BIGLOBEのサービス基盤では、VMware 製品を活用して高い可用性を実現しています。その中でVMware製品をどんな感じで使っているかのTipsを、皆さんにお伝えすることで、皆様のお役に少しでも立てればと考えております。 BIGLOBEはコミュニティを大切にしている会社です。私が普段の業務の中で行っていくコミュニティへの貢献については、このブログでお伝えしていきますのでご期待ください。また、私の記事を読んでいただいてBIGLOBEに興味を持っていただけると幸いです。 今回は、取り急ぎのご挨拶まで。 以上です。

この度、BIGLOBEでテックブログを始めることになりました。 初回ということもありBIGLOBEについて紹介させてください。 www.biglobe.co.jp 当社は、インターネット等のネットワークを利用した情報サービスの提供、およびこれに付帯または関連する一切の業務を行っています。  ・どこでも快適・安全につながる”インターネット接続サービス” 　光接続サービスやモバイル接続サービスを提供しています。 ・インターネットをもっと楽しむサービス／アプリ 　パソコン向け、スマートフォンサービス向けとして最新ニュース、旅行情報、 　ビューティー情報、各種セキュリティサービスなど、生活に役立つ様々なサービスを提供しています。 ・プロバイダとして30年以上の経験をもとに法人のお客様へサービスを提供しています。   www.biglobe.co.jp 意外にもあまり知られていないですが、2017年1月からKDDIグループです。  結構、自社開発しています。 テックブログを始めたきっかけ  BIGLOBEではこんなことを悩んでいます。 ・新しい開発手法を取り込みたい ・クラウドのさまざまな新機能を取り込みたい ・一緒に働いていただける仲間を見つけたい 特にBIGLOBEでは古い資産を見直して全面的に新しいものに置き換えていくことを社内一丸となって進めています。 AWS等のクラウド利用も意欲旺盛なエンジニアを中心に進めています。 このTechBlogでは、BIGLOBEで取り組んでいることや苦労していること、悩んでいること、普段の社内風土や環境を現場エンジニアを中心にみなさまへ情報発信をしていきたいと思っています。 ・BIGLOBEって何開発しているの？ ・格安SIMの会社だよね？ ・昔インターネットプロバイダで有名だったけどいま何しているの？ ・びっぷるって何者？ www.biglobe.ne.jp 社内は常に和気あいあいしてまして、定期的にeスポーツ大会や社長を交えた交流会なども行なっています。 そんな日常生活もこのTechBlogでご紹介できれば嬉しいなと思っています。 今後ともよろしくお願いいたします。 ビッグローブ株式会社　基盤本部　堀内晋也