いろいろな種類がある .NET の違いとは

はじめに

こんにちは Synamonでエンジニアをしている庭山です。

Unityでの開発では主に.NET（ドットネット）という環境下、C#というプログラミング言語を使用しています。

また、次世代の .NET 6 というバージョンが近く正式リリース予定(2021年11月)となっています。

そんな .NET ですが、色々とWebを検索や記事を読んでいると

• .NET
• .NET Framework
• .NET Core
• .NET 5
• .NET Standard

.NET ●●●という色々な種類があったり

• Mono
• Xamarin

.NET という単語すら含んでいなかったりで、初見だと正直「わからん...」な状況になりませんか？

私も実務でUnityを触リ始めるタイミングで本格的に C#を触り始めて、あまり気にしていなかったのですが、改めて調べ整理してみました。

TL;DR

• .NET ●●● はランタイムの名称
• コンパイル済みコードを複数のプラットフォーム（OSやランタイム）で動作させるためには .NET Standard をターゲットにライブラリを作成する

App Models

• .NET 4.x
  • .NET Framework 4.x
  • Windows 向けランタイム
• .NET Core 3.x
  • Windows以外のOS（LinuxやmacOS）でも互換のあるプログラムを動かすことを目的としたランタイム
• .NET 5
  • .NET Core 3 の後継（4はスキップされた）
• .NET 6
  • .NET 5 の後継で 2021年11月頃リリース予定
• Mono
  • Windows以外のOSで.NET Framework の動作互換を目的として作られたオープンソフトウェア
• Xamarin
  • Android、iOSを含んだクロスプラットフォームフレームワーク

.NET Standard Library

• .NET Standard 1.x / 2.x など
  • ランタイム間で互換のある基本API群（BCL、Base Class Library）
  • クラスライブラリ作成などでターゲットを .NET Standard にすることで、実行コードレベルで .NET Standardをベースに作られているランタイム上で互換がある
  • 使用可能なAPIはSystem名前空間以下など限られたクラス群のみ

.NET

一般に.NETという場合、.NET全体の環境を指す。（Wikipedia より引用）

なるほど…。

詳細

色々な種類のランタイムが存在していますが、アーキテクチャを読み解くとその理由も徐々に分かってきました。

（引用元：Introducing .NET Standard - .NET Blog）

技術レイヤーが別れていて、下にあるものほど土台や基礎を担っているレイヤー（Infrastructure）、上に行くほど応用(Application）になっていることが分かります。

それでは、下のレイヤーから見てみようと思います。

Common Infrastructure

基礎となる言語仕様やそのコンパイラ、ランタイム実装に必要なコンポーネント群です。C#言語仕様やC#コンパイラはここに位置する形になります。

.NET Standard Library

Unity の ビルド設定を編集する Player Settings でも選択できる「あれ」です。

Unityでは

• .NET 4.x (.NET Framework 4.xに相当)
• .NET Standard

と選ぶことができます。

C#や、Unityを触り始めて日が浅かったりしますと バージョンの数値が大きいほうがなんとなく最新っぽく見える 雰囲気が出てますよね。（実は私は最初そうだと思っていました…）

調べてみると、概ね以下のような存在のようです。

.NET Standard

• ランタイム実装のための基幹ライブラリ（BCL・Base Class Libraryと呼ばれている）
• クラスライブラリ作成時にターゲットを .NET Standard にすることで .NET Coreや.NET5、Xamarinなどのランタイム各種での動作互換があり、再利用が可能
• ただし、使用可能なAPIはSystem名前空間以下など限られたクラスのみ

.NET Standard から見た場合の互換性を見ると下図のようになります。

例えば

• .NET Standard をターゲットにビルドされたクラスライブラリは .NET Standard をベースに持つ各実行環境において参照できる
• .NET Standard をターゲットにビルドできるのはクラスライブラリであり、実行可能なアプリケーションは作成できない
  • .NET Standard は実行環境ではなく、クラスライブラリ群であるため

のようなことが挙げられます。

逆に、下図のようにランタイム間では互換がありません。

よって

• .NET Framework をターゲットにビルドされた実行プログラムは .NET Core のランタイムでは動作しない
• .NET Framework をターゲットにビルドされたクラスライブラリは .NET Core をターゲットにしているプログラムから参照できない

のようなことが挙げられます。

そして

.NET Standard をターゲットにビルドされたクラスライブラリは .NET Standard をベースに持つ各実行環境において参照できる

を満たすことができれば、ランタイムを問わず様々な環境でビルド済みのコードを動作させることが可能になることになります。

.NET Standard バージョン

とは言っても、.NET Standard にもバージョンが存在します。

主な違いは

• サポートするクラスライブラリのクラス数
• サポートする C# の言語バージョン

で、バージョンが上がる毎にサポートする範囲が広くなっています。

結局はランタイムがどのバージョンをベースに実装されているかにも注目が必要ですが、複数のランタイムを前提としている場合は各ランタイムで採用している .NET Standard のバージョンに合わせる形になります。

App Models

基幹レイヤー Common Infrastructure・ .NET Standard を用いたランタイムの実装が行われているレイヤー

アプリケーション開発者がどの環境下で実行可能なのかを決定し、プログラミング・ビルドを行うことで実行可能アプリケーションを作成していくことになります。

Windows の Visual Studio の新規プロジェクト作成ウィザードでコンソールアプリケーションに絞り込んだ場合、このように複数の候補が出てきます。

この場合の選択肢は

• .NET Core
• .NET Framework

となります。

逆に Mac の Visual Studio の新規プロジェクト作成ウィザードでコンソールアプリケーションに絞り込んだ場合、選択可能な候補は１つだけでした。

この場合の選択肢は

• .NET Core

となります。（.NET Framework はWindows向けランタイムなので選択できない）

主なランタイム

もう少しランタイムの種類について整理してみたところ、以下のようなランタイムがあることが分かりました。

• .NET Framework 4.x
  • Windows 向けランタイム。Windowsに特化したAPIも持っている
  • 他のOSでは互換がない
• .NET Core 3.x
  • Windows以外のOS（LinuxやmacOS）でも互換のあるプログラムを動かすことを目的としたランタイム
• .NET 5
  • .NET Framework 4.xの後継ではなく、.NET Core 3 の後継（4はスキップされた）
• .NET 6
  • .NET 5 の後継で 2021年11月頃リリース予定。
  • .NET Frameworkは4.8で最終バージョンとなり、今後の流れは .NET 6, .NET 7, .NET 8 ... となっていく予定
  • Xamrin や WPF から 徐々にMAUI へ
• Mono
  • Windows以外のOSで.NET Framework の動作互換を目的として作られたオープンソフトウェア（.NET Frameworkのすべてをサポートしているわけではない）
  • Unity のC#スクリプト部分は Mono をベースに作られている
• Xamarin
  • Windows、macOSに加え Android、iOSを含んだクロスプラットフォームフレームワーク

さいごに

.NET というワード１つ掘り下げるだけでもそれなりの情報に辿り着くことができましたが、基幹部分を知ることで見える範囲が広がり色々な応用（.NET以外でも）に繋げられる部分でもあるのでこういうことも大事かな、と思っています。

（＊昔ではありますが業務で Java を深掘っていた時期があったので、このあたりの仕組みは似ているかもれないな、と思いました）

Goで作ったAPIでGithub Actionsを使ってAPIを直接叩くテストを回す

ごあいさつ

エンジニアのうぃすきー(@Whisky_shusuky)と申します。弊社ではインフラ・バックエンド・フロントエンドとWeb周りを全般的に対応しております。

最近Goをよく使っているため、以前公開したGinで作ったサンプルAPIにGithub Actionsの設定を追加してCIでtestが回るようにしてみましたのでこの場を借りて紹介しようと思います。

github.com

またサンプルAPIの中身については以前Qiitaに記載しましたので必要でしたらご確認ください。

qiita.com

テストの紹介

元々Railsを扱う機会が多かったので、Railsでのrequest specと同様にして実際にapiにアクセスしてレスポンス内容を検証するテストを実行することでAPIの動作を保証したいと思いました。 testfixturesを使えばテスト用DBにテストデータを以下のようにしてyaml形式で定義できます。

- id: 1
  shop_name: "test shop name"
  shop_description: "test shop description"

https://github.com/whisky-shusuky/gin-gorm-rails-like-sample-api/blob/master/test/testdata/fixtures/shops.yml

このデータを以下のようにして実際にAPIにアクセスして取得するテストを書きました

   t.Run("returns 200 when GET /", func(t *testing.T) {
        req, _ := http.NewRequest("GET", testServer.URL+"/api/v1/shops", nil)
        res, _ := client.Do(req)
        body, err := ioutil.ReadAll(res.Body)
        if err != nil {
            t.Error("[Error]", body, err)
        }

        assert.Equal(t, http.StatusOK, res.StatusCode)
        expectedBody := `{"shops":[{"id":1,"shop_name":"test shop name","shop_description":"test shop description"}]}`
        assert.JSONEq(t, expectedBody, string(body))
    })

https://github.com/whisky-shusuky/gin-gorm-rails-like-sample-api/blob/master/test/shop_request_test.go

Github Actions でテストを回す

上記のテストをgithub actionsで回るように設定しました。

name: test
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]
jobs:
  golangci:
    services:
      mysql:
        image: mysql:5.7
        ports:
          - 3306:3306
        env:
          MYSQL_ALLOW_EMPTY_PASSWORD: yes
          BIND-ADDRESS: 0.0.0.0
        options: --health-cmd "mysqladmin ping -h localhost" --health-interval 20s --health-timeout 10s --health-retries 10
    strategy:
      matrix:
        go-version: [1.16.x]
        os: [ubuntu-latest]
    name: test
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - name: testing
        run: ENV_GO=citest bash -c 'go test ./... -v'

