勉強履歴(と雑記)

プログラミング初心者のメモ書きです

過去に受けたストレングスファインダーを振り返る

再び自己分析系の記事になります。
絶賛転職活動中で会社探しや面接を受けたりしてると、どうしても自分の内面に関心が向いてしまう機会が多いので仕方がないですね(?)。

2020年3月に受けたストレングスファインダーの結果を元に、自分という人間を考察してまとめたいと思います。
社会で働き始める直前に受けたものなので今受け直したら多少変動はしているのでしょうが、取り敢えずはこの結果で考えていきます。
以下が自分の34資質です。


上位5資質は以下の通りです。

1 回復志向
2 内省
3 慎重さ
4 分析思考
5 学習欲


逆に下位5資質はこんな感じです。

34 コミュニケーション
33 最上思考
32 活発性
31 社交性
30 ポジティブ


領域別で考えていくと、戦略的思考力の領域が1位から10位までの資質の内6つを占めており、 残りの3つが実行力の領域、最後の1つが人間関係構築力の資質である運命思考となります。
逆に影響力の資質は下位10資質のうち6つを占めており、人間関係構築力が残りの4つとなっています。
戦略的思考力と実行力が強みになりやすい反面、人間関係構築力と影響力は中々武器にできないタイプといった感じです。

この結果を簡単にまとめると、「一人で色々考えるのが好きで、自己完結してしまう目立たないやつ」になりますかね。
実際のところそんな感じの人間ではあります。良く言えば「思考力が高く自律性がある」、悪く言えば「頭でっかちなぼっち」です。
8位に責任感など、実行力の資質が上位に来ているので全く行動力がないわけではない(はず)ですが、何をするにしても思考が先だって石橋を叩いてから渡るので、行動のスピードは遅くなりがちです。
人間関係構築力に属する資質の幾つかは11~15位に固まっているので、人との関係を無碍にするようなタイプではないのですが影響力の資質が尽く下位に来ているので、理由がなければ積極的には関わろうとしない感じになります。


上位10資質をフル活用すれば、物事の問題や課題を見極めて(回復志向・分析思考)、情報を集め(学習欲・収集心)、情報を元に解決策を見出した(着想・内省)後は、確実に為すべきことを行う(慎重さ・責任感)ことができると解釈することができます。
ただ、影響力の低さから、放っておくと自分の頭の中で完結して満足してしまうので、折角集めたデータやアイデアは人前に出ることなく埋もれてしまいがちです。
そうなると宝の持ち腐れになってしまうので、対策としては忘備録といった形でSNSやブログなどにアウトプットして、ついでにネット上で公開していくのがベストでしょうか。
また、人間関係構築力や影響力の強い人と組んで、人前に出て変化を起こしていく目立ったことはお任せし、自分はその後ろで間接的にバックアップやサポートをしていく縁の下の力持ち(黒子？)になるのも一つの手だとは思います。

以下のページを参考にすると、私の好き嫌いは以下のようになります。

xn--bckg8a9ab8bxc5fpjscf3i.com

○好き

  • 問題の解決策を見つけること
  • 未知の分野の新しい情報や経験に出会うこと
  • 危険を回避するために注意深く予測し、事前回避すること
  • 静かな環境で思案し、関心ごとについて頭を働かせること
  • 客観的に正当性を検証された事実やデータ

○嫌い

  • 判断材料を与えられずに、性急な判断を求められる状況
  • 対処すべき問題から目をそらす考え方
  • 知ったかぶりや、人の意見に耳を貸さないこと
  • 物事に対し、考えなしに取り組むこと
  • まったく整理されていない意見や主張


これを踏まえると、自分の向いている環境・向いていない環境は以下のような感じになるでしょうか。
○向いている環境

  • 落ち着いて一人になることができる
  • 問題に対して柔軟に対応できる組織
  • 性急さを求めず、待ってもらえる
  • 合理性を重視する
  • 必要な情報は与えてもらえる

○向いていない環境

  • 多くの人が集まった騒がしい場所
  • 直ぐに結論が求められる、急かされる状況
  • 抱えている問題を見て見ぬ振りをする
  • 体育会系で精神論が強い
  • 必要な情報が隠されてしまう


6位から10位、25位から29位の資質も踏まえた場合、ウェットな職場よりはドライな職場の方が向いていると言えます。

