設計とは、 要求（やりたいこと）をヒアリングする 要求を要件（何を満たさないといけないのか）に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する） 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案（いわゆる比較表で書いていくのが楽） 検証結果 選定・合意結果（合意した代替策や妥協ラインについても記載する） 詳細設計（どういう実装にするとか、パラメーターにするとか、細

日本語話者も英語話者も歩みよる、インクルーシブなコミュニケーション実現のためのメルカリ独自の言語支援施策 「新たな価値を生みだす世界的なマーケットプレイスを創る」というミッション達成のため、メルカリでは、世界中から集まる多様なメンバーが活躍できる組織を目指しています。 現在、メルカリのエンジニア組織の約4割が「海外から来たメンバー」。特にプロダクト開発におけるコミュニケーションでは、英語が必須です。そのため、英語習得が求められる日本人メンバーは、LET（Language Education Team）が提供する「言語学習プログラム」に日々取り組んでいます。 しかし、この学習プログラムの本質は、メルカリで働く全員が英語を流暢に話せるようになることだけではなく、国籍や言語に関わらず、全員が円滑にコミュニケーションを図ることができるようになること。今回は、社内向けに英語学習、日本語学習、そして「

Sports Analyst Meetupは、現役スポーツアナリストとスポーツ分析に興味のある方の情報共有イベント。ここでは認知科学研究者のなういず氏が、時間割引の視点からどうしてバントは減らないのか、心理学的アプローチから解説しました。 どうして送りバントは減らないのか？ なういず氏（以下、なういず）：『どうして送りバントをやめられないのか』というタイトルで発表いたします。なういずと申します。よろしくお願いします。 初めましての方もいると思いますので、最初に簡単に自己紹介させてください。私、なういずというハンドルネームで活動しています。Twitterは@nowism_sportsでやっていますのでフォローしてもらえると嬉しいです。サッカーは柏レイソルを、野球は巨人を応援しています。 普段は東京大学の大学院で認知科学を研究しています。研究の中では人間の非合理的な意思決定というものに興味があ

安倍晋三首相が半分夏休みモードに入っている。27、28両日は午後から官邸で執務し、28日の定例閣議も見送った。ただ東京都を中心に全国で新型コロナウイルス感染が再拡大。山梨県の別荘で静養し、ゴルフを楽しむといった恒例の夏休みの過ごし方ができるかどうかは見通せない。 首相は27、28両日の午前、東京都内の私邸で過ごし、午後に官邸へ「出勤」。28日午後は新型コロナや大雨被害に関する会議に出席し、外務省幹部らとも面会した。 首相は当初、23日からの4連休を利用し29日まで1回目の夏休み取得を検討。山梨県鳴沢村の別荘での静養も考えたが、取りやめた。

これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの

以前社内に書いたポエムなんだけど年に1回くらい引用したくなるので公開した tl;dr; 質問をする時はゴールを提示する【MUST】 理由1 理由2 コンテキストを詳しく共有する【SHOULD】 期待してた結果(expect)と実際の結果(actual)を書く【IMO】 2020/7/22 12:30追記 2020/7/22 19:00追記 tl;dr; テンプレ 【質問内容】 【やりたいこと or 今困ってること or 質問の意図】 質問をする時はゴールを提示する【MUST】 なにかやりたい けど実現できない、うまくいかない それで質問する って感じに、質問をする動機としてまず やりたいことありき のはずなので、それを提示すべきです 理由1 質問される側（以下回答者）は質問内容がふわっとしていると色々なケースを想定して回答を組み立てます *1 例「Aの場合は～だけど、Bの場合は～」 こうい

「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ

とある休日 娘（5歳）「パパ、一緒に技術ブログを始めない？」 娘「昔から私とパパがローカルに書き溜めてる技術記事が、かなり溜まってきたでしょ？」 娘「それをブログとして公開してみようよ」 ワイ「おお、それは楽しそうやな」 ワイ「どこのブログサービスを使おうかいな」 娘「せっかくなら、ブログシステムから自分たちで作ってみようよ」 娘「私はフロントエンドを担当するから」 娘「パパはRuby on Railsか何かで、APIを作ってよ」 ワイ「おお、Ruby on Railsなら昔やったことあるわ」 ワイ「RailsのAPIモードで、ブログ記事を返すエンドポイントを作ればええんやな」 娘「そうそう」 次の日 ワイ「API、できたで！」 ワイ「/api/articlesっていうエンドポイントにアクセスしてくれたら」 ワイ「ブログ記事が取得できるようにしておいたわ」 娘「さすがパパ」 娘「そういえば

