タグ

開発に関するticchoのブックマーク (22)

  • ソシャゲ運営を8年やって感じた、良いところと悪いところ - 音速きなこおはぎ

    ポエムです。筆者はプランナーおよびプログラマーとして、いわゆるソシャゲの運営を8年ほど務めてきました。過去を振り返って、ぶっちゃけ話をつらつらと書いていきます。 現実はこんなに若くないけど TL; DR 「運営」の良いところは何よりも「失敗できること」。ゲームづくりは試行回数が命。 一方、「ソシャゲ」に目を向けると、今後はゆるく滅びていくしかないだろうなあと思ってしまう。法外な課金体系についても思うところがないといえば嘘になる。 AI の出現やらでビジネスモデルもクリエイティブも大きく変化が予想される中で、今までの成功論からは離れて、もっと危機感を抱いて次の時代を作らなければ生き残れないだろう。 おことわり 内容はすべて筆者の個人的意見であり、責任はすべて筆者に帰属し、所属する組織団体の意向とは一切関係がありません。 それと、一部経営層への批判と捉えられる文章があるかもしれませんが、それら

    ソシャゲ運営を8年やって感じた、良いところと悪いところ - 音速きなこおはぎ
  • わかりやすいシステム構成図の書き方 - Qiita

    わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか? このシステム構成図のわかりにくい点が3つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の3つです。 わかりやすいシステム構成図 これら3つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分

    わかりやすいシステム構成図の書き方 - Qiita
  • 2022年におけるフロントエンド開発のベースライン

    LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022フロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは4Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは!LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変

    2022年におけるフロントエンド開発のベースライン
  • 超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1) Regional Scrum Gathering Tokyo 2022

    超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1) Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 記事ではほぼ90分におよぶセッションの内容を、前編、後編(1)、後編(2)の3に分けて紹介します(この記事は後編(1)です)。 前編では、子供の頃からプロ

    超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1) Regional Scrum Gathering Tokyo 2022
  • ヒット作が出ないまま10年間個人アプリ開発を続けたエンジニアの末路|dancingpandor

    この記事は 個人開発 Advent Calendar 2021 の18日目の記事です。 「もうスマホアプリ市場はレッドオーシャン」とか、「個人アプリは埋もれてしまって全然ダウンロードされない」とかいう話をちらほら聞きます。 実際、過去に個人でアプリをリリースしたけれど、ヒットしなくて辞めてしまった、という人もいるのではないでしょうか。 では、もし… ヒット作が出ないまま10年間個人アプリ開発を続けたら、どうなってしまうのか という話をします。 作ったものまずは、これまで作ったアプリやダウンロード数などのデータをまとめます。 これまでにリリースしたアプリは、 iOS(ツール系):39 Android(ツール系):1 ゲーム:29 で、計68です。 (Androidアプリは、iOSアプリのAndroid版なので合計にはノーカウント) ツール系アプリは、「写真/ビデオ」カテゴリが多いです

    ヒット作が出ないまま10年間個人アプリ開発を続けたエンジニアの末路|dancingpandor
  • アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021

    アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか? という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応

    アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021
  • そろそろ語ろうか(其の壱)|和田洋一

    2016年2月末、スクウェア・エニックスを離脱して数か月になり、これまで伝えられなかった事もお話しできる立場になりました。 証券時代16年、ゲーム時代16年と、気がつけば中々の古参。 改めて見渡すと、アーケードゲーム、家庭用ゲームPC、スマホゲームと全ての時代を経験し、かつグローバル展開を行っていた方がほとんどいらっしゃらない事に気づきました。 またこの間、経営者として、業界リーダーとして、数々の貴重な局面に立ち会っています。 事実を忘れてしまったり、自分の都合のいいように記憶を塗り替える前に、皆さんにお話しする意味があると思いました。 経営者は、その足跡について1ミリ単位で説明できなければならないというのが、私の持論です。 無論、その時々の事実認識には個体差はあるでしょう。また、戦略実行にあたっては、様々な方が関わりますから、各人の視点によって、同じ事実でも見え方は異なるでしょう。さら

    そろそろ語ろうか(其の壱)|和田洋一
  • 拝啓、お客様。Webサイト制作のコストはここにかかります。 | 株式会社LIG(リグ)|DX支援・システム開発・Web制作

    令和ですね。こんにちは。バックエンドエンジニアのまさくにです。ゴールデンウィークで休んでいたら、シュワシュワと筋組織が融解し、「自然に帰ろう……自然に帰ろう……」と遺伝子に刻み込まれた内なる声が僕を光射す方へ誘いました。もはや社会復帰は難しいかもしれない。 さて。さてさて。 皆さま、いかがお過ごしですか。新しい期に入り、心機一転したい気持ちでしょうか。何ならアレですか。お持ちのWebサイトをリニューアルしたい、そんな気持ちをそろそろお持ちでしょうか。 失礼ながら、そのお気持ち、 たぶん5ヶ月、遅いです! 仕事としてWebサイトの制作に携わってから、5年くらいが過ぎました。現在はバックエンドの作業を行いながら、TD(テクニカルディレクション)やPMプロジェクトマネージャー)として、プロジェクトに関わることも増えてきています。その観点から言って、お客様と我々の間には「Web制作」の考え方にお

    拝啓、お客様。Webサイト制作のコストはここにかかります。 | 株式会社LIG(リグ)|DX支援・システム開発・Web制作
  • Redmineの裏の顔~開発基盤としてのRedmine - プログラマの思索

    Redmineには、オープンソースのプロジェクト管理ツールという表の顔だけでなく、業務アプリケーションの開発基盤(プラットフォーム)という裏の顔もある。 アイデアを下記にまとめてみた。 【1】最近、Redmineを企業(IPAも含む)が機能拡張する事例が少しずつ増えている。 何故、Redmineをカスタマイズしてでも、使いたいのか? Redmine来は、オープンソースのプロジェクト管理ツールという表の顔がある。 ソフトウェア開発の進捗管理を開発チームがやりたいなら、一通りの機能が揃っている。 特に、日では、Redmineの人気が高いらしい。 その理由は、インストールして、プロジェクトやワークフローなどのパラメータを設定すれば、すぐに運用できるからだろう。 そして、実際の運用は各チームで微妙に異なる場合が多いけれど、その微妙な違いもRedmineで実装できるくらい、Redmineが柔軟

    Redmineの裏の顔~開発基盤としてのRedmine - プログラマの思索
  • 基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る(前編)

    基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る(前編) 基幹システムをクラウドで実現する。その過程でどのような技術を用い、どのような苦労があったのか。小売り流通業である西鉄ストアの基幹システムをAmazonクラウド(以下、AWSAmazon Web Services)の上で実現したノーチラス・テクノロジーズが、その詳細について紹介したセミナーを5月15日、アマゾンジャパン社のセミナールームで開催しました。 大規模システム開発の現状、Hadoopの可能性、クラウドのメリットとデメリットなど、参考にすべき多くの内容が語られたセミナーでした。この記事ではその概要を紹介します。 止まってはいけない基幹システムをクラウドへ ノーチラス・テクノロジーズ 代表取締役社長 神林飛志氏(写真中央)。 西鉄ストア様の部基幹システムをクラウドへ移行する

    基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る(前編)
  • 最強のIT系かあちゃんからたかしへのアドバイス

    ぎゃばん -1.0 @ledsun たかしへ あなたの勤怠確認しました.こんなに残業が多い割に大して売上が上がってないのはどうしてですか?顧客との信頼関係の構築も甘いとと思います.来月からは頑張って下さい.ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 2012-02-24 13:21:23 ぎゃばん -1.0 @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか?残業でカバーですか?お客様が参加するイベントが入っていません。都度調整ですか?事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか? 2012-02-24 13:46:29 ぎゃばん -1.0 @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかっ

    最強のIT系かあちゃんからたかしへのアドバイス
  • 高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!

    どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP

    高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
  • 最初から締め切り終盤勢いの開発は可能か? - teruyastarはかく語りき

    ※最後に2つ追記しました。 この話面白い。 11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - デジタル - 日経トレンディネット http://trendy.nikkeibp.co.jp/article/column/20111215/1039018/ スマホゲームアプリの開発を命じられたのは、東日大震災直後の今年3月。 出された課題は 「4月から開発に着手し、7月末までに70タイトルそろえる」 「開発スタッフは既に決まっている人間で進める」 「8月にTVCMなど大々的なPRを行うため遅延は許されない」の3点 『11のやめたこと。』 1.「組織の細分化、階層化をやめる」 マネジャーが増えるということは、ゲームの作り手が一人減るということ。 優秀な人間がマネジャーになるほど、アプリの制作力は低下する。 2.「職種別の目標設定をやめる」 プログラマー、企画など

    最初から締め切り終盤勢いの開発は可能か? - teruyastarはかく語りき
  • テスト/品質系エンジニアが身に付けておくと得をする7つの技術 - 現場のためのソフトウェア開発プロセス - たかのり日記

    「Software Test & Quality Advent Calendar 2011」の初日エントリーとして、書きます! テスト/品質系のエンジニアも、今や、テストや品質のことだけを知っているだけでは、幸せにはなれない時代となってきています。 プログラムは書けなくても、身に付けておくと良いと思っている技術をまとめてみました。 ※注 今回記述した内容は、以下のような私のドメインに偏ったモノになっています。 ミッションクリティカル/エンタープライズ系 Java/.NET 他のドメインでは異なる部分や他の標準的なツールがあれば、コメントを頂ければと思います。 バージョン管理/課題管理 今や、必須のスキルと言えるでしょう。 バージョン管理(SCM/VCS/DVCS)としては、 集中型のSubversion(SVN) 分散型のGit/Mercurial などが有名ですね。 分散型の場合は、各エ

    テスト/品質系エンジニアが身に付けておくと得をする7つの技術 - 現場のためのソフトウェア開発プロセス - たかのり日記
  • 工数見積もりで陥りやすい罠 - プログラマの思索

    「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記:一部修正した。 ※追記:Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念~Velocity: プログラマの思索 ソフトウェア開発に特有な技術~ソフトウェア見積り: プログラマの思索 チームは加速するのか~Velocityの使い

    工数見積もりで陥りやすい罠 - プログラマの思索
  • DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して

    データベースには,「トランザクション分離レベル」というものがある。 以下では,それが なぜ必要なのか? デフォルトのレベルでは,どうして駄目なのか? PostgreSQLでは,どうやってレベルを変更・確認するのか? などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは: 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか,のレベル。 ANSI規格では,4つのレベルがある。 READ UNCOMMITTED (一番低い) READ COMMITTED REPEATABLE READ SERIALIZABLE(一番高い) 徹底比較!! PostgreSQL vs MySQL 第3回:トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく

    DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して
  • Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して

    プログラミングと設計は来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の

    Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
  • 営業は利益を、開発は売上を | ベンチャー法務の部屋

    私は、弁護士という職業上、あまりビジネス・コンサルタントっぽい発言は控えてしまう傾向にあります。 ただ、数多くの経営者やコンサルタントの話を耳にさせていただく中で、ある瞬間にいろんなことが結びつき、異なる表現ではあるけれども、同じことを意味しているのではないかと思わさせられることがあります。今回は、その話をさせていただきます。 先日、企業の利益向上のための施策についての議論を耳にしました。話をわかりやすくするために、小売業で考えてください。その議論とは、次の問題に関わるものです。問題とは、「既に市場で売り出されている製品Xについて、さらに利益を上げるためには、どうするか」というものです。もちろん、市場や経済は、様々な要素や人間の気持ちによって左右されますので、画一的な回答があるわけではありません。ただ、一般論として、利益を上げるには、(i)価格を上げる、(ii)販売数量を増やす、(iii)

  • あなたが知らないかもしれない 受託開発の基礎知識 - 新井俊一のソフトウェアビジネスブログ

    ソフトウェアビジネスラボ第三回の私のスライドを掲載します。 (第2回のスライドは弊社の戦略がばれてしまうため掲載できません、残念。) ソフトウェアビジネスラボ第三回では大阪から壇弁護士に来ていただき、 ソフトウェア受託開発の契約についてお話しいただきました。 来場者の皆様に大変ご好評をいただきました。 また次の機会には是非みなさんお越しくださいね! あなたが知らないかもしれない 受託開発の基礎知識