最後に自分が転職先に考えているWeb業界とマッチしているかどうかについて考えていきます。
結論から言うと、やはり会社によるのかなと思いました。
Web業界は変化が早くスタートアップやベンチャー企業も多いことから、求人票によく記載されている求められる人材の素質としては、「とにかく早く動く」「急成長したい人」「やる気や熱意のある人」など、どちらかというと自分が不得手とするものが多い印象です。
ですから、就活していて本当にWebエンジニアで大丈夫かなと不安になってしまいがちでした。
しかし、今回の記事でまとめたように、自分には合理性や問題解決などWebエンジニアとして活かしていける強みがある他、環境的にはリモート勤務が可能な業態であることから向いているとも言えます。
結局のところは企業が何を重視しているかにより、「スピード」や「熱量」、「一体感」を優先するような会社とは合わない一方、「合理性」や「正確性」、「多様性」などを優先する会社とは合うというだけの話になるのだと思います。
ユニコーンよりはゼブラを探した方がいいのだということですね。
諦めずに就活続けていきたいと思います。

この診断自体約2年半に受けたものなので、改めて受け直してその結果を考察するのも良いかもしれません。
また、あくまで上記は自分で自分を振り返った姿なので、他の人から見てもらうためにコーチングを利用するのも一つの手ですね(90分で料金は1万ぐらいらしいです)。
長くなりましたが今回は以上です。

GithubのRelease機能

現RUNTEQ生の方たちが色々なポートフォリオをリリースしており、自分が作ったアプリよりも凄いものを作っているなぁと思う毎日です。
そんな中で各ポートフォリオのGithubリポジトリを見ていると、リリースから暫く経過したアプリであってもRelease機能を使用していない人が多く見受けられました。
他にもまとめている記事はたくさんありますが、ブログの更新ついでに簡単にまとめておきます。

バージョンについて

GithubのRelease機能は、アプリケーションのバージョン管理を行うために使用されます。
ソフトウェアのバージョン管理で良く使われるのはセマンティックバージョニングで、例えば現在Rubyの最新バージョンは「v3.1.2」ですが、この表記がセマンティックバージョニングです。

それぞれの番号は前から順にメジャー・マイナー・パッチバージョンと呼ばれ、アプリに施した変更に応じてそれぞれの数字を上げていきます。

メジャー： 互換性のない、APIを破る変更。
マイナー： APIのプロバイダーのみに影響する変更、または新しい下位互換性のある機能の追加。
パッチ： 下位互換性のあるバグ修正。

GithubのRelease機能を使ってバージョン管理を行うと以下のように表示されます。


手順

では、本題のRelease機能の使い方を以下に示していきます。
完結にまとめると、「Githubにあるタグ機能を使い、タグにバージョンアップの詳細情報をつけることで管理を行う」ということになります。

①最初にターミナルで以下のコマンドを入力してタグを作り、リポジトリの方にプッシュしておきます。「v~~」「version ○○」はそれぞれのアプリケーションのバージョンに合わせてください。

git tag -a v1.3.4 -m 'version 1.3.4'
git push origin v1.3.4


②リポジトリ画面のReleases部分をクリックすると、 バージョンの詳細内容がまとめられたページに飛びます。また、Tagsをクリックすると先程コマンドで追加したタグが確認できます。

③Draft a new releaseをクリックすると、リリースに関する情報を記入するフォーム画面になります。先程追加したタグを選択し、バージョン名とリリース内容を記載します。

タグを選択する際、まだ追加していないタグを入力すると下の画面のようにCreate new tagと出てタグを作成できるので、Githubの画面だけで完結させることもできます。

④入力が完了したらPublish Releaseをクリックすると、①のバージョン一覧ページに移動し、新しいバージョンが追加されています。また、リポジトリ画面のReleasesも変化しています。

⑤Publish Releaseをクリックする前に、latest releaseではなくpre-releaseの方にチェックを入れていると、表示が変化しています。

⑥一度出したReleaseを削除したい場合は、以下のコマンドでタグを削除すればReleaseも一緒に消えます。

git push --delete origin v1.3.5


以上となります。
Release機能は実用的な面以外にも、リポジトリの見栄えが良くなる(プロっぽくなる?)ので人によっては運用・管理のモチベーションが上がるかもしれません。

