【初心者向け】JaSST Tokyo（ソフトウェアテストシンポジウム）で学んだ、QAチームで行うテスト運用と自動化のエッセンス３選

今年の3月10日、11日で　JaSST'22 Tokyo （ソフトウェアテストシンポジウム2022東京）というイベントに参加しました！ちなみにこちらはオンラインでした。２日間に及び、とても充実した内容だったので、だいぶ前のイベントですが記事にしました。

JaSSTソフトウェアテストシンポジウム-JaSST'22 Tokyo

JaSSTとは

JaSSTってなに？という方も多いかもしれません。

簡単にいうと全国各地で行われる「ソフトウェアテスト」にテーマを絞ったイベントです。

ソフトウェアテスト技術振興協会が中心となって、日本各地でシンポジウムを開いており、テストに関わるエンジニアやテストの自動化ツールに携わる複数の会社さんが参加されるようです。開催地は札幌・関西・東北など複数ありますが、今回のJaSST Tokyoは年に１度の日本国内最大のソフトウェアテストシンポジウムでした。

前提

私がシンポジウムに参加した目的、解決したかったこと

　私自身、仕事をしながらなんとなく「これ知りたいけどどこで学べるんだろ？」とモヤっとした疑問を感じていたことがありました。具体的には、

　　🤔 他社のQAエンジニアって普段何を意識して仕事をしているのだろう？ 

　　🤔 一般的に、チームでテストを行う際の課題はなんだろう？

　　🤔 テストを自動化したい時は何に注意したらいいのだろう？

といったもやみでした。

これは、組織とプロダクトが大きくなっていく過程で、チームとタスクの運用を運用する中で、今後どんな障害があり、何に気をつけていったらよいかを予測したい、という気持ちから生まれた疑問でした。

QAEチームもメンバーが少ない上に自分自身も経験がまだ浅すぎる状態（QAEになって４ヶ月目..）だったので、大まかに大量の情報収集をしたいと思い、たくさんの登壇者が集まる大きなイベントに参加してみました。

この記事の対象となる人

　　　🐤 QAエンジニアの経験が浅い人

　　　🐤 複数人のチームでテストを運用を始めたいと思っている人

　　　🐤 テストの自動化を始めたいと思っている人

こんな人にはちょっとだけ参考になるかもしれません。

はじめに：そもそもQAの仕事とは？

例えばですが、弊社のチームが普段取り組んでいることは

• 　　プロジェクトの際にQAチームの参加・不参加を他チームと相談する
• 　　テスト実施のプランを立てる
• 　　テストケースを書く
• 　　テストケースのレビュー
• 　　テストの自動化を一部考慮して、効率的に回せるように仕組み化する
• 　　テスト結果に基づいて、バグ報告をする

　　　　　　　　　　　　　　・・・・などなど・・・・

ついでにこちら、他社のQAエンジニアさんが書かれたものですが、とても参考になる記事を社内の上司から共有頂いたので、おすすめします👇QAの仕事をより深堀って書いてあります。

note.com

あくまで個人的な考えですが、QA（品質保証）の定義ってすごく広いと思っています。

例えば、プロダクトの１機能がきちんと動くこと、バグがないことだけでなく、エンジニアが最大限のアウトプットを出しつつ納期に間に合うようにタスク調整するOps的役割だったり、顧客が満足に製品を使えるように、カスタマーサクセスから受けた要望を満たせるようにエンジニア側と話しあったり、バグの数や顧客からのフィードバックを分析してよりよいプロダクトにアップデートして、品質全体が上がっていくことを数字で示したり。

自分はまだQAのキャリアは一年未満なので「それ違うでしょ」「全然分かってない」とかいう感想を持たれる方もいるかもしれません😓。また、上記を完全にマスターするのはほぼキャパシティ的にかなり厳しいと思うので、理想論になっているかもしれません。

でも、それくらいQAができることの世界は幅広いのではないか？と思っています。

幅広いからこそ方向性に迷うつらみ

幅広いということは選択肢が多いということ。人は選択肢が多いほど選べないと言われています。（ジャムの法則というらしい。）

