タグ

開発とシステム開発に関するsatoshieのブックマーク (14)

  • 優先順位が口癖になる危機感 - ジンジャー研究室

    開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。(なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない) 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは3ヶ月後だ。そして3ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。3ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する

    優先順位が口癖になる危機感 - ジンジャー研究室
  • これからドメインエキスパートという職種が重要になりそう - SaaSベンチャーで働くエンタープライズ部長のブログ

    2021年はB2B SaaS開発にどっぷり浸かりました。バクラク請求書という経理業務の支払処理に該当するサービスを開発していたのですが、当然のことながら専門業務向けのSaaSになります。 プロダクトマネージャーとしても動いていたのですが、具体的な経理知識が必要になり、経理の方から常にヒアリングを重ねていました。しかし、個社によって事情は異なります。例えば、仕訳の切り方1つにしても教科書的に正しいものと、現場での作業では簡略化して入力するものなどがあり、それらを考えた上での仕訳機能を策定する必要があります。 また、法令改正などの影響によって仕様が影響を受け、ここも理解して開発を進める必要があります。あるべき仕様やペインが何なのか、また法令によってどのような影響を受けるのかを判断できる、経理業務に精通した人間が内部にいる必要を痛感しました。 この内部領域専門家は「ドメインエキスパート」と呼ばれ

    これからドメインエキスパートという職種が重要になりそう - SaaSベンチャーで働くエンタープライズ部長のブログ
  • 政府向けシステムの話をするときの前提知識

    政府向けシステムに関わったことがある身からすると、政府向けシステムの話をするときに前提として知っておいてほしいことは、住基ネット最高裁判決に「現行法上,人確認情報の提供が認められている行政事務において取り扱われる個人情報を一元的に管理することができる機関又は主体は存在しない」という骨子があること。これによって政府向けシステムは個人情報を一元的に管理できず、個人情報は各自治体で分散管理しかできない。この文面でググれば政府がどれだけこの骨子を気にしているかは分かると思う。 今回の話は「国民マスターテーブルを持たずに認証するにはどうすべきか」という政府向けシステムで常に挙がる課題で、良いアイデアがある人は政府に提案しにいってほしい。個人情報保護法の目的外利用に違反しない上で。 はがき送りつけこれをできるのは自治体のみで防衛省はできない。防衛省は国民の住所氏名を知らないのではがきを送れない。防衛

    政府向けシステムの話をするときの前提知識
  • COCOA開発受注企業が事業費94%を3社に再委託、さらに2社に…不具合の原因企業「分からない」:東京新聞 TOKYO Web

    新型コロナウイルス陽性者との接触を知らせるアプリ「COCOA(ココア)」の開発で、厚生労働省の委託先の企業が別の3社に、契約金額の94%で事業を再委託していたことが分かった。同省は再委託比率を「原則2分の1未満」とする規定を設けているが、それを大きく超える比率で認めていた。ココアは不具合が続発。同省の調査や監督が及ぶ元請け企業の役割が小さく、原因把握が難航している。 (皆川剛)

    COCOA開発受注企業が事業費94%を3社に再委託、さらに2社に…不具合の原因企業「分からない」:東京新聞 TOKYO Web
  • 数億円規模の案件を たった二人で開発させられた話

    # 数億円規模のプロジェクトをたった二人で開発させられた話 先日、関わっていたプロジェクトを抜けることになりました。 原因はもちろん炎上によるものなんですが、これがもう炎上すべくして炎上したようなぶっ飛んだプロジェクトでしたので、 ここで吐き出させて下さい。 # 20数名のメンバーの一人だったはずが、いつの間にか総勢一人になっていた 僕の仕事のスケジュールに空きができ、週3日程度の仕事を探していた頃、Twitterから開発案件の依頼がきた。 内容はよくあるシステムのリプレース案件。 開発メンバーは既に5人程度集まっており、その後20人ほど合流するとのことで、総勢20名以上の開発メンバープロジェクトだ!こんな規模の新規開発なんて初めてだからワクワクするぞ! と思っていたら、PHPの案件なのにほとんどがJavaの人だったのでメンバーとして数えられず、参画する前に去っていってしまった。 合流する

    数億円規模の案件を たった二人で開発させられた話
    satoshie
    satoshie 2020/02/13
    ご愁傷様です感が半端ない。このPM(と言われている人)は生暖かく監視対象に入れます。
  • 青山Pが振り返る「ドラゴンクエストX」3つの失敗――消すつもりのコードが本番環境に

    翔泳社は2019年2月14~15日に「Developers Summit 2019」を開催した。稿では、スクウェア・エニックスでドラゴンクエストXのプロデューサーを務める青山公士氏の講演「ドラゴンクエストXを支える失敗事例」の内容を要約してお伝えする。 青山氏は「ドラゴンクエストX オンライン」(以下、「ドラゴンクエストX」)で起きた3つの不具合とその原因を取り上げ、ドラゴンクエストX開発陣が不具合から得られた教訓を紹介した。 ドラゴンクエストXはどのように開発、実装されているか? ドラゴンクエストXは、各ユーザーがゲームクライアントを通じてサーバに接続し、ゲームをプレイするMMORPG(Massively Multiplayer Online Role-Playing Game)だ。開発では、さまざまな機能拡張や期間限定イベントの実施を見据えて柔軟に対応できる「運営」と、不具合修正や障

    青山Pが振り返る「ドラゴンクエストX」3つの失敗――消すつもりのコードが本番環境に
  • 業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary

    昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か

    業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary
  • メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した(前編)。Mercari Tech Conf 2018

    2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま

    メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した(前編)。Mercari Tech Conf 2018
  • 20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog

    こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに番リリースしました。 「それってテストいるんですか?」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi

    20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
  • 短期インターンシップでAkatsuki Inc.に行った - takanakahiko’s blog

    この度,Akatsuki Inc.(以下アカツキ)で短期インターンシップをさせて頂いた. 得た経験を忘れないように,そしてインターンシップに興味のある若者へ少しでも参考になるように,記録を残しておこうと思う. なりゆき 2018年4月某日,私はGoogleの社でLTをしていた. なぜ私は,女児アニメの話を200人の前で話しているのだろう. 時は少し遡る. ... 私は六木ヒルズ森タワーにいた. そう,「Tokyo GAS on GCPUG 2018 Spring」に参加していたのだ. 学生枠でギリギリ滑り込みの参加であったが,とても有意義な情報を得られて満足していた. その会場で一のアナウンスが入る. 「BeerTalkの枠が一つ増えました.飛び入りで話したい人は手を上げてください」 私の右手は天井を指していた. ... そのときに発表した資料がこちらである https://spea

    短期インターンシップでAkatsuki Inc.に行った - takanakahiko’s blog
  • プロダクトのヘルプサイトをマークダウンに移行した話 - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは!開発部テクニカルコミュニケーショングループの仲田です。 皆さんマークダウン使ってますか?(唐突) 文書記法の一つで、プログラマーにとっては馴染みがあるものだと思います。サイボウズのプロダクト仕様書もマークダウンで書かれることが多くなっています。 ですが、公式ドキュメントを作る用途として採用される例はまだ少ないように思います。数ヶ月前になりますが、プロダクトのヘルプサイトをマークダウンに移行しましたので、今回はその話をします。 なぜ移行したのか マークダウンに移行した動機は、一言で言うとヘルプサイトの制作や更新を効率化するためです。 サイボウズでは、プロダクトのアジャイル開発化を進めています。アジャイル開発では、ウォーターフォール開発と比べてリリース間隔が短縮されます。パッケージ製品がメインだった頃には、リリースは年単位で、短くても数ヶ月ごとというスパンでした。ところが、クラウド

    プロダクトのヘルプサイトをマークダウンに移行した話 - Cybozu Inside Out | サイボウズエンジニアのブログ
    satoshie
    satoshie 2018/09/22
    頭良い。これやりたい。
  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • RDBMSの時代の終わりが見えてきた - きしだのはてな

    クラウドと一緒にやってきたもの 最近、クラウドが流行ってます。 GoogleMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。 で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。 GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonSimpleDB。どれも、基的にはひとつのテーブルにハッシュコードでアクセスするようになっています。 ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。 クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDB

    RDBMSの時代の終わりが見えてきた - きしだのはてな
  • 今度の不況でSI業界が悲惨な状況に陥りそうな3つの理由 - masayangの日記(ピスト通勤他

    釣り 題名に「3つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 当かな? 題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流=付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会

    今度の不況でSI業界が悲惨な状況に陥りそうな3つの理由 - masayangの日記(ピスト通勤他
  • 1