参考

セマンティック バージョニング 2.0.0 | Semantic Versioning
https://docs.github.com/ja/repositories/releasing-projects-on-github/about-releases
git tag と GitHub の Release 機能でプロっぽさを出してみよう - Qiita

原体験ドリブン

今日はRUNTEQ内のイベントで原体験ドリブンの著者であるチカイケ秀夫さんの公演があり、その中で原体験のペアワークを行いました。 折角なので、ワークの結果をログとしてブログに残して置こうと思います。

↓の本です。

note.com


ワークの内容としては、以下の５つの項目について自分で回答を書いておきます。 各回答に対して個人の場合は自分で、ペアの場合は相手の人から疑問を色々と投げかけてもらい、どんどん深堀りしていくものです。

  • 現在やっていること
  • 時間を忘れてできること
  • 好きなこと/好きな言葉
  • 苦手なこと/嫌いなこと/されて嫌なこと
  • 将来やりたいこと


今回のワークでは自分の回答は以下の通りになりました。 それぞれ細かく書いていくと長くなるので、箇条書きで行きます。 また、書いていたら色々と思い出すこともあったのでワーク＋αになってます。

1.現在やっていること

  • webエンジニアへの転職活動。
  • 前職がレガシーな業界(プラント・建築業)で、その働き方や紙・ハンコ社会に疑問を持ったのがきっかけ。
  • 上手いこと業務を効率化、ペーパーレス化させて、もっと働き方に幅を持たせられる社会にしたいなと思った。
  • 単純にカルチャーフィットしなかったのもある。
  • 2年前流行っていた某プログラミングスクール社長のYoutubeを見たのも関係しており、前職よりもエンジニアの方が向いているのではと思った。

2.時間を忘れてできること

  • ゲーム(特にRPG)。
  • 親が好きで小さい頃から親がプレイしているのを見ていた。
  • 自分がお腹の中にいる時、母親はFF6をやっていたらしい。
  • 自分が初めてゲームプレイしたのは6才くらいで、ゲームは遊戯王のやつ(城之内バージョン)だったと思う(RPGじゃない)。
  • ゲームの攻略本も好きで、ボロボロになるまで読んでた(FF4,5,6をまとめたやつとかロックマンエグゼ4,5など)。
  • 働き始めてからここ2年半ぐらいは封印していたが、最近ちょっとやった(ブレイブリーデフォルト2)。

3.好きなこと/好きな言葉

  • 中庸。
  • 今までの人生経験＋ニュース＋勉強の結果、身についた価値観。
  • 過ぎたるは及ばざるが如し。
  • いまいち原体験らしい体験や記憶はなく、あんまり深堀りできなかった印象。

4.苦手なこと/嫌いなこと/されて嫌なこと

  • コミュニケーション/長時間労働/怒鳴られること。
  • 凄く他人に気を使ってしまって消耗してしまう。
  • 中高の頃は今ほど酷くなく、大学入ったあたりから。
  • 大学はサークルに入らず、基本一人でいた。
  • 大学受験に失敗して第一志望に合格できなかったのがコンプレックスになり、その頃から人に対して疑心暗鬼になってしまったように思う。
  • 元々負けず嫌いな性格であり、運動はあまり得意ではなかったが、中学の時は勉強ができたことから、無意識の内に自分には勉強しか取り柄がないと思っていたのかもしれない。第一志望に受からなかったことで、コンプレックスに変化してしまった。
  • 前職が長時間労働で、自分は年次が若い＋積極的に早く帰ろうとしていたので常識的な範囲の労働時間(10~30h)だったが、周囲は月の残業時間45h以上は当たり前(人によっては100hオーバー)の環境で凄い嫌だった。
  • 残業する時は大体、紙の資料を印刷して折り畳んでクリップでまとめる作業だったように思う。もしくは、日中は各所からの調整で忙しく、自分のデスクワークが進められなかった時。
  • 自分も仕事しているはずなのに、しっかり仕事してないように思われるのが嫌だった。
  • 前職で目の前に座る先輩がよく怒られていて、割と自分に近いタイプの人だったのもあって、自分も怒られている気分で凄い嫌だった。
  • 数年前流行った半沢直樹が嫌いで、何故人気があったのか理解できなかった(怒鳴るような感じの演技が嫌)。親は見ていたので、横でイヤホンして見ないようにしていた。
  • 小さい頃、親が喧嘩する時は他の部屋に逃げていた。
  • あまり怒られるようなタイプではなかったが、怒られた記憶で一番古いものは、親の鼻歌が嫌だったので耳を塞いだら何故か怒られてしまったこと。