選択のパラドックス（多すぎると選べない）：行動経済学とデザイン05｜ジマタロ｜note

そこで、冒頭で書いた自身の

　　　❗️QAエンジニアは普段何を考えてテストをするのか

　　　❗️チームで行うテスト運用

　　　❗️自動化する際のポイント

という悩みを解決するヒントになりそうなエッセンスについて、シンポジウムで学んだことを３つ、まとめてみました。

💡エッセンス１：プロダクトにとって適切かつ、チームにとって扱いやすいツールを選定する

何をもって適切かは会社のプロダクトやチームの方針によると思うのですが、テストをより効率的に行うためにさまざまなツールがあります。テストをするだけではなく、それらのツールを利用してテスト自体を管理することも、QAエンジニアが意識すること、ということを学びました。例として、以下のようなツールがあります。

便利なツールたち

（１）自動化ツール

自動化ツールに関しては、

　　Autify

　　Selenium

　　Ranorex

などが有名でしょうか。ちなみに弊社iCAREでは、UI選択型のmablというツールを使っています。自動化ツールにはどうやらたくさんの種類があるようです。👇下の記事は、シンポジウムの内容とは無関係ですが、知識としてわかりやすかったので紹介します。

hldc.co.jp

　　　🙄. 。(この中から何を選べばいいんだ....)

といった迷いが生じると思います。

その場合、テストスクリプトが修正しやすい（メンテナンスがしやすい）ものを選ぶと良いとのことです。これもアプリケーションにあったもの、テストしたいこと、チームにとって合っているものを選定すればよいのでは、という解釈です。

（２）テスト管理ツール

エクセル形式でテストケースを管理する方法もありますが、楽に、手早く、かつ分析までやってくれるツールもあります。

シンポジウムで紹介されていたのは、

　　TestRail

　　Quality Forward

です。テストを管理するってナニ？、と思うかもしれません。一言で言うと、テスト結果をまとめる作業を減らすもの、らしい。実際に使ったことがないので正確なことは書けないのですが、具体的にやってくれることは、

・テストの結果を集計、比較、分析してくれる。

・画像や値などのテストデータを登録でき、テストに関わる情報を一元管理できる

・テスト全体のサマリーや進捗、メンバーのアサイン負荷などを提示してくれる

などなどがあるそう。使いこなせるかわからないけど便利そう。。！

親和性が高いツールを組み合わせる

自動化ツール単体でも、結果の推移などを自動で表示してくれる機能はあるのですが、テスト管理ツールを組み合わせることでより便利にテストを運用することができます。

例えばTestRailであれば、代表的な課題管理ツールJIRAと連携して、テスト結果の分析から得られた課題を登録することができるようです。そんなことまでできるのか.....すごい、といった感想。

一歩進んでテストを楽にしたい、かつその結果を楽に可視化したい、というチームには向いているのかもしれません。ここまでできたら、自動化できなくて手動で行うべきテストに、時間と労力を十分に割くことができそうですよね。🧐 わーい。

💡エッセンス２：複数人でも管理しやすいテストを考える

前項にも関連する内容かもしれませんが、アプリケーションが成長するとテストケース数も増えて、管理が大変になります。またチームメンバーも増えることで誰がどこまで何を管理しているか混乱することもあるのではないでしょうか？

最初にできそうなこと

チームやテストが複雑になる場合、最初に以下のことを取り組むとよさそうです。

（１）１つのテストケースを単純にする

　　　単純にすることで、誰もがわかりやすく、メンテナンスがしやすいテストになる。

（２）変化に強いオブジェクトを作成する

　　　テスト内容に若干の変化があったとしても、メンテナンスコストが低いテストを作ることで、アプリケーションの成長に対応しやすくなる。

（３）共通化できるものは１つのスクリプトにまとめる

　　　複数箇所で使用するテストのデータはテスト管理ツールなどで一元管理すると楽。

（４）テストの「目的」別で簡単に選定できるようにする

　　　緊急用の最低限のテストとか、ユーザーの受け入れテストなど、目的に絞ったテストを整備することで、よりアプリケーションが成長し、障害や新機能リリース時などでテストしたい状況が異なる時に素早く対応することができる。

