残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。 IT技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載「プロジェクト成功確率向上の近道とは？」では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。 連載1回の「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」、第2回の「サンプル例に見る
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
Vue.js＋Vuex＋TypeScriptのWebフロントエンド開発現場を前向きに改善した話 - ZOZO TECH BLOG
こんにちは。Webフロントエンドエンジニアの松井菜穂子です。 ZOZOテクノロジーズに入社して一年ほど経ちます。 あるサービスの立ち上げから運用まで、Webフロントエンドのチームリーダー・開発メンバーとして関わってきました。 当記事では、当社のWebフロントエンド開発現場にあった問題と、それぞれの課題に対して堅実に積み重ねた技術的な改善方法についてご紹介します。 はじめに モダンな技術でも負債は生まれる 負債を何故改善するのか 要因 その1: Vueコンポーネントを綺麗に分割する テンプレート コンポーネントクラス 使用例 解決策 テンプレート コンポーネントクラス 使用例テンプレート 使用例コンポーネントクラス コンポーネントカタログで汎用化を促す コード テンプレート（atoms.vue） コンポーネントクラス（atoms.vue） サンプル その2: Vuexをシンプルにする Sta
コードネームの決め方 - にょきにょきブログ
プログラマの仕事のうち、名前付けという作業は大きな割合を占めるのではないでしょうか。 頻繁に名前付けを行いますし、かつ、センスが求められる部分でもあります。 今回は変数名やメソッド名ではなく、プロダクト名につけるコードネームについて。今までの経験上、コードネームの付け方についてある程度知見が貯まり、パターンが見えてきました。ここでその知見を記録したいと思います。 コードネームの決め方に慣習があればそれに従え！ 例えば植物の名前とか、島の名前、山の名前、物語のキャラクターの名前、といったような慣習があれば割と楽に決められることでしょう。逆に、無ければ何か慣習を作っておくと便利です。 例えば島の名前で決める、という慣習を決めたとすると、結構良い名前がざくざく出てきます。Lesbos, Malta, Aruba, Vaila, などなど。 イニシャリズム方式は愛着が湧かないぞ！ コードネームをイ
個人開発のすゝめ - Qiita
はじめに 普段から個人開発について考えていることを書き出してみました。 私自身はこの記事の初版を書いた2年ほど前にのぞきみというアプリをリリースし 有り難いことに現在30万ほどダウンロードしていただいています。 2019年末についに50万DLの大台に乗りました、嬉しい🎉 （2020/01/09追記） 2021年12月時点で82万を超え、佐賀県の人口を上回りました🎉 （2021/12/02追記） 2023年6月、ついに大台の100万ダウンロードを達成しました💯 （2023/06/09追記） 想定読者としては「アプリ開発初中級者で個人開発未経験、なかなか一歩目を踏み出せなかった二年半前の自分」に宛てて書いています。 私はAndroidエンジニアですが、コードについては全く触れませんのでiOSでも共通する部分が多いと思っています、Webはよく分かりませんごめんなさい。 長いので要約すると
米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - ログミーTech
2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。2日目のKeynote「敢えて属人化せよ！ エキスパートの集団こそが最強のチーム」に登壇したのは、Microsoft本社で活躍するエンジニア、河野通宗氏。日本からアメリカへと移った中で感じたカルチャーショックと、その開発環境について語ります。 マイクロソフト本社で働くエンジニア 河野通宗氏（以下、河野）：Microsoftの河野と申します。ふだんはシアトルでAzureサービスを作っているんですけど、今回は川口さんにご縁があってお呼び
コードを美しく保つためのたった一つの方法 - ボクココ
ども、@kimihom です。 とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。 結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。 サービス設計レベルでの"美しさ" を極めよう いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。 その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が１冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われて
個人開発のモチベーションが続かない、作り終わらない。原因と対策を考えてみた。 - フロントエンドの地獄
運営者ギルドという、個人や少人数チームでWebサービスやアプリを作っている人のSlackチームがありまして、そこで furuta さんやnaichi さんとチャットしていて、個人サービスを作っていて「モチベーションが続かない」「いつの間にか辛くなってくる」という個人開発あるあるについて話していました。 個人開発は「自分の作りたいもの」を「自分の使いたい技術」で「自分の好き」に作れる最高の舞台です。クリエイターならやらない手はないでしょう。 しかし、何も考えずにいざ足を踏み入れてみると、思ったよりも険しい道だと気づくのです。 仕事でもなく「自分が作りたくて作っていた」はずなのに、いつの間にかどこかに逃げ出してしまうモチベーション。何ヶ月経っても作り終わらない現代のサグラダ・ファミリア。仕事がバタついて1週間面倒見ていなかっただけで「え、なにこのクソコード」と毒づいてしまうほど荒れ果てたmas
クレジットカードを使わないでlinebotを作ったときの話 - Qiita
7日目担当の @esu_eichi です。 6日目は @tsubasaogawa さんの「pushd と dirs を peco でちょっと便利に使う」でした 書く内容 このページにはタイトル通り、クレジットカードはないけどlinebotが作りたい、という数少ないであろう人々向けに クレジットカードなしで登録/利用できたサービスなどをまとめておきます。 書かない内容 linebotの作り方やapiのtips、ハマリポイントなどは書きません。 クレジットカード登録なしで使った技術の話をまとめておくだけです。 経緯 先日学生向けインターンシップを担当しました。 学生でもとっつきやすい課題ということでLine Messaging Apiとlaravelで 簡単なリマインダを作るというハンズオンを行いました。 今回はその準備のときの話です。 課題 学生向けということで、無料かつクレジットカードが無
RaspberryPi の産業用途 - Qiita
RaspberryPi を産業用途に使う可能性に関するメモ 注意：本記事は、RaspberryPI の産業用途を推奨するものでも、限界について述べるものでもありません。単なるメモにすぎません。 追記：キュウリの仕分けについてはInterface 2017年3月号に詳細な記事があります。 RaspberryPi には 次のように思うことが多いだろう。 ・電源スイッチはなぜないの？ ・電源の安定性は大丈夫？ ・連続運転したときの放熱は大丈夫？ それらの問いに対するアプローチが次のものだ。 bizright Raspberry Piを堅牢化したIoTゲートウェイ Raspberry Pi 3搭載の「BH3」を発売 なぜ「ラズパイ」が産業機器向けに伸びているのか 製造元は意図していなかったものの、2016年に約200万台が産業用途向けとして出荷されたシングルボードコンピュータがあります。この製品
SUUMOアプリチームがスプリントを廃止してカンバン方式に移行した話 | リクルートテクノロジーズ メンバーズブログ
このエントリは全9回を予定する18卒新人ブログリレーの第4回です！ 今回は、SUUMOのモバイルアプリ開発の現場から、企画と開発が一体となったチームでの開発プロセスについてご紹介します！ はじめに はじめまして。リクルートテクノロジーズ新人の三田涼介です。現在は不動産検索サービスSUUMOのAndroidエンジニアとして働いています。 今回はSUUMOアプリチームの開発プロセスについて紹介します。 SUUMOは巨大なサービスでありながら日々高速に改善を行っており、週1回以上の頻度でiOS、Androidの各OSでリリースを行っています。このスピード感を実現するために、開発プロセス自体も日々磨き込みが行われており、私が配属された3ヶ月前にも開発プロセスに大きな変化がありました。 この記事では、私が新人としてキャッチアップしていく中で学んだ、 なぜ開発プロセスを選ぶことが必要なのか どうやって
cookpad storeTV の広告配信を支えるリアルタイムログ集計基盤 - クックパッド開発者ブログ
こんにちは。メディアプロダクト開発部の我妻謙樹（id:kenju）です。 サーバーサイドエンジニアとして、広告配信システムの開発・運用を担当しています。 今回は、cookpad storeTV （以下略：storeTV ）の広告商品における、リアルタイムログ集計基盤の紹介をします。 storeTV における広告開発 storeTV とは？ storeTV は、スーパーで料理動画を流すサービスで、店頭に独自の Android 端末を設置し、その売り場に適したレシピ動画を再生するサービスです。 より詳しいサービス概要にについては、弊社メンバーの Cookpad TechConf 2018 における以下の発表スライドを御覧ください。 storeTV における広告商品の概要 storeTV では、imp 保証型の広告商品を提供予定です。imp 保証型の広告商品とは、例えば「週に N 回広告を表示す
Microsoft、手書きのUIスケッチをHTMLに変換する「Sketch2Code」を発表
Microsoft、手書きのUIスケッチをHTMLに変換する「Sketch2Code」を発表：AIで手書きの図形と文字を認識 Microsoftは、手書きでスケッチしたUI画面をHTMLコードに自動変換するWebベースソリューション「Sketch2Code」を発表した。 Microsoftは2018年8月30日（米国時間）、ホワイトボードなどに手書きでスケッチしたユーザーインタフェース（UI）画面を、AI（人工知能）を利用して、HTMLコードに変換するWebベースソリューション「Sketch2Code」を発表した。 Microsoftによれば、UIのデザインプロセスには無駄が多いという。通常は、まずアイデアレベルのスケッチをホワイトボードに描き、数人で検討してから写真に撮影し、HTMLコードを書き下す。これでは手間ばかりかかり、すぐにアイデアを形にできない。 画像認識技術とAIを組み合わせ
ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita
ソフトウェア開発の様々な局面で役に立つ、心理学的現象や行動経済学についての知識です。 経験則で把握済の事柄もあるかもしれませんが、 言語化して名前を与えることで何かのときにスッと出せたり、周囲の方々と議論しやすくなったりすると思います。 以下の3つの分類で記載いたします。 打ち合わせやチームワークに役立つ知識 設計やプログラミングに役立つ知識 メンタルヘルスケアに役立つ知識 打ち合わせやチームワークに役立つ知識 自己効力感 自己効力感とは、自分には何かを達成する能力がある、と信じる感覚です。 自己効力感が形成されていると、仕事の意欲が増したり、効率が上がったりします。 「この仕事は絶対ムリ～(>_<)！」と感じている仕事についてやる気がわかなかったり進捗が出なかったりするのは、自己効力感の欠如が原因であることがあります。一旦やる気を出すと案外簡単に進められたとか、真剣に取り組むと思ったより
システム技術者が「ちょっと変えるだけでしょ？」という、ユーザーからの注文に辟易する理由。
どうも、 「単純な要件でも、システムの作りによって大きく難易度が変わる」 「システムは決して規格品ではなく、作る人によって全く出来が異なる」 ということが直感的に理解しにくいところが、色んな問題の根本原因の一つなんじゃないかなあ、という気が最近しています。 しんざきは、システム開発関連の仕事をしています。元々の専門分野はDB屋なんですが、まあ他にも色々やります。 で、当然のことながらユーザーと色々やりとりをして、仕様を固めて設計して開発して、みたいなことも何度もやっているのですが、その際何度も何度も聞いた言葉の一つに、 「ちょっと変えるだけでしょ？」 という言葉があるんです。 恐らく、システム開発に携わったことのある人であれば、何度となく聞いた言葉ではないでしょうか。 この「ちょっと変えるだけでしょ？」という言葉は一種の呪いの言葉、パワーワード・キルのようなものでして、ユーザー側と開発側の
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
【SIer新人向け】研修では教えてくれないノウハウ集 - Qiita
「ようこそ 魔境 SIerへ！」 はじめに この記事は、SIer（Systems Integrator）に入ったシステム開発未経験者の新人さんたちへ送る、研修では教えてくれないノウハウ集です。 実際、弊社の長い研修では実務に使えそうなことをあまり教えてくれませんし、ノウハウは現場の人の頭にしかない状態なので、新人さんは暗中模索で仕事を覚えていくことになります。 それも非効率なので、実際に私が２年半1で失敗したこと、やってきてよかったこと（ノウハウ）を体系化したので共有します。 新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。 （本当はガッツリ社内向けに書いたものなので、一部汎用的でない表現がありますがご了承ください。） 目次 業務面 技術面 プライベート面 の三本柱でお送りします。 対象読者 SIerの1,2年目相当であり、学生時代に契約のあるシステム開発を
アプリ開発者とインフラ技術者間のSRE的なコミュニケーション改善に役立つインフラ基盤とは
アプリ開発者とインフラ技術者間のSRE的なコミュニケーション改善に役立つインフラ基盤とは：SREの考え方で“運用”を変えるインフラ基盤 大解剖（3）（1/3 ページ） 本連載では、「インフラの、特に基盤寄りの立場からSRE（Site Reliability Engineering）の活動を行い、Webサービスの価値を高めるためにはどうしたらいいか」について、リクルートの新たなインフラ基盤を例に見ていきます。今回は、インフラ基盤の技術的解説とともに、出始めている成果、今後の展望についてお話しします。 本連載「SREの考え方で“運用”を変えるインフラ基盤 大解剖」では、「インフラの、特に基盤寄りの立場からSRE（Site Reliability Engineering）の活動を行い、Webサービスの価値を高めるためにはどうしたらいいか」に悩んでいる方々に向けて、リクルートの新たなインフラ基盤で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
それはYAGNIか? それとも思考停止か?
direnvを使おう - Qiita
