同期エンジンの心臓部を書き換える
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
三井住友銀行アプリについてお話します。｜SMBC DESIGN
こんにちは！三井住友銀行 デザイナーの堀と申します。 前回の初投稿から、SNSなど多方面でたくさんの反応をいただきありがとうございました。予想以上の反響で銀行内でも話題となり、三井住友銀行のデザイナーの活動が少しでも広がったことにうれしく思います。 その中で「銀行アプリが変わった」とのコメントを多くいただき、自分たちが関わったプロジェクトがお客さまの手元に届いているんだなぁと感動しました。 今回はその「三井住友銀行アプリ」について書いていきたいと思います。 本題に入る前に…、お伝えしたいことがあります。 三井住友銀行初！2019年度グッドデザイン賞を取りました！！（ぱちぱちぱち） デザイナーだけでなく、たくさんの方々のご協力、お客さまの声から作られたアプリなので受賞したときは本当にうれしかったです。 それでは本題です。 アプリリニューアルの背景 様々な理由がありますが、まずはこれです。 キ
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
少機能で高機能な製品を作る
ついついやってしまいそうになるのが新しい機能の追加だが、そこは心を鬼にして本当に必要な機能なのかを考えるべきだ。 多機能な製品は市場の幅を広げると思いがちだが、そんなに簡単に市場の幅は広がらないし、多機能にすればするほど価格を上げていく必要が出てくる。 高くて多機能な製品が必要なお客さんはほんの一握りだし、もともとの市場が小さい場合は、そんなお客さんはいない可能性がある。 一度追加した機能は外せない最初のうちに色々便利な機能を追加しようと躍起になりがちだがそれらの機能は一度でも積んだらそう簡単には外せなくなる。 外せないとりあえず付けた機能をメンテナンスしていくのはなかなかしんどい。その機能が邪魔で新しい機能をつけづらい、といった問題もでてくる。 多機能は製品の寿命を縮める場合がある機能を追加すればその分だけコードが増える。さらにテストも増える。依存関係も増える。 つまり、その製品のメンテ
トレタの増井さんに聞く、B2Bサービスのカスタマイズ
今日の夜、トレタの増井さん（@masuidrive）さんと会って晩御飯を食べました。下らない話や日本企業の海外進出の話などをする中で、B2Bサービスがカスタマイズを受け入れるというのがどういうことなのか、という話が大変面白かったので、許可を得た上でブログ記事にさせてもらいました。 B2Bとは、Business to Businessの略語であり、企業が主に企業に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指す言葉です。対義語がB2C(Business to Consumer)で、企業が主に個人に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指します。B2Bビジネスの場合は契約1口あたりの金額が大きくなる傾向があり、逆にB2Cビジネスは1口あたりの金額はさほど大きくないのが普通です。 自分も昔の会社でB2Bを経験したことがあるのですが、B2Bをやる上で1つ大
考え直そうーーRuby on Rails生みの親でBasecampの創業者がスタートアップに贈る言葉【寄稿】 - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
Ruby on Railsの生みの親、Basecamp（旧 37signals）のファウンダーでCTOのDavid Heinemeier Hanssonさんによる寄稿記事です。著書に、ニューヨーク・タイムズの�ベストセラー「REWORK」と「REMOTE」。「ル・マン24時間レース」のクラス優勝者。Davidさんの活動は、ご本人のWebサイト、またTwitter（@DHH）でフォローできます。本記事は、Mediumに投稿された記事をDavidさんから許可を得て翻訳したものです。元の英語記事もどうぞ。 *記事は、「Web Summit 2015」のDavidさんの講演内容を起こしたものです。 #WEBSUMMIT2015 12年前、僕はBasecampというスタートアップを共同創業した。月額制のシンプルなコラボレーションツールで、チーム間のプロジェクト進行を後押ししてくれる。 それがあること
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
「できません」と言わないソフトウェア技術者の話。
私の知人に、ほとんど「できません」と言わないソフトウェア技術者がいる。営業であれば、「出来ません」と言わない方は普通にいるのだが、ソフトウェア技術者では珍しい。 「GoogleAnalyticsのように、グラフィカルに表示できないですか？」 ⇒「なんとかしましょう」 「1週間以内に実装できないですか？」 ⇒「わかりました」 「応答のスピードを上げられますか？」 ⇒「やってみます」 彼は周りからたいへん頼りにされているのだが、かと言って安請け合いするわけでもない。仕様に問題があれば必ずディスカッションを求め、必ず納期は守る。 私は彼が「やったことはないですが、多分できるでしょう」と言い、そのとおりになったことを何度も見た。 最近すぐに「できません」という社員が増えているとの悩みを経営者の方々からお聞きする。無茶な要求をする 上司や顧客がいるのも事実だろうが、考えもしないで「できません」という
グーグル元社員がエンジニアに「酔っぱらいテスト」を薦める理由
おたくの社員が失敗作を生む たいていのテクノロジー企業は、発売前の商品のベータ版を社員に使わせて反応を見る。「ドッグフード」と呼ばれるこのプロセスは、バグや、使い勝手が悪いところを見つけて、商品の完成度を高める貴重なチャンスだ。 もちろんグーグルもドッグフードをやっている。 ただ、「ちょっと問題があるんだよね」と複数の元社員は明かす。グーグルは社員におたくっぽい人間が多いから、商品の評価におかしな偏りが出るというのだ。「商品を世に出すには、グーグル社員の支持を集めないといけない。グーグルの社員が使いたいと思うものでないといけないんだ」と元幹部は語る。 とはいえ、社内トライアルで確実に支持を得る方法があると、この人物は言う。データ機能とチャートを加えることだ。必ずしも一般ユーザーには重宝されない機能かもしれないけれど……。 「社内トライアルでいい結果が出るように、グーグル社員の好みを意識しす
第1回 事業会社における開発とポエム | gihyo.jp
この連載ではピクシブ株式会社という東京にある事業会社で盛んになっている「ポエム」によって駆動する開発について、その特徴をお話します。第一回は舞台となっているピクシブという会社はどのような環境か、その会社で書かれている「ポエム」とは何なのかをお話します。 「ポエム」で開発を駆動するとは 駆動開発という言葉はソフトウェア開発文脈でよく使われます 例えばテストコードによって開発を駆動するテスト駆動開発という言葉は開発者にとってお馴染みでしょう。 ではポエム駆動開発という言葉を聞いた事はあるでしょうか？ ポエム駆動開発のオリジナルはppworks氏によるポエム駆動開発によるWEBサービスの作り方 pplog誕生ものがたりというエントリーで発表された手法です。 意思決定の際大事なのはポエムなのです。「pplogのポエムは俺たちのゆるふわインターネット「pplog」 をリリースしました（してまし
「メンテナンス大変なのでサービス閉じたいです」 - tototoshi の日記
Web サービスの会社にはイケイケなサービスの陰に隠れて、かつてイケイケだったけど今はイケテナイサービス、とか、ぶっちゃけ最初っからあんまりやる気なかった☆サービス、これどこで拾ってきちゃったのサービス、などなど、惰性で続いちゃってるようなサービスがごろごろあったりします。 そういうイケテナイサービス群はメンテナンスの手間を取らせる物なので、エンジニアとしては閉じてしまいたい。でも非エンジニアとしては閉じたくない。いや、本当は閉じたい！でもちょっとは儲かってるし、閉じるとわずかながら存在するユーザーからクレームくるし、連携先の企業とやりとりするのめんどいし、まあいろいろめんどうそう。 そこで、「イケテナイサービスにはできる限りメンテナンスの手間を払うな」という話がエンジニアのとこにきて「お前なーっ！そのメンテナンスの手間がなーっ！」となり、話がループを始めます。なぜこういう噛み合わない話に
遅ればせながら「「特許庁業務・システム最適化計画」の改定について」について - kuenishi's blog
Slashdotでみた56億円返還の件で興味が湧いて調べていたら、 「特許庁業務・システム最適化計画」の改定についてというやつを見つけたので目を通してみた。一度失敗したプロジェクトをどう再出発させるのかということと、実社会に直接影響を与えるこのシステムがどういう風になっていくかに興味があるからだ。 28枚という短い文書だが、短いだけに情報が凝縮されていてとても面白い。リンクされているPDFの文書は、平成25年3月という、一作年度末に書かれたものであることがわかる。この文書は、改定前の失敗とかそういったことには一切触れない。おそらく改定前のものと比べながら読んだら非常に味わい深いものになること請け合いであるが、ここではとりあえず措くこととする。 まず、特許庁の業務は大きく分けて、受付発送、方式審査、実体審査、登録、公報発行、審判の6種類があること、そのために平成2年に世界で初めて電子化された
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
タクシー業界を変えた『日本交通タクシー配車』は、情シス社員2人の挑戦から生まれた【特集:スマホが企業を救う】 - エンジニアtype
トップページ > 旬ネタ > タクシー業界を変えた『日本交通タクシー配車』は、情シス社員2人の挑戦から生まれた【特集:スマホが企業を救う】 スマートフォンのGPS機能を使ってタクシーを呼び出すO2Oアプリが人気を博している。現在、類似アプリが複数存在しているが、その先駆けとなったのが『日本交通タクシー配車』だ。 開発を担当した日交データサービスは、1977年に日本交通グループのシステム部門として発足して以来、配車や顧客管理、給与計算、日報管理など、同グループにおける基幹業務システムの開発と運用を行っている。社名や業務内容から想像される通り、この配車アプリの開発に乗り出すまでは、自社ホームページ以外でBtoC向けサービスにかかわることはほとんどなかったという。 システムグループリーダーの若井吉則氏は当時を振り返る。 「ガラケー全盛期に携帯向けの『モバイル配車』というサービスを提供していたこと
優れた仕様を決定するために必要なこと - GoTheDistance
たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない？
いつまで開発のやり方ばっかり語ってるの？ #sgt2013
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
技術革新は何のためにあるのか？ - 急がば回れ、選ぶなら近道
技術革新は須く斬新的なものであるべし、という肩に力の入った信念の人は流してください。ちょっと、力の抜いた小ネタなので。 最近というかここ10年来、いわゆる業務系のシステムに関わっていてよく思うことではあります。特に最近、NoSQLやHadoopといった「新技術」が登場するにつけて強く感ることではあるのですが、なんというか、「こんな感じ」のことができます、というようなプロダクトアウト的でありながら、かつ、漠然とした抽象的な話が多すぎる気がします。要は、全般的に問題の設定が苦手だよなということです。 特定の技術の各論はともかく、まず、大上段に構えると、実はITでは一般の人が想像する以上にユーザーとベンダーで期待ギャップがあります。ユーザーから見ると、大抵は「こんなこともできないのか？」ということがごく普通にできません。一方、一般のTVとか報道とかは、スパコンや遺伝子やビッグデータや、なんやらか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Wantedlyの成長を支える管理画面 #admin_night
3年前の僕へ
TechCrunch