テスト関連でその他考えること

テストケース作成だけでなく、テストをチームで運用していくためには以下のことも大切であると感じました。

・仕様は開発と共に更新していく

・チームで品質の定義を考えてみよう

・誰がどこの品質を担保するか明確にしてみよう

仕様についてまだまだ言及できる立場ではないので今回の記事では割愛しますが、２・３個目についてはチームメンバーが揃った段階で取り組むと良いのではないか、と思います。これらが大切だと思った理由は、

チームで目指す「品質」の定義が明確になり、誰がどこの品質を守るかが整理できるから、です。特に、絵やポストイットを使って図にして可視化すると、楽しくかつわかりやすく理解できるみたいですよ。

前提でも書いた通り、品質という意味は幅広いので、このようにチームで運用する場合は整理することで、チームが目指すところ

・何を守り

・そのために何をテストしたいのか

について共通認識を得ることができます。

そこで初めて、実践するTO DOとして、前項に書いた適切なテストツールの選定をすることにつながるのだと思います。

💡エッセンス３：テストを自動化する時の注意点

テスト自動化研究会という団体があり、そこのHPで「テスト自動化の８原則」

sites.google.com

というポイントがまとめられています。

こちら見るとすごくわかりやすくまとめられているのですが、この原則の中でもシンポジウムで取り上げられていて、個人的に印象的だったものを抜粋。

・闇雲に自動化するのは危険

「テストを自動化するほど楽になるのではないか？」と一見思いがちです。私もQAを始めたばかりの頃はなんとなくそう思っていました。しかし思いつくままに、なんとなく大事そうなテストケースから片っ端から自動化していくのは良くないらしい。

理由としては、

　　テストメンテナンスの手間が大きくなる、実行時間が伸びる（手動でやってしまった方が早い）という事が生じてしまうため。

本末転倒・・・・

自動化に向いてないテスト？

ではどんなテストは自動化を避けるべきなのでしょうか？

　　・探索的テストのような明確な仕様がない

　　・手順が複雑で自動化するのに手間がかかりすぎる

　　・結果に人の判断を必要とする

　　・新機能のため、まずは手動で実施して結果を確認したい

などといったもの。確かに自動化には向いてなさそう。。。。。（としか言えない泣）挙げてみると、確かに手動にしかできない部分な気がします。

・自動化の初期設計で自動・手動を効果的に組み合わせよう

上記のような事案になるのを防ぐために、テストの自動化を考える初期段階から設計することが大事。自動化するテストにも「向き・不向き」があり、それを最初の段階で整理すると、余計な自動テストを作ってしまって混乱したり、無意味な作業をするコストを削ることができます。

自動テスト、手動テストの良いところ・得意なところをそれぞれ理解して組み合わせるテストの設計をすることで、より効果的なテストを行うことができます！

まとめ

前提が長くなってしまったかもしれませんが、初心者QAエンジニアにとって共感できるところはあるのではないかな〜と思い、この記事を書きました。

QAエンジニアはエンジニアの比率の中でも少なくてニッチな立場なので、他のチームから「QAって一体何してるんだ？と思われてるかも・・・」なんていう気がしたり、社内にもメンバーが少ないしなかなか情報を集められない、という困りごともあるのでは。　この記事では、JaSSTのようなイベントがあること、そこから似たような課題感を感じている人がいることを知ってもらえたら嬉しいです。

また課題に対しての方向性を考えるためのヒントになったら幸いです。

自動化についてもまだまだ弊社でも進めている初段階でして、詳しいことが書けないのでちょっと悔しいです。これからも勉強していきたいと思います！

では👋

ひよっこQAエンジニアが会計ソフトfreeeのオフラインイベントに参加してみた

先日６月１日、会計ソフトfreeeさんのオフィスに訪問して、QAエンジニアと交流し、経験豊富な方々に仕事のアドバイスを直接頂く、という貴重な経験をしました。

参加したイベントはこちらです。👇 

freee-tech-night.connpass.com