5. 将来やりたいこと

  • 何かしらの創作活動(1番可能性が高いのは絵)。
  • PF見ればわかるようにドラゴンが好きなのだが、残念ながら現実には存在しないので、
  • ドラゴン好きな人は絵などの創作活動で表現している人が多い。
  • ドラゴンが好きな創作する人の展示会などに行った時にも、何か創作やられるんですか〜と聞かれることがたまにある。
  • PFのイラストを発注する時も、自分で描けたら良かったのになあとか思ってた(まあ仕事しながらそんな余裕あったかと言われると‥)。
  • が、勉強が一番得意だったので美術とか工芸は学生時代あんまり興味なかった。
  • 転職活動中なのもあり、いまいちチャレンジするのに難儀している状態。
  • 自分の絵をネットに公開できるの凄い度胸だと思う。


ワークの結果を見て、以下の要素に整理することで自分の原体験を知ることができます。

  • 原体験
  • 過去の自分にアドバイス(原体験に関わりのある大人に言いたいこと)
  • 価値観(思い)
  • 過去の自分と同じ状況(環境)にある人/笑顔にしたいこと
  • 手段


自分の場合はこんな感じになりました。

  • 原体験
    →前職の経験、働いていた時のもやもや
  • 過去の自分にアドバイス(原体験に関わりのある大人に言いたいこと)
    →もう少し前職でやれたことはあったのではないか？
  • 価値観(思い)
    →長時間労働・非効率な仕事を良しとしたくはない
  • 過去の自分と同じ状況(環境)にある人/笑顔にしたいこと
    →労働の問題を少しでもなくしたい
  • 手段
    →IT(プログラミング)の力で


今回のイベントより前に本を読んで個人ワークをやっていたので、自分については割とすんなりできた感じです。
後、ストレングスファインダーで2番目に内省、4番目に分析思考が来る人間なので、自己分析が得意なのも関係しているように思います。

ただ、ペアの方の掘り下げはあまり上手くいかなかったです(申し訳ない‥)。
誘導的な質問はNGとされているのもあり、質問に窮する時が何度かありました。
先週読んだ、エンジニアリングマネージャーの本でコーチングについての記述があったので、それと同じ要領で行うのがベストなのかなと思いますが、中々直ぐには身につけられませんね。
何度かペアを変えてやってみた方が良いとのことなので、機会があればという感じですね

あんまり技術的な記事を上げられていないので、次辺りちょっとしたやつでもいいので上げたいですね。
今日はこんな感じで以上です。

エンジニアリングマネージャーのしごと

アウトプットの習慣を戻すと言っておきながら、前回から１ヶ月弱空いてしまいました…
この１ヶ月具体的に何していたかというと、RubyとRailsの復習および就活をしていました。
正直、今までやってきたことの振り返りが中心で新しく学習することは少なかったので、
ブログに書く必要あるのかなってしまって放置してしまいました。
技術的な話だけに絞ってしまうと更新が難しくなってしまうので、
もうちょっと関係ない話や雑記的な内容でもOKにして、取り敢えず更新を続けることを目標にしていきたいと思います。

最近は、8月末にオライリーから発売された「エンジニアリングマネージャーのしごと」をRUNTEQ内の輪読会で 読み進めています。
1週間に2章のペースで進めて、章ごとに担当者を決めてFigjamに整理した後に発表するという形でやっています。
私が担当したのは8章で、人が辞める時・人を辞めさせる時の対処法について書いてありました。
今回はそのまとめを文章化していきたいと思います。

1．人が去るのは普通

自分の人生やキャリアをよりよいものにするため人は会社を去るものです。
2018年のアメリカのテック業界での離職率は13.2％とのこと(ちなみに日本の2020年の離職率は14.2％、情報通信業は9.2% )。

https://www.mhlw.go.jp/content/11652000/000845829.pdf

