好き?依存?回避行動?

 

 

自分の好きなものがわからない。

 

 

いや、厳密にいうと

それが本当に好きなのか、依存しているだけなのか、何かを回避するためにやっているのかの区別がつかない。

 

 

高校生時代の自分であれば、何が好き?と聞かれれば、間違いなくポケモンと答えるだろう。

毎日ポケモンのネット対戦のことばかり考え、合計3000時間以上を費やし、世界一にも輝いた。

 

 

 

でも、それって本当に好きだからやっていたのだろうか。

レーティング対戦というゲーム開発者側が開発した、ゲームを長く続けてもらうための仕組みに踊らされ、

ポケモンというコンテンツよりも勝つことが好きで、たまたま勝つことができて、

それによって周りから認められていく体験に依存していただけではないのだろうか。

 

現に、世界一になった後は以前よりも勝てなくなっていって、

その状態でやるポケモンの感想は気持ち悪い以外に形容する言葉がなかった。

 

 

 

 

 

今はどうだろう。

ダンス、イラスト、プログラミング、読書、ブログ、YouTubeなど、わりといろんなことをやっている気がする。

 

でも、何一つとして自信をもって好きだと言えるものがない。

継続できている理由としては、やってて気持ち悪くならないからでしかない。

 

 

 

ゲームって、やったところで何が得られるのかよくわからないから嫌いだ。

娯楽のためのコンテンツに対して、何かを得たり成長できるかという観点でしか考えられなくなっている自分も嫌いだ。

それをやると気持ち悪くなってしまう自分も嫌い。

それを回避するために特に好きとも言えないことを継続している自分も嫌い。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

自分の成長につながらない行動を気持ち悪く感じる理由はなんだろう。

 

 

 

 

 

自分が成長しなかったところで別に何の問題もないのに。

 

 

 

 

 

 

勝つことと楽しむこと

 

もらった手札で最大限のプレーができて、

それでも負けた際に湧いてくる負の感情をどう処理していいのかがわからん。

 

 

確率を収束させるような競技で自分ができるのは、

その場面で最大勝率に繋がるプレーをすることだけなんだけど、

それでも悔しいって思っちゃうのは客観性が何よりも大切なその後の振り返りに支障が出ちゃう。

 

 

 

でも悔しいともなんとも思わなくなったら、勝って嬉しいとも思わなくなりそう。

 

 

結果に一切執着せず、その過程のみに執着できるようになるのが理想なような気もするけど、 そんな状態でモチベーションを保てる人間って存在するのかって思っちゃう。

 

客観的なデータとして算出される結果と、楽しむことの折り合いをどうつけていいのかがわからない。

 

よく競技勢が言う「勝つことが楽しい」っていう回答だと、どうしても目的が勝つことになっちゃってなんか歪んじゃう気がするんだけど、なんで歪むと思うのかが言語化できない。

 

 

 

正直、何にモヤモヤしてるのかもよくわからない

 

 

 

 

 

僕ぷろじぇくとりーだー。またチームを破壊する

 

 

 

3年前、人生初の「チーム開発」なるものを経験した。

 

当時の自分は他者を尊重するってことを理解できていなかったし、自分に対して自信も余裕もなかったと思う。

 

だから平気で自分の発言を押し通そうとするし、他者を蔑むようなことをしていました。

 

 

 

かと思えば次の日には長文でクソ真面目に謝罪してる。情緒不安定なDV男かよ。

 

 

今思えば、チーム開発とか、他者との関わり方とかそういうのを勉強し始めたきっかけって、この経験が本当に大きい。

 

 

それが理由なのかはわからんけど、当時に比べて反省点がぼろぼろ出てくる。

ぷよぷよが上達するほど、自分が下手に感じてくる感覚に似てる(多分伝わらない)

 

 

 

 

 

そんな自分が、1年間プロジェクトリーダーとして活動した諸々を書いていきます。

 

 

クソ長いので、興味のある部分だけ読んでもらえるとありがたいです。(前提条件だけは最初に読んだ方がいいかも)

 

 

 

 

前提条件

 タイトルで偉そうに「僕ぷろじぇくとりーだー」なんて書いてるけど、そのプロジェクトの実態は、単なる大学内のPBLです。

 

PBLってのは、企業がやってるプロジェクトを真似してお勉強しまちょうね〜って感じの活動のことです。

 

