amareloのブログ(仮)

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

JAWS-UG 初心者支部#37 codeシリーズハンズオン参加レポート

5/27(木)、JAWS-UG 初心者支部#37 codeシリーズハンズオンに参加しました。

今日はJAWS-UG朝会にも参加して、AWSの勉強盛沢山でした。朝会の方も後ほど書いて公開しますが、先に初心者支部の方のレポートを公開します。

(5/29追記)朝会の参加レポートも書きましたので、読んでいただけますと嬉しいです!

amarelo24.hatenablog.com

目次

イベントページ

jawsug-bgnr.connpass.com

LT:AWS勉強中に勘違いしがちなこと AWSJ 亀田 治伸さん

Lambdaはバッチ処理基盤?

  • バッチ処理はひとまとまりのデータを一括して処理する方法。
  • メインフレームで使われていた用語であり、リクエスト単位でコンピュートリソースをアロケートすることを間接的に指す。
  • Lambdaを使う時は、Statelessかつイベントドリブンを意識すること。
  • 冪等性も大事。Lambdaには重複実行の可能性もあるため。
  • ステートを引きまわすときは、Step Functons、MWAAのどちらかを使うこと。バッドプラクティスではない。  - Lambdaが別のLambdaを呼び出す構成だと、どちらかのLambdaが止まった時に困る。

CloudFrontの通信費用が8倍?

  • CloudFrontのデータ転送量はGB単位。
  • ビットレート(bps)で計算する場合、1/8しないと高額のように見えてしまう。

インスタンスストアについて

  • EC2の腹の中にあるストレージ。
    • EBSはネットワーク接続されているストレージ。
  • 揮発性ストレージのため、インスタンスストアに保存されたデータは、インスタンスの有効期限のみ保持される。

ハンズオン

Codeシリーズ(CodeStar、CodeCommit、Codebuild、CodeDeploy、CodePipeline)のハンズオンでした。 手順は以下にて公開されています。

shigeru-oda.github.io

CodeStarだけはじめて触りましたが、数クリックでCI/CD環境が作れたのはビックリしました。 CodeStarは裏でCloudFormationが動かして環境を構築していました。 CloudFormationは色んなところで関わるサービスのように印象があるので、 もう少し勉強しておいた良さそうに思いました。

無事完走しました。ハンズオンは楽しいですね!これで満足せず、日を開けてもう一度復習のためにじっくり触りたいです。

最後に

ハンズオンの資料って準備するのは大変だけど勉強になるということを仰っていました(どなたの言葉か忘れました。スイマセン!)。 本当にそれだなぁと思いました。全部自分で調べてシナリオ作るので、理解は物凄く深まりそうです。 それを公開していただけることには感謝しかありません。ありがとうございました!

第20回redmine.tokyo勉強会 参加レポート

5/22(土)第20回redmine.tokyo勉強会に参加しました。

自分の中でも5月の恒例勉強会となっているredmine.tokyo。今回も楽しみにしていました!! 本編の内容について、まとめを書いていきます。

目次

イベントページ

redmine-tokyo.connpass.com

YouTubeチャンネル

セッション内容はこちらでご覧になれます。

www.youtube.com

Togetter

togetter.com

セッション

講演: 【2021年最新】Redmine 4.2 新機能評価ガイド @g_maedaさん

Redmine4.2概要

  • 二要素認証できるようになった。
  • グループがウォッチャーになれる。
  • Redmine4系の最終。次は5.0の予定。
  • 3.4以前には未修正のセキュリティ脆弱性(CVE--2021-31863)があるため、今のうちに4.2に移行した方が良い。

Redmine4.2新機能の一部

  • 認証

  • 活動画面

    • 日付指定ができるようになった。
    • ユーザフィルタができるようになった。
  • トラッカー

    • トラッカーのコピーをできるようになった。
    • カスタムフィールドを多用している人には便利。
  • 添付ファイル

    • チケット・Wikiページの添付ファイルの一括ダウンロードできるようになった。
    • ファイル形式カスタムフィールドにたいするドラッグアンドドロップができるようになった。
  • メール通知

    • 優先度が高いチケットの更新を通知するオプション
      • 通知メールの量を抑えるのに役立つ。
  • フォーラム

    • フォーラムのウォッチャー管理
      • フォーラムのメッセージに対して他のユーザをウォッチャーとして追加できるようになった。
  • インポート

    • ユーザアカウントのCSVインポートができるようになった。
    • CSVインポート時のフィールドの対応関係を自動設定できるようになった。
  • チケット

    • グループをウォッチャーとして追加できるようになった。
    • 関連チケットを一括追加できるようになった。
      • コンマ区切りで複数指定できるようになった。
    • 右クリックメニューからの子チケット追加をできるようになった。
    • チケット画面に完了、未完了のバッチが付くようになった。
    • チケットがクローズできない場合の理由を表示するようになった。
  • ロールと権限

    • 権限レポートのCSVエクスポートができるようなった。
    • 一般ユーザにプロジェクト削除を許可できるようになった。
  • プロジェクト

    • プロジェクト一覧のデフォルト表示形式設定を変更できるようになった(ボード or リスト)。
  • テキスト書式

    • Wikiツールバーのテーブル挿入ボタンが追加された。
    • Wikiツールバーのコードハイライトボタンをカスタマイズできるようになった。
    • テーブルのカラムを動的にソートできるようになった。
  • 作業時間

    • 作業時間の詳細のグループ条件に「チケット」を追加。
  • ユーザーインターフェース

    • チケット編集画面で「自分に割り当て」できるようになった。
    • Ctrl+Enterによるフォーム送信。
    • 編集・プレビュータブを切り替えるショートカットキー
    • 太字・斜体・下線のためのショートカットキーが追加された。
    • Wikiページのリンク挿入時のオートコンプリート。
    • チケットコメントのURLのコピー。
      • チャットやメールでリンクを伝えるときに便利。

