本セミナーでは、デザインやITの知識を持たない方でも直感的で使いやすいUIの検討（アプリケーションの画面設計等）を行える方法論をご紹介します。 DXに取り組む企業の増加、ノーコード開発ツールの発展などの背景から、最近、デザインやITの知識をほとんど持たない方が業務用アプリ等の画面をつくる機会が増え…
前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「１年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは？ — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024 Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「４年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では４年以上完成しないもの、に含め
このnoteでは、プロジェクトマネジメント（以下、プロマネと略記）のおすすめ本をマトリックス図に整理してご紹介します。 ◆変更履歴◆ 2024.05.07 初版公開 2024.06.12 以下書籍を追加 ・プロジェクトマネジメント 最強の教科書 ・驚異のプロジェクト実行術 準備編 ・驚異のプロジェクト実行術 実践編 2024.10.03 分類図追加、以下書籍を追加 ・よりよくわかるプロジェクトマネジメント ◆今後追加予定◆ ※追加のお知らせはX（@coffee_nomimasu）にて行います ・プロジェクトマネジメントの基本が全部わかる本 ・プロジェクトマネジメントの本物の実力がつく本 ・ITエンジニアのためのプロジェクトマネジメント入門 プロマネ本を探すときの悩み筆者の本棚にあるプロマネ本プロマネ本を探すとき、多くの方は「プロジェクトマネジメント おすすめ 本」などとキーワード検索して、
yamlでテストシナリオを書いたらそのまま実行できる……そんな夢のようなシナリオテストツール"runn"の紹介とやってみた記録です これまでのシナリオテストツールに対する課題感 シナリオテストツールといえば、 Cucumber や Gauge といったツールが有名です。 ですが、これらのツールは「シナリオファイル」とは別に、シナリオを実行するためのコードも書かないといけません。しかも、そのコードではAPIを呼び出す処理を特定のプログラミング言語を使って書かなければなりません。その中には、HTTP Clientを実際に操作するような処理も含まれます。 私は「シナリオテストがしたい」のであって、「シナリオに沿ってAPI呼び出しを行う処理を書きたい」のではありません。こういった課題感を、ここ数年ずっと抱えてきました。 そんなとき、ついに見つけたツールが "runn" でした。 APIのシナリオテ
「地方自治体、府省庁、民間企業が誰でも利用できる素材を配布することで、別々の機関が同じものを制作したり、検討する時間を省く」（デジタル庁）という。アイコンなどを共通化し、ユーザーが一目で理解しやすいデザインを広げることにもつなげる。今後は実際に利用する自治体や企業の声を踏まえ、順次素材数を増やす。 関連記事 デジタル庁、Web・アプリデザインの指針まとめた「デザインシステム」公開 地方自治体の活用も見込む Webサイトやアプリの開発時、一貫したデザインにできるようドキュメントやデータをまとめた「デザインシステム」をデジタル庁が公開した。「デザインシステムに関わる活動をオープンにし、デザインシステムの認知向上や改善につなげる」という。 デジタル庁のWebサイトは阿部寛HPより「やばい」と話題に 河野大臣も「読んでね」 エンジニアの知識共有サービス「Qiita」に6月11日に投稿された「デジタ
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
はじめに テストコード一般の考え方 壊れにくいテストを書く 実装した通りに動作することではなく、仕様通りに動作することをテストする テストコードはシンプルにわかりやすく書く 失敗の原因がわかりやすくなるように意識する RSpecの書き方 テストケース名をitの引数で明記する letよりもlet!を使う 通常の変数と同じ方針に基づいてlet!を利用する subjectを使わない 不要なcontextでのネストを避ける matcherを適切に使い分ける factoryのデフォルト値に依存しないテストを書く 参考にしたブログ記事等 付録：RuboCop設定 We are hiring! サムネイル画像 はじめに テストコードを書く習慣も、近年ではかなり一般的なものになってきました。 ドワンゴ教育事業のバックエンドチームでも自発的にテストコードを書く文化は根付いており、実際に計測はしていませんが、
はじめに 個人開発もエンジニア自体の歴も浅いSEです。 就業先がJavaをメインで使う企業なのですが、個人的にフロントエンドまわりが好きです。 元々、興味本位でデザインの本だったりUXに関する本とかを読んでいたりするのですが、 その結論の際にたどり着いたのが、 「理論とか決まってるなら、それをよしなにやってくれるor参考にできるツールとかサイト探せばよくね」 という結論になりました。なんと怠惰な思考でしょうか。 そんなわけで、こちらではデザインに限らず、色々開発に便利なツールを紹介させていただきます。 （有名なのが多いかもしれませんが、ご容赦ください、結局有名なものに行き着くのです） レイアウト関係 1. Awwwards おしゃれなwebサイトが集まっているサイトです。 ここまで個人開発でお洒落にできたらいいなと思いますが、自分はアニメーションを考えるときや、 作りたいフロント側のデザイ
回答 (7件中の1件目) 通信するデータ量が増えれば増えるだけ、遠距離間における反応は遅くなることは感覚的に理解できるのではないかと思います。 そういう意味で、反射速度を上げてゲームむを滑らかに遂行させるためには、なるべく通信するデータは少ないのがベストです。 なので、単位時間当たりのプレーヤーの位置、入力コマンド、標的の座標といった、操作に関わるデータを何かしらのデータ圧縮を用いて通信し、そのうえで遠隔地にいるプレーヤー同士の対戦を実現しているのだと思います。 その時に、なるべくデータを小さくするためにある程度の操作などをテーブルにまとめておいたのを用意し、一回のデータで複数のコ...
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
介護や医療、ヘルスケアなどの領域で、高齢社会に適した情報インフラを提供している株式会社エス・エム・エスの西村直人（@nawoto）です。私は2005年からソフトウェア開発においてアジャイル開発を実践しており、現在はアジャイル開発の考え方を軸にチーム開発の支援などを行っています。 エンジニア組織ではリリースを頻繁にできることが望まれますが、リリースすることに疲れたりしませんか？僕たちは「リリース疲れ」と呼んでいますが、疲れが溜まるようにどんどんリリースが辛いものに感じてきます。エンジニア以外に言ってもあまり理解してもらえませんが……。 そんな悩みを解決するべく、エス・エム・エスの開発チームで行ったのは、レゴを組み立てること。え、なんでレゴ？そんな「リリースレゴ」という取り組みについてご紹介します。 プロダクト開発を継続すると起こる「リリース疲れ」 事業は長く継続していくように構築されているも
はじめに 規模の大小を問わず、レガシー化したサイトには色々な課題が存在します。課題の根本的な改善のためにソースコードをゼロから書き直してリニューアル（以後、このことをフルリニューアルと呼称します）するということは、とても魅力的な一方でリスクもあります。フルリニューアルすなわちアンチパターンとされていることも多いですね。ここでは「中規模程度のコミュニティサイトをフルリニューアル、すなわち一から全部作り直す」という選択をした背景や、その進め方について書いていきます。 なお、書きやすさのために筆者一人で思考・実行したように書いていますが、実際には事業部所属のもう一人のエンジニアもしくは二人の考えや行動をミックスしたものとなっています。 TL;DR PHP 5/Ethna & Smarty/オンプレ/オフショア開発7年ものを引き継ぎ/ツライ ↓ PHP 7/Laravel & Vue.js, El
2017年2月にコーエーテクモウェーブから発表された多機能VR筐体「VR センス」は、近年盛り上がりを見せるVRマシンの中でも、際だってユニークな存在だ。 ※VR センスでは、VRのシステム自体はPlayStation VRを使用している。プレイヤーはコックピット型の筐体内部に座って、VRの世界を体験。座っているシートが前後左右上下等に稼働してアクションを体感できる「多機能3Dシート」をはじめ、「香り機能」「風機能」「ミスト機能」「温冷機能」や、頭の上にいきなり虫が落ちてきたり、足下をネズミが走り抜けたりといった感覚を疑似体験できる「タッチ機能」まで搭載されている。（編集部注） 歴史シミュレーションゲームで知られるコーエーテクモが独自のVRマシンを、しかもアミューズメント向けの筐体をリリースするというのも驚きだが、我々が特に興味を抱いたのは、本機の開発経緯だ。 このVR センスはなんと、コ
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
こんにちは。 テストエンジニアからサービス開発エンジニアにロールチェンジした、茂呂一子です。 先日リリースしました、iOSクックパッドアプリのリニューアルプロジェクトに参加し、サービス開発エンジニアとしての第一歩を踏み出しました。 今回は、アプリのリニューアルをすすめていく中で、試してみたことについて、お話しします。 アプリリニューアルの内容やそのデザイン意図については、13年続いた「つくれぽ」をリニューアルした話｜Misaki Kubosaka｜noteが詳しいので、こちらをお読みください。 リニューアルプロジェクト第1フェーズの問題点 iOSアプリのリニューアルプロジェクトは、とても大きく、機能を段階的にリリースするため、3つのフェーズに分けて開発していくことが決まっていました。 そのため、開発チームはメンバーの追加をしつつ、複数回の開発サイクル(仕様決定、設計、実装、検証)を繰り返す
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
モダンアプリケーション開発ホワイトペーパー（日本語改定版）が公開されました | Amazon Web Services
Amazon Web Services ブログ モダンアプリケーション開発ホワイトペーパー（日本語改定版）が公開されました 皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー（日本語版）がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS（英語版）の日本語版になります。 ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」（日本語版）というタイトルの51ページのドキュメントで、 はじめに
5. 5 目録 ◼ 私の失敗体験談（不均衡データの学習） ◼ 機械学習開発における壁 • 機械学習のビジネスフレームワーク「5D」 • Define（定義する） • Data（データを集める） • Development（開発する） • Deploy（実装する） • Drive（運用する） ◼ ビジネス応用における壁 • AIを使ったキュウリの自動選別 • 機械学習を使って売り上げに貢献する • 機械学習を使わない選択肢 ◼ まとめ 6. 6 目録 ◼ 私の失敗体験談（不均衡データの学習） ◼ 機械学習開発における壁 • 機械学習のビジネスフレームワーク「5D」 • Define（定義する） • Data（データを集める） • Development（開発する） • Deploy（実装する） • Drive（運用する） ◼ ビジネス応用における壁 • AIを使ったキュウリの自動選別 • 機
2020/02/01 追記 [コード付き]誰も知らない関連銘柄を、機械学習を使って素早く見つける こちらに最新の結果を載せました！ 気づいたんですけど、私みたいな貧乏人はショッピングモールでおしゃれなゴミをせっせと買い漁るんですが、お金持ちの人って株を買うらしいんですよね。 考えてみれば貧乏人が欲しがるものって、百均のちょっとしたものから家や車やバイクやゲーム機など、買ったらお金が減るものばかりなんです。 それに比べて、お金持ちが買うものって、株や投資用の土地や、リスクこそあるものの貧乏人が欲しがらないわりに買ったらお金が増える可能性のあるものばかりなんですよねー。 これは悔しい！休日になるたびにせっせとショッピングモールにお金を運んでゴミを買い漁ってる自分を見てお金持ちはきっと笑っているに違いない！いやお金持ちには自分のような人間は視界にすら入らないのか、これはさっそく株を買わないと！と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
