ちょめ子 @chome2xx 私「この機能って今使われてますか？」 ？「今は使われてない認識です」 私「設計書って更新されてます？」 ？「更新されてる認識です」 いや、認識じゃなくて事実を教えてくれって思ってしまうのだが、SEこういう言い回し好きだよね

建物は変化する。刻々と成長し、みずから学んでいくものである。単なる空間的な構造物ではなく、時間というパラメータを考慮に入れ、この世界に生まれ、様々な成長を遂げ、やがては死に至る、一種の「有機的存在」としてとらえなおす必要があるのではないか。 スチュアート・ブランド※1 は、著書『How Buildings Learn』で、時の流れとともに建物に何が起こるのかを探究しました。そのなかでブランドが提示した「ペースレイヤリング（Pace Layering）」の概念は、建築の世界にとどまらず、情報やメディアに関わる分野でも多くの注目を集めてきました。 この本が世に出てから20年後の今、その思想の意味をあらためて考えたいと思います。 スチュアート・ブランドの基本モデル ペースレイヤリングの基本となったのは、この本で示された以下のモデルです。 ［図1］ “Shearing Layers of Chan

コンテンツマーケティングでのエンゲージメント獲得では「関係性の分岐点」を意識すると良いです。そのコンテンツ単体へのアクションを期待するだけでなく、どうすれば関係性のないユーザーに対して「次のメッセージ」を届けられるかを意識すれば、オーディエンスビルディングにつなげられます。一方で、短絡的な目先の獲得ではなく段階的に受け入れてもらう設計も必要です。 ここではエンゲージメント獲得について話をしていきます。 まだ関係性のないユーザーにどうすれば「次のメッセージ」を届けられるか コンテンツを起点としてユーザーに対してエンゲージメント獲得を図るとき、コンテンツ単体へのアクションを中心に設計されることがあります。「いいね」やgoodボタンなどの評価、ソーシャルメディアへのシェア、どれだけの時間を費やしてくれたか（滞在時間、再生時間）、最後まで楽しんでもらえたか（視聴維持、読了）、関連コンテンツ遷移など

はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな

よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

ソフトウェアデザイナー（以下、デザイナー）とソフトウェアエンジニア（以下、エンジニア）の両職能を行き来している人はもしかしたら共感してもらえるかもしれませんが、デザイナーがデザインをする上での思考とエンジニアが設計する際の思考は「具体的情報を集めて抽象化した情報をベースにさらに具体的情報を検証し、また抽象化した情報へフィードバックする」といういわゆるモデリングを踏まえるのはどちらも行うことです。 デザイナーは直感的でエンジニアは論理的という印象が強く一見すると交わらなそうな両職能ですが、意識的であっても無意識であっても実はモデリングをするということに関しては変わらないです。 これをデザイナーとエンジニアの両職能を自身でやるとより肌感として感じますし、モデリングを意識的にやっているからこそ両職能の行き来がシームレスにできるとさえ思います。 というわけで、今回はデザイナー・エンジニア（それ以外

ITリサーチ大手の米Gartner（ガートナー）は2021年12月7日（現地時間）、電動化や自動化が進む自動車業界において、自動車メーカー上位10社のうち半数が、2025年までに自社で半導体チップの設計を行うようになるとの見解を発表した。自社設計に切り替えることで、これまで半導体メーカーに依存していた半導体供給に対するコントロールを強化する狙いがあるとしている。 現在自動車業界で使用している半導体の多くが8インチウエハーを使って製造されている。8インチウエハーは、自動車用半導体以外にも、電源管理用ICや各種センサー、無線通信用チップなど様々な製品の製造に使用されている。こうした需要に加え、8インチウエハー用の半導体製造装置の新たな確保が難しく、ファウンドリーの生産能力をこれ以上拡大することは難しいという事情もある。こうした状況を踏まえ、ウエハーを12インチに切り替え、新たな製品を自社で設計

経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている

こんにちは、ティアフォーのSafety Engineerの須永です。 ティアフォーの安全への取り組みを数回にわたって紹介していくシリーズの今回は第２回目になります。第１回目については以下をご参照下さい。 tech.tier4.jp 最近、社内では機能開発に向けた実車機能テストが増えてきています。公道での実験もあることから、より一層、安全意識を持った実験を行う必要が出てきています。そこでティアフォーでは安全に関する社内の勉強会を隔週で開き、社内における安全意識と知識の醸成を図っています。 そのような取り組みの中で今一度初心に帰り、「安心・安全って何だろう？」ということの確認と自動運転の安全を確保していくための私達のアプローチを確認しました。今回の記事では、その内容をお伝えしようと思います。 そもそも安心・安全ってなに？ ティアフォーの中でも安心・安全の議論はよくされます。しかし人によって言葉

こんにちは、開発チームのアーキテクトをやっている竹野（@Altech）です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して

フレームワークってよく聞くけど、一体何ができるんだろう？ Go言語のフレームワークには、どんなものがあるんだろう？ と疑問に思うことってありませんか？ そんなときは、実際にGo言語のフレームワークで使うコードを見てみると何ができるのか理解しやすくなります。今回はできるだけコードも載せながら、さまざまな種類のGo言語のフレームワークについて解説していきます。 なお、次の記事ではそもそもGoとはどんなプログラミング言語なのか、その特徴をできることや将来性も交え詳しく解説しているので良ければ参考にしてください。 → Go言語とは？特徴やできること、学習方法をわかりやすく解説 Go言語とは Go言語はGoogleが開発したプログラミング言語です。基本的な特徴としては、コンパイルと実行が高速で、シンプルな設計の言語とされています。静的型付け言語なのでJavaやCなどの開発言語と類似点が多い反面、継承

clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

「UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている」「キャッシュはアーキテクチャではない。単なる最適化だ」などの語録を生んだ「Goの父」とも呼ばれるロブ・パイク氏の「プログラミング5カ条」について、ネット上で話題となっています users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html Rob Pike's Rules of Programming (1989) | Hacker News https://news.ycombinator.com/item?id=24135189 パイク氏の「プログラミング5カ条」は以下。 ルール1：プログラムのどこで処理時間がかかるかはわからない。ボトルネックは意外な場所で発生するので、ボトルネックがどこにあるかを証明するまでは、臆測

タイトル詐欺である。今回も反省せずに続きといきたい。 前回も示したが、ざっくりとした銀行の基幹系システムは「勘定系」「情報系」「チャネル系」の三つの構成になっているという図が上である。ざっくりとしたものなので、実際にはもっと複雑(特にメガバンクでは)だし、これがあるのにアレがない、とかいったものはある。細かいところを気にしすぎると禿げるぞ。 今回は、銀行の基幹系がなぜ古臭いのかという話をしたい。古臭いと言ってもいろいろあって、特にエンジニア界隈からは「メインフレームを使ってる」とか「COBOLみたいなカビの生えた古代言語を使ってる」とか、とにかくイケてないシステムの代表例のように言われることが多い。対して、預金者の側からはネットとの親和性だとかサービス面の不満からくるイケてないという話が多いと思うのだが、これはどちらかというとシステムの話ではなくて、サービス設計とかその背景になるビジネスモ

はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一

はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も

「ランディングページってホームページ運営やWebマーケティングをしていると時々聞くけど、どういう意味？」「ランディングページと通常のページは何が違うの？」