パネルディスカッション1: Backlog x Redmine対談 #2

パネラー:@tamagawaconanさん

パネラー:@Madowindaheadさん

モデレータ:@ryouma_nagareさん

プロジェクトマネジメントは偉い人だけのものじゃない

  • 今までは、偉い人がプロジェクトを進める能力もリソース、完成イメージを持っていた。

    • 今は先行きが分からない、偉い人でも正解を持っていない。
      • 情報は武器だけど、今は情報を持っていても正解とは限らない。
      • 見るべき情報も多くなっていて、答えを出しづらくなっている。一人の人がすべてを把握するのは無理。
  • 得意分野は人それぞれ。それを組み合わせていかないと、良い仕組みを作れない。

    • だからこそ、まずはセルフマネジメントが重要。
    • 自分の能力をどう生かしていくか、得意不得意は何かを把握する。
      • 自分に向き合う。できることだけでなく、できなかった事実にも。それが武器になっていく。そこからスタートしていくことがマネジメントの第一歩。
      • 不得意なことを無理に得意になろうとすると、得意なことにも悪影響を及ぼす恐れがある。取り繕おうとしなくても良い。
  • フラットな組織のマネジメントスタイル

    • データを使って意思決定ができるように。
  • ヌーラボのマネジメントでまだハマってないなぁって思うことは?

    • ふわっとしたところはいきなりBacklogの課題に入れずに、チャットで議論する。
    • Cacooを使って図式化したり、オンライン会議もする。ケースバイケースでツールを使っている。
  • マネージャー作りの観点

    • 中途の人で自分の意思を持って動ける人をどう生かしていくか。自然とそういう流れになっている。
    • 様々な地域や部署があるところだと、どうマネージャー作りを進めて良いかは一概に言えない。
  • チケットでのコミュニケーションをすることはある?

    • チャットでコミュニケーションを取る。Backlogでスター連打や感謝の言葉を伝えたりを良くやっている。
    • 時間かかる施策についてはチケットに書いて、ふりかえりをする。ベースラインを上げる方法としてRedmineを使っている。
    • 前のマネージャーがどうやっていたかを、チケットを見てあたりをつけることはある。
  • チームになると書けなくなる問題

    • チームになると書けないのは、1人の時でも書けないのでは?
    • 書く練習として、未来の自分のために書く。

プロジェクトの民主化に必要なこととは?

  • 情報をオープンに、文章を書くなどテクニックもあるが、人間関係を円滑にすること。伝え方を気をつける。人間関係を柔らかくする。
  • 自分を鍛えたり弱点を理解してどう表現するか?不十分な部分をさらけ出したうえで自分を鍛える。悩み続けるしかない。そうしていれば、仲間は勝手に増えていく。

LT:メールとExcelによるタスク管理にRedmine導入の途中経過報告 @kawamasatoさん

  • 現状の課題

    • タスク管理
      • 自分が返信していないスレッドをさがして対応。見落としが発生。
    • ナレッジ管理
      • テキストファイルやWordでメモがある。
      • フォルダ構成が適当で類似フォルダが多数。
      • 手順書がメンテされていない。
  • そうだ!Redmineにしよう!

    • コストは構築作業だけ。
    • WindowsはBitnamiでらくらく構築
  • Redmine導入後

    • タスク管理
      • 一人Redmine
      • 関連者には見れるようにしておく。
      • 案件発生の経緯から分かるように記録。
      • 作業記録は画像を多目でわかりやすくする。
  • ナレッジの蓄積

    • 経過を含めて記録する。
    • 説明を求められたときもすぐに提示できる。
    • 類似案件にもすぐ対応できる。
  • Redmineのここが凄い!

    • ボトムアップで導入可能。
    • データも自分たちのもの。
    • サービス停止がない。
    • 画像付きで手軽に記録を残せる。

LT: テキスト化した「チケット駆動開発がまわりはじめるまでの取り組み」の紹介 @zinrai さん

資料

speakerdeck.com

概要

  • チケット駆動開発についてAdvent Calender 2020でかいたが、書き終わらなかった。
  • 2021年もAdvent Calenderで書こうと思っている。少しでも続きを書きたい。

LT: Redmine使ってみた5年間12万チケットを5分で振り返る @nekosanzu1さん

資料

www.slideshare.net

