amareloのブログ(仮)

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

第1回 ぶろぐの勉強会 参加レポート

3/2 第1回 ぶろぐの勉強会 に参加しましたので、レポートを書きます。

目次

イベントページ

blog-o.connpass.com

セッション概要

ぶろぐの勉強会にようこそ!はじめまして! 山下さん

資料

www.yamamanx.com

概要
  • 検証したこと勉強したことを必ず書くようにしている。
  • 書き出すことで整理をしている。
  • ブログを書くことが仕事の中心。
  • 趣味でつながっていくためのツール。
  • 自分自身が勉強になっている。
  • Stay Writing!

「途中の人」になるために  坂本 雄一さん

資料

※公開されたら追記します。

良いアウトプットをしていくための5つのポイント
1.ちゃんと影響を受ける
  • ふむふむで終わらせるとそのうち忘れる。
  • ちゃんと影響を受けることが重要。ただ、取り入れるものは選んでも良い。
    • 土日でも勉強頑張ってみる。
      • 資格が取れた。
    • 本には好き勝手書き込む。
      • 記憶に残りやすい。過去の自分の思考回路が面白い。
    • だらだらテレビを見そうになったら消す。
      • 本当に興味あることに時間を割ける。
2.途中のものでも見せる
  • 完璧でないものでも途中で見せることが大切。
  • 点数が付くところに出ている人の方がカッコイイ。
  • 10点でも20点でもいいから自分の中から出す。そうしないと点数すらつけてもらえない。
3.他人の批評は控える
4.ゆるく継続する
  • 習慣に頼る。
  • 楽にできないか考える。
  • 間が空いても恥ずかしがらずに再開する。
  • 「ゆるくても続く知の整理術」という本がおすすめ
5.インプットする
  • アウトプットのためのインプットが一番効率が良い。
  • 必要だと思った書籍がよい。
    • 書籍は厳しいチェックを経て出版されている。
    • 体系的にまとまっている。
    • 知識が線でつながる。
まとめ
  • 自分の思うカッコいい人になりたい。

    • カッコいい人とは?
      • やり始めた人、やり続けている人、成し遂げた人
      • やり続けている人、途中の人が一番カッコいい。
  • ブログ含む外部発信は、簡単に途中の人になれる。

    • 検索したら出てくる。
    • 知識が整理される。
    • 自分自身思い出させる。

ブログをしてたらNHK出演につながった話 福村 浩治さん

資料

docs.google.com

エンジニアになった理由
  • 技術力で兄の介護できるのではないかと考えて。
  • 介護分野に特化したのは、両親の高齢化と兄の将来が不安になったため。
ITツールを使って見守りを
  • 自宅にタブレットを配置して、Skypeにより通勤中や業務の合間に見守りを。
  • ネットワークカメラを導入
    • 要介護側は何の操作もする必要がないため上手くいった。
      • 要介護側に負担を強いても定着しない。
      • ボタンを押すだけだとしても、それが難しい人もいる。
ブログをはじめたきっかけ
  • これまでの介護のノウハウを発信するため。
ブログが名刺代わりになることも
  • 介護の話での執筆依頼が来た。
  • ブログを見たNHKの職員から出演依頼が来た。
ブログをしない理由は?
  • 間違ったことを書いたら恥ずかしい。
  • アウトプットすることで何が得なのかわからない。
    • 間違っても良い。間違ったら訂正するだけ。
まとめ
  • 自分のノウハウを共有することで有益なブログを作ろう。

さあ、ブログをはじめよう。どこで?どうやって? トレノケート株式会社 髙山さん

資料

※公開されたら追記します。

ブログ公開先について
Self Install / CMS
  • メリット

    • 自由度がたかい
    • 個人ならば無償で利用可能
    • 有償版ならば日本語サポートあり
    • コンテンツ配信とプログラムを分離可能でセキュア
  • デメリ

    • メンテを含め運用はすべて自己責任
    • 脆弱性対策も
    • ブログ書くだけではオーバースペックなことも
WordPress
  • メリット

    • 自由に自分好みのサイトを作れる。
    • デザインテーマが豊富。
    • プラグインによる拡張。
    • 利用者数の多さで情報や関連書式も多い
  • デメリ

    • メンテは自己責任
    • 脆弱性対策
    • プログラムへの候が気がひどい
    • 動的生成なのでアクセス不可が大きくなる
Static Site Generator
  • メリット

    • 使い慣れたエディタからそのままデプロイ
    • 静的ファイルを生成するのでセキュリティが高い
  • デメリ

    • 公開サーバ、構築サーバを用意しないといけない。
    • メンテ、運用は自己責任
SaaS(Zenn)
  • メリット

    • 技術系記事とポエム系記事を分けて書ける。
    • 書き溜めた記事を本にできて販売できる。
    • Markdownで書ける。
    • GitHub連携できる。
  • デメリ

    • あまり見当たらない。
    • 技術系とポエム系は運営の判断で入れ替えられる。
    • マサカリが飛んでくるかも
ブログを書くときに気をつけることは?
  • コードを書くとき

    • セキュリティ情報が含まれていないか確認する。
    • ちゃんと動くか確認する。
  • 勉強会について書くとき

    • 写真や資料の公開ルールを確認する。
    • 鮮度が落ちないうちに書く。
まとめ
  • 楽しく続けることが一番!
  • 今ならおススメはZenn。
  • 今日から始めてみよう!

最後に

最近ブログ書いてて良かったと思うことや、書いてて楽しいと思うことが多かったので、今日の勉強会はホントに共感ばかりのでした。