思っていた以上の学びを得ることができ、オンラインが主流になりつつある風潮の中で、是非オフラインイベントの価値を皆に知って欲しく、記事にまとめてみました。

　自分自身、そもそも他のIT企業のオフィスに足を踏み入れたことがなく、「他のエンジニアってどんな環境で働いているんだろう？」といった興味がありました。また、コロナ禍で多くのイベントがオンラインになり、現在働いているiCAREでも、ここしばらくはmeetupイベントもオンラインとなっていました。基本的にイベントはオンラインでしか参加したことがなかったので、「オンラインとオフラインってどう違うんだろう？」という興味もあり、他社オフラインイベントに参加してみました。

「オフライン」イベントは学びの宝庫だった

　率直な感想としては「想像以上の学びと楽しさがあった」です。当然、登壇で聞ける内容はオンラインでもオフラインでも同様なので、オンラインでのイベントに慣れてきた今、「学べることは同じなのだから、オンラインでも十分なのではないか？むしろ足を運ぶ手間も省けるから、わざわざオフラインで参加しなくてもいいのではないか？🤔」とすら思っていました。

しかし実際行ってみて、その予想を遥かに裏切られ、登壇内容の学びを超えたたくさんの学びがあったので、是非今後はできる限りオフラインで参加したい！という気持ちに変わりました。

 具体的に何が良かったのか？🧐

１． 働く人や環境の違いを体感することで、自分を客観視できる

やっぱり会社の規模・オフィスの中・働いている人・イベントや仕事で使われる環境などの違いを生で見ることができるのは刺激になります。

具体的には

• 自分よりも年齢が若く、多くの知識や技術を身につけて活躍している人がいる
• 従業員にとって働きやすく生産性を上げるためのオフィス環境が整っている
• 登壇内容を配信し、イベントを運営するためのスタッフの動きや使用する機材

などといった見ることができ、会社が違うだけでこんなにも雰囲気が違うんだなぁ、と改めて感じました。

他社を訪問したことがなかった身としては、「同じ仕事をしていて、世の中にはこんなに凄い人たちがいるんだな....」と改めてピリッと姿勢が正される思いでした。特に、私のようなIT業界に入ってまだ経験が浅い人にとっては、自分の知っている世界、普段身を置いている世界がほんのごく一部分でしか過ぎないことを実感できるでしょう。

　体感した新しい環境と、自分が身をおく会社の環境と比較してみることで、自分またはチームで「今できていること」「できていないこと」を整理したり新たに発見する機会となります！

もし会社のメンバーと一緒に参加して、「他社のこんなところを参考にうちでも取り入れたいよね」といった話ができたら、イベントでの学びをチームの成長に活かすことができると思います！

２．イベント内容が記憶に残りやすい

意外とオンラインよりもいいなと思った点です。配信現場という緊張感が記憶力と集中力を高め、画面越しに登壇者の顔やスライドを眺めて聞いているより、圧倒的に話の内容が頭に入って来たため、登壇者が語った要点も、よく覚えているし理解できたかな、と感じました。

登壇者の方が話したエッセンスが強く記憶に残ったため、翌日から早速、それらを自社のプロジェクトのテスト実施に活かすことができ、これまで以上に納得感や自信を持ちながらテストをすることができました。

３．登壇者と直接話して、交流できる

オンラインでも、イベント後の懇親会や質問タイムを設けるケースが多いと思いますが、オフラインだと直接話せるので、やっぱり純粋に楽しいです😊✨。

私は基本初対面の人と話すことに抵抗感をあまり感じないタイプなので、特にそう感じました。また、オンラインイベントだと複数人と同時に繋がるので、「この人に！」聞いてみたい、という質問はしづらい場合があります。そんな時オフラインだと、１対１で話を聞くことができ、心理的なハードルが下がったりします。

（どういう状況が話しやすいかは、人それぞれなので、向き不向きは分かれるかも知れませんが）

しかし、対面で登壇するような方と話せる機会は、駆け出しエンジニアにとっては大変貴重です。エンジニアの経験年数が短く、あまり自信がない人こそ、直接話してみることで、突っ込んだあんなことやこんなことまで、お話を聞けるチャンス。