内容

  • 導入から5年

    • チケット文化のはじめの一歩は越えた。
    • チケット便利、Redmine好きという言葉が出てきた。ファンが増えた。
  • 1年目:課題管理の崩壊を食い止めろ。

    • 複数の課題報告の取りまとめ。毎週徹夜の進捗報告準備だったのを、Redmineで課題管理することに。
    • タスク管理で組織の課題解決とマルチプロジェクトで見せることで可能性を見せた。
  • 2年目:トライアンドエラーでとにかくファンを増やせ!

    • 自分と関係ない部門を巻き込め!
      • 何かを「管理」している部署に導入した。
  • 3年目:利用の幅を広げろ!

    • 申請業務を統合。管理表認識の脱却。
  • 4年目:Redmineの限界を超えろ!

  • 2019年のredmine.tokyoで話したので、そちらを参照。

  • 5年目:情報を活用しろ!

    • 魅せろ!データ分析!
  • チケット文化が生まれた後の話

    • タスクの抽象化が進みタスク認識が生まれやすいが忘れにくい。
      • クローズできないチケットが増えて、イヤになることもある。
      • チケットハウスキーピングは必要。
  • Redmineはタスク管理ツール/プロジェクト管理ツールではなく、業務改善ツール。

LT: Redmine issue assign notice plugin の紹介 @onozatyさん

  • Redmine issue assign notice plugin
    • チケット担当者が変わった時に通知するプラグイン
    • 変更前変更後の担当者が分かるようになっている。
    • メンションを変更後の担当者に飛ばせるようになっている。
      • 動作確認済のサービス:Slack、Teams、Google Chat、Rocket.Chat
    • チケット担当者を切り替えながら進めていくようなプロジェクトではとても有用なプラグイン

LT: 時系列データをグラフ化する、redmine numericfield chart macroの紹介 @matobaa さん

  • カスタムフィールドの値を時系列グラフにするWikiマクロ。
  • きっかけは、課員全員の体温を記録するための方法を知りたいというツイートから。
  • Redmine.JPで紹介してもらえた!
  • チケットのコメント欄にも書ける。

  • 時系列データの使用例

    • 体温推移
    • 勉強会参加人数の推移
    • ニコニコカレンダー
    • レーニングの推移
    • 残数表示

講演: 新型コロナウイルス感染者情報管理 by Redmine @skysさん

資料

speakerdeck.com

概要

  • 感染者情報管理サイトを作成した経緯

  • サイトの紹介

    • プラグインをカスタマイズしたり、独自プラグインを使っている。
    • 以下を参照可能
      • 都道府県一覧(プロジェクト一覧)
      • 感染者一覧
      • カレンダー表示
      • 感染者情報(チケット)
  • 情報取得と更新

    • Python で情報取得してpandas(ローカル)で差分確認。その後Redmineの更新を行う。
  • 課題

    • 一部が手動対応のまま。
    • サマリ表示の崩れ、表示速度、モバイル最適化。
    • 暫定的にJavaScriptで書いている箇所が多い。
  • 展望

    • 対応都道府県の追加
      • サーバー増強と更新できる人の追加必要。
    • グラフの追加

パネルディスカッション2:「Excel中毒者への特効解毒剤Redmine

話し手:@ta_ke_chan_

聞き手:@akipiiさん

今の現場でどんな問題があったか?

  • 工場の管理がExcelベース
    • Excel管理大好きな人が多い。
    • WebUIはよくわからず使ってもらえない。
  • 基幹システムから落ちてくるデータが作業計画の基本
    • Excelを途中で介在させて、UI・連携ツールとして動かす。

ExcelおじさんにRedmineを使ってもらうための工夫

  • Redmine入力ツールをExcelで作成。
    • UIをExcelにすることでExcelおじさんも入力する。
    • 基幹システムからデータをCSVで持ってこれる。
    • データはRedmineに集約されるので、多重管理にならない。

プロジェクト管理の場面ではRedmineをどのように使っていた?

  • ガントチャート・かんばん・工数管理の機能を利用した。

    • RedmineのLycheeプラグイン(有償)を利用中。
    • もとは同じチケット。チケットの表現を変えているだけ。
  • ツールによる効果

    • ガントチャート効果
      • タスクを積み上げてWBS作成手法を取るようになった。
      • チケットで並べると
  • チームやメンバにどんな変化があったか?

    • 見える化効果

      • リーダーがメンバの管理監視のために使わないことを明言し、メンバーの心理的安全性を担保してから開始。
      • メンバのたすくや進捗率が他のメンバに見えることで、アドバイスやヘルプなどのコミュニケーションが盛んになった。
    • 若手中堅メンバーの活動

      • 中堅メンバや若手メンバが率先してツールの使いこなしをして、ベテランに指導することで双方向のコミュニケーションが盛んになった。
      • 全体的にチーム力が上がった。
    • データ蓄積効果

      • 決まったフォーマットでデータが蓄積されることで、過去プロジェクトの状況をふりかえり、分析することが可能になった。

LT: Redmine地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) plugin の紹介 @geosanak さん

  • 汎用のタスク管理システムとしてRedmine地理空間情報を使えないか?
    • GTT(Geo Task Tracker)プラグインを開発。
      • 背景位置情報を埋め込むことが可能
      • プロジェクトごとに区域をあらわすポリゴンを設定可能。
      • 設定したプロジェクトの区域をプロジェクト概要に表示。
      • チケット作成時に位置情報付与。