自分が経験したPBLの条件(活動)を挙げていくと、こんな感じ

  • 週1回3時間の活動
  • 活動に対する給与なし
  • 活動に対する単位取得なし
  • 参加は基本的に自由(学部1年〜修士2年が入り乱れる)
  • 年2回の企業発表あり
  • 学内サービスを開発
  • 基本オンラインで活動(新型コロナの影響)
  • 基本的に学業、研究、就活、アルバイトが優先される

 

正社員として働いたことがないので、企業さんのことは全然知らんけど

このPBLにはこのPBLなりの歪な難しさがあると思う。

 

まず、単位も出なければ、給料も出ない。

これって想像以上にでかい。モチベーションの最低限の基盤が存在しないってことだから。

 

だから、各々このPBLに対する「核」をもって取り組む必要がある。

 

仮にそれがあったとしても、チームがそれを大事にする文化がなかったり、

途中でその核を達成してまったり、そもそも途中でその核が変わってしまった場合は、もうそのチームに所属する意味がなくなっちゃう。

 

しかも、このPBLは基本的に学業・研究・就活・アルバイトよりも優先度が低いから、「核」はそれなりに大きいものでなきゃいけない。

 

とはいえ、リーダーがチーム全体のモチベーションをコントロールして、「俺についてこい!!」くらいことが言えれば話は変わってくるかもしれない。

自分はそんなこと全くできなかったんですけどねぇ。

 

 

そんでもって、PBLっていう特性上、メンバー各々の「核」が非常にぶれやすい。

  • とにかくサービス開発を体験してみたい
  • 知り合いがいるから入った
  • 意識高そうな組織にとりあえず入りたい(学部1年の時の自分💩)
  • 技術力を向上させたい
  • 人の役に立つようなサービスを考えたい
  • チーム開発を通じて大規模向けアーキテクチャを試したい
  • チームをマネジメントしたい

 

初めましての人や、ほとんど開発言語を触ったことがない人がいる中で、

これらの「核」が競合しないように、競合した場合は落とし所を見つけながら、1年間週1回3時間しかない中で活動していく必要がある。

 

その上で、「成果」と「学び」のバランスも考えないといけないのがえっちすぎる。

 

成果ってのは、基本的には開発するサービスのことです。

ある程度の成果が出せないと、日頃この活動をサポートしてくれている企業さんに面目が立たなくなる。

 

学びってのは、この活動を通じて得たものの総量の大きさって感じかな...?

せっかく入ってきてくれたメンバーをほったらかしにして、上級生だけでサービスを開発していくなんてことはあってはならないと思うし、そんな活動に自分はPBL的な価値はないと思う。

 

 

 

 

...なんか前提条件というか、難しさみたいなのをあげると、ただ単に文句言ってるだけに感じちゃうわね。

あくまで、こういう前提を理解してもらった方が、以降の項目が読みやすくなると思って書いています。

 

チームをリードしていく上で、こういう前提を理解した上で望むのは絶対に必要だと思うし、

与えられた条件下でどう活動していくかを考えていくことも、チーム開発の面白さだと思います。

 

 

 

 

 

 

 

まぁ、チームを破壊した人間がそれ言っても説得力ないんだけどね。

 

 

 

 

 

 

チーム崩壊を招いた最大の要因

 当初このチームは23人で活動していました。

それが、終わる頃には11人(ただいるだけの人を除くともっと少ない)になっていました。

 

無断欠席は当たり前だし、開発もコミュニケーションもうまくいかず最悪な状態にあったと思います。

 

 

自分も、最後の方はチーム状況を改善させようというより、「どうやってそれっぽく最終発表会を終わらせるか」ということしか考えていなかった。

 

正直、ここまで精神的に追い込まれたのは初めてだった。今振り返ると貧弱すぎんだろ。

 

チーム崩壊の原因は色々あるとして、大きく以下の2点に集約されるのかなって思う。

 

  1. リーダーの実質的な不在
  2. 他者を尊重することに対する履き違い

 

 

 

プロジェクトリーダーの実質的な不在

 前提条件で「核」の話をしたけど、自分にとっての「核」は、チームで開発することそのものでした。

 

PBLという歪な条件下で、自分たちなりの進め方を模索・追求していく。

顔も知らなかった新しいメンバーと、新たな視点を共有し成長していく。

 

はっきりいって、開発するサービスなんてどうでもよかった

 

 

 

プロジェクトリーダーってより、プロジェクトマネージャーって感じ。

そんな奴がプロジェクトリーダーをやると、実質的にチームのプロジェクトリーダーが不在になる。

 

 

そんな状態でメンバーがついてくるわけないんよね。

そもそもついていくものすらないわけだし。

 

 

 

 

 

 

 