実際に私は、３名の登壇者の方の中で、最も経験年数が若い方にお話を聞いてみて、QAエンジニアとしての駆け出しの頃のキャッチアップは何を意識したか？といったお話を伺ってみたところ、快く色々教えてくださいました✨

社外の同じ職種に就いている方と対面で話すことで、自分が目標としたい方を新たに見つけることができますし、キャリアの先輩方に顔を覚えてもらうチャンスでもあります。リファラル採用が増えてきているエンジニア業界、またそもそもエンジニア業界でも少数派のQAエンジニア界隈では、自分の会社を知ってもらったり顔を知ってもらうことは、もしかしたら、今後の役に立つのでは....？と密かに思っていたりします。。

４．予想外のチャンスが降ってくる

上記の直接話せるということにも関連しますが、直接登壇者の方と話していると、次第に他の方々が自然と集まって来てくれて、思いがけない方と話すチャンスが降ってきたところが、個人的に更に楽しいと思った点です。オンラインでも話すこともできなくはないですが、普段関われない（というかペーペーが同じ空気を吸うのも畏れ多い...😵）ような大ベテランの方に、普段教えてもらえないことを教わるチャンスがありました。

「ゆもつよメソッド」というテスト手法でQA界隈で有名な湯本さんに直接お話を伺うこともできました。この方は、ソフトウェアテスト関連の本を多数執筆していらっしゃいますし、講演会も開いています。

今回のfreeeのイベントでは、オフラインでの訪問者が少なかったため、質問時間を最大限に使わせて頂き、チームとして小さい故の自社の悩みや現状を具体的に相談させて頂きました🙏。

その結果、テストケースを作る時に意識すると良いことや、より良いQAエンジニアになる、より良いテストができるようになるための改善点を客観的にアドバイスをいただくことができました。

一つの質問をきっかけに、色々な興味が広がり、次第に自分の中でも、もっと突っ込んだ話を聞いてみたい、という流れになることもあり、想定していた以上の知識の収穫を得ることができました❗️これはオフラインの生の勢いがあってこそできたことかな、と感じています。

freeeの登壇者の方々及びイベント運営の方々、ありがとうございました。

とても気さくにお話をしていただき、是非学んだことを自社に持ち帰って生かしたい！というモチベーションにもなりました。

知識の学びだけでなく、気持ち的な変化もあった

自身の所属する会社はQAエンジニアが私を含めて２人と少ないため、「今の取り組みや進め方でいいのかな、自分の普段の仕事はこれでいいのかな....」、という漠然とした不安がありました。会社専属のQAのアドバイザーのような方がおらず、正しい目標にしたら良いものがわからず、手探りな場面が多くあったため、個人的に心理的な迷いを感じながら業務を進めることも正直ありました。

しかし、他社の同じ職種の方の話や経験を聞くことで、自分の仕事に心理的に納得感を持つことができ、「この場合はこれでよかったののか」「こう感じるのは自分だけではなかった」と自信を持つことにつながりました。また「先輩が言っていたことはこういうことだったのか」と理解が深まり、よりチームの一員としての目指す方向性がまとまる流れに向かっているように感じます。

他にも、QAエンジニアのキャリアはイメージしにくい点はあったが、多様なスキルを磨いて仕事で活躍している人をみることで、よりQAエンジニアの専門性に興味やモチベーションを高めることができ、将来のキャリアへのワクワク感やQAエンジニアという職種の価値も感じることができました。... 🔥

登壇で学んだQAのエッセンスあれこれ

• １PJに対して100ケースくらいを目指すのが量的には程よいので、テストケースを書くときはその量を意識してみる
• PJの始まる初期段階で、あらゆるポジションの人で集まり「リスクの洗い出し会」を開き、注意すべきバグをあらゆる角度から把握する。それによって、テストするべきことを網羅しやすくなる
• PJのリリースが終わったら振り返り会をおこなって、なぜバグが生じたのか？という知見を蓄積することで、その後の未知のバグに備えることができる
• 人の失敗学を学ぶことでバグが生じやすい箇所を感じ取る勘や嗅覚を磨き、テストに活かすことができるようになる
• QAのテストをする時は、好奇心を持って「こうしたらどうなるんだろう？」と悪さをしに行くように、いちユーザーとして楽しんで実施することもコツ
• テストケースを消化することだけでなく、上記のようなテストを人の手で行うためにも、余裕を持てるテスト計画にすること

