amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

BPStudy#162〜アジャイルな組織のつくり方 参加レポート

2/22 BPStudy#162〜アジャイルな組織のつくり方 に参加しましたので、レポートを書きます。

目次

イベントページ

bpstudy.connpass.com

第1部 BPStudyラジオスペシャル〜アジャイルな組織のつくり方

チームを機能させるために、今までで高い効果を感じたアジャイル開発のプラクティス

  • ふりかえりとナレッジを残すことで大抵のことは上手くいく。

    • 過去に失敗した課題がわかるので、前向きな議論ができる。
    • デジタルの上で行動する。あとで検索できるように。
    • 可視化して議論する習慣を。
  • バリューストリームマッピング

    • 組織横断でボトルネックの改善意識が生まれる。
    • 個別最適化から全体最適化に。
    • 人は目先の仕事にとらわれがち。仕事全体を俯瞰して視座を上げることが大事。
    • ルールは作った瞬間に陳腐化する。作った時点では正常に挙動していても、時間が経つと想定外の挙動(バグ)が生じる。
      • 定期的に制度のリファクタリングをすることが大事。
      • 当時は必要だったのものが今必要か見直すこと。
    • value stream mapping を作成する際におススメのデジタルツール
      • ホワイトボード系のツール。縦横無尽に使えるものがいい。
      • 付箋紙系のツール。

書籍に描かれるような現場は多いのか?変われない原因は?

  • 既存の日常業務の重力・バイアスが強いため。それを壊せないと変われない。

    • それを壊すためには、ビジョンを明確に、臨場感のあるゴール、問題に合意する、因果関係を明らかにする。
    • 変化するにはゆとりの時間、考える時間が必要。
    • 余白のマネジメント。余白のための仕組みづくりを。
  • 思考停止、行動停止、1人で何とかしようとしすぎ(させようとしすぎ)

    • 古い価値観に縛られすぎている。
    • ミスすることを責めることで、その人を思考停止と行動停止に追い込む。
      • 1人でなんとかしない、なんとかさせようとしないこと。
    • 問題提起をした人だけに問題を押し付けないこと。
    • モブワークにすることで属人化を防ぐことができる。意見を出しやすくなる。

まとめ

  • 変化を楽しむ。今までと違うことをしてみる。見方を変えてみる(沢渡さん)。

    • 変化を楽しめる人がこれからは強いと思う。
    • 変化を楽しめるファンを増やす。
  • 感謝、共感を口に出して言うことが大事。自信を持たせることが大事(新井さん)。

第2部 LT大会

ここアジャ で紹介されているふりかえりを見てみよう 森一樹さん(@viva_tweet_x)

資料

speakerdeck.com

タイムライン
  • 時系列順、イベント別に出来事を並べる。思いついたところから大まかに。
  • 出来事は事実と感情を合わせて書く。
  • みんなで共有して掘り下げる。

    • チームの共通認識を作ることができる。
感情グラフ
  • 感情の高低をグラフにする。
    • チームの変化や何にモチベーションを感じているかなどを共有できる。
    • チームをメタ認知できる。
    • お互いの相互理解に使える。
チームストーリー(未来)
  • 未来のありたい姿、なりたい姿を共有する。
  • なりたい姿への現在地、そのギャップ、ギャップの打破策、なりたい姿への加速装置を書いて共有する。
    • 未来志向になる。チームの軌道修正がしやすくなる。

最後に

沢渡さんと新井さんのセッションは、2/19のデブサミでも聴講しましたが、2/19のセッションとは少し違ったお話を聴くことができました。

1人で何とかしようとしないで、チームで成果を出して変化を楽しめるようになること、大事だなと思いました。 一担当者だけが問題に対応して他の人は手を出さない文化は不健全ですし、属人化の要因になりかねません。 チームの共通認識を作って未来志向に進んでいけるようになれば、チームみんなで問題を受け止められるようになり、より良い成果を出せるようになると思います。 少なくとも社内のメンバーは敵ではなく味方。共感者を増やし、思考停止に陥らず、身近なところから少しずつ変えていきたいと思いました。

今回も貴重なお話ありがとうございました!!

Developers Summit 2021 参加レポート

2/18、2/19の2日間、Developers Summit 2021 が開催されました。 私は、2/19を休暇にしていたため、2日目のみ聴講しました(1日目も仕事しながら聴きたかったのですが、無理でした…)。 それでも全部聴くことはできなかったため、聴講出来たセッションについてレポートを書きます。

目次

イベントページ

event.shoeisha.jp

セッション概要

デベロッパーからはじめるレガシー組織の景色の変え方~旧ノーマルからニューノーマル

沢渡 あまねさん、新井 剛さん、【モデレーター】近藤 佑子さん

