『元ヨワヨワエンジニアですが、Microsoft認定資格プログラムについて語っていいですか?』

見出し画像を拡大表示

『元ヨワヨワエンジニアですが、Microsoft認定資格プログラムについて語っていいですか?』

筆者のスペック紹介

阿部 真貴男(あべ まきお)
PPT入社後、DODAの検索システムの開発・保守を担当。大人数が関わるプロジェクトにて、検索技術や自然言語知識の土台を築く。
その後、現 技術統括部に異動。マネージャーの三澤さんの配下で難易度の高い技術を扱うシステムの開発を学ぶ。
現在は、DXソリューション統括部 NewITソリューション部に所属し、AI検索システムのPM・エンジニアとしてプロジェクト成功に向けて奮闘中。
休みの日は娘とサイクリングしたり、ボクシングの練習をしたり。

エンジニアブログを拡大表示

定期的に訪れるIT技術トレンドリセットでたちまちヨワヨワエンジニアに

コロナ禍で『全世界同時リセット』というワードが、度々注目されていますが、技術の世界では、度々『リセット』が起きています。

例えば、5〜6年前にトレンドだった言語・サービス・開発手法・開発環境・システム実行環境の半分は、現在使われていません。
そのときのトレンド技術だけに集中して勉強していると、その技術が使われなくなった途端にヨワヨワエンジニアになってしまいます。

この技術トレンドの転換期にプロジェクト管理の勉強に没頭していた私は、トレンド技術のキャッチアップに取り組んでいたメンバーとは埋められない経験の差が開き、たちまちヨワヨワエンジニアとなってしまいました。

ツヨツヨエンジニアに囲まれながら、ヨワヨワエンジニアがいかに価値を発揮していくかを模索する日々

自身がヨワヨワエンジニアになってしまった一方で、ツヨツヨエンジニアだらけのNewITソリューション部。いかに自分が価値発揮をしていくか模索する日々が始まりました。

コロナ禍によって、これまでのビジネスモデルや価値観が大きく変化し、余暇が増えたタイミングがあった方も多いのではないでしょうか?
私はこのタイミングで、世の中のトレンドとなっているITサービスの構造や裏側を学ぶようになりました。

そして、多くのITサービスにおいて、膨大なデータをいかに活用するかが、サービス成功の秘訣であることを知ったのです。検索技術や自然言語知識の土台を活かすチャンスにあふれていることに気がつきました。

元ヨワヨワエンジニアですが、Microsoft認定資格プログラムについて語っていいですか?

Microsoft認定資格プログラムとは?
Microsoft認定資格プログラム(Microsoft Certification Program, MCP)はマイクロソフトが実施する資格体系の名称です。

自身が最新の技術的な役割や要件に対応していることを示す資格で、開発者、管理者、ソリューション アーキテクト、データ エンジニア、データ サイエンティスト、データ アナリスト、AI エンジニア、DevOps エンジニア、セキュリティ エンジニア、機能コンサルタント等の職務ごとに認定パスがあります。

私はコロナ禍で余暇が増えたタイミングで『ソリューション アーキテクト』『データ アナリスト』『AI エンジニア』の基本的な資格から、上位資格までを取得しました。

基本的な資格から上位資格まで無料で知識を積める環境が公式で用意されており、基本レベルの資格の勉強時間は、それぞれ最短3日から最長で10日程でした。