https://github.com/whisky-shusuky/gin-gorm-rails-like-sample-api/blob/master/.github/workflows/master.yml

ここではservicesのmysqlをデータベースとして使用しております。ローカルではdocker-composeで別途立てたコンテナを使用しているため接続方法が異なってきます。 そこでrun: ENV_GO=citest bash -c 'go test ./... -v'の形式で渡した環境変数ENV_GOを使って環境に応じて接続方法が変わるようにして対応しました。若干ハードコード気味ですがそれは置いておいて、こんな感じで環境変数に応じて動作を切り替えることが可能です。

       if env == "citest" {
            datasource = "root@tcp(127.0.0.1:3306)/"
            dsn = "root@tcp(127.0.0.1:3306)/sampletest?parseTime=true"
        } else {
            datasource = "root@tcp(db)/"
            dsn = "root@tcp(db)/sampletest?parseTime=true"
        }

これでPRをmaster向けに作るとGIthub Actionsが走ります

むすび

Railsを元々書いていてGoを書き始めた方はrequest specを書きたくなると思います。そのような方の参考になりましたら幸いです。実際にAPIを叩くテストを書いたことが無い方も、APIの動作を担保するという意味では有効だと思いますので試してみるのはいかがでしょうか。

テックブログ運営を回すための取り組み 〜再始動編〜

続かないテックブログ

エンジニアリングマネージャーの佐藤（@unsoluble_sugar）です！

「テックブログ（技術ブログ）は続かない」という話は、エンジニア界隈で定期的に話題になりますよね（唐突

なんとなく技術広報面で有益である認識はあるものの「運用がうまく回らない」という企業は多いのではないでしょうか。

• 6年半のテックブログ運用を振り返って気づいたメリットと長く続けるコツ - ZOZO TECH BLOG
• 2020年エンジニア採用活動ふりかえり-採用広報編 - Tbpgr Blog
• テックブログは続かない - 何サイトか潰した後にブログが有名な企業に転職しての気づきと反省｜久松剛／IT百物語の蒐集家｜note
• テックブログを続ける試行錯誤―5年目の平日毎日更新テックブログ運営者の視点から｜TechRacho by BPS株式会社
• CTOがテックブログなんとかしてって言って一ヶ月が過ぎました - SmartHR Tech Blog
• ZOZOのテックカンパニーへの変遷、CTOとしての取り組みを振り返る｜kyuns /キュン 今村雅幸｜note
• テックブログ運用担当者がテックブログのリアルを語る『Tech Blog Night』イベントレポート - SMARTCAMP Engineer Blog