辞めるパターンは自主退社と会社都合による退社の2つあります。

2．スタッフが去るとき(自主退社)

この本では、労働者の都合で辞める場合を良い退職理由、 会社・マネージャーとの関係に起因する退社を悪い退職理由としています。

良い退職理由は新しい仕事の機会・家族の都合・よりよい報酬があります。
良い退職理由の場合、マネージャーができることは以下の通りで、基本的には円満に送り出そうと言っています。

  • お互いに都合の良い退職日を決めよう。
  • リファレンスが必要かどうか確認。
  • 引き継ぎ。
  • 後任の採用。
  • 祝福して送り出す。


悪い退職理由は給料に不満があって辞める、同僚(チームメンバー)との関係が悪い、昇進の機会がない、新しい挑戦や仕 事をやる機会がないなどが挙げられています。
このような事態になってしまうのは、スタッフとマネージャー間で信頼関係が築かれていないためであり、未然に防ぐためにも普段の1on1で以下の内容について話をしておくべきだとしています。

  • キャリアアップ
  • マズローの欲求階層(スタッフ自身の自己実現についての話)
  • イライラすること

3．うまく戦う(残留について)

自主退社するスタッフに残留依頼をかける場合について書いてありました。
退職届が出された時点で転職活動済みの場合が多く、そうでなくても精神的には別の会社にいる場合が殆どなので、基本的には退職を受け入れて送り出すのがベターです。

ただ、そのスタッフがハイパフォーマーであり、会社に残ってもらうために生じる不均衡(賃上げや移動の埋め合わせなど)を受け入れられる場合は、残留依頼をかけてみても良いかもしれません。
まず、退職の理由を会話の中で特定し、解決できる問題かどうか検討します。
概ね、以下の理由が考えられます。

  • お金
  • キャリアアップ
  • 仕事の種類
  • フラストレーション


解決できそうであれば、上司・HR・部門内の他のマネージャーに協力を求めてカウンターオファーを作成します。
カウンターオファーを出して、スタッフが残留してくれればめでたし、気が変わらなくても最善を尽くしたとして気を病まないようにしようとのことです。

４．スタッフを辞めさせる(会社都合の退職)

会社都合でスタッフを辞めさせる場合の話です。
パフォーマンスが低く、仕事をこなせない人への対処としてPIP(業績改善計画)が挙げられています。
外資系でもない限り日本だと馴染みがない印象ですが、以下の点がまとめられているドキュメントのことを指します。

  • 現在の職務内容の概要
  • パフォーマンスや振る舞いの問題
  • PIPを通過するためのゴール
  • PIPの期間(1~3ヶ月が妥当)
  • マネージャーからのサポート


PIPが達成できなければ解雇ということになるので、脅しのような形では使うのではなく、他の方法でパフォーマンスを改善させようとしたけど失敗した場合に限り使うべきとのことです。
実際、PIPを悪用している会社もあるようでアメリカでは社会問題にもなっており、PIPで調べたら日本の外資系の企業で不誠実な使い方がされていると告発しているサイトが見つかりました(気になる人は自分で調べて)。

PIPを作成する場合は以下の点を検討する必要があります。

  • パフォーマンスの問題が根拠のあるもので、過去に本人へ伝えたか
  • 設定したゴールは達成可能で、期間内に終わるものか
  • ゴールの達成に必要なスキルが不足しているか、不足している場合は理由とサポートの方法を検討
  • 個人的な問題によるものかどうか


PIPが完成したら予めスタッフと共有したうえでミーティングを行い、調整を加えつつ相手の合意を得られたらPIP期間に入ります。
毎週進捗を確認し、スタッフの方に改善が見られた場合は晴れてPIPを通過、何事も起こらないパターンです。
逆に改善が見られなかった場合も、すぐ解雇はせずに正式な警告を出すのが妥当とのことです。
PIPに反したことを示すドキュメントを提示し、これが最後の機会であると伝えます。
これでもPIPに反するようであれば、その時が解雇となります。

解雇(リストラ)

上記の解雇はスタッフ側に問題がある場合ですが、何も問題がなくても解雇する時もあります。
リストラという名の業績悪化による人員削減です。

この場合の課題は次が挙げられています。

  • 解雇される側に何ら非がない。
  • 解雇される側にとって不意打ちになる。
  • マネージャーとしてもスタッフには去ってほしくない。


