【メモ】LINQを用いた計算について
C#以外の言語でMapやReduceなどを利用することが多いが、C#だとLINQでできてしまうので、便利なことが多い。
普段、仕事で使っている場合はLINQ to EntityかObjectを利用することが多く、ほとんどが 「Select」「Where」で利用することが多い。
Aggregateを使うと、よりいい感じにできるみたいなので、自分の整理のためにメモしておく。
まあ、MSのサイトにこう書いてあるのだが、例えが自分にはわかりにくかったので・・・
例えば 配列で[ 2, 3, 4, 5, 6]というものと、初期値として10というものがあった場合、 それぞれの配列に10をかけたものの合計を求めるとする。 forとLINQそれぞれ利用したものは以下の通り。
int[] arr = new int[] { 2, 3, 4, 5, 6 }; int initial = 10; int result = 0; /*For文*/ for (int i = 0; i < arr.Length; i++) { result += initial * arr[i]; } Console.WriteLine($"合計 : {result}"); /*LINQ*/ var linqResult = initial * arr.Sum(x => x); Console.WriteLine($"合計 : {linqResult}");
これを、配列に記載の値をかけるとした場合、LINQには掛け算はないが、Aggregateを利用することで、計算結果を次の配列に使うことができる。
int[] arr = new int[] { 2, 3, 4, 5, 6 }; int initial = 10; int result = 0; /*For文*/ int multi = 1; for (int i = 0; i < arr.Length; i++) { /*multi変数を使いまわしとなるが・・・*/ multi *= arr[i]; } result = initial * multi; Console.WriteLine($"合計 : {result}"); /*LINQ*/ var linqMultiResult = arr.Aggregate(initial, (sum, next) => sum * next); Console.WriteLine($"合計 : {linqMultiResult}");
Aggregateを活用すると、初期値、(設定する値、配列の値) => 計算式 とすることで、初期値の値から、次の添え字の結果、その結果をまたその次の添え字の結果として、計算ができる。 パット見ると慣れない記述となるが、for文であれこれ考えるより、1行でスパッとできるので、いい感じ。
欠点ではないが、極力、指定する数値の型は合わせる方がよさそう。intとdoubleとか異なる型だとコンパイルエラーになります。
ただ、自分が日ごろ管理しているビジネスアプリだとあんまり使わないかな？(会計処理だと使えるかもです)
【メモ】安全確保支援士の学習
2022年秋の安全確保支援士の受験をしました。
結果は・・まだわかりませんが、今回試した方法を記載します。
事前スペック
- 仕事ではあまりネットワークやセキュリティに関することはしていない(クラサバがメイン)
- 2022年春にネスペを受験したので、少しは知識が残っている(ネスペは午後1が2点足りず)
- 仕事でクラウドを使うことになっていきそうなため、ネットワーク・セキュリティの最低知識を知らねば・・・という状態でした。
最初に取った作戦
翔泳社の本 → ざっと一通り読んだけど、かすかにしか覚えられず(鈍器ですね)
インプット系が多く、アウトプット(問題演習)がないため、私は知識定着しにくいなと感じていました。特に、基礎的な部分が身についているのかを計りづらく、「覚えれているかな？」と不安になるばかりでした。
また、仕事がバタバタしていたのと、情報処理試験一週前にビジネスキャリア検定試験も受験予定に入れおり、そちらに集中していました。 そのため、余計、情報処理の学習ができていない状況で、状況にあっていない本でしたね。
中身は良い本なんですけどね。
まとめると・・・。
- 広く浅く書かれているのですが、テーマごとの関連性がつけにくかった(前をやると、後ろのが分かるというのではなく、網の目のように入り組んでいるように感じた)
- アウトプットがしづらい。過去問を解けばいいのですが、テーマごとに絞る時間がない。章や節ごとに書いてあるチェック一覧が分かればいいのだが、限られた時間内では難しかった
と、なんだかんだしていたら、試験まで残り2週間。さて、どのようにやろうかとネットサーフィン、twitterを眺めていたら、いいのあるじゃんということで、この二つに絞って学習し始めました。。
方向転換
とにかく、要素技術が私の中で整理できていない。情報の関連性がなく、ストーリーになっておらず、頭に定着しにくい状態でした。 また、午前Ⅱ対策のための過去問演習の準備を楽してできないかなと。
- 過去問対策
安全確保支援士の過去問道場という便利なサイトがあるじゃないですか。 過去回と分野別、また解説もしっかり書かれていると。お得ですね。 専門分野のみ絞って、過去問をやりまくりました。データベースやソフトウェア開発全般はある程度、自信があり、セキュリティに絞って問題解けるのは良かったですね。 また、解きながら、現時点の平均点や学習記録も残せ、定量的に自身の変化を知ることができるのもGoodでした。
- 専門知識のストーリー化
この中の「一緒に支援士の勉強をしませんか？」というプレイリストを聞きました。(2倍速で)
ほかにもあったのですが、会話のテンポ、声質、使っているイラストが私にとってはすっと入ったからです。
このプレイリストは毎回、以下のようにテーマごとに10分から15分くらいの動画になっていました。
まさるさんのyoutubeは多くテーマありますが、上記のプレイリストがとても良いつくりでした。話が連続しており、前で学んだことを生かして、新たなテーマを知る。順番にテーマ、要素技術を抑えられるというのが私にはあっていました。
- 暗号の種類→暗号化の方法→認証(エンティティ、メッセージ)→デジタル署名→CA局→アクセス制御
と、まずは防御側のことを知り、攻撃側のやり口を知る。
50以上の動画がありますが、文字で閲覧するより、イラスト動画で、ネットワークのやり取りを説明しており、イメージをつかむのに最適でした。 (私は聞きながら、ノートに同じような図を模写して覚えていました)
実際、本番でも、映像で見たことを思い出して解ける問題もありました。
動画なので、わからなくても何度も見返せますし、視覚と聴覚で覚えられるので、読書だけよりは刺激はあります。
イメージつきやすいものから取り組んだ方がいい
アナログの書籍で覚えるというのもよいですが、せっかく、先人の知恵を拝借でき、かつ分かりやすく解説している動画が数多く出ております。 玉石混合ではありますが、自分のスタイルに合ったものを見つけて、一気に広く浅く理解を深めるのがよいかと。
そこから、時間があればハンズオン(サンドボックスなどが提供されているものは実験してみる)で触ることで理解が深まります。
いろいろつまみ食いは良くないですが、選択肢の幅を広げて、自身に最適な学習ツールを見つけて、学習していっていただければ幸いです。
エリック・エヴァンスのドメイン駆動設計 輪読会 #2 に参加した(自分のメモ)
前回ひ引き続き、DDD輪読会に参加しました。
今回は、聴きながら家のことでバタバタしており所々でしか聞けませんでした。 Discordeの参加者のみなさんのコメントを後追いして、ピックアップします。
前回の勉強会のメモ restofwaterimp.hatenablog.com
今回も前回同様、事前にhackMDに気づきや疑問を記載し、それを拾い上げるスタイル。 前回と違うのは、気づきの数が・・・倍以上に膨らんでいる。
今回、一番刺激になったのは本編ではなく、本編終了後の廊下でのミノ駆動さんの話。 そこに至るまでの前振りなどは背景がわからないので、私の中では？？？なのですが、 evans本の本質、というかエリック・エヴァンスが伝えたいこと。というのに立ち返れた気がします。 内容は後ほど。
また、本勉強会で前回も感じたのですが、みなさん「言葉の定義」に敏感。 自分が気にしてなかったことも、取り上げられて議論されるので、それを聴ける、見れるだけでも勉強になります。
学び(完全に自分のためのものです・・・hackMDのコメントを拾って、リンクなど)
今回聞いたところのhackMDから自分がわからないこと、深堀したいことをピックアップ。 この記事で何か学べるわけではありません。自分もここからリンクを追って、学べるようにまずは書き起こしてます。 これから、参加していき、何のことか自分なりで語れれば、更新していきます。 深く学びたい場合は、勉強会へ参加するのが近道ですww
参加されている方の属性(しばてぃさんがPower BIで作成したもの。こういうことがすぐできるのが、 Power BIの凄さですね) オンラインということもあり、全国から参加されてます。
例の「Power BI でリアルタイムアンケート」を evans 輪読会の勉強会でやってみた！
— { "しばてぃ" : "Takashi Shibata" } (@shibatea365) 2020年9月5日
非常にウケが良かったのでまたやってみたい！#dddcj pic.twitter.com/hKHFEJnOtR
2章のHackMD
「用語と概念間の関係性」
この意味と、表記の揺れや意味の揺れについて議論が進む。 開発者とユーザ側。また、ユーザの間でも意味が違う。 コンテキストが異なれば、意味が違うのはそうなのだろうが、同じコンテキストないで、同じ意味を違う言葉で使っていたり、同じ言葉を違う意味で使っているなら統一する必要がある。
「よく言われる「DDDは重厚・重たい」という評価の発祥はどこか」
私は重たいと思っていた。書籍の厚さもあるが、覚えなければいけないことがたくさんあるイメージがあった。 実際、最初に一人で読み始めたときは話が抽象的で、読むために必要なバックグラウンドが掴めていなかった感じ。
実装の本かと思えば、設計の本とも思ったが、どうも単純な設計の話だけに終わらない本というのが今のところイメージです。 読み進めたら変わるかも。
「ユビキタス言語」
little_hands こと松岡さんの
「ubiquitous = in every where」で、ただ言葉を合わせましょう、以上に「会話でも、コードでも、ドキュメントでも」っていう意味が込められてるので、「共通言語」以上の意味を持つのだと思います
で、ユビキタス言語って、文字に起こした時の言葉だけじゃないのねと理解した。てっきり、用語だけ統一と思っていたので。
「OOUI」
オブジェクト指向UIは読んだことがないからどういうことかわからなかったが、フロントエンジニアとバックエンドのエンジニア間で共通の言語を用いた方が良いかという質問かなと。
同じ方が良い意見もあるし、違うこともあるという意見もあった。 私自身の経験だと同じ方が良いという認識であった。が・・あくまで、「開発者の中」という意味で。 これが、ユーザ(扱う部門が違う)とかだと同じデータでも違う言葉を使うこともあるなと思っていたので、何が良いかはわからず。 もし違っていても、違った意味で使っていると関係者が認識できているのならそれはそれでいいのではと思ったり。(ただ、誰かが確認を取らなければいけないので後々面倒になりそう)
「表現すべきことをより簡単に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること」
イテレーティブにすることというのもあるが、社内のコンサルタントによく言われることがあったなと思い出した。簡潔にかつ具体的にわかるかつストンと腹に落ちる言葉を考えるってこと。それを図とコードに再び反映させるってのはドメインのモデルを見直すということ(と自分は認識)
「çになってしまうと、ドキュメントはプロジェクトの進捗とのつながりを失ってしまうことが多い」
この話、リアルで聴けていないのでコメント見て。 いろいろ参考にしてよいというリンクが貼っていたので、転記 前回の知識を噛み砕くでもドキュメントの話は上がっていた。前回はリバースで作れるものはあえて書かない。「なんでそういうモデルにしたのか」というのは残した方がいいよねと。今回の話はドキュメント更新されないよね・・・ということかな？
www.slideshare.net
以下の言葉の定義について議論されていた。
- モデル
- 図
- コード
- ユビキタス言語 自分なりの説明ができると良さげ。
「P41 の図2.4と図2.5 のモデルについて」
違う図が書いてあるのはみなさん許容されている。違う視点で書かれているから。 その事象をどう捉えるかということと、「誰に伝える図」なのかがポイントかなと感じた。
何か調査をするときなども、「自分の分析のための図や表」と「誰かに説明するための図や表」は違うことがある。 また、切り口も変えることがある。
松岡さんが書いていたエリックの地球儀の話はこのyoutubeなのかな？あとでみよっと。 www.youtube.com
ここで22時ちょっと過ぎくらい。ここから廊下が始まった・・(終わったのは翌日2時少し前くらいだったそうです)
上段に記載しましたが、本編外でご講演(?)がミノ駆動さんよりあったので、そこがとてもためになった。 RailsとDDDの話の前提として以下のことが語られました(自分の理解なので間違っていたらごめんなさい)
「DDDで達成したいこと」は何か？という問いかけ
日本語版への序文にEvans自身が書いていて
主人公はコアドメイン。コアドメインの価値を最大化すること。 → メイン業務のウリや価値って何かを語れるか。
ビジネスの足を引っ張るのは何か
コアドメインに集中するために、他の層との結合を疎にする → 例えば、オニオンアーキテクチャ
ドメインの変化 → 実装のモデルも変化
設計時にはコアドメインの変化が実装にどう影響するかはわからない(というか、ユーザとかはしらない) そのため、できそうと設計時に判断してもシステム側が足を引っ張ってしまい、開発生産性が下がり、市場競争に負けてしまう可能性もある。 それを防ぐため、実装もコアドメインに集中させるため、依存を取り除くようにすべきだろうということ。
自社サービス(対外向けのサービス)を作る人はモチベは上がるが、内向きの仕事やSIなどの他企業の仕事の場合は モチベが上がらないという意見もあったが、それは違うということ。 より良い設計を作ることで、自分の価値をあげ給与に反映や、自社の売り上げに貢献する。 自分自身の価値をあげる活動にする。
DDDの特性として、
保守性
変更容易性
機能性
私の周り(SIer)では自分の書いたコードの設計で、自分の価値をあげようとか、売り上げ貢献に反映する動機でDDDなど より良いコードを書くという人がいないのでエンジニアの方からこういう言葉が出るのが衝撃であった。
設計やコードを洗練するということが自発的になされないことが多く、なかなかつらしのこともある(ただの実力不足？)。
わからないなりにDDDを取り入れようとしているのだが、自分の中のモチベは「保守性」と「変更容易性」 提供している機能にコアな部分の変更を容易にし、ビジネスへの変更をなるべく早く対応できるように変えたいなと。
話を聞いていて、実装をする人も経営のことを知るべきと感じた。 (多分、DDDやろうとしている人はビジネスエキスパートと話をする必要があるので、自然に対象のドメイン業務および 経営は学ぶ必要があるとは思っている) 自分たちが作るものの価値、インパクト、投資対効果などなどを見極めつつ何に注力するかというのを 他人任せにせず、自分で決めれるようになるのいい。
参考で貼られていたリンク
脈略のない文章になってしまいましたが、これで終わり。 今回も、開催していただいた@jnuank_さんありがとうございます。
次回もまた参加しよう！
読む敷居を下げてもらえる本(かなりお世話になってます)
エリック・エヴァンスのドメイン駆動設計 輪読会 #1 に参加した(自分のメモ)
ドメイン駆動・・・。書籍持っているけど、一人で読み続けられず、挫折し、積読状態になっていたところ、 「オンライン」で開催しているじゃん、と見つけ、参加。
昔に統計の書籍で輪読会には参加したことはあったが、「初学者入りにくい・・・」と思っておりましたが、本輪読会。。最高の学びの場でした。 文殊の知恵最高って感じの内容で、あっという間に3時間聞いてました。
勉強会のスタイルは hackMDで書籍の気づき・感想と疑問を事前に参加者で書き書き。 勉強会中は、hackMDの内容をファシリテーターの方が、まるでラジオを聞いているかのような感じで、題目に対してアテンド。 並行で、Discordにチャットでその時の気づきやアドバイスなどなどが経験者や有識者からひっきりなしに書き込まれるという。 音声はきかなあかんは、チャットは追わなければ・・・とてんやわんやでした。
聞いているだけ、チャットを眺めているだけで、学習できるという素晴らしい場の時間でした。
でもって、あとで、チャットを追ってみよう・・・と取り組み始めているのですが、コメントが多く、追うのだけで大変。 ただ、テキストで追っていくだけで、「そういう話していたな〜」と思い出しやすいです。
学び(完全に自分のためのものです・・・hackMDのコメントを拾って、リンクなど)
今回聞いたところのhackMDから自分がわからないこと、深堀したいことをピックアップ。 この記事で何か学べるわけではありません。自分もここからリンクを追って、学べるようにまずは書き起こしてます。 これから、参加していき、何のことか自分なりで語れれば、更新していきます。 深く学びたい場合は、勉強会へ参加するのが近道ですww
ドメイン
エヴァンスの用語解説では「知識、影響、または活動の領域」 開発するのって、このドメインにある問題を解決したいことを作るのかなと。 why必要として、whatどういう姿になっていたいのか。 howに走らない。何となく、BABOKとかREBOKの話かな？
モデルをシンプルにする
幹と枝葉と思っていた。幹だけを見つけるのがとても難しい。それも、「誰も見ても、それ！」と言える部分を見つけるのが。
コメントで参考となっていたサイト martinfowler.com シンプルなデザインのルール
テストに合格する
意図を明らかにする
重複なし
最小限の要素
優先順位は上の方が高い。 実装する時や設計する時は「意図を明らかにし」「最小限の要素」でドメインのことを示すことができるのか。 不要な部分は削るのだが、削った結果、「ビジネスに価値があるモデル」になっているかかな？検証するには例示とかかかな。
アジャイル開発(大規模)
「チームを複数に分割したアジャイル 開発」→危うい
何となく、モデル分析して、「このモデルはこのチーム」「このモデルはこのチーム」、「かぶるところあるけど、これはあのチーム」って分けるとあとで崩壊ってことかな？ もしくは、全体のモデルを考えずにモデル考えて、全体でつなげたらつながらん・・・ってことかな。SIerだとよくある・・・ってなっていたけど、よくあるかと。 アジャイル でなくても、ウォーターフォールでもあると。関連するシステムの境界を跨いで全体を俯瞰できるように(一人でも複数人でも)しなければ、 ドメインの境界はつながらないだろう。(業務もシステムもどちらも考える必要あると個人的な経験ではかある)SIerだと、先に機能ごとにチーム分けて、 つながらなくなることありますから・・・。
cynefin framework ← 初めて聞いた
知識の噛み砕き
CleanArchitectureから考えるのか？？ モデリング と言ってもデータベースモデリングではない。業務分析/ドメイン分析のこと。 ここは納得。データモデリングからするのではなく、業務を知ること。用語、一番主となるフロー、登場人物などを知ることが先。 また、その業務が「何のために、何を実現させるために」やっているかを整理するのも。(これしないと、データの世界だけで追っていても何作っているのか訳わからなくなる)
「最初からドメインオブジェクトだけをテストコード上で会話させる設計」 → どういうことかわからず。。。。本読めばわかるのかな？
勉強会の参加の皆さんは「設計、分析は一回こっきりではなく、ずっとやる」というtwadaさんのコメントに納得されていますが、 私の周りの現実ではそうならないこと多いなと・・・(業務は常に改善、進化するがね。システム変わらないのかい？というのと、システム作っても「もっと良い感じにならないかな？」 と考えるのが価値を高める気がするのだが・・・)
継続的学習
ここの質問、自分の取り上げてもらえてよかった。ドメイン知識が人に残る(それが成長)というのは理解できていたのだが、一度解散したプロジェクトがまた戻った時、 どうやってドメイン知識を引き継がせるのか・・・がわからなかったので。コードの設計はドメインの切り方などで残すけど、設計意図とかどうやっているのだろうと。
意図や歴史を（口頭でも）伝承できる人を増やす、絶やさないという方向もあったりしますよね は私もなるほどと思った。一人じゃなく、増やせばいいのだと。
why なして、そういう設計(モデル)にしたのかを他でわかるようにしておく what ←
how Resharperやjig(私もC# 使いなので、ReShaper使いたいけど、買ってもらえない・・・)
RDRA ADR(Architectural Decision Records) Design Doc → 聞いたことなかったので、見てみる。 www.sparxsystems.jp
ドメインエキスパートへコードを見せるか
自分は見せたことない。間に入る方(大体情報システム部門)へはありますが・・・。 コードではなく、業務モデリングを見せて説明かなと。そっから、正常系なのか例外系なのかを嗅ぎ分けるのが難しいですけど。 (往々にして、話し手のバイアスが入るので)
ソフトウェアを再構築するようなモデルの見直し
私もこれは気になっていた。放っておきたいけど、メスを入れたいのだけど・・・
t_wadaさんより t-wada.hatenablog.jp
で、タイムラインに流れてきたこれをポチりとした。
きたら読み込む
リファクタリング、リアーキティング、リライト について書いてあるそうなので、そこをまずはみる。
輪読会で扱っている書籍
【メモ】MS Learn のsandboxの利用(Visual Studio2019を利用する場合)
勝手に自分がはまったのでメモ。
サーバレスアプリケーションのMS Learnの途中でVisual Studio で作成した function を azure functionにデプロイする という演習があり、途中でsandobxに接続するというのがあるのですが、 なかなかうまくいかず、てこずったので記録として残します。
何にてこずったのか？
ここで、Concierge Subscriptionがでず・・・
Azureで関数を作っていたし、VSも最初からログインしていたのに出てこない・・。 なぜ？と思っていて、関数を作り直したり、 sandboxを一回expireさせてから再度やったりと。
結果として、これが解決なのかわからないですが、 こうしたらできた、ということで。
VSのアカウントのプロファイル管理で再度ログインする
これで見えるようになりました。
VS右上にある、アカウントのアイコンをクリックし「アカウントの設定」をクリック
プロファイルの管理画面に遷移する
そこで、アカウントのタイプでsandboxがあるので、一度切り替えて保存。
そうすると、Conciergeのサブスクリプションが表示された
選択できれば、そのまま継続できます。
MS Learnに記載されている内容やdocsの内容もVS 2017がベースで書かれているものなので、 2019でやるときには少し違う部分があるみたいです。
これで、先に進める・・・。
【C#とpython】 リストとタプルと辞書と集合
リストとタプルと集合がよくごっちゃになるので整理
| タイプ | 使い方 | C#だと | pythonだと | 特徴 |
|---|---|---|---|---|
| リスト | 添字 | new List<T,T> | をつける。t=["A","B","C"] | add,removeで追加削除可能 pythonならappendなど |
| 辞書 | key-valueとして利用する | new Dicitionary<T,T>() | Dictionary = {"USA":1, "JAPAN":2, "Germany":3} | RDBのような構造。 |
| タプル | C#だと戻り値。pythonだとimurableな変数 | return (0,1)など。C#7.0より利用かのいう | ()をつける。t = "A","B","C" | 追加、削除など要素の書き換えはできない |
| 集合 | 数学的な集合と同じ。文字列や文字を一意に作成する | HashSet() Sorted Hash()など | set() 文字 やset 配列の値 set Dictionary キーの値のみ一意に | 追加削除はできない |
DevRelのトップランナーが語る「DevRelってなに？」【758Dev】に行ってきました
2/17(月)にNAGOYA INNOVATOR'S GARAGE で行われました、
DevRelのトップランナーが語る「DevRelってなに？」【758Dev】
を聞いてきました。
DevRelって言葉は聞くのですが、エヴァンジェリストやアドボケイトと何が違うの？ というのが自分の中で引っかかっていたので、実際に活動をされている
Microsoft Evangelist 小田祥平 さん
IBM Developer Advocate 萩野たいじ さん
名城大学 准教授, IBM Champion for 2020 鈴木秀和 さん
のお三方の講演&ディスカッションでした。
直感で私が「そうなんだ」と感じたことは
「双方向」 「熱量」 「まず行動」
です。
DevRel Meetup in Tokyoについて – DevRel Meetup in Tokyo
DevRelとは？ DevRelは外部の開発者との相互コミュニケーションを通じて、自社や自社製品と開発者との継続的かつ良好な関係性を築くためのマーケティング手法のことです。
でも、エヴァンジェリストとかアドボケイト がイコールDevRelかといわれるとそうでないようです。
前者は「職務や役割」で後者は「アクティビティ」に当たります。
つまり、だれでも「DevRel」の活動ができるってことです。
「外部の開発者との相互コミュニケーション」 「自社や自社製品と開発者との継続的かつ良好な関係性を築く」
をベースに活動となると 例えば、自分が作ったアプリや、言語、自社サービスについてブログやTwitterでつぶやく(NDAに抵触しないように) 外部のコミュニティーへ出向く、発表する 自分の事業部の外という意味では社内のLT大会の発表や活性化活動で語り合うこともDevRelととらえてもよさそうです。
セミナーの中で興味深かったこと (私の私見も入っているので、発表者の意図とは違うかも・・)
・DevRelやろうよ
自分の会社の中だけしか知らないと、自分のレベルがよくわからななくなる。 世界の中から見て、会社または人はどういつ立ち位置なのか。会社、あなたの強みって何か言えますか？
そのために、会社の外のコミュニティへオフサイトで出かけてみる。 オンラインで学ぶこともできるが、オフサイトでリアルに登壇している人の熱量や参加者のモチベの高さに刺激を受けるのも大事。 それによって、自分のレベルを上げること！が重要。
・DevRelに求められる要素
技術力も必要になるが、「マーケティング」を知ることが必要。 自分の強みを生かす、価値を創造するという目的のため、自分をブランディングする必要がある。 となると、市場の外部分析して、自分もしくは会社の内部分析して、どこで戦うか決めて、 プロモーションして、どうやって外部の開発者と良好な関係を作るか戦略、戦術を練らなければならない。
もう一つは「コンサル力」 といっても、フレームワークを覚えたり戦略コンサルというわけではなく、「引き出す力」が必要 双方向コミュニケーションを良好にするため、かつ自社のサービスを利用してもらうためには相手の困りごとと 自分のサービスがマッチする必要がある。困りごとを把握するため、対象から情報を「引き出す」能力が必要とのこと
・疎外要素
否定
Fixed MindSetにならないこと(MSではGrowth MindSetを推奨)
https://neuroleadership.com/your-brain-at-work/microsoft-growth-mindset-transformation に記事ありました。
コンフォートゾーンにいるほうが楽なので、現状を変えたくない。 変えようとすると反発する人や否定する方もいる
それに屈しない「熱量」が変化しよとする人には求められるかと。
で、覆すには「巻き込む」か「結果」を先に出してしまうかというのが発表者の意見でした。
DevRelに限らず、よくある話と。組織における業務改革や構造改革もこれ当てはまりますよね。
・大学生への取り組み
コンピュータを「使う側」から「作る側」への視点の切り替えが必要というのが妙に納得。 大学でCSを学んでも直接、事業、会社で扱える能力がつくか、というのに対する対応として ITエンジニア育成プロジェクトを行っている。
名古屋エリアでこういう取り組みしている大学あること知らなかったので、人材育成としてもいい取り組みだと感じた。 CSを学ばずにSI企業へ入る人も多いので、SIも現場だけでは世の流れに追い付いけるわけないので、若い世代を 他流試合にたくさん出すことをしたほうが・・・(って、やる気とか熱意がないと始まらないけど)
と、DevRelって話を聞きに行ったのですが、総論では自身のキャリアプランを考え直そう。 その一つとして、「外部のコミュニティに足を運び、刺激を受けよう！」というのが 一番だったかと。
発表の中でも「お客さん」として参加ではなく、「自ら何かを出す」と、 発表する側、企画側、ブログ、TwitterなどのSNSで自らを発信する力ってのが求められていくのでしょうね。
企画をしていただいた、
IBM見習い隊 さん Microsoft Learnもくもく会 さん
ありがとうございました。
最後に、会場となった名古屋イノベーションズガレージ、めちゃきれいでよかった