勉強方法については無料で利用できる公式MicrosoftLearn( https://docs.microsoft.com/ja-jp/learn/ )のみで、特に参考書を買ったりなどはしていません。

何から手をつけていいかわからない方には、基本的な資格(Fundamentals)がおすすめです。
資格によっては、無料でオンラインセミナーを受講でき、受講後は受験料が免除されます。

DXソリューション統括部では、資格によっては上位資格でも『バウチャー制度』で受験料が免除になるケースがあります。さまざまなエンジニアが多くのMicrosoft認定資格にチャレンジしているので、勉強会・もくもく会をはじめとした資格取得のためのコミュニケーションがとても盛んです。そのため、勉強のモチベーションを常に高く保てます。

Microsoft認定資格のご利益

資格取得をしてもあまり業務で役に立たない説は、どの企業でも議論になると思いますが、私が受けたご利益を紹介したいと思います。

<勉強会/もくもく会をはじめとした資格取得のためのコミュニケーション>
勉強会・もくもく会をはじめとした資格取得のためのコミュニケーションを取れる環境があります。

普段一緒に仕事をしないエンジニアともコミュニケーションを取りながら、さまざまな“気づき”を得ることができます。
コミュニケーションの幅を広げることで、チームの垣根を超えた技術相談等が可能です。

Microsoft社でウェビナー・ハンズオンの講師を担当>
数々の資格取得やMicrosoft Azureのサービスを活用したシステム開発の実績を活かし、
Microsoft社でウェビナー・ハンズオンの講師を担当しています。

クラウドサービスにおける課題を瞬時に解決>
原因不明のシステム停止やエラー等、解決までに時間がかかる課題が定期的に発生しますが、解決のためのアプローチは一つではありません。
資格取得により得た多くの知見の中から、最適なアプローチを選択できます。

<顧客から信頼されるビジネスパートナーに>
顧客の前で結論を言い切ることはなかなか難しいことですが、十分な理論武装ができていれば、結論を言い切ることが可能になります。
これにより顧客から信頼されるビジネスパートナーになれるのです。

これらの沢山のご利益により、気がつけばヨワヨワエンジニアから『元ヨワヨワエンジニア』になることができちゃっているではありませんか。

●○●

パーソルP&Tでは幅広いポジションで積極的に採用中! 現在募集中の職種は以下から確認できます。

また、パーソルP&Tにご興味を持っていただけた方に、イベント開催情報やブログの更新情報をお届けいたします。いますぐの転職は考えていなくても少しでも興味があれば、SNSをフォローする感覚でご参加いただきたいです!

 

【エンジニアブログ】MaaSに携わっている&学びたいエンジニア向け 実践Tips満載、Qiitaブログを紹介します

こんにちは、パーソルプロセス&テクノロジー(以下、パーソルP&T) システムソリューション(以下、SSOL)事業部 中途採用グループです。

私たちのSSOL事業部ではお客様とともに新しい技術領域への取り組みを推進しております。今回記事を書いていただいた杉本さん、千葉さんが所属するモビリティソリューションデザインチームは、中でも「MaaS」領域におけるサービス開発を手がける、20代の若手中心のチームで、その取り組みや実践TipsをQiitaにて定期的にアウトプットしています。

本noteでは、どのメディアで何を、どのような想いで発信されているかを伺いました。ぜひご覧ください。

 

1. はじめに

はじめまして。パーソルプロセス&テクノロジー(以下、パーソルP&T)システムソリューション事業部、交通サービス部のモビリティソリューションデザインチーム所属の杉本・千葉です。

画像1を拡大表示

※ 杉本(写真上・中央)、千葉(写真下・左側)、他チームメンバー

私たちが所属するモビリティソリューションデザインチームは、ざっくりいうとモビリティ(ここでは移動手段全般)について、「移動の円滑化」や「促進」につなげるサービス開発などを手掛けており、MaaSに関わる取り組みを通して、社会課題を解決することをミッションとしています。

◆MaaSとは?
Mobility as a Serviceの略。マースと読みます。
簡単に言うと、ICT(情報通信技術)を活用して、シームレスな(途切れない)移動を提供することです。
たとえばお家から目的地まで、スマホひとつあれば予約も決済も乗車も簡単にできる、などのこと。
サイクルシェアやカーシェア、電動キックボードといったパーソナルモビリティなどが最近日本でも多くみられるようになりましたが、そういったものを使って、かつ組み合わせて、一つのサービスとして利用できることがMaaSとなります。

 

※以前投稿したMaaSそのものをご紹介するnote記事はこちらから。
MaaS が着目されている背景、日本におけるMaaSの特徴やプレイヤー、国内外の課題や事例をまとめました。これであなたもMaaS博士!

▼「MaaSとは」でたどり着いて欲しい記事 
  https://note.com/ppt_msdg_maas/n/naae427dbc37c

 

 私たちのチームは昨年度より発足した20代の若手メンバーを中心としたチームで、メンバーも組織としても若く、MaaSへの取り組みの中で様々な技術習得や課題解決を通して、日々成長しています。

今回は、その中で学んだこと、うまくいったことや行かなかったこと等のノウハウを発信しているエンジニア向け「Qiita」ブログをご紹介したいと思っています。

• 「MaaS」について興味がある・学び始めたエンジニアの方
• すでに「MaaS」に関わっている方

はもちろん、

• モバイルアプリの開発に携わり、先進のライブラリやプラットフォーム開発を活用したい方
• データ分析や予測分析、BIツール活用に興味のある方

にもぜひ見ていただければと思います!

2. Qiitaでの発信について

画像2を拡大表示


MaaSチームでQiitaの投稿をスタートしたのは今年(2021年)の5月から。MaaSにかかわる業務や取り組みの中で、関連した得た知識を皆さんにフィードバック・ご紹介したい、という思いで発信しています。


[ パーソルP&T MaaSチーム Qiita投稿 ]

  ブログはこちら☞ https://qiita.com/ppt_msdg_maas

例えば、以下のような内容の記事を発信しています。
● React Nativeライブラリを用いて、地図を表示するiOSアプリの作り方
APIを用いたLINE Messageでの送信方法、決済方法
● データを扱う「エンジニア/データアナリスト/データサイエンティスト」、データ分析を学んだエンジニアが考える「違い」と必要なスキルセット
● Tableauを用いて東京都の1kmメッシュ別の滞在人口データを可視化してみる

○●○


MaaSに関わるサービスは、必然的に利用者が「移動する」ことが前提になります。そのため、モバイル端末で動くアプリの開発が必須です。
その中で、例えば複数の移動手段を組み合わせてルートを検索したり、移動履歴・行動履歴等の情報を収集し分析し最適化させたりするなどの仕組みを構築していくことも重要になります。

これまでQiitaでは、発信では、MaaSに関連するそれぞれの技術要素で「何ができるか」を中心に紹介してきました。今後は、よりそれらを実践的な内容で紹介していけたらと思っています。
 ・モバイル開発、MaaS開発の実践Tips
 ・実務に直結する有効な技術(⇄実務に活かしづらい技術)

3. どんな人に見てほしいか

画像3を拡大表示

私たちはQiitaへの投稿を通して、「新しい技術領域にチャレンジする人の指針になる」記事を書いていきたいと考えています。私たち自身が当事者だからこそ感じるのですが、エンジニアとして新しい分野へ挑む際、「何から始めるべきか」や「どう進めるべきか」を判断するのって難しいですよね。

特に昨今、アプリケーションに新たな機能を実現するにも、類似したサービスや事例・実現手法が無数にあり情報があふれていますし、トレンドの移り変わりが激しいことからどの技術領域を選定していくかといった判断も難しいと思います。

私たちも同じように苦労しているからこそ、経験を活かして、技術を利用する価値やメリットを伝えることを意識しつつ、技術の活用で躓くポイントをフォローするような記事、私たち自身が「こんな記事と出会えたらよかった」と思えるような記事を書ければと考えています。

MaaSに関わる記事が中心になると思いますが、分野を限定せず、幅広く情報発信していく予定ですのでぜひQiita上でのフォローをお待ちしています!

4. 最後に

私たちも一人のエンジニアとして思うのですが、アウトプットすることはすごく意義のあることですよね。

得た知識の定着、整理といった側面もあるのですが、人の目に触れ、何かを伝えようと意識してアウトプットすることは実際にやってみると難しく、それを通して自身の理解不足に気づかされることも多いです。

皆さんにとってはもちろん、私たち自身が足りていない部分に気づき、それを補うためにインプットを増やすといった、良いサイクルが生まれるよう、発信を通して、自身やチームの価値を上げていくことも、Qiitaで発信する目標の一つです。
そして、これらの活動を通じて、エンジニアコミュニティの一員として、貢献していきたいと考えています。

是非、これまでの記事、今後の記事をご参考にしていただければと思います。

~ ~ ~

以上、モビリティソリューションデザインチームによるQiitaブログのご紹介でした!私たちの生活をより便利に豊かにするMaaS分野。本ブログと一緒に是非チェックいただけると嬉しいです(*^^*)

是非次回の記事もお楽しみに★

~ ~ ~

弊社のTechコミュニティにご登録頂いた方には、今後もこのようなエンジニアブログの情報や、イベント開催情報をいち早くお届けいたします。SNSをフォローする感覚でお気軽にご参加ください。

https://crm.hito-link.jp/app/entry/ppt/saiyo

 

【エンジニアブログ】システム開発エンジニアからジョブチェンジした私が語る、サイバーセキュリティ職を目指すあなたに伝えたいこと

見出し画像
 

みなさんこんにちは、パーソルプロセス&テクノロジー・グループソリューション統括部・プラットフォームソリューション部・情報セキュリティグループ所属、仁科です。

今日私がご紹介しようと思っているのは、ズバリ「サイバーセキュリティ」についてです。セキュリティエンジニアというと、他のエンジニア、例えばアプリケーションエンジニアとは全く別領域のイメージを持っている方も多いのではないかと思います。

しかし、興味がある・やってみたい、という気持ちがあれば、何かのきっかけにジョブチェンジすることはできます。私自身、キャリアのスタートはアプリエンジニアでした。ということで本日は、

・サイバーセキュリティって何?
・(アプリ)エンジニア時代の経験って活かせるの?何が似ていて何が違うの?
・どうすればサイバーセキュリティの仕事につけるの?

といったことを書いていこうと思います。

 

私について

画像1

元々は開発ベンダーやSIerで、テスター・プログラマーからPMまで約14年間担当していました。後述の通り、システム開発・管理をしながらサイバーセキュリティに首を突っ込む機会があり(約4年間)、その後サイバーセキュリティ職としてのキャリアをスタート。
現在はパーソルグループのプライベートSOC※でサイバーセキュリティにかかわる仕事をしておりますが、セキュリティ業務の特性上、業務の中身を公にできず、具体的な仕事の分野は割愛させていただきます。

※SOC・・・「Security Operation Center(セキュリティ・オペレーション・センター)」の略で、顧客または自己組織を対象とし、情報セキュリティ機器、サーバ、コンピュータネットワークなどが生成するログを監視・分析し、サイバー攻撃の検出・通知を行う組織のこと。

 

はじめに:日本で20万人も不足しているサイバーセキュリティ人材

皆さんは、数年前2020年の国内のサイバーセキュリティ人材が20万人不足するという推計があったのを知っていますか。すでに2020年を超えた今、実際にどれだけの人数が不足しているのか分かりませんが、サイバーセキュリティ人材で中途採用をしようとしてもなかなか人が集まらないというのはSIerでも事業会社でもよく聞く話ですので、今でも不足しているという状況は変わらないと思います。

一方、サイバーセキュリティ人材を目指そうといっても、一定のハードルの高さを感じられる方は多いと思います。が、私自身は最初からセキュリティエンジニアだったわけではありません。システム業界に就職してプログラマーからスタートし、いろいろやってからサイバーセキュリティ業界にたどり着きました。

そんな経歴でもあるので、システム開発とサイバーセキュリティで似ていること、違うことについて、私見を書いてみたいと思います。エンジニアとしてのキャリアでサイバーセキュリティに関心をお持ちの方の参考になれば嬉しいです。私はアプリケーション開発経験が長いので、例え話がそちらに偏るのはご容赦ください。

【SEとサイバーセキュリティの類似点】:攻撃者という「関係者」

画像2

まず、システムエンジニアのみなさま向けに、SEとサイバーセキュリティについてお話しします。

システム開発プロジェクトでは、ステークホルダーという用語で表現する『関係者』がたくさん居ますよね。同じように、サイバーセキュリティでは、関係者という意味では攻撃者も範囲に入ってきますステークホルダーと言う単語を当てはめるのはどうかと思いますが)。

