安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
2022年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
People Experienceチーム*1の酒井（@sakay_y）です。 2022年もエンジニア新人研修を行いましたので、軽い紹介と、講義資料および一部講義動画を公開いたします。 2022年のエンジニア研修について 講義資料公開（2022年版） モバイルアプリ開発 サイボウズのアジャイル・クオリティ MySQL - テストデータが偏るということ モブに早く慣れたい人のためのガイド テクニカルライティングの基本 ソフトウェアテスト セキュリティ ソフトウェアライセンス 社内限定の講義や昨年と同じ講義について 最後に 2022年のエンジニア研修について 研修のコンセプトは例年とほぼ同じです。 誰に 新入社員メンバーに 何と言ってもらう 基礎的な知識/技術/ツールを学べた！ 開発/運用本部のチーム/人を知ることができた！ スケジュールは以下のとおりです。（一部は、予定になります。） 講義期間
技術を楽しめているか？ Scalaエンジニアが研究・開発・教育それぞれで試行錯誤した10年のキャリア - Findy Engineer Lab
読者の皆さん、はじめまして。株式会社オプト所属のエンジニアでかつJapan Scala Association（JSA）理事を務めている水島宏太（@kmizu）と申します。 この記事では、私の経歴を大学院の修士課程から現在に至るまで振り返って、どのような試行錯誤をしてきたかを「教育」「研究」「開発」という3つの軸を中心にお話ししたいと思います。この軸は今の自分を規定しているものでもあり、これまで試行錯誤してきたものでもありました。 私のキャリアは割と行き当たりばったりな部分がありまして、皆さんの参考になるかどうか分かりませんが、「こういうキャリアもあるんだ」「こういう生き方もありなんだ」程度にでも受け止めてもらえればうれしいです。 「研究する力」と「技術の感性」を磨いた大学院時代 プログラミング言語でわいわいする楽しさ 人生の転機となったScalaコミュニティ活動 ScalaMatsuri
はじめての「簡単なお仕事」は簡単ではない。 - MonotaRO Tech Blog
モノタロウでスマホアプリを担当しているuw_shioです。 今回は増員をしていった結果、各自がそれぞれ頑張るようなチームとなってしまった状況から、ペアワークをきっかけに、ペアプロ、モブプロが文化となってチームとしてワークできるようになったお話をします。 組織の規模が拡大していく過程において、属人化された業務を個人単位で行う働き方から組織としてワークする形へのシフトは避けて通れない道となります。そんな時に悩みの種となりやすいのが、業務の属人化やメンバーの育成ではないでしょうか。 部下や後輩に新しい業務を引き継ごうとしても時間がかかり上手くいかない、そんな経験ありませんか？私は過去に何度もありました。 例えば、アフリカーンスなど未知の言語を習得するというタスクをアサインされたとしたら、何から始めて良いか分からず漠然とした不安を感じるのではないでしょうか。新しいこと、とりわけ新しい業務に対しては
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
リクルートテクノロジーズ エンジニアコース新人研修の内容を公開します！（2020年度版） | Recruit Tech Blog
こんにちは！ リクルートテクノロジーズでセキュリティエンジニアとして活動している、藤原 巧です。 毎年恒例となっており、大きな反響をいただいている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートテクノロジーズでは、新卒採用の新人向けに３ヶ月間の技術研修を行っています。この技術研修では大きく分けて２つのコースが設けられています。 1. プログラミングやWebサービスの構造の基礎を体系的に学び、その後一人につき、ひとつのスマホサイトを企画からリリースまで行うコース 2. 一定以上のプログラミングスキルと開発系経験がある新人に向けた、実際の開発で必要となる様々な技術要素をより深く学び、その後実際のサービスでチーム開発にてOJTを行うコース 今回公開するのは 2. で使用した資料です。 この技術研修は、そのほとんどの部分を内製で実施しています。 この研修の最大の
２つのDXと技術的負債-YAPC Tokyo 2019
「エンジニアリング組織論への招待」はビジネス書としても技術書としても評価された。これら二つは別のことなのだろうか。それをも同じものなのだろうか。 この講演では技術者体験DXと企業のデジタル化のDXの２つを橋渡ししていく。 「エンジニアリング組織論への招待」の骨子である、不確実性を恐れる人間の本能を乗り越えて、それらに向き合える組織を作ることによって生産的なチームができる。 そして、ソフトウェアを作るとは、「認識に齟齬がないほど明晰な言語に書き下すこと」であれば、これは情報の非対称性を減らすというコミュニケーションそのものだろう。 このコミュニケーションのコスト構造をそのまま、システムの構造に当て込んでしまうというのを「コンウェイの法則」と呼ばれている。 組織構造の問題が、システムへと転移して、コントローラビリティを喪失すること。これが技術的負債の真実であるなら、これはありふれた経済現象であ
やっていく技術テーマを探す - はこべにっき ♨
Webエンジニアを8年くらいやっていて、なんとなく、一通りのことはできるようになってきた。ただ、ちょっと得意な分野もあるとはいえ、基本的になんでも屋さんとしてやっているので、技術者としてのアピールがいまいちだなーというのが気になっている。そこで、技術者としての自分をアピールできそうな技術テーマを一つ選んで、それにじっくり取り組んで見ようと考えた。 しかし、取り組む技術テーマをうまく選ぶ自信がない。そこで、ちょっと作戦を考えて取り組む技術テーマを見つけようと試行錯誤してみたので紹介してみる。 ステップ1: 指標を考える やっていく技術テーマを見つけるにあたって、テーマの候補をスコアリングしてみることにした。漠然とスコアをつけるのは難しいので、自分が普段技術テーマに取り組むかどうかを考えるときに気にしていることを思い出して、5つの指標に分解してみた。 指標1: 自分の興味 自分がおもしろい、や
開発の“無理ゲー進行”はこう回避せよ！ 若手エンジニアが締め切りを健全に守るためのストラテジー - エンジニアHub｜Webエンジニアのキャリアを考える！
エンジニアHub > 記事一覧 > 開発の“無理ゲー進行”はこう回避せよ！ 若手エンジニアが締め切りを健全に守るためのストラテジー エンジニアにとっての永遠のテーマ、「締め切りはどうしたら守れるか」。上司に言われるままにタイトなスケジュールを押し付けられた経験があるエンジニアは少なくないはずです。 「無理ゲー進行」を生み出す要因はいくつもあります。「完全版をリリースしなけばいけない」という固定観念や、期日だけを厳密に管理して現場へプレッシャーをかけるプロジェクト進行、無理なプロジェクト進行を経営課題と認識せず、現場の「頑張り」に甘えて放置している経営者（意志決定者）など。顧客（クライアント）や上司から押し付けられる「無理ゲー進行」に、工数見積もりに慣れていない若手エンジニアはどう対処していけば良いのだろうか――。 無理ゲー進行の原因をひも解いていくのは、かつて株式会社ミクシィにて最年少で執
若手エンジニアを不幸にしないための開発の「べからず」集 コーディング編 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集が 長くなりすぎたので、コーディングに関する部分を別項目として独立させました。 「若手エンジニアを不幸にしないための開発の「べからず」集」を書くことを思いつくきっかけとなった記事 若手エンジニアを不幸にしないためのC++コーディングべからず集 も参考にしていただければ幸いです。 コーディングの「べからず」 何を実装すべきなのかについての詳細を確認しない。 アジャイルな開発をしている場合には、すぐさま開発することがあるので、時として何を実装すべきなのかの詳細を確認しないままになってしまうことがあります。 実装のコーディングの前に、個別の関数への仕様が十分に明らかになっているかを確認しない。 ヘッダファイルに記述されたドキュメンテーションコメントをも誰でもが曖昧さなしに解釈できる内容になっているかをチェックしない。 実装すべき内容は、どのよ
若手エンジニアを不幸にしないための開発の「べからず」集 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の）若手は、将来も働き続けるための力を付けるための組織内での教育が、（昔ほど）なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業前提の仕事のスケジュールを組織がたてることが多い。（その分野の理論を知っていれば自明のことを実験で証明することを要求されるのは苦痛である。） 設計指針の「べからず」 何ができれば十分かを明確にしない 開発目標は、何ができれば十分なのかを明確にしないまま、追加
短期間で新技術を学ぶ技術
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase
お題「エンジニア立ち居振舞い」 技術的な暴力を振るわない 何事も初めて、ということがあるだろう。 プログラミングが好きで、かつ業務経験もあり、 いろいろなサービスに手を出している人ですら、初めてやったこと、というのがあるはずだ。 ECサイトをつくるため、CGIの処理、ブラウザからの快適な買い物を実現するために独学した小売店経営の個人事業主。 iOS上でのアプリ開発が解禁されて、初めてiOSアプリを開発するようになったWindows向けアプリケーション開発者。 Go言語が発表され、初めてGo言語でサーバサイド側のアプリを書いたフロントエンドエンジニア。 AWSのLambdaアーキテクチャ == Serverlessという問題の解決、分散の仕組みに心を惹かれHTTPS経由のファイルアップロードの処理をLambdaに寄せたIoTサービスを始めようとしている組込系エンジニア。 Nintendo S
時代はもくもく会だと思う。エンジニア向けイベントの区分と人種について。 - clock-up-blog
各々が各々の時代を持てば良いと思う。 少なくとも今の僕にとって時代はもくもく会だ。 まず会社以外でプログラミングに触れないってのは無しだと思う。勉強しよ？ セミナーに参加するのは良いと思う。自社のエンジニアしか知らない状況は世界が狭すぎて危うい。そんな人間の未来は茹でゆでガエルだよ。（※1） セミナー後の懇親会に参加するのも良い。生身のエンジニアと双方向な対話をしよう。 勉強会という曖昧な名前のイベントも良い。が、その様態は多種多様なので各々自分の目で確かめる必要あり。 ハンズオンなんかは情報を聞くだけじゃなくて実際に参加者全員が手を動かして作業するイベント。確実な糧になる。すごく良い。（※1） ハッカソンというやつも良い。集まった人間の間でその場でチームを組み、時間内に何かを作る。成果物ができる。 もくもく会、良い。集まった人間が各々に各々の好きな作業をする。すごく良い。僕の中ではこれが
インフラを意識してコードを書くということ - Hatena Developer Blog
チーフエンジニアの id:Songmu です。 4月に 新人エンジニア研修を行なった のですが、その際に、「インフラを意識したアプリケーションの書き方」という講義を担当しました。そこでおこなった講義の内容について整理しながら書き起こしていきたいと思います。 インフラを意識すると何が良いか 業務でWebアプリケーションを扱うと、個人ではなかなか扱えないトラフィックであったりデータ量を扱うことになります。小規模サービスでは考えなくてよかった多くのことを考慮する必要がでてきます。なかなか体験できないことでもあるので、楽しく、やりがいもあります。 また、そういった経験を通して、インフラを意識しコードをかけるスキルを身につけることは、Webエンジニアとしては大きな強みとなります。ISUCONで優勝できるかもしれません*1。 インフラを意識すると何が良いか 〜 中規模ベンチャーの場合 そもそも、はてな
ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊社特有の部分は一部省いています。） ああ、なんという長い旅だったろう。この会社で５年間もセキュリティを担当していたよ（諸々の失敗は許してくれ） 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