旧ノーマル組織の限界
  • 統制管理型一辺倒の組織(クローズな組織)では限界。
  • 統制管理型、アジャイル型両方の良さを知っている方が、エンジニアとしては強い。
  • 統制管理型は変化に弱い。思考力主体性を奪う。
  • やっていくと慣れるけど思考停止になる。どこかで揺らぎを入れて思考停止を防ぐ。
慣れた不便から解放されよう ~僕たちが見せられる「新しく心地よい」世界
  • 新しいツールを使ってみる。広めてみる。
    • いっしょに操作しながら進めてみると良い。
  • ディベロッパー発のルネサンスを。
半径5m以内の変化のファンを創る
  • 新しいやり方を率先して試し、快感体験と成長体験を創る。
  • すぐに実感できる小さな変化を楽しんでいく。

  • ファンを創るのはブランディングそのもの。3つのファンを創ることが大事。

    • 技術のファン(自分が使っている技術への理解)
    • サービスやプロダクトのファン
    • カルチャーのファン(オープンに議論するカルチャーのファン)
まとめ
  • 過去はどうあれ、未来を創るのが(ニューノーマルを創るのが)エンジニア
  • カスタマーサクセスを創る。オープンになってみんなで未来を変えていこう。
感想

沢渡さんのセッションは何度も参加させていただきましたが、毎回勇気を貰えます。 小さな改善と成功体験を自分も相手も繰り返していく、そうすることで少しずつ改善が改革につながっていく。 改めて、オープンで優しい組織を作れるようになりたいと思いました。

やったもんがち!ニューノーマル時代を生き抜くために、組織の1メンバーであるあなたがDevOpsを促進する方法 横田 紋奈さん

資料

speakerdeck.com

DevOpsとは
  • 顧客に素早く価値を届けるための文化的な姿勢・取り組み。
  • Dev(開発)とOps(運用)が協業する。コラボレーション。
DevOpsで得られるものの例
  • 組織がビジネスが上手くいくことで自社や自分の価値が上がる。
  • 互いのことを考慮し、質の高い成果を出せる。できることが増える。
  • 責めない文化でバトルが減る。
  • 作業の効率化で楽できる。
DevOpsを実践するには
  • ベストプラクティスを取り入れながら改善を繰り返していく。
  • 他と同じである必要はないし、ゴールもない。
  • 改善と議論の繰り返し。
  • 組織の数だけ成功がある。やったもん勝ち!
一人一人がどんな行動をすればよいか?
  • ネガティブな思考、発言では変化を起こせない。また、変化は一人では起こせない。

  • 人に影響を与えるには

    • 話す前から協力してもらえないと決めつけない。同僚を味方ととらえて向き合う。
    • 課題に合った小さく身近なゴールを設定する。ゴールは複数でよいが優先度をつける。
    • 他者が置かれている状況を理解する。
    • 自分を過小評価せず、どんな人も価値を与えることができると認識する。
      • 人に刺激を与える、個人的な関係性など。
    • ギブアンドテイクで影響を与える
      • 価値を与え合うことで周りを巻き込んで成果を出す。
      • 相手に動いてもらうために自分にできることがあると認識することが大切。
  • ゴールを意識できるようになり、行動できるようになった。

    • とにかくコミュニケーションを取り続けた。
    • 長期的な目線も取り入れた価値を生み出そうとした。
  • 「味方」としてコラボレーションしたことで達成感と絆を感じた。
まとめ
  • コラボレーションすべきは開発と運用だけではない。色んなパターンがある。
  • 序盤のステップを大切にして自分自身と向き合うこと。
  • ゴールを決めて方向性を定めていく。
  • できることからはじめていくこと。
感想

自分はネガティブ思考なので、どうしても他人を味方ではなく敵と思ってしまいがち。 でも、それでは自分も相手も成し遂げたいことをうまく進められない。 沢渡さんのセッションでもオープンにとありましたが、自分自身の心もオープンにしないとなぁと思いました。

エンジニアのためのメンタルヘルスマネジメント 鈴木 裕介 さん

ストレス、ストレッサー
  • 身体的症状には気づきづらい。まず身体のサインに気付くのが大事。特に不眠や頭痛には注意。
  • 変化はすべからくストレス。

  • 心理的ストレッサーは3つあり、特にデイリーハッスルズには注意。ドラクエでたとえると毒の沼地。気づいた時には遅いことも…

    • カタストロフィ(社会的不安、生命の危機)
    • ライフイベント(配偶者との離別など)
    • デイリーハッスルズ(面倒な状況、上司の言い方など)
  • ストレッサーには個人差がある。

  • エンジニアに多い因子は「弁別性」。無駄やリターンがないことが嫌いなため、不合理な白黒つかない状況がストレス。
腰痛対策
  • 慢性腰痛とは、作業による前傾姿勢により、背骨の間にあるクッション「髄核」が後ろにはみ出た状態が固定しちゃう状態。

    • 後ろにずれた髄核をこまめに戻す体操をこまめに。
  • 職場での対人関係のストレスが強く出ると、腰痛を感じやすくなる。

    • 腰痛はメンタル疾患でもある。