ただし、当然ですが良好な関係を築くことはできませんし、必要もありません。ですが、何が目的なのか、何が目的でこんなことをやっているのかを解き明かす必要があるという意味では、要件定義で考えることと変わりないと言っても良いと思います(言い過ぎですかね?)。

システムエンジニアとして働く中で、上流フェーズで顧客の要件が曖昧でなかなか進められないという思いをした人も居ると思います。このように「相手の考えが良くわからない」、ということはサイバーセキュリティでも起こります。

実際、攻撃の痕跡と思われるログの中には、何を目的としているのかよく判らないものもあります。ですがそれを、脆弱性情報や、アプリ開発の知識、攻撃の進展段階に当てはめてみたりすると、見えてくるものがあったりします。(ここは、サイバーセキュリティとしての専門性を求められるところです)

一方、違いとしては、要件定義では顧客に貢献するためにその目的を探りますが、サイバーセキュリティでは攻撃者の目的を阻止するためにその目的を探るという点です。当然といえば当然ですね。

こういった、よくわからない行動を発見して、切り分けして、分類して、仮説検証して……。この探るという作業が面白い、興味が持てると思えるなら、それはサイバーセキュリティでも活きてくると、私は思います。

 

IT技術者とサイバーセキュリティの類似点】攻撃者も、使って(悪用して)いるのはIT技術

画像4

<用法次第で毒にもなる薬と同じですね>

IT技術と一口に言っても幅は広いですので、ここではアプリケーション分野に絞って話を進めます。

攻撃者が使うのもIT技術――、何を当たり前のことを、と思われるでしょうが、この点が、IT業界からサイバーセキュリティ業界にキャリアチェンジした私が感じる一番大事な部分だと思っています。

攻撃者の中にはマルウェアを買って攻撃に用いる(つまり技術にそれほど明るくないと思われる)人もいますが、マルウェアがプログラムで動いていることに変わりはありません。それは、システム開発で用いるのと同じプログラムです。

何が言いたいのかというと、サイバーセキュリティ業界は、システム開発からかけ離れた、何か特殊な知識だけで成り立っている訳ではない、ということです。

もちろん、プログラムの使い方や目的、求められる知識の深さには違いがあります。例えば、普通のプログラマーならバグは嫌がるでしょうが、攻撃者はそれを理解して使いこなします。攻撃者はプロラムのバグ(攻撃に悪用できるバグは脆弱性と言います)や、設計上の穴を見つけ、時には強引な手段に出る。攻撃者はそのためにIT技術の知識を活かし、悪用します。

もう一度書きますが、攻撃者が使うのもプログラム言語などのIT技術です。だとしたら、システム開発で培ったノウハウも生かす道はあるはず。

これが、私がサイバーセキュリティに携わる上での原点の1つです。

 

【サイバーセキュリティ職を目指す1】得意分野を作ろう、活かそう

とは言え、攻撃者が使う技術は、大雑把に言っても、アプリケーション分野(ざっくりプログラム言語も含むものと捉えてください)だけでなく、インフラ分野、ネットワーク分野など、多岐に渡ります。つまりアプリケーション分野だけ知識があっても、全ての攻撃に対応することはできません。

そうなると、「自分にはサイバーセキュリティは無理だ」「太刀打ちできない」……と考えたくなります。ですが、システム開発でも、上に書いた3分野の全てに詳しい人材はそうそう居ません。1分野でも得意分野を作り、それを強みとする。あらゆるIT領域で言われていることですが、これはサイバーセキュリティでも言えることだと思います。

それから、例えばプログラミングをされている方なら、ただプログラムするのではなく、どうすれば効率的に処理させられるか、バグに繋がる考慮漏れが無いかなどを深く考えてみる。このような何かを追求する姿勢はプログラミングを理解するのに役立つだけでなく、それを逆手にとる攻撃者の思考を読む訓練になり、サイバーセキュリティへの応用につながると思います。

 

【サイバーセキュリティ職を目指す2】サイバーセキュリティ人材としての経歴を作ろう

画像4

これまでのスキルを活かして、サイバーセキュリティをやってみたい!…と言っても、実際にはなかなか実現しづらい面があります。やはり、何かサイバーセキュリティに関する実績を作る必要があるでしょう。

私の場合、運良く(いや、悪いのかもしれませんが)、関わっていたシステムが攻撃されていることが発覚し、その調査に携わる機会(主にログによる不正ログイン調査)がきっかけとなりました。自己紹介で「システム開発・管理をしながらサイバーセキュリティに首を突っ込んで(約4年間)」というのがその時期にあたります。

とはいえ、運用中のシステムで、攻撃される状況を意図的に作り出すようなことは、皆さんがSEやプログラマーであれば当然、やるべきではありません。笑 そのため、環境が許すなら、運用中のシステムのセキュリティ強化を名目にセキュリティ対応を引き受けてみるというのは一つの策かと思います。

また、サイバーセキュリティのコミュニティやイベントに参加してみるというのも良いと思います。知識も増えますし、知り合いや仲間もできます。サイバーセキュリティ業界では、横のつながりは大切な財産になります。私の場合、仕事上で知り合ったサイバーセキュリティ業界の方から交流が増え、勉強会などに参加するようになりました。

 

おわりに

サイバーセキュリティ人材にも様々な経歴の人がいます。大学で専門に学んだ人もいれば、私のようにSEや開発に従事していた人、ネットワークを専門にしていた人、インフラを専門にしていた人とさまざまです。一人で全ての領域をカバーするのは難しく、そういった人たちと協調して対応していくことが大事になるのだろうと、私自身は考えています。