雑な箇条書きになりましたが、以上の点を参考に、自社のQAチームのレベルアップに繋げることができたらと思います❗️

また、個人的に駆け出しQAエンジニアのレベルアップとしては

• QAの技法を学ぶ
• テストの際に「何を確認したいのか」明確な目的を持ってテストする
• 自社のソースコードを理解できるようにする
• テストコードを書けるようにする

この辺りがまずは目指すとよい目標かな、という学びです🌟

最後に：オフラインイベントには是非参加してみよう〜！！

個人的には想像の何倍も学びが多くて楽しかったので、ぜひこれからもいろんなオフラインイベントに積極的に参加してみたいです。THE 学会、みたいな堅苦しさはない事がほとんどだと思いますし、より広い世界を体感できるのではないかと思います！

会社の雰囲気も圧倒的に伝わりやすいです。この会社の雰囲気はなんか好きだなあとか、こういう人と一緒に働きたいなあ、とか自分の気持ちに気づくこともできます。技術やスキルだけでなく自分のキャリアの価値観を知るチャンスでもあります。それらを通して、新しい目標の発見のきっかけにもなります。

オンライン・オフラインの良さはそれぞれありますが、

駆け出しエンジニアで他の会社のエンジニアの世界をあまり知らない方、QAエンジニアのような、会社でチームメンバーも少なくて業務に関してアドバイスや情報を手に入れる機会が少ない方、そのような方々は特に、オフラインイベントを活用してみることをお勧めします😊❗️

もちろん、QAエンジニアに限らず、フロントエンドやサーバーサイドなど、あらゆるポジションの方にもお勧めしますよ！

自身の所属している株式会社iCAREは、「働く人の健康を創る」を目標に掲げ、現在およそ140人くらいの組織として頑張っています！

私はまだまだ一人前ではありませんが、勉強熱心な仲間と共に日々成長させてもらっています。

よかったらこの記事を読んでくださった方、ぜひオフラインイベントでお会いしましょう✨！ iCAREでも２ヶ月に１回、DevチームのMeetupを配信しております。ぜひ、以前のようにオフライン開催も再開できるようにしていきたいと思っています。

一緒に働いてくださる方も募集中です❗️

debianのホスト名を変えてみる

Linux基礎練習編。

　AAA ＠＋＋＋: ~$ _ linuxでログインすると、上記のように表示されることがあります。 ここでは

👉user名＠ホスト名：今いるディレクトリ（上記の場合はホーム画面を指す）＄　_コマンド_

という構図になっている。

ちなみに、 ・コンピューター名：そのデバイスの名前。 ・ホスト名：サーバーを示す名前。ネットワークに接続されたパソコンを識別する時の名前。例えば、サイトAがwww.~~~~、サイトBがwww.?????だったら、使っているサーバーは同じ。 ・ドメイン名：インターネット上で出会う住所。ドメインを、DNSがIPアドレスに変換することでデータのある場所を特定して通信している。 ・ユーザー名：linuxのばあい、root以外で作ったアカウントの名前。

ついでに.....

debianでもホスト名を変更することができるが、これはroot権限でないと変更できない。

ちなみに.....

root権限に切り替えるときは、 「su」コマンドだ！ このとき、rootのパスワードを聞かれるので、忘れないようにメモしておくことをおすすめする。

元のユーザーに戻るときは、「exit」で戻れる。 また、指定したユーザーに切り替えたいときは、「　su AAA（ユーザー名）」で切り替える。 （環境変数の引き継ぎについては割愛）

話が戻るが、ホスト名を変更する方法は # hostnamectl set-hostname ***** でできる。 反映されていなかったら、一度ログアウトして、再ログインしてみると、反映されていることが確認できる。

