仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR
仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR
「ベンダーロックイン」と呼ばれる、情報システムを導入した企業以外がメンテナンスなどを行えず、他社の参入が難しくなる状態について、公正取引委員会は、他社の入札参加を難しくする行為などが企業側にあれば、独占禁止法に違反するおそれがあるとする報告書をまとめました。 「ベンダーロックイン」について公正取引委員会は、去年6月から中央省庁や地方自治体などを対象に調査を行い、1021機関からの回答をもとに報告書をまとめ、8日、公表しました。 情報システムの保守や改修の際の契約相手について尋ねた質問では、従来の企業と再度契約したことがあると答えたのが98.9%を占め、このうち48.3%は、その理由として「既存事業者しかシステム機能の詳細を把握できなかった」と回答しました。 公正取引委員会は、情報システムに詳しい人員が十分でないことなどを背景に、官公庁でベンダーロックインが広がっているとみています。 そのう
要約 「英語で意見を言おうとすると5歳児のようになってしまう」という課題を解決するEnglisterというサービスを開発した。 自分で使ってみたところ、10問程度の問題を解くだけでスラスラと英語で意見を言えるようになった。 実装はDeepL APIとNext.jsのAPI routeを使って爆速開発をした。 追加(2021/01/18) 記事を公開してから毎日機能追加をしています。2週間前からどれだけ変わったか是非見ていただきたいです。 背景にあった課題 「英語で意見を言おうとすると5歳児のようになってしまう」 英語にすごい苦手意識があるわけではない。TOEICは840点で、すごく簡単な日常会話なら問題なくできるので、海外旅行で困るということはなかった。しかし、仕事でたまに海外の人とやりとりをするときや外資系企業の英語面接で**「ちょっと難しい質問」**をされると、途端に5歳児になってしま
Ruby on Rails を用いたシステム上で入力フォームを実現する際、Rails が提供しているフォームヘルパーを利用した実装や、React や Vue によるコンポーネントの自前での実装が一般的に行われます。 ここで、職業で学生を選択した場合は学校名と学年、会社員を選択した場合は役職と年収を入力する...といった、条件分岐が大量に生まれる入力フォームを想像しましょう。 一般的な実装手法では、あるフォームの入力値が他のフォームに影響を与えるような、複雑で動的な入力フォームの実現をするために、大量の if 文を書く必要があります。 また、ユーザから送信された入力値の正しさをバリデーションするために、バックエンド側に同様の if 文を大量に書く必要が出てきます。 そこで私は、複雑な仕様の入力フォームの実装のための JSON Schema 活用方法および事例について紹介します。入力フォームの
Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈(少なくとも自分の観測範囲)では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの
September 15, 2021 @ iCARE Dev Meetup #25
Nuxt.js で開発されていたAI受診相談ユビーのフロントエンドを Next.js で作り直しました。 まだまだ仮説検証を繰り返すフェーズのスタートアップのため、機能開発を止めて一気に置き換えることはできず、機能ごとに少しずつ置き換えてリリースをしました。結果、5人のプロダクト開発チームによる機能開発と並走して、全体の移行を1人で1ヶ月の短期間で終わらせることができたので、その意思決定や過程、工夫を紹介します。 移行前の課題 まず前提として、移行前の Nuxt.js による実装は 2018 年に立ち上がったもので、当時 toC の Web サービスを持っていなかった Ubie が ほぼ 1 人の小さいチームで PoC 的に作り始めたものでした。また、当時の Next.js は今ほど多機能ではないプレーンなフレームワークでした。 これらを踏まえて、当時の状況で MVP を最速で作るための技
「アジャイル開発が必要」と声をかけられて行ってみたら、モノを作る以前の状態で、何を作っていくのか方向性がない、「必要なのはサービスデザインだった」ということが少なくない。 言葉の解像度があってない、で片付けるのには大きすぎるズレ。アジャイル開発を早期に何らかアウトプットしていくもの、くらいのイメージだけで捉えていると起きうる。どうやって、最初のアウトプットが生み出されるのか、がブラックボックス。タイムボックスという箱に蓋をして、外から眺めているだけでは、この解像度は高まらないままだ。 やむを得ないことだ。プロダクト作りのリテラシは関係者によって様々だ。アジャイルだの、サービスデザインだのが意味するところを理解するには時間も、下地も、関心も不足しがちだ。 では、目の前の立て込んでいるプロダクト作りはどうしたら良いのだろうか。何を作るのかの方向性について何ら確からしさがないところで、最初のイテ
こんにちは、Quipper iOS エンジニアの @manicmaniac です。 現在スタディサプリ iOS アプリ開発チームのエンジニアリングマネージャをしています。 今回はスタディサプリで長らく使われていた React Native のコードを Swift に書き換えた話をします。 実は React Native から Swift への置き換え自体は半年ほど前に完了していたのですが、ブログに記すのに時間がかかってしまいました。 スタディサプリにおける React Native の利用 Quipper では 2017年ごろから React Native を iOS / Android アプリ開発に利用し始め、スタディサプリでは 2018年3月ごろから徐々に React Native を iOS アプリケーション開発に導入していました。 iOS 版スタディサプリの、git から取り出した
プロジェクトが始まるときにかなり初期の段階でWBSを作ることは多いとおもいます。そのWBSの作成、プロマネやディレクターに任せっぱなしになっていないでしょうか。WBSはスケジュールをガントチャートで表したものを指していると思われがちですが、実はスケジュールだけでなく見積もりやアサインを精度高く行うためにも重要なものです。 たとえば「Webデザイン作成」というスコープにどのような実作業が含まれているかはWBSを作ることによって見える化しプロジェクトメンバーやクライアントと共有できるようになります。ときどき下記のように書かれたWBSを見ることがあります。 Webデザイン作成 ・作成 ・確認 ・修正 ・確認2 ・修正2 ・確定 しかし、これでは「Webデザイン作成」に必要な知識、さらには作業量・スケジュール・予算も分かりません。Webデザイン作成の例を続けると、下記のように「作成」のスコープを分
はじめに この記事はiOS 13以降にもSwift Concurrency(つまりasync/awaitやActorなど)が使えるようになると思っていなかったときに書いたものです。 はなしの準備 雑談として「最近はどんなアーキテクチャでiOSアプリ作るの?」という話題があったので整理の文章を書いてみます。 Appleの性質上、2021年7月でもまだ決め手のようなものはないし、私だったらTCAやVIPERを候補にモジュール分割してなるべくDB使わずに作って必要になったらCore Dataを採用すると思います。 それはそれとして、Android BlueprintのREADMEかなにかでGoogleのソフトウェアエンジニアが「チームが生産性を最大化させるアーキテクチャを選べばいい」なんてことを書いてあったのを読んだ記憶があるんですが、それは最もですねと思いつつも、しかしそもそも選択肢がわからな
結論から書くと、ちょっと思い当たらない。というおはなし。 そもそも「えきねっと」とはJR東日本の予約サイト。今週末にリニューアルを実施しました。 切符オタクの界隈では「あの切符が発行できない」「売ってはいけないはずの切符が検索結果に出てくる」などなど、いろいろな反応があったようですが、一般の方からすると「鉄道オタクがなんか騒いでいるなぁ」っていう感じかもしれません。私も個々論的なところはあまり興味がないから、そこについては書きません。 じゃあ、ここで何を書くかというと、UIの話をします。鉄道に限らず、いろいろなシステムにも言える話かな、と思ったので。 きっぷを買うまでの道のりが大変先述のプレスリリースには色々と変更点が書かれているんですが、1番目に書かれているのが「列車のお申し込みの操作方法が変わります」という点。 「えきねっと」トップページからダイレクトに、「乗車駅」「降車駅」や「日時」
","naka5":"<!-- BFF501 PC記事下(中⑤企画)パーツ=1541 --><!--株価検索 中⑤企画-->","naka6":"<!-- BFF486 PC記事下(中⑥デジ編)パーツ=8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下(中⑥デジ編)パーツ=8826 -->","adcreative72":"<!-- BFF920 広告枠)ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag PC誘導枠5行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">
委託したシステム開発が頓挫したとして、野村ホールディングス(HD)と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。プロジェクト失敗はベンダー側に非があるとした2019年3月の一審判決から一転、2021年4月の控訴審判決はユーザー企業側に責任があるとした。工数削減提案に十分に応じなかったり、プロジェクト途中で追加要件を多発したりした野村側の姿勢を東京高裁は問題視し、逆転敗訴の判決を下した。 関連記事 野村HDが日本IBMに逆転敗訴の深層、裁判所が問題視した「X氏」の横暴な変更要求 野村HDが日本IBMに逆転敗訴のワケ、「工数削減に応じず変更要求を多発」と指摘 東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券のユーザー部門「X氏」の振る舞いだ。 当時、投資顧問事業部(判決文では「投資顧問部」)の次長だったX氏は、パッケージソフトに
「ユニコーン企業のひみつ」という本を読んだ。 本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。 そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。 ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン(評価額10億ドル以上の未上場企業)に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にSpotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ(Spotifyもすでに上場しているので厳密にはユニコーンではない)。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応
日本のソフトウェア開発はなぜ落伍したのか。中国のエンジニアの間でも話題になることが増えている。未来樹Aは、その理由をエンジニアの視点で解説をしている。委託開発が多い。システム開発の目的がイノベーションではなく、生産性の効率向上に留まっている。政府、地方自治体の案件が上位企業に集中するため、ベンチャーが育たないという理由を挙げている。 中国でも話題になっているCOCOAの件 日本でも話題になっているが、中国でも接触確認アプリ「COCOA」の件が、エンジニアの間で話題になっている。中国では、位置情報とQRコードを活用した健康コードが、2020年2月11日という早い段階で、アリババと杭州市によって開発され、1月ほどで他都市にも広まった。感染リスクが高いと判定されると赤になり、公共交通や店舗の利用ができなくなる。不便は強いられるが、それでも、生鮮ECやフードデリバリーが発達をしているため、生活はな
どうも、エンジニアのgamiです。 数日前に、NoCodeツールのAdaloを使って開発された大学生向けSNS「Union」が資金調達を発表しました。 NoCodeで資金調達まで走ってその後作り直すというのは、まさにNoCodeの正しい使い方という感じする。 "UnionはNocodeツールのAdaloを使用して作成されています。しかし、Nocodeで作成されたアプリは依然として速度、操作性の観点からUI/UXが劣るため今後はFlutterを用い..."https://t.co/kQvk7iEvN6 — gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) April 3, 2021 このニュースには、NoCodeの素晴らしさと限界が現れていると思いました。 「NoCode」という言葉を真に受けると、「もうプログラムを書いたり、高いお金を払ってエンジニア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く