いろいろ書いてきましたが、最後にもう一つに重要なのは、やはりこれでしょう。

サイバーセキュリティに興味があるか、やってみたいか。

技術がどうとか、年齢がとか悩むことは色々とありましたが、結局のところこれがあったから、筆者もサイバーセキュリティ職を目指しました。

もしこんな気持ちがあるのなら、あなたもぜひチャレンジしてみてはいかがでしょうか。

 

【エンジニアブログ】言語化できるスキルを身に付けよう! 言語化は集団/組織の継戦能力を最大値化する近道(後編)

みなさんこんにちは。
パーソルプロセス&テクノロジーの正直者のはず 須田です。

「昔SPI(適性検査)を何度か受けた際に、内向性がMAXと評価されていた」という話をするたびに「…ライスケール(嘘つき度)は?」がセットでついてきたのはなぜでしょう。
もちろんライスケールは0でしたよ?

さて前回、『骨太な組織』を構築して、社会的な信頼性の高い組織にしていこうと思ったらその施策の1つとして「再現性」の高いプロセスを積み上げていくことが重要で、その実現の第一歩として今まで感覚や経験則などの属人的な取り組みに任せきりだったものを「言語化」してチーム内、あるいは組織内で共有していくことがとても大切だとお話ししました。

今回はその続きです。

↓↓ 前編はこちら ↓↓

はじめに

本内容は次のような方々に向けたものとなっています。

 ・継戦能力の高いチーム作りや永続化された組織作りにお悩みの方
 ・安心して任せられる人材を作り出しやすい環境が欲しい方


 あと、「嘘やん」とお思いの方。

自己紹介

画像8

須田 孝(Takashi Suda)
システムソリューション事業部 技術統括部 品質保証部。
「ことさらモノづくりという事業において、様々な「質」を中心にプロセスを構築し、マネジメントを実践すればSQCDすべての面においてハイパフォーマンスが実現できる」をモットーに日々奮闘中。
先日、小学生時代の絵の具セットが古い段ボールが出てきました。「物持ちいいなー…」と思ったのも束の間、カチカチになった元絵の具らしきもの、毛が抜けて棒だけになった筆、ちょっと力を加えただけでパリパリ割れていくバケツを見て、早々に捨てました。

 

言語化スキルは広い視野を持って 

とかく集団を「組織的」たらしめるのは、そこにコミュニケーションが発生し、その質によって個人では成し得ない大きな力にできる点にある…のは前回説明の通りです。

そしてコミュニケーションを成立させるには、どうしても意思疎通を図るためのツールが必要になります。これを私は「言語化」と呼んでいます。

よって、なにも日本語でだらだらと表現するだけが言語化ではありません。ここで凝り固まってしまうと一気に難易度や大変さが跳ね上がってしまいます。ボディランゲージという言葉があるように、文章にしなくても言語化できる方法は多種多様にあることをまず知っておいてください。

画像1

そして、図や表なども集団のなかで共有できるレベルにまで昇華できていればそれは立派な言語化の1つです。わかりやすいところで日本が誇る文化の1つ『マンガ』や『アニメ』も人のイメージを言語化し、共有する言語化ツールと言えるのではないでしょうか。

画像2

エンジニアの皆さんにとっても馴染みのある言語化ツールと言えばチャートではないでしょうか。たとえばそう、フローチャート等です。

同じような発想のもとにできた有名な図表にはUML(Unified Modeling Language:統一モデリング言語)もありますよね。UMLはすべて図(charts and diagrams)で構成された10(または11)の様式のことをいいますが、その名の通りLanguage…言語といわれています。

UML

・作成するのに少々特殊なツールを用いないと効率が悪い
・(ツールがないために)作成しても相手が読み取れるとは限らない

といった事情から、欧米や他のアジア圏はともかく、日本ではあまり普及していない言語の1つです。ですが、きちんと使いこなせれば要件定義~詳細設計でも、各種調査やメモとして残す際にも使える非常に優れた言語群ですので、食わず嫌いをせずに使いこなしていただければと個人的には思っています。

たとえば先日、「問題」を起こしてしまった際の対処としてその汎用的な処理手順を整理していたのですが、これもまたUMLの1つ(アクティビティ図)を用いたものとなります。

画像7

テスト工程でバグが検知された際でも、設計工程でレビュー指摘を受けた際でも、あるいはマネジメントで期限を超過してしまった場合でも、「問題」と言えるものが発生した場合にはどこでも使える処理フローとなっています。

「是正(修正)」「再発防止」「影響範囲の特定」「類似見直し」の4つの関係性と手順、判断基準などを1つの図表にまとめています。文章で整理すれば数千行にもなるであろうこれらの内容も、このように図表を用いて言語化してしまえば数百文字で表現可能です。

ちなみに、作成に用いたツールはAstah*Community v6.9です。商用利用が可能な最後のバージョンで既に提供もされていない無償ツールですが、ただ脳内整理して画像化するだけであれば個人的にはこれで十分です。

再現性を阻む障害

やはり会社を、組織を、あるいはチームを永続的に成長、繁栄させていくためには個人が持っているイメージや感覚、経験則などを言語化し、その内容から組織的に活動できる仕組みやプロセスへと昇華させていくはたらきが必要です。

そう、重要なのは「一人の能力」より

「組織文化の醸成」

なのです。そしてそこには常に「非言語的なプロセスの言語化」が伴わなければなりません。言葉にできなければ誰かと意見を交わすことすらできません。共有することも不可能です。チームとして、組織としていつまで経っても統一感のある活動を行うことができません。

画像4

言語化する」という手続きを踏まない以上、コミュニケーションは決して成立することなく、コミュニケーションが成立しない以上、絶対に集団としてのパフォーマンスを生み出せないのです。そして集団としてのパフォーマンスを生み出せないということは、いつまで経っても個人主義に頼らざるを得ず、組織文化を醸成することは適わないということでもあります。
結果、ある「特定の誰か」がいなくなった時点で立ち行かなくなる事業やプロジェクトといったリスクを常に抱え込んだ脆弱な組織、集団となってしまいます。

ではみなさんは日頃、どのようにこの「再現性」を得るための努力をしているでしょうか。

たとえば開発プロジェクトを思い起こしてください。

3か月前にお客さまと取り決めた詳細な仕様や設計内容について「当時とまったく同じ認識や理解を得られる状況を生み出す」ために、みなさんはどのような取り組みをされていますか?

いつでも
だれでも
何度でも

まったく同じ理解、認識になっていますか?

いえ、個人が…ではなく、組織として、チームとして誰一人欠けることなくそれが実現できていますか?

ちょっとしたプロジェクト活動などでもこの「再現性」というのは、案外軽く扱われているシーンを見かけることがあります。結果的に、認識の抜け漏れが発生しても、お客さまとの間で認識の齟齬が発生し大きな問題に発展することがあっても、です。

