接続」で指定しないといけないが、それ以外は使い慣れたPowerShellで操作できるので、GraphExplorerから一歩進んだGraphAPIの勉強にはぴったりだと思いました。Online編11月に開催されたIgniteの動画をせこせこ見ています。全部見終わった後に感想を書こうかと思いましたが、見たい動画が50本くらいあっていつ終わるか分からないので、切りのいいところで感想をリリースしていきます。Onlineの新機能。"+"アドレスによる、受信アドレス追加Gmailでは10年以上前に実装されている機能で、myaddress+[任意の文字列]@gmail.comとかで受信アドレスを無限に作成できる機能。当時のテクとしては、myaddress+rakuten@gmail.comで楽天からのメールを全部フィルタする、って技がありました。(new!)セカンダリアドレスでのメール送信その名の通りですが、メールシステム構築時の設計要素が増える。3rdパーティー製のMTAにメールを投げていてMTAがメールアドレス課金の場合、セカンダリアドレスがでユーザーがメールを送信する事で、課金が発生してしまう。Onlineは既定でonmicrosoft.comのアドレスをセカンダリに持つため、onmicrosoft.comのアドレスを使ってユーザーが外部にメールを送信できてしまう。メールでの監査検索などでひっかける時の条件が増えそうで心配です。3rdパーティー製MTGでメールアーカイブしてたら、1人のユーザーのメールを抽出するのにプロキシアドレス分検索しないといけないから辛い。この仕様が防げないなら、プライマリアドレス以外では外部にメールが送信できないようなトランスポートルールを作成するしかないのかな。メッセージの取り消しOutlookにRecall機能というのがありますが、相手がRecallメッセージをクリックしないと取り消せなかった(なので、相手はメッセージを必ず読むことができた)のが、相手がO365を利用している場合、サーバー内部で取り消し動作が入るので、取り消し処理の強制力が強力になった。実際に取り消しできたかレポートも出る。相手がO365外の場合に機能しないとはいえ、これはうれしい変更。Stormの抑制1時間以内に5000以上のアドレスに対するReply-Allのメッセージが30以上発生した時に、一時的にメール送信が禁止される機能。発生しなさそうですが。管理センターでメールフローの確認がよりやりやすくなるGUIが変わっただけっぽいが、HistoricalSearchやGet-MessageTraceなど、複数のコマンドを使い分けで取得していたのがGUIから指定できるぽいのはいいかも。JAPAN現状、あて先の最大数は500だが、1~1000アドレスとなる1000になってうれしい!と思いきや、実際の案件だと「3rdパーティーのアーカイブの処理能力を超えるから、少ない宛先にしか送れないようにしたい」「外部向けのメールの宛先数は絞りたい」とか言われるので、小さくできるのがうれしい機能。Submittionが既定で無効になるサブミッションポート(587番ポート)の事。Onlineにメールボックスを作って、通常のSMTPクライアントでメール送信している場合はNGになる。現状のオブジェクトはそのままの設定で、新規のオブジェクトも設定をONにすれば使えるようになる。OutlookOutlookカレンダーチームによるセッション。去年は2人ペアだったが今年は1人が妊娠→出産中なので1人でやるぜいぇーい!と元気にスタート。iOSで以下が出来るようになる。中にはデスクトップ版でも使わないようなマニアック機能がありますが。予定の検索その他、既にリリース済みですが、大きなアップデートとしては共有メールボックスの追加が可能になった事。予定調整がさらにしやすく。Web限定ですが、部屋名をインクリメンタルっぽく入力するだけで、空いている部屋を提示してくれる。単一予定だと既に実装済みだが、これを繰り返しの予定もサポート。会議室にメタデータを設定する事で、会議室を探すときにより詳細な情報を閲覧できる。カレンダー共有の新ロジックがベータテスト中。同期が早くなるのとMAPIやRESTでいじりやすくなるのがメリットだが現時点ではバグあり。会議送付時に参加者自身が"場所"やTeamsMTGを追加できるようにしたこと。参加者が予定を変更する権限は今までなかったので大きな変化。SIer的には大きく話その1。365にSyncすることができる。便利な一方、嫌がるお客さんから禁止してくれとか言われそう。SIer的に大きい話その2。同士なら、管理画面で設定しなくても予定表の共有ができる。これも便利な一方、防ぐ方法は聞かれそう。空き時間の共有だけだからいいと思うんですけどね。去年予告されて期待された2つの機能「MTGを辞退しつつ、自分の予定表に残す」「MTGの主催者を別の人に交代する」はリリース予定未定に。あとはバグフィックス。タイムゾーン跨ぎの終日予定が、ちゃんと終日で表示されるようになります。excitingBRK2001に比べれば大したことないセッション。全般的にGmailで先行している機能が付きます。返信文章をサジェストしてくれるとか。もらったメールの表を編集する事で相手にも反映される機能や...Teamsからのメッセージに対して、OWA画面から返信できる機能。Onlineコマンドレット。バックエンドの構成を見直したおかげで、従来のコマンドレットに比べて動作が4倍~8倍速くなり、安定する。大量の夜間バッチ処理などで5,000件問題に悩まされていたのも解消される可能性があると思いました。新しい管理センターの話。Suiteからの移行時にメールだけじゃなく予定表や連絡先も取り込めるようになったのはポイント。移行ソリューションが死んじゃいますな。edition全部知ってる内容で大したことなかったです。前半のEOPの設定でマニアックな話をしていますが、実際には効果が未知数なことが多いし静的に定義してもスパムには効果がないので、EOPにお任せが一番いいと僕は思ってます。中盤のATPあたりは、E3で使える機能とE5で使える機能が混ざってますが、知らないなら見ると勉強になる。Intelligenceはメールの専門家ならお客さんに説明可能であるべし。後半のSPF,DKIM,DMARCは知らない人は見ると勉強になるけど...メールの専門家じゃなきゃ不要です。全体的にdocs以上の情報がないセッションでした。threatsサイバーキルチェーンの紹介と、各リスクに対する対策を説明したセッション。見慣れたキルチェーンの図。残念ながら、社内のインサイダー(悪者)を見抜くのは難しい。防ぐには、技術的な観点よりは、インサイダーの振る舞いを予測し、エミュレートし、脆弱でない事・不正なログがない事などを確認。ビジネスプロセスの見直しなどが有効。そもそも、インサイダーが発生する土壌となるような社内の透明性や評価制度などが問題である。その他、クラウド事業者自身やさまざまな攻撃者に対する対応を検討するようなセッションでした。Sentinelの紹介はあったものの、メールというよりはセキュリティ系のセッションで、セキュリティを語る上でのベースとなる知識をインプットできるセッションです。mobileのセッションと見せかけて、実質EM+Sのセッション。policyってのが登場。policyとの違いが良くわからん...。Docsここらへん、ミスって設定するとTeamsからのアクセスがブロックされたりするから設計難しく、端末が準拠済みだったらOKとする案件が多かった気がするけど最近は違うのかな。差分の知識だけで生きてくのがつらくなってきました。Mobileから、スパム、マルウェア報告が出来るようになるIntuneチームが頑張ってるのは分かるけど、ロックスクリーン通知を防ぎたい顧客はいるのか?まぁどちらかというと防ぎたいだろうけど...。SIer的には顧客からカネが出づらい機能が増えるのは複雑な心境ですな。AIPとかS/MIMEは会場の反応も微妙でした。行ってきたこちらのイベント。connpass去年、私が同様のイベントに参加したレポートはこちら。Japanに行ってきました。今年の感想ブログはただのメモなので、twitterなどにも拡散せずメモを書きます。#pmconfjp表題のイベントに行ってきました。2019「プロダクトマネージャー」とは、サービス型プロダクトの責任を一手に引き受けるロールです。...などを考え続ける、昨今のSaaS型ビジネスの台頭により注目され始めてきたロールかな、と思います。私がこのイベントを知ったのはfukabori.fmの及川さんゲスト会です。自身がサービス開発を行っているため、何かヒントが得られればと思い参加しました。私はとあるSIerでサービス開発の部署に所属する一社員。SI主体のビジネスからサービス開発に舵を切る事になり専門の部署が立ち上がるも、手探り状態で四苦八苦。そんな状態なので、全てのセッションで学びがありました。ここではその学びをロールスキル・テクニックマインド組織の4つに分けてまとめていきます。ロール「プロダクトマネージャーって何する人?」という問いが、カンファレンス全体のテーマでした。それに対する登壇者のアンサーはさまざまでしたが、会社の規模・プロダクトのフェーズによってPdMに求められる役割は変わるが結論かと思います。棚橋さんのスライドがよくまとまっており、自社/プロダクトの状態にマッチしたPdMのロールを考えるのが、pmconf参加者の宿題だと思いました。ヒントとなるのは「企業が求めるプロダクトマネージャーとその人材戦略」でパネラーの皆さんが話されていたこと。転職者をそのまま採用してもうまくいかないオンボーディングが何より重要という話があった通り、後述するプロダクト開発のスキル・テクニックを持った前提で、社内文化の理解・社内ステークホルダーとの調整できる能力が重要なのかな、と思いました。確かに、自社内の人材にPdMとしてのスキル・テクニックを身につけさせる方が、社内リソースの理解、競合他社と自社の差別化ポイントの理解、社内の顔の広さなどでPdMの仕事はやりやすいと思います。三木さんのセッション。ロードマップをコミットしつつ、技術メンバーに品質アップを求め、二枚舌を使い分けています。うまくバランスとりつつフェーズ毎で重視するポイントを変えるのがPdMのロールだと思いました。あと、PdMはなんでもやって当然、ということ。私自身、いろんな所から呼び出し食らって「この職業何なの!?!?」と思っていたところに全部やる職業だよ~と言われたので、覚悟を決めて呼ばれる前に自分で動くことにします(白目スキル・テクニックPdMに必ず必要な顧客ニーズ理解スキル。これは小城さんのセッションが素晴らしかったです。koshiro顧客ニーズ理解の原理原則はジョブ理論やデザイン思考だと思いますが、これを実際の現場でどう実践すればええねん?というアンサーに応える、体系化されたプロダクト開発の手法と実践がまとめられていました。類似の話で、freeeの岡田さんによるストーリーテリングの重要性も面白かったです。出席できませんでしたが、en-japanの岡田さんのセッションも面白そうでした。プロダクトマネージャー|note「ひとまず出来る人をアサインして何とかしてもらう」するだけのPdMは終わり、ウォーターフォールでいうPjM、PL、Memberのようなステージを定義し、PdMを目指してもらうようなキャリアパス定義するのは、大きい組織を動かすには大事だな思いました。先進企業によってPdMに必要なスキルが定義されつつあるのが、ありがたい事です。変わったところだと、会議のテクニックの話を頂いたCOPILOTの定金さん。初日のTransferWiseさんのセッションで「自律的なチームは、会議などせずとも、プロダクトの計画、ロードマップを策定できる」と言われてましたが、現実的にはそんなチームばかりではない。チームをそこまで引き上げるための手段として会議というツールは有効なのかな、と思いました。PdMにはデータ分析スキルは必須!というセッションに響いている方が多かったです。関連セッションはこちら。会社なので、集められるデータが少なく私はピンと来ませんでしたが、マーケティング部門はAdobe社のMarketoを利用していろいろやり始めたようなので、必要なスキルとして意識はしようと思いました。マインド上層部はチームをチームを信頼し、権限と責任を移譲する。チームは結果でそれに応える。メンバーを信頼し、自律的に動いてもらう機能を実装するのではなく、顧客に価値を提供するとプロダクトに関わる全員が理解する最初のキーノートをはじめ、いろいろな場所で同じようなことが語られていました。小手先のテクニックより一番大事な話だと思いますが、文章で伝えるのは難しいのでこのブログでは軽めに紹介して終わり。いうのを肌で体感出来るのはカンファレンスに参加した人の特権ですね。参加しなかったメンバーにどう伝播させるかが難しい。このために利用されるのにOKRという概念があり、セッションでもたびたび登場していました。こちらはプロノイア・グループ株式会社のピョートルさんの発表より。いった記事もあります。Googleの「最高の上司」がチームの生産性を高めるためにしていることただ、旧来型の組織にOKRをいきなり導入するのはハードルが高いので、OKRに飛びつくのではなく、自身/メンバーのマインドセットを育てたり、チームの心理的安全性を高める、といった改善から進めるのがよいかと思います。山田さんのセッション。権限もリソースも与えられないのにサービス開発しろとか無理だよね、けどPdMの努力で徐々に会社を変えていける...という内容でした。上司がやってくれている事と似ていて勇気づけられました。受託SIとは全く違うロールが必要であるそのロールやタスクは○○であるという可視化をし、認知するところから始めてます。今作ってるのはこんな感じの図。上層部の協力者とのつながりはあるので、ある程度まとまったら話に行こうと思っています。ついても、予算と必要なメンバーを計画する権限はあります。人事権はありませんが、上司がメンバーを引っ張ってこれなかったら予算は達成できなくても仕方ない、となっているので、よいかな...と思います。アサインついたら実行責任もついてきますが、PdMのあるべき形っぽくていいかな、と思います。予算もメンバーに可視化され、プロダクト別の採算になっているので、KDDIさんの目指している形と近いのかなと思いました(上司ありがとう)。自分の方向性が間違っていない事を確認できたので、非常に良いセッションでした。宣伝:弊社のプロダクトこれだけだと弊社の欠点だけあげつらった形になるので、プロダクトも少しだけ紹介しておきます。えるとこの2つに私は関わってないので、これらのプロダクトチームは上にあげた課題を解決した上でプロダクト開発しているのかもしれません。まとめ登壇している方はサービス開発先駆者の皆様ばかりで、非常に学びになりました。初日のネットワーキングで会話した方々は、私と同じでサービス開発初心者だったり、会社にサービス開発を理解してもらうよう奮闘していたりと、仲間がたくさんいる事が分かり勇気づけられました。非常に素晴らしいイベントでした。来年も参加したいです。TAKAKING22.com登壇者のスライドがまとめられてて便利です。@satomikko94.bグラレコ風メモがあって可愛いです。2019の動画を見よう!という趣旨で、いつもよりは緩くまったりとした雰囲気でした。方法は、sli.doに見たい動画を投稿して票が多かったものからピックアップです。Igniteキーノート。これはリアルタイムで全部見てたので、特に今更な感想です...。投票数が多かったから選ばれたけど、確かに私も昔はキーノートを動画で見たことはなかったから、みんなで見たのは(未視聴の人がハマるきっかけとしては)よかったのかな。minutesSPOサイトの構成。私はSPOよくわからないですが、サブサイトというのが諸悪の根源(なのか?)であり、もっとフラットにつながり合おうぜ、というセッションでした。あるサブサイトはどうするの→弊社、ShareGateのツールで整理できるぜ、とのセッション付き。adoptionTeams普及させるにはどうしたらええねん!というセッション。私に何のメリットがあるの?を明確にする)、コンテンツより文脈、流れを重要視しろ、というのが書かれていました。チャンピオン制度については私はそれの成功例を体験していないのですが、これだけみんながいいと言っているならいいんでしょうね...。Apps吉田氏のセッション。この間、別件で対応していたのであまりヒアリングできず、でした...。キーノートの所で特に思ったのが、結局黙って2時間見る形になったので、チャットルームとか、動画の上にコメント投稿できるオーバーレイ的なシステムで参加者同士がコミュニケーションできればいいと思いました。あと、参加者が分散するかもしれませんが、2レーンに分けてそれぞれ見たい動画を見れるといいのかな?と思いました。セッション一覧の集め方Igniteのセッション1600つくらいの情報を全部ダウンロードしてExcelにまとめたよ、という話をtwitterしたら、主催のもくだいさんから話してくれと言われたので話しました。...が、当日は若干社内の取り組みの話を重視してしまい、集めた技術にはタッチできなかったのでここで説明します。Wikipediaやコンサートチケットの転売屋も同じ技術を使っていますが、要は検索エンジンのクローラーを自作するようなイメージです。スクレイピングを行う言語でメジャーなのがpythonですが、私はnodejs(javascript)でやってます。pythonはツールが乱立しているが、nodejsはGoogle謹製のpuppetter一択であり、初心者的には迷いが少なかったこと、本も出ているのが理由です。スクレイピング+Web操作自動処理プログラミング私はpowershellで運用スクリプトを書ける程度のレベルですが、この本を読むことで今回の処理が実装できました。pythonでもnodejsでも、本物のWebブラウザのRPAみたいにポチポチするのではなく、ブラウザドライバー(Webドライバー)というブラウザのプロセスにアタッチして自動的に操作するモジュールに対して命令を実行します。pythonではselenium、nodejsではchrominiumです。ここらへんの定義はややこしいですが、ひとまずブラウザをAPIで操作してるんだな、くらいの理解でいいです。QiitaRPAと違った利点は、RPAが「画面」を操作するのに対して、ブラウザドライバーが「ブラウザをAPIで操作」するので、後者の方がWebサイトのデザイン変更に強い。CSSが更新されてデザインが大幅に変わった場合、RPAだと一環の終わりだが、ブラウザドライバーはHTML要素を見るので問題なく操作可能。Flowも後者のブラウザドライバータイプなので、普通のRPAより優位性高いです。変更弾力性が高いのは、WebシステムそのもののAPIを利用することです。MS-500,MS-100,MS-101を受験して合格しました。