そーくのつれづれぶろぐ

web系エンジニアの勉強したことなど

バックエンドエンジニアがフロントエンド界隈を知るためにした、たった一つのこと

TL;DR またの名を今北産業

  • (運用を見据えた)アプリ開発をした(Vue3/firebase)
    • 守破離の守:入門書を精読した
    • 守破離の破:早計だったかもしれない?「とりあえず(入門書より)最新verで作るか」
    • 守破離の離:設計の良さ・悪さへの想い
  • 開発で得た心得
    • 最新の公式ドキュメント(tutorialだけでなく設計思想も込みで)を読んだ上で本番運用を想定したwebアプリを作ろう

3行じゃないやん。

想定読者

  • フロントエンド界隈でトレンドのフレームワークを利用したことがないエンジニア

アプリ開発をしようと思ったきっかけ

  1. 作りたい
    • コーディングはたのちい
  2. (そのフレームワークを利用したコードの)コードレビューができない
  3. 円滑にプロダクトを育みたい
    • 担当プロダクトは10年超選手
    • 対してフロントエンドエンジニア部隊とバックエンドエンジニア部隊が存在する(最近フロントエンドエンジニア部隊がジョインした)
    • フロントエンドエンジニア部隊が持っている価値観やミッションを理解していないとミスコミュニケーションが発生する可能性がある

やったこと

最初に書いた通りモノを作った。

バックエンド側の業務の複雑さは、DDDでモデリングしたら集約は1個で収まるくらい。フロントエンド側で言えばコンポーネントが(大小は置いておいて)20個はいかないくらい。

守破離の守:入門書を精読した

公式の構築手順を踏んでも何故かエラーがでて環境構築が終わらない
フレームワークの旨味を無視したモノリシックなコードは修正コストを肥大化させる*1

過去の私から

という経験知があったので、とりあえず新しいことを学ぶにはそのエキスパートの言うことに従ってみるべきだと感じて以下の入門書を精読しました。

Vue.js入門 基礎から実践アプリケーション開発まで | 川口 和也, 喜多 啓介, 野田 陽平, 手島 拓也, 片山 真也 |本 | 通販 | Amazon

これには様々なご意見があると思いますが、この本を選んだのは以下の点で学びがあると判断したからです。

  • 日本語で書かれている
    • 英語読解力はまだまだ自信がなかった
  • フレームワーク自体の思想について説明がある
    • 著者がコミッター。ワーオ、あんしーん☆
  • hello worldで終わらず、実運用を見据えた構成になっている
    • 中規模なプロダクト開発を想定した開発環境のセットアップ、ミドルウェア管理、設計方法、実装、など

守破離の破:早計だったかもしれない?「とりあえず(入門書より)最新verで作るか」

髪の毛が後退しているのではない。 私が前進しているのである。

Twitter 孫正義

「入門書が古いのではない。技術が進んでいるのである。」でした。*2

この入門書が発売された2018年では「Vue2+webpack+Vue test utils」という構成でしたが、私が『とりあえず新しいプロダクトを生むなら最新verで作るのがセオリーやろ、知らんけど』と思ってVue3で作ることを決意したのが…ちょっと早計かもしれませんでした。後悔はしていませんが。

よくよく公式ドキュメントを追っていくと「Vue3+Vite+Vitest*3」を推奨とされており、Vue3+webpackについてはどちらかというと今まで実運用でVue2を利用されていた方向けにかかれており、公式推奨ではないようでした。入門書の1/5くらいを割いて説明をされていた開発環境の構築がそのままでは流用できない状態でした。これは決して入門書に対して批判しているわけではなくて、いかにこの界隈がレッドオーシャンなのかを私が知らなかったゆえに起きたことです。PHPerでいてどうして推測できなかった自分。凹む

守破離の離:設計の良さと悪さへの想い

実際に手を動かしてコンポーネント設計をAtomic Designをもとに行っていくと、色々設計課題が見えてきました。(例えば親コンポーネントからのプロパティ継承のネストがなんか深くなる問題)
とりあえず倣ってみたものの、なんだかイケてない。なにがイケてないのか。

色々情報を探っているとフロントエンドでもバックエンド同様必要に応じたオブジェクト指向の一部を取り入れたりしたほうがいいなど、フロントエンドも大きな枠組みで言えばバックエンドと似たような設計課題を持ちつつある(というか既にそうなっている)というのが改めて理解できた気がします。そして自分の設計力の現実も理解できた気がします。

まとめ

