なぜ心理的安全性は必要なのか?
ここ最近心理的安全性についてあれこれ考えたことをつらつらと書いていく。
※個人の見解です。夜寝れないテンションで頭の中を空にするために書きました。
結論として、心理的安全性は、チームに「健全な衝突」を起こせるようにするために必要であり、成長していくに必要不可欠な土台であるので必要である。
バズワードとしての心理的安全性
「心理的安全性」という言葉はバズワードのように扱われ、誤解を生みやすい存在である。
たとえば、「仲が良い」状態を心理的安全性が高いと言っていたり、「きついことをストレートに言う」状態を心理的安全性が低いと言っていたりする。
しかしこれはよくある誤解であり、心理的安全性を理解していない。
心理的安全性が高いとどんな状態になるのか?という点から見ていく。
心理的安全性が高いチームでは「挑戦や成長が促進される」状態になる。
言い換えれば、「失敗から学び、成功に達せる」と全員が理解している状態である。
このようなチームでは、チームでの失敗は共有され、積極的にメンバーは挑戦を行い、そこからまた得た失敗から学びを共有しあいゴールに向かって成長していく。
逆に、心理的安全性が低いチームの状態の例をあげてみると「絶対にミスが許されない環境で、かつ誰にも相談ができない」状態のチームになる。
この状態のチームでは、以下のことが起こりうる
- 失敗を共有しないので同じ失敗を他の人が繰り返す可能性がある
- ミスを恐れ、挑戦をしなくなり、言われたこと以外をしなくなる
- ミスを隠す
- 相談が行われず、独りよがりの解のまま進んでしまう
- マネージャーは自分のミスを作りたくないので、マイクロマネジメントが増加する
- 健全な衝突ができず、衝突を避け、飲み会での愚痴が増える
- 思考が完璧主義に寄り、他人に厳しくなる
- 他責思考になる
- 会議で誰も意見を発しなくなる
中でも健全な衝突を出来なくなるというのが際立って組織レベルでは問題になる。
問題があるにも関わらず、問題が声として浮かび上がってこない。
次に、上辺だけの関係なので面従腹背の状態となり飲み会での愚痴が増える。
そのまま物事は改善されることがなく進むので、疲労感から他責するようにになったり、メンバーの持つ知識を活かしきれなかったり、時には転職という手段にも繋がる。
健全な衝突を起こせるように、心理的安全性が必要になる。これが理由である。
身近にある例
実はこの状態を簡単に誰でも観測する方法がある。それはTwitterでバズっているツイートのリプや引用リツイートを見る方法である。
Twitterでは名前も知らない人の意見に対して自分の意見を添えてツイートする機能がある。引用リツイートのことだ。
この引用リツイートを用いて、あるツイートで発している内容に対して別の見解を述べるケースがある。
ここで本来行われてほしいのは、別の見解から得られる新たな気づき、そこから生まれる総合的な解への発展、そして見解をくれた方への感謝だ。
しかし現実はそう上手くは回らない。平気で初手から見解が甘いことを理由に人格否定が行われるケースもあるし、議論がエスカレートした結果、人格否定が行われるケースもある。
残念ながら、心理的安全性が低く、匿名性が保たれてしまうとこのような結果になってしまうのである。
場面場面で見ていく。
まずAさんがある主張ツイートを行う。この主張ツイートは自分の経験から得た考えを共有するものである。
次にBさんがAさんの主張に対して自分の見解で少し否定的なものを乗せ、引用リツイートする。BさんはAさんとは当然別々の人生を歩んでおり、経験も全く異なる。だからこそ根底の価値観が異なり別の見解が生まれる。
AさんはBさんの主張を見る。
ここで、もし自分がAさんだったらどうするだろうか想像してみてほしい。
名前も知らないような人から急に否定的な意見が投げつけられ、自分の経験を否定されるのである。
感情をコントロールできる人であればBさんの主張ある価値観を探るために対話を始める。
しかし、人間の本能はそう出来ていない。攻撃されたら防御のために攻撃をするのである。
当然インターネット上で自分をバカだと晒したくはないため、自分の主張を正しいとするためにBさんに対して反論を行う。
これは無知を晒したくないという心理的安全性が低い状態で発生する行動である。
また、その主張を見てブロックする行動にでる可能性もある。これは衝突を避けるという心理的安全性が低い状態で発生する行動である。
そして反論されたBさんはどう感じるだろうか?これも同様に、無知を晒さないために自分の主張をより強固なものにするため言葉が強くなっていくのである。
そうして次第に人格否定が行われ、いつの間にか勝敗に焦点が当たっているのである。
これを社内・チーム内で、起こしたくないのであれば心理的安全性は必要なのである。
人間は前に進むのは簡単に出来るが、後ろを見たり、進んでいる途中で止まるのは本能的に難しい。
だからこそ理性で後ろを見直したり、立ち止まる勇気を出す必要がある。
おわりに
今のようなトレンドの移り変わりが早い時代では、機敏に失敗から学びを得て、それを成功に繋げる必要があり、さらに自分たちも成長していかないと取り残されて行ってしまう。
ここまであえて使わないようにしていた言葉だが、この時代に対応するにはアジャイルな思考・概念で取り組んでいかなければいけない。
アジャイルに行うために心理的安全性はステップ0として必要不可欠なものなのである。というのもこの話のもう1つの言いたいことである。
深夜寝れなくて深く考えずに考えたことを書きました。後で起きて恥ずかしくなったら消すかもしれません。
やむのワクワクツールマガジン Vol.2 RunCat
RunCat
RunCatとは?
ネコがあなたのMacのメニューバーに住み着き、ひたすら走ります! ネコはあなたのMacのCPU負荷に応じた速度で走ります。ネコの走りっぷりを見ることで、現在のCPU負荷がどの程度かわかります。 動画の書き出しやプログラムのビルドなどの待ち時間にネコを眺めてみるのはいかがでしょうか?
メニューバーに常駐するアプリケーションで、CPUの使用率やメモリの使用率によって動作が早くなる指標として使えます。
機能
メトリクス機能
設定によって
- CPU負荷
- メモリ性能
- バッテリー状態
- 容量
- ネットワーク接続状況
を表示できるため、サクッとPCの状態を確認でき、大変便利です。
詳細機能
このメトリクスが割と詳細まで見られて、
- ネットワーク情報
- バッテリー容量(温度や充放電回数が見れるので劣化具合も分かる)
- メモリの使用量
が分かるため、アクティビティモニタを確認する必要なく「あ、今メモリ使いすぎててやばいからなにか終了させたほうがいいな」と分かります。
かわいい
やっぱりParty Parrotはかわいいから眺めてて楽しいよね :party_parrot:
やむのワクワクツールマガジン Vol.1 Fig
Fig
Figって何
エレガントな補完
Zshをカスタマイズしている人ならご存知だと思いますが、zsh-autocomplete
とかに近い機能をもっと簡単に導入できます。
個人的にはFigのが使いやすく、zsh-autocomplete
等はMakefileで活用する場面があるものの、Figを入れてからはFigばっかり使うようになりました。
package-jsonに定義したscriptsもちゃんと補完がでます!
統合可能
ターミナルアプリごとにカスタマイズが必要な拡張をしてしまうと、VSCodeのターミナルでは使えなかったり、PHPStormのターミナルでは使えなかったり、iTerm2でしか動かなかったり、不必要なベンダーロックに苦しんでしまいます。
しかし、Figは統合可能なため、デフォルトのターミナルやiTerm2, Hyper, VSCode, Tabby, JetBrains,などなどほとんどのターミナルをカバーしています。
なので移行というよりは、拡張になります。とっても楽でいいですね。
Figのここがすごい!
IDEのように補完を出してくれる
ポップアップでIDEのように補完を出してくれます!しかも説明も含めているため「あれ、このコマンドなんだっけ?」ってなった時に補完があるので検索する手間を省いてくれます。 :party_parrot:
対応しているCLIが多い
例だけでもGit, NPM, Docker, heroku, SSH, Scripts, Google Cloud, AWS これらのCLIに補完が対応しています。
「あっ・・・このCLIは対応してないんだ・・・」と思った時でも、自分が補完を定義できるため定義ファイルを書いてしまえば補完を出せるようになります。
導入が簡単
アプリをダウンロードして、セットアップすれば完了!(メールアドレス登録は必要か忘れました)
導入
アプリ入れて、setupに2~3stepすすめるだけ。
まとめ
まじで便利なのでぜひ入れて試してみてください
The 20th Anniversary of TDDを聴いたメモ
9.The 20th Anniversary of TDD の回において頭に残ったフレーズをメモってます。
テストにはCheckingとTestingがある
Checking
品質を向上させないテスト。(=品質を維持する) リグレッションからの保護を主とした目的にするテスト。リファクタリングや機能拡張などの変化についていくために必要である。 既知であるものを、既知であり続ける。 最低限動作してほしいものを確認する。
Testing
品質を確認するためのテスト。 創造的で認知の外からソフトウェアをテストする。エラーを見つけるために創造的破壊行為を行う。 探索的テストと言われることが多い。 テストファーストは一番最初はTestingになる。
品質を向上させるにはCheckingとTestingの両方必要
既知のであるものを、既知であり続けるCheckingと未知のものを探りにいくTestingの両方が品質向上には必要である。 テストコードでTestingの領域である「未知の探索」を行い、未知を既知にすることでCheckingとしてテストコードに残すことが可能になる。そうすることで未知がだんだんと既知になっていき、予想外のエラー・バグというものが潰されていく。
品質を向上させていくという同じゴールを目的にして進めるのが大切。DevOpsの 「KPIを追い求めていくと同じバスに乗っていても同じ向きを向いていない」 話になる。
ロールの「固定」より「循環」
ある日はTestingを行うテストエンジニアというロールにしたり、ある日はCheckingを行うエンジニアというロールにするロールチェンジをチーム内で循環させることが出来たら知見は深まっていく。
そのまとめは・・・
Software Design 2022年3月号に書いてあるってよ。もう買った。
CircleCIからAWS SAMを使ってLambdaにデプロイする
実現したいこと
AWS SAMでLambdaに勝手にデプロイしてくれたら嬉しい。
前提条件
samconfig.toml
があるtemplate.yml
がある
出来上がったyml
version: 2.1 orbs: aws-cli: circleci/aws-cli@3.1.1 sam: circleci/aws-sam-serverless@3.2.0 executors: node: docker: - image: cimg/node:18.2.0 resource_class: large commands: aws-auth: description: AWSとOIDCで認証を行い、認証情報を環境変数にexportする steps: - aws-cli/install - run: | aws_sts_credentials=$(aws sts assume-role-with-web-identity \ --role-arn ${AWS_ROLE_ARN} \ --web-identity-token ${CIRCLE_OIDC_TOKEN} \ --role-session-name "circleci-oidc" \ --duration-seconds 900 \ --query "Credentials" \ --output "json") echo export AWS_ACCESS_KEY_ID="$(echo $aws_sts_credentials | jq -r '.AccessKeyId')" >> $BASH_ENV echo export AWS_SECRET_ACCESS_KEY="$(echo $aws_sts_credentials | jq -r '.SecretAccessKey')" >> $BASH_ENV echo export AWS_SESSION_TOKEN="$(echo $aws_sts_credentials | jq -r '.SessionToken')" >> $BASH_ENV source $BASH_ENV deploy-dev: description: SAMを利用してdev環境のLambdaにデプロイを行なう steps: - sam/install - run: command: | sam deploy \ --config-file samconfig.dev.toml \ --no-confirm-changeset jobs: deploy-dev: executor: node steps: - checkout - aws-auth - deploy-dev workflows: version: 2 deploy: jobs: - deploy-dev: context: - lambda_deploy
はまりどころ
OpenID Connectを使ってCircleCIとAWSを連携させる
参考資料(2つの記事で補完しあっています) CircleCIがOpenID ConnectをサポートしたのでAWSと連携させてJWTを使用したAssumeRoleを試してみた CircleCIとAWSをOpenID Connect 認証で連携する
参考資料をもとに、Contextを作成し、IDプロバイダIAMを作成する。
IAMを作成したらRoleを割り当て、ここで作成したContextにAWS_DEFAULT_REGION
とAWS_ROLE_ARN
を設定する。
SAMからLambdaにDeployする最小ポリシーが難しい
AWS初心者に優しくないポリシーしてました。
参考資料 AWS Lambdaのデプロイに必要なIAMポリシーについて
上記の参考資料から
CloudFormation
DescribeStackEvents DescribeStackSetOperation CreateChangeSet DescribeChangeSet ExecuteChangeSet GetTemplateSummary DescribeStacks
-> すべてのリソース(stackのregion指定するだけでもダメでした)
IAM
GetRole PassRole DetachRolePolicy CreateRole DeleteRole AttachRolePolicy UpdateRole PutRolePolicy CreateUser
-> すべてのリソース
S3
GetBucketTagging GetBucketWebsite GetJobTagging GetObjectVersionTagging RestoreObject GetBucketAcl GetBucketNotification GetBucketPolicy GetObjectVersionTorrent PutObject GetObject GetIntelligentTieringConfiguration GetObjectTagging GetMetricsConfiguration GetBucketLocation GetObjectVersion
-> Bucket name指定くらいまで
Lambda
GetFunction CreateFunction UpdateFunctionCode DeleteFunction AddPermission ListTags (参考資料にないけど)
-> Function指定くらいまで
ここがとてもつらかった。
感想
CircleCIよりもAWSのポリシーのがとっても苦労しました。
追記
- すでにデプロイされたLambdaに対する権限のみで、デプロイされていないLambdaには追加で権限が必要になりそう
- ROLLBACK権限等も足りていない部分があるので要調査かも
CicleCIのクレジットを無駄遣いしてしまった話
CircleCIでは実行時間に対してクレジットを使う
戒めポイント1 無闇にSSHしない
実行時間に対してクレジットを消費してしまうため、無闇にSSHなどしてしまうとキャンセルするまでは実行時間カウントされてしまうのでよほどじゃない限りやってはいけない。
有識者的にはSSH Debugで動く方法確率させてからymlに落とし込むほうがいいらしい。なるほどなぁ。
戒めポイント2 最低限記法などは確認してから実行する
記法等で無駄にビルドが走ってしまうのはとっても勿体ないので、最低限の記法などは確認してから実行するほうが良いです。
Homebrewでcircleciのcommand line toolsをインストールすればlocalで実行確認ができます。
brew install circleci
circleci config validate
基本的にCI上で確認を行なう作業はCI環境依存の問題だけにとどめたい
戒めポイント3 規模が大きくなるまではリソースを抑える
たとえば、大きな resource_class (CPU 4基、 メモリ 8 GB) を使用して 1 分あたりのクレジット数を増やし、大規模なプロジェクトのビルドを高速化することができます。一方、小規模なプロジェクトでコードのリリース頻度が低い場合や、ビルド時間を重視しない場合は、小さな resource_class (CPU 1基、 メモリ 2 GB) を使用できます。
config.yml
でresource_class: small
を指定すると1分あたりのクレジットが減る(その代わり遅いけど)
largeは並列化とか使わない限り必要なさそう?
SSHするときはsmall, 並列でバリバリ動かしたいときはlargerでもいいのかな、という見解も最近は出てきました。
番外編 M1Macでもローカルで動かしたい
M1 Macでは現状 Docker executorは対応していないらしい :cry:
https://circleci.com/product-roadmap/
余談
1000クレジットくらい無駄遣いしてしまった。
1人アジャイル
1人アジャイル
アジャイルの本質って
アジャイル(すばやい・俊敏な)と言葉からも分かるように、「いかに短い期間で仮説検証のプロセスを回せるか」というのが本質という話を聞きました。
https://open.spotify.com/episode/4XxazWssiQyVocnaIUu9J7?si=9221dca6a64347cb
自分はふんわりとした理解で「合意形成を取って進めていくもの」「チームビルディングをしっかりして進めていくもの」「顧客のことを第一に考えるもの」とアジャイルを誤解していたと思います。
そこで考えたのが、「仮説検証のプロセスを短い期間で回す」ことが本質であるのであれば、これって個人レベルにも落とし込めることが可能だと思いました。
イテレーションの中で仮説検証を繰り返す
スクラムではスプリントの終わりにレトロスペクティブがあります。
これはスプリントの終わりに行なう反省会のことで、ここでYWT(やったこと・わかったこと・次にやること)やKPT(Keep, Problem, Try)を考え、これからを見直して、目標にむきなおる会のことです。
「みんなでやるものだから一人ではできない」と考えていましたが、本質から考えるに「一人でも十分実施可能」ということがわかりました。
たとえば、1日というイテレーションを定め、個人レベルで「ふりかえり」を行なうことです。
自分の中に内在する「良くない習慣」や「今日の失敗」を省みることができ、明日に向かって「これはこうしたほうがいいんじゃ?」という仮説を建てることができるため、明日に「検証」ができることになります。
これは「日」というイテレーションで区切っていますが、もっと小さくすることも可能で、それがみなさんがよくご存知の「ポモドーロテクニック」だと思います。
25分という時間の中で集中し、5分間の休憩で25分の中のふりかえりを行なうイテレーションなのです。
他にも週次レビューや月次レビューで粒度を大きくして分析することも可能だということです。
他にも悟ったら追記
5月の報告
学びの5月
5月が音速で過ぎていきました。
5月は技術面が多めで、ヒューマンスキル系のインプットがなかなかできなかった中で、「DXはこういうことなんだなぁ」という既存で定義がなあなあになっているものに対して理解が深まることもありました。
5月にやったこと
CULTIBASEにハマった
4月からだとは思いますが、CUILTIBASEのPodCast等々聴いていて、見事ハマってしまいました。
安齋先生の書籍を読みつつ、CULTIBASEの動画を見ています。
問いかけの作法は万人におすすめができる内容で、自分みたいな下っ端からできる「問いかけ」のhowなどが載っているのでとても参考になります。ぜひぜひ購入してほしいです。
ジャーニーシリーズを読んだ
1人からチームにスクラムを波及させていくカイゼン・ジャーニーでアジャイルのプラクティスを知ることができました。
本通りに物事がうまく行くわけではないですが、「こういうモデルケースもあるよ」といったニュアンスで捉え、似たような事象が起きたときに都度参照したいな、と感じる書籍でした。
ディジタルトランスフォーメーション・ジャーニーについては、上記で少し話した「DXに対する理解」というものが深まる書籍でした。
今までは「DXはデジタル化すればいいんでしょ〜」「業務プロセスの見直しがDXだよね〜」みたいな「わかった気」ですませていたのですが、「これからの組織のあり方を変える」機会になるのがDXなのかなぁとまた「分かった気」になりました。
DDDに入門した
DDDに入門しました。いままでは「興味があるけどな〜、実践機会ないしなぁ」みたいな感じでなあなあになっていたDDDですが、触れる機会が出てきたため、本格的に触り始めることができました。
DDDをやりはじめて「あれ、自分全然オブジェクト指向理解してなくない?」と感じてしまったこともあり、オブジェクト指向の再入門から始めています。
ここらへんやっぱりLaravel使ってるとかなり意識的にしない限りはトランザクションスクリプトで書いてしまうので、何かしらのエキスパートの手ほどきは欲しくなるかな〜といった所感。
オブジェクト指向のこころはとても良い本で、自分の基礎力構築に役立ってくれると確信しています。
t_wadaさんがおっしゃっていましたが、この時代のピアソン・エデュケーション本はオブジェクト指向の第一次パラダイムを変革している書籍なので、今の土台になっているんだなぁと。
良いコード/悪いコード 通称ミノ駆動本ですが、これも様々な書籍からのエッセンスを分かりやすく噛み砕いて説明している書籍だったので理解しやすく勉強になるな〜と感じました。
技術書読むのが苦手な人とかに結構刺さるのではないかな、と個人的には感じる部分も
TypeScript
うひょー氏の入門本でやっとちゃんとTypeScript入門しました。意外とPHPみたいに書けるなぁと思える反面、「型で表現する」というパラダイムに面白さを感じました。
オブジェクト指向中心になるので、型エイリアスをバンバン使うことはあまりないのですが、ちゃんとIDE上で怒ってくれるあたり親切だなぁと思いつつ、今日もany型と戦っています。
アジャイルへの理解が深まった
アジャイルって単なる手法かと思っていたのですが、そうではなくて、「仮説検証のリードタイムをいかに短くするか」がアジャイルの本質だったんだなぁとCULTIBASEを聴いていて思いました。
「仮説検証のリードタイムをいかに短くするか」が本質であるのであれば、これって個人レベルに落とし込めるのではないか?と感じました。が、これは別記事でまた話そうと思います。
6月は
オブジェクト指向の理解を深め、DDDに対する理解も深めたいと思っています。
片手間で組織開発やファシリテーションについて勉強しつつ、どこかしら小さいチームでLTなどをして少し自分が苦手な「話すアウトプット」の力を鍛えて行きたいと考えてます。
4月の報告
あっという間に過ぎてしまった4月だった。
ブログも結構サボっていてしまったので、5月はもう少しアウトプットを増やしていきたいと思う。
インプット期間
部署移動と空白期間
3月で去年の10月頃から外れ、部署移動を行うことになった。(希望した)
急な部署移動変更希望でもあり、自分に割り当てられる仕事がすぐには出来ない、ということで勤務中の学習期間として時間に余裕ができた。
LaravelでGraphQLをどう扱うかを学習したり、GraphQLのスキーマ設計・スキーマ定義のベストプラクティスを探していたりしていた。
4月の第一週はその作業だけで終えてしまったわけだが、第二週は割り込み処理で別の仕事を進めていた。
同時にプライベートで興味が出て学んでいた組織開発・組織文化・チーム開発の経験を積みたいと感じ、社内プロジェクトに乱入していった。
ランニングとポッドキャスト
3月中旬頃から始めたランニングが今でも続いている。その背景としてcouch-to-5kとポッドキャストがある。
Couch to 5k
Couch to 5Kというものがある。これは、9週間で何も運動をしていなかった人が5km走れるようになるプログラムであり、挫折しにくいプログラムである。ちなみに以下の本で知った。
歩きとランニングを交互に混ぜることが多く、苦じゃない。結構おすすめ
ポッドキャスト
今ままでポッドキャストを聴く習慣がさほどなかった。ランニングを始め、ランニング中の暇つぶしとして聴き始めたポッドキャストだが、学びのレベルが1つ上がったように感じる。
主に聴くのは以下である。
中でもfukabori.fmは自分の中の見聞を大きく広げてくれる存在である。
問いかけの作法の回を聴いて、[問いかけの作法]を購入した。(すごく役に立っている)
問いかけの作法は万人に勧めたいくらい内容が濃く、今後の人生でファシリテーションしていく必要が出てきた際に大きく役立ってくれるのだと直感した。「お通夜ミーティング」から発生する「孤軍奮闘の悪循環」の話や、Howの話が盛りだくさんで興奮した。面白い。
GoFデザインパターンの回は有名なtwadaさんが出演し、かなり興味深い話をしていた。デザインパターンを学ぶ前に聴くとデザインパターンが生まれた背景・意味・現在必要なものがわかるので、学習効率がかなり向上すると思われる。
あと、心理的安全性の回はゆめみの代表片岡さんが出演する会で、心理的安全性について興味深い話がたくさんあった。
今まで自分が理解していた心理的安全性は表面的なものであり「ちゃんと理解していなかったのだな」と感じたし、「心理的安全性を高めるには」という問いに対して真摯に考えるきっかけになった。にしてもゆめみの組織構造・取り組みはとても参考になる事例が多い。
とまぁ、話し続けるとキリがないのだがポッドキャストは現代の情報で溢れかえった海から厳選された情報が著名人というフィルターを通して聴くことができるのでキャッチアップの質としてはかなり高い部類なのだと理解した。あと面白い。
ポッドキャスト以外にも本は色々読み進めていて以下の本を読んだ。(読んでる)
ヒトと組織
技術からヒトへ
3月まで技術のことにしか興味がなかった自分が、今では大きく興味の領域が変わった。
おそらく焦点が「自分」から「組織」に変わったのだと思う。自分の成長はもちろん大切だが、自分が成長した先に何があるのか?と考えた際に結局は「組織」が先にあるのだと感じてしまった。
自分の中のミッションとして、「携わるヒトすべてが幸せになる」というものがある。
それに直結するものとして今までは「良いテストを書く」というミクロな視点だったが、よりマクロな視点で見るようになった。
チーム開発手法や自己組織化する考え方、人はMIssionで動く、学習する組織、尊敬、謙虚など。
正直まだ全貌が全く掴めていないが、日々この分野のインプットを進めている。
仕事では
社内プロジェクトにいくつか参加し、本やポッドキャストから得た知識を上手く利用しながら良い方向に向かうように働きかけた。
まず、自分が参加時点でミッションがなく、ビジョンがない状態であったため、Whatから考えてしまっている状態に見えた。
その状態では空回りする可能性が高く危険だった。
なのでMissionから向き直すためにと、いろいろな疑問をぶつけた。(問いかけの作法が大いに役立った)
MTGを経て軌道修正を行なったり、作文して考えを伝えるのが4月の主な仕事だったと言える。
まだまだ不完全な状態で他にも良いやり方があるように感じるので、もっと本を読みつつカイゼンしていくつもりだ。
技術もぼちぼち
5月からTypeScriptを書くことになりそうなので必死に勉強している。
また、DDD案件に関われそうなのとミノ駆動本も発売されたということでコーディング技術も高めたい欲がある。
リファクタリングの本も途中で止まっているし、ポッドキャストから得たデザインパターンの話からちゃんとデザインパターンを学び直ししたい気持ちもある。やることが多い状態だ。
まとまりのない形で思考を垂れ流すだけの記事になってしまった。読みやすい文章を書くように頑張りたい・・・。
5月もとても忙しそうな月になりそうだ。
1年目エンジニアの内省〜マインド編〜
はじめに
前の記事から1ヵ月半程度しか経っていないが付け加えるという意味で今回文字に残す。
2/14の段階で「今年度はこんなもんだろ」と思い、書き上げてしまったがブレイクスルーは突然くるものだった。期間は関係ない。
技術的な面でのブレイクスルーはないが、精神面、マインドの面でのブレイクスルーが大きかった。
今回は前回記事に付け加える形で、前回記事の「ふわっと」していた部分を明確なものにしていく。
転職活動という刺激
実のところ12月から転職活動をぼちぼち進めていた。TechTrainを利用させていただいて、数社と面接をしたり、メンターの人と話す機会があった。
メンターの人や他企業の人からのフィードバックはある意味真の客観的目線になる。真は言い過ぎである程度偏りはあるだろうが、社内やコミュニティなどの今後の人間関係を気にしたフィードバックではない。
この転職活動が自分の中に変化のきっかけを与えてくれた。最終的に転職はやめた。
考える力
発端
一番自分の弱点として浮き彫りになったのは、考える力が乏しいということだった。
TechTrainの小澤さんと何度かキャリアの相談を行っている最中に浮き彫りになってきたポイントだった。
考える力と言ってしまうと曖昧すぎて何を指すのかがいまいち伝わりにくい。なので少しここではスコープの狭めた言い方に変える。なぜ?と考える力が足りていなかった。
これは実際の会話のやりとりである。
小澤さん「yum3は食べ物で何がすきなの?」
ぼく「・・・ラーメンですかね?」
小澤さん「なぜラーメンが好きなの?」
ぼく「・・・塩分がたくさん取れるから・・・?」
小澤さん「それってラーメンじゃなくても良くない?塩舐めればいいし」
ぼく「・・・たしかに!(なんで自分はラーメンが好きなんだ)」
と一見他所から見られたら「大丈夫かコイツ」となる状況なのだが、自分は割とよく食べるラーメンについて好きな理由を的確に述べることができなかった。これがなぜ?と考える力が足りていないことの理由である。
これは好きな食べものに限った話ではなく、直感的に良いと感じ終わっているものに対して同様の事項が起こりうる。
自分は感覚派な部分があり、この問題に直面していた。転職活動でなぜ? と聞かれる場面は多くあったが、自分は「体裁上、ロジックに矛盾がない程度に」答えていたことに気がついた。上っ面マンだったのである。
変化
この「なぜ?」と考える力を鍛えるためにはどうしたら良いのか?
それは単純で、物事に対して「なぜなぜ」と自問自答していくことが一番為になると小澤さんから教えてもらった。
ただ何日も「なぜなぜ」と考えるが、自分の中で納得できていない・咀嚼できていない部分があり、なぜ「なぜなぜと自問自答すると良いのか」(今思うとここで「なぜ」と思えているのが成長なのかもしれない)という疑問の答えが見つからずに悩んでいた。
そのときネットで調べていて出てきたのが「言葉にできる」は武器になる。であった。
自分は技術書はたくさん読むが、ビジネス書は嫌われる勇気と幸せになる勇気くらいで(これがエンジニアを目指すきっかけとなった)他には興味がなかった。
結果から言うと、「言葉にできる」は武器になる。は自分の求めていた答えそのものだった。(1章と2章しか読んでないが)
本書では、言葉が意見を伝える道具であるならば、まず、意見を育てる必要があるという方針をもとに、「内なる言葉」で意見を育て、「外に向かう言葉に変換せよ」 と述べている。
内なる言葉というのは
無意識のうちに頭に浮かぶ感情や、自分自身と会話することで考えを深めるために用いてる言葉
であり、「声には出していないが自分だけには声として聞こえること」が該当する。
つまり、「なぜなぜ?」と向き合うことは「内なる言葉と向き合い、意見を育てている」ので、良いとされている。
また、この内なる言葉を書き出してT字型思考法を使い考えを深めていく方法が自分の中に腑に落ちた。
詳しくは本書を図書館等で借りて、ぜひ自分で読み噛み砕いて理解してほしい。
今後
本書にかかれていた「自分との会議」を行いつつ、自分についての解像度を上げることが必要だと感じた。
「なぜ?」だけではなく、「本当に?」と問いかけることで体裁上の答えをしていないか考えられるのも大きい。
この自問自答を繰り返していくうちに、「本当に自分のやりたいことは転職して手に入るのか?」「転職をする本当の理由は?」「転職で解決するのか?」という論題にも触れていき、棚卸しをすることが変化のきっかけになったのだと感じる。
余談だが、就職活動でよく言われる自己分析や志望理由はこのなぜ?と考える力が必要で、自分に対してなぜ?なぜ? を繰りかえしていかなければならないのである。
「なぜ?なぜ?」を知ってから思考のアウトプット記事がこっちで
言葉にできるは武器になる。を読んだ後の思考アウトプット記事はこっち
他責思考
「自分は他責思考ではない」という誤解
自分は他責思考ではない。考えるまではそう思っていた。
プログラムが動かなかったら自分のせいで、今の自分がいるのも自分のせいである。他人は関係ないという認識は常に持っていた(当たり前ではあるが)
しかし、1つだけ他責思考になっていた部分がある。それは環境が悪いということだった。
ただ最初から他責思考ではなかったと思う。理由として、自分はエンジニアになりたいと思って入った専門学校がIT系資格取得しか目指していない専門学校だった(大原ではない)
数年後自分がなりたいと思っていたエンジニアがWeb系エンジニアだということに気づいてから学校は意味のないものになった のだが、「自分がこの学校を選んでしまったのが悪い」と思い独学でプログラミングを学んだ。
学校の環境が悪いなら変えようと思い、副校長に直談判しに行ったこともあった。結果変わらなかったが・・・。
つまり、ここで言いたいのは「組織は変わらないもの」という「先入観」を持ってしまい、環境が悪いとどうすることもできないという考え方を持ってしまっていたということだった。
ラベリングと役割
新卒で会社に入社し、上司を持ち、新卒の扱いを受ける、ごく普通の流れだ。
人間は無意識にラベリングをし、役割が人を作る。
つまり、新卒 というラベリングを受けて、新卒 という扱いを受けていると「自分は新卒らしく振る舞わなければいけない」「新卒なので会社のことを全く知らない」「新卒は学生気分」のような考えに近づいていく。
そうなってしまうと発言は減り、ある程度会社の内情を知るまでは黙ってしまう。負の連鎖である。
「新卒だから優しくしよう」だとか「新卒だからゆっくり伸びていってもらおう」というのもラベリングが悪さをしている。別に新卒じゃなくても優しく接するべきだし、新卒でなくてもゆっくり伸びていってもらえれば良いじゃないか。
会社の雰囲気・構造を変えようと思って新卒を雇い始めたが、新卒を新卒として扱っているようでは変わらない。そしてこの状況が多く起きると「新卒を雇うのは会社の考え方に染めるため」と言われてしまう。
そして、これは他の事にも言える。上司だから伝えづらい、PMは何もわかっていない、社長は末端のことを全く理解できていない。といったことだ。
新卒じゃないからイノベーションを起こせないのか、そうではない。誰にだって変えることはできる。 そのマインドが重要なのではないだろうか。
会社への不満と他責思考
他責思考の話に戻るが、「自分は新卒だから何もできない」「自分は新卒だから会社をよく知らない」といったように「自分は新卒だから」を言い訳にチャレンジを過度に恐れ、「会社に不満があったら会社が悪い」と思っている節があった。そして転職活動に繋がったのである。
実際はラベリングに屈していた自分が一番悪いのであり、会社側は変革を起こしてもらいたいと思っている。むしろ「自分が今抱えている不満」を感じているのは「良い方向に変えていくチャンス」なのではないかと考えるようになった。
「文句を言っていればいずれ変わる」から「自分から変えていく」マインドに変わり、積極的に社内への活動を行うようになり、「ただ淡々と日々の仕事をこなす」だけから抜け出したことで毎日の仕事がより一層楽しいものに変化した。
これからも自分ができることを考えつつ、積極的に行動していけたら良いと思っている。
余談
ラベリングの話はEM.FMのep1.Engineering Managerの魅力から知見を得た。
ランニング x 技術Podcast最高と思いつつ、週3日でランニングをしている。
ちなみにPodcastを聴くという習慣は、転職活動の面接で相手をしてもらった方から共有してもらった。ありがとう転職活動。
環境のせいにしているのではないか?と考え始めたきっかけは「原因」と「結果」の法則で、言及されていたからである。少し宗教寄りの自己啓発だが考え方は参考になる。
再現性
今何もできていないのに他で何ができる?
転職活動を行っていく中で 「再現性」 が大切という話を聞いた。
自分が今の状況で何も成し遂げていないのに、他の場所に行ったからといって何かを成し遂げることはできるのだろうか?
もちろん成し遂げられない場所もある。ただ自分が今いるこの場所で成し遂げられることはあると感じていて、成し遂げられればそれは大きな経験になると思った。
これから
やりたいこととキャリア
やりたいこととは何か、積んでいきたいキャリアとは何か?ということを考えていった時に自分の中にある理想像というのは、エンジニアリング・マネージャーが近いと感じた(察している人もいるだろうが)
自分は開発者には幸せに開発してもらいたいと思っているし、デザイナーには幸せにデザインしてほしいと思っている。つまり、チーム・組織レベルでのマネジメントを行い、チームの生産性・メンタリティを高めていきたいのだと感じた。
今まで技術以外のことには触れない人生であったが、この変化によって他のことも勉強しようという気持ちが強くなっている。
今はまだ技術の知識も浅く、マネジメントの知識も浅いが「良くしていきたい」という気持ちを忘れずに精進していきたい。その過程で「自分はまだ知識が浅いから」というラベリングでチャレンジを恐れるのではなく、積極的に機会があればチャレンジをしていきたい。
チームや組織の最適解はない、人によって背景は違うし価値観も異なる。その不確実性の中で良い方向に向かっていけるようにマネジメントしていける、そんな人間になろうと思っている。
とりあえずはピープルマネジメントの領域をいろんなケースを見つつ、学んでいくのが2年目のタスクなんだろうな・・・と思っているそんな次第である。
参考資料
本
EMという概念についてはこの本から得た