コーピング
  • ストレスに対応するために意図的に行う「自分助け」の行動。
  • ドラクエの呪文のようにあればあるほどよい。リスト化しておくとよい。
感想

ツイートにも書いた通り、これに尽きるなと思いました。 自己肯定感が低いこともあり、すぐに落ち込んで罪悪感に苛まれるので、ストレス反応に弱いことにも改めて気づきました。 結構メンタルヘルスを害しやすい要因が自分にはそろっているので、うまく自衛しながら過ごせるようになりたいです。

ほんと今までよくメンタルヘルス害せずにやれたものだなぁ。。。危ない危ない(汗)

ニューノーマル時代のコミュニティは誰もがチャンスに満ち溢れている。 中道 一志さん(@ici_mici)

資料

speakerdeck.com

意思を示す。
  • 勉強会に参加して質問したり、参加レポートを書く。
  • 意思を観測可能な形にする。
  • 人前で話すなど意思を表現する。
  • 意思を示すことで共感されたり、視野が広がったりする。スキルアップにもつながる。
  • 意思を示すのに経歴や肩書は関係ない。
  • 自信がないとかは気にしなくていい!
  • 「違い」は価値である。
  • 「制約」は味方を変えると武器になる。
コミュニティの運営
  • ヒトデ型組織を作る。

    • 分散協調型、それぞれが自律的に動きながら協調をもって成り立つ組織。
    • 縦割りにせずその時対応できる人で対応する。
  • ヒトデ型組織を作るには。

    • ビジョン(最重要)

      • ビジョンを明文化する。仲間を集めてからのビジョン定義ではなく、ビジョンをもとに仲間集めする。
      • モチベーションを統一する必要はないが、皆の想いを知ることは非常に重要。
      • 他人のモチベーションをどうにかしようというのが間違い。
    • 鉄のルール

      • 関心を寄せリアクションをする。励まし合う。
      • 各々の立場や状況に関心を持ち、常に決定を尊重する。意見は遠慮なく。
    • 同期と非同期

      • 問題提起と意思決定は同期で行う。情報共有と議論は最小限にする。
        • 初めて出た重要な事柄をその場で決定することはしない。
      • 検討はすべて非同期で。非同期を生かして、会議に参加できない人の意見も取り入れる仕組みを作る。
    • 情報を透明化する。

  • リーダーとして大切なこと

    • みんなを信頼し感謝の意を伝える。
まとめ
  • 日本中があなたの舞台。踏み出す勇気を!
感想

登壇やレポート執筆で意思を示すこと。本当に大事だと思います。 また、表現力や文章力がない、経験値がないなど、制約がある中で挑戦する方が成長するなぁと思いました。 最近では自分も気にせず色々「あ、やります」の気持ちでやってたりします。

コミュニティの運営については、今自分が置かれている立場において、とても参考になるお話でした。 ビジョンの共有、メンバへの関心、感謝、今までの自分はできていたか改めてふりかえりたいと思いました。

コロナ禍でエンジニアイベントはどう変化していくのか? オンライン時代の技術と人との出会い方

モデレーター:仲亀 拓馬さん(@kameneko1004)

登壇者:赤川 朗さん(@Akira_Akagawa)、草間 一人さん(@jacopen)、森川 晃さん(@ariaki4dev)

オンラインイベントについての課題についての議論をmiroを使い、聴講者参加型で行われました。 自分が感じたことは以下の通りです。

  • 登壇してレスポンスが感じづらいと、登壇内容良かったのか悪かったのか、ふりかえりしづらい。
  • アーカイブ残る勉強会だと、登壇の場合はあとでふりかえりしやすい。ブログ書く場合は見返すことができて本当に助かってる。
  • やはり何でかんでイベントに参加した人たちと直接話をしたいなぁって思う。

じっくりと聴いたり、復習しやすくなったという利点がオンラインにはありますので、今はその利点を十分活用したいです。 しかし、オンライン生活慣れたけど、同じ興味や思考を持つ参加者や登壇者と話をしたいという気持ちは残ります。 完全オフラインはまだまだ難しいと思うけど、少しずつでもオフラインとオンラインのハイブリッドや、 規模を縮小したオフラインイベントが開催されると嬉しく思います。

最後に

2日目だけの参加でしたけど、多くの気づきを得られました。 デブサミの登壇者には、表現のしかたは違えど、

  • オープン
  • 他者への共感・関心
  • 感謝
  • 未来思考

を共通して持っている人が多いなぁと思いました。 自分は性格上後ろ向きになったり、自分の表現を躊躇することが多いですが、積極的にオープンマインドでいようと思いました。 また、他者へのリスペクトを忘れず、他者にどんな価値を提供できるか考えて仕事しようと思いました。