このことに気づくのに半年かかりましたとさ。

 

 

 

 

 

他者を尊重することに対する履き違い

 3年前の初プロジェクトで、自分は他者を尊重することができず、結果としてチームを崩壊させました。

 

反省どころか猛省したし、2度とこんな過ちは繰り返すまいと、五臓六腑に刻み込んできました。

 

 

それがいつしか、「尊重すること」が「傷つけないこと」に挿げ変わっていました。

 

メンバーを傷つけないようにすると、いつまでたってもメンバー同士で意見がぶつかった際に意思決定ができない。

 

Aの意見を聞いて「あーそうだねいいねいいねー」って、

Bの意見を聞いて「確かにそれもそうだねーうーんどうしようねー」って、

 

そうじゃねぇだろ。意思決定はアイデア出しの発散フェーズとは真逆のことやりてぇんだろうが。

 

 

確かにメンバー全員の意見とか、意思はちゃんと聞くし汲み取っていく。

だけど、現状のチームのことを考えて最良の選択をする。それ以外は切り捨てる。

 

 

それでも、仮に意見を切り捨てられたとしても、

 

この人が決めたことについていきたい

 

そう思ってもらえるような行動や姿勢を見せていくことが、「他者を尊重する」ってことじゃねぇのかよ。

 

 

そのための努力をせずに、チーム開発でみんな1番だよーみたいな小学校の運動会みたいなことやってなんか意味あんのかよ馬鹿がよぉ

 

 

 

 

 

 

 

自分が目指したかったもの

 とりあえず情報系の大学に入ったから、意識高いっぽいことしてみたい!

 

2016年、当時学部1年生の自分は、そんなしょーもねぇ理由でこのPBLに参加しました。

 

実際のところ、こういった感じでこのPBLに参加する人は少なくないと思う。

PBLの参加を検討する下級生の話を聞いても、

 

「何から始めればいいですか」

 

みたいなことをすごく聞かれる。

 

「〇〇をやりたくて、○○の技術を扱いたいんですけど、詳しい人知りませんか」

 

みたいな聞かれ方をすることがほとんどない。

 

でも、だからこそ

 

「何をすればいいのかわからないけど、自発的に何かに挑戦していきたい」

 

みたいな子たちと一緒に成長していけるような場所を作りたかった。

1年間を通して、自分に自身が持てるくらい技術力が身につくような場所を作りたかった。

 

自分だったら、そういう場所を作れると思ってた。自分の能力をあまりにも過信しすぎてた。

このPBLの条件を考えると、「何かやってみたい」じゃあまりにも「核」が小さすぎる。

 

 

だからこそ、リーダーとして開発するサービスの価値を見出して引っ張っていく必要があった。

 

複雑な概念を抽象化して説明できるだけの技術力が必要だった。

 

メンバーの想いを引き出してあげられるようなコミュニケーション能力が必要だった。

 

 

 

 

いろいろ足りてなさスギィって感じだけど、まぁまだ23年間しか生きてないわけだし、こっからよな。

 

 

 

 

 

 

 

つらかったこと

 まともに(PBLがまともなプロジェクトと言えるかどうかは置いといて)プロジェクトリーダーなるものをやったのは今回が初めてだったんだけど、

無断欠席(or遅刻)されるがつらいったらありゃしない。

 

そもそも無断欠席されることがつらいってことすら想像してなかった。

鬱になりかけた一番の原因は何って聞かれたら、多分これを答えると思う。

 

なんであんなにしんどいんだろうね。

なんか知らんけど、自分のやってることを全否定された気分になるんよなぁ。

 

実際に何人かと1対1で話し合ったこともあったんだけど、結局対して改善されんかった。

気持ち的には幾分か楽にはなったんだけど、チームの成功を考えるとそれだけじゃダメなんよね。

 

 

あとは、孤独感をめっちゃ感じた。

誰も自分の味方をしてくれてないというしょうもない錯覚すら覚えた。

 

でも、それって単に自分のリーダーとしての能力が不足してるだけなんよね。

このチームで目指すことに対して、メンバー全員が同じ認識を持って、各メンバーに対して期待することをちゃんと伝えていれば、孤独感なんて感じないんやろなぁ。

 

それができたら苦労しないって話なのかもしれないけど、

じゃあ今以上にやりようはなかった?って聞かれると、全くそんなことはないし、

「難しい」ってのは、それに取り組まない理由にはならんよね。

 

 

あーあと、孤独感っていうと、メンバーにどれだけ弱みを見せていいのかって部分がすごく難しかった。

 