参考にしたサイトはいくつかあるが、わかりやすくまとまっていたのはコレ。

linuc.spa-miz.com

変えることができたら、以下のコマンドで確かめてみよう。

$ cat /etc/hostname

今回はここまで。

通信の安全性を担保する仕組み

フィヨルドの内容で、通信の安全性を担保するための仕組みについての記載があった

ポイントとしては ・TCP ・SSL

TCPは、自分が送った内容がきちんと通信先に届いているか確認しながら送信するプロトコルのこと。相手側に確認しながら行うので、転送速度は遅い。が、確実。 一方UDPという方法があり、これは転送の速度を早めるため、相手に確認しながら送信しない。したがって早いが、確実に相手に届いているかどうかは怪しい。

これらの通信の安全性をより高めるために、TCPに加えてSSLという方式が使われるようになった。

SSLは何をしているかというと ・データの暗号化 ・接続先のサーバーが信頼できるかどうかを確かめる

この２つ。

特に、クレジットカードの番号など重要な個人情報を送信するときに使われる。 接続先のサーバーが信頼できることを、サーバーの認可局が「証明書」を発行することによって示し、かつデータを暗号化することで、データ内容を盗まれても中身がバレない。

また、具体的には ・送信側と受信側が同じ共通鍵を持ち、データを暗号化・暗号を復元する手段 ・サーバー側が公開鍵を持ち、クライエント側が秘密鍵を持つことでより安全にデータを送受信する手段

があって、SSLではこれ２つを組み合わせているのが実際のようだ。

とりあえず概要まで。

Linux操作の覚え書き

Fjord Boot Campで　Linuxのコマンドの概念や操作のルールについて、ググれば出てくるが覚えられないので、手順に沿って概要だけざっくりまとめてみた。

サーバーを立ててみる

今回はフィヨルドの内容に沿って、さくらVPSのサーバーを契約してみた。 ソフトはLinuxの、Debianをインストールした。 これにより、私専用のWebサーバーが、東京のどこかに作られたことになると考えると、すごく興奮する！ 何ができるのかというと、サーバーを持つことで全世界にwebページを公開できるようになる。

Linuxを触ってみよう

↑ Linuxのキャラ、Tuxくん。狂気を感じるほどの瞳孔の開き具合がかわいいマスコットだ。

ここで必要な知識がいくつかある。

• 権限、ユーザーについて
• ディレクトリの構造
• 重要なコマンド
• その他の注意事項

一つずつ潰していく。

権限、ユーザーについて

権限はざっくり分けて２つに分けられる。

• root

最強の権限。Superuser

• 一般ユーザー

root以外のユーザー。グループを作成して、そのグループにユーザーを登録することもできる。

この記事を書くまでごっちゃになっていたのだが、root権限・ユーザー（権限）と、rootディレクトリとユーザーのディレクトリは違う。 root権限は誰もが持っている最強オーナー権限。 その権限で操作をしていると下手なミスをした時に悪影響があるらしいので、ユーザーを作成して、そのユーザーにログインして操作しよう。 さらに、ユーザーでログインしてもrootディレクトリというのは存在する。（実際触ってみてようやくわかったw）

ディレクトリの構造

ユーザー名でログインしたらそのユーザー権限の、ディレクトリに入ることになる。 ぱっと見では見えないが、このときのユーザーのディレクトリは root ディレクトリ　> homeディレクトリ　> 登録したuserのディレクトリ　である。これらは 「cd ../」 でディレクトリを移動できる。 さらに「ls」でディレクトリの中身を見てみよう。 これは、ユーザー名(haruka~~)における、rootディレクトリのてファイル一覧である。 rootディレクトリには、いろんな色のファイルがあるみたいだ。気になるものは開いてみよう。 詳しい中身はこちらの記事がとてもわかりやすいので貼っとく。↓

qiita.com

重要なコマンド

Sudo

root権限、すなわちsuperuser権限 で何かをdoする権限を付与することができる。一般ユーザーに付与することで、一般ユーザーでログインしている時もsudoを使うことでroot権限を（借りて）実行することができる。っよぃ.......!

su