初日聴講したかったですが、参加できなかったセッションについては後で資料を読もうと思います。

JBUG 東京 # 20 #オンライン 〜そこが知りたい!Backlog活用術〜 参加レポート

2/19 JBUG 東京 # 20 #オンライン 〜そこが知りたい!Backlog活用術〜 に参加しました。 Backlogの活用方法についてとても貴重なお話を聴くことができて、勉強になりました。 というわけで、今回もレポートを書いていきます。

目次

イベントページ

jbug.connpass.com

セッション概要

「そこが知りたい!Backlog活用術」をテーマに15分LTx2本

APIDIY オープントーン金田さん @da_ka_ne
資料

www.slideshare.net

  • slackのコマンドでAPI実行

    • Toggl(タスクの時間記録)の開始と終了の実行
    • Backlogの課題登録・更新
      • Togglの開始漏れ終了漏れがなくなった。
      • 手動で記録をする手間やタイムロスもなくなった。
      • Backlogのステータス、実績更新漏れも防止。
  • Webサービスは大概APIを備えているので、足りない機能はAPIDIY

新卒エンジニアがBacklogで業務効率化しました! アスクル三浦さん @mxShun
資料

speakerdeck.com

お問い合わせ対応の展開
  • 見落としの発生と回答時間の長期化

    • お問い合わせを集約して。5営業日以内に解決を目指す。
  • Backlogの利点

    • 管理コストが低い。
    • ナレッジが蓄積される(これが一番大きい!)。
  • 欠点

    • お問い合わせする人の導入コストが高い。
      • 説明会の実施とWikiによるマニュアルの整備で対応。
  • Backlogに移行して

    • 5営業日以内の解決率向上
    • 問い合わせ数が減少
    • 他部署から情報展開の依頼
稟議申請の簡素化
  • 入力か所40か所、1申請に20分。

    • 情報が散らばっていた。
  • Backlogの情報を基に自動入力

    • ブラウザ上のブックマークレットを実行して情報取得
    • 申請コストを大幅カット。1つの申請を5分に。月300分のコストカット。
    • やり取りがBacklogで完結。

「そこが知りたい!Backlog活用術」をテーマにクロストーク

登壇ふりかえり
  • 三浦さんが担当した仕組みはどのくらいで作成したのか?(金田さん⇒三浦さん)

    • 問い合わせのリマインド、稟議申請共に1週間で作った。三浦さん一人で!
    • 計測は普段からしており、問い合わせ数と日数を毎日確認して数値化している。
    • 新入社員6名で運用改善している。
  • 便利なAPIについて(三浦さん⇒金田さん)

    • 画面からできることはすべてAPI揃っている。カスタム属性登録などもできるので、色々な可能性は秘めていると思う。
リモートワークについて
リモートワークをはじめるにあたり
  • 新入社員ですべてが新しい環境だったため、リモートワークに対してはあまり新しいといったところは感じなかった(三浦さん)
  • 出社した方が良いとは思うが、もともとリモートワークしていたため苦労はなかった(金田さん)。
テキストコミュニケーションで気をつけていること
  • 聞きたいことの例をつけて聞く(これて○○のことですか?)(金田さん)。
  • テキストベースだと感情が伝わりづらいので、感情をどう乗せるか意識している。スターを良く押している(三浦さん)。
進捗が止まっている課題などをどうしているか?
  • 長くなって複数のコメントに分かれる等の状態になっている課題はいったんクローズにして、新しい課題を作る(金田さん)。
Backlogのあれこれトーク
  • コメントの長さなどからプロジェクトの健全度を測れる仕組みを作ってみたい(金田さん)。
  • APIを使って日々の課題を解決する方法を色々考えたい(三浦さん)

最後に

Backlog単体だけではなく、APIの利活用で課題管理を効率化出来たり、社内業務の改善を実現できたりなど、 様々可能性があることを知れて収穫のある勉強会でした。 職場ではBacklogを使えないので、個人利用で使い込んでみたいと思いました。

貴重な事例を共有いただいた登壇者のお二人とスタッフの皆様、ありがとうございました!!

「50代以上エンジニアのキャリアストーリー」参加レポート

2/9、「50代以上エンジニアのキャリアストーリー 〜将来のエンジニアライフを考える〜」に参加しましたので、レポートを書きます。 自分も来たる50代の生き方を考えなければならない年齢になったのもあり、 当日にconnpassで見つけたこのイベントのタイトルに惹かれ、参加登録しました。

目次

イベントページ

findy.connpass.com

togetterまとめ

togetter.com

セッション概要

パネルディスカッション

エンジニアとして働き続けている理由
  • 新しい技術が出てきて面白い。技術の進歩を眺めるのが面白い。働き続けているのはそれがすべて(増田さん)。
  • 趣味と実益を兼ねている(塩谷さん)
  • 好きだから(渡辺さん)