LT: Redmineの通知メールを暗号化しなければいけなくなった話 @mattani さん

  • エンドユーザに提供しているサービスのインシデント管理をRedmineで管理している。
  • エンドユーザの情報管理上チケットに書けない情報を書けるようになれば効率化になる。
    • チケット通知本文に載ってしまう。
      • メール通知はやめられない。
      • SMTPS/STARTTLSは相手の環境に依存する。
      • エンド-エンド暗号化(S/MIMEPGP)を検討
        • PGP/MIMEプラグインの本家は更新されていなかったが、folk先は更新されていたのでPGP/MIMEプラグインを試してみた。
          • システム管理者がサーバで鍵ペアを作成する。
          • 全ユーザーに個人用鍵ペアを作ってもらい、Redmineに登録してもらう。
            • メールクライアントはOutlookとThunderbird78でPGPサポートされている。

LT: Power Automate Desktop(PAD)をRedmineから実行してみた @hiroiwsk6さん

  • 今回やりたかったこと

    • チケットからPADを呼び出したい。
    • チケットIDを引き渡して、実行結果を引き渡したチケットIDに返したい。
  • 苦労した点

    • PADをリモート実行するのが大変。
    • LinuxからWindows10のOSの差。
  • 今後の活用

    • 監視ツールからのアラートを受けて、RPAにシナリオ録画してRPAに実行させることはできないか?

LT: 見積もりスキル養成ギプスとしての Redmine @akabekobekoさん

資料

speakerdeck.com

内容

  • 見積は難しい。

    • 不確定要素が多く期限だけが決まっている。
      • 見積スキルを上げるにはどうすればよいか?
  • 予定工数と作業時間

    • これらを活用するだけで、見積もり筋がつく!
      • 予定工数をチケット作成時に入れる。
      • 作業時間を入力して実態を把握する。
  • 予定工数と作業時間の一致と乖離を体感を繰り返す。

    • 実態から見積達成の阻害要因を把握し、解決方法を考える。
      • 負荷を適切に保つこと。
  • 適切な負荷

    • 粒度が大きい=予定工数が長すぎる。
    • 工数が長すぎ=作業時間の記録が雑になりやすい。
    • 反復が難しい=スキル反映の機会が減る。
      • 予定工数の上限を決める。
      • 1週間以上の長期チケットは放置されがち。
  • 目の前のプロジェクトで実施すること。すでにある程度の見積もりを経たチケットがあれば、格好の材料。

  • 環境を作れなかったら、個人プロジェクトなどを作って自主練する。
    • 環境が作れない場合はテキスト上で実施する。

感想・最後に

今回は、タスク管理・プロジェクト管理に限らず、多様な事例を聞くことができて今まで以上に勉強になりました。 Redmineの拡張性の広さ、可能性の広さを感じることができました。 自分の所属部署では、プロジェクト管理ツールを使わずExcel管理が主流の職場ですが、 タスク管理・プロジェクト管理に限らず、Excelで管理していることはRedmineでも管理できそうだと思いました。 これまでExcel管理を良しとしていた職場なので、パネルディスカッション2でも話が上がったように、 ユーザにRedmineを意識させないようにすること、これは本当に大事だなぁと思いました。

Redmineを使って、プロジェクト管理に限らず、職場の課題管理や慣れた不便を解決したり緩和することはできないか、思考を巡らせたくなりました。 結果的にRedmineの導入ではないとしても、実現できたことがあったら登壇、グループディスカッション、懇親会で情報共有して、少しでもコミュニティに貢献したいと思いました。

毎回、様々な気づきを得ることができて、運営の皆様には本当に感謝です!今回もありがとうございました!!

cookieによるセッション管理とcookieの属性について

ウェブ・セキュリティ基礎試験勉強記事の2つ目。今回はcookie(クッキー)によるセッション管理とcookieの属性について書きます。

目次

参考文献

cookieとは

  • ステートレスなHTTPの仕様をそのままに、HTTPの仕様を拡張してWebアプリケーションとWebブラウザの間で情報交換、セッション管理を実現できるようにするための技術。
  • cookieが保持できる値の個数や文字列長には制限があること、利用者本人がcookieの値を参照変更できることから、秘密情報の格納には向かない。

cookieによるセッション管理

以下のような順番でセッション管理をします。

  • Webサーバからのレスポンス時に、WebサーバはCookieにセッションIDを格納します。
  • レスポンスヘッダの[Set-Cookie:]により、Webサーバはブラウザに対してCookie(セッションID)を保存するよう指示します。
  • cookie値を覚えたブラウザは、その後同じサイトにリクエストを送る際に覚えたCookie(セッションID)を送信します。
  • WebサーバはCookieを受け取ると、Cookieに格納されたセッションIDを基にしてメモリ上に持っているクライアントの状態を復元します。

セッション管理の要件

セッションIDは連番などではだめで、以下のような要件があります。

  • 三者がセッションIDを推測できないこと。
  • 三者からセッションIDを強制されないこと。
  • 三者にセッションIDが漏洩しないこと。