弊社Synamonのテックブログも例外ではありませんでした。

2020年以前は、年に5記事前後。2021年に至っては、5月にようやく1記事投稿という状況。

XR（VR/AR/MR）という市場づくりを担っている企業の一員として「さすがこれはまずいのでは…」という危機感を覚え、私が入社した2021年7月以後、テックブログ運営の立て直しを試みることにしました。

何はともあれ現状ヒアリング

まずは社内のエンジニアメンバーにヒアリングをし、現状の理解とこれまでの取り組みについて整理してみました。

Synamonのテックブログは2018年に発足。大枠の目的やガイドライン等の資料は残されているものの、現在在籍しているメンバーで詳細を把握しているのはごく数名。運営に積極的なメンバーも限られ、存在意義の共通認識も薄れているという状況でした。入社時のオンボーディングで伝え漏れていたりと、誰が担当しているのか不明瞭で聞くに聞けない状況も発生していたようです。

見えてきた問題

テックブログに関するヒアリングやブレストの結果、大きな問題のくくりとして以下のようなものが見えてきました。

• 書く人がいない
  • 書く目的がわからない
  • 書く人が限られている
  • 書くのが面倒
• 更新が続かない
  • 継続性のある運営施策が立てられていない

本記事では「書く人がいない」問題に対し、具体的にどのような取り組みを行なったかについて書かせていただきます。

テックブログを書く目的の明確化

大前提として「テックブログを書く目的がわからない」というメンバーも見受けられたため、改めてテックブログを書くことで得られるメリットを言語化・可視化することにしました。

企業の性質によっても観点は異なるかと思いますが、主なメリットとしては以下のような要素が挙げられました。

• 外部のエンジニアに対する認知向上
  • どんな技術を扱っているか
  • どんなエンジニアが居るか
  • 組織やチームにおけるカルチャーの発信
• 採用面で有用
  • 採用候補者がテックブログを見てくれる
  • 直接的な効果があるとは言い難いが、継続できれば中長期でストック型コンテンツとなる
• エンジニア個人のブランディング
  • Synamonの○○さん
  • あの記事を書いていた○○さん
  • あの技術領域に詳しい○○さん
• アウトプット能力の向上
  • それなりに調べて、情報を整理する必要がある
  • 外向けに正しく伝えようとする書き方が鍛えられる
  • 数をこなせば書くハードルが下がる
  • 他媒体でも書けるようになる
• 普段つくっているものに価値があるということの再認識
  • 外からフィードバックを得られる機会が増える
  • 場合によっては検索でヒットして会社やプロダクトの露出も増える
  • 誰かの役に立つという実感を持てる

個人的には「情報は発信する人のところに集まる」という認識があったので、テックブログをやらない理由はないと思っていました。しかしながら、改めてその理由を言語化して共通認識を深めることで、これまでテックブログに懐疑的だったメンバーも協力的な姿勢になってくれる比率が増えた印象です。

技術ブランディングという面では、まだまだコンテンツが足りず方向性が定めきれていない部分もあるため、今後徐々に詰めていければと考えています。

特に弊社Synamonは、XR界隈においてはそれなりに名は知られているものの、テック企業としての知名度は皆無な認識です。エンジニアへの認知獲得という点においては、テックブログは最も重視されるべきコンテンツだと言えるでしょう。

目標のフォーカスを絞る

続いてテックブログの具体的な運営施策のお話です。まずは「書く人を増やす」「書くハードルを下げる」という点にフォーカスし、継続できる体制の土台構築をすることを目指しました。

ロードマップを引いて計画的に進行していくのが理想的ではあるものの、運営に割けるリソースも限られています。施策についても選択と集中をすることで、足元を固めつつ前進し、小さな改善サイクルを回しながら方向性を見定めていくスタイルが妥当だと判断しました。

書く人を増やす

これまでも「テックブログを書いていた」「書けそう」「書いてみたい」というエンジニアが数名居たため、特に意欲の高いメンバーを集め、運営チームを発足することとしました。熱量のある人たちを集めるというのは、困難な状況を打破するための通過儀礼みたいなものです。

編集長を置くという方針も考えられましたが「少しでも多くのメンバーに当事者意識を持ってもらいたい」という思いや、継続性の担保を重視し、今回はチームでの体制づくりを選択しました。

専任の担当を立てたとしても、その人が忙しいとどうしても続かなかったり、ひとりでは本人のモチベーション維持が難しいといった問題はよく起きます。また、チームや部署をまたいだ体制の方が、より多くのメンバーを巻き込めるだろうという算段もありました。

実際に運営チームとして動くことにより、少しずつ書いてくれる人が増えてきました。各プロジェクトで得られた知見についても「テックブログで発信できそうかも？」といった対話の機会が生まれ、テックブログという媒体を介し、エンジニア同士の情報交換が活発になるという副作用も得られています。

有志メンバーで開催しているPMBOK勉強会が継続できているのも、テックブログの存在が支えとなっている気がします。ただ社内で完結するだけでなく「学んだ内容をテックブログに書けると良さそう！」という相乗効果があるからこそ、お互い両立できているのかもしれません。 synamon.hatenablog.com

「会社として技術力を前面に出していくのか」「業務の一環とするか否か」といった観点も、書く人を増やすための重要なポイントになりそうですね。

書くハードルを下げる

Synamonではそもそも「記事を書く人が少ない」という大きな課題がありました。理由は多々ありますが、とにかく記事を書く上で懸念となっている障害をひとつずつ取り除いていくことが大切です。

そのため、記事執筆＆公開までのハードルを極力下げる方向で運用検討を進めました。

• まずは運営チームが率先して記事を出すことで雰囲気を掴んでもらう
• 記事公開までのフローを最小限にとどめる
• 記事ネタについて相談する場を設ける
• 簡易的なレビュー体制を整える

運営チーム発足後の実施開始から、まだ2ヶ月程度ではありますが、現時点でひと月に4記事出せている状況です。

これは運営チームで掲げた当面の目標として「最低でも週に一度は記事を出せる体制づくりを行う」というものがあり、その目標に向かって各自が動いてくれている結果だと思います。

