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

テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023

2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書

文章を書く前にやることよい文章を書くには、実際に文章を書く前に、読者は誰か、どういう悩みを解決するのかを企画することが大切です。また、それを元にアウトラインを書いておきます。 このふたつを元に文章を書くことで、読みやすい開発ドキュメントにつながります。これについては、次の記事をご覧ください。 開発ドキュメントを書く前に決めるべき3つのこと【企画編】開発ドキュメントにおけるアウトラインの書き方開発ドキュメントの書き方企画とアウトラインの作成が終わったら、実際に文章を書いていきます。文章を書くときは、次の9つを意識して書きます。これだけで、読みやすさ、分かりやすさが大きく向上します。 一文を短く切る結論を先に述べる指示語を使わない主語を明確にする、述語との距離を近づけるひらく・閉じるを統一する再現条件を示す前提を揃える見出しや箇条書き、表などを適切に用いる読者に伝わる用語を使うひとつずつ説明し

アニメ業界のエンジニアリング改革に向き合って 『シン・エヴァ』の制作を支えた「スタジオカラー」のシステムづくり 2022年5月11日 株式会社カラー 執行役員 技術管理統括／株式会社プロジェクトスタジオQ 取締役副社長 技術管理統括 鈴木慎之介 1981年東京生まれ。高校在学中にドワンゴにエンジニアとして入社。音楽配信サイト等の立ち上げを経て、2006年動画共有サイト「ニコニコ動画」の立ち上げに参画。その後、開発部長、子会社社長等を歴任。2017年、麻生塾・カラー・ドワンゴの３社による映像制作スタジオ「プロジェクトスタジオQ」を立ち上げ、2019年、カラー執行役員技術管理統括に着任し、カラー全体のシステム及び、『シン・エヴァンゲリオン劇場版』を始めとした作品を支えるシステムを担当。 社会の変化に立ち向かう人たちに向け、「テクノロジーで、挑戦を恐れない勇気を。そして変化のリスクをチャンスに。

たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に

みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、

識別符号（アクセス管理者によってその内容をみだりに第三者に知らせてはならないものとされている符号≒パスワード）がないので、不正アクセス禁止法が禁ずる行為には当たらないが、虚偽内容で予約するのは、人の事務処理を誤らせる目的で行えば電… https://t.co/D7EJ5cCksU

//////////////////////////////////////////////////////////////////////////////// 追記：2021年5月2日 なーんでこんな場末の記事に辿りついたのか見当も付かんのですが、どうにも変な人たちが湧き始めたので、コメント欄を閉鎖します。 あと言葉足らずの部分の補足とか一部過激な表現も訂正いたしました。 //////////////////////////////////////////////////////////////////////////////// この記事はとある友人Aに向けたものである。 先日彼とモンスターをハンティングしながらの雑談の中で「ゲームクリエイターとして見たらディライトワークスってどうなの？」と聞かれたからである。 実は私は大のFateファン、というかTYPE-MOONファンである。 いわ

日本のソフトウェア開発はなぜ落伍したのか。中国のエンジニアの間でも話題になることが増えている。未来樹Aは、その理由をエンジニアの視点で解説をしている。委託開発が多い。システム開発の目的がイノベーションではなく、生産性の効率向上に留まっている。政府、地方自治体の案件が上位企業に集中するため、ベンチャーが育たないという理由を挙げている。 中国でも話題になっているCOCOAの件 日本でも話題になっているが、中国でも接触確認アプリ「COCOA」の件が、エンジニアの間で話題になっている。中国では、位置情報とQRコードを活用した健康コードが、2020年2月11日という早い段階で、アリババと杭州市によって開発され、1月ほどで他都市にも広まった。感染リスクが高いと判定されると赤になり、公共交通や店舗の利用ができなくなる。不便は強いられるが、それでも、生鮮ECやフードデリバリーが発達をしているため、生活はな

COCOA が動いていなかったことで大臣が謝罪してひと騒動起きている件について、開発者視点からのメモを残してみます。 なぜこのメモを書いたのか 世間的には不正確な情報で叩ければOKの風潮が強くてしんどいので、正しいと思われる情報を拾い集めたものです。中抜きwww 王子wwwww Xamarin wwwwwwww みたいな人にはあんまり興味ないかと思います。 調べ始めたきっかけはこのツイートと引用されたblog記事ですが、記事の内容が違うことはすぐに指摘されて撤回されていたのですが、実際どうだったのかさらに調べてみました。 接触通知アプリ COCOA とはなんなのか 仕組みとか何かは公式サイトでもみてもらうとして。この件で煽っている人でも一部理解できていない人がいるようなのですが、直接的な効果としては 保健所が濃厚接触者追跡をする際の手助けとなるためのアプリ ということになります。アプリをイ