実際にはセッションIDの生成を自分たちで開発するのではなく、Webアプリケーション開発ツールにて提供されるセッションIDを利用した方が望ましいです。

セッションID漏洩の原因

セッションIDが漏洩すると他の利用者になりすましされる恐れがあります。セッションIDの漏洩の原因は、以下の通りです。

cookieの属性

cookieの属性は以下の通りです。

属性 意味
Domain ブラウザがcookie値を送信するサーバのドメイン。デフォルトではcookieをセットしたサーバのみに送信される。
Path ブラウザがcookie値を送信するURLディレクト
Expire cookieの有効期限(指定しない場合は、ブラウザ終了まで。)
Secure HTTPSの場合のみcookieを送信
HttpOnly JavaScriptからcookieにアクセス不可にする。

Domain設定

複数のサーバにcookieを送信したい場合は、Domain設定をします。 例えば、[Domain=example.jp]と設定すると、

  • a.example.jp 、b.example.jpにcookieが送信される。
  • a.examle.comには送信されない。
  • c.example.jpにはcookieを送信したくなくても送信されてしまう。

という動きになります。

ドメイン指定によりcookie漏洩(セッションID漏洩)の恐れがありますので、Domain設定は通常は設定しないことが望ましいです。

Secure属性

Secure属性設定を指定すると、HTTPSリクエストにのみcookieを送信します。これがないと、HTTPリクエストにもcookieを送信してしまいます。 平文でセッションIDを送ることになりますので、盗聴のリスクが発生します。

cookieにセキュア属性をつけることで、HTTPリクエストへのcookie送信を止めることができます。 ただ、HTTP/HTTPS混在のWebサイトの場合は、Webアプリケーションが動かなくなる恐れがあります。その場合は、別途トークンをチェックする対策が必要となります。

HttpOnly属性

JavaScriptからcookieにアクセスできないようにするための設定です。 XSSの影響を軽減する効果があります。ただし、根本的な対策にはならないため、XSSそのものの対策はする必要があります。

最後に

今回はcookieについてまとめました。HTTP(S)もcookieについても、この先脆弱性対策について理解するためにはちゃんと理解しておいた方が良いなと改めて思いました。 まだまだ「完全に理解した」わけではないので、たびたび見直しながら学習したいと思いました。

HTTPのGETメソッドとPOSTメソッドの違い

ウェブ・セキュリティ基礎試験(徳丸試験)を受験すると宣言してから随分と時間経ってしまいました。やっと着手できるようになりましたので、勉強再開します。 これからは、ウェブ・セキュリティ基礎試験について勉強したことをここに書いていこうと思います。

で、改めてGETメソッドとPOSTメソッドについて勉強しなおしましたが、「違いって何だっけ?」って思いましたので、整理しなおしました。

目次

参考文献

GETメソッド

  • 参照(リソースの取得)に使用する。
  • パラメータをURLに格納してリクエストをする。
  • 副作用(※)がないことを期待される。

※サーバ側でのデータ追加・更新・削除があること。同じ要求を何度繰り返しても同じ結果が得られること。

POSTメソッド

  • メッセージボディにパラメータ値を格納してリクエストをする。
  • 秘密情報を送信する場合に使用する。
  • 副作用がある場合に使う。
  • データ総量が多い場合(URLが長すぎる場合)に使用する。

秘密情報送信時にPOSTを使うべき理由

  • URL上のパラメータがReferer経由で外部に漏洩する恐れがあるため。
  • パラメータがサーバのアクセスログに残るため。
  • パラメータが入っているURLを利用者にSNSなどで公開される恐れがあるため。

Refererとは?

リンク元のURLを示すヘッダです。セキュリティ確保の目的でRefererチェックに使われたりもしますが、 アクセス者が意図的に書き換えることも可能です。 また、URLにセッションIDのような秘密情報を含んでいると、Refererヘッダから情報が外部に漏洩して、 なりすましに悪用される恐れがあります

最後に

今日はここまでにします。 これから勉強を進めるにあたり、不備不足がありましたら追記修正していきます。 短くてもアウトプットしながら学んでいけたらなぁと思います。

ssmonline #9「これからの時代の組織論 パネルディスカッション」参加レポート

4/28(水)、ssmonline #9「これからの時代の組織論 パネルディスカッション」に参加しました。

今回は沢渡さんと波田野さんと丸山さん3人のパネルディスカッションでした。始まる前から楽しみでした!

目次

イベントページ

ssmjp.connpass.com

togetter

togetter.com

セッション

沢渡さん これからの時代の組織論

資料

docs.google.com

  • 統制型マネジメントは確実性があるものに対しては有効。
    • しかし、統制型しか知らないと思考停止型人間を量産するリスクがある。不確実性に向き合えない。
  • イノベーションを生み出すには、統制型とオープン型のハイブリッドのマネジメントにシフトしていくこと。
  • デジタルワーク前提で時間で評価・拘束されない働き方が理想的。
  • 慣れた不便を言語化して、知的生産性を上げていく。

丸山さん 現場からみた運用組織論