俺たちの戦いはこれからだ…！

走り出しが好調な一方で、今Qは個人目標にテックブログを書くことを設定したメンバーが多かったり、Synamonのnoteや公式Twitterでの情報発信の活性化も相まって、運営再始動のタイミングでブーストがかかったような印象もあります。

一過性で終わらせることなく、今後も継続のサイクルを回せるようにするための施策は、引き続き検討していく必要がありそうです。継続性のある運営施策として、記事管理シートや運営定例MTGの実施なども行なっているところですが…

少し長くなってしまったので、今回のお話はここまでとしておきます。

追記：続編書きました！

synamon.hatenablog.com

最後に

本テックブログやnote記事のお知らせは、Synamon公式Twitterで発信しています。 弊社の取り組みに興味を持っていただけましたら、ぜひフォローお願いします！

twitter.com

Meetyで僕とフランクにお話をすることもできますので、テックブログ運営に関する話やエンジニアキャリアに関する相談、おすすめ本について情報交換をしたい方は、お気軽にお声がけください😊 meety.net

それでは、また次回お楽しみに！

Photon Cloudでサーバーにカスタムロジックを載せずに使えるユーザー認証機能を触ってみた

Unityエンジニアの岡村です。

Unityでのアプリ開発において、リアルタイム通信の実装にはExitGames社のPhoton Realtime及び、Photon RealtimeをUnity向けのAPIでラップしたPhoton Unity Networking（PUN）が広く使われています。Photon Realtime及びPUNはサーバーの存在を前提とした通信エンジンで、Photon ServerもしくはPhoton Cloudを選択する事が出来ます。小規模なスマホアプリやゲームでは、アプリ開発者側がリアルタイムサーバーを用意する必要のないPhoton Cloudが人気です。

一方で、Photon CloudはEnterpriseプランでない限りサーバー上にアプリ固有の処理を載せることが出来ない為、カスタマイズ性に関してはPhoton Serverに劣ります。カスタマイズが出来ないことは、セキュリティ対策の観点において大きな懸念事項となります。そこで、今回はPhoton CloudのEnterpriseプランを契約しない範囲ではどの程度セキュリティ対策が出来るのかを調べ、触ってみた記録を紹介します。

Photon Cloudの認証機能

Photon Cloudはデフォルトで認証機能を持っており、以下を認証プロバイダーとして利用することが出来ます：

• Steam
• Facebook
• VIVEPORT
• Oculus
• カスタム認証

どの認証方法でも、認証に成功した時のみPhotonサーバーに接続することが出来るという挙動になります。

また、認証に成功した場合、プロバイダはユーザーIDやニックネームなどの追加情報をクライアントに返すことが出来ます。

簡単なカスタム認証サーバーを用意してテストする

こちらの公式ドキュメントによると、Jsonを返すWebサーバーがあればカスタム認証が実装できそうです。 doc.photonengine.com

という事で、node.jsとngrokを利用してローカルPC上に簡単な認証サーバーを立てて挙動を試してみました。

フォルダの作成、依存ライブラリのインストール

任意のフォルダを作成してnpm initで初期化した後、そのフォルダ内でnpm install expressを実行し、expressをインストールします。

サーバーコードの記述

次のコードをserver.jsとして、作成したフォルダ内に保存します。

var express = require('express');
var app = express();

app.get('/auth', function (req, res) {
    console.log(JSON.stringify(req.url));
    console.log(JSON.stringify(req.headers));

    // 必要なパラメーターが渡されているか確認
    if (!('userId' in req.query && 'password' in req.query)) {
        res.json({ ResultCode: 3, Message: "[AuthServer]Missing Parameters" });
        return;
    }

    let userId = req.query.userId;
    let password = req.query.password;

    // 渡されたパラメーターが正しいか確認
    if (!(userId === 'user01' && password === 'password')) {
        res.json({ ResultCode: 2, Message: "[AuthServer]Invalid UserID or Password" });
        return;
    }

    // 認証成功
    res.json({ ResultCode: 1, UserID: userId, Message: "[AuthServer]Authenticated" });
});

app.listen(3000);
console.log("server listening ...");

サーバーの実行

フォルダ内でnode serverを実行する事で、先ほど作成したserver.jsが読み込まれてサーバーが起動します。

サーバーの公開

ngrok http 3000を実行する事でローカルの3000番ポートがhttpサーバーとしてインターネットに公開されます。

3000番という値はserver.js内で指定している値ですので、そのポートが使用中の場合はserver.js内の記述と共に変更してください。 また、ngrokで生成されるURLはフリープランの場合、起動するたびに毎回ランダムな値に変化する為注意して下さい。

Photon Cloudの設定

Photon Cloudのコンソール上で、カスタム認証サーバーを設定します。

認証URLは先ほど起動したngrokで生成されたものを指定します。また、クライアントがいない場合、全てのクライアントを拒否する設定のチェックを入れておきます。（訳がおかしいですが、これは認証サーバーが応答していない場合、全てのクライアントの接続を拒否する設定の様です。）

今回はテストなので、認証処理が走っていることを分かりやすくするために、匿名クライアントの接続を許可する設定のチェックを外します。

クライアント側認証処理の記述

クライアント側の接続を行う前の箇所に、以下の処理を追記します。

AuthenticationValues authValues = new AuthenticationValues();
authValues.AuthType = CustomAuthenticationType.Custom;
// サーバー側ロジックで要求しているものと同じuserIdとpasswordをパラメータとして設定する
authValues.AddAuthParameter("userId", "user01");
authValues.AddAuthParameter("password", "password");
 
loadBalancingClient.AuthValues = authValues; // Photon Realtimeの場合
PhotonNetwork.AuthValues = authValues; // PUNの場合

// この先に接続処理を書く

挙動確認

まず、認証パラメータを渡さないクライアントで接続してみます。

次に、パラメータは渡すが値が誤っているクライアントで接続してみます。

最後に、パラメータとその値が正しいクライアントで接続してみます。

エラーが出ておらず、接続に成功しました。

ちなみに、クライアント及びクラウドコンソールで指定したパラメータは以下のようにURLクエリパラメータとして渡されます。

