接触確認アプリCOCOAからの教訓｜情報処理学会・学会誌「情報処理」
楠 正憲（内閣官房 政府CIO 補佐官） 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた．筆者は 2020年4月から接触確認アプリの導入について，有志での議論に参加し，有識者会議のメンバとして，また途中から政府CIO補佐官として， 接触確認アプリの導入を支援してきた．本稿では接触確認アプリCOCOAの開発と運用について，どのような課題があったかについて振り返る． 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年（2020年）3月頃のことである．ちょうどシンガポールのTrace Togetherが話題となって，日本でも接触確認アプリをリリースできないかといった話題で，いくつかのコミュニティが盛り上がり始めた． Androidのシェアが高いシンガポールに対して，日本ではiPhoneのシェアが非常に高く，iP
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
牛の背に乗るネズミになれ! ソフトウェア思考のススメ
牛の背に乗るネズミになれ! ソフトウェア思考のススメ 2020.01.04 Updated by Ryo Shimizu on January 4, 2020, 14:06 pm JST 昨年一年間をかけて、僕は日本の大企業群を研究した。 大企業の中心で働く様々な人にインタビューし、彼らの会社が技術をどう捉え、ビジネスをどう捉えているかを知った。 どうしてこれほど海外のネット企業勢の蹂躙を許しているのだろうか、という疑問に答えるためだ。 そしてわかったのは、根本的に日本のビジネスシーンでは「ソフトウェア」が理解されていないということだった。 プログラミングではない。ソフトウェアである。 アメリカのネット企業のトップも全員がプログラマーというわけではない。 しかし、彼らはソフトウェア的発想、ソフトウェア的思考法というものをごく当たり前のように身に着けている。 これを僕は「ソフトウェア思考」と
「本日増員20名が来る。マシンはまだない」信じられないPMの言動10選 - paiza開発日誌
Photo by thejbird こんにちは。倉内です。 先日PM経験を振り返って反省する記事を書いたばかりですが（さまざまな反応ありがとうございました！）今度は前職でプロジェクトメンバーだった頃に遭遇した、いろいろなプロジェクトでの「信じられないPMの言動」をまとめてみました。 このようなPMを反面教師にしきれなかった部分ももちろんありますが、「自分はこうならないぞ」と戒めにしていた部分もありました。 今回は私の経験談だけでなく、SEの友人にヒアリングした内容も含めています。もちろん表に出せるものだけを厳選しているのでご安心ください！ 信じられないPMの言動10選 1.「年末年始休む人は理由含めて報告して」 出る前提かい！というツッコミはもはや入れる元気もありませんでしたが、デスマってると休むのが異端みたいな空気ありますよね。怖い。 みんな頑張って出るならまだ納得できるのですが、実作業
書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
メテオフォール型開発 - 実践ゲーム製作メモ帳2
今日は、日本の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな
「 ソフトウェアの資産計上」は業界の求めたこと | おごちゃんの雑文
Twitterで いつどう言う理由でこんなアフォな法律にしたのか知らないけど、即刻撤回するだけで日本はIT国になれる気がする。 「日本においては、税務上は自社開発のソフトウェアも資産計上して、3年若しくは5年で減価償却をする必要があります。」 https://t.co/TaAkA72OG7 — ザバ(ザバイオーネ) (@z_zabaglione) 2017年8月22日 というのが流れて来て元ネタの、 Amazonは最大のハックである「税ハック」と日本のソフトウェア産業の競争優位 を読んだのだが、事実誤認とゆーか、読みスジ違いが酷いのでまとめておく。会計士の人が書いているようなので、そういった意味の「間違い」ではないのだが、根本にズレがある。 そもそも、昔は無形固定資産に「ソフトウェア」という科目はなかった。 なかったらどうだったかと言えば、「ソフトウェア」は全て経費であり損金だった。その当
Facebookの特許条項付きBSDライセンスが炎上している件について｜こんぴゅ
先月あたりから、オープンソースソフトウェア（以下、OSS）のライセンスのあり方について、Facebookを火種にして侃々諤々の議論が起こっているので解説してみる。 ASFがFacebookにNOをつきつけることの始まりは、Apache Software Foundation（以下、ASF）という著名OSSプロジェクトを多数保有する非営利団体が、Facebookが自社OSSに付加している独自ライセンス Facebook BSD+Patents license を「Category-X」リスト（禁忌リスト）に追加したことだ。 ASFプロジェクトは、Category-Xに含まれるOSSに依存してはいけない決まりがあるため、Facebook製のOSSに依存しているプロジェクトは、8月31日以降はそれらの依存を取り除いてからではないと新しいリリースが出来ない。影響を受けたプロジェクトは少なくとも C
「スキル伝授にはペアプロが最速」というのは何故か - 圧倒亭グランパのブログ
この問いに対して、自分なりの答えを言語化できたのでまとめます。 目次 目次 疑問 実践する機会 自分なりの答え 「コードを書く瞬間の思考」にアドバイスを貰える 他の方法で代替できない ペアプロの欠点 まとめ 疑問 きっかけは、下記の方々のやり取りをTwitterで見かけたからです。 「それをできる人とペアプロする」以上に短期間で新しい技術を身につける方法を知らない。— Jxck (@Jxck_) 2017年2月3日 ペアプロが最速だろうなあ https://t.co/SdbZZ2EypI— Takuto Wada (@t_wada) 2017年2月3日 サッと調べると「最速なのは同意」という意見が大半でした。自分もこれには同意するのですが、「なぜペアプロが最速なのか？」という疑問を持ったのです。 ペアプロ、最速だと思うんだけど、なぜ最速なのかがハッキリわからない。「わからないことがすぐに聞
正確な見積もりはデスマーチ・プロジェクトを救うか？
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回から“見積もり”をテーマにした新シリーズ「見積もり：ソフトウェア技術者の最高の能力」をお届け。今回は、ソフトウェア開発で正確な見積もりが必要とされる理由について紹介する。 今回から新シリーズとして、「見積もり」を取り上げます。見積もりは、これまでお届けしてきた“ソフトウェア・メトリクス”以上に大きなテーマであり、ソフトウェア工学における最重要課題の1つといえます。 ソフトウェアの開発は、可能性を追求する「科学（science）」ではなく、採算性を重視する「工学（engineering）」です。プロジェクトでソフトウェアを開発する場合、“何人のエンジニアを何カ月投入すればよいか”を見積もることは非常に重要ですが、実際、ほとんどの組織でこうした見積もりがきちんとできていません。この瞬間にも、世界中で何十万ものソフトウェア開発プロジェクト
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（4）
プロジェクトの規模 † ソフトウェア見積りの最大の変動要因はソフトウェアの「規模」 規模は他の要因以上にばらつきがある 規模はLOC（Lines Of Code：コード行）、ファンクションポイント、要求、Webページ数などではかれる どの尺度で測ってもプロジェクトの規模と工数は正の比例関係にある 最大のコスト変動要因がプロジェクトの規模であるというわかりきった事実に組織は二つの点で違反する。 「■そのソフトウェアがどれだけの規模になるかわからずに、コスト、工数、スケジュールを見積ってしまう（p.62）」 「■ソフトウェアの規模が意識的に増やされた場合（つまり要求変更に応じた場合）にも、コスト、工数、スケジュールを調整しない（p.62）」 ソフトウェアの規模の不経済＝「ソフトウェアにおいて、プロジェクトが大きくなるほど、より大きなグループ間のコーディネーションが必要になる。大きなグループにな
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（3）
4章 見積り誤差はなぜ起きる？ † 見積り誤差を引き起こす原因は、一般的に４つある。 ■ 見積りプロジェクト自身に関する不正確な情報 ■ プロジェクトを遂行する組織の能力に関する不正確な情報 ■ 正確な見積りをサポートするプロジェクト内の過剰な混乱（つまり、移動するターゲットを見積もろうとすること） ■ 見積りプロセス自体から発生する不正確さ （p.38） ↑ 見積りの不確実性の原因、不確実性のコーン（見積りプロジェクト自身に関する不正確な情報） † 「それぞれに具体的な機能が詳細に理解できるまでは、ソフトウェアプロジェクトのコストを正確に見積ることは困難だ。「何か」が定義されていないのに、その何かを構築するために必要な作業量を見積ることはできない。(p.38）」 機能単位の見積りは、その機能の詳細、採用される設計とその複雑さ、実装方法・実装者のスキル、要求される品質レベル、担当者のデバッ
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（2）
アークウェブシステム開発SandBox Web制作会社アークウェブのスタッフが、システム開発のTips・ノウハウをまとめているWikiです アークウェブシステム開発SandBox アークウェブWebマーケティングSandBox アークウェブWebデザインSandBox アークウェブ アクセシビリティWiki http://www.ark-web.jp/sandbox/wiki/2658.html トップ ] [ 編集 | 凍結 | 差分 | バックアップ | 添付 | リロード ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ] 3章 正確な見積りの価値 † 非現実的なターゲットと達成不可能なコミットメントによって見積りが不正確になり、プロジェクトが失敗するのは長年取り上げられている 「多くのソフトウェアプロジェクトは、カレンダー時間の不足によって失敗している。これは他のす
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（1）
1章 見積りとは † 見積りの精度を向上させるためには、「見積り」、「ターゲット」、「コミットメント」を区別して考えることが重要 見積り プロジェクトにかかる期間やコストを予測すること ターゲット 実現したいビジネスの目標。達成可能なものとは限らない。 コミットメント 定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束。コミットメントと見積りが同一のものである場合もあるが、コミットメントと見積りが同一で「なければならない」と考えてはいけない。 見積りは先入観に縛られない分析的なプロセスであり、ゴールはあくまで正確性であって、特定の結果を追求することではない。一方、計画のゴールは特定の結果を追求になる。「見積りとは計画を立てることではないし、計画は見積りを作ることではない(p.4)」 見積りと計画は全く異なるものであるから、求められているものが見積りなのか計画である
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【魚拓】みずほ銀行の炎上プロジェクトに支援に行ってきた話|問題編 - ここもちろぐ