運用をイノベーティブに変化していくためには

  • 変化に遅れない。
    • 運用のアジャイル
    • 意思決定の高速化
    • コミュニケーションの高速化(ホウレンソウからザッソウへ)
  • 先回りして速攻で相手のneedsを刺す。

    • 追うもののスタンスで。
    • 運用データ(監視アラート等)を情報に変え、傾向を読んで先手を打つ。
    • 問題を発見するスキルを身に付ける。
  • 測定できないものも管理する。

  • 権限移譲を積極的に行う。
  • 朝令暮改を変化に対する対応として前向きにとらえる。

  • 最適化が重要。

  • 「我々はどこにいるのか」を知り評価する。
  • 結果に対して謙虚になり正しく見直すこと。

波田野さん これからの時代の組織論

資料

speakerdeck.com

  • 組織はだいたい「硬直化・タコつぼ化」する。

    • 他部門の情報がなく、よその課題に興味を持てない。
    • 内部の最適化を求めて事業への貢献が後回しになる。
  • 硬直化・タコつぼ化を壊すには。

    • 情報の囲い込みをやめて情報をオープン化する。
    • 全体最適化指向になる。
      • 事業への最適化を求める。
    • 組織の構造を変える。
      • 機能的組織から事業的組織へ。またはその逆も。
  • ツリー型組織の弊害

  • ツリー型組織でオープンなコミュニケーションを実現するには

    • 経営が現場に任せる。
    • 現場に権限が必要。

パネルディスカッション

運用組織について

  • 運用組織は「運用実施」と「運用改善」がある。
    • 運用実施はオペレーティブ、運用改善はクリエイティブ。
    • それぞれ最適な組織や評価制度、スキル、マインドセットは違う。
    • オペレーションに興味がない人は、クリエイティブな仕事はできない。
    • オペレーティブ側の人をクリエイティブ側にすることで化ける人も一割ほどいる。
      • 組織がいかにそこに投資できるか。

人事領域とのコラボレーション

  • 会社文化がおかしいのは、人事制度もおかしい。
  • 人事担当者にもITリテラシーは必要。
  • 組織は人のつながりで存在するもの。ビジネスもコミュニケーションも大事。
  • 人事だけでなく、様々な組織が2.0にバージョンアップする必要がある。

守備範囲を広げるために

  • 自社サービスのドックフーディングをして、ユーザ側の問題点と担当者側の問題点を理解する。他人事にしない。
  • 日本の組織はグレーゾーン、野球でいうところの三遊間を拾わない傾向がある。
  • グレーゾーンを拾うためには
    • グレーゾーンの扱い方を定義する。
    • グレーゾーンを喜んで拾いたがる人に任せて正しく評価する。
      • クロスプレイになる可能性もあるが、それを怒らない風潮にすること。

最後に

あまりにもお三方の議論の濃度が濃すぎて、ついていくのがやっとでした(汗)が、ポイントとしては以下の通りかなと思いました。

  • 組織内外様々なつながりで組織はアップデートし成り立っていく。
  • 組織内向きの活動になりすぎず事業の成長に結びつくように。

改めて「組織」は生き物だなぁと思いました。生きていくためには成長していくことが大事。仕組みを作ったり改善をしても、それが事業の成長に結びつかないと不十分。 成長するためには当然一人の力では無理があるので、組織に所属する人たちがみんなで自分事となり協力し合える文化にできればなぁと思いました。 大変かもしれませんが、最初は一人で小さなことから工夫や改善をしていき、多くの人に伝搬できればと思いました。

熱い議論を聴くだけでも、「自分も頑張りたい!」と思えますね!力をもらってばかりでなく、誰かの力になれるようなアウトプットを自分もできるようになりたいです。

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

4.22(木)、JAWS-UG朝会に2か月ぶりに参加しました。今日も参加レポートを書いていきます。

目次

イベントページ

jawsug-asa.connpass.com

セッション

ラジオ体操

久々に本気でラジオ体操しましたw 良く体ほぐれました!!

はじめてのEKS Kubernetes案件 勉強方法 山田 俊一さん

資料

www.slideshare.net

概要

  • kubernetesは学習コストがあって、ネットも書籍も情報がありすぎてわからない。
  • 学習要点を洗い出し、優先度、現状、理想を目標設定する。
  • 学習要点ごとにレベル感をチェックし、体系立てて学習していく。
  • なんちゃって1人スクラムでPCDAをまわす。
    • 1週間を1スプリントとしてアウトプットを出していく。
    • 毎週上司と顧客にデモ、ふりかえり、改善を回していく。
  • ベースの学習にはEKS WORKSHOPが超おススメ。初級者のところまでやるのも学習になる。

AWS control towerの中身をみる 富松 広太さん

資料

www.slideshare.net

概要

  • AWS Control Tower とは、複数のアカウントを効率的に管理するためのサービス。
  • Landing Zoneが作られる(セキュリティとコンプライアンスのベストプラクティスに基づく環境)。
  • 違反作業の制限(予防的ガードレール)と違反作業の通知設定(発見的ガードレール)を有効にする。
  • 子アカウントにSCPの縛りがある場合はOrganizationsの方が良い。
  • これからマルチアカウント管理を始めるには、OrganizationsよりはControl Towerの方が良いかも。

お金がいっぱい溶けちゃったはなし sumiさん