技術的な話であれば、

「ごめん、わからん。一緒に勉強しよう!」

で済むと思うんだけど、チームの方向性の話となるとそういうわけにも行かない。

 

「これからこのチームどうしていこうか...」

ってリーダーが言い続けるチームやばすぎやろ...

 

ちょうどこの頃、この辺について企業の社員さんとお話しすることが多かったんだけど、

一番納得できたのは

 

チームが目指す最終地点には絶対の自信をもつ、でもそこに至るまでの道には自信を持たなくていい

 

って話だった。

 

例えば、Twitterを例に挙げると、

ユーザの何気ない呟きを共有できるようにしたら絶対面白い!!って部分は自信を持つけど、

じゃあそのためにどうサービスを実装するかって部分は、わかんねぇ教えてくれーでも最悪問題ないって感じかな。

 

世間では当たり前の話なのかもしれないけど、全然知らんかった。

(というよりは、意識できていなかったって表現の方が正しいかな...)

 

そういう意味で、自分が目指す最終地点はサービスじゃなくて開発する環境そのものでした。

 

この辺から、

あれ、自分のやりたいことってプロジェクトリーダーじゃない...?

って思い始めた。

 

 

 

 

 

学んだこと

 学んだことについては細かいことまで書くと絶対ダレるので、特に印象に残った3つだけ書きます。 

 

良い悪いより、価値があるかないか

 この考え方めぇちゃくちゃ大事。多分誰かと一緒に何かをやる上で、一生使うことになると思う。

 

例を挙げるなら、

 

「オマエ、遅刻した。遅刻は悪いことダ。ユルサナイ」→ ドカーン

 

ってのが、良い悪いで考えるってことで、

 

「オマエ、遅刻した。どうすれば遅刻しないようにナル?それとも、そもそも遅刻って概念がないような体制を考エル?」 

 

ってのが「チームにとって」価値があるかないかで考えること(だと思う)

 

 

はっきりいって、良いか悪いかなんてどうでもいいんよな。

別に「悪い」ことしたチームメンバーを訴訟して、懲役を科したいわけじゃないんだし。(訴訟したいメンバーがいるチームは、そもそもチームじゃない)

 

リーダーがやるべきことは、メンバーを訴訟することじゃなく、最高の形でチームが目指す最終地点に導くことなんよな...

 

 

大体、人の行動の理由なんて、過去の体験と周りの環境と偶然がほとんどを占めてるんだし、多少やらかしちゃうのはしょうがなくね?

 

ものすごく極端な話をすると、過去の体験と周りの環境と偶然が噛み合っちゃったら、誰だって平気で殺人を厭わない人間になると思う。

 

だから、やらかした「人」が悪いって考え方をしてると、いつまで経ってもチームの状況は改善されない。

 

 

分野や領域に問わず、トップレベルの強ぇ人が優しいのって、「悪い」ことに目くじらを立てる無意味さを知ってるからなのかなって、何となく思った。

 

 

 

畏怖の言辞「そもそも」

  意思決定の場で交わされる言葉において、「そもそも」ほど恐ろしいものはない。

 

意思決定の場で大事なのは、メンバー全員の総合的合意を得ることだと思う。

だから、仮に自分が求めていたものは違った意思決定がなされた場合でも、どういった経緯で決まったのかを全員が理解しておく必要がある。

 

じゃないと、決まったことに対して疑問が残った状態で作業することになったり、途中で決まったことが簡単にひっくり返ったりする可能性がものすごく上がっちゃう。

 

 

だから、意思決定の場で「そもそも」って言葉が飛び出した瞬間、もうその段階から総合的合意が得られてないことがまるわかリング。

 

「そもそも」って言葉が出てくる原因は、以下のようなことが考えられると思う。

  • その人が今までの話を聞いていない or 聞くような環境が整っていない
  • 誰でもすぐに疑問を開示できるような環境が整っていない
  • 総合的合意が得られるような進め方になっていない 

 

 勿論、「そもそも」って発言した人は悪くない。(さっきも言ったけど、良いか悪いかはどうでもいい)

 

 

大事なのは、「そもそも」って発言が出てきた際に、チームで総合的合意が得られていないことを自覚して、その原因を精査し改善していくことだと思う。

 

 

 

オンラインによる孤立化 

 オンラインが中心の活動ってのは今年度が初めてだったんだけど、

正直なところ、オンラインの難しさを舐めてた。

 

コミュニケーションが難しくなるって言うのは勿論そうなんだけど、

新しく入ってきた子がめちゃめちゃ孤立しやすい。 

 

