中堅エンジニア転職して今年1年間でやってみて良かったこと反省したこと
皆さん、こんにちは。職業「戸倉彩」です。
初めて1月〜12月が会計年度の会社でスタートから1年間を過ごし、何とかFY19(Fiscal Year/Financial Year)の仕事納めを終えました。ご支援ご指導いただいた皆さまに大変感謝いたします。
今回は、転職1年経ち、こうすればもっと自分の枠を超えて仕事ができたかもしれないという自戒の気持ちを忘れないように、また中堅どころのエンジニアの方々の転職後のヒントになる部分もあるかもしれないので記事を書くことにしました。
新しい環境で学び続ける姿勢
転職後、この1年を通じて主に「企業や組織の文化」、「同僚やパートナー企業様、お客様、コミュニティの方々との信頼関係の構築」、「自社製品やサービス関係する新しいテクノロジー」、「デベロッパーアドボケイト(エンジニア職)」そして「ダイバーシティ&インクルージョン」の5つについて学び続けることを実践してきました。簡単にその内容を紹介していきます。
1. 企業や組織の文化について
正直、入社してみないと分からないのが企業や組織の文化です。企業から社員に提供されている各種トレーニングを受講するのはもちろんのこと、正しい情報を得て正しい判断ができるようになるために、積極的な社内の情報収集や、個別に他部署の方々とランチやコーヒーブレイクにご一緒させていただきました。人事部やマネージャーからは得られにくい現場の実態や生の声を把握することができましたのはとても役に立ったと思います。入社して間も無い時期だと、同じチーム以外の人に自分からコンタクトして直接会って話すという行動は、かなり勇気がいるかもしれません。Facebookなどから誰かと繋がっている人であることが事前に分かれば「共通の友達」という共通点を持っていることからお誘いしやすい傾向はあるかと思いますが、「同じ会社に所属している」という共通点は最強だと考えているのでそこはあまり躊躇せずに行動してみました。と言いながらも、役職が上の方や心配な場合には、マネージャーや勤務年数が長くて繋がりを持たれている同僚に頼んで紹介をお願いしました。初めて自分からコンタクトする場合は、社内と言えどもマナー重視で「自己紹介」と合わせて「会いたい理由」「目的」「お相手のご都合の確認」等を敬語で書いたメールを送り、打診させていただきました。基本的にお断りされたことは一度もありませんでした。逆にタイミングが合わずまだお会いできてない方々がいらっしゃるので、来年スケジュールを仕切り直すところです。
また、SNSやコミュニティ活動などで「ワタシの知らないシリーズ」として、社外の方々にもぜひ知って欲しいと感じた素敵な企業の文化や出来事を投稿し続けてみたところ、思いの外、社内の方々から反響をいただき、追加情報を得ることができたり、社内外のネットワークが広がるきっかけに繋がりました。
[Point] 企業の歴史を学び、組織図と役員名を覚えることは大切です。年度が変わると組織が変更になる場合があるので、学び続ける必要があります。
2. 同僚やパートナー企業様、お客様との信頼関係の構築
前職を退職する際に意図的に「退職ブログ」を書かなかったこともあり、しばらくの間、社内では「出向ですか?」「契約いつまでですか?」と聞かれ、社外のコミュニティなどでも前職のイメージを引きずったまま会話が進んでしまうことがありました。この1年間を通じて、コミュニケーションを工夫したり、前職のロゴがついた持ち物の取り扱いなど小さな工夫を積み重ねてみました。IT業界16年目を向かえる転職回数を重ねている中堅どころのエンジニアともなると、ビジネスパーソンとしてあらゆる方々との信頼関係を構築するためには「企業への貢献」と「実績」だとしみじみ思いました。
[Point] 一般的に転職した職場でNGワードとされている「前職では〜」という言葉。前職の企業ブランド力が強いだけに、IT業界の代表的の話題や会話の中でもどうしても出てきてしまう傾向があるので、要注意だと実感しました。
3. 自社製品やサービス関係する新しいテクノロジー
社内用語や自社製品特有のIT用語、とくに3文字単語のオンパレードに慣れるために、単語帳を作りました。パブリッククラウドのエンジニアとして、OSSやテクノロジーのトレンドを理解しつつ、自分でも手を動かす機会を増やしました。新しいテクノロジーは勤務年数に関係なく、誰もが学習が必要になります。チームや他部署のエンジニアと一緒にもくもく会をしたり、ハッカソンなどで新しいテクノジーを参加者と一緒に使ってみることで学習を主体に楽しめる環境を作り、時には追い込みをかけながらスキルアップを現在進行形で継続しています。
また、企業買収により、コンテナ領域もメイン担当することになり、さらにモチベーションを向上しながら励んでいます。グローバルのIT企業の良いところは、国内で相談できるエンジニアが不明確だったり不在の場合に、時差はありますが世界中に散らばっているエンジニアと相談したい時にいつでも繋がれることです。昔から「バグの女王」と呼ばれた経験があるくらい、とにかくバグに遭遇する確率が高く、その度に一つ一つ丁寧に対応していくことで原因究明や回避策を学びながらサポートやローカライズチームとも連携をはかることができました。
[Point] テクノロジーとの出会いも運命のようなところがあるので、担当することになった製品やサービスは、ありのまま愛してあげることです。
4. デベロッパーアドボケイト(エンジニア職)
今年11月に出版した「DevRel (Developer Relations) エンジニアフレンドリーになるための3C - 翔泳社」書籍の中でもご紹介させていただいている通り、「デベロッパーアドボケイト」という仕事はエンジニア職の中でも3つのC、Code: テクニカルなスキルはもちろんのこと、Contents: コンテンツの制作や情報発信、Community: テック系コミュニティに貢献していくためのスキルやセンスが求められる特殊な仕事です。ワタシにとっては、「開発者をヒーローにする」ことをミッションにし、テクニカルにDevRelを推進する組織に所属したいという強い意思を持ち続け、探し求めてたどり着いたポジションです。テクニカルエバンジェリスト時代に成し遂げることができなかった事を実行しよう、自分が出来ることを一つ一つ増やして行こう、自分たちの未来を描こう、という新たな気持ちで取り組みました。また、特定の専門分野で活動するエンジニアではなく、あらゆるエンジニア職の方々と会話ができるように様々なテクノロジーを網羅できるデベロッパーアドボケイトを目指し、自社のテクノロジーの学習だけでなく、自腹を切ってアメリカのシアトルに約2週間ほど滞在してマイクロソフト主催の開発者向けカンファレンスMicrosoft Build 2019への参加、最新Mixed Realityのトレーニング受講、全国のコミュニティへの参加や登壇のための事前準備、書籍執筆などなどを通じて多くの学習活動を並行して進めました。
[Point] 過去の成功体験にしがみついていては次に進むことはできません。「今」を変える自分の力を信じて失敗を恐れずに前進するのみです。
5. ダイバーシティ&インクルージョン
多くの外資系企業では、ダイバーシティ&インクルージョンのトレーニングが提供されていたり、定期的に関連イベントを開催していることと思います。企業によってユニークな取り組みが行われているため、入社前からチェックはしていたのですが、実際に社内イベントに参加してみるとこれまでに経験したことのない世界が広がっていました。今年は入社歴が短い社員として社内イベントに登壇する機会にも恵まれ、普段接する機会がない方々とも関わりを持つことができました。何よりも経験豊富な技術理事を務める女性との出会いは衝撃的でした。
[Point] ダイバーシティ&インクルージョンは、男女問わず強く活気のある組織を作る上で鍵を握っています。転職したら早いタイミングで一度はイベントに参加したり、ダイバーシティ&インクルージョンについて話ができる人を見つけておくと良いと思います。とくに女性エンジニアの場合は、困った際に道しるべをスムーズに得られるかもしれません。
自己反省していること
結論から書くと、個人のスキルよりも協調性やチームワークを尊重し過ぎると、「動けない自分」を作ってしまうケースがあることを学びました。新しい職場に早く溶け込むために、疑問に思うことはどんどん声を出し、上記でも紹介したように自ら学ぶ姿勢で新しい環境の中、数々の挑戦に挑んでみましたが、改めて1年間を振り返ると、どこか 遠慮がち になっていた自分と アンコンシャス・バイアス (無意識の偏見) による正しくない理解や思い込みが自分を支配していたケースが発生していた事に気づきました。
エンジニア組織における「チームワーク」に貢献できること
これまでに国内外のIT企業でエンジニア職に従事し、共通して学んだことは「チームワーク」は、チームリーダーによる適切な働きかけにより、チーム内でチームワーク意識が浸透し、モチベーションがある中で生まれるということです。 その上で、チームワークを形成する上で各メンバーが貢献できる具体的なタスク例をいくつか挙げると、日頃の情報共有の徹底や、お互いに技術的なサポート、個別のミーティング設定、外資系の場合、日本語での議事録やレポート作成などなどが考えられます。テクニカルなタスクもあれば、必ずしもそうではないものも混在します。いづれも多少なりとも負荷が発生するため、人によってタイミングやスキルによってすぐに対応な可能な人と、そうではない人が必然的に生まれます。議事録などのように、その場に居る人であれば誰でも対応可能なタスクは公平性を保つために持ち回りでできるのがベストだと考えていますが、組織によっては役職や勤務年数によって割り振られているケースもあるかと思います。 転職後は、人によっては「いち早くチームに貢献したい」、という気持ちの焦りや強い意思から、自分が対応できそうなことを一気に引き受けてしまう傾向があるかと思います。ワタシの場合も、「とにかく自ら動けるだけ動く」ことを通じて貢献すると同時に学びを一気に加速させようとしたところ、本来の自分タスクとのバランス維持のため、自分のアプローチ方法やプロセスの見直しを何度も繰り返す場面がありました。また、そうした考えとは相反してテクニカルエバンジェリストやアドボケイトといった技術を広める活動を担うエンジニア職の特有の考え方かもしれないのですが、キャラ被りを避け、周りの様子を見ながら時折、シニアな自分は目立たないようにと振舞っていました。
結論
「チームワーク意識」は、そのチームの役割が企業にどのような価値をもたらすのかによって熱量や期待値は大きく変わるように思います。転職1年目は、異なる文化に自分を置くわけなので同調圧力の不安が脳裏を横切ったとしても、自分の意見やリクエストを表明できるチームに所属しているのであれば、チームの一員としてコミュニケーションしながら適切なタイミングで「相談する」「頼めることは頼む」あとは「アンコンシャス・バイアス(無意識の偏見)が発生しないように務める」ことで、さらにパワフルな新しい道が拓けるのではないかと思います。
職場でこれまでに培った能力を、自分らしくさらに発揮することができるように、FY20に向けての準備はもう着々と始まっています。今後も感謝の気持ちを忘れることなく、一層ステップアップを目指して参ります。これからも叱咤激励、応援の程よろしくお願いします。
Have A Happy Life♪
※Twitterで最新情報発信中 @ayatokura
【参加レポート】OpenShift.Run 2019 に参加して学んだこと 〜Operator 101〜
皆さん、こんにちは。職業「戸倉彩」です。
2019年12月20日(金)、東京・恵比寿のEBiS303にてOpenShiftにフォーカスしたOpenShift Community Japan主催の「OpenShift.Run 2019」イベントが開催されました。
今回は参加レポートと合わせて、ワタシの中でとても印象に残ったKubernetesの自動化の決め手となる「Operator 101」セッション内容について紹介していきたいと思います。
OpenShift Japan Communityとは
OpenShift Community Japanは、Red Hat社の有志メンバーとOpenShiftを実際に利用しているユーザーによって成り立っているテック系のコミュニティグループです。これまでにOpenShiftを軸に、関連するテクノロジーについても学べるOpenShift Meetupイベント(サテライト含む)を東京、大阪、名古屋、福岡で開催しています。常に運営メンバーも募集しているようなので、もし興味がある人は問い合わせしてみてください。
- OpenShift Japan Community- connpass
2019年12月22日現在、メンバー登録数: 861名。過去に開催されたOpenShift Meetupで発表された資料も公開されているので誰でも閲覧することができます。 - OpenShift Japan Community - Twitter
定期的にOpenShiftに関する情報発信やイベント開催時には現地からの実況中継が行われています。
OpenShift.Run 2019 とは
OpenShift Community Japanが主催し、企業スポンサーやメディアスポンサーによる協力によって開催されたコミュニティイベントです。「Red Hat OpenShift(以下、OpenShift)」について、最近知ったという人から本番環境でフル活用しているユーザー、パートナー、顧客、コントリビューターが集まって学びやネットワーキングする場が提供されました。過去に開催されたOpenShift Meetupと比べると400名規模という比較的大きなイベントであり、イベント特設サイトも設置されました。
https://www.openshift.run
イベントに参加した理由
近年、コンテナプラットフォームに関心を持ち始めたことをきっかけに、コミュニティベースでの学習活動を進めてみたいと考え、実は以前から何度もOpenShift Community Japanが主催するイベントへの参加を試みていたのですが、日程的になかなかタイミングが合わず、やっと今回は時間を確保して参加することができました。 また現在、所属している企業がRed Hat社の買収が2019年7月に完了したことで、IBM Cloudで提供されているテクノロジーを拡めるお仕事を担うデベロッパーアドボケイトとして、Kubernetesに加えてOpenShfitについても担当することになりました。すでに「IBM Developer Dojo」 を通じてエンジニアの方々に「OpenShift(Minishift)入門コース」や「OpenShift on IBM Cloud + AI入門コース」という座学形式(前半)とワークショップ形式(後半)を組み合わせてOpenShiftを実際に体験していただけるイベントの企画から当日の講師までを務めていますが、OpenShiftを活用するために押さえておきたいテクノロジー範囲は広いだけでなく、Kubernetesにおいてはリリース頻度が高いため、自分自身も効率的かつスピーディーに学習しなければいけないと感じています。
当日のイベント全体の流れ
一部、セッションの順番の入れ替えはありましたが、基本的にはサイトに公開されていたEvent Timetableに沿ってイベントは進められました。
13:00-13:30 Registration
初めて訪れたEBiS303は、JR恵比寿駅から徒歩3分の好立地にあり、建物に入って正面のエスカレータで登るだけでスムーズに3Fイベントホールに辿りつくことができました。時間通りにイベント受付が始まり、GUESTバッチを受け取って会場内に入るとあっという間に席が埋まっていきました。
おそらく、イベント告知のタイミングで「来場者先着プレゼント Red Hat OpenShift 4 入門 小冊子」が用意されていることを知った多くの参加者は早めに会場入りしたと思われます。席はすべて3人掛けのテーブルでしたが、真ん中席でも落ち着いてパソコンやノートでメモを取りやすいスペースが確保されていました。
13:50-13:50 Welcome to OpenShift.Run
オープニングの動画が流れ、Shingo Katayama氏によってOpenShift Japan Communityの紹介が行われました。コミュニティメンバー800名突破!とのことでお祝いムードに包まれましたが、先ほどconnpassを確認したところ861名になっており、メンバーが増加傾向にあることが伺えます。
OpenShift Japan Communityは、グローバルで展開されているOpenShift Commonsとは別に、国内で独立したかたちでコミュニティ活動を実施しているとのことです。
OpenShiftのオンライン学習コンテンツ
OpenShiftの学習環境として、OpenShift環境の構築をしなくてもブラウザからすぐにOpenShiftを体感できる「OpenShift: Interactive Learning Portal」サイトを案内していました。コンテンツはすべて英語のみとなりますが、登録不要で、手軽にOpenShfitを無料で試したり学ぶことができるサービスです。サイトにアクセスすると今日現在は下記の6つのメニューが表示され、「START COURSE」ボタンをクリックするとそれぞれのシナリオ別にお好みでどれからでも始められます。学習段階に合わせて無理なくスキルアップできるコンテンツなので、ワタシも少しづつ制覇していきたいと思います。
各コンテンツが開始されると、左側に操作手順書、右上にKatakodaエディタ、右下にターミナル(bash)の構成で画面が表示されます。画面を閉じると操作した内容はすべて消えてしまう仕様になっていますので、検証などで行いたい場合には注意が必要ですが、バージョンごとに色々試せそうな「OpenShift Playground」は重宝しそうです。
- Foundations of OpenShift
- Getting Started with OpenShift for Developers
- Logging in to an OpenShift Cluster
- Developing with odo
- Deploying Applications From Images
- Deploying Applications From Source
- Using the CLI to Manage Resource Objects
- Connecting to a Database Using Port Forwarding
- Transferring Files in and out of Containers
- Exploring and using metrics and HPAs
- Introduction to Federated Clusters with Kubefed
- Introduction to GitOps with OpenShift
- Multi-cluster GitOps with OpenShift
- Foundations of OpenShift
- Developing with Quarkus
- Eclipse Vert.x deployment
- Spring and Spring Boot development
- Java EE 8 Development
- Application Messaging with OpenShift
- Thorntail development
- Red Hat Data Grid development
- Node.js development
- JBoss BRMS Loan Application demo
- Red Hat Decision Manager Loan Application demo
- Red Hat Decision Manager DMN Introduction
- Java EE Batch Processing with OpenShift, WildFly & JBeret
- Debezium deployment
- Hello! Fuse - Getting Started
- Subsystems, Components, and Internals
- Linux Container Internals 2.0 - Lab 1: Introduction to Containers
- Linux Container Internals 2.0 - Lab 2: Container Images
- Linux Container Internals 2.0 - Lab 3: Container Registries
- Linux Container Internals 2.0 - Lab 4: Container Hosts
- Linux Container Internals 2.0 - Lab 5: Container Orchestration
- Linux Container Internals 2.0 - Lab 6: Container Standards
- Linux Container Internals 2.0 - Lab 6: Container Tools Ecosystem
- OpenShift Playgrounds
- OpenShift 3.6 Playground
- OpenShift 3.11 Playground
- OpenShift 4.2 Playground
- Service Mesh Workshop with Istio
- Istio 1.0.x workshop: Istio Introduction
- Istio 1.0.x workshop: Deploy microservices
- Istio 1.0.x workshop: Monitoring and Tracing
- Istio 1.0.x workshop: Simple Routing
- Istio 1.0.x workshop: Advanced RouteRules
- Istio 1.0.x workshop: Fault Injection
- Istio 1.0.x workshop: Circuit Breaker
- Istio 1.0.x workshop: Egress
- Istio 1.0.x Advanced: Observing with Kiali
- Istio 1.0.x Advanced: Mutual TLS
- Building Operators on OpenShift
- Kubernetes API Fundamentals
- Etcd Operator
- Operator SDK with Go
- Operator Lifecycle Manager
- Ansible Refresher
- Ansible Kubernetes Modules
- Ansible Operator Overview
- Mcrouter Operator powered by Ansible Operator
- Operator SDK with Helm
13:50-14:30 Operatorに手足をつっこんでみようか。レッツエンジョイ
★公開セッション資料はこちら
最初のセッションは、「転職してKubernetesの国にきました」と語るKazufumi Saito氏によるOperatorの開発・実行・管理について役立てるオープンソースのOperator Frameworkに関する「Operator 101」セッションでした。詳しい内容について、後ほど紹介いたします。
14:30-15:10 Machine Config Operatorのちょっとイイかもしれない話
★公開セッション資料はこちら
セッション発表の裏でリアルにOpenShift 4.2を構築してみます!と勝負に出たToshihiro Araki氏。OpenShift環境において、CoreOSに対しKubernetesネイティブな構成(宣言型)を提供する「Machine Config Operator(MCO)」について、yamlファイルの記述例やコマンドを交えて解説していました。
OpenShift 4は、Operatorフォーカスのプラットフォームであり、MCOはそれをオペレーションシステム自体にまで拡張し、カーネルとkubelet間のすべてに対する更新や構成変更を管理することが可能になりました。
MCOには下記のようなコンポーネントが存在し、それらに基づいてOpenShift環境下のCoreOSノードに対する管理操作を自動的に行えるので、人の手を介さないPOD管理と同じように自動化の美しい世界が広がります。
・ machine-config-operator: ノード設定に関する機能とCRDを提供するOperator
・ machine-config-server: OCPクラスタへのノード追加時にignitionを提供
・ machine-config-controller: 宣言型のアップグレードメカニズムの調整機能を提供
・ machine-config-daemon: マシン設定アップデートとその検証を提供
一方で、現状は完全に人手によるシステム管理に置き換わるものではないため、OpenShiftをオートスケールなどの恩恵が受けられるクラウド(IaaS)上に構築し、MCOの仕組みを組み合わせることでエンジニアが苦労するシステム運用負荷が高まった際などの無理ゲーに即効性のある一つの解決策として一歩前進しますねという話でした。
最後に、AWS上にOpenShiftが33分で正常にインストールされたことを確認して、こちらのセッションは無事に終了しました。
15:30-16:10 マイクロサービスの開発に疲れる前にdaprを使おう!
★公開セッション資料はこちら
OpenShift.Run 2019の前半戦はインフラ寄りの話が中心でしたが、ここからはアプリ側の話をするセッションが投入されました。
初期の頃からOpenShiftを触っている経験豊富なKei Omizu氏による最近発表されたMicrosoftのマイクロサービスアプリケーションの開発を容易にする「dapr(Distributed Application Runtime)/読み方:ダパー」に関するセッションは、限られた時間でテンポよくVisual Studio Codeを使ったデモも交えて行われました。daprをKubernetes上で利用する場合、dapr自身がコンテナとして実行され、HTTP/gRPC API経由で呼び出して利用できるとのことです。daprはistioに似て非なるもので、ステート管理ができることがエンジニアさんから評価されるポイントの一つに。セッション最後に電卓の足し算(Go)、掛け算(Python)、割り算(Node Express)、引き算(.Net Core)の各ボタンが異なる言語/フレームワークで書かれた別モジュールで構成されている電卓アプリケーションを使った分散トレーシングについて紹介していたのが面白かったです。
daprの公式サイトはこちら
最後にデモしていたKubernetes分散電卓のソースコードはこちら
16:10-16:50 「詰める」と「散らす」の動力学: 原理・原則から理解するコンテナ配置戦略
★公開セッションはこちら ネコ耳スタイルで登場したチェシャ猫がイベントのムードをさらに盛りあげていました。 Kubernetesをデプロイした際に配置されるNodeが「よしなに」決まる件について、よしなにの中身を詳しく解説していくセッションで、Kubernetesの働きについて勉強になりました。
Operator 101セッションで学んだこと
ここからは最初のセッションの話に戻り、もう少し詳しい内容についてお伝えしていきます。 「Are you happy with Kubernetes?」「Kubernetesが好きな人いますか?」 Kubernetesが登場してから、学習コストが高く、実際の運用管理には専門的なナレッジやノウハウが無いと厳しいと感じている方が多いのではないでしょうか。ワタシ自身もそのように感じていますが、クラウドネイティブを加速させる上で、直面しているインフラや開発現場の多くの問題はコンテナ技術によって解決されており、「今」こそ注力して取り扱うテクノロジーであると信じています。セッション始めの問いに会場にいた参加者は興味深く聞き入っていました。
Red Hat社員も語るKubernetesの保守の難しさ
セッションの中で、2018年6月に海外で公開された「Why running your own Kubernetes deployment could be a terrible idea」記事に掲載されたRed Hat社のAshesh Badani氏による「Kubernetesは偉大な基礎技術ですが、ストレージ、ネットワーキング、セキュリティ、アプリケーションフレームワークなどを統合し、それを四半期ごとに更新し続けることは大きな負担です」というコメントが紹介されました。Kubernetesを取り扱う現場のエンジニアたちが感じていることと共通の認識であることが伺えました。
Kubernetesのキホン
Kubernetesは、「マニフェスト(あるべき姿)の宣言」によってクラスタ内の多数のコンテナのデプロイやスケーリング、ルーティングなどの運用管理を担うことでサービス維持を実現します。 これを支えているのが「Control Loop (Reconciliation Loop)」です。「Analyze(あるべき状態と現在の状態を比較)」→「Act(あるべき状態になるように処理)」→「Observe(現在の状態を観測)」を繰り返すことによって維持し続けるのが動作の基本になります。
保守を担当するコンテナ「Operator」のススメ
そこで、Kubernetesの拡張機能であるOperator(読み方:オペレーター)がキーになります。etcdの保守を例に、もしOperatorがなく、人がオペレーションを実行する場合を見ていきましょう。
Operatorがある場合は、どうでしょうか。
明らかに自動化により操作する人にとってメリットが大きいことを直感でお分かりいただけましたでしょうか。では、Operatorを利用するためにはどうしたら良いのでしょうか?答えは2つあります。1つは、「創る」です。その創るために、再び英語ドキュメント読んだり調べ物が増えて大変そうと思われるかもしれませんが、すでにコミュニティの方々によって日本語の参考になるコンテンツは用意されているようなので活用しましょう!
- Kubernetes Operatorで実現するNoOpsの世界 - Shunya Murata / Kazuki Suda
- Kubernetes Operator開発ツールの比較表や、ゼロから作るKubernetes Operatorの定義(CustomResourceDefinitions/CRD)について丁寧に解説されています。Yahoo! JAPANのKubernetes Cluster Operatorの実例や実装ノウハウ、学びも含まれているので、実案件対応などに迫られている人は参考になると思います。
- 実践Kubernetesカスタムコントローラの道 - バルゴ
- オンライン販売されているKubernetesでControllerがどのように動いているか理解したい人や自分でも実装したい人を対象に書かれた物理本です。この書籍を読めばKubernetesのControllerの動作原理を理解でき、SDKであるKubebuilderやOperator SDKを使ったサンプルOperatorの実装ができるようになりそうです。
「Operator開発の大まかな流れ」としては、次の5つのステップになります。 1. Operator SDKで雛形生成 2. 新規CRD追加 3. 新規Controller追加 4. Operator Podをビルド・デプロイ 5. CRを追加・適用
もう一つの答えは「活用する」です。特にミドルウェアについては必ずしも創る必要はありません。現在、Operatorを介して新たなISVの世界が広がっていることも知っておくと良いでしょう。
OperatorHub.ioサイトにアクセスすると、Kubernetesコミュニティで開発されている豊富なOperator対応製品が登録または取得が可能です。先ほど実際にアクセスしてみたところ、Red Hat、Microsoft、Google、IBMも!などの企業やコミュニティによる95アイテムが登録されてました。
他にもセッションでは、Operatorライフサイクルなど追加情報について紹介されていましたが今回は割愛させていただきます。106ページの公開されたセッションスライドはOperatorをはじめたい人必見です!!!
※改めてリンク貼っておきます。
Operator 101 〜Operatorに手足をつっこんでみようか。レッツエンジョイ〜 - Kazufumi Saito
)
Operator 101のまとめ
Operatorを押さえておき、創る/使うことによって、Kubernetesの能力であらゆるもの(インフラ、k8s、ミドルウェア+アプリケーション)を自動化できます!みんなで手足をつっこんで使っていきましょう!!
セッションの中でもエンジニアの味方になってくれるテクノロジーであることを強調するかたちで何度も表示されたスライドでした。
来年もOpenShift Japan Communityによるイベントが開催されるようです。最新情報はconnpassまたはTwitterでご確認ください。これからも新しいニーズに対応しながら進化し続けるOpenShiftについて一緒に学び、語り合いましょう!
Have a nice Geek Life♪
※Twitterで最新情報配信中 @ayatokura
【IBM Watson】AIが性格を推定してくれるPersonality Insigthtsデモサイトの構築方法 (Node.js編)
皆さん、こんにちは。職業「戸倉彩」です。
今回は今すぐ使えるIBM Watson Personality Insights APIのサービスを使用した、テキストやTwitterのツイートを分析するWebアプリケーションを開発する方法を紹介します。パブリッククラウドのサービスを使用しますが、無料の範囲で作成することができるので、自己学習やコミュニティのハンズオン等の題材に迷った時には役立てていただければと思います。
IBM Watson Personality Insights (性格分析)とは
Personality Insightsは、IBMが提供しているIBM Watsonサービスの一つで、テキストから筆者のパーソナリティ(ビッグ・ファイブ、価値、ニーズ)の3つの特徴をAIから推測します。詳細についてはIBM Watson Personality Insights 公式サイトをご覧ください。
Personality Insightsデモサイトとは
IBM Watson Personality Insightsが使われているデモサイトがこちらに公開されています。リアルタイムに「サンプルのTwitterアカウント」、「テキスト入力」、「ご自身のTwitterからツイートされたテキスト」による分析を体験できます。
デモのために設置されているサイトのため、アクセスが集中した場合やメンテナンス時には正常に動作しない可能性もあるようです。 GitHubにソースコードが公開されていますので、macOSやWindowsのパソコンをお持ちの方であればいつでも誰でも入手して、自分でデモサイトを手元の環境に構築して動かすことができます。また、Apache 2.0ライセンスで配布しているため、商用利用も可能です。 万が一、ソースコードに問題があることを発見した場合には、直接GitHubのリポジトリにIssueをあげて報告をしてください。
始める前に
1. Node.jsのインストール
Node.js公式サイトから入手できます。2019年12月27日現在、12.14.0 LTSが推奨版となっています。
2. IBM Cloudのアカウントの取得
IBM Cloud上で提供されているIBM Watson Personality Insightsのサービスを使用するため、ライトアカウント/従量課金(PayG)アカウント/サブスクリプションアカウントのいづれかのアカウントが必要です。これからIBM Cloudを始める場合は、過去にQiitaに投稿した「無料ではじめられるライト・アカウント登録方法」をご覧いただき、アカウントの登録を行なってみてください。
3. IBM Cloud CLIのインストール (IBM CloudにWebサイトを公開する場合)
下記のコマンドを実行して、IBM Cloud CLIのインストールを行います。
curl -sL https://ibm.biz/idt-installer | bash
- Windowsの場合、 管理者としてPowerShellで次のコマンドを実行します。
[Net.ServicePointManager]::SecurityProtocol = "Tls12"; iex(New-Object Net.WebClient).DownloadString('https://ibm.biz/idt-win-installer')
4. Twitterアカウントのログイン情報の取得
特定のTwitterアカウントでツイートされた内容を分析させたい場合は、対象となるアカウントのログイン情報を入手する。 もし、これからTwitterアカウントを取得したい場合には、下記サイトよりTwitterアカウントを作成し、ツイートをはじめる。※100程度の単語からの分析が可能ですが、より正確な分析のためには、より多くのテキストが存在していることが望ましいです。 https://twitter.com/i/flow/signup
操作の手順
大まかな操作の流れは下記の4つになります。 1. Personality Insightsのサービス作成 2. GitHub上のリソースのクローン 3. 環境ファイルの設定 (.env) 4. Twitterアプリケーションの設定 5. ローカル実行
1. Personality Insightsのサービス作成
- WebブラウザからIBM Cloudにアクセスしてログインする。
- IBM Cloudダッシュボードから右上の[カタログ]メニューをクリックする。
- 左側メニューの[AI]をクリックする。
- 右側に表示されたAIカテゴリとして提供しているサービス一覧から[Personality Insights]を見つけてクリックする。
下記の項目を確認した後、右側の[サマリー]で設定した内容を確認して正しければ[作成]ボタンをクリックしてサービスを作成する。
地域の選択
- デフォルト[ダラス]のままでもOKです
- ドロップダウンメニューから[東京]も選択できます
- 料金プランの選択
- 今回は、[ライト(無料)]にチェックが入って選択されていることを確認してください
- 検証や実案件などで1ヶ月あたりに1,000件を超えるAPI呼び出しを行う場合には[ティア]または[プレミアム]を選択してください
- サービス名
- デフォルトのままでもOKですが、任意のサービス名をアルファベット、記号、数字の組み合わせで指定することが可能です。
- 今回の例では[PersonalityInsights-Japan]を指定してます。
6.しばらくして[リリース・リスト]ページが表示されたら、左側の[サービス資格情報]メニューをクリックする。 7. [サービス資格情報]に自動生成された[Auto-generated service credentials]の[資格情報の表示]リンクをクリックする。 8. 表示された資格情報の[apiey]および[url]は後ほど使うため、メモ帳などにコピーしておく。
2. GitHub上のリソースのクローン
ターミナルから下記コマンドを実行してGitHubからソースコードを入手する。
git clone https://github.com/watson-developer-cloud/personality-insights-nodejs.git
3. 環境ファイルの設定 (.env)
1.[personality-insights-nodejs]ディレクトリを移動する。
cd personality-insights-nodejs/
2.エディタでフォルダの中身を開いて .env.example ファイルを .env というファイル名でコピーを作成する。 3. .env ファイルを開き、前の手順で取得したサービス資格情報を追加し、ファイルを保存する。
PERSONALITY_INSIGHTS_IAM_APIKEY= ここにapikeyをコピペする PERSONALITY_INSIGHTS_URL= ここにurlをコピペする
4. Twitterアプリケーションの設定
- Twitter Developerサイトからアプリケーションを作成する。
コールバックURLを追加する。
ローカル環境の場合:
http://localhost:3000/auth/twitter/callback
- クラウド環境の場合: 各クラウドサービスの仕様を確認してURLを指定してください。
- IBM Cloud環境の場合:
<application-name>.mybluemix.net/auth/twitter/callback
3..env ファイルにTwitterアプリケーションの資格情報を追加し、ファイルを保存する。
TWITTER_CONSUMER_KEY=<consumer-key> TWITTER_CONSUMER_SECRET=<consumer-secret>
5. ローカル実行
- 下記のコマンドを実行して依存関係をインストールする。
npm install
2.アプリケーションを実行する
npm start
3.Webブラウザで localhost:3000
にアクセスする。
4. Personality Insightsデモサイトが表示されれば成功です!!!
指定したTwitterアカウントのツイートによるテキストから性格を分析したい場合には「あなたのTiwtterによる分析」ボタンをクリックして操作を行なってみてください。
このアプリケーションについて
このアプリケーションは、Node.jsで動くWebアプリケーションです。後は、お好みのクラウドサービス上にデプロイしたり、自由にカスタマイズしてご活用ください。
ディレクトリ構成
. ├── app.js // express entry point ├── config // express configuration │ ├── error-handler.js │ ├── express.js │ ├── i18n.js │ ├── passport.js │ └── security.js ├── helpers // utility modules │ ├── personality-insights.js │ └── twitter-helper.js ├── i18n // internationalization │ ├── en.json │ ├── es.json │ └── ja.json ├── manifest.yml ├── package.json ├── public │ ├── css │ ├── data // sample text and tweets │ ├── fonts │ ├── images │ └── js ├── router.js // express routes ├── server.js // application entry point ├── test └── views // ejs views
IBM Cloudを活用してWebサイトを公開する方法
- IBM Cloud CLI を用いてターミナルまたはコマンドラインからIBM Cloudにログインする。
※ログインの際に、APIエンドポイントや地域がus-southに指定されていても問題ありません。
ibmcloud login
2.下記のコマンドを実行してCloud Foundry (IBM CloudでWebサイトを手軽にホスティングすることができるサービス) をターゲットにします。
ibmcloud target --cf
3.manifest.ymlファイルの3行目のアプリケーション名の部分を編集し、ファイルを保存する。
例えば - name: my-app-name
など、ユニークな文字列を指定してください。Webサイトを公開する際にURLの一部になるため、ご注意ください。
4.アプリケーションをIBM Cloudにデプロイします。 ネットワーク環境により必要な時間は異なりますが、安定している環境の場合には数分〜で完了します。
ibmcloud app push
5.アプリケーションをデプロイしたURL (https://アプリ名.mybluemix.net) にアクセスして、公開されたことを確認します。
例えば https://personality-insights-qiitademo.mybluemix.net
今回はここまでです。お疲れ様でした! Have a nice Geek Life♪
※Twitterで最新情報配信中 @ayatokura
待望のVS Code Meetup コミュニティはじめました
撮影: @szkn27
皆さん、こんにちは。職業「戸倉彩」です。
VS Codeファンの皆さま、 2019年12月18日(水)、記念すべき初めての「VS Code Meetup #1」をコミュニティ立ち上げイベントを開催いたしました!! すでに毎年恒例のQiita Visual Studio Code Advent Calendar 2019 - 18日目 に記事を公開させていただいてますが、アップデート情報も兼ねてこちらにも投稿させていただきます。
VS Code Meetup #1 イベント当日は、2015年4月29日にVS Codeが発表されてから、皆さんと一緒にVS Codeを大切に見守ってきた熱い想いを込めて「VS Code 変遷と今後の展望」セッションを発表させていただきました。
Hi @code team! at last VS Code Meetup in Japan #vscodejp launched with 10+ speakers 280+ attendees! we will accelerate more contribution from Japanese Developers. Let’s meet when you come to Japan🇯🇵 pic.twitter.com/esLdHwX5Pr
— Nori Suzuki (@szkn27) 2019年12月18日
VS Code Meetupとは
有志によって運営している強力かつ軽量なオープンソースのコードエディター「Visual Studio Code」のユーザーコミュニティです。ご興味のある方は、connpassでグループを作成しましたのでお気軽にご参加ください。今後は分科会や地方展開も検討したいと思いますので、お気軽に運営メンバーにお声がけください。
祝!2019年12月26日現在、登録メンバーが1,000名を突破しました!!
https://vscode.connpass.com/
エディタとは
皆さんはどのようにエディタと向き合っていますか?ワタシ自身は下記の3つが理想的なエディタだと考えています。 * 誰でもできる * どこでも使える * やりたいことに集中したい
エディタ選び
メールを読むためのツールやデバイスを選ぶのと同様に、エディタもシンプルに「お試しで使ってみて相性の良いもの」を見つけて利用するのが良いと思います。コードを書く人は、キーボードを利用したり、必要に応じて開発ツールをインストール環境が望ましいため、スマホやタブレットではなくデスクトップ環境で活用できるエディタを使ってみましょう。
ワタシがVS Codeをオススメし続ける理由
「初心者から経験者にも役立つ」ということに限ります。 ここでいう初心者というのは、エディタ自体はもちろんのこと、さまざまなテクノロジーの初学者の手助けになる拡張機能が豊富に用意されているVS Codeであれば、心が折れそうになりがちな不得意分野のテクノロジーとも前向きに取り組むことを小難しい設定などを介さずに支援してくれます。
気になる日本語化について
2015年から変わらない...VS Codeの日本語化問題について。 VS Code自体は日本語で利用することが可能です。しかしながら、VS Codeに関する最新情報や技術情報は基本的に英語で提供されています。現時点では、これらは日本語になる予定が明らかになっていないため、コミュニティを通じて皆さんと一緒に改善していければと考えています。まずは日本語情報は #vscodejp ハッシュタグをつけて情報発信していただけると幸いです。 * 公式サイト https://code.visualstudio.com/ * 公式Twitterアカウント @code * リリースノート https://code.visualstudio.com/updates/
VS Code快適生活でいろいろ振り返る
日本語の公式情報が限られている中、ワタシはVS Codeを活用して学んだことをシェアするプラットフォームとして技術評論社の月刊誌「Software Design」 に 「VS Code快適生活」 連載記事を寄稿することを選びました。毎月バージョンアップが行われるVS Codeを題材に、新機能や動向について情報をまとめていくのは必ずしも容易ではありませんが、たくさんの読者の方々、そして出版関係者の方々に応援いただき、今でも継続させていただいています。毎月、技術雑誌とは思えないくらいキュートな猫が愛らしいポーズで表紙を飾っており、ついつい表紙買いしたくなるエンジニアさんもいるとか、いないとか。
2019年で印象に残った機能は下記の通りです。 * Visual Studio Live Share (リアルタイムの共同開発) * Visual Studio Online * Visual Studio IntelliCode (AI支援付き開発機能) * リモート開発機能(SSH/Windows Subsystem for Linux/Containers) * Visual Studio Codeアイコン変更
アナタにオススメのVS Code
さてさて、皆さんのパソコンにインストールされているVS Codeは何色ですか?VS CodeにはいろいろなBuildが存在しています。ここでは代表的なものを紹介しておきます。それぞれ同じマシンに同居させることが可能なので、目的に応じてお好みでインストールして利用してみてください。VS Codeアイコンのロゴの色で各Buildを区別しやすいようになっていますので、Dockなどにアイコンが並んだ時に視覚的にも分かりやすく、間違えて操作することが防げます。 * VS Code Stable Build マイクロソフトのVS Code 公式サイトから提供されている定番の安定版 (青色のVS Codeアイコン) * VS Code Insiders Build 一歩先に機能を試したい場合のベータ版。こちらもマイクロソフトのVS Code Insiders ダウンロードサイトから入手可。 (緑色のVS Codeアイコン) * VS Code Exploration Build 最新Electronを搭載したさらに一歩先に機能を試したい場合の探検版 (オレンジ色のVS Codeアイコン) * VS Code - OSS オレオレVS Codeをビルドしたい方にオススメのOSS版。GitHubのVS Code リポジトリに丸っとソースコードが公開されています。 (独自アイコン)
クリスマスシーズンの「今」限定の機能ご紹介 ←本当にその時の「今」限定になってしまいました
クリスマスシーズンに突入しました。VS Codeチームは今年も期待通りにクリスマス気分を味わえるスペシャル機能を私たちにプレゼントしてくれました!ぜひお試しください。そして周りに知らない方がいたら、教えてあげてください。 1. VS Code Insiders版をダウンロードする。すでにダウンロード済みの人は最新バージョンにアップデートする。 2. VS Code Insidersを起動し、画面左下の「管理」アイコンをチェックする。クリスマス仕様になっていたらOK。 3. 「管理」アイコンをクリックしてメニューから「Happy Holidays!」を選択する。 4. VS Code画面いっぱいに白い雪が降ってきます。
🆕ホリデーシーズンの「今」限定の機能ご紹介
気を取り直して、2019年12月26日現在、VS Code Insiders(バージョン1.42.0)で提供されているBuildでも画面左下の「管理」アイコンは通常通りの仕様のまま、メニューから「Happy Holidays!」を選択することができます。おそらく年明けに配布されるBuildでは、この機能は消えてしまうと思いますので手元でしばらく楽しみたい方は、VS Code Stable版をメインに利用し、Insiders版は最新バージョンに更新しないのが良いかもしれません。
VS Code Meetup #1 ご参加ありがとうございました!
イベント当日はオンラインおよびオフラインで約300名規模の方々にご参加いただき、SNSも皆さまのご協力により大変盛り上がりました。どうも有難うございました。
@youtoyさんが 「VS Code Meetup #1 - 初回基礎編( #vscodejp )」 に関するつぶやきのまとめをしてくださいました。当日参加できなかった方、振り返りをされたい方は参考にしてください。
次回のイベント開催予定
VS Code Meetup #2 は2020年1月23日に開催予定です。運営メンバーおよび関係者一同で次回もご参加いただく方々に楽しんでいただけるようイベント準備を進めています。多数のご参加をお待ちしております。
またお会いしましょう! Have a nice Geek Life and Happy Holidays♪
※Twitterで最新情報配信中 @ayatokura
神様からの贈り物「DevRel エンジニアフレンドリーになるための3C」書籍
皆さん、こんにちは。職業「戸倉彩」です。
2019年11月15日。 国内でDevRelを牽引してきた中津川篤司さん、小島英揮さんと共著で、翔泳社より 「DevRel エンジニアフレンドリーになるための3C」 書籍を出版いたしました。
人生で商業誌を出版するのはこちらで2度目となります。
普段のテクニカルライター活動している月刊誌の連載技術記事とはまた異なり、試行錯誤の連続でした。 それはとても難産でした。
製本された見本誌が手元に届いた時には「生まれてきてありがとう」と心の中で叫びました。そして発売日当日。多くの方々に祝福されながら、読者様の手元へと書籍が届けられ始めました。
発売日から40日。
商業誌を一冊でも書いた経験のある方は、難産の末にやっと出版にこぎつけた書籍が、全国の書店の棚に1ヶ月以上も陳列されていることが奇跡だということを実感されたことがあるかもしれません。少しでも長く愛される書籍であって欲しいと願いながら。
今回は、「DevRel エンジニアフレンドリーになるための3C」書籍の出版に纏わるエピソードについて綴っていきます。
DevRelでデベロッパーの可能性を広げたい気持ちが原動力
これまで、DevRel Meetup in Tokyo コミュニティの登壇や同人誌の頒布などを通じて 「DevRelの始め方やコツ」 が分からずに悩んでいる企業やエンジニアの方々を支援してきました。中には、これからDevRelを盛り上げようとしているエンジニア仲間と個別に会議室に集まって対話を重ねながら、DevRelについてどのように所属先の上層部に理解してもらい、限られたリソースでどのようにパフォーマンスを引き出すことができるのかを議論し、最適な方法について何時間もディスカッションを行なったこともありました。
しかし、これまでのご依頼や出会いは100%、直接お会いしたことのある方々でした。
これは非常にありがたいことであり、信頼や期待を裏切れないという心地よいプレッシャーを感じながら、自分自身を前進させる力になりました。
一方で、国内で 「DevRel」 についてもっと多くの方々に伝え、DevRelを定着させるためには、より最適なアプローチを見つけ出す必要がありました。そこで知人の紹介で知り合った今回のDevRel書籍の編集をご担当いただいた大内孝子さんに相談し、自分の出した答えが「商業誌」でした。
次に、DevRelの魅力を伝えるには、独りよがりでないノウハウや情報を集約することが必要だと考えました。受け取り手を魅了しつつ、実践的な情報の充実を担うためには...。そこで、定評のある方々とのコラボレーションが欠かせないと判断したのです。日本で初めてDevRelに特化したビジネス展開されている中津川さんと、AWSのユーザーコミュニティをゼロから育て上げた小島さんにご快諾いただき、執筆活動がスタートしました。
共著と言えども書籍を出版するということは、熱量的にも情報量的にもセミナー数十本分のエネルギーが必要でした。現在、電子書籍も増えてきている中で、「紙の書籍」 で出すことの緊張感もありました。
DevRel執筆と技術啓蒙の共通点
原稿を書き進めていく中で、普段、デベロッパーアドボケイトとして開発者の方々に技術を伝える活動を行う際に求められる多くのことと共通しているのを感じました。ここからは、その中でも最も大切なことを5つに絞ってお伝えします。
1. ターゲットとの合意形成
優れた情報を発信しても、受け取り手がその情報を必要としていなければ、当然ながら心に響きません。狙うターゲットを明確化し、その層に分かりやすく伝わるメッセージを心がけました。また、一人でも多くの読者の方が、自分ごと化できるように工夫しました。
2. 学習
書籍を書くということは、学習に大きく寄与します。 頭の整理をしながらも、読んでもらうための視点を忘れずに取り組みました。この書籍を執筆している期間は約20冊以上の読書をしました。過去に役立った書籍を読み返したり、気になった書籍を購入して新たな自分の世界が広がりました。
3. 情熱
目の前の時間を3年5年先に置いて妄想を繰り返しながら「今」伝えるべきことを魂を込めて書き綴りました。また、自分のDevRelに対する情熱や考えを全力で共有することで、読者の方々に元気になっていただくと同時に、内容を理解していただいた後に「よし、やってみよう!」という意気込みを感じてもらえるように自分なりの文章力で表現しました。
4. 経験談を交える
国内のIT業界でテクニカルエバンジェリストやデベロッパーアドボケイトに従事した経験のある人は限られています。可能な限り、「あの時」どうだったのか、そして「今」どうなのか、という実体験を交えて解説するようにしました。
5. 感謝の気持ち
多くの方々にご支援ご協力いただきながら、皆さんに楽しみながらDevRelを学んでいただける内容を準備しました。1冊の書籍の販売にどれだけ多くの方が関わり、どれだけ多くの時間と情熱が注ぎ込まれているか計り知れません。感謝の気持ちでいっぱいです。
開かずの箱が空いた瞬間
前職でテクニカルエバンジェリストの看板を下ろし、最終出社日に会社に置いてあった荷物を約6年間の思い出と一緒にダンボール1箱に詰め込んで自宅に持ち帰りました。当時、会社の都合によりブロード(ターゲットリストではなく、全てのエンジニアのために活動すること)に対してDevRelを遂行できるポジションがクローズとなり、自分の役目を終えた満足感と喪失感を同時に感じていました。箱は閉じられたまま約1年の月日が経ちました。現職のデベロッパーアドボケイト活動の合間を縫って執筆したDevRel書籍の最終入稿が無事に終わり、それまで走り続けてきた心身が一気に解放されたかのように部屋の片付けを始めた、その時です。まるで開かずの扉が空いた瞬間のようでした。閉じられたままのダンボール箱を開けたたことで、当時のDevRelの相棒だった数々のキャラクターのノベルティや私物に再会し、やっとあの時に止まってしまった時間と気持ちから解き放たれた気持ちになりました。大きな変革には痛みを伴いますが、成長への道はその先にしかないのもまた事実であることを再確認しました。何よりも、DevRelができる場所を追い求め、極め続けていなければ、このタイミングで、この世に今回のDevRel書籍は生まれていなかったことでしょう。
最後に
「DevRel書籍で世の中にどんな影響を与えたいですか?」と聞かれたら、 「DevRelの道を進みやすくして、日本にイノベーションを起こすために企業とエンジニアが共創するためのエコシステムを推進していきたい。」と答えるでしょう。それは、とても意味があることだと考えています。 そのためには、皆さんのご支援が必要です。この記事を読まれているということは、恐らくDevRelに興味を持たれたりしているのではないでしょうか。ぜひ、周りに企業とエンジニアが共創するための手法「DevRel(Developer Relations)」を知らない方がいらっしゃったら伝えてください。そしてDevRelについて日本企業の事例も交えた先人の知恵と、未来へのヒントが詰まった「DevRel エンジニアフレンドリーになるための3C」書籍が存在していることをご紹介いただけるとありがたいです。
Have a happy DevRel Life♪
※Twitterで最新情報発信中 @ayatokura
Software Design誌の連載記事【Visual Studio Code快適生活】1周年を迎えました!
皆さん、こんにちは。職業「戸倉彩」です。
いつも「Software Design」(技術評論社)をご愛顧いただいている読者の皆さま、本当にありがとうございます。 おかげ様を持ちまして、9月18日発売の「Software Design 2019年10月号」で毎月連載させていただいている「Visual Studio Code快適生活」記事が12本目となりました!
ワタシは、外資系IT企業で会社員をしながら、プライベートでテクニカルライターをしています。当然「業務に影響しない範囲」で活動する必要があるため、休日や深夜のスキマ時間にパソコンに向かっています。今回は、「Visual Studio Code快適生活」の記事にかける想いについて少しお話します。
「Visual Studio Code」とは、マイクロソフトが提供しているmacOS、Windows、Linux対応の軽量なコードエディタです。
■Visual Studio Code公式サイト https://code.visualstudio.com/
「Software Design」という雑誌に出会ったのは、自分がIT業界を目指そうとしていた学生の頃です。当日は、まだインターネット上で公開されている技術情報は限られており、また多くの技術情報は日本語化されていませんでした。そんな時、日本語で丁寧に解説されている特集記事や様々な記事に技術的に助けてもらっただけでなく、当時の著者の方々のテクノロジーとの向き合い方や物事の捉え方など非常に感化されました。いつしか年月が過ぎ、IT業界でエンジニア職をしながら、あの頃の自分と同じように英語の壁や技術に困っている人を助けたい、と思うようになりました。
そんな中、何かに導かれるかのように「Visual Studio Code快適生活」の企画の話が持ち上がり、テクニカルライターとして未熟だったワタシは、まずは数ヶ月〜半年の期間を目処に、前職のマイクロソフトを退職してから初めて自社製品の紹介としてではなく、第三者の視点で「今のVisual Studio Code」をより多くの人に届けるために、月刊誌というプラットフォームで記事を書かせていただくことにしました。
正直、毎月毎月バージョンアップが行われ、しかも公式マニュアルもREADMEもすべて英語で展開されている「Visual Studio Code」を題材にした連載記事を毎月執筆することは容易ではありません。無論、書籍化の難易度が高いと言われている「Visual Studio Code」。読者アンケートや数多くの応援メッセージが励みとなり、また賛同してくださった仲間達と一緒に、連載も続けながら、2019年4月号では特集記事としてVisual Studio Codeの魅力や使いこなす方法が詰まった最新情報を世に送り出すことができました。奇跡的な1冊であり、ワタシの中では人生で最高の「Software Design」誌となりました。本当に嬉しくて、嬉しくて保存用、観賞用、布教用、補完用、記念用に5冊購入しました!
その後も、気づいたら普段コードを書いている開発者の方だけでなく、非エンジニアの方々にもエディタに触れてもらうことで自分の手から生まれる「新しい体験と感動」そして「オープンソースの世界」を感じてもらいたくて、Visual Studio Code愛と魂を込めて書くことが毎月の習慣のようになり、現在に至ります。
Visual Studio Codeの1年振り返りや、最新バージョンのVisual Studio Codeについて知りたい方は、是非これを機に「Software Design 2019年10月号」の「Visual Studio Code快適生活」をご購読いただけると幸いです。
これからも「自称Visual Studio Codeエバンジェリスト」ではありますが、「エディタを使って書く事からデジタルなモノづくりやコミュニケーションが始まる」ことの大切さを忘れずに、日本語での最新情報の発信、オープンソースへの貢献に尽力し、「エンジニアや開発者の方々と共に可能性を切り開いていきたい」と考えています。
今後とも「Visual Studio Code快適生活」をどうぞ宜しくお願いします。
p.s. 技術評論社の皆さま、この場をもちまして改めて多大なご支援をいただき感謝申し上げます。
Twitterよりもブログでエンジニアの戦闘力を上げる
皆さん、こんにちは。戸倉彩です。
新年度を迎えて新たな気持ちでスタートを切った方もたくさんおられると思います。
ワタシもよりパワフルに活動すべく、改めるべき自分の中のルールと向き合うことにしました。 それは、ワタシ自身が活用している 「SNS」 と 「ブログ」 についてです。
SNSとTwitterとブログの違い
本題に入る前に、少し言葉の定義を整理しておきたいと思います。
SNS とは
Social Networking Service の略で、ユーザーにとって自分と自分の世界について言葉やメディアを共有することで関係を深め、新しい繋がりを作るためのオンラインサービスです。
[参考] ソーシャル・ネットワーキング・サービス - Wikipedia
Twitterとは
Twitter社が運用管理しているSNSの一つで、Twitterアカウントを用いてTwitterのアプリケーションやWebサイトから最大140文字(日本語)で投稿し共有できるサービスです。企業から各業界のインフルエンサー、個人が利用しています。利用者のうち何割くらいがエンジニアかさだかではありませんが、日々、最新の技術情報ネタが飛び交い、開発者向けイベントやコミュニティなどが開催されると技術的な内容に関する投稿は日夜を問わず盛り上がりを見せ、IT用語やイベント名がハッシュタグがトレンド入りするケースも増えています。
* Twitterの月間アクティブユーザーは4,500万人規模だそうです。2019年2月にTwitter社は、デイリーアクティブユーザーに関するデータも含まれている「Q4 and Fiscal Year 2018 Letter to Shareholders | February 7, 2019 @TwitterIR」 を公開しました。
ブログとは
定期的に更新される日記やレポート記事が公開されているWebサイトのことです。
日本では、企業サイトの配下にその企業に所属しているエンジニア職の社員らがエンジニアブログやサポートブログを書いて公開しているケースも増えてきましたが、本業に関わらず技術的なブログを個人ブログまたはナレッジ共有サイトにブログ投稿する人も増えてきました。
[参考] ブログ - Wikipedia
なぜエンジニアにとってブログを書くことが重要なのか
ブログの語源は、Webサイト上に Log(記録) として残すための WebLog (読み方: ウェブログ) が略された単語になります。すなわち、「ブログ」 は個人の価値を高めて情報発信する場としてだけでなく、記録を兼ねているのです。実際にブログを書くということは、それなりの時間の確保と文章力、集中力が必要となりますが、自分と向き合ってアウトプットしたものが、Web上の記録として残るという意味でもあります。
エンジニアがブログを書くメリット
ここでは、3つの視点でエンジニアがブログを書いて公開することで得られる代表的なメリットについて考えてみました。
エンジニア成長編
✅ 自分の考えや意見をストーリーとして伝えられる能力を養う
✅ SNSから離れ自分と向き合うために集中する時間を作る
✅ 技術的なブログで学んだことを記録に残す
✅ ブログを書くために調べものや他の人と会話することもスキルアップの一部になる
✅ 自分の資産になる
対外編
✅ 自分が何者なのかを表現でき、セルフブランディングに繋がる
✅ デジタルコミュニケーションを楽しめる
✅ ネット上の誰かの役に立つ情報を共有できる
✅ ブログをきっかけに執筆や登壇などのユニークな機会を得られる
✅ プロフィールやレジュメなどでURLで自分のアウトプットを示しやすい
技術情報の共有編
✅ 技術スキルを向上するきっかけになる
✅ 個人の視点で会社で触っている技術について綴ることができるので一般ユーザーに伝わりやすい
✅ 会社で触っていない技術をテーマに挑戦することで、後々、仕事でも役立つことがある
✅ 自分が触れている技術を他の人やコミュニティに展開しやすくなる
✅ 技術的なナレッジや体験についてアウトプットを公開することはIT業界全体や社会貢献に繋がる
ワタシが考えるTwitterのメリットとデメリット
ワタシは気づいたことを手軽にスマホから投稿できるTwitterを好き好んで利用し、活用しているので、これからも続けたいと考えています。しかしながら、改めてTwitterへ費やしている労力や時間とのバランスは見直したいと考えています。大きな理由は、Twitterには致命的なデメリットがいくつか潜んでいるからです。
Twitterを活用する時のメリット
✅ 文字数の制限の中で伝えたいことをシンプルに表現できる
✅ ハッシュタグを活用しタイムリーに同じトピックで情報共有ができる
✅ 情報拡散力に優れている
✅ Twitterのフォロワーさんと一体感のあるコミュニケーションを楽しめる
Twitterを活用する時のデメリット
☑️ 文字数に制限があるため限られた表現に留められてしまう
☑️ ツイートした内容は流れしまう傾向がある
☑️ フォロワーの数でいろいろと判断されてしまうケースがある (良い意味でも悪い意味でも)
☑️ Twitterを利用していない、または苦手な人たちに届けたい情報を届けることが困難
☑️ 投稿内容や表現によってトラブルに発展するリスクがブログよりも高い
インターネットの恩恵を受け、ワタシ達はSNSを通じて個人が世界中に情報発信できる時代になりました。Twitterは依存性が強い部分もあるのでコントロールしつつ、「エンジニアとしてスキル、セルフブランディング、そして自分の将来性」を考えて、ブログを公開し、ブログを書き続けてみることで得られる効果は絶大であることを再認識すると共に、自戒を込めて皆さんにもお勧めしたいと思います。
★お知らせ★
DevRel Meetup in Tokyo コミュニティ仲間と一緒に、同人誌 「ブログを書こう: ブログを書く技術」 を出しました。深夜〜明け方に、Markdown 形式で Visual Studio Code を使って「Visual Studio Codeでブログを書こう」パートを書き上げました。はてなブログ や Qiita などに記事を Markdown 形式で書こうとしている方から、すでに書かれている方にも読んでいただけると嬉しいです。Kindle版はこちらからお求めいただくことができます。
Have a happy DevRel Life♪
※Twitterで最新情報発信中 @ayatokura