他のユーザーになりたいときに使う。suの後に何もなければrootで、su （ユーザー名） => （ユーザー名）でログイン。

su -

以下は　 kazmax.zpp.jp より引用。 今のところ、環境変数の影響がまだピンとこないのでそこについては保留。 su （user名）と　su - （user名）の違いは、user変更前と後で、環境変数を引き継ぐかどうか、だそうだ。

今日は一旦ここまで。

linux復習まわり

フィヨルドを毎日１時間でも進めることを再開。 息をするように、毎日習慣にしていくんだ・・・・

フィヨルドブートキャンプ場に強制送還される

　プログラミングを勉強していると、新しい聞きなれない情報の嵐で、「これって結局何なんだっけ？」⇄「ググる」の無限ループに陥る。 そこで私は脳の自然処理に任せるべく、フィヨルドから一旦手を引いたのであった。（嘘です、単純に業務に追われて手が回らなかった） 流石に経費で結構なお金を支払ってもらっているし、「手が回らない」で言い訳できない金額だし、やりたい気持ちがあるのであればせめて少しずつ取り組んでいるところは見せないと。

人間、モチベーションの波が生じてしまうのは仕方ないのだが、それをどうやって乗り越えて取り組むかが人間の課題である。

私はこういう時、「ゲームのように取り組む」のが合っていると思った。 「楽しい！」しか興味やモチベーションの対象、言ってしまうと楽しくないと行動できない人間であることをこれまでの人生で学んだからだ。

Linuxって

Linux周りの情報が整理されてなくて、結局なんなんだと思っていたが、時間をおいて思考が整理されたようだ。

Linuxとは、MacやWindowsと同じようなOSであり、前者２つと並列の機能を持つもの。 MacやWindowsはそれらのパソコンの中にMacOSが入り、WindowsOSがはいっていることで、一般人がパソコンを買ったときには最初からそのOSを使ってパソコンを利用できる。 Linuxは、パソコンと呼ばれるハードウェアに入れ込むことで機能を持ったパソコンとして起動できるOS。そして無料で、自分のパソコンに入れることもできるものなのである！

要するに、自分のパソコンに、もう一つパソコンを持てるようなもの！

すごい！

出会ったLinux周りの用語整理

distribution

Linuxで使える、ソフトみたいなもの。 Debian, CentOS, とかが有名みたいだけど、他にも１０種類以上あるらしい・・（一生使わない気がする）

apt

distributionたち（debianとか）に使用できる、パッケージの管理システムのこと。 aptコマンドなどを使って、パッケージがインストールできるよー。

メモはここまで。

day1: 02/06 はじめに

Restart

ようやく、QAの仕事も少しずつ軌道に乗り始めたので、フィヨルドブートキャンプ生として本格的に学習に集中していこうと思う。 私が目指していることは、プログラムをただ書ける人になるのではなく、いちサービスを作れる人になることだ。 では早速。

フィヨルドの取り扱い方

フィヨルドブートキャンプは、はっきり言って難しい。初心者向けではないと思うし、エンジニアの夫のサポートがある私ですら挫折するんじゃないかとひやひやする。 何が難しいかというと、ヒントが少ない。課題もシンプル。その中で考え、課題を分解し、ヒントから紐解き、解を導く力が必要になる。また逆に、（よくわからない）ヒントの嵐で混乱することもある。その中で本当に必要な情報を整理して、本当に欲しい解にたどり着くようにする力も養われる。 そこに気づかず漫然と文章を目で追っていると、1000％嫌になることだろう。勉強の過程でも「ひと工夫」が必要なのだ。 私はそこに気づくのに2ヶ月かかった。

ルール

このままじゃ終わんねぇ、と気づいた自分が決めたことは、２つ。

• 周囲のレベルを知り学習・エンジニアの仲間を作り切磋琢磨するために、社内slackのようにdiscordを最大限活用する。 => discordで報告・ペアプロ・質問会・チーム開発を経験する

• 学習定着度を高め、かつアウトプットの速度を上げるために、アウトプットの場を作る　=> はてなブログに毎日OUT PUT

決起会

やっていき！