チームメンバーが顔見知りだったりすると、音声だけでもある程度相手の顔が浮かぶし、むしろオンラインの方が色々と楽だったりする。

 

なんだけど、周りに知ってる人がいないとそういうわけにも行かない。

ただでさえ緊張している中で、周りの様子が全然わからないって相当なストレスだと思う。

 

特にオンラインで話してると、同じところで複数の話題を話すことができない。

だから、必然的に重要度が高かったり、チーム内で知り合いが多い人の発言が中心になっちゃう。

細かく話すところを分けたとしても、そこに移動することそのものにハードルがある。(移動前にそこがどんな雰囲気かとか、どんなこと話してたかってのもわからんしね)

 

 

自分としても、調子どうよみたいな話しかけがすごくやりづらかった。

如何せん困ってそうとか悩んでそうとかがオンラインだと全然読み取れん...

 

 

改善策としては、オンライン通話のやり方を工夫するってのも大事だけど、

それ以上に何気ない雑談の機会を意識的に増やすってのが大事だと思う。

雑談を挟んだかどうかでチームの雰囲気って全然違ってくる。

チームにもよるんだろうけど、少なくとも自分はもっと雑談の重要性を伝えていくべきだった。

 

 

 

 

 

良かったこと

 自分は、このPBLをチーム全員が成長していける場にしたかった。(詳細は自分が目指したかったものにて)

 

結局、自分の力が及ばなくて叶わなかったけど、たった一人、

たった一人だけど、このPBLを通じてものすごく成長してくれた子がいました。

 

彼はTypeScriptの型エラーを、TSLintの設定を無理やり外すことでエラーが消えましたって言うような子でした。(静的型付け言語の意図をちゃんと説明しなかった僕が圧倒的に悪い)

 

それが今では、React、Reduxの概念を理解した上で、Atomic Designを使いこなし、さらにはAtomic Designの利点を理解した上でその問題点を指摘するまでに成長していました。

 

勿論、成長したのは彼自身の能力でしかないけど、

その成長に少しでも貢献できたこと、その成長過程を側で見られたことが嬉しかった。

 

 

自分が培ってきたものが、誰かの人生に少しでも貢献できるのって、本当に素敵なことだと思いましたとさ。

 

 

 

 

 

プロジェクトで使用(検討)したツール

 前提条件でも話したけど、今年度は基本的にオンラインでの活動だったから、ツールに関しては例年より考えることが多かった気がする...

 

Zoom

 オンラインの活動ってことで、最初に使ったツール

良い感じではあったんだけど、当時(2020年4月)はブレイクアウトルームや画面共有の機能が整備されていなかった(1画面しか共有できない等)ので、結局通話のツールとしてはDiscordを採用することに。

 

Discord

 本プロジェクトで採用した通話ツール

各メンバーがどのボイスチャンネルにいるのかがすぐに把握できるデザインが良き。 

チャットもできるけど、文章の共有はSlack、通話はDiscordで分けていました。

Slackを使わずに、通話とチャットとDiscordで完結させる方が良かったかも。

チャンネルとしては、サービスの役割ごとにボイスチャンネルを作って分けていました。

 

SpatialChat

 検討はしたけど、結局使わなかった通話ツール

通話に参加している人が円として表示されて、円同士が近いほど、その人の声が聞こえるようになるってやつ。

よりオフラインに近い感じにできるかなーって思ったんだけど、やっぱり遠くの声が聞こえるって言うのに限界があったし、どうしてもチーム開発で使えるまでは行かないかなーって感じだった。(普段はオンライン懇親会とかでよく使われているらしい)

 

Slack

 本プロジェクトで採用したチャット(?)ツール

例年このPBLで採用されているので、特に検討もしなかった。

チャンネルとしては、各メンバーの分報チャンネルを作るのが結構良さげだった。

やっぱ新しく入ってくれた子とかは、どのチャンネルで発言して良いかわからないみたいな問題が出てきちゃう。

そんな時に、呟き感覚で書ける自分用のチャンネルがあると、とりあえずそう言った問題がなくなるし、メンバー間で交流もしやすくなる。

他の候補としては、Microsoft Teamsとかがあると思う。

 

Google Drive

 本プロジェクトで採用した資料置き場

作成したスライドやポスターとかを置いて、メンバー間で共有できるようにしてた。

Drive上で共同作業するっていう用途ではあまり使ってなかった。

共有だけならDropboxでもよかったかも。

 

HackMD

 本プロジェクトで採用したオンライン版のホワイトボード(?)

