Posts

1.この記事で達成したいこと aws_security_groupリソースを使って複数のインバウンドルールを追加しようとして引いたエラーを解決する $ terraform apply 略 │ Error: error updating Security Group (sg-000000000000): error authorizing Security Group (ingress) rules: InvalidParameterValue: The same permission must not appear multiple times │ status code: 400, request id: 000000000000000000 │ │ with aws_security_group.dummy-sg, │ on main.tf line 23, in resource "aws_security_group" "dummy-sg": │ 23: resource "aws_security_group" "dummy-sg" { エラーメッセージが指す23行目付近で書いていること $ view main.tf 略 23 resource "aws_security_group" "dummy-sg" { 24 name = "dummy-sg" 25 description = "dummy security group" 26 vpc_id = aws_vpc.dummy-vpc.id 27 28 ingress { 29 description = "Allow 80 from anywhere for redirection" 30 from_port = 80 31 to_port = 80 32 protocol = "all" 33 cidr_blocks = ["0.0.0.0/0"] 34 } 35 36 ingress { 37 description = "Allow 8080 from anywhere for redirection" 38 from_port = 8080 39 to_port = 8080 40 protocol = "all" 41 cidr_blocks = ["0.0.0.0/0"] 42 } 2.前提 Terraformのインストール方法を始めとする初期設定は終えているものとして話を進める 3.環境情報 Terraform実行環境 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ terraform version Terraform v1.1.0 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v3.70.0 ※ terraform applyで使う要件については、後述するaws_security_groupリソースくらい。なので、ここでは割愛。 ...

1.この記事で達成したいこと 以下の本を読んだので感想や学びを残す 走ることについて語るときに僕の語ること (文春文庫) | 村上 春樹 2.本書の内容を三行で 優れた小説家には才能があるが、自分にはそういったものはなく、凡人といっていい では、凡人がどうやって小説を書き続けようか？（そもそもなぜ書くことになったのか？も触れている） それは小説を書き続ける集中力とそれを支える体力を養おうと考え、試行錯誤していく、、 3.感想 本書は、特に秀でたわけではないが続けなければならないこととの付き合い方 という普遍的な問いに対して示唆を与えてくれる。自分は先天的な才能を持ち合わせていないという境遇が分かったとしても、集中力や持続力は後天的に身につけることができる。また集中力や持続力は肉体的な衰えと抗うためにも必要だという。そういった集中力や持続力を獲得するためになんとかランニングを始め、トレーニングを続けているが、その難しさと続けるコツ、考え方のヒントが本書では散りばめられている。ぼくにとって胸に響いた箇所は以下の 2 箇所だ。 Pain is inevitable, Suffering is optional. それが彼のマントラだった。正確なニュアンスは日本語に訳しにくいのだが、あえてごく簡単に訳せば、「痛みは避けがたいが、苦しみはオプショナル（こちら次第）」ということになる。 たとえば走っていて「ああ、きつい、もう駄目だ」と思ったとして、「きつい」というのは避けようのない事実だが、「もう駄目」かどうかはあくまで本人の裁量に委ねられていることである。 走り続けるための理由はほんの少ししかないけれど、走るのをやめるための理由なら大型トラックいっぱいぶんはあるからだ。 僕らにできるのは、その「ほんの少しの理由」をひとつひとつ大事に磨き続けることだけだ。 また、本書は継続する勇気と活力を与えてくれる。文体はみずみずしく、景色が目に浮かぶよう。自己啓発書というより小説を読んでいるかのような気持ちになる。それで何かを続ける難しさと大切さを自身の経験談になぞらえて語られている。ぼくはいわゆるソフトウェア・エンジニアとしてお仕事しているのだけど、本書を読み進めていくうちに、走って、自分をシステムに見立ててパフォーマンスチューニングしたい気持ちに駆られる。（実際やったがなかなか続かない笑。） このようにぼくは本書から何かを続けること、とりわけ自分がそこまで得意ではないことを粘り強く続けることのエッセンスを学んだと思っている。とはいえ、これだけが本書から学ぶことができることではないはず。なんども読み返したい一冊である。

こんにちは。gkzz (@gkzvoice) / Twitterです。本記事は社会人学生 Advent Calendar 2021の 24 日目の記事です。 実は先日、学生生活のふりかえり記事を書いています笑。 帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる | gkzz.dev せっかくなので自分の社会人学生生活について改めて向き合うこととし、表題のとおり「ほんとうに社会人学生になってよかったのか？」と批判的に捉え直すことにしました。多くの社会人学生のふりかえり記事では、社会人学生になることに対して大変など苦労する声を聞くことはありますが、結論としてはポジティブな内容が多いです。ところが、ぼくの場合はそんなことはなくて悩みながら勉強しているというのが正直なところです。社会人学生生活のネガティブな一面にもっとフォーカスした記事を読んで自分の考えを反芻させようとするも、そのような記事はなかなか見つかりません。そこで現時点での考えを後々思い出すことが出来るように、自分のために「結局自分は何を決めかねているのか？」書き留めておくことにしました。 想定読者 本記事の想定読者として以下の 2 点を挙げている。 社会人学生になろうと入学書類を集めている、社会人学生になる前の自分 晴れて大学を卒業した、社会人学生を終えた後の（、大学での学びを活かす決断をするときの）自分 というのも、「そうだ、社会人学生になろう！」と準備を進めているころに読んでいたらまた違った展開になっていたかもしれない。また「卒業してから何をするか？」について少しでも今の考えを書き留めておくことで実際にそうなったときに考える助けになるように思うからである。 後者については、後述するハッカー飯さんという Web サービスをきっかけにいただいたフィードバックであり、かつなくてはならない観点だった。他にもたくさんの方からご指摘いただいたので改めて感謝の気持をお伝えしたい。ありがとうございました！ さて、はじめに本記事を書いているぼくの背景について軽く触れておきたい。というのも、ここで取り上げる話題に対する考え方は読者によって千差万別だと思うし、またそうあるべきだと思うので、あくまでもぼく個人の場合という前置きをおくためにも書いておきたい。 自己紹介 もともと経済学部卒、営業寄りの仕事をしていたが、プログラミングをする機会があり、エンジニアに転職してはや 4 年。 先日サイボウズに転職。 今年 2021 年 12 月、帝京大学理工学部の通信教育課程の 2 学年に編入学。 予想はしていたが、仕事と勉強の両立はたいへん。 またそれとは別に「ほんとうに社会人学生になってよかったのか？」とやや考えがゆらいでいる。（今回の主題はココ！） 「大事なことは卒業することではなく、卒業してから何をするか？そのために今後の自分の人生に置いてどこに専門性を置くか？決めて進むこと」であるが、それが決まらない。 卒業するという手段が目的化している。 どうして悩んでいるのか？ 仕事と勉強でてんやわんや。 このままでは単位を取るだけで終わってしまうという危機感は募る。 とはいえ、微々たるではあるが、できなかったことができるようになっていく感覚はある。 「ほんとうに社会人学生になってよかったのか？」と問われるとなってよかった 「わざわざ学生にならなくても勉強はできるけれども、どうして学生をするのか？」それは勉強そのものが好きだからというのと、学歴をゲットして第三者に勉強した結果を評価してもらいたかったから。 社会人学生になって迷いはあるけど社会人学生にならなかったらまた別の迷いが出てきそう、、。 で、答えは出ていないけど「卒業してから何をするか？そのために今後の自分の人生に置いてどこに専門性を置くか？」決めるためのヒントはみつかった これまで選んできた選択が実は関連性があった。 Steve Jobs’ 2005 Stanford Commencement Address もともと経済学部に在籍していたせいか、株式投資、企業価値評価は興味がある。 理転した、しないは関係ないという見方もできるのか 「古きは潔く捨てよ」“アンラーニング”がベテランエンジニアの価値を左右する【GMO ペパボ・栗林健太郎】 - エンジニア type | 転職 type 入学する前の自分に伝えたいことを五月雨に 一般の技術書や記事、YouTube の動画など学習教材は玉石混交ではあるがあふれており、学習の機会はいくらでもある。 単位駆動でインプットが進む。 時間の使い方に制約が入ると集中できるというか集中せざるを得ない環境に追い込まれる。 関心の対象が広がった。 単位を取るために食わず嫌い精神を捨てて勉強するため、以前まで興味がなかったことに対しても関心を持つことが出来るようになり、自分の可能性を広げることができた。 勉強も学校にとらわれることなくやりたい。 勉強以外の活動もしてもいい。 たとえば、[【読書メモ】『HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント』 | gkzz.dev より。 マネージャー業務に関心・興味がないわけではなく、むしろチャレンジしてみたいなというお気持ち 興味が湧いたきっかけは以下のポッドキャストを聞いたこと 良いマネジメントとは？良いミーティングとは？ w/ konifar | fukabori.fm 着地点のない内容ですが、書かない後悔よりは書くめんどくささを選び、記事にしたためました。これからもがんばるぞ〜！！ ...

1.この記事で達成したいこと 以下の本を読んだので感想や学びを残す The DevOps ハンドブック 理論・原則・実践のすべて : ジーン・キム, ジェズ・ハンブル, パトリック・ボア, ジョン・ウィリス, 榊原 彰, 長尾 高弘: Japanese Books 2.前提 本題に入る前に、前提として僕の DevOps 周りの背景知識について触れようと思う。 2-1.僕の DevOps 周りの背景知識 これまで以下の経験をしており、多少なりとも DevOps とはなんぞやという点は抑えているつもりだった。。 toB の Web サービスの運用と開発 Gitlab Runner と Argo CD を使った GitOps なパイプラインの設計と構築 Django 制の社内システムの開発 以下の podcast を聞いたことがあり、Circle CI はまさに DevOps を体現していると思っている 7. CI/CD とか、CircleCI 自体の設計・開発プロセスとか | fukabori.fm ※ 本書を読み進めるまでは、DevOps とは開発と運用が手を取り合っておこなうこと、あるいは一手に引き受けることだと思っていた しかし、本書を読み進めていくうちに、DevOps を推し進めるには、それだけで足りないと考えを改めることになる 3.目次 第1部 3つの道 第1章 アジャイル、継続的デリバリー、そして3つの道 第2章 第1の道:フローの原則　ほか 第2部 スタートのための糸口 第5章 最初に手を付けるバリューストリームの選択方法 第6章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる　ほか 第3部 第1の道:フロー改善の技術的実践 第9章 デプロイパイプラインの基礎の構築 第10章 高速で信頼性の高い自動テストの実現　ほか 第4部 第2の道:フィードバックの技術的実践 第14章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す 第15章 遠隔測定データを分析して問題の予測と目標の達成に活かす　ほか 第5部 第3の道:継続的な学習と実験の技術的実践 第19章 日常業務での学習の実現と日常業務への学習の注入 第20章 一部門の発見を全社的な進歩につなげる　ほか 第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践 第22章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける 第23章 デプロイパイプラインを防御する 4.感想や学び DevOps とは開発と運用が手を取り合っておこなうこと、あるいは一手に引き受けるという方法論だけを説いているのではない。 ソフトウェアの変更を早く、安く、正確にプロダクション環境に反映させるという目標がまずあり、その目標を達成するために IaC を始めとする方法論などの話題が出てくる。 本書で言うリードタイムとプロセスタイムの違いに意識するという点もその一例。 DevOps は Unix 哲学の考え が随所に表れているという印象を持った。 例えば、DevOps を推し進める上で重要なこととして、リリースやデプロイのサイクルを早くするためにバッチサイズを小さくしたり、受け渡しの数を少なくすること（フローの原則）を挙げている。 このようなリリース対象を小さくすること、あるいはパイプラインの簡素化はまさに Unix 哲学でいう"Small is beautiful"や"Make each program do one thing well"だと感じた。 DevOps を推し進める上で重要なことはフローの原則以外に以下の 2 つを挙げている。 フィードバックの原則。 継続的な学習と実験の原則。 フィードバックの原則と継続的な学習どちらも大事なことだと思うが、ここではフィードバックの原則に関連して今月弊社に転職して驚いたことがあったので書き残しておきたい。 それは 「フィードバックをし、またそれを受け入れている光景」 をいたるところで見かけるということ。 例えば、情シスなどいろんな部署が主催するオンボーディング研修に参加すると、都度 zoom で質問やコメントをしあっている。 また、kintone のアプリ（チャット）上でも、そういったやりとりがテキストベースでされている。 なお、これは余談だが、情報量が多い様子を「情報の海」と言うこともあり笑。 以下の記事のとおり、情報の取捨選択が求められていると感じる。 cf. 若手から偉い人まで！ テレワークで重宝されるサイボウズの分報はいかにして社内に浸透したのか？ - ログミー Biz 5.本書で何度も読み返したいところ 『6.3 専任の変革チームを編成する』 ...

本日2021年12月01日(水)、サイボウズ株式会社（Cybozu, Inc.） に入社 しました。ポジションは 生産性向上エンジニア です。これに伴い、株式会社エーピーコミュニケーションズ（以下、APC）を先月11月30日付で退職しました。 ※ 写真は近くのお花屋さんで買った観葉植物を撮影したもの。寒々とした今年の冬を乗り越えようと古い葉っぱを落として新しい葉っぱが代わりに台頭している。 これまでやってきたこと お仕事 toBサービスの運用やCI/CDパイプラインの設計・構築などいろいろ プライベート 社会人大学生として情報系の勉強をしている 帝京大学理工学部(通信教育課程)の社会人大学生1年目をふりかえる | gkzz.dev それまでは読書会を毎週開催したりしていた #技術書を英語で読む会 という自分が参加したかった読書会を半年ほど開催したからふりかえる | by gkzz | Medium ブログでも書いているのでご参照ください！ https://gkzz.dev https://zenn.dev/gkz https://qiita.com/gkzz 生産性向上エンジニアとしてやっていきたいこと 採用ページに書いてあるとおり、横串に自動化/効率化施策を推し進めていくと伺っています。あまり扱っていく技術や取り組んでいく業務内容にこだわりはなく、むしろチームにとって必要だけど手が回っていない 「落ちているタスク」 を拾い上げてきたので、これからも選り好みせず地道にやっていこうとおもいます。 業務内容 チームを横断した開発効率を高める基盤の整備 開発チームの業務の自動化や効率化の支援 など 過去の活動事例はこちら https://blog.cybozu.io/archive/category/生産性向上チーム https://tech.cybozu.io/slides/tags/生産性向上チーム/ 主に使っている技術要素 言語: Go, TypeScript バージョン管理: GitHub (Enterprise Cloud / Enterprise Server) CI: GitHub Actions, CircleCI, Jenkins アプリケーション監視: Datadog パブリッククラウド: AWS, GCP 仮想化技術: Docker, Kubernetes Infrastructure as Code: Terraform, Serverless Framework 参考：キャリア採用 生産性向上エンジニア | サイボウズ 採用情報（新卒・キャリア） ...