資料

speakerdeck.com

概要

  • CloudEndure で80万円以上溶かした。
    • CloudEndure はオンプレのシステムをAWSに移行するためのシステム
  • 移行元サーバの容量(7TB)を把握しないままレプリケーションした。
  • 課金が怖く止めておいたが、移行元からはずっと同期されていた。
  • 移行元サーバの容量を把握していなかった。
  • 想定外の課金に気付けなかった。

  • 是正策としてAWS Budgetsで通知設定をした。

    • Budgetsは、使用料が予想を超えた時にアラートを出すサービス
  • AWS のコスト管理ツールはたくさんあるので、組み合わせてコスト管理するのも良い。

  • AWSは従量課金です!!

AWS Transfer Familyを触ってみた! ハンズラボ 中川 皓紘さん

資料

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

概要

  • AWS Transfamilyとは?
    • SFTP、FTP、FTPSでファイル転送ができるスケーラブルなマネージドサービス
    • SFTPサーバ立てるのと比べて管理コストがかからないので、SFTPサーバの面倒を見たくない人にはお勧め。
    • S3かEFSにデータ連携ができる。
    • 個別ユーザごとに細かなセキュリティ設定ができ、CloudWatchを使ったログ取得と解析ができる。
    • 料金が高くデメリットが大きい…

CloudTrail の証跡から IAM ポリシーを生成する IAM Access Analyzer の機能を AWS CLI から使ってみた話 弁護士ドットコム株式会社 伊藤 嘉洋さん

資料

speakerdeck.com

概要

  • IAM Access Analyzerの新機能について
    • CloudTrailの証跡(最大90日分)を解析してIAMポリシを作る。
      • 実際にはポリシドキュメント(JSON)を作る。
    • AWS CLIからも使える。
      • サブコマンド[accessanalyzer]が追加.された。

最後に

山田さんのKubernetesの勉強した時の話はとても参考になりました。目標を立てて体系的に学習していくこと、デモや報告を設定して進めることで自分も相手も理解を深められると思いました。自分も真似したくなりました!

sumiさんの80万円請求の話はビビりました。改めて料金通知設定は最重要と思いました。個人アカウントの通知設定と利用状況を見直さねば!個人で万単位のお金を溶かすとシャレにならない(汗)

今日はまだまだ知らないサービスの話が多く、勉強になりました。知らないサービスや技術の話を聞くと、もっとAWS勉強しようという気になりますね。また来月の朝会も参加したいです!

jawsug-asa.connpass.com

「エンジニアキャリア2.0~新時代の働き方、生き方を探る~」 参加レポート

4/17(土)、エンジニアtype様主催のカンファレンス「ENGINEER キャリアデザインウィーク」内の「エンジニアキャリア2.0~新時代の働き方、生き方を探る~」に参加しました。

目次

イベントページ

type.jp

ecdw2021.connpass.com

セッション概要

これからの時代、エンジニアの働き方はどう変わる?

「自分がどう生きたいか」を定義する

みなさん共通して仰っていたのは、一言でいうとこれかなと思いました。自分が楽しく働けるキャリアを自分で作ることが大事!もっと我を持って働いても良いのかもしれません。

  • エンジニアに限らず「私の働き方をこう変えていく」と言っていい時代だと思う(澤さん)。
  • テクノロジーによる課題解決にチャレンジしようとする人達が強い。自分自身がどうありたいか「個」の時代(戸倉さん)。
  • 会社に自分のキャリアを預ける今までの働き方はもう無理がある。キャリアの選択権を自分で持つこと(村上さん)。
  • エンジニアリングが分かっている人は強い。エンジニアの働き方はさらに広がると思う。

また、話の途中で「志」について触れていました。志はあった方が良いと思いますが、あまりにも志に対する気持ちが強すぎたり、志を決めなきゃと思うと動けなくなると思います。今の自分がそれかなぁって気づきました。

「志」を先に決めるのではなく、まずは「自分がどうありたいか」を見つめなおした方がよいと思いました。そこから「志」がついてくるのかなって思いました。

  • 志を持っていなかったが、持つ必要はないと思う(村上さん)。
  • 常に半歩先のことをやっていたら、場当たり的になる(澤さん)。
  • 志はキレイに見えるけど、ともすれば呪いの言葉になる(澤さん)。

組織との理想の関係は?

自分と会社はフラットな関係性が理想

会社は様々な保証をしてくれますが、会社に尽くせという丁稚奉公な文化が残っている。 ではなくて、お互いが良好な関係を気づき、パフォーマンスを出せる組織にする必要があると思いました。

  • 自分の気持ちを表現できる社風、自分を大事にしてくれる会社に勤めるのが理想的(戸倉さん)。
  • 会社と組織がお互いがいい具合で利用し合える関係。その会話が健全に出来るのが良い(村上さん)。
    • 全員が楽しくモチベーション高く働ける環境を作れる経営者は強い。
  • 自分が嬉しくなることを個々人がもう一度定義する(澤さん)。
    • 個々人の個性を生かせる会社は生産性が上がる。カオスな状況を十分に活用すればよい。

キャリア構築のヒントになる注目の「技術・働き方」トレンドは?