マークダウン形式でメモとって共有できるツール。

とにかく軽いってのが最高。複数人で同時に書き込んでもほとんどラグがない。

何かしらの話し合いの最中に使ってることが多かった。

 

Trello (+ Elegantt)

 本プロジェクトで採用したスケジュール管理ツール

スケジュールはガントチャートで管理したかったんだけど、意外と20人規模のチーム用のツールって無料じゃ使えなかった...

だから、TrelloにChrome拡張機能であるEleganttを使ってガントチャートに変換してました。

使えることには使えるんだけど、いかんせんEleganttがめちゃくちゃ重かった...

これ以外で無料で使えるツールがあれば教えて欲しいです。

 

Miro

 本プロジェクトで採用したオンラインアイデア出しツール

オンラインでアイデア出しとかやったことなかったけど、かなり使いやすかった。

Miroに関しては、2つのボードまでは無料で使える。

1つのボード内に画像とかを配置しすぎると、どうしても重くはなっちゃう。

似たようなツールとしてMURALがあるけど、どっちも違いがよくわからんかった。

 

XD

 本プロジェクトで採用したモックアップ作成ツール

他にモックアップを作るツールとしてはFigmaがあるけど、どっちもそこまで使いこなしてないから、違いがよくわかってない。

本プロジェクトのフロントエンドはAtomic Designを採用してるんだけど、Figmaの方がAtomic Designと近い用語を使ってる気はする。

 

 

 

フロントエンドの開発環境

 フロントエンドの開発環境作りは結構頑張ったつもりなので、紹介させて欲しい。

使った諸々は以下の感じです。

  • 言語:TypeScript
  • ライブラリ:React、Redux、redux-saga
  • UIデザイン手法:Atomic Design
  • UI開発環境:Storybook

 

こういう技術選定になった理由としては、正直、自分が一番まともに教えられそうだからっていうのが最大の理由です。

 

そういった中で、如何にプログラミング初学者の子にも「チーム開発」を体験してもらえるかっていうのが大きなテーマでした。

 

Reduxとredux-sagaの考え方は一見複雑に感じちゃうけど、

強力な一方向のデータフローを実現しているから、1ファイルあたりの記述量が抑えられて、結果的に各ファイルの記述内容や意図が理解しやすくなると思った。

 

あとは、状態管理や通信処理をUIの記述部分から完全に分離できるってのがでかい。

これによって、プログラミング初学者の子はUI部分(or 通信処理)だけに集中して取り組める。

 

UI Componentの切り方(?)としては、Atomic Designを採用しました。

理由としては、メジャーなUIデザイン手法の中で最もUI Componentの分割が細かかったからです。

ビジネスが絡むサービスの場合は、もっとまともな理由がないと話にならないんだろうけど、自分がこのPBLに対する認識的にはこの程度の理由で問題ないと思った。

 

あとは、Reactの良さを活かしやすいってのも大きかった。

何かしらの技術を学ぶ上で、その技術の良さを実感できるかどうかってものすごく大事だと思う。

 

Atomで基本的なReact Componentを理解

 → OrganismsでReactの再利用性やデザイン手法の利点を理解 

 

みたいな流れをイメージしていました。

 

 上記の勉強用サンプルコードを書いていたので、是非ご意見いただけると嬉しいです。

(諸々の説明はREADME.mdにあります) 

 

 

 

それと、勉強用サンプルコードには導入してないんだけど、Storybookってのがめちゃめちゃ良かった。

 

作ったComponentを一覧で見られるサービスなんだけど、これがあるおかげでデザインのレビューが凄くやりやすかった。

デザイナーさんとのコミュニケーションが取りやすくなるのも大きなメリットだと思う。(うちのプロジェクトではそれは実現しなかったけど...)

 

 

 

 

 

おわりに

  今年度は、本当に精神的にしんどかったー。

多分周りからしたら何も変わってないと思われるんだろうけど、かなり心に傷を負った1年間でした。

 

それだけに、得られた学びは大きかった。

心に傷を負ったのも、それはそれで良かったのかなと。

 

「傷ついたことがないから、他人に何を言ったら傷つくかがわかんないんじゃない?」

 

って言われたこともあったくらいだし。

 

内容はかなり吟味してまとめたつもりだけど、グダグダな文章になっていないかとか、逆にまとめられすぎて軽い感じになっちゃってないかとかが心配。

 

 

 

内容の質はどうであれ、少しでも役に立つようなことが書かれていれば幸いです。

 

 