どうも上司に嫌われているようだ。 無視される、自分の書類だけ無言で返される、関係者のはずなのに会議や決定事項の伝達が来ない。 まぁ何とか仕事をしているのだが、段々と体が悲鳴を上げてきた。 会社に行こうとすると胸が締め付けりるように痛む 極端に朝早く目が覚める 家による一人でいると突然声をあげて泣いてしまう 飯がおいしくないが満腹以上食べて吐いてしまう 家事が面倒 大好きだった趣味のスポーツをやりたいと思えない 友達や彼女に会うのが億劫 メンタル病んでいるのは分かるけれど、仕事しないと食っていけないし、このコロナで転職も難しいと思うので今日も仕事に行く。 自分は世間的に見ても明るくてスポーツ好きなタイプだったと思うので、周りに心配をかけないよう、 最低限の身だしなみを整え、今日もその仮面をかぶって仕事に行く。 世の中にはもっと辛い人がいると思うので、甘えんなよ、って言われるかもしれないけど、

いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・　良い仕様書がもたらす 5 つの効果 ・　仕様書の重要性が増していく 2 つの理由 ・　仕様書に含めたい 14 の項目・実戦編 ・　仕様書作成時に心に留めたい 3 つのこと ・　具体的な仕様書サンプル（

Almanacウェブサイト プログラミングをせずとも、ウェブもしくはモバイルアプリを直感的に構築できるノーコードサービス分野が成長してきました。「Bubble」や「AppGyver」のようなアプリ開発、日本の「STUDIO」や「Strikingly」に代表されるLP開発など、領域は様々です。ノーコードの本質は、時間やコストを圧倒的に削減することにあります。そして今、ノーコードトレンドの考えが新たな体験として企業で広く使われるドキュメント作成分野にも広がりつつあります。 「Almanac」は、ビジネスドキュメントテンプレートのクラウドライブラリを提供。マーケティング、人事、法務テンプレートなど、専門家によって公開された、磨き上げられた1万件の文書を提供しています。各資料をコピペすれば、ユーザーは手軽にプロのドキュメント内容をトレースできます。UIはノートツール「Notion」にとても似ていま

前職から転職して１ヶ月がすぎたので、現時点での個人の感想を記しておく。 以下に該当するような人にはひょっとしたら役立つかもしれない。 ３０代だけどプログラマーに転職したい。 自社開発企業に転職したい。 プログラミングスクールに通うべきか迷っている。 未経験から転職してついていけるか不安。 前職は何をしていたか 前提として、前職のことについて簡単に書いておく。 前職は中学の教員だった。 専任教員だったので、担任も持っていたし、生徒指導もしていたし、部活動も担当していた。 そう書くとブラックなイメージがあるかもしれないが、私立進学校だったのでそれほどハードでもなかった。 生徒は荒れているどころかおとなしすぎるくらいだし、部活も１８時までには終わっていた。 朝は８時からなので早いが、それでも頑張れば９時間労働で帰ることもできた。*1 夏休みは１ヶ月以上あったし（ただし部活動や夏季講習で３分の２は

タイトル通りですが、1年目エンジニアのインフラのイの字も知らなかった私が1ヶ月半かけてKubernetesで環境構築するまでの失敗の軌跡です（そして環境構築できたのが奇跡）。 理想的にはこれを読めばインフラ初心者でもKubernetes（以下k8s）で環境構築できるところまで説明することですが、そういうわけでなく、環境構築の解説というより自分の失敗やつまづきポイント、役に立ったことをただただ書き連ねていきます。ただ他の初心者の方も同じようなところでつまづくこともあると思うので少しでもお役に立てたら嬉しいです。 バックエンド側で使った技術は以下になっています。 言語：Ruby（RoR） API：GraphQL インフラ：Azure その他：Docker、k8s 実際の実装でハマったところは各章の最後に教訓として簡単にまとめてはいますが、大事なことは先に結論として述べておきます。 Docker