当初の目的は少なくとも達成できたの、かな?と思います。まだまだ理解が及んでいないかもしれないですがwebサービスとして形にしたことで少なくとも会話するときに相手がどういうバックグラウンドで話しているのかを想像することはできるようになったと思います。

あともしこれを読んでいる方がいらしたら、とりあえず、フロントエンド界隈を学ぶときは書籍よりも公式のオンラインドキュメントやそれに準ずるオンラインの学習コミュニティを先に学ぶほうがいいかもしれません。

ただ、個人的には先述した入門書はフレームワークを知るためにとても勉強になりました。著者の皆様方ありがとうございます!

記事を書き終えた今(脱稿ハイによる感想)

記事を書いていて学生時代にとある教授が言っていた造語『ハンカチーフの法則』というのを思い出しました。 机に広げたハンカチを、人差し指と親指である一点を摘んで持ち上げると、横から見たら山みたいになりますよね。
一つのこと(つまんだ箇所)を理解しようとしたら、それを理解するために結局周辺の知識(裾野)が必要になる。という例えで教えていただいたのですが、なんか思い出しました。ありがとうございます先生。教授が元気に過ごしてらっしゃることを祈るばかりです。

アドベントカレンダー7日目を選んだ理由は推しの誕生日だからですハッピー最高!!!

あとt_wada先生がオライリーサブスクええぞっておっしゃってたので割引期間にポチりました。もう英語読むしかねえ。

*1:これには多種多様のご意見があると思いますが、ひとまずフレームワークそのものが先人のベストプラクティスの集合知だということを踏まえて、それに反する書き方をするのは可能な限り控えたほうがいい、という文脈で記載しています

*2:実際にはEvan You氏がめちゃくちゃできる凄腕エンジニアでこのフロントエンド界隈の欠点を補う素敵な解決策を熱意をもって生み出し続けているのかもしれない。すみません、ちょっと自信ないです

*3:書いている現時点でもまだメジャーバージョン番号は"0"

アラサーの私がようやくアウトプットすることに肯定的になった理由

TL;DR またの名を 今北産業

以下の体験を身にしみて実感できる原体験を得たから

  • 効率よく学習ができる
    • インプット・アウトプットがともに増える
  • サードプレイスができる
  • 上記がポジティブなスパイラルになる

はじめに

愚者は経験に学び、賢者は歴史に学ぶ オットー・フォン・ビスマルク

私は愚者でした。これを読むみなさんには賢者であってほしいと願いを込めて書きます。

この記事の内容は天下の t_wada さんがすでに何回も、また色々な場所で若手エンジニア向けに講演なさっている内容のごく一部になります。

speakerdeck.com

私自身、この上記の内容を2018年にリアルイベントで拝聴しました。けれども言っていることは理解できてもなかなかアウトプットする勇気がなく、今に至るまであまりアウトプットをしてこなかったなと思います。先人の教えは素直に受け止め実践したほうがいいというのを改めてこのアドベントカレンダーを機に思い直し、認めようとしました。

若手とはもう言えない私だからこそのリアルな失敗談と掲題の理由を、ちょっとした読みものとして読んでいただけると幸いです。そしてあなたが賢者であらんことを。

※すでに貴方が賢者であれば以降の文章は読む価値がないです
※超絶ポエミーなので…隙間時間に読んでいただきたい…ちょっと恥ずかしい…

qiita.com

ずっと失敗するのが怖かった

アウトプットすることで怖かったのは多分それをしたことで自身の何かに傷がつくことを恐れていたからだと思います。その何かは私のプライドかもしれないし、株かもしれない。*1失敗が自分の生きる価値そのものを損なうものだと過度に認知していた(認知の歪み)のだと思います。

労働した対価としてお金をいただく構造上、少なくとも"労働している"自分の価値はお金に換算されるのは言い逃れができない事実ですが、労働以外に人は複数のペルソナを持って生きています。それは母であったり父であったり、妹であったり、友人であったり、先輩であったり、後輩であったり、同士であったり、恩人であったり…様々なものがある。なのに私は それらの複数のペルソナをないものとして、"労働している"自分=自分という存在の価値とする としてました。それもつい最近まで、それを信じて疑わなかった。恐ろしいことです。

歳を重ねるほど失敗が許されない