勉強したことをアウトプットしていくことを繰り返したいというと思いで最近はブログ書き続けていますが、 あまり「書かねば」で考えすぎずに「書きたい」で書いていこうと思いました。 私は「書かねば」と変な義務感持つ性格なので、上手く付き合っていこうと思いました。

あと、時間見つけてZennに書いてみよう!

P.S.ブログ公開後、勢いでZenn登録しました!何を書くかはこれから考える!!

JAWS-UG朝会 #18 参加レポート

2/24(水)JAWS-UG朝会 #18 に参加しましたので、レポートを書きます。

#目次

イベントページ

jawsug-asa.connpass.com

セッション

AWS KMSを触る 富松 広太さん

資料

www.slideshare.net

KMS(Key Management Service)の概要
  • CMK
    • owned CMK(AWSが管理、見れない)
    • AWS Managed CMK(AWSが管理、見れる。)
    • Customer managed CMK(利用者が管理)
      • AWSが作成する方法と、自分で作成する方法がある。
    • データキー
KMSとは
  • 鍵を安全に保管してくれるサービス
  • S3、EBSのデータ暗号化、復号化
  • キーローテーション、暗号化鍵の方式を決定
CMKとデータキーの違い
  • データキー:データを暗号、復号化するために利用
  • CMKキー :データキーを暗号、復号化するために利用

    • なぜCMKで直接暗号、復号化しないのか
      • マスターキーをAWS外部に出したくないから。
      • データをAWSに送るのは不便だから。復号処理が一定時間でないのが嫌だから。
  • 暗号、復号化の利用お作法

    • Encrypted data Keyを使い暗号化し、使っても取っておく。
    • Plaintext data Key で暗号化し、使ったら捨てる。
      • エンベローブ暗号化
EC2にEBSをアタッチすると
  • ①暗号化されたデータキーを復号指示
  • ②復号化されたデータキーを取得
  • ③EBSデータを復号化
  • ④利用終了時(EBSデタッチ)に復号化されたデータキーを削除

    • データキーの管理はAWSが裏側でやってくれている。
    • KMSを削除すると即座にEC2の動作に影響はないが、次回EBSアタッチ時にエラーがでるので注意が必要。
    • KMSを削除したら、EC2が起動している間にデータを他の場所に保管する。
キーローテーション
  • キーの実態を入れ替えること。
  • 過去に暗号化したデータでも、キーIDを元に暗号化復号化できる。
  • 世代管理もしているため利用者側に影響はない。
  • AWS管理だと自動利用が可能。
KMS削除
  • KMSを削除して良いか迷ったら、暗号化データが復号できない可能性もある。
    • 一定期間様子見できるのでいきなり削除しないこと。
    • KMS削除は時間差の障害が起こる可能性がある。

Amazon QuickSight導入事例で解説、お蔵入りしないBI導入のポイント 小寺 加奈子さん

資料

www.slideshare.net

BIプロジェクトが失敗しやすいのは?
  • 何のデータをどのように見るのか、目的が不明確。
  • BIシステムをアップデートする予算、計画、体制がない。
  • BIプロジェクトならではの事情
    • 正解が明確ではない。
    • スペシャリストがいない。
    • 使わなくても業務が回ってしまう。
    • 現場の業務が増える。
顧客導入成功(QuickSight)のポイント
  • データを毎日見る業務プロセスと風土作り。
  • ユーザや情報システム部門のセルフサービスに依存しない、ベンダとの継続的な運用支援体制の構築。
  • データを見れる店長を育成した後に、多店舗に全面展開。
  • アンバサダー的人材を育成。
  • データの統廃合とデータ構造の最適化。
まとめ
  • データ活用プロジェクトは、作って終わりにするのでなく、PDCAを回し続ける業務プロセスと実行可能な体制を実現すること。
  • 運用サポートを手厚くし、データ文化を育成すること。

PDCAはホント何においても大事ですね。目的の言語化、導入後の運用体制構築、終わりの定義も大切だと思います。データ分析のファンを作り続けていくことも必要だと思いました。やはり文化作りは大事!!

AWS関連のブログを書いてて山ほど得したこと報告 山下 光洋さん

資料

www.slideshare.net

山下さんのブログ(ヤマムギ)

www.yamamanx.com

人とつながる
  • Redmineについて、学生さんから手順の問い合わせしてSNSでつながった。
  • Cogintoについて、他支部メンバからSNSで感謝の連絡がきた。
ブログ自体が勉強になってる
  • AWSへブログを移行したこと、失敗したこと障害対応について書いて勉強になった。
  • Well-Architected フレームワークのベストプラクティスを試し、理解を深められた。
  • モニタリングの結果から対応して、主要な攻撃について理解を深められた。
仕事で使う
  • ブログに書いた内容をトレーニングで見せることができる。サブドキュメント化できる。
  • コンテンツ化(書籍化)ができる。
  • 理解できていないことの整理ができる。
  • ブログを書くことが必須。
ブログ書くことのメリット
  • 勉強になる。
  • 書くことで整理できて不明点抽出もできる。
  • 人に知ってもらえて人とつながる。
  • 仕事のツールとして活用できる。

ツイートした通り共感しかありません!間違いを書かないように注意する必要はありますが、自分だけでなく誰かの役に立ってると前向きに描き続けたいと改めて思いました。

最後に

朝会後の仕事は気持ちが引き締まりますね! 2ヶ月参加できませんしたが、久々み朝から刺激をいただけました!次回も参加したいです!

次回は、3/24(水)です!

jawsug-asa.connpass.com

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つを意識して素材を作ろうと思います。 そして、ブログ執筆や登壇資料作成に生かしたいと思いました。

最後に

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

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