あと、感想とか読者の実体験とかツールの話とかコメントでもらえると嬉しいかも。

 

 

 

 

 

 

 

 

 

 

 

2020年に読んだ神本TOP3

 

 

 

第三位 なぜ世界のエリートは「美意識」を鍛えるのか

 複雑で変化の激しい現代において、論理的思考だけでは太刀打ちできないよね。

っていう話の展開から、どのように「美意識」を活用していくべきかってことが主張されてる。

 

人間の直感ってもっと単純化された領域でしか役に立たないイメージだったけど、かなりその認識が覆された気がする。

 

今までは論理的思考と美意識は対になる存在で、各々が活躍する領域はお互いに独立していると思っていただけに、「美意識を論理的思考で支えていく」っていう考え方は新鮮で、自分の視野がグッと広がった感覚がありました。

 

 

 

第二位 習得への情熱

 チェスと太極拳推手の両方で世界トップクラスだった男のお話。

彼の人生を振り返りながら、どのようにチェスや太極拳推手を極めていったのかが書かれている。

 

物事の本質を見抜くことや、それをどのように磨いていくことかという話もかなり参考になったけど、

何よりも練習や試合中におけるメンタルの話がかなり強調されていたのが印象的だった。

自分が思っていた以上に、筆者の経験はメンタルが成長や勝利に大きく関与していた。

 

改めてメンタル的な部分を考えさせられるきっかけになったし、以前自分が学んだこととの共通点もあって自信にもなった気がする。

 

 

 

第一位 相手は変えられない  ならば自分が変わればいい

 人間の悩みのほとんどと言われる人間関係において、マインドフルネスと心理療法ACTという療法の観点からどう向き合っていくかということが書かれている。

 

自分も読んでびっくりしたんだけど、基本的には恋愛における人間関係の衝突がベースに書かれてた。

とはいえ、誰かと協力する機会があるなら読む価値あり。

というか、誰かと良好な関係を築いていきたいなら必須級の本だと思った。マジでイチオシ。

 

はっきりいって、生温いことは書いてなかった。

真剣に、難しいけど、どう自分や相手と向き合っていくかが書かれてる。

小手先のテクニックではなく、人間として生きていく上での1つの大きな考え方を学ばさせていただきました。

 

良好な人間関係を築く上で、善か悪かは重要ではなく、価値があるのかが重要である

 

間違いなくこの考えは一生使っていくことになる。

 

自分は昔チーム活動で大失敗をしてて、それ以来チームにおける組織づくりについて結構勉強してきたつもりだったけど、この本に勝るものはなかった。

というよりも、真っ先に読むべき本だと思った。

 

 

 

 

 

エロ漫画の女体模写が最高に楽しい

 

 

 

タイトルが既にきめぇ...

 

 

正直、最近は性に関する書籍を読むことも減ったし、関心も薄れていたんだけど、

 

結局何歳になってもえっちぃことが好きなんだなぁって

 

 

 

 

最近、エロ漫画に出てくる全裸女性を模写することにハマってしまった

 

 

 

イラスト描いてる時間って、不思議とめっちゃ集中できるよね

(塗り絵したことある人なら共感してもらえるはず)

 

 

 

いかんせん自分は重度のSlack依存症なんで、何か一つのことに無心で集中できる時間って最近本当に少なくなってしまった...

 

 

 

 

そんな中、寝る直前の1時間で、えっちな女の子のおっぱいとか、おしりとか、むちむちのふとももとかを描くのが憩いの時間になりつつあるのです

 

 

 

 

 

実際に模写してみると、エロ漫画家すんげぇってなるわ

 

一本一本の線が生きてるんよ。

 

本当に繊細なバランスで成り立ってるんよ。

 

少しでも崩れたら、むちむち感やもちもち感は失われる上に、そもそも人体のパーツとして脳が認識できなくなるんよ。

 

 

 

ど素人の自分でも感じるんだから、ある程度イラスト描ける人はもっともっと

いろんなことを感じられるんだろうなぁ

 

 

 

 

 

 

 

とはいえ、この趣味にはデメリットもありまして

 

 

 

エロ漫画をおかずにしようとした時に、

 

 

「あ、次これ模写してみたいな」

 

 

とか

 

 

「ここのふとももの表現力はんぱねぇ...」

 

 

とか考えてしまって、なかなかに興奮しづらくなっちまった。。。

 

 

 

エロ漫画の模写は、メリットとデメリットをよく考えてからやろうね

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

需要がある訳ないけど、最近模写したイラストを載せておきます

 

1年後くらいにめちゃめちゃ成長した姿を見せられることを願って

 

 