補聴器使ってる当事者より。 アラサー、先天性難聴からの左耳失聴、右耳の残存聴力＋補聴器で音を聞き取っている。 確かに補聴器は万能ではない。多くの人が想像できるように、ノイズも増幅する。たとえていうなら、裸耳での音がFMなら、補聴器越しの音はAMというか。 お店でつけた最初の瞬間は、人の声、店内のざわざわ音、空気の音、どこかで机に何かを置くカチャカチャ、ゴトッという音、ぜんぶ同じ強さで耳に入って来る感じになる。人間の耳は、自然に聞こえたい音と聞こえなくてもいい音をよりわけ、調整しているんだと痛感した。しばらく我慢してつけ続けると、だんだん耳というか脳がその状態に慣れて、補聴器からの音でも取捨選択をできるようになるんだけど。最初は辛い。特に補聴器初めての人は。言われるがままにボリューム大きくすると、ハウリングが起きて頭痛がしたり、耳に入る音の種類が多すぎてすごくイライラしたりする。 特に耳が遠

はてなに書いたところで該当者に届かない気がするけど、見かけた人が数十年後に思い出してくれればいいや。それか家族に該当者がいれば。 補聴器は聞こえにくいなって思ったり、まわりに指摘されたらすぐ使ってくれ。せめて補聴器屋か耳鼻科に相談に行ってくれ。すぐ買わんでもいいから。 俺は補聴器を売っている。仕事は楽しい。楽しいんだが、耳そのものじゃないので、限度はある。 特に聞こえなくなってから相当経ってから補聴器つけた人。歩かなきゃ歩けなくなるのと同じで、ずっと聞いてなきゃ聞こえなくなる。音は補聴器で増幅できるが、言葉の聞き取り能力がダメ。ダメです。聞き取り能力が落ちたら取り戻せないと思っていい。聞き取り能力と、聴力は、別物です。音は聞こえても理解度が下がってる。自分でも気づかないうちに、言葉として聞き取れない脳になっちゃうのだ。 「高いもの買ったのに」って気持ちは分かるわ。自分だって何十万も出して思

「COBOLシステムの全面刷新は断念しました」――。大手企業A社のシステム部長はこう言って肩を落とす。25年以上使ってきた顧客管理システムをCOBOLからJavaへと書き換え、プラットフォームを一新する計画だった。ところが想定以上にプログラムが存在していたうえに、その中身を知るメンバーはいなかった。ドキュメントもほとんどなく、発注先である開発会社が「白旗」を挙げてしまったという。 6割を超える企業に「COBOL」が存在 日経クロステックの調査によると、国内にはレガシーシステムがいまだ数多く存在している。ユーザー企業は社内に、ITベンダーは担当企業にCOBOLを使った情報システムがあるかどうかを聞いたところ、実に6割を超える回答者が「ある」と答えた。さらにこのうち4分の3を超える企業では、具体的なリプレース計画も無い状況だ。 レガシーシステムの放置はDX（デジタルトランスフォーメーション）を

こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。 弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。 テレワーク環境で私たちのエンジニア部門で急務と感じた課題テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート？全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様

ここ数年、SFA（営業支援システム）や会計ソフト、BI（ビジネス・インテリジェンス）ツールが浸透したことで、経営情報の多くはデータベース化されている。しかし、未だにデータベース化が進まず、アナログな運用が続いている領域もある。 それが予算策定、予実管理、見込管理などに代表される経営管理だ。経営管理業務は関係者が多く、多段階、多部署、多拠点との数値のやり取りが必要なため、Excelなどの表計算ソフトにデータを転記・加工しているケースが大半となっていた。 実際、5段階の組織でExcelを使って数値提出・承認を行ったり、全国2000箇所の拠点からExcelで数値を集めたりしている会社もある、という。 そんな非効率・属人化しがちな経営管理業務にGit（分散バージョン管理システム）およびGitHubワークフローの仕組みを応用し、データベース化を推進するサービスが登場した。7月8日、ログラスは次世代型