それを「予算が…」「スケジュールが…」というのは言い訳になりません。「その結果、問題を起こしてもいいのか?」というとそれは絶対にNoだからです。既存の手法にとらわれず、知恵と工夫を駆使して限られたリソースのなかで実現する方法を模索していくしかありません。「できるできない」で悩んでいても決して前には進みません。「やる+どうやるか」でしか人も組織も前に進めないのです。

これは、そもそも組織文化の醸成過程において「再現性」そのものがあまり重要視されてこなかったことにも起因します。

それだけ「とても優秀な方々が多かったのだろう」という予測はできるのですが、それもそうした優秀な方々が最前線で頑張れている間だけ有効となる話です。病気で戦線を離れたり、昇格や異動、離職などで集団から外れてしまったりしたらそこでおしまいです。

実際、私も10年以上前に入院した際、仕様や設計で確認したいと多くの人たちが訪れ、問い合わせを受け、挙句、病室にPC一式を置かれ、いつでも対応できるように…と言われたことがあります。
まさに、「人」に依存することで組織的なフォローができない状況を生み出した良例(?)と言えるのではないでしょうか。

「勝って兜の緒を締めよ」といったことわざがあるように、人は調子がいい時は調子が悪くなった時のイメージができにくいものです。しかし調子が悪くなってからなんとかしようとしてもあとの祭りです。特に組織文化なんてものは一朝一夕で醸成されるものではありません。大抵の場合は年単位で浸透させていくものですから、調子が悪くなってしまってから立て直すのは一苦労です。

個人が優秀であればあるほど、このことがおざなりになりやすいんですよね。
なにせ、個人で様々な成果を出せていた頃はそこまで集団のパフォーマンスを感じやすい環境に身を置くことも無かったでしょうから。

言語化の先にあるもの

適切なイメージの言語化を行うということは、そのまま「コミュニケーションを成立させる」ということに他なりません。言語化したところでそれが自分以外の誰かに伝わらなければ意味がありませんよね。言語化することそのものが目的ではなく言語化はただの手段です。目的はあくまで「コミュニケーションを成立させる」ことであり、これによってのみ集団活動の円滑化が図れて、パフォーマンスの最大値化が可能となるわけです。

誰かと意思疎通を図れば、それはコミュニケーションとなります。そしてコミュニケーションを成立させるというのは、相手に伝わってほしいことが齟齬なく伝わるということでもあります。

「伝える」のはさほど難しくないのですが、大事なのは「伝わる」ことです。どんなに必死に伝えても相手に伝わらなければなんの意味もありません。コミュニケーションが成立するかしないかは『受け手が決める』ものです。送り手が好き勝手に決めていいものではないことを肝に銘じておきましょう。

小さな子供と話をするのと同じだと思ってください。子供と同じ目線に立って、こちらから歩み寄っていかないと話もままなりませんよね。

画像5

TVCMやチラシでも同じことが言えます。見る人が理解できる内容になっていなければ視聴者に伝わるものも伝わりませんよね。

お客さまと会話するシーンを想像してみてください。ITの専門用語ばかりぺらぺらと並べ立てても、ITリテラシーに疎いお客さまは、ちんぷんかんぷんですよね。

プログラムの関数を思い浮かべてください。これから呼び出す関数へ渡す引数は、呼び出す側が自由に定義できるものではありません。常に呼び出される側(受け手)が事前に決めているものですよね。

すべての『情報伝達』において同様のことが言えます。

ゆえに、
「コミュニケーションを成立させる」ための言語化というのは、私は

「コミュニケーションの摩擦係数をゼロに近づける」

ということだと理解しています。
一切の摩擦が無くツルッツルッの状態で軽く押せばどこまでも進んでいくくらいストレスフリーな状態にすること。相手に思考や忖度をさせる暇もなく理解や納得を導き出せること。そうなるような言語化を心掛けること。そして、できるだけ優秀な人たちの過去の実績に裏打ちされたプロセスを

いつでも
だれでも
何度でも

再現できる組織文化を構築すれば、あとはその世代ごとの人材たちが活用し、応用し、時に改善し、放っておいても組織は「常に」「安定して」成功をおさめ続けていくでしょう。

そうして洗練された仕事は必ず次のようになります。

画像6

そうして良い結果をおさめ続ければ、当然お客さまの信用を得ます。次に依頼する仕事の期待も否応なく高まります。

日経コンピュータなどが定期的に出している顧客満足度調査などで上位を取る かも知れません。口コミだけでなくそうした評価も相まって、ますます競争力が向上すること請け合いです。

それに優秀な方々の成功プロセスに対し、再現性が高いということは「失敗」「ミス」などによる手戻りも減るということです。手戻りは最も多く消費される冗長コストの1つです。これが減るということは、そのまま純利益に還元されるということでもあります。

まとめ

このように

再現性の高い取り組みと
それを実現するための言語化およびその徹底


することが、いかにメリットしかない素晴らしい仕組みか、おわかりいただけた方もいるのではないでしょうか。是非みなさんも、自分だけのスキルやノウハウにとどめておこうとせず、どんどん言語化を図り、組織のパフォーマンスを向上してみてください。そしてそうすることが当たり前の組織文化を醸成させていきましょう。

これを「show-how」といいます。

専門知識、技術情報、ノウハウを英語でknow-howと書きますよね。how (どうするか)を知っているという意味です。情報社会ですから、ノウハウは無形資産としてしばしば大きな価値を持つのは間違いありません。

しかし、ノウハウでは個人として優れることはできても、組織を優れさせるには不十分です。show-howとは、技術、プロセス、方法などをいかに見せるかという専門知識です。最近では無形資産の価値も見直され、より組織に、社会に貢献できる情報とすることに重きが置かれるようになってきました。

ノウハウで閉じ込めておくよりも、そうする方が結果的に大きな成果や次のビジネスにつながりますし、そうした方が圧倒的に組織貢献度は高くなるからです。

是非とも言語化する姿勢に価値を見出し、1つも2つもランクが上の組織を構築してみてください。IT業界に生きる以上、できないはずはありません。だってIT(Information Technology)とは"情報を取扱う技術"の総称であり、私たちはその道のプロを名乗っているわけですから。

本内容がほんの少しでもみなさまの役に立ち、何か月、何年、何十年と先を見据えたチームや組織構築の手助けになれば幸いです。

 

●●●

 

最後まで記事をご覧頂きありがとうございました🙇

パーソルP&Tにご興味を持っていただけた方に、イベント開催情報やブログの更新情報をお届けいたします。今すぐの転職は考えていなくても少しでも興味をお持ちいただいた方は、SNSをフォローする感覚でご参加いただければと思います。


下記の記事ではガイドマップのように過去の記事をまとめております。
ぜひ他の記事も読んでみてください!

【エンジニアブログ】言語化できるスキルを身に付けよう! 言語化は集団/組織の継戦能力を最大値化する近道(前編)

みなさんこんにちは。
パーソルプロセス&テクノロジーの正直者 須田です。

ここまでなら「何言っちゃってんの?」程度で済ませてくれるのに「いやー、私極度の人見知りでー」というと、なぜかかぶせ気味に「嘘だ」と言われます。

ウソジャナイヨ?

さて、私なりに25年ものあいだIT業界を渡り歩いてきて、様々なチーム、組織を見てきましたし、運営してきたなかで学んだこと…といいますか、実践してきたことを1つご紹介してみたいと思います。