以上

上記のコードや構成はテスト用に書いたものなのでかなり雑です。少なくとも本番利用する際にはIDパスワードを直接渡すのではなく、他のルートで発行して貰った一時的なコードを渡す等の対応をした方が良さそうです。しかし、今回node.jsやngrokを利用する事で、とても簡単に認証の流れをテストできて面白さを感じたため載せてみました。

という事で、本格的にオンラインを活用するゲームであればゲームサーバーは必須ですが、Photon Cloudでも最低限の認証機構が搭載出来る！というご紹介でした。

宣伝

Synamonは、Unity / C#エンジニア、テックリードを中心に新しい仲間を募集中です。 「XRが当たり前の世界をつくる」というミッションに共感したメンバーが、切磋琢磨しながら日々挑戦しています！カジュアル面談も実施中なので、ご興味ある方、お気軽にご連絡ください。

カジュアル面談はこちらから meety.net

エントリーはこちらから herp.careers

また、本テックブログやnote記事のお知らせは、Synamon公式Twitterでも発信もしています。 弊社の取り組みに興味を持っていただけたら、ぜひフォローをお願い致します！
twitter.com

PMBOK 7th 勉強会 第2回 【Section2: 価値提供のためのシステム】開催しました

PMBOK 7th 勉強会 第2回 開催しました

エンジニアの松原です。先日社内でPMBOK 7th 勉強会の第2回目が開催されました。開催の経緯などは以下の記事を読んでいただけると分かりやすいかと思います。

synamon.hatenablog.com

また、前回の記事は以下になります。

synamon.hatenablog.com

今回も第2回の勉強会で行った内容についてとその振り返りについて記事に書き起こしました。今回はThe Standard for Project ManagementのSection2から読み進めた内容になります。

PMBOKとは

PMBOK（Project Management Body of Knowledge）とは、PMI（Project Management Institute）がプロジェクトマネジメントに関するノウハウや手法を体系化してまとめた本です。

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management (ENGLISH) (English Edition)

1996年の初版出版以来、4年に1度くらいの頻度で改訂が繰り返されており、2021年8月に第7版が出版されましたが、まだ日本語訳された本が無いので、勉強会では英語版を参加者各自が日本語に翻訳して読み進めています。

Section2: 価値提供のためのシステム

The Standard for Project Management(以下ではPMBOKと略します) のSection2では前回の勉強会でも項目に登場した『価値提供のためのシステム』について、またそれがガバナンスやプロジェクト、機能、プロジェクトの環境、またはプロジェクトマネジメントとどう関わるのか、そして組織にとって何が価値になるかを説明しているセクションになります。

サブセクションでは以下のように分かれており、それぞれの目線からの組織の価値に関する要素を説明しています。

2.1 価値の創造

組織における価値の創造について説明しています。組織はステークホルダーに向けて価値を生み出しており、価値の例として以下のようなものがあります。

• 新しいプロタクトやサービスを作ることや、顧客またはエンドユーザーのニーズを見つけること
• 社会的または環境的な貢献を行うこと
• 効率、生産性、有効性や応答性の向上
• あるべき将来のための組織の変化を促す取り組み
• 既存のプログラムやプロジェクトから継続的な利益を生み出す

ポートフォリオやプログラム、プロジェクトや運用は上記の例に挙げた価値を生み出す要素となっており、組織戦略をもって価値を生み出すシステムとして成り立ちます。 これらの要素はアウトカムをもたらし、アウトカムは利益を生み出し、さらにその利益が金銭的な価値や重要性、有益性などの価値を生み出すと説明されています。

PMBOKではさらにこれらの要素がお互いにどう関わってくるか、影響し合うかについて掘り下げていますが、この記事では割愛させていただきます。

2.2 組織のガバナンスシステム

ガバナンスシステムは、価値提供のシステムと連携して機能し、スムーズなワークフローを可能にし、問題を管理し、意思決定をサポートします。またガバナンスシステムは監視、制御、価値評価、コンポーネント間の統合、および意思決定の機能などを備えています。

PMBOKではこのサブセクションに詳細項目が置かれておらず、特筆する図表を使った掘り下げもなかったので、ここでの組織のガバナンスとは一般的な組織体制として捉えています。

2.3 プロジェクトに関連した機能

プロジェクトを効果的かつ効率的に実行するために必要な要素があります。ここではその各要素を『機能』と呼んでおり、プロジェクトに関連する機能は、1人の人物、グループ、または定義された役割に組み合わせることができます。 このサブセクションでは各機能の説明を掘り下げています。記事にすると長くなってしまうので、下記に機能の項目のみピックアップしました。

• 監視と調整の提供
• 現在の目的とフィードバック
• ファシリテーションとサポート
• 作業遂行、見識への貢献
• 専門性の適用
• ビジネスの取締や見識の提供
• リソースと方向性の提供
• ガバナンスの維持

これらの項目は職務内容として表せるものがある一方、職務として表現できる範囲よりも広い内容を含むものもありました。

2.4 プロジェクトの環境

プロジェクトは、価値の提供にさまざまな程度の影響を与える内部環境と外部環境内に存在し、運用されています。これらの環境は、計画やその他のプロジェクト活動に影響を与える可能性があります。さらに環境はプロジェクトの特性、ステークホルダー、またはプロジェクトチームに良い影響、悪い影響、または中間的な影響を与える可能性があります。

内部環境について

内部環境は組織内部で、組織自体、ポートフォリオ、プログラム、別のプロジェクト、またはこれらの組み合わせから発生する可能性があります。成果物や取り組みやプロジェクトから学んだ内部知識を含んでいます。それらの分類についてピックアップしました。

• プロセス資産
• ガバナンスのドキュメント
• データ資産
• 知識資産
• セキュリティと安全対策
• 組織文化、ガバナンス構造
• 施設とリソースの地理的分布
• インフラストラクチャー
• 情報技術ソフトウェア
• リソース可用性
• 従業員の能力

PMBOKではこれらの項目について簡単な説明はありますが、深い掘り下げはなかったので、こちらも一般的な組織にあるものと同じかと考えています。

外部環境について