「趣味と実益を兼ねている」という塩谷さんの言葉は深いなぁと思いました。 やはりどんな仕事をするにも、この領域に行きつければ強いし、楽しみながら仕事できるなと思いました。

「好きこそものの上手なれ」って言っていいかわかりませんが、この言葉が思いつきました。

エンジニアとして苦労したこと
  • オブジェクト指向をわかるのに苦労した(渡辺さん)。
    • 覚えるのは大変だけど楽しい。
  • 年を取ると意識的に体を動かしていかないと錆びつく(増田さん)
    • 年取っていろいろなことを見れるようになった。昔は辛かった。
  • 面白くて対価になる仕事を見つけるのが大変(増田さん)
  • キャッチアップは好きなものでお金になるものを選ぶ(塩谷さん)。
    • とがったものと枯れきったもののアンテナを張ること。
年下のエンジニアに伝えたいこと(技術習得で工夫している点、やって良かったと思うこと)
  • いろいろやって仕事の幅ができた(塩谷さん)。
  • チャレンジを1つ入れる。ただ欲張らないこと(渡辺さん)。
  • 基本的な仕組みや原理を理解すること。その方が早く習得できる(増田さん)。
    • 流行りのものを次から次へと追っ掛けるのは効率が良くない。

増田さんの「基本的な仕組み」を理解する。これはホント大切だと思います。が、どうしても新しい技術ばかりに目が行ってしまう(汗) 一度ちゃんと基本的な原理を見直そうと思いました。

情報処理技術者試験の午前問題(特に午前Ⅰ)で苦労するのって、基礎がちゃんとできてないからかなぁなんて思いました… まずは、増田さんが紹介していた「教養としてのコンピューターサイエンス講義」を買って読もうと思います。

これからチャレンジしたいこと
  • 難しい設計をやりたい。そういう仕事を見つけたい(増田さん)。
  • 定年になっても仕事があればやっていると思う(渡辺さん)。
その他、質問などから
  • だいたい朝5時前後に起きて、何かチャレンジする時間にしている(渡辺さん)。
  • プロダクションに近いコードを書きたい(渡辺さん)。
  • フリーランスを続けられるのは「人」(増田さん)。
  • エンジニアとして実力があれば、いつでもプレイヤーに戻れる。マネジメントも一度チャレンジしてみること(塩谷さん)。

  • 最近読んで面白かった本(増田さん)

LTセッション

未来のわたしストーリー bash0C7さん[@bash0C7official]

資料 bash0c7official.fanbox.cc

  • キャリアデザイン、成長ロードマップ、成長したスキル選び

    • これらをゴール逆算で突っ切る(ムリ!!)
  • ミッションにほれ込む ⇒ 課題をつかむ ⇒ 仲間に花を持たせる。

    • 評価のおこぼれをいただくループを作りたい。
50代になっても道は定まらない さっぴー川原さん [@sapi_kawahara]

資料 speakerdeck.com

  • プログラマ35歳定年説。35歳になると学べなくなる(学ばなくなる)。
    • 学べなくなったのではなく、学ぶ姿勢を失ったのでは?
  • 我流を直して新たな道を進もう。
    • 我流は転職の障壁
  • 道が変わっても学び続ける。
  • 人生は投機的実行だが無駄なことは何もない。

最後に

最後のまとめで、皆さん以下のように語られていました。

  • 学び続けていれば年齢は関係ない。興味があればずっと続けられる。(増田さん)。
  • 執念、諦めないこと(渡辺さん)。
  • やりたいことをとことんやっていくこと(塩谷さん)。

皆さん共通しているのは「技術が好き」なんだと思いました。だから、長く続けられてきたしこれからも続けるのだろうと思いました。 自分も学ぶこと、挑戦することは好きです。大変だけど、様々な仕事をやりつつ、学びと挑戦を繰り返していきたいと思いました。また、

  • 自分の仕事は本当に好きで続けたいことか?
  • 一生続けたいことが何かあるか?
  • それは真っ当に取り組んでお金になることか?

これらを日々問い詰めながら、今後の道を定めたいと思いました。

とても参考になるお話を聴くことができて感謝しています。 登壇者の皆様、運営の皆様、ありがとうございました!!

「文章の問題地図」を読んで

先日、上阪徹さんの著書「文章の問題地図」を読みましたので、感想を書きます。

今回、近所の図書館で見つけて読みました。今までの問題地図シリーズも学びと気づきが満載でしたが、文章の問題地図も予想を裏切ることなく、学びと気づきが満載でした!文章を書くのがいまだに苦手な私にとっては、刺さる内容ばかりでした。

目次

書籍について

gihyo.jp

感想

文章が下手で未だに苦手意識がある私にとっては、刺さる内容がたくさんありました。 その中でも特に印象に残ったこと3つを書きます。