誰かに言われたのか、自分がもともと自分に言い聞かせていたのかはもう覚えていませんが、歳を取ると一定の経験を経ているので、求められる役割や成果物の質と量は格段に上がらざるを得ません。一年前の自分より下回ることは、ビジネスにおいては基本NGです。 *2 できたことは次からは当たり前にできることを求められます。小さい失敗はともあれ、職責に応じた給金をいただいている以上、大きな失敗をすることは評価がマイナスになるのは致し方ないことだと思います。

私は共感性や感受性が高い人間なので、たとえば上長との会話の中で求められる職責に応じた立ち居振る舞い・考え方をする必要があるとノンバーバル・コミュニケーションからも過剰に汲み取ってしまうところがあって、余計に”ちゃんとしなきゃ”と思ってました。いやまあそれ自体は正しいんですが、誤っているところは言ったことをそのまま受け入れるのではなくて、それを勝手に”ちゃんとしなければ私は存在する価値がない”と置換してそれを本当に信じていたことですね。*3

転機:新しいサードプレイスができた(アウトプットに肯定的になった原体験)

システム開発における”作る”だけでなくもっと広義の意味での”作る”行為も好きだった自分がいて、ぼんやり人生で一度は自分の作ったものを趣味の範囲内で分かち合いたいと思って、趣味のモノづくり用のtwitterアカウントを作って不定期に自分の作ったものをつぶやきはじめました。仕事ではないので、できたものの質や量は気にしていませんでした。自分が思うままに作れる自由。それによる気持ちよさ。自分が思うままにつくったものをフォローする人が少しずつ増えていき、中には会話をしあう仲の人ができました。そうするともっと楽しくなって作る。同士の作ったものを見たり感じてそれに刺激を受けてまた作る。 つまるところアウトプットがきっかけで、インプットもアウトプットも増え、更にはそのアウトプットによって新しい安心できるコミュニティ、いわゆるサードプレイスができました。 ずっと仕事以外のペルソナを否定してきた私にはとても新鮮でとても救われました。

とった歳は変えられない。が今は変えられる

過ぎた時間はもうどうしようもなくて、世間的にみた私は若手ではなくて中堅で、後進育成やチームを引っ張る・支えになるなどの上位職になるのは必然ですが、それでも 今が一番若い のは紛れもない事実です。なので私にできることは前を向いて、目の前の課題や将来の像に対して今できることをやるしかない。*4

と書くと、なんだか大変お固くて大変そうでウッとくるので笑、 ようはサードプレイスで得たポジティブな体験を、今度は仕事場であったり、仕事に関連した”フォースプレイス”を作るという未来の体験に転用したい、と思って私は今この記事を書いています*5。楽もしたいですが私は欲深いので、 どうせなら楽しくありたい。

で、エンジニア界隈ではありがたいことにそういった仕事とは違うコミュニティに繋がれる文化、というのがすでに出来上がっている*6のと、大抵はそういうコミュニティになんと!無償で所属できたりもします(かかったとしても数千円とかも全然多い)。 すごい著名な本の中の人がtwitterで色々知恵を共有してくださっていたり、twitterスペースを開いていたり、コメントくださることもままあって、思ったより他業種より先人が身近にいます。

おわりに

今私がこうして記事を書けているのも、ひとえに私に関わる人々やいままで会社を支えてきた誰かのおかげです。上長、上位職の皆様、メンバーの皆さま、ありがとうございます。後輩にあたる方も何気ない雑談や、ツッコミ、指摘をくださってありがとうございます。これからもよろしくおねがいします。

もし興味持たれたらツイッターやってますので、覗いてみてくださいませ。

twitter.com

おわりのおわりに

弊社のとあるメンバーがカレンダー2個目をつくったお!って社内チャットで言ってて、まさか2つ目が…と思ってカレンダー2を見てみたら初日が空いていたので、初日がないのはあかんとなんかなりまして急いで前日に書いている次第です。あと2記事書きます。(白目)

*1:プライドは私の中にある自己評価で、株は私の中にいる他者からの評価

*2:同じ職種である前提。他業界にキャリアチェンジは除く

*3:機械学習アルゴリズムすらも”人間は誤る”という前提からはじまるのに。完璧な人間など存在しないのに。とほほ。

*4:歳を重ねると良くも悪くも融通が聞きやすくなるので、下からも上からも指摘やツッコミをばんばん貰えるようHRTを持って生きていたい

*5:余談ですが、複数のコミュニティに所属している人ほど自己肯定感が高いそう。失敗しても他のペルソナでの自分を肯定できるコミュニティがあるから。SPOFを避ける設計を人生でも応用(?)したい今日この頃