外部環境は組織内のプログラムやプロジェクトとは異なる外的な要因として紹介されていました。組織の外部の要因は、プロジェクトの結果を強化、制約、または中立的な影響を与える可能性があります。こちらも分類化されてましたのでピックアップしました。

• マーケットプレイスの状況
• 社会的および文化的影響または課題
• 規定環境
• 商用データベース
• 学術研究
• 業界標準
• 財務上の考慮事項
• 物理的環境

これらの項目についても簡単な説明のみでしたので、説明も一般的な内容で、特に目立った特徴はありませんでした。

2.5 製品管理に関する事項

ポートフォリオ、プログラム、プロジェクト、および製品管理の分野は、より相互に関連するようになっています。このサブセクションでは製品管理の分野について、また製品管理の分野がポートフォリオ、プログラム、プロジェクトにどう関わってくるかが書かれています。 製品管理には、人、データ、プロセス、およびビジネスシステムの統合が含まれ、製品のライフサイクルを通じて製品またはサービスを作成、維持、および開発します。

製品のライフサイクルのサンプルが図表で示されており、ポートフォリオのガバナンス、プログラム、プロジェクトがどのように製品のライフサイクル(導入期、成長期、成熟期、衰退期)と関連するかを表していました。

以下に製品管理の形態の例について挙げます。

製品ライフサイクルのプログラムマネジメント

関連するプロジェクト、補助プログラム、およびプログラム活動が組み込まれています。 非常に大規模または長期実行の製品の場合、1つ以上の製品ライフサイクルフェーズが十分に複雑であるため、一連のプログラムとプロジェクトを連携させる価値があります。

製品ライフサイクルのプロジェクト管理

継続的なビジネス活動としての製品機能の開発と成熟を監視します。 ポートフォリオガバナンスは、必要に応じて個々のプロジェクトをチャーターして、機能強化や改善を実行したり、他の独自の成果を生み出したりします。

プログラム内の製品管理

製品管理は製品のライフサイクルに組み込まれているプログラム内に適用されます。 製品の特定の利益を達成するために一連の補助的なプログラムまたはプロジェクトが実行されます。競合分析、顧客獲得、顧客支援を製品管理のコンピテンシー適用することでさらに利益をもたらします。 製品管理は独自の知識体系を持つ別個の分野ですが、プログラム管理およびプロジェクト管理分野内の重要な統合ポイントを表しています。

ここでいう製品管理は、明記はされていませんが、おそらく分析をもとにした一般的な製品のアップグレード、メンテナンスも含んでいるかと思います。

勉強会を実施してみて感じた課題

課題