まずは素材を整理する

書籍に書かれていた「素材」とは以下の3つです。

  • 事実
  • 数字(売上高、従業員数、創業年数など)
  • エピソード(驚いた、不思議に思った、聞いた話など)

今まで文章がなかなか書けない時はのことを振り返ってみました。 そのほとんどが、「事実とエピソードがハッキリしていなかったからだ」と、思い当たるフシがあることに気付きました。 本を読んでも、勉強会に参加しても、勉強しても、そこから得た事実がなければ、書こうにも書けません。 事実だけあって書き出せても、そこにエピソードが無いと文章にはできない。 自分が文章なかなか書けない、書きづらい理由にとても近いと思い、腹落ちしました。

いきなり書こうとしない

「とりあえず書きながら考えればいいや」

私はこう考えて書くことが多かったです。丁寧に書こうとしすぎるのも問題ですが、「とりあえず書きながら考えればいいや」と「ラフに書いて後で修正しよう」は全然違うと思いました。素材出しをやりながら書くのでは、分かりやすくまとまった文章はかけないなぁと納得しました。

まず、素材を整理して構成を組み立てる。それから、自分で見直して肉付けする、または他人から意見をもらって精度を上げる。そのような書き方に変えていきたいと思いました。

書けない理由

自分が思ったことをその場でメモをとっていないから書けない。

これまでの人生で、勉強会のレポートや読書感想文が苦手だった理由はこれだと思いました。

  • 何を感じたか
  • 何を学んだか
  • 何に驚いたか
  • 何を次につなげていきたいか

ただ読んだり、ただ勉強会に出ているだけではなく、これらの意識がなければ何も書けないなと改めて思いました。 これから読書や勉強して学んだことは、この4つを意識して素材を作ろうと思います。 そして、ブログ執筆や登壇資料作成に生かしたいと思いました。

最後に

今まで自分が文章書くことに抵抗があった理由が明確になって、すっきりした読後感でした!!やはり問題地図シリーズはおもしろいです!!図書館に返却してしまいましたので、いつでも再確認できるように購入しようと思います。

短いですが、最後まで読んでいただきありがとうございました!!

2021年の目標・やりたいこと

amarelo(アマレロ)です。今日、誕生日を迎えました!!早いもので、1月ももう終わりますね。

誕生日だからというわけではありませんし今更感ありますが、2021年にやりたいことをアウトプットしようと思います。

目次

今年の目標

今年の目標は大別すると以下の通りです。それに関連したやりたいことを書いていきます。

1.AWSの経験と知識を積む。

昨年までに認定試験に合格してきましたが、実践を積めていません。 かといって今の職場でAWSの経験値を積める見込みはありません。 その実践の場を登壇駆動で作ろうと思います。

やりたいこと

後付けっぽくなりましたが…(汗)1/19にJAWS-UG 初心者支部で登壇しました! また登壇させていただきたいです!!

2.プログラミング言語を勉強する。

今までプログラミング言語をろくに身に付けずにここまで生きてきたため、プログラミングの勉強にどうも抵抗感を感じていました。 でも、自分で何かを生み出すことをやりたい気持ちは残っていますので、今年は真剣に取り組もうと思います。

昨年末にPythonの書籍を1冊(電子書籍で)購入しましたので、手を動かしながら1冊読み切ろうと思います。 まずはとにかくプログラミング言語を一つでも勉強して、まずは成果物を一つ作ってみようと思います。

やりたいこと
  • Pythonを勉強する。
  • 可能ならば他の言語も勉強する。
  • 身に付けた言語で成果物を作る。

3.ウェブセキュリティの勉強

業務でウェブセキュリティに関わっていることもあり、 昨年からウェブセキュリティ基礎試験の勉強をしています。 また、プログラミング言語を勉強して作る成果物がウェブアプリならば、 公開するのに最低限ウェブセキュリティを抑えておく必要があると思います。 昨年末あたりで勉強の手が緩んでいましたが、気持ちを新たにして勉強しなおしたいと思います。 ゆっくりでも勉強を進めていきます。

やりたいこと
  • ウェブセキュリティ基礎試験の受験
  • ウェブセキュリティに関するブログ記事を執筆する。

4.英語力を上げる。

去年、こんなツイートをしました。

IT業界に長く勤めてきましたが、英語に触れないわけにはいきません。 昔から英語は苦手だったため、日本語訳されていれば楽だと何度も思いました。 今も思っていますが、「英語分からないアピールし続けているのは傲慢なのかもなぁ」とふと思いました。 特に、仕事上それを悪気なくでもやってしまうと、企業のイメージも下げてしまいかねません。 英語を読めれば自分の仕事の幅も広がりますし、生産性も上がるはず。 いつまでも逃げていないで、少しは英語を読めるくらいにはなろう!と思いました。