*6:文化醸成をしてくださった先人に大感謝

【RDBS】やっぱり実行計画を読めるようになりたい!実行計画の読み方実践編(初級)

はじめに

下の記事の実践編、ということで簡単なSQLの実行計画を読むことで「実行計画の読み方を理解する→SQLがどんな処理をしているのかがざっくりわかる」状態になることを目指します。読み方のポイントをまず知りたい、という方は以下のブログを参照してみてください。

soachr.hatenablog.com

  • はじめに
  • 対象読者
  • (復習)実行計画の読み方ポイント3つ
  • 実行計画をみてみる
    • ケース1: 結合処理 「顧客名と住所の一覧を取得する」
      • SQL
      • 実行計画
      • 読んでいく
    • ケース2: 探索処理「姓が'White'である顧客を検索する」
      • SQL
      • 実行計画
      • 読んでいく
    • ケース3: 演算処理「支店IDごとの顧客数を取得する」
      • SQL
      • 実行計画
      • 読んでいく
    • ケース4: ソート処理「映画のカテゴリをアルファベット順で取得する」
      • SQL
      • 実行計画
      • 読んでいく
  • 最後に

対象読者

  • 一度実行計画を学んだけど挫折してそのままにしている人
  • 実行計画のcost/actual time以外の情報が読み取れない...いう人
続きを読む

【図解】ストレス症状の深刻度合いに沿ったメンタル回復方法【備忘】

概要

個人の振り返りの備忘としてストレス解消法を記載する。 ここ数ヶ月〜数年の自分の行動や情動を記録していく中で自分なりの症状ごとの回復方法の確立ができつつあるので 回復方法を思い出せないストレス症状になったときにこの図が見えるようにtwitterの固定ツイートや色々な目のつきやすい場所に配置する あと単純に私が思うメンタルについて語りたいのでここに語る。

対象読者

  • 原則筆者
  • メンタル回復方法は色々な記事や本があるが、結局はその知識から自分を見つめ直して受け入れ、自分を知っていく作業になる
  • が、それだけだとあれなので、知識をどこから取り入れるかはお届けできるので読んだ本を最後に紹介する

ストレス症状の深刻度合いに沿ったメンタル回復方法

f:id:soachr:20220206113350p:plain
ストレス症状の深刻度合いに沿ったメンタル回復方法

詳細

MP

ストレス症状の度合いを”メンタルポイント”、略してMPとして表した。 私はロールプレイングゲーム(FFV,FFVIとか好き)などを嗜んでいたため、マジックポイントと重ねるのが理解しやすかった。

この図は私の現状起きる症状・対策法を可視化した。フェーズごとの長さは起きる頻度がやや相関している。 ようやっと最近MPをプラスにすることができる頻度が多くなってきたのでこの図と記事を作成している。(MPマイナスのときは記事は無理しないとかけない) 私は運良く会社・チームメンバーに恵まれて色々調整をしてもらっていて、心療内科に通えて、良くなってきている。 本当にありがたい。

(超個人的な語り)抑うつ状態に関する私の個人的見解

MPにはマイナスが存在する

うつ病自律神経失調症など精神疾患にかかる立場としては、かかったことがない人からみればマイナスが存在することを知らないように思う。 上記の症状を外から見たら怠けているように見えるかもしれないし、そんなことで?と思うこともあるかもしれない。 たしかに一時的に図解した症状が起きることはある。私の中ではこれはMP=0と考える。MP=0はつらい。しんどい。わかる。

でも、かかったことがない人はこれが継続してずっと長引いたときを想像してほしい。いつまで続くかわからない。不安が押し寄せる。 元気だったらできていた考えることができないからPDCAすら回せない。今までできていた家事もできずに汚れた部屋にいてもどうでもいいと思う(そもそもそれに気づきもできない)。食べるものの執着がなくなる。好きなものを忘れていく。起きるのも面倒だ。起きているのも面倒だ。 そんな状況がずっと続く。長ければ数十年。つらい。

でも持っている者は持たざる者を理解するのは難しい。 今回私はメンタルに関しては理解を持っているけれど、私が既に持っていて当たり前だと思っていることを羨んでいる人がいることは心得ているつもりなので、理解されることを期待はしない。でも言わないと伝わらない。伝えても伝わらない・理解されないことは往々にしてある。

「自己管理ができていない」「怠けている」だけではない苦しみがある、かもしれない。 元気そうに見えてもそれは氷山の一角で実際はMPをごりっと削って振る舞っている、かもしれない。