「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも

はじめに この記事を書いているモチベーション 自己紹介 NTTのどこで働いていたの？ 入社した理由 前職の良かったところ ①休暇がとても多い ②福利厚生が充実している ③業績が安定している ④スキルアップできる（運要素多め） 退職理由 ①「自分がやりたいこと」と「この会社でできること」のミスマッチ ②本質に集中できない セキュリティ 社内システム Thinクライアント 社内資格制度 ③手を動かすエンジニアとしてのキャリアアップが望めない ④向上心のある人が少ない ⑤経営層への信頼 申し訳ないこと 結局、入社してよかったのか 次はどこで働くの？ はじめに 多分令和一号目のNTT退職エントリーを書きました。 平成最後のNTT退職エントリは↓っぽいですね。 yuyarin.hatenablog.com この記事の内容は、あくまで個人の一経験に基づいた主観性の高い内容です。 この記事を書いているモ

ホーム 全記事 ニュース 『フォートナイト』の成功は、終わりなきデスマーチに支えられていた。土日返上で行進を続けるライブサービス時代の申し子 海外では近年、『Anthem』を手がけるBioWareの開発難航と過酷な労働環境（関連記事）、『League of Legends』のRiot Gamesにおける性差別文化（関連記事）といったゲーム業界に蔓延る問題が、現・元従業員による告発記事として続々と暴かれていっている。告発者は企業の機密情報をリークしていることもあり、こうした報道には眉をひそめる読者もいる。一方で、上述したBioWareとRiot Gamesのように、記事の公開を受けて指摘対象となった企業が改善に向けた取り組みを発表するケースがあるのも事実。告発記事はゲーム業界に確かな影響を与えてきた。 そしてこのたび、海外メディアPolygonが、現在のゲーム業界を代表する作品のひとつ『フォ

筆者撮影、2019春先日、他社からのオファーを断った。非常にエキサイティングな海外の会社（勤務地も海外）だったのだけれども、その決断に際して3週間くらいうじうじと迷っていた。 この記事は、入社エントリでも退社エントリでも年収エントリでもない。少し変わった選択をした26歳のソフトウェアエンジニアが、会社をどう選んでいくのかに関して自分なりに整理した。ついでに、まだあまり情報がないTRI-ADという会社についても少し触れる。 20代でキャリアに関して悩むことは多い。大学院か就職か、どの国・地域でどんな人々と働きたいのか、そもそも何がしたいのか。そんななかで、なぜトヨタを選択したのか、会社の選択とリスクってなんなのか、TRI-ADや自動運転が抱える挑戦はなんなのか、という順に話を構成する。キャリアについて悩む人や、TRI-ADに興味がある人の何かの助けになると嬉しく思う。 注意会社の見解ではない

富士通退職エントリーが話題な時期となってまいりました。 5年いた富士通を退職した理由 新卒で入社して13年が経ちましたが、いまだに在籍しております。 tnaoto.hatenablog.com 前回の記事から3年くらい経ったので、その差分でも書いてみようと思います。 2016年 富士通研究所では共通インフラとして開発環境整備が行われており、研究員全員が使えるGitHub Enterpriseの導入を仕切っておりました。 2019年現在でも、GitHubEnterpriseは利用されております。 もちろん富士通のクラウドサービスを活用しております。 jp.fujitsu.com この導入に関し、富士通事業部やGitHub社と連携し、海外カンファレンス(GitHub Universe)に参加させていただくなど初体験のことがありました。 これらの活動から、富士通の職位で一般最高位であるプロフェッ

ITプロジェクトに参画するには色んな立場があると思います。ざっと上げるだけでもこんな感じで、失敗する要因はだいたい決まっています。プランニング不足です。 ・受託開発を請けた開発会社として ・プロジェクト支援依頼を請けたコンサルタント・PMOとして ・事業会社のプロジェクト運営側として私はSIer→事業会社→独立してコンサルタントというキャリアを歩んできましたので、全ての立場でITプロジェクトに参画させて頂きました。上手く行った案件もあれば、そうではなかった案件もありました。 SIあるあるだと思いますが、案件が火を吹いてしまうと優秀なエンジニアが矢継早に放り込まれる傾向があります。未熟な人では火を消せませんから。当時SIerに在籍していた私は、結果的にやらかしたPMと優秀なエンジニア、給料変わらないのに優秀な人が貧乏くじを引いてしまうの意味がわからないなぁと思った記憶があります。 その後私も