日本でデジタル母子手帳を運用するとしたら？ - eaglesakuraの技術ブログ
この記事はなに？ ちょっとした頭の体操である つらつら思ったことを書くだけ デジタル母子手帳 そのまま、いま子育て世代が（基本的に全員受け取っているハズの）母子手帳をスマホで見たり管理したりできるようになる 検索すると、色々ニュースやプレスリリースが出てる 個人的な見解 本当に必要な状態を満たして、普及すればとても良いことだと思う しかし ここは2019年の日本 あの マイナンバー を作り出した国やぞ 最低限必要な要件を考える 現状 公的・民間問わず、複数の母子手帳サービスがリリースされている www.mchh.jp www.boshi-techo.com 各種記録機能 予防接種などの記録を保持する 必要な記録（１語、２語の発話時期とか）を書き込める その時の状況、単語内容などのメタデータ（コメントデータ）を書き込める アクセス権限の付与 母子手帳は、「母」「子」だけが使うものではない 必
14年かかった！個人開発で月収100万達成した話｜SiRO
こんにちは！専業で個人開発しているSiROです。 苦節14年、個人開発で月収100万円を達成したことですし、一度ここまでの知見をまとめ、共有したいと思います。同じ道を志す方の参考になれば幸いです。 想定読者：個人でWEBサービスを作って稼ぎたい人 実際の月間PVと月収 ↑これは全サービスをサマリーした数字です。収入源は広告収入。 PVは最高記録で450万PV/月くらい。月収の軸ラベルは隠してありますが、ピーク時に100万円オーバーです。月収とPVの関係をまとめると・・・ 月収10万円達成 29万PV 月収20万円達成 48万PV 月収30万円達成 70万PV 月収40万円達成 267万PV 月収50万円達成 282万PV 月収60万円達成 339万PV 月収70万円達成 440万PV 月収80万円達成 444万PV 月収100万円達成 422万PV ※PV数は参考程度です、特にツール系は何
設計のための、問題の捉え方––ドメイン知識の暗黙知を形式知にする Part1
2018年11月8日、Classi株式会社が主催するイベント「設計Night2018」が開催されました。Builderscon tokyo 2018にて好評を博したプレゼンテーション「開発現場で役立たせるための設計原則とパターン」をもとに、発表だけではカバーできなかった3つの論点について、3名の登壇者がより詳しく深掘りします。プレゼンテーション「ドメイン知識の暗黙知を形式知にするためには」に登壇したのは、magnolia_k_氏。講演資料はこちら 設計のための問題の捉え方 magnolia_k_氏：実は今日で「設計Night」に出たの2回目なんですね。1回目は、今年の3月ぐらいに吉祥寺の居酒屋で、しんぺいさんのブログを見せながらみんなで酒を飲む「酔いどれ設計Night」という会をやって。7人ぐらいですごい楽しかったんですけど、今日は僕としんぺいさん以外、全員抽選に外れるという（笑）。 （会
よいコミットメッセージを書くために心がけていること - くりにっき
よいコミットメッセージとはどういうものだろう？ - chiastolite’s blog に対するアンサーソングです chiastolite.hatenablog.com 必要であればWhyを補足するためのContextを書く 元エントリだとコミットメッセージの話だったけど僕はPRで実践してもいいと思います。*1 起点となるURLを明記する レビューで指摘されたのであればPRのコメントのURL issueのURL アプリケーションエラーであればSentryなどのエラートラッキングシステムのURL GitHub外のタスク管理ツール（例：redmineやBacklogやTrelloなど）に修正概要が書かれているのであればそのURL チャットのやり取りが起因ならSlackなどのパーマリンク 公式ドキュメントのURL CIがコケているのであればCIのビルドのURL チーム開発していればコミットやP
提案を通せない人が押さえるべきビジネスパーソンの思考パターン3つ | BtoCマーケティング支援のホジョセン
ホジョセンは、よくセグメンテーションのお仕事をさせていただきます。消費者・生活者をいくつかのパターンに単純化することで、クライアントさんの戦略や行動の指針とするものです。マーケティングではSTP戦略のSにあたる部分ですので、ご存知のかたも多いと思います。 これを同僚に当てはめてしまえ、というのが今回のコラムになります。社内で自分の提案を通すためにはどのようなアプローチを取るのが効率的なのか、プロジェクトマネジメントを円滑に進める上でどうコミュニケーションをとっていけばよいか、と考えた上で編み出した単純モデルです。 いろんな方といっしょに働く中で多少のアップデートはしましたが、基本的には10年以上使っているパターンです。僕の(元)同僚の皆様は何度も聞いた話だと思いますが、ご了承ください。また、このモデルに落ち着くまでにさまざまな方からのフィードバックをいただきました。諸先輩方、元同僚の皆様に
様々なTODOアプリやタスク管理方法を試行した結果最終的にプレーンテキストに行き着いた話 - みんからきりまで
TODOアプリという永遠のテーマ このブログでは過去に何度かタスク管理についてエントリを書いてきました。 kirimin.hatenablog.com kirimin.hatenablog.com kirimin.hatenablog.com タスク管理のためのいわゆるTODOアプリについては色々なものを試してきて、KanbanFlow→Habitica→GitHub→Todoistと移り変わっていった。 でもやっぱりメモ帳を使ってしまう問題 このように最高のタスク管理をしようとポモドーロ機能やリマインド機能、優先度設定やタグ付け、定期タスク登録など様々な機能を持ったタスク管理アプリを使ってきたが、いつも気がつくとWindows標準のメモ帳かVScodeでプレーンテキストに書きなぐってしまう。 しかもそれが一番しっくりくるのだ。 多分理由はいろいろあって、たとえば 一瞬で開ける いらなくな
サービス開発でぶつかってきた壁と、そのとき助けてくれた本 - クックパッド開発者ブログ
こんにちは、開発ディレクターの五味です。クックパッドにレシピを投稿してくれるユーザーのための機能やサービスを開発する「投稿開発部」に在籍しております。 投稿開発部は、2018年1月に前身となる部からメンバーを一新して発足した部署です。自分たちで1から戦略を作るため、強い実感を持ってユーザーを理解することを信条に、資料を読んだり前任者に聞いたりするだけではなく、実際にユーザーとたくさん話し、たくさんレシピを投稿し、ユーザーのことをたくさん考えてきました。 この記事では、その中でぶつかった課題を解決するために取り入れた書籍や、それをうまく業務に取り入れるために行っている工夫を紹介します。 サービス開発にはさまざまな壁が現れる ユーザーと事業目標に真摯に向き合うほど、サービス開発にはたくさんの壁が現れます。私たちも例外ではなく、部の発足以降、以下のような壁に激突してきました。 「ユーザー課題の見
コモンズの悲劇 - Wikipedia
タイ東北地方のコモンズ。牛飼いは、脇道に生えている草を牛に食ませる。ローカル・コモンズを利用し管理する現地住民は、草の根民活として評価できる。 コモンズの悲劇（コモンズのひげき、英: tragedy of the commons）とは、多数者が利用できる共有資源が乱獲されることによって資源の枯渇を招いてしまうという経済学における法則。共有地の悲劇ともいう。 アメリカの生物学者、ギャレット・ハーディンが1968年に『サイエンス』に論文「The Tragedy of the Commons」を発表したことで一般に広く認知されるようになったが、発表後多くの研究者も反論を唱えた。 概要[編集] たとえば、共有地（コモンズ）である牧草地に複数の農民が牛を放牧する場合を考える。農民は利益の最大化を求めてより多くの牛を放牧する。自身の所有地であれば、牛が牧草を食べ尽くさないように数を調整するが、共有地で
「上下関係にこだわる人を、絶対に入れたくない」という会社の話。
先週のしんざきさんの記事 「「職位が高い人間ほど、技術的な実務から遠ざかってしまう」のを解消しようとして、失敗した時の話。」 を読んで、思い出した話があったので、書いてみたい。 この話のキモは、なんと言っても次の部分である。 細かい不満は色々とあったんですが、突き詰めてみると 「コーディングが出来るのはいいんだけど、ぶっちゃけ職位が下のヤツにあれこれ管理されるのはなんか嫌」 という、言ってしまえば極めて感情的な問題がその状況の根本原因でした。 上の話の通り、会社には、「格付け」やら「序列」やらに、強いこだわりを見せる人が、本当にたくさんいる。 彼らはわずかでも「軽んじられた」と感じると、子供のように拗ねてしまう。 例えば、こんな具合だ。 「俺のところに会議の出席案内きてないけど？」 「なんで部長に言う前に、俺のところに持ってこないの？」 「これ、席順が間違ってるだろ。」 それは極めて強力で
絶対時間(エンペラータイム)というのを生活に導入したらいい感じになった - でこらいふろぐ
前提 私は以下ブログに書いた通り、子育てしながらコツコツやりたいことを進める工夫として、1日やるTODOを繰り返し予定で入れてひたすら毎日そのTODOをやっていく、TODO以外のやりたいことがパッと出たら、spreadsheetで作った"やりたいことリスト"に突っ込んで忘れるということをしている。 dekotech.dekokun.info 絶対時間(エンペラータイム)の導入 最近、1日のTODOが一旦全部終わったら、そこから寝るまでの時間を"絶対時間(エンペラータイム)"と定義して、何をやってもいい時間としてみることにした。寝る時間は21:30固定なので、21:30までの余った時間、ということになる。 だいたい1日0分から40分くらいの間で推移しつつ運用できている。 無事に今日のタスクや家事を全て済ませることができた。これから約40分、エンペラータイム(絶対時間)だ！！！— でこくん (
「反ヴィーガニズム」問題について - 過ぎ去ろうとしない過去
５月に入ってから、twitter上ではヴィーガンを攻撃するようなツイートが、目立って増えてきている。なぜ突然そのような現象が起きたのか。一説では、まとめサイト（アフィリエイトサイト）における仕掛けがあるという。 話に聞いたところ、反ヴィーガニズム、どうやら匿名掲示板、アフィブログ、Twitterが連動して盛り上げてるみたいですね。 特に匿名掲示板では3月中旬から同じIDで立てまくってるやつがいる、と。 アンチフェミなどと同様で、恣意的な流れを作って誘導してる輩がいるようで。 — 孔悠鬼 (@kongyouguai) May 20, 2019 真偽のほどはさだかではないが、たとえきっかけがまとめサイトのアクセス数稼ぎにあったとしても、けして彼らを「アフィブログに釣られた情弱」とバカにしてはいけない。むしろ日本twitterにはヴィーガンに対して進んで攻撃的な態度をとるようなユーザーが潜在的に
技術力評価会のこと
VOYAGE GROUPでは技術力評価会という制度でエンジニアの技術力を評価している。そのやり方を紹介しつつ、よくあるトラブル、そしてそこに込められた想い…。我々はどこに行こうとしているのか。その全貌が明らかになる。 （この文書は エンジニアのマネージメントで悩んでいる人が集まる会 #3 での発表資料をもとに加筆・修正しています） 技術力評価会の実装VOYAGE GROUPでのエンジニア職評価は4グレード制を採用しており、グレード1, 2の人が評価対象者、グレード2,3,4の人が評価者となる。つまり、グレード2の人は評価される方もやるし、評価する方もやることになる。 人事評価は「能力」「実績」「CCFB」で決定されるということになっている。ここでいう「能力」について評価しようっていうのが技術力評価会の領域というわけだ。つまり、人事評価制度のすべてではないし、ここだけで給料が決まるわけでもな
プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)７つの要点。仮説（48）転職(9) - Qiita
プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)７つの要点。仮説（48）転職(9) プログラマ転職転職活動interview名古屋のIoTは名古屋のOSで 背景 プログラマが、顧客、仲間、発注先の人と打ち合わせなどで、人と面談することがある。 採用の面接官になることもあれば、顧客への御用聞きに伺うこともあるかもしれない。 顧客、発注先との面談では、時間を切ることが大事。 公式・非公式 公式の面談と、非公式の面談との組み合わせが必要になるかも。 ここでは、まず、公式の面談に絞ります。 面談が終わった後、思いも寄らない、声をかけてもらうことがあります。御用聞きはそのためのものと言ってもいいかもしれません。面談後の非公式の時間に最大の成果があることも。 苦手な口頭のやりとりは、仕事と割り切って、１週間に１時間くらいは時間を割くのもいいかもしれません。
Qiitaで記事を公開するときに気を付けるべきマナーについて 〜無断でネットや書籍の内容を丸写しするのはやめよう〜 - Qiita
はじめに 僕は「プロを目指す人のためのRuby入門」（通称チェリー本）というRubyの入門書の著者です。 本書は発売以来、非常に多くのみなさんに読んでいただき、筆者として大変喜んでいます。 しかし、その一方でQiitaを見ていると、「これ、明らかにチェリー本の説明文やサンプルコードを参考にして書いてますよね？」という記事をよく見かけます。 中にはきちんとマナーを守って記事を公開されている方もおられますが、残念なことに僕から見て「悪意がないのはわかるけど、そのスタイルで公開されるのはちょっと困る」と感じるケースがかなり多いです。 この記事では、書籍やネット上の情報を参考にしてQiitaに記事を公開する際の最低限のマナーについて説明します。 また、この記事の内容はQiitaのみならず、自分のブログに記事を書くときにも意識すべき内容になります。 備考：「そもそもこの記事ってガイドライン違反じゃな
Cordovaをdisる人類全員に読んでほしい「Cordovaつらいを考える」｜榊原昌彦
以下の記事で「Cordova／Ionicに比べれば、まだ少しはまともな選択だろう」と述べてあるのをみて、ここ数年Web Nativeに関わって思うことをちょっとまとめてみようと思います。 私はWeb Developerですので、この記事はWeb Native寄りの意見になります。また、本記事内では、いわゆるWeb Viewでつくるガワアプリを「Web Native」、それ以外（React Native/Native Script/Swift/Kotlinなど）をまとめて「Mobile Native」と呼称しております（分類はWhere Does Ionic React Fit in the React Ecosystem?から） note: Cordovaつらいって言っちゃだめという記事ではありません。OSSの活動は続いてるので、伝聞や過去のものではなく、最新のCordovaやWeb Na
メモ：「口の悪い優秀なエンジニア」の問題を英語でググりたいときは「toxic experts」とか「brilliant jerks」 - Technically, technophobic.
これの内容どうこうよりも、こういう話をググりたくなったときのための自分用メモ。 anond.hatelabo.jp 11月頭くらいにTLでそういう話が盛り上がってたけど、きっかけはたぶんこの記事で、 While toxic experts bemoan lack of skills, they showcase the main skill gap the tech industry needs to fix: empathy. https://t.co/zLhJpl2oxn— Ned Batchelder (@nedbat) 2017年11月3日 続いてNetflixのBrendan Gregg氏が書いたこの記事。 new post: Brilliant Jerks in Engineering https://t.co/npUqguRCmZ pic.twitter.com/lLSuPn
僕がプログラムを作る手順｜erukiti
プログラムを作る時に、紙に設計を書いてから書く人、いきなりコードを打ち始める人、色々なパターンがあると思います。 僕がプログラムを書く手順について雑にまとめてみました。 関数と書いてるものは、場合によってはクラス・メソッドその他かもしれません。ご自身の環境に合わせて適宜読み替えてください。 まずはプログラミング自身というよりはそこに至るまでの話から始めます。 脳内のあれこれを吐き出すまずは何を作るのか、どうやって作るのか、なぜ作るのかなどを整理します。 紙やホワイトボードは最強です。UMLなりポンチ絵なり、文字なり好きな物をものすごい解像度で描けます。 安いノートを買ってきてもいいですし、ホワイトボードや、消せる紙、NuBoardなどを使うというのもいいでしょう。ちなみにお金を掛けずに擬似的NuBoardをするのであればクリアファイルを活用するといいでしょう。 タブレット+ペンもとても便利
そのリリース日そんなに大事ですか？ - だいくしー(@daiksy)のはてなブログ
今期の目標設定を決めましょう、というときに、よく「〇〇の機能を期日どおりにリリースする」と書きたくなりがち。ぼくも以前はよく書いていた。 マネージャの仕事をそれなりの期間やっていくうちに、この考え方はまったく意味がないな、と思うようになった。 リリース日を遵守する、というのは、プロダクトのビジネス価値を生み出す要素の一つにすぎない。期初にたてた予算が、この日にリリースされることを前提に計画されている、とか、競合製品よりはやく価値を出すためにはどうしてもこの時期にリリースしたい、といった感じだろう。 なのでリリース日を目標にするのはなんの問題もない。当然そのように振る舞うべきだ。ただ、これが評価に結びつくととたんに破滅する。 リリース日遵守を基準点。遅延すると減点、前倒しで加点。こんなふうにしてしまうと最悪。 開発を進めるうちに、どうしてもリリース日に間に合いそうにない。スコープを絞って間に
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アンチパターンから学ぶ RDBの正しい設計 / learn-from-failure-2