やりたいこと
  • 英会話を受講する。
  • テレビの英会話講座を見て勉強する。
  • 英語勉強のための書籍を最低1冊購入する。

今月から、所属企業で募集されていた英会話講座に申し込み、受講し始めました。 ついていくのに必死ですが、受講期間中は楽しみながら頑張って乗り切ろうと思います。

TOEICなどの資格試験は、いったん受けれたらいいな程度で(汗) 資格取得が目的になってしまいそうなので、まずはちゃんと読めるようになりたい。

5.自分が焙煎したコーヒー豆を世に送り出す。

昨年、コロナ禍がはじまったため、コーヒーを広める活動が何もできませんでした。 何か一つでも自分が焙煎したコーヒー豆を世に送り出す活動をしたいと思いました。

やりたいこと
  • コーヒー抽出に興味がある人を募る。
  • 自分が焙煎したコーヒー豆に興味を持ってくれた人に、豆を送ってコーヒーを飲んでもらう。
  • 継続してもらえるならば、お代をいただいてコーヒー豆を提供する。

6.料理の腕を上げる。

今までも料理をしてきましたが、あまり本格的に取り組んだわけではありませんでした。 私の妻が料理が上手くて美味しいためそれに甘えてきました。 しかしながら、妻も働いているし子供の面倒も見てくれている。 自分は仕事と好きなことをさせてもらって、子育ても家事もしないのは図々しいと思いました。 少しでも妻の負担を減らすべく、料理にもっと力を入れたいと思いました。 料理をすることで手順を組み立てる能力も上げられるはず。

やりたいこと
  • 一品料理を12品目作れるようになる。
  • 朝食一食分(家族全員の)作る。
  • 昼食一食分(家族全員の)作る。
  • 夕食一食分(家族全員の)作る。
  • 作った料理をSNSやブログにアップする。

1月に豚角煮を作りました。できる限り月一は何か作ろうと思います。

7.健康を維持する。

在宅勤務になってから、本当に運動しなくなりました(汗) コロナに負けない健康な体を維持するためにも、体力作りは継続したいです。

やりたいこと
  • 睡眠時間を6時間確保できるようになる。
  • 風呂に20分以上つかる。
  • 週に3回、最低10分間の筋トレをする。
  • 最低週に一度はランニング or ウォーキングをする。

8.自分のキャリアを見直す。

実は、この目標が今年一番やりたいことだと思っています。

現所属企業で働いて15年(これで年齢層バレますね)。一昨年あたりから「このままでいいのか?」と悩んでは繰り返す日々を送っています。 今日誕生日を迎えてまた一つ歳をとりました。もう決して若くはないし、転職することはどんどん不利になる(ひょっとしたら、ロクな経験の無い自分には無料かもしれません)。 いいかげん、本当に自分がやりたいことを言語化して動こうと思います。 そのうえで、このまま現所属企業で働き続けるのか、転職できる可能性があるならば転職するか、それともコーヒー焙煎人を完全に本業とするのか…を決めて、 注力することを固めたいと思います。

やりたいこと
  • 職務経歴書を書く。
  • 転職サービスに一つ登録する。
  • カジュアル面談を受ける。
  • 企業が開催するMeetupに参加する。

その他のやりたいこと

目標に関連すること以外にもやりたいことはまだありますが、とても100個書けるほど思いつきませんでした。 目標と直結しないところでは以下の通りです(しょうもないものもありますが…)。

  • 春にネットワークスペシャリストを受験する。
  • LPIC-1の勉強をする。
  • インフラ勉強会に登壇する(昨年以前もやっていましたが、今年もやりたい)。
  • 外部勉強会で登壇する(これも昨年以前にやってたことですが)。
  • キーボードを買い替える。
  • 机を買い替える。
  • モニターを買う。
  • Zennを使ってみる。
  • Notionを使ってみる。
  • 電子工作をする。
  • 鈍行列車でのんびり旅をしたい(コロナ状況による)
  • とにかくカフェ巡りをしたい(これもコロナ状況による)
  • このブログ名を変えたい。いつまでも(仮)ってのも…
  • このブログの見栄えをもう少し良くしたい。

少なくともネスペは受験します。一昨年のリベンジをしたい! あと、在宅勤務環境をもっとアップデートしたいw

最後に

一通り書き出してみましたが、去年より自分で自分の首を絞めている気がしました(汗) 時間の使い方を見直し、素早い判断をできるようにならないと!

自分のレベルを上げるためにも一つでも多く挑戦したいと思っています。 今年の年末にどれだけできたか、ブログに書くのが楽しみですw

「JAWS-UG 初心者支部#35 LT大会!! 」に登壇しました!!

1/19(火)JAWS-UG 初心者支部#35 LT大会!! に登壇してきました。遅くなりましたが、レポートを書きます。

目次

イベントページ

jawsug-bgnr.connpass.com

