【書評】「さあ、才能に目覚めよう」は全く色あせていない
さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0
- 作者:トム・ラス
- 発売日: 2017/04/13
- メディア: 単行本
この本は、2011年に購入した。今は2.0というのがあるが、購入したのは1.0(2.0とついてないもの)。 勝間和代の帯が若干恥ずかしいんだけど、それは置いとく。
社会人も11年目になる、この本は入社して2年目くらいに買った本で、 何かのサイトでお勧めされていたと思われるが、そのまま積読してしまった。
そして今、自分は色々社会人として悩んでいる。 このままだらだらと仕事をこなすのか、思い切って環境を変えるのか。 そもそも自分は何がしたいのだろう?microsoftの澤さんがいうように、beingを考えたとき 自分はどうしたいんだ?と答えが出せなかった。
そんな時にふとこの本を思い出した。 自分の才能ってなんだろう。と。 そしてこの本にあるストレングスファインダーをしてみたという流れである。
この本は、7章まであるが、大まかに3部構成になっている。
- 才能についての説明
- 自分の才能の活かし方
- 他人の才能の活かし方
前半中盤と、自分と向きあう内容になっており、これはこれですごく役に立つ。 まず自分の才能がなんなのか。 40分くらいのテストに回答すると、34種類の才能の中から特に特徴的な5つを発見してくれる。
自分の場合は、過去に述べた通りである。
その才能をとりあえず受け止めることにした。 直感と外れていないし、自分にとってこうありたいという内容と近いからだ。
しかし、この書籍で(期待していなかったが)嬉しかった内容は終盤の 「他人の才能の活かし方」である。 昨今withコロナで働いき方が否応なしに改革されている中で、 この本に書かれている内容は非常に重要だと思う。全く色あせていないどころか、今読むべき本なのかもしれない。
さて、他人の才能の活かし方、と書いたが、 他人というよりも部下にあたるかもしれない。 これはマネジメントに近い話である。 部下に何を期待するのか、どう接するのか、どう評価するのかなど。
自分の場合は部下というよりチームメンバーにあたるが、 年齢的に一番上というのもあって若干マネジメントのようなこともしている。
その際に漠然と思っていたことがこの本に書かれていた。 自分の中では、こういうチームができたらもっといいのになと思っていたことが、 この本でその通りのことが書かれていて、すごく嬉しかったのだ。間違ってなかったと。
例えば下記。
ここの従業員を型にはめ込むのではなく、あくまで最終的な結果に重きをおくべきだ
日本の多くの企業がそうかもしれないが、多様性は基本的に認められない。 評価の多くは減点法であり、平均的にミスしない人間が評価される。 特別目立ったスキルを持っている人間を特別なタスクの担当にさせるようなことも滅多に起こらないし、 そもそもそのようなスキル発掘の場を設けていない。本当はあの人はすごいのに・・・もったいない。という人材がたくさんいるのだ。 彼らが評価されないのは、1種類の陳腐な物差しですべての社員を評価しているからだ。 さらにそれが過程の比重が大きいからたちが悪い。例えば残業して頑張っているかどうか、上司に好かれているかどうか。等。
研修にかける時間と資金は、従業員の弱点を矯正してスキル・ギャップを埋めるだけではなく、一人ひとりの強みを発掘し、それを伸ばすために費やすべきだ
社内研修や社外研修はあるが、本当に心の底からクソだと思ってしまう。この時間を返してくれと切に願う。 そもそも何のための研修なんだろうと考えると、管理部の自己満なんだろうなとしか思えない内容だ。 これで何をしたいんだろう、ビジネスマナーや論理的思考など、すっごい薄っぺらい内容だ。 なぜエンジニアが受けるのか。この疑問に対する答えは「社会人としての常識」などであろう。 でもそんな常識を立派に持っている人間よりも、バリバリ設計やコーディングができる人間の方がプロジェクトはうまくいく。
専門知識のある従業員とここの顧客との関係が尊重される知識経済の世界では、特定の分野にしろ、顧客情報にしろ、従業員の方がマネージャーよりもくわしいなどということがいくらでも起こりうる。そういう状況でマネジャーが従業員の決定や判断を覆すおそれががあるようなら、そんな企業はすぐに力をなくすだろう。
上司は、なぜか自分を偉いと思う。部下を教育するとか、部下をしかるとか、訳のわからないことを抜かす。 そのくせ仕事は承認印を押す、定例会議に参加するがメインである。 忙しいというのは、シャローワークだろう。誰にでもできる仕事で忙殺されている人間のどこが偉いのだろう。
自分は役職はついていない。そして役職をもらうための社内政治もするつもりはない。 今の会社では役職はいらないと思っている。この会社での陳腐なものさしで自分を計測されるのが嫌で仕方がない。 ただしチームメンバーやその他従業員に対して、一緒に何かを作り上げたいという気持ちはあるし、 彼らの人生を棒に振るうような飼殺し的なキャリアパスは避けさせたい。 そのための努力はしたいと思っている。
まずは自腹でチームメンバーにこの書籍を買おうと思う。 そしてお互いの才能を確かめ合い認め合うことから始めようと思う。
【AtCoder反省】AtCoder Beginner Contest 166
Dの問題が意外とあっけなくとけた。
範囲については真面目に考えなかった。とりあえずえいやでいいや。みたいな。 あとは、大体考え方は同じ。
X = int(input()) a = [int( i/2)*((-1)**i) for i in range(1, 1000)] b = [int( i/2)*((-1)**i) for i in range(1, 1000)] """ 1 Aが正ならBは負または、Aより小さい正 2 Aが負ならBは負 3 X/(a+b)は、1以上の整数 """ find = False if X == 0: print(0) else: for a_ in a: for b_ in b: if a_ + b_ == 0: continue if a_ >= 0: if b_ >= 0 and b_ > a_: continue if a_ < 0: if b_ >= 0: continue """ if X%(a_+b_) != 0: print("hoge") continue """ if (a_**5) - (b_**5) == X: print(f"{a_} {b_}") find = True break if find: break
3 X/(a+b)は、1以上の整数
については、n乗同士の差の展開式で (a+b)(a4−a3b+a2b2−ab3+b4) = X となって、 (a4−a3b+a2b2−ab3+b4) = X/(a+b)
となるから左辺が整数だから右辺も整数になると思って制限設けたけどうまくいかなかったので外した。
自分はinputが何行にもわたるものが嫌いだ。だって面倒だから。 今回はBもCもそんな感じだった。けどそれで食わず嫌いしてると点数が稼げないんだろうから そこをちゃんとテンプレート化して楽になるようにしないといけないなと思いました。 環境も今はgoogle colabでやってるが、 ちゃんとした物を作りたい。けどめんどうなのでとりあえずほったらかし。
【AWSソリューションアーキテクト】Route53、データベース
Route53を利用したフェールオーバーな構成を実習した。
構成は↓ (udemy講義から引用)
この場合の構成を別リージョンに構築するときは、 構成をそのままコピーするよなコマンドはなくて全部手作業で作る。 超面倒な作業だしミスも発生しそう。
ついでにデータベースについても座学だけ。 実習は一旦飛ばした。お金がかかりそうだから一気にやれる時間を確実に確保しなければいけないから。
以下メモ書き
【AtCoder反省】AtCoder Beginner Contest 165
AtCoder Beginner Contest 165
をやった。が全然だめだった。AとBだけ解けたが、Cはめんどうでとかず Dは最後のテストだけが通らずに22時になってしまったのやめた。
知識やスキルもさることながら、ちゃんとした環境も整っていない。 ちゃん整えよ。
【AWSソリューションアーキテクト】Well Architected Framework
AWS 認定ソリューションアーキテクト – アソシエイトの試験内容
内容 | 比率 | |
---|---|---|
分野1 | 回復性の高いアーキテクチャを設計する | 34% |
分野2 | パフォーマンスに優れたアーキテクチャを定義する | 24% |
分野3 | セキュアなアプリケーションおよびアーキテクチャを定義する | 26% |
分野4 | コスト最適化アーキテクチャを設計する | 10% |
分野5 | オペレーショナルエクセレンスを備えたアーキテクチャを定義する | 6% |
これは、Well Architected Frameworkを活用できる人向けのテスト。
AWSアーキテクチャ設計の基礎
AZの選択
- 1つのリージョンにつき2つのAZを利用してアーキテクチャを設計することが基本(3つ以上はコスト効率が低下)
- マルチ AZにサーバーやDBの冗長構成を確立することで高い可用性を実現する
VPC
サブネットの分割
- サブネットはCIDR範囲で分割したネットワークセグメント
- ウェブアクセスの要否。
- /24以上の大きいサブネットを推奨
- 1つのAZに対して1つずつのパブとプライベートが基本
VPC間接続の設計
- VPC peeringにより2つのVPC間でのトラフィックルーティングが可能
- 接続が必要なVPCはそれぞれPeeringが必要、どのような接続にするか設計が必要
- アソシエイト試験は、well-architected frameworkで提唱されている5つの設計原則に沿った試験範囲になっている
Well Architected Framework
Reliability
- インフラストラクチャサービスの障害復旧の自動化など軽減設計
- 復旧手順のテストによる検証
- 需要変化に応じた水平方向へのスケーラビリティに高可用性の確保
- キャパシティの推測をやめる
- モニタリングと自動化を進める
基盤:IAM VPC AutoScaling ELB CloudFormation
変更管理 CloudTrail AWSConfig
障害管理 CloudWatch
Performance Effciency
コンピューティング:AutoScaling Lambda
ストレージ:EBS S3 Clacier EFS
データベース:RDS DynamoDB ElasticSearch Aurora Redshift
容量と時間のトレードオフ:CloudFront ElastiCache
Secuirty
- 全てのレイヤーにおいてセキュリティを適用
- アクセス追跡・モニタリングの確実な実施
- 条件ドリブンのアラートをトリガーとしてセキュリティイベントの応答を自動化
- AWS責任共有モデルに基づく対象範囲の保護に集中する
- セキュリティのベストプラクティスの自動化
- ソフトウェアベースのセキュリティ設定を使用し、迅速でコスト効率の良いスケーリングを安全に実行する
- 仮想サーバのカスタムベースラインイメージによる新サーバーへの適用自動化
- インフラストラクチャ全体のテンプレ化による管理
データ保護:ELB EBS S3 RDS KMS
権限管理:IAM MFA
インフラ保護:VPC
検出制御:CloudTrail CloudWatch AWSGuardDuty AmazonInspector
Cost Optimization
- 不必要なリソース削減
- 透明性のある費用割賦
- マネージド型サービスの利用によるコスト削減
- 固定の償却コストを変動コストへと転換
- スケールによるコストメリット
- データセンターへの投資不要化
需要と供給の一致:AutoScaling
コスト効率の高いリソース:EC2購入方式 TrustedAdvisor
支出の認識:CloudWatch 見積もりツール
継続した最適化:AWS最新情報 TrustedAdvisor
Operational Excellence
- コードに基づく実用実施
- ビジネス目的に沿った運用手順
- 定期的に小規模で増加的な変更実施
- 予期せぬイベントへの応答テスト
- 運用イベントと障害からの学習
- 運用手順を最新のものに保持すること
準備:CloudFormation Codeシリーズ RunbookPlaybook
運用:SystemManager ServiceCatalog CloudTrail AWSArtifact AWSGuardDuty CloudWatch AWSConfig APIGateway
進化:継続的かつ段階的な改善のために時間とリソースを割り当て、運用の有効性と効率性を向上する
【AWSソリューションアーキテクト】aws勉強の課題殴り書き
とりあえずここまで終わったが、 ハンズオンだけではどうもまだ理解できない部分が多く、最後の小テストでは半分くらいしか合っていないので、別途勉強し直しが必要と感じる。 特に、より理解を深める必要があるのは下記項目。
- ポリシー周り
- AMIとsnapshotの違い
ああもう他の課題ありそうだけど既に忘れたけどしょうがないか。
たとえば
この構成について、 nat ネットワークacl エンドポイント の使い分けの理由とか。わからん。 まあとりあえずざっと進める。