みんな意外と知らないのでメモ
検索エンジン最適化（SEO）スターター ガイド - Search Console ヘルプ
大前提の部分が大体補完できる感じで
みたいなものが大体書いてある。
そして本文内にも書いてあるんですが
サイトの最適化はユーザーのニーズに応えるために行ってください。検索エンジンはユーザーの 1 つであり、他のユーザーがコンテンツを見つけるのに役立っています。検索エンジン最適化は、検索エンジンがコンテンツを理解して他のユーザーに提示するのを助けるためのものです。
ユーザに読みやすい正しいコンテンツを提供することができていれば、自然とGoogleが見つけてくれるというのが彼らの言い分なので、正しく作ることが重要だということを教えてくれます。
小手先のブラックハットSEOのようなことがSEOの本質だと勘違いしている人がたまにいるので、そういう人たちの認識合わせとしても一読する機会があるととてもいいサイトです。
なんたらbokと呼ばれる知識体系の本多すぎなのでまとめる
Body of Knowledge の略で日本語だと「知識体系」と訳す。
プロジェクトマネジメントにおける知識体系。おそらく一番有名なBOK。
Project Management Institute(PMI)
ソフトウエアエンジニアリングに関する知識体系。「ソフトウェア工学の専門家における知識の集積を記述する包括的用語です。」とWikipediaには書いてある。
ソフトウエア品質に関する知識体系。日本科学技術連盟と日本品質管理学会を中心として日本国内のソフトウエア開発の現場担当者や研究者が策定した日本発のBOK。
ビジネスアナリシスにおける知識体系。ビジネスアナリシスとは「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにおけるチェンジ（変革）を可能にする専門活動」と定めている。
International Institute of Business Analysis(IIBA)
データマネジメントの知識体系。データガバナンスを達成する要素に対するマネジメントの知識体系なので、データをどう運用するなどの考え方の知識体系。
サイバー犯罪捜査の知識体系をまとめたもの。サイバー犯罪なので手口や証拠などがまとめられている。
Cybercrime Investigation Knowledge Forum(CIKF)
情報セキュリティに関する業務に携わる人材のための知識体系。セキュリティなのでトリアージとかインシデントとかの話がまとめられている。
エンタープライズアーキテクチャの知識体系。アメリカで生み出されたものなのでアメリカのエンタープライズシステムにおける知識体系の色合いが強い模様（全然日本語文献がない）
Wikipediaを適当に噛み砕いてみるコーナー
予め定められた機能要件に対して、どれだけ満たせているかという品質。機能要件をどれだけ満たしているか、また過不足があるかの品質。
こちらに関しては要求された機能がつつがなく実装されているかが見るポイントなる
堅牢性や保守性など、機能要件で定められた部分ではない非機能要件をどれだけ満たすかという品質。
こちらに関してはソフトウェアのアーキテクチャなど、機能として要求する部分ではない観点の品質が問われる。例としては負荷に対しての耐性などがあげられる
雰囲気でリーダーをやっている関係で悩みが絶えないので エンジニアのマネージメントで悩んでいる人が集まる会 #1 に行ってきました。
さきほどの資料です！
— める@5/5ファミコンバンド！ (@c5meru) February 26, 2019
エンジニアリングマネージャーでいるのがつらくなったときは #EM集会https://t.co/npRskhkIY5
資料あげましたー
— 惹句@情緒が顕著 (@zaki_taka4) February 26, 2019
Y: SpeakerDeckのアカウントを作って資料をあげて見るhttps://t.co/bctQRMXFl2
#EM集会
ググったらめちゃくちゃ精度高い資料が出てきたのでメモがてら
プレス発表 第4次産業革命に向けたスキル強化の指針“ITSS+（プラス）”に新たに「IoTソリューション領域」「アジャイル領域」を策定し、公開：IPA 独立行政法人 情報処理推進機構
「アジャイル領域」は、第4次産業革命を実現するために必要なアプローチでありながら、アジャイル開発そのものに関する的確な理解が十分普及していないという問題意識から、アジャイル開発のベースにあるマインドセットや原則、アジャイル開発プロセスやチームの特徴、および開発者の学ぶべきスキルについて説明しています。
IPA側でアジャイルを説明した資料がないので改めて作られた、という感じ。
アジャイルのベースともなる「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に関してベースの内容と、それに対しての補足が書き加えられた資料
アジャイル領域へのスキル変革の指針 アジャイルソフトウェア開発宣言の読みとき方
ビジネス用語であるよねー、というのをシステム開発的に噛み砕いてみる雑記
この場合における「信用」と「信頼」を噛み砕く。
主に実績や成果物に則して使われることばで、過去の実績などを伴って信じることに関して「信用する」という言葉を使うことが多い。
「信用取引」という言葉がわかり易い例で、信用、すなわち過去の実績を踏まえての取引なので、この言葉からも信用の意味がわかりやすい
主に気持ちや未来のベクトルにおいて信じることに使われることばで、信頼する側とされる側の双方の気持ちのつながりをベースに使われることが多い言葉。
信用とは違い、精神的な面が大きく、人柄やお互いの関係性などから信じるのが信頼で、考え方としては「今より先に行われることがらに関して信じること」「結果がまだわからないことに関して信じること」
システム開発におけるコードレビューは良い例だと思っていて、コードを書くことは信頼してお願いするが、細部に関してのズレは認識齟齬などで発生することがある。そういう面において「信用はしない」という観点からちゃんとクロスチェックする部分こそ「信頼するが信用しない」なのかと思う
昔ながらの環境構築は手順書を起こし、それをチェックして複眼的に作業をしたりする。これらも最たる例で、手順書を起こす人間は信頼しているが、その人が起こす作業の内容を100％は信じ切っていいわけではない。そのためちゃんと複数人で見て信用に足るアウトプットを作り上げるということなのだと思う。
自身の登壇も貼りましたが、銀座Rails#6 の全体的な行ってきたよメモです。
とりいそぎ今日のスライドです > テストコード未経験者が RailsでそれなりにRspecがかけるようになるまでの話 /Inexperience rails developer ,Use Rspec https://t.co/o9erwUfCOi #ginzarails
— しんくう (@shinkuFencer) February 22, 2019
Rails6からRailsをわかっていく #ginzarailshttps://t.co/BR6s5N4WeG
— cawahara (@cawa) February 22, 2019
※登壇に登場したブログポストは出てきたらリンク書きます