自分の登壇について

登壇資料

speakerdeck.com

登壇ふりかえり

まず、今回登壇してみようと思えたのは、昨年末の「AWS CloudShell おもしろ選手権」での登壇があったからです。 あの時はガチで登壇者として申し込んでいたのを忘れており、慌てて準備しました。 でも、「登壇することさえ決めれば何とかなる!」と思えたので、「今回も何とかなる!いや、何とかする!」と思えたので、登壇者として申し込みました。 無事、抽選突破して登壇に至りました。

良かったこと

今回は登壇する気満々で臨んだので、テーマ検討も準備も余裕をもって取り組むことができました。 3日前にいったん資料を作り終えて、登壇の練習と微調整をすることができました。 おかげで、前回のように直前にワタワタすることはありませんでした。

ホント事前準備大事!!!

改善したいこと

登壇そのものは緊張していたとはいえ、あまりつっかかることもなく話せたかなと思います。 ただ、資料はもう少しコンパクトにまとめた方が良かったと思いました。 発表に5分半くらいかかってしまいました…やはり、5分LTでスライド30枚オーバーはキツイ…

わかったこと

実際にAWS CloudShellを動かしたこと、一生懸命取り組んだことをLTで発表したことで、 試験対策勉強や書籍を読むだけとは比べ物にならないくらい、理解できた感じがしました。

自分は「やる!」と一度腹をくくれれば、「何としてもやりとげよう!」と思うことができる人間だと再確認しました。 何やるにしても腰が重くて二の足踏む性格ですが、それなりに動ける人間で安心しましたw

他の登壇者のセッション

他の登壇者の方々のセッションも楽しく拝見させていただけました。 資料とポイントのみで恐縮ですが、以下に書いていきます。

AWS AthenaとFluentdでログ集約基盤構築 ユータさん

speakerdeck.com

  • Fluentdを導入し、ApacheRailsPostfix、SlowQueryのログをS3に集約して検索性を向上した。
  • ApacheログとRailsの日付ログフォーマットが異なるので、同一時間帯で比較できるようにするためUNIXTIMEカラムを追加した。
  • 生データのログも参照できるようにした。
  • SlowQueryのログをクエリタイムでソートできるようにしたいが、いい手が思いつかず…

組織がAWSを使い始めるときに考えたい、アカウントとユーザーの管理 sumiさん

speakerdeck.com

  • アカウントの目的が行方不明になるとアカウントが乱立する。
  • マルチアカウント管理はこれといった正解がないので、組織にベストな方針を検討しよう。
  • 複数アカウントの管理にはOrganizationsを使うのがよい。
  • AWS SSOはいいぞ!

IAMの「あ」の話 佐々木 拓郎さん

speakerdeck.com

  • 認証と認可の違い

    • 認証(Authentication):誰であるか?
    • 認可(Authorization) :何を使わせるか?
  • IAM設計の基本方針

    • 認証情報を盗まれないようにする運用設計
    • 認証情報が盗まれても被害を最小限にする権限設計
  • マルチアカウントが一般化した現在では、いかにIAMユーザーを作らないかがポイント

会社AWS環境が無法地帯なのそろそろなんとかする話 けびん@札幌さん

speakerdeck.com

  • Trust Advisor で教えてくれるベストプラクティスを対応して、オールグリーン(すべてOK)にした。
  • Trust Advisorの案内は、最低限やっておくこと。

AWS Lambdaと非同期と私 kyokucho1989さん

www.slideshare.net

  • LambdaからDynamoDBの読み込みがされないうちに、SORACOM Lagoonへデータ送信されてしまう。
    • 同期処理(複数のことを同時に実行すること)をやらずに、非同期処理(これをやってから、これをやる)を入れて処理する。
    • Lambda(node.js)の場合、asyncハンドラーを用いる。

「やってみなはれ」がつなげるアウトプットループ Naomi Yamasakiさん

www.slideshare.net

  • アウトプットしないのは知的な便秘
  • まずは飛び込んでみよう。一歩でもいいから次のステップに。
  • アウトプットがループしていく。

最後に

最後の山崎さんの登壇を聞いて、アウトプットで誰かに影響を与えられるのってホントに素晴らしいなぁと思いました。 アウトプットのループを起こせるよう、様々な場所でLT登壇したい! 今後、今までよりアウトプット前提で勉強会に申し込もうと思います。 ブログでのアウトプットはもちろんですが、登壇の回数をもっと増やしたいです。

  • 「登壇したい」と思ったらとにかく登壇申込をする。
  • 勉強会の日から逆算してとにかく手を動かしテーマを考える。
  • 登壇する。
  • ふりかえる。
  • また登壇する。以降ループ・・・

成長するためにはこれに尽きると思いました。 ただ、しんどくならないように注意はします。

次も、楽しく勉強してアウトプットできればいいなと思っています!!