少々長くなってしまいますが、これ1つあるかないかで『骨太な組織』が作れるかどうかが大きく変わってきますので、前編と後編にわけてご紹介します。
最後までお読みいただければ、それが嘘ではないと嫌というほどご理解いただけるものと思います。

 

はじめに

本内容は次のような方々に向けたものとなっています。

 ・継戦能力の高いチーム作りや永続化された組織作りにお悩みの方
 ・安心して任せられる人材を作り出しやすい環境が欲しい方

  
  あと、「嘘やん」とお思いの方。

 

自己紹介

須田さんエンジニアブログ5

須田 孝(Takashi Suda)
システムソリューション事業部 技術統括部 品質保証部。
「ことさらモノづくりという事業において、様々な「質」を中心にプロセスを構築し、マネジメントを実践すればSQCDすべての面においてハイパフォーマンスが実現できる」をモットーに日々奮闘中。
数年前から色々な果樹を育て始め、収穫できるようになってさらにハマって今では花木や草花、ハーブまで手を出し300種近く。最近ではもっぱら近所から「園芸関係の人らしい」と囁かれる。

 

須田の過去インタビュー記事はこちら ↓↓

 

個人と集団の違い

個人のままであろうとせず集団になる理由、それは個人でできないことを実施するために他なりません。そもそも個人ですべてができるなら個人ですべてやってしまえばいいんです。その方が一人あたりの収入も多く入ることでしょう。

…ですよね?

画像1

私たちが生まれるよりももっとずっと昔であれば、それで成立する仕事も多かったかもしれません。でも、それでは時代の変化とともに大きな仕事ができなくなってきたために「会社」というものが生まれました。

個人では成し遂げられないことをするために集団ができ、その一形態が会社となっているんですね。仕事を依頼する側の視座へと変えて見てみると、個人ではなく集団になるのは「集団だからこその成果」を期待されているからだと言っていいでしょう。

みなさんは、集団の中に属する…ということをそのようにとらえたことってありますか?

 

組織の永続化を考える

さて。

集団の意義やそこに求められているものはわかりました。そのためにチームや組織があるということもご理解いただけたことでしょう。すなわち集団に属する以上は、「個人の能力」ではなく「集団だからこそ出せるパフォーマンス」が要求されているのです。

では、そのパフォーマンスが一過性のものだったらどうでしょう。

「ある人がいたから」
「私だったらできる」

それはそれで個人能力としてとても素晴らしいことではあるのですが、それってその人がいなくなった時点ですべて終わりですよね。

企業に依頼してくださるお客さまというのは、特定の個人だけを信用して仕事を出すわけではありません。あくまで公正な比較評価の上で「この会社なら成功させてくれる」と信じて仕事を依頼します。そう、信じているのは組織であって、個人ではないのです。

画像2

そのような信用、あるいは信頼に対し企業として組織として応対せず、個人の力量任せになってしまうのはとても残念ですよね。なによりお客さまが残念に思っていることでしょう。その人が「病で倒れた」「異動した」「離職した」等によって継続することが不可能になった時点で信用に応えることができなくなってしまうからです。それでは永続的に事業を続けることはできません。

つまり組織や事業の永続化という観点から考えた場合、必ずその先には『人』に依存せず、仕組みやプロセスによって構築された再現性の高い取り組みが必要となり、その実現によってのみ事業継続能力を持てると言えるわけです。

 

再現性の高い取り組み

「再現性」とはその名の通り

いつでも
だれでも
何度でも(冪等性)


同じ取り組みができ、近似した結果が出せることを言います。料理のレシピや家電の取扱説明書、ゲームの攻略本などをイメージしてもらえるとわかりやすいかもしれません。

品質保証の観点から言わせていただくと、これができるプロセスこそが最も質が高いものとなります。「質が高い」取り組みができている状態とは、偶然やまぐれの結果に対して使うものではなく、常に安定して期待に近い成果を出せて初めて使うことが許されるものです。

とても面白いネタを持つ芸人でも、あるネタだけしか面白くなければ「一発屋」としか言われませんよね。偶然などの一過性で出せた成果を正しく評価できないのは、どの世界でも同じです。

では、組織として再現性の高い取り組みとは具体的にどのようなものを指すのか。

それはいつやっても、誰がやっても、何度やっても同じ期待結果を出せるプロセスを持つ…ということになりませんか?

そうなるためには、まず最初に何が必要だと思いますか?

そう、まずは言語化する」ことです。より高い質を安定的に拠出できるベテラン勢が持っているノウハウを個人の経験則だけに閉じたものにするのではなく、それらをすべて言語化し、可視化することです。個人知から組織知へと昇華させるのです。


これらはシステムソリューション事業部が取得している国際規格、ISO 9001:2015(以下、QMS)のなかでも求められています。

7.1.6 組織の知識
組織は、プロセスの運用に必要な知識、並びに、製品及びサービスの適合を達成するために必要な知識を明確にしなければならない。 この知識を維持し、必要な範囲で利用できる状態にしなければならない。
国際的にも知識やノウハウを明らかにして「いつでも」「だれでも」「何度でも」利用可能にしておくことは"当たり前"として求められているものですが、そもそもスキルや経験の言語化、ナレッジ化は20年以上前から業界全体で普通に言われてきたことでもあります。

そうした取り組みを定着させることで初めて、組織は「組織」としてのパフォーマンスを遺憾なく発揮し、また事業の永続化へとつなげていくことが可能となります。

 

ソフトウェア品質の世界でも常識化!

実はこのことは、ソフトウェア品質(ISO 25010 / ISO 9126)の世界でも当然のように昔から言われてきました。ソフトウェア品質の世界では次のように4つの質が求められます。

須田さん プロセス品質

そこでは「質のいい製品やサービスというものは、質の高いプロセスに依存する」と考えられています。良い結果を生み出した際には、その結果がただの偶然とならないようにプロセス(仕組みや順序、手続き、ルール、基準等)として明確に言語化しなければ、同じ質を維持し続けることは難しい…と言っているのです。

このように「質の高い」プロセスを「いつでも」「だれでも」「何度でも」再現できるようにした集団や組織には、安心感が生まれます。そこにいる個々人の増減で一喜一憂しなくて済むようになるからです。

個人で実現できても、それは個人のスキルが高いだけ。
だけど集団で実現できなくては、集団活動の質が向上しない。

この状態を放置し続けても「できる人はできる」「できない人はいつまで経ってもできない」という状況からは一向に脱することができません。それでは組織としてのパフォーマンスを最大限発揮することは叶わず、お客さまも不安が拭えなくなってしまいます。だからこそ個人の頭の中にあるイメージや考え方、手順、着眼点、経験則などを集団活動に応用できる形に落とし込むことが重要となるわけですね。

まとめ

さて、前編はここまでです。

再現性の高い取り組みを推進することで個人ではなく組織の地力が向上する仕組みと、そのために必要不可欠な要素の1つが様々な知識やノウハウの「言語化」であるというところまでお話しました。

 

次回は

言語化スキルといっても具体的には?
・とことん有益な再現性の高い取り組みを阻む要因
言語化の先にあるもの