そういうふうに少しでも思っていただけるとより安心して回復に専念できると思う。

読んだ本

ちょっとストレスに状態かも?と思った方向けに、私が読んだ本を紹介する。

疲れない体大全

メンタルはメンタルだけでなくフィジカルも関係してくるので、全体的に疲れに対してインデックスを貼るのにおすすめ

マンガでわかりやすい うつ病の認知行動療法

認知行動療法(偏った認知の癖を治すための方法)についてわかりやすく書いてある。 認知行動療法の第一人者の方監修だからとおすすめされたもの。

soachr.hatenablog.com

とりあえずストレスの概要だけについては手前味噌ながら上記でまとめてあるので読んでみてもいいかもしれない。

自分を知るためにやったこと

  1. (前提)MPがマイナスになっている状態が3週間くらいあったら迷わず心療内科にかかる(この状態では既に自分で解決する力はない。専門家に頼ることが第一) (言っときながら自分のときはこの決断ができなかった)
    • 結構お金がかさむのは事実だが、意外と国の制度で実費負担料が減らせる可能性があるのでまずは自分第一で
      • 所得税の医療費控除(医療費が年間10万以上の場合)
      • 自立支援制度(取得した。自立支援制度に対する診断書をかける医師にかかることが大事)
      • 障害者福祉手帳取得(これはだいぶ審査基準が高いらしい)
  2. (PDCAのPD)上述した本を読む
  3. (PDCAのC)ウェアラブルトラッカーによる睡眠、運動記録の確認・メンタル症状の記録

www.fitbit.com

apps.apple.com

  1. (PDCAのA)トラッカーを受けての改善策実施(本などの知識を借りて)
    • 職場への勤務の相談
    • 認知行動療法(私の場合は分け合って臨床心理士のカウンセリングも受けいている)
    • 図解の対処法実施
  2. 3,4の繰り返し

おわり

元気になるぞー!

【読書メモ】イラスト図解式 この一冊で全部わかるWeb技術の基本

イラスト図解式 この一冊で全部わかるWeb技術の基本

概要

所感

  • 思ったより知らない/抜けている情報があり読んで良かった...
  • ほどよく新しい概念も紹介されているし、IT未経験者にはとっつきやすい印象
  • 基本情報処理などの知識がなくてもざっくりwebの知識、概念がわかる
  • ただの基本説明だけでなく実用として使われている/使われていないが軽く書かれているのが印象的

動機

  • 会社にあった
  • 復習がてら読んでみようか