言語化能力

自分もこれが大事だと思い共感しかありません。自分がどうありたいか、どうしてほしいかを端的に表現して道を切り開く、自分の身を守ることを考えるためには、言語化能力が必要なのだと思いました。

澤さん
  • 具体化を一度抽象・汎用化して、別の具体化をできる能力が必要。
  • 経営者など非エンジニアの人々にテクノロジーのブリッジ(通訳)を出来る人が必要。エンジニアはみんなその候補生。
村上さん
  • 抽象化して一発でわかってもらうために、コミュニケーションスキル(ライティング、スピーキング等)が全職種に必要になる。
戸倉さん
  • 自分の身を守れるように考えることが必要。

転職するかしないかの見極めはどうしたらいいの?

ポイントは「市場価値を知ること」「自分らしくいられる環境かどうか」かなと思いました。市場価値を知って他社でやっていけるか、やっていけても自分の気持ちと折り合いをつけられる環境か、それに見通しが立てば転職に踏み出せるのかもしれないと思いました。

村上さん

  • 自分の市場価値を見極めるためにも転職活動は常にした方がいい。するつもりがなくても。
  • 辛い仕事を辛いままやり続けなくても良いように、自分の中で別のプランを作る。

澤さん

  • 自分に「タグ」が付いたと思ったら、いつでも転職できると思う。そのための活動をする。

戸倉さん

  • 自分が優先したいことができる会社が理想的。
  • 自分が必要とされているか?を見直す。
  • やりたいことに対してできたポジションに対して、「今しかない!」と思えたら迷わずGO!

【質問】一緒に仕事したいと思うエンジニアの条件

  • 課題認識を正しくできて、複数の提案をできて、それに対するリスクを正しく出せる人。(村上さん)
  • 船が難破して「こいつと一緒に生き延びることができるか?」と思える人。 スキル云々ではなくて人間力の方が大切。(澤さん)
  • 変化を楽しめる人(戸倉さん)

これは採用の立場からだけでなく、今いる環境についても当てはまるかもと思いました。こう思えなくなった人が近くにいたら、自分の成長も阻害されかねないし、楽しくなくなると思います。自分がこれを感じたら、転職など居場所を変えることもありなのかなぁと思いました。互いに敬意を持ちつつ、楽しく協力して仕事できる関係性が健全だと思いました。

【質問】新人ならばこれをやってけ!ということは?

澤さん

  • 筋トレ!体が健康なのは大切。

村上さん

  • 今いる場所で期待されていることの100%以上のことを出せるように動くこと。

戸倉さん

  • 所属書式の人やテクノロジーに興味を持つこと。
    • 役員やキーパーソンの名前を覚えることは人への興味の現れ。
  • 日記をつけておくこと。ふりかえりのために。

【質問】言語化能力を鍛える方法

皆さん共通して仰ってたのは Twitter!!140字以内に収めるのって、何気に大変なんですよねw自分も言語化能力向上を意識して使っていきたいと思いました!

澤さん

  • ツイートするにも食事の写真だけ等でなく、なぜこれを選んだかなどを書くと良い。
  • 音声メディア(Stand.fm、Voicyなど)で話すことも言語化能力を鍛えられる。

戸倉さん

  • ツイート内容への反応から伝え方の良しあしを確認をする。
  • レスポンスをスピーディーにすることにも意識する。

【質問】影響を受けた本は?

  • マーケターのように生きろ(戸倉さん)
  • 葉隠(澤さん)
    • 武士の生きざまが書かれており、現代にも通ずるところがある。
  • 「釈迦とバザール」「人を動かす」(村上さん)

英語の必要性

村上さん

  • 英語はもっともコスパのよいスキル。
  • 今から必死にやれば話せるレベルになる。リアルタイムに話すためには英会話が必要。

澤さん

  • 人間関係構築のためには自分で話せた方がいい。
    • 情報交換程度ならばリアルタイム翻訳でも良い。

最後に

  • 世の中を変えることに関与できる素晴らしい仕事。テクノロジーをキーワードに自分が活躍できる場を探して楽しんでもらいたい(戸倉さん)

  • 世の中を面白くする力を持っているんだと思って働いてもらいたい。色んな分野に欲張ってもらいたい。色んなところに自分の立ち位置を作ってほしい(澤さん)。

  • エンジニアには伸びしろしかない。全産業にICTが必要になる。テクノロジーの翻訳者などエンジニアのバックグラウンドになれるよう視野を広げて色々考えること(村上さん)。

まとめ

自分がどうなりたいか、どうすれば面白く生きられるか、それをアウトプットして伝えることで自分を守り世の中をよりよくしていくことができる。ブログ書いたりツイートしていることは間違っていない、もっと鍛えるつもりで取り組みたいと思いました!!「自分はどう生きたいのか」「どうやって世の中に貢献できるか」を自分はまだ定義できていないので、日々考え、言語化を繰り返していきたいと思いました。まだまだ言語化能力を鍛えられる、自分には伸びしろがありそうでワクワクしてきました!

澤さん、村上さん、戸倉さん、貴重なお話をありがとうございました!

土曜日の午前中に開催を企画していただいた主催の方々に感謝です!