エンジニアの梅原です。 少し前から「心理的安全性」というキーワードについて、疑問に思うところがあって色々と考えていて、 なんとなく考えがまとまったので、自戒も込めて文章として書き起こしてみました。 もともと社内向けに書いたものでしたが、思いのほか反響があったためこちらでも書いてみようと思います。 めちゃくちゃなこと言ってんな、って思う人もいるかもしれませんが、際に振ったときの思考実験だと思って読んでもらえると。 心理的安全性とは何か？ 一般的に「心理的安全性」とは、以下の定義で語られます。 "A shared belief held by members of a team that the team is safe for interpersonal risk taking." （このチーム内では、対人関係上のリスクをとったとしても安心できるという共通の思い） Edmondson (19

（※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。） はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ

（※以下は去年の弊社のQiita アドベントカレンダーに投稿したものです。） リンクアンドモチベーションで、QAエンジニアをしています、代慶と申します。 先日のレガシーコード改善のワークショップに引き続き、和田卓人（t_wada）さんにTDD（テスト駆動開発）に関してワークショップを開催してもらいました。 本記事では、t_wadaさんの頻出していた言葉や名言と共に、当日の研修での学びの概要を伝えていきたいと思います！ 当日の流れ 当日は、10人のエンジニアが10時から16時まで研修を受講しました。 前半は、座学メインで、適宜質問にも答えていただきました。 後半は、実習メインで、TDDの実践を行い、t_wadaさんとの公開1on1の時間を設けていただきました。 ※今回の講義は、前もってTDD Boot Campの動画の視聴も行い、よりTDDの理解を深めることができました。 TDDの概要 TD

こんにちは、リンクアンドモチベーション SREグループの久原です。今回はSREチーム内で取り組んでいるAmazon ECS on Amazon EC2(以下 ECS on EC2)構成からAmazon ECS on AWS Fargate(以下ECS on Fargate)構成への移行プロジェクトについて、特にEC2とFargateの差分を中心にお話しできればと思います。 背景 サーバーレスへの移行に関するメリットについてはここでは詳しくは触れませんが、一般的に言われているように サーバー管理等の運用コスト削減 が主な移行の背景となります。 弊社ではこちらの記事に記載のある通り、4Keys Metricsという指標をモニタリングし、開発組織の継続的な改善活動に取り組んでいます。 開発フローの細かな改善も重要ですが、より高いレベルに進化させるためには抜本的なアーキテクチャの見直しが必要となり

はじめまして、新卒からCREグループに配属されて2年目のWakaです。 この記事では、CREのエンジニアチームが「日々取り組んでいること」と「心がけていること」をご紹介いたします。 そもそもリンクアンドモチベーションのCREとは？ エンジニアチームって何しているの？ プロダクト対応 仕様確認 障害対応 イレギュラー対応 顧客が迷わず利用できるようにするための改善 プロダクト改善 ヘルプページの更新の依頼 CSのケイパビリティ向上 CREエンジニアとして、心がけていることは？ お客様のお困りごとを想像すること 技術で解決することに誇りをもつこと そもそもリンクアンドモチベーションのCREとは？ チームでは、「顧客の信頼性を最大化する」をミッションに掲げ業務をしております。 具体的な業務は、得意な領域により以下のような役割分担で対応をしています。 アプリケーション開発・改善を通して、顧客の不安

はじめに こんにちは リンクアンドモチベーション QAエンジニアの小島です 開発ツールの導入者がチームにツールを浸透するのに苦労する というのはあるある話かと思います なんで必要なの？ どう操作するの？ どうメンテしていくの？ こうした壁を乗り越える話を、先日Autifyさんのイベントで発表させて頂きました その内容や気付きを紹介します 活用に至るまでの道のり 実は、弊社でAutifyを導入してから1年が経ちました 振り返ると、色々な壁を乗り越えて来たんだなと感じます そもそもAutifyってなに？から説明したり 導入でテスト工数が削減できて喜んだり 時に活用が難しくなって相談をもらったり 自由に使い方を改善するチームが出てきたり 中でも今回は、開発チームが自律的に活用するステップに焦点を当てています 発表内容 スライド speakerdeck.com YouTube 発表は30:45~で

はじめまして。リンクアンドモチベーションでソフトウェアエンジニアをしています、shimody13です。 主に普段の業務では、モチベーションクラウドの新規開発チームのメンバーとして働いています。 僕自身、大学生の頃はエンジニア経験はなかったので入社して初めてエンジニア配属が決まり、エンジニアとしてのキャリアが開かれたという形です。 当初は右も左も、配列も分からない自分でしたが、リンクアンドモチベーションで働く中で、徐々にエンジニアとしての奥深さ、楽しさに気づいていけて、今ではエンジニアになれて本当にラッキーだったなと思っています。現在は配属を決めてくれた、会社の人事の方には非常に感謝しています。 本記事では、そんな僕がリンクアンドモチベーションで働く中で、若手エンジニアとして働く弊社の魅力を記述していけたらと思います。自分みたいな若造が、10年年上の先輩に魅力を訴求できるかは分からないので、

以下は去年の弊社のQiita アドベントカレンダーに投稿したものです。 qiita.com これはなに？ はじめまして。リンクアンドモチベーションの伊藤です。 主にバックエンドの開発を担当しており、最近はタイトルにあるように新規機能開発や既存機能改善に関わる多くの設計に「レビュワー」として携ってきました。 この記事では私がレビュワーとして開発の「設計」に関わってきた中で、 スムーズにステークホルダーの認識が揃ったな 議論がより深まった上で決定できたな と感じた設計におけるポイントをまとめてみました。 「設計でなにをしたらいいか迷っている方」 「コーディングだけじゃなくもう少し上流工程に入りたいと思っている方」 の参考になれば幸いです。 そもそも設計って？ この記事では特に「基本設計」について触れていきたいと思います。 実装よりも上流の過程についてはこの記事などを参照ください。 唐突ですが設

こんにちは。リンクアンドモチベーション SRE グループの綿引と申します。 今回はRedashから別AWSアカウントのDBに対してアクセスできない際に確認するポイントをご紹介したいと思います。 ただ以下の背景の関係上 「Redashサーバが存在するAWSアカウントと参照したいDBが存在するAWSアカウントは VPCピアリングで接続されている 」 という前提で進めさせて頂きますので、その点はご容赦頂ければと思います。 背景 先日 「ある AWS アカウントの Redash から、別アカウントの Aurora に対しアクセスを可能にしたい」 という話があったので対応したのですが、このナレッジを残しておきたいと思ったことが背景となります。 尚、構成に関して次項に記載しているのですが、本記事を見て頂いている方の担当システムで全く同一の構成というケースは少ないかとは思いますのでご参考程度に見て頂けれ

はじめに こんにちは。 リンクアンドモチベーション SREの篠原です。 普段アプリケーションの開発をしていると、何かしらに繋がらなくて困るといった場面は少なくないと思います。 立ち上げたはずのwebアプリにアクセスできない アプリとDBが疎通できない 〇〇のサーバにSSHできない 現在SREとして、そして過去インフラエンジニア/システム管理者としての経験もある筆者がこのような時にどうやって調査し解決しているかを紹介します。 特に若手の開発者やインフラエンジニアの方々に参考になれば幸いです。 (あくまで個人の考えのため、もしより良い方法などありましたらぜひコメントで教えてください!) L4レベルで疎通できるか確認 役に立つコマンド nc telnet curl OSI参照モデルにおけるL4、トランスポート層での通信ができるかどうかをまず確認します。 誤解を恐れずにいうと具体的にはIPアドレス

こんにちは、リンクアンドモチベーション SREグループの久原です。今回は、SREチーム内の生産性・信頼性向上のために取り組んだミドルウェアアップデートの自動化施策について紹介いたします。 背景 自動化の成果 手順の簡略化 before after 対応時間の削減 やったこと ミドルウェアアップデートの手順 自動化の方針 ①各項目ごとに手動の部分はCodeBuildを使って自動化する before after ②項目間の移行はCodePipelineを使って一気に実施できるようにする 今後の展望 背景 なぜミドルウェアアップデートの自動化に取り組んだのか？それは現在SREチームで注力している 「トイルの削減」に対して大きく貢献するため です。インフラ民主化の記事でも取り上げたように、トイルの対応時間のトップ3を見ると、かなりの割合をミドルウェアアップデートが占めていることが分かります。 トイ

こんにちは。リンクアンドモチベーション SRE グループの川津と申します！ 弊社では、開発や本番環境等、至る所で Docker (コンテナ仮想化) を利用しています。 普段から使っているが、仕組みは分からない！という方も多いのではないかと思い記事にしました！ 背景 近年の開発では、各自のローカル PC 上での開発として docker (docker-compose) を使う事が多くなりました。 例えば、最近の Web Application の殆どは以下の３つを使って動きます。 RDB (e.g. mysql) in-memory data store (e.g. redis) Object Storage (e.g. Amazon S3 , MinIO) 昔は開発者 wiki や README.md に上記の構築方法が書かれていて、開発者みんなが頑張って自前でローカルマシン上に構築をして

はじめに バックエンドエンジニアのやまぴーです。 pryというツールをマネしながら対話型デバッグツールを作成していた 前回の記事の続きになります。 前回までの様子 シンタックスハイライト どうも味気ない印象なので、見栄えを良くしていきたいです。 エスケープシーケンスで色やスタイルを付与したいと思います。 試行錯誤の末、テストが最終的にこんな感じになりました。 { '42' => "\e[1;34m42", '6.7' => "\e[1;35m6.7", '"string"' => "\e[31m\"\e[31mstring\e[31m\"", 'class' => "\e[32mclass", 'Object' => "\e[1;34;4mObject", }.each do |input, expected| assert(expected, Pry::SyntaxHighlighted

目次 はじめに ことのきっかけ 改善提案のためにやったこと 解決する課題を決める プロトタイプを作る 戦略を立てる アウトカム目標を設定する 提案する さいごに はじめに はじめまして、フロントエンドエンジニアの鵜木(うのき)です。 弊社では現在、生産性の向上を目的に Motivation Cloud (以下 MC)のフロントエンドをリアーキテクトしています。今回はこのリアーキテクト活動の背景やここに至るまでの経緯をご紹介したいと思います。 新しいアーキテクチャの設計内容や採用した技術スタックに関する紹介は別記事で行います。なので本記事はこれからアプリケーションレイヤーの大規模改善を検討している人向けになります。 ことのきっかけ リアーキテクト活動が始まったきっかけは、フロントエンド横断組織(通称 フロント会*1 )メンバーの開発モチベーション低下が発覚したことです。その時のコメントを一部

はじめまして。Motivation Cloud のエンジニアをしています、宮田と申します。 Link and Motivationには2022年3月に入社しました。 私はキャリアにおいて、SIerやITベンチャーといった創業当時からIT系のサービスを提供する会社に在籍していました。 Link and Motivationのような創業が非ITの会社は初の経験です。 本記事では、入社してから感じたことを書こうと思います（忘れないうちに！）。 Link and MotivationやDXを進める非IT企業に興味を持っている方の参考になれば幸いです🙇‍♂️ Link and Motivation に興味を持ったきっかけ 元々Link and Motivationという会社のことは知っていました。 新卒の就職先としては人気でしたし、グループ会社のopenworkは転職時の参考にしていました。 しか