新しく得た内容

  • Webの設計思想

    • RESTful
      • 統一性インタフェース/アドレス可能性/接続性/ステートレス性
    • セマンティックWeb
      • Webページの情報に意味を付け加える
        • webページは簡単に言うとどんな内容を表すのか
  • HTTP/1.1おさらい

    • HTTPキープアライブ
      • 1webページで発生する複数リクエスト/レスポンスを同一のTCPコネクション内で行う
    • HTTPパイプライン
      • 1webページで発生する複数リクエストを並列に送る(前まではレスポンスが帰るまで他のリクエストは投げられなかった(直列だった))
  • HTTP/2と1.1との差分(改良点)

    • (HTTP2について)2015年5月に標準化
    • ストリームによる多重化
      • before : HTTPパイプラインで多重化(並列にリクエストを送る)してはいたが、不十分だった
        • リクエストが来た順番をレスポンスも準ずる必要があるため、最初のリクエストに対するレスポンスが大きい場合は後続のレスポンスはその処理を待たなければならない
      • after : TCPコネクション上に仮想的にストリームというさらなるコネクションの場を提供することで、before時の順番を守るということを考慮しなくてもよくなった→さらなる待ち時間の短縮
    • バイナリ形式
    • 1.1まではすべてのデータはテキスト形式である必要があったが、バイナリデータのまま送れるようになった
    • ヘッダー圧縮
    • HPACKという、前回のヘッダ情報の差分のみを送る方法でヘッダ自体を圧縮する
    • サーバプッシュ
      • webページに複数の画像などの、従来でいう複数のリクエストが必要なwebページに対し、一番最初のリクエストが来た時点でサーバ側がwebページに必要なレスポンスを返すよう動く仕組み
  • HTTPSSSL/TLSハンドシェイクの流れ

    • 暗号化方式は多数に渡るため、実際の暗号化通信を行う前に両者で取り決めを行う
    1. クライント/サーバ間で暗号化方式の決定
    2. 通信相手(サーバ)の証明
    3. 鍵の交換
    4. 暗号化方式の最終確認
 ```

 - CDN (Contents Delivery Network)
   - コンテンツキャッシュサーバの集合体. エンドユーザからみると一つのキャッシュサーバに見えるようになっている。実際はアクセス元に最も近いキャッシュサーバが採択され、必要に応じて応答を行う

 - スマホアプリは大きくは2種類
   1. WebViewアプリ
     - スマホのブラウザを介してアプリの表示を行う
   2. ネイティブアプリ
     - スマホのブラウザ等は介さず、viewに関する部分はアプリ内部で処理を行い生成し、データの処理などはweb APIを通してやり取りを行うタイプ

 - ”情報セキュリティ”とは下記を3点を維持すること
    1. 機密性
    2. 完全性
    3. 可用性

 - 脆弱性おさらい
   - パスワードクラッキング ... 当たりをつけたパスワードでログインを試み、ID/PASS情報を入手する攻撃
     - ex) **ブルートフォース攻撃** ... ランダムな可能性のある文字を片っ端から試す方法

ウェアラブルトラッカー「fitbit Charge4」1ヶ月使用したけど買ってよかった。

www.fitbit.com

1ヶ月弱使用しましたが、買ってよかったと思います。

動機

不定愁訴(動悸・めまい・脚の不定期の痛み(週1,2)・疲れやすい・急な肩こり/頭痛など)が多く、 日常に不便を感じることにずっとコンプレックスを持っていたので 不調の原因がどこにあるのかをデータで確認した上で効果的に健康になりたい、 という動機でスマートウォッチの購入を検討し始めました。 主に以下を満たすものを探したところ、fitbitにいきつきました。

  • バッテリーの持ち
    • 持ちが短いとつけ続ける習慣がつかなくなりそうなので
  • 軽量
    • 腕時計をつける習慣がないので違和感を覚えたくなかった
  • ラッキングするデータ
    • 運動量/睡眠の質/心拍数

仕様と実際の使用感に差異があったか : なし

バッテリーの持ち

問題なし。公式ではGPSなしだと7日間と書いてあったが、ほぼほぼ同じくらいです。
充電はお風呂に入っている一時間で50%くらい(かそれ以上)充電できるので優秀かと思います。
充電が終わってないから待っている間に腕時計をつけなくなる...というのはあまりなさそうです。
ただ手首に接する本体側の汗による汚れが結構つくので気になる人は気になりそうです。

軽量

問題なし。大きな違和感はないので満足しています。

ラッキングするデータ

 精度は特に違和感なし!明らかな精度劣化などは今の所感じていません。

生活で変わったこと

  1. 食事見直しのモチベーションアップ

消費カロリーと摂取カロリー(手入力)で日常のカロリー収支が可視化されるので以前よりなにを食べてなにを減らすべきか明確になりました。消費カロリー > 摂取カロリーに努めて一ヶ月生活したところ、体重1kg減, 体脂肪率0.5%減しました。

  1. 継続的な運動へのモチベーションアップ

心拍数検知によって運動すると、fitbitが褒めてくれます。 また消費カロリー可視化により運動をするメリットを思い出させてくれます。

終わりに

データ取得と可視化の恩恵を得られたので良かったなーと思います。

だべる

半年〜一年くらいかけてリングフィットアドベンチャーで筋トレしてきて、 先月からようやく20分の有酸素運動してもめまいがしないようになってきました。(えらいわたし!!!)
ようやく世間で脂肪燃焼のためのアクションでよく言われる「週2,3の20分以上の有酸素運動」ができるようになった...スタートラインまで長い...だが自分頑張った!
筋肉量つける&脂肪燃焼で体軽くなったり、脚の冷えさよならとか、起きてる時間増やせたり...効果あると思うので引き続きストレスかからない程度に継続していきたい。 引きこもりなので有酸素運動はfitboxでトレーナーとほそぼそやっていきます。

fitboxing.net

要件定義 > システム仕様を行う際のポイントをまとめてみた

元資料

www.ipa.go.jp

「システム化要求定義」は「システム仕様」と言葉を変えている。
(あまり"システム化要求定義"に馴染めなかったのでより平易に記述したつもり)

まとめ

f:id:soachr:20200823221455p:plain
システム仕様の定義ポイントまとめ

所感

業務で要件定義に関わることになったのでポイントをまとめてみた。
フェーズごとの責務がふわっとしていたのが、少し具体的になれたと感じる。