解雇を告げる際は怒りやイライラをぶつけられる可能性が高いですが、落ち着いてやるべき事をやりましょう。
告げる側も辛いものですが、一番辛いのは解雇されるスタッフの方なので乗り越えましょうとのことです。


以上が8章の要約になります。
すごく世知辛い話でした。
いつかは人を辞めさせる側に立つ日が来るかもしれないので、 その時は上記の内容を思い出して、離職がお互いにとってよい結果になるようにしたいですね。

解雇について日本は厳しいとよく聞くのでちょっと調べてみたんですが、次の記事によると欧州に比べたら実はそれほど厳しくないとのこと。

shuchi.php.co.jp

解雇のさせやすさはアメリカ＞日本＞欧米らしいです。
リストラをさせるのは日本より欧米の方が難しく、雇用者有利な制度となっているそうで。
ただ、日本の雇用形態はメンバーシップ雇用で総合職として雇用するため、ジョブ型のように仕事がなくなったからクビとは言えず、何かしら仕事を任せられるようであればクビにできないのが噂の実態とのことです。

折しもTwitterで連載されている「100話後に心が折れるスタートアップ」という漫画がそろそろ完結しそうなのですが、 それを見たのも合わせて人を雇うのも辞めさせるのも大変なんだなって思います。
今回は以上です。

久しぶりの更新

約1年間放置していましたが、アウトプットの習慣を戻したいなと思って更新します。
前回の記事がポートフォリオについての考えをまとめたものでしたので、
リハビリも兼ねてアプリについてちょっとまとめていきます。
あれから更に時間がかかりましたが、2ヶ月ほど前に完成させることができました。

www.dragon-twitter-analysis.com

結局案を思いついてから1年も経過してしまいました。
主な原因としては、以下の要因が考えられます。

  • 仕事を続けながら開発していたので、時間的なリソースがないのとストレスで難航。
  • 持ち前の完璧主義。
  • 人を頼ることができない性格。

1つ目はそのまんま。今は2ヶ月前に仕事を辞めて、毎日悠々自適に暮らしております。
有給消化期間でアプリをどうにか完成させたって感じです。

2つ目と3つ目は私の性格の問題ですね。
どうにも最初からハイレベルなものを作らなければと思ってしまう傾向にあります。
元からあるこの傾向に加えて、自分の通っていたプログラミングスクール(RUNTEQ)卒の受講生が作ったアプリが大体完成度が高く、
RUNTEQ卒の看板を背負うからにはと余計に気負ってしまった感じがあります。

また、自分の中では「人を頼ること＝人に迷惑をかけること」になっています。
人に貸しを作ることになるが、それを返す当てもないので甘えることができないというロジックです。
そのせいで分からないことを人に聞くことができず、一人で解決しようとして無駄に時間がかかってしまいました。

仕事の時はスイッチが切り替わるので、中途半端でも取り敢えず上司に成果物を出し、分からないことはタイミングを見計らって質問してました。
お金を貰って仕事をしている以上、自分のこだわりで他の人に迷惑をかけることはできませんからね。
ただ、私的なことになると上手く行かなくなってしまうのが我ながらネックだなと思います。

後はまあ、こんなアプリを作る以上私はドラゴンが好きなわけですが、
単純にそれを開示するのがとても恥ずかしかったのも割と関係しています(今はあまり気にならなくなりましたが‥)。

2ヶ月間のユーザー数とPV数はこんな感じです。
1回使ったらいいかなって感じのアプリであることがわかりますね。
もう伸びないと思いますが殆どのユーザーはRUNTEQ関係の人なので、ドラゴン好きな層など他のユーザー層に使ってもらえたら伸びる可能性は残ってますね(が、いまいちどう宣伝したら良いかが分からない)。

完成してから1ヶ月ちょっとの間はアプリの改修や修正を行ってました。
今現在はログインすればするほどレベルアップする機能を実装予定ですが、それに必要なイラストがまだ作成途中なので待ちの状態です。
この機能を最初から実装していたらもう少し使ってもらえたのかなと思いつつ、ひとまずアプリの改修は一段落させます。