• Section2までの翻訳に手を付けられていないメンバーが多かった
• 抽象度が高く、一般的な意味に対する紐づけが難しかった
• 前回よりは進行はスムーズに感じたが、やはり時間繰りが難しかった(Section2は文章量自体は少なかったが第2回の勉強会で収まりきらなかった

対策

• 議論時間を設けるため、本の内容を全部読み上げるのではなく、簡単に要約する程度にとどめる
• 翻訳の効率化など

勉強会を終えた後の振り返り

今回から中身が入った内容が含んでいましたが、同じ系統の本を読みなれていないと単語の直訳の意味に引っ張られやすい印象がありました。細かいところでメンバーごとに感じている意味も違っていたのが印象的でした。(OperationやFunctionが取りうる意味、ProgramとProjectの違いなど)

また、私は上記の『外部環境』は自分で翻訳した際にあまり良い意味が含まれていないように感じていましたが、参加メンバーと議論した結果、良い意味も含んでいたことが良い発見になりました。

手作業での翻訳は個人のニュアンスが含まれるため、議論で意味を擦り合わせるのはやはり必要であると感じました。

次回予定

次回はSection3についてレポートする予定です。

Varjo Unity XR SDKを使ってパススルーを試す

こんにちは！
Synamonでエンジニアをしている黒岩(@kro96_xr)です。

プレスリリースにもあります通り、SynamonではVarjo XR-3を導入してよりハイエンドなXRコンテンツの開発にチャレンジしております。

今回Unity向けSDKを触る機会がありましたのでSDK内のサンプルを動かすまでの手順を記事としてまとめておこうと思います。正確な情報が知りたい方は公式リファレンスも参照してくださいね。

なお、Varjo XR-3の紹介や体験記事については下記の記事にまとめられておりますのでよろしければご覧ください。

note.com

必要要件(2021/9/12時点)

• システム要件を満たしたPC
• Varjo Base3.0.0以上
  • インストールにユーザー登録が必要
• SteamVR
• Unity 2019.4.0f1以上(Built-in Render Pipelineの場合)
  • URPとHDRPの場合はUnity XR SDK Compatibilityを参照
• Unity Windows Build Support
• DirectX 11の使用
  • OpenGL, Vulkan, DX12は現時点で未対応
• Varjo Unity XR SDK Plugin
• Varjo XR-3 & VR-3 Ultraleap SDK for Unity
• Varjo XR-3
  • 無くてもVarjo Base内のシミュレータでテスト可能

大きいのはXR-3がなくてもVarjo Baseのシミュレータで簡易なテストは可能なことですね。私もリモートワーク中にシミュレータで実装をした後に出社して実機でテストというようなことをしています。
また、今回の記事で使用している私用PCのグラボはGTX1060です。実際にVarjoを動かすことはできないスペックですがシミュレータでサンプルを動かすくらいならできました。
機材費が高額となるため個人で実機を使用するのは難しいですがSDKを触ってみたいという方はぜひ試してみてください！

プロジェクトのセットアップ

SDKに同梱されているサンプルがHDRP対応なのでサンプルを動かすだけならHDRPテンプレートからプロジェクトを作成するのが楽かと思います。
また、URPだとPostProcessに対応していないようなのでリッチなコンテンツを作りたい場合はHDRP一択になるのかなと考えています。

When using URP, you need to modify the camera settings to be able to write into the alpha channel of the color buffer. For video pass-through to work, make sure the camera’s Post Processing and HDR settings are disabled.
引用元

それでは実際のプロジェクト作成に移りましょう！
* プロジェクトの作成

• パッケージマネージャーからSDKをインポート

  • Gitを使う場合
    • Window > Package Managerをウィンドウを開き、左上の+ボタンからAdd package from git URLをクリック
    • https://github.com/varjocom/VarjoUnityXRPlugin.git を指定してインポート
  • ローカルにダウンロードして使う場合
    • Window > Package Managerをウィンドウを開き、左上の+ボタンからAdd package from diskをクリック
    • ダウンロード済のSDKのpackage.jsonを選択してインポート

• プロジェクト設定の変更

  • Edit > Project Setting > XR Plug-in ManagementからVarjoのチェックをONにしてください
    

• レンダリング設定の変更

  • 前提知識
    • Varjoのディスプレイは中央のFocus Displayと周辺のContext Displayがあり、両目で計4枚のディスプレイがあります
    • Edit > Project Setting > XR Plug-in Management > Varjoから各種レンダリング設定を変更できます
  • パススルーを使用するための設定
    • OpaqueをFalseにする(標準がTrueなので変更必須)
      • Falseにすることでアルファブレンディングを行うようになります
        
    • (HDRP)Project Setting > Quality > HDRP > HDRenderPipelineAsset > Rendering > Color Buffer FormatをR16G16B16A16に
      
    • (HDRP)カメラのBackgroud TypeをColorに、Background ColorをRGBA(0,0,0,0)に
      
    • (URP)カメラのBackgroud TypeをSolid Colorに、Background ColorをRGBA(0,0,0,0)に
      
    • (URP)カメラのRendering > Post ProcessingをFalseに
      
    • (URP)カメラのOutput > HDRをOFFに
      

これで設定はOKです。

サンプルシーンの読み込みとシミュレータでのテスト

• サンプルシーンの読み込み
  Varjo XR Plugin>2.1.1>HDRP Samplesに各種サンプルシーンがあるのでそれを使用してください。
  今回はパススルーの設定をしましたのでMixedRealityを使用します。
  

• Varjo Baseでのシミュレーション
  なにも接続せずにVarjo Baseを起動すると"No headset connected"となりToolsは選択できない状態ですが、左下の"Analitics window"だけは使用できます。

Analitics windowをクリックすると新規ウィンドウが開きますので、左下のボタンをクリックしてメニューを表示>Simulateボタンを押してXR-3を選択してください。

選択すると、Analitics windowが再起動しますので、これで準備完了です。
この状態でUnityでPlayを押すとAnalitcs windowにレンダリング結果が表示されます。
ピンクの部分がパススルーになる部分です。

おわりに

本記事ではVarjo Unity XR SDKを使ってサンプルシーンを試してみました。
現状では中々触る機会がないような機材ですが、シミュレータもありますので興味ある方はぜひ触ってみてください！
マーカー検知やハンドトラッキングについても実機検証は出来ているので次回以降の記事で触れられたらと思います。

ここまで読んでくださりありがとうございました！

▼最後にお知らせです▼

お知らせ

Synamonは、Unity / C#エンジニア、テックリードを中心に新しい仲間を募集中です。
「XRが当たり前の世界をつくる」というミッションに共感したメンバーが、切磋琢磨しながら日々挑戦しています！カジュアル面談も実施中なので、ご興味ある方、お気軽にご連絡ください。
カジュアル面談でご来社いただきXR-3を体験することなども可能ですよ！

カジュアル面談はMeetyから▼
meety.net

エントリーはこちら▼
herp.careers

また、本テックブログやnote記事のお知らせは、Synamon公式Twitterでも発信もしています。
弊社の取り組みに興味を持っていただけたら、ぜひフォローお願いいたします！
twitter.com

PMBOK 7th 勉強会 第1回を開催して得られた学び

PMBOK 7th勉強会、始動。

こんにちは！
Synamonでエンジニアリングマネージャーをしている佐藤（@unsoluble_sugar）です！

先日、本テックブログでアナウンスしたとおり、社内のエンジニア有志メンバーが集まり「PMBOK 第7版」の勉強会を開催することになりました。

synamon.hatenablog.com

2021年8月の出版時点では日本語訳版が出ておらず、英語版を訳しながら読み進めていく形となったため、Section区切りで何回かに分けて継続開催していきます。  

PMBOKとは

PMBOK（Project Management Body of Knowledge）とは、PMI（Project Management Institute）がプロジェクトマネジメントに関するノウハウや手法を体系化してまとめた本です。

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition and The Standard for Project Management (ENGLISH) (English Edition)

1996年の初版出版以来、4年に1度くらいの頻度で改訂が繰り返されており、2021年8月に第7版が出版されました。

本書は『The Standard for Project Management』と『PMBOK Guide』の2部で構成されています。今回は1発目ということで『The Standard for Project Management』の序章〜Section 1まで内容を翻訳。

本記事では概要の抜粋と、勉強会を開催してみて感じた課題について書き記していきます。

序章

1987年にホワイトペーパーが発表されてから、PMBOKは進化し続けてきました。改訂の間に世界的な変化が起きています。

• 古い組織や技術が消えていく一方で、新しい組織が生まれ、技術も進化している
• 過去10年だけでもあらゆる製品、サービス、ソリューションへのソフトウェア導入が急激に進んでいる
• 様々な変化は起きているものの、基本的な概念や構造は変わっていない
  • 一人で考えるよりも集団で考えたほうが包括的な解決策が得られる
  • 組織はプロジェクトという手段を使い結果やアウトプットを提供する

PMI関係者によるフィードバック

PMIは世界中のステークホルダーのフィードバックを取り入れ、PMBOKをより現実的なものにしています。世界各地で開催されたワークショップのフィードバックをまとめると、大きく４つのポイントが強調されました。

① 信頼性と関連性の維持・強化
② 読みやすさ、使いやすさの向上させる一方で、新しいコンテンツを詰め込みすぎないこと
③ ステークホルダーのニーズを察知し、実践的な補足コンテンツを提供する
④ 過去の版の内容には継続的な価値があり、その価値を否定することなくシフトすることでより強化される

これらに適応するため、PMBOKはプロセスベースからプリンシプル（原則）ベースに変わり、成果物よりも価値をもたらす結果に焦点をあてる形になってきました。

• 予測型から適応型アプローチへ
• 組織の戦略、価値、ビジネス目標の推進に結びつける「バリューチェーン（価値連鎖）」に焦点を当てる視点に変わった
• アウトプットよりもアウトカム重視

第6版からの追加項目

第6版と比較すると全体の構成が再編されていますが、新たに追加された項目としては以下のとおりです。

• The Standard for Project Management
  • 価値提供システム
  • プロジェクトマネジメント原則
• PMBOK Guide
  • チーム、開発アプローチとライフサイクル、プロジェクトワーク、デリバリー、不確実性
  • テーラリング
  • モデル、メソッド、成果物
• PMIstandards+

PMIstandards+は、プロジェクトマネジメントの継続的な進化をサポートするデジタルプラットフォームです。

『The Standard for Project Management』と『PMBOK Guide』を補完する情報も見れるということで、本書と合わせてチェックしてみるのが良さそうです。

Section1

『The Standard for Project Management』は、プロジェクトマネジメントを理解し、どのようにして意図した成果を実現するのかという基礎を提供するものです。

本記事では、主な用語と解説のみピックアップします。

主な用語と解説

アウトカム

プロセスやプロジェクトの最終的な成果、結果。アウトプットや成果物も含まれるが、より広い意味でプロジェクトがもたらす利益や価値に焦点を当てている。

ポートフォリオ

戦略的目標を達成するために、グループとして管理されるプロジェクト、プログラム、およびオペレーション。

プロダクト

生産され、定量化可能な成果物。それ自体が最終的に提供されるものである場合や、成果物を構成するものの一部である場合もある。

プログラム

関連プロジェクト、補助的なプログラム、プログラム活動の集合体。個別に管理した場合には得られない利益を得るために、バランスを保って管理される。

プロジェクト

独自のプロダクト、サービス、または結果を生み出すために行われる一時的な試み。プロジェクト作業そのもの、またはプロジェクト作業フェーズの開始と終了を示す。単独で行われることもあれば、プログラムやポートフォリオの一部として行われることもある。

プロジェクトマネジメント

プロジェクトの要件を満たすために、知識、スキル、ツール、およびテクニックをプロジェクト活動に適用すること。意図した成果を実現するためにプロジェクト作業を指導すること。プロジェクトチームは、幅広いアプローチ（予測型、ハイブリッド型、適応型など）を用いて成果を達成することができる。

プロジェクトマネージャー

プロジェクト目標の達成に責任を持つプロジェクトチームを率いるために実行組織から任命された人物。成果を達成するためにプロジェクトチームの作業を促進し、意図した成果を実現するためのプロセスを管理するなど、さまざまな役割を果たす。

プロジェクトチーム

プロジェクトの目的を達成するために、プロジェクトの作業を行う個人の集合体。

価値提供のためのシステム

組織を構築、維持、発展させることを目的とした戦略的な事業活動の集合体。ポートフォリオ、プログラム、プロジェクト、プロダクト、オペレーションのすべてが、組織の価値提供システムの一部といえる。

価値

絶対的な価値、重要性、または有用性のこと。ステークホルダーによって価値の捉え方は異なる。顧客は製品の特定の機能や特徴を利用できることを価値と定義することができる。組織は利益からその利益を達成するためのコストを差し引いたものなど、財務的な指標で判断される事業価値に焦点を当てることができる。社会的価値とは、人々の集団、地域社会、環境への貢献を含むものである。

その他

『The Standard for Project Management』で使用されるその他の用語については Lexicon of Terms | Project Management Institute を参照。

勉強会では、ポートフォリオ、プログラム、プロジェクトの関係性が曖昧なメンバーも居たため、理解を補足するための参考記事を貼っておきます。

xtech.nikkei.com

Section2でもこのあたりの話が出てきますが、後述するPMBOK第6版の図解解説本にもわかりやすい説明が載っていたので、そちらも参考になるかと思います。

勉強会を実施してみて感じた課題

今回の勉強会は参加者5名、1時間枠で開催。第1回の実施を終えた上で、以下のような課題があがりました。

課題

• Section1まで読んでおく前提だったが、手を付けられていないメンバーも居た
• 用語の解釈が難しい場合がある
• とりあえずやってみる精神で始めたものの、良い感じの進め方ができなかった
  • 全文を読み回ししていると時間が足りない
  • その場で翻訳するのはしんどい
  • 英語スキルの度合いによって翻訳に時間がかかる
  • 翻訳に注力してしまい肝心の内容について議論する時間が薄かった
  • 隔週開催ではペース配分のバラツキや継続性が失われる懸念あり

対策

• 事前に次Section分を読んでおくこと
• 各自で内容を掻い摘んで要約してくる
• 勉強会では要約内容を示し合わせ、議論にフォーカスする
• 隔週開催ではなく毎週開催に
• 勉強会（読書会）の進め方について知見収集する

実施方法にも改善の余地あり

勉強会の実施方法も少し考えた方が良さそうだと感じました。

今回はoViceで通話しながら、Scrapboxを画面共有で映しつつ概要を箇条書きしていましたが、各自の要約内容を照らし合わせるのであれば、miroのボードを使う形式の方が適しているかもしれません。

miro.com

以後の勉強会では、より最適な手法を模索していければと思います。

やっていくぞ

今回は『The Standard for Project Management』の序章〜Section 1までということで、第6版から第7版への変更点概要や、本書で使われる用語の定義が確認できた程度でした。

とはいえ個人的にPM経験はあるものの、これまでPMBOKは未履修だったため、本書に触れる機会が得られて良かったです。

第7版は引き続き読むとして、第6版の内容を補完するため日本語解説書をポチってみました。土台を固めて挑んでいく構えです（ｷﾘｯ

図解即戦力 PMBOK第6版の知識と手法がこれ1冊でしっかりわかる教科書

本テックブログやnote記事のお知らせは、Synamon公式Twitterでも発信もしています。
弊社の取り組みに興味を持っていただけたら、ぜひフォローお願いいたします！

twitter.com

Meetyで僕と本のお話をすることもできるので、本書に関する情報交換をしたい方は、お気軽にお声がけください～ meety.net

次回はSection2以後の様子をお届け予定です！
お楽しみに！

追記：Section2の記事出ました！

synamon.hatenablog.com