をご説明したいと思います。

 

本内容がほんの少しでもみなさまの役に立ち、何か月、何年、何十年と先を見据えたチームや組織構築の手助けになれば幸いです。

 

●●●

 

今回のエンジニアブログはここまで。後編もお楽しみに!

パーソルP&Tにご興味を持っていただけた方に、イベント開催情報やブログの更新情報をお届けいたします。今すぐの転職は考えていなくても少しでも興味をお持ちいただいた方は、SNSをフォローする感覚でご参加いただければと思います。

https://crm.hito-link.jp/app/entry/ppt/saiyo

 

下記の記事ではガイドマップのように過去の記事をまとめております。
ぜひ他の記事も読んでみてください!

 

 

【エンジニアブログ】ブリッジSE3年目の私がおすすめするエンジニアのための英語学習のコツ

はじめまして、パーソルプロセス&テクノロジー(以下、パーソルP&T)の星野です。

「英語に興味はあるけど自信がない…」そんな悩みを抱えるエンジニアのみなさん。

そのお気持ち、よくわかります。

私も学生時代、短期留学したイギリスで「ハンバーガー、テイクアウトでお願いします」がまったく通じず、「ポテト」をテイクアウトしたという苦い思い出があります。

そんな私ですが、英語学習を継続し、現在はブリッジSEとして海外開発案件を担当。現在も英語勉強中です。

この記事では、エンジニアが英語を学ぶメリットや英話学習のコツをご紹介します。
以下の方にオススメの記事となります。ぜひ参考にしてみてください。

・英語って必要なの?
・英語力に自信がない
・英語の勉強方法がわからない
・英語を話せるようになりたい


1.自己紹介

画像6

星野 花恵
パーソルP&T システムソリューション事業部 海外拠点推進部 所属。
新卒入社後、金融システム、官公庁システム維持管理などを担当。
2018年、POS+統括部(現ポスタス株式会社)で、はじめて海外開発案件を担当。
自社プロダクト開発、グローバルチーム開発のおもしろさを知る。
育児休暇を経て、現在は自社プロダクトの勤怠管理システム「MITERAS勤怠」をグローバルチームで開発中。
プライベートでは、夫、私、娘、犬との3人+1匹暮らし。
最近気になることは、実母のLINEの既読がbot並みに早いこと。

 

2.エンジニアが英語を学ぶメリット


突然ですが、エンジニアが英語を学ぶメリットは具体的にどのようなものがあると思いますか?
私は3点あると考えています。

画像16

① 入手できる情報量が増える

インターネット上の情報は英語で書かれていることが圧倒的に多いことをご存知でしょうか?

Q.現在、インターネットで最も使われている言語は?
A.英語(62.8%)

画像18

※W3Techs 2021/10  https://w3techs.com/technologies/overview/content_language


60%以上の情報が英語で書かれているのに対し、日本語はわずか1.9%という結果です。
Android APIリファレンスなども、日本語に翻訳されていない部分がたくさんありますよね。
英語が読めれば、すぐに独力で一次情報へのアクセスが可能になります。

② ビジネスチャンスが増える

画像7

何かを学習するには、学習コストがかかるもの。
将来的にビジネスチャンスを最大化できる言語も英語なのでしょうか?
海外の研究によると、現在~2050年まで、世界で最も「使える」言語は英語とされています。

 

Q. 世界で最も話されている言語は?
A. 英語(11億3000万人)

画像7

※WorldAtlas 2020  
https://www.worldatlas.com/articles/most-popular-languages-in-the-world.html


Q. 現在、あらゆる観点から最も使える言語は?
A. 英語 ※地理、経済、コミュニケーション、知識、メディア、外交の観点からスコア付けされたランキング

画像7

※World Economic forrun 2016 https://www.weforum.org/agenda/2016/12/these-are-the-most-powerful-languages-in-the-world/


Q. 2050年時点で、あらゆる観点から最も使える言語は?
A. 英語 ※地理、経済、コミュニケーション、知識、メディア、外交の観点からスコア付けされたランキング

画像7

※World Economic forrun 2016 https://www.weforum.org/agenda/2016/12/these-are-the-most-powerful-languages-in-the-world/


また、英語によって増えるビジネスチャンスの一例として以下のものが挙げられます。
 ・日本国内の外資系企業で働く
 ・日本国内の日本企業(海外部門)で働く
 ・海外の日系企業で働く

ビジネスチャンスが増えるって、ワクワクしませんか?

③ 多角的な視点を持てる

画像7

英語を通じて海外の方と話すことで、1つのことを多角的な視点で考えられるようになります。

例えば、日本のエンジニアは、設計~テストを1人で実施することも多いと思います。
一方、海外のエンジニアはフロントエンド担当、バックエンド担当、テスト担当と分業制なことも多いです。

海外のエンジニアにメリットを聞いたところ、以下の点を挙げていました。
・作業が並行して進められるのでプロジェクトの生産効率が高い
・エンジニアは自らの専門性を磨くことに集中できる

このように、世界中の人と関わることで新しい考え方や価値観に触れ、時には日本にとどまっていたら気付けなかった日本の素晴らしさも実感できます。

 

3.エンジニアのための英語学習のコツ


では、英語学習を始めるにはどのような方法がよいのでしょうか。
ビジネス英語をしっかり学習する方法は堅実ですが、時間もかかります。
そこで、忙しいエンジニアにオススメのトピックを絞り込んで学習する方法をご紹介します。
この学習方法では、効率的に必要なトピックの英語力を高めることができます。

<トピックを絞り込んで学習する方法>
 ① トピックを決める
 ② とにかく暗記する
 ③ 瞬発力を鍛える
 ④ 実践力を鍛える
 ⑤ トピックを変えて①~④を繰り返す

画像8

              画像9

画像10


<各ステップの説明>

① トピックを決める

画像11

最初は「自己紹介」や「趣味」など、日本語でスラスラ話せる内容に取り組むことがポイントです。
馴染みのあるトピックを採用しましょう。


② とにかく暗記する

画像12

これは英語の基礎となる筋トレです。
トピックの単語、フレーズを現代のあらゆるツールを駆使して暗記しましょう。

③ 瞬発力を鍛える

画像13

ここで問題です。
Q.「ありがとう」は英語で何というでしょうか?
A. Thank you.

すぐに「Thank you.」と思い浮かんだ方がほとんどではないでしょうか?
これは、みなさんの「英語の感謝の言葉」→「Thank you」の 瞬発力が高いためです。
新しく学んだフレーズの瞬発力も鍛えることで、スムーズに英会話のステップに進めますよ。

<オススメの進め方>
英語を聞き、10秒以内に日本語に訳して書き出す、話す。
日本語を聞き、10秒以内に英語に訳して書き出す、話す。

 

④ 実践力を鍛える

画像14

英会話を通して実践力を鍛えていきましょう。
コストはかかりますが、講師の質や教材がしっかりしている有料のマンツーマン英会話レッスンを受講することが効率的です。
時間のある方は「留学」、時間のない方は「オンライン英会話」をオススメします。
集中して取り組めて、同じ志をもつ仲間に出会うことができる留学はとてもオススメです。
新型コロナの影響で留学も難しい今、なんとオンライン留学サービスも始まっています。