最近は新しい勉強を始めています。
今はDockerでNext.jsとRailsの環境構築をやっていますが、中々上手くいきませんね。
コンテナ自体は立ち上がり、Next.jsの方は一応開発できるようにはなったのですが、
Railsとdb(MySQL)の接続ができていない状態です。
環境構築が終わったら、勉強目的でアプリをReact・TypeScript化していきたいと思います。
しょぼしょぼアプリですがなんだかんだ愛着はありますし、
初回時間がかかったので次はスピード感を持って実装するのを目的としています。
フロントよりのアプリなので、RubyとRailsの復習も必要ですね。

ぼちぼち就職しないといけないので、履歴書や面接対策・企業探しや研究など色々やることは山盛りですが、
ここまで来たらマイペースでもいいから1回絶対Webエンジニアになります。
長くなってきたので今日はここまで。

なぜこのポートフォリオを作ろうとしているのか

またしばらくの間更新をサボってしまってましたが、 現在もエンジニア転職を目指してポートフォリオを作成している途中です。
作ろうとしているアプリは以下のアプリです。

github.com

アカウントのIDを入力して診断ボタンを押すと、 普段のツイートに応じた診断結果がドラゴンの形で帰ってきて、 そのアカウントの人となりをある程度知ることができるアプリです。
READMEにも書いてありますが、このアプリを作ろうとしたより詳細な理由をまとめておきたいと思います。

何故このアプリを作ろうとしているのか

  • SNS(Twitter)を使い始めたが、匿名である以上攻撃的、乃至読んだ人に負の影響を与える内容の発信はどうしてもある
  • そのような発言を見るとモヤモヤする
  • 他人がそのような発言をすることはもちろんの事、自分自身も行っている可能性がある
  • 予め相手がどんな人間かある程度分かれば、SNS上だけに限定されるが、付き合い方の準備が出来る
  • 自分自身が周囲に与える影響も客観的に捉えることができて、SNSの使い方を改めるきっかけになる

何で診断結果を🐉にしたか

  • 自分が好きなだけ
  • 元々作ろうとしてたアプリを軌道修正した結果
    • ペルソナ診断を作ろうとしてた。
      ここで言うペルソナとは、ゲームペルソナシリーズに出てくる超能力のことで、この能力を持つ者は心の中にある自分自身を神話上 に 出てくる神や悪魔の形で召喚出来る。
      また、ペルソナはタロットカードの大アルカナで分類分けされており、心理テストを回答していき、その診断結果を神や悪魔で表現する予定だった。
  • ただ、以下の理由から挫折。
    • 自身がいまいち版権もので作るのに抵抗があった。
    • 一般的に神話とかタロットカードについて知ってる人は少なく、ゲームを知らない人には分かりにくいのではと指摘される。
    • 診断結果にイラストをつけたいと思ったが、公式の画像を使うわけにはいかないし、ココナラとかで頼んだとしてもかなりの数のイ　 　　ラストになるため、結構な額が必要となることが予想される。
  • ペルソナの中には一部🐉も含まれている。
    • 神話上の神や悪魔は、人間が作り出したものである以上、完璧な存在ではなく、どこか人間を反映した要素を持っており、それは🐉に も言える。
    • 🐉は西洋圏では悪の象徴とみなされる事が多い一方で、東洋圏では恐れの対象として神扱いされている。
    • 善悪関係なく強さの象徴として描かれる事が多く、一般の認知度が高い上にどちらかと言えばプラスのイメージがついている印象を受 けるため、診断の結果として表示するのにいいのではないかと思った。
    • 後イラストお願いするのであれば、自分が好きなものの方がいい。
  • ただ、ドラゴンの診断アプリは既に類似品が結構あったので、一捻り加える必要があった。
    • そこで、過去のスクール生のアプリを見ていたら、テキストの感情を分析して数値化するAPIを使って、その結果を診断の判定に使って いる方がいて、感情分析API面白そうだなと思って使おうとした結果、今の形に不時着した(ここまで来るのに４〜５ヶ月)。

類似アプリとの差別点(エンジニアチェッカーやきのこネガティブ診断)

まだ開発途中なので、現段階での話になりますが‥

1. 技術的な点

  • Vue
  • TailwindCSS