f:id:bluestick_believer:20201216221048j:plain

 

 

f:id:bluestick_believer:20201216221055j:plain

 

 

f:id:bluestick_believer:20201216221101j:plain

 

 

f:id:bluestick_believer:20201216221113j:plain

 

日本人 × Atomic Designによって直面する"オーガニズム"問題

 

 

 

 

 

Atomic Designについての説明は割愛させていただくが、

本記事を読む上で、「User Interfaceの整理術」程度の認識で問題ない。

 

 

 

 

Atomic Designを扱う上で、Organisms(オーガニズム)という単語を使用することは避けては通れない。

 

 

 

この「オーガニズム」という単語を聞いて、何を思い浮かべたかを正直に答えていただきたい。

 

 

 

 

 

 

 

 

 

 

そう。生物や有機体といった意味だ。

 

 

 

 

 

 

天下のGoogle先生に聞いてみても、この事実は揺るがない。

 

 

 

 

 

f:id:bluestick_believer:20200505164225p:plain

 

 

 

 

 

 

 

 

 

 

...イカれてやがる。

 

 

 

 

 

 

 

 

オーガズム(Orgasm)とは、骨盤周りの筋肉にリズミカルな痙攣を伴い、強い快感を生んだ後に弛緩状態に至るものであり、

オーガニズム(Organisms)とは全く関係ない。

 

語源も、スペルも、イントネーションも異なる。

 

 

 

しかしながら、日本では頻繁に、"オーガズム"が"オーガニズム"と誤って使用されている。

この何気ない誤用が、日本に甚大な被害をもたらす。

 

 

 

 

 

 

 

例えば、頭精子畑な男子大学生に、Atomic Designを教える状況を思い浮かべて欲しい。

 

 

 

Organisms という単語が出現する度に、頭精子畑の頭の中には、女性が快楽に溺れる映像が浮かんでしまうだろう。

 

 

 

そうなってしまっては、もはやAtomic Designの話をしている場合ではない。

 

一刻も早く、己の欲望を、己の右手で、開放しなければならないという重大なタスクが発生してしまう。

 

 

 

 

 

 

 

Atomic Designが優れたUIデザイン手法であることは、わざわざ私が述べるまでもないことであろう。

 

しかし、日本で、特に性欲旺盛な男性がチームにいる場合は注意が必要だ。

 

"オーガニズム"の誤用については、形容し難い憤りを感じるものの、長い年月を経て染み付いた誤用を正すことは困難である。

 

 

 

そのため、私たちはこのような問題があることを認識および理解し、

チームメンバーや環境に応じて、対策を講じていく必要がある。

 

 

 

 

 

【2019年】人生を変えてくれた本

 

 

スタンフォードの自分を変える教室

- 「意志力」とは何なのか

- 「意志力」にどのように向き合っていくべきなのか

ってことを、とにかくわかりやすく教えてくれる。

 

いや、本当にわかりやすい。

 

翻訳された日本語の文章からでも、

筆者の「柔らかな言葉でわかりやすく伝えよう」という意志や想いがガンガン伝わってくる。

 

 

「意志力」ってのは、知識とそれに基づいた工夫によってどうにでもなるんだってことを教えてくれる1冊。

 

 

 

 

人生が変わる最強の呼吸法

人間は1日に約22000回の呼吸をし、10分間呼吸できないだけで死んじゃう。

呼吸は生命を維持する上で最も重要な行動であることは間違いない。

にも関わらず、あまりにも呼吸に関する知識が足りなさすぎた。

 

「深呼吸はするな」

とか

「酸素が足りないのではなく、二酸化炭素が足りていない」

といった、今までの自分の常識をぶっ壊すような知識が目白押しだった。

 

 

何よりこの本を読んだおかげで、

長年の悩みだった鼻詰まりの症状が改善された。圧倒的感謝。

 

 

 

最高の体調

「健康」とは何かということを極限まで濃縮した1冊。

 

ここでいう「健康」ってのは、

怪我とか、病気みたいな話じゃなくて、

ぼんやりとした不安に襲われるとか、なんかだるいとかそういう話。

 

心身の不具合における原因ってのはいくつもの要素が複雑に絡み合っていて、

それぞれの要因に対してどう向き合っていくべきかを科学的観点から解説してくれる。

 

 

 

この本が2019年の自分を形成してくれたと言っても過言じゃない。

 

 

この本のおかげで、

自分が本当にやりたいことを見つけられたし、

集中力も尋常じゃないくらい上がって、毎日がわくわくしてしょうがない。