<オススメのサービス>
 ・オンライン留学サービス
   CNE1  (https://www.cne1jp.com/

 ・オンライン英会話サービス
   DMM英会話 (https://eikaiwa.dmm.com/

 

<オススメの進め方>
 ・英会話レッスンで対象トピックについて、20分ほど英会話をする
 ・以下の単語やフレーズを復習する
   ・聞き取れない
   ・意味がわからない
   ・伝わらない
   ・話したいのに英語が出てこない
 ・復習後、再度英会話に挑戦

 

4.英語学習を続けるコツ

画像15

普段仕事をしながら英語学習を続けることは本当に大変です。
以下のようなモチベーションを維持できる環境を作り、英語学習を続けていくことが大切です。

・英語学習の明確な目標設定をする
 X年後にXXXの仕事をする等、明確な目標設定をし、目標達成に向けて頑張りましょう。

・応援してくれる仲間をつくる
 英会話の先生や留学仲間は比較的応援してくれます。世界一のサポーターになってもらいましょう。

・気の合う英会話の先生を見つける
 趣味や今日のできごとを笑って話し合える先生を見つけましょう。
 その先生とのトークを日々の息抜き&英語学習にしましょう。

 

5.まとめ

いかがだったでしょうか?
今回は、エンジニアのための英語学習のコツをご紹介しました。
ご紹介した学習法はあくまで一例です。この記事が少しでも皆さまの一助になれば幸いです。

最後までご覧いただきありがとうございました。

●●●

弊社のTechコミュニティにご登録頂いた方には、今後もこのようなブログの情報や、イベント開催情報をいち早くお届けいたします。SNSをフォローする感覚でお気軽にご参加ください。

https://crm.hito-link.jp/app/entry/ppt/saiyo

 

 また、下記の記事ではガイドマップのように過去の記事をまとめております。ぜひ他の記事も読んでみてください!

【エンジニアブログ】必見!~Oracleデータベースの知識を身につけるなら是非みてほしい、おすすめの書籍3冊~

はじめに

SIerとしてデータベースの移行プロジェクトに携わる上で、その特徴・技術的な側面を知識として理解することは非常に重要です。しかし、さまざまな書籍が発行され、インターネットにも情報が溢れる中、知識をしっかり身につけたいという中でもどのような書籍を選ぶべきか迷ってしまうことがよくあると思います。

 

私自身、昨年データベースの移行プロジェクトを担当し、新卒の方と一緒にお仕事する中で、私が今までに経験したことを伝えるということは出来たのですが、その際改めてデータベースに関する知識をしっかり身に付ける為には本を読み体系的に知識を身につけることもとても重要だと感じています。

 

そこで本ブログでは、Oracleデータベースにて昨年度グループ企業の基幹システム移行を行なった私が実際に読み、役に立った・知識習得に最適だと感じたおすすめの本3つを紹介させていただきます。

ある程度データベースに携わられてきた方の中で、特にOracle関連の知識をしっかり身に付けたいという方の参考になれば嬉しいです。

 

自己紹介

無題

服部 知幸
これまでデータベースSEとして5社でキャリアを重ね、2020年4月にパーソルプロセス&テクノロジーに中途入社し、グループ会社であるパーソルテンプスタッフの基幹システムのデータベースの保守・運用を担当しております。
昨年度はデータベースのバージョンアップ(移行)作業を担当し、現在はデータベースの安定稼働を目標に日々バタバタしている毎日を過ごしております。

こちらは上司の富永さんとのインタビュー記事です。
良かったらご覧ください。


おすすめの本1


「マスタリングOracle DBA (DB press)」

読みやすさ:★★★★★
知識の網羅性:★★★☆☆
実務への活かしやすさ:★★☆☆☆


この本はこれからOracleデータベースをやってみようという方に是非読んでもらいたい初心者向けの本です。私自身、Oracleデータベースを業務で担当するようになった10年以上も前に先輩から勧められて読んだ本になります。

会社に入ったばかりの1年目の方でもとても読みやすくOracleデータベースというのはどういうものなのかというのがとてもわかりやすく書かれています。
データベースは難しいものというのが固定観念である方が多いと思いますが、この書籍は難しいことを簡単な言葉を使って丁寧に表現してくれているので、一番最初にこの本を読むとデータベースをもっと勉強しようという気になります。

これから業務で担当するという方や、独学で勉強しようと思っていて基礎を身に付けたいという方にはとても良い本だと思いますので、是非読んでみていただきたいと思います。

ちなみに私が購入した本は色んな方を転々として、最終的には前職の新人君がとても気に入ってくれたので退社する時に餞別にプレゼントしたため私の手元にはありません。
Amazonなどのランキングでは下位のため、みなさんノーマークだと思うのですがとても丁寧に書かれていて入門用としてはおすすめの一冊です。


おすすめの本2

「プロとしてのOracle運用管理入門」

読みやすさ:★★★★☆
知識の網羅性:★★★☆☆
実務への活かしやすさ:★★★★★


こちらはおすすめ1の本を読んでから読んでいただくとデータベースへの理解が深まる中級者向けの本になっています。
そして、データベース移行というよりは保守寄りの内容となります。私の現在の担当業務が保守・運用ですのでぴったりです。

データベースは動いていて当たり前と思われる中ですが、実際、保守ではどのようなことをしないといけないのかがとても分かりやすく書かれています。

言い過ぎかもしれませんが、この本に書いてあることを順番にやっていくだけで、パフォーマンスもそうですが、セキュリティ面でもかなり質の高いデータベース運用が出来ると思います。


おすすめの本3

「絵で見てわかるシステム構築のためのOracle設計」

読みやすさ:★★☆☆☆
知識の網羅性:★★★★☆
実務への活かしやすさ:★★★★★

これは、自己紹介にも書きましたデータベースの移行作業をする際に、私自身がこれまでの自分のやり方にとらわれず第三者の意見を取り込みたいという目的で購入した本で、上級者向けの内容になります。

一言でデータベースの移行と言っても、何をしなければならないか、何から始めるべきかという定義はあまり定められておらず、過去のプロジェクトで実施したことや我流でやるという方が殆どだと思いますが、この本ではデータベースを新たに構築する前に検討しなければいけないこと、検討した方が良いことがたくさん書いてあります。

より効率よく円滑に移行を進められたい方、必見です。 


おわりに

データベースは難しいという印象を持たれている方はたくさんいるかと思いますが、概念がわかってくるととても面白いものですし、難しい分やりがいがあります。
日本のマーケットにデータベースエンジニアが少ない分、出来るようになるととても頼りにされますし、今データベースに携わっている方も今後携わりたいと感じていらっしゃる方も、少しでも興味をお持ちの方は是非読んでいただければと思います。


最後までご覧いただきありがとうございました。

 

●●●

 

弊社のTechコミュニティにご登録頂いた方には、今後もこのようなブログの情報や、イベント開催情報をいち早くお届けいたします。SNSをフォローする感覚でお気軽にご参加ください。

https://crm.hito-link.jp/app/entry/ppt/saiyo

 

 また、下記の記事ではガイドマップのように過去の記事をまとめております。ぜひ他の記事も読んでみてください!