2. ユーザー視点

  • ユーザー登録機能で、診断結果を追うことができる(予定)
  • エンジニアチェッカーはインフルエンサーを撲滅する目的で作られた(基本は他の人が対象)。
    きのこは自分のSNSでの発言がネガティブになってないかをチェックするという自己管理の目的で作られた(基本は自分が対象)？
    このアプリは周囲に悪影響を及ぼしがちな人(悪いドラゴン)から自身の身を守りつつ、自分が周囲に悪影響を及ぼさないようにする(邪竜化)しないようにする目的なので、対象は自他両方。

エンジニアのアカウント診断 | エンジニアチェッカー

あなたのツイートのネガティブ度を診断します！ -きのこネガティブ診断-

まとめ

とりあえずですがまとめてみました。
ポートフォリオ用のアプリとしてどうなんだという気持ちも正直あります(二番煎じ、三番煎じ感が‥)。
元々業務改善系のアプリ作ろうとしていましたが、現実問題として厳しいことを知り、
今度は身近な課題解決系のアプリにしようとしましたが、どうしてもネガティブな感じになってしまってました。
だったら自分の趣味に走ってしまえという方向性で行ったらここに行き着いてしまった感じです。
完全オリジナルなんて今時無理でしょうし、初めて挑むことだからうまく行かなくて当然なので、ダメ元で取り敢えず完成させたいと思います。

Tailwind Cssの導入方法

久しぶりのブログ投稿になってしまいました。 現在、ポートフォリオを鋭意制作中です。

タイトルにもあるように、ここ数日は Tailwind Cssをポートフォリオで使おうとインストールしてました。 忘備録として残しておきます。

1. yarnでインストールする

CDNで取り込むやnpmでインストールする方法もありますが、 今回はyarnで行いました。

yarn add tailwindcss@latest postcss@latest autoprefixer@latest

2. Tailwind Cssの設定を行う

今回はapp/javascriptディレクトリの下にcssディレクトリを作って、 そこにtailwind.config.jsを置くことにしました。

cd app/javascript/css
yarn tailwindcss init

作成されたtailwind.config.js

module.exports = {
  purge: [],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

3.postcss.config.jsの設定変更

ホームディレクトリにあるpostcss.config.jsに以下の記述を加えます。

module.exports = {
  plugins: [
    require('tailwindcss')('./app/javascript/css/tailwind.config.js'),
    require('autoprefixer'),
  ]
}

4.tailwind.cssを作成してビルド

cssディレクトリ内にtailwind.cssを作成して次のように記載しました。

@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

その後、次のコマンドでビルドしました。

yarn tailwind build ./app/javascript/css/tailwindcss.css ./app/javascript/css/tailwindcss_dev.css

長いので、package.jsonのscriptを利用することでコマンドを省略することができます。

  "scripts": {
    "dev-css": "tailwind build ./app/javascript/css/tailwindcss.css ./app/javascript/css/tailwindcss_dev.css"
  }


私の場合はビルドしようとした時にpostcss plugin autoprefixer requires postcss 8というエラーが出てしまいました。 エラーが出た時点でのpackage.json

"dependencies": {
    "autoprefixer": "^10.3.1",
    "postcss": "^8.3.5",
    "tailwindcss": "^2.2.4",
  },

postcss8は入っているはずなのですがエラーが出てしまったので、tailwindcssも含めて互換性のあるバージョンに落としました。

yarn add tailwindcss@npm:@tailwindcss/postcss7-compat @tailwindcss/postcss7-compat postcss@^7 autoprefixer@^9

5. 実際に画面を表示させる

次のファイルにそれぞれ以下の記述を追記することでTailwind Cssが使えるようになります。 app/javascript/packs/application.js

 import '../css/tailwind.css';

app/views/layouts/application.html.erb

<%= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>

後は、自分の表示させたいページのclassにUtilityクラスを書いていけばOKです。 実際にページを実装していくことを考えると、tailwind.config.jsの中身を色々と設定していく必要がありますが、 長くなりそうなので今回のメモはここまでにします。

ちなみにTailwind Cssを使ってみようとした理由は以下の3つです。 ①好奇心 ②流行りらしいから ③名前が自分の作ろうとしているポートフォリオのイメージと合っている(？)

参考にしたサイト

tailwindcss.com

tailwindcss.com

Rails6でTailwind CSSを使ってみる