式年遷宮アーキテクチャに関して（いまさら） - 勘と経験と読経
数年前に流行したソフトウェアアーキテクチャのメタファー（？）として「式年遷宮アーキテクチャ」というものがある。最近自分が日本美術史の授業で聞いた話を踏まえると、われわれエンジニアは式年遷宮をちょっと誤解しているような気がする、という話。いまさらなんなのさ、という気もするが色々調べてしまったので備忘録的に記録しておく。 式年遷宮アーキテクチャ たしか、このあたりの記事がきっかけで Martin Fowler氏の語る“犠牲的アーキテクチャ" 以下など各所で言及されていたように記憶している（おそらく初出は別のブログ記事だと思うのだけれども、現在はアクセスできないようだ）。 青空文庫と式年遷宮アーキテクチャ: 青空文庫200周年に向けて from masayoshi takahashi 一種のミームなので厳密には定義できないが「式年遷宮アーキテクチャ」という言葉に込められた要素は 定期的に作り直す
教育心理学はソフトウェア開発に活用できるか（教育心理学特論を読み終えて） - 勘と経験と読経
数年前からアジャイル開発コミュニティで話題になっていた放送大学のテキスト「教育心理学概論」というものがある。その増補改訂版である「教育心理学特論」を、放送大学大学院の講義15回を通じて読み終えた。そこで、本記事ではソフトウェア開発という観点から同書の感想などについて触れてみたいと思う。 教育心理学特論 (放送大学大学院教材) 作者:芳雄, 三宅,始, 白水発売日: 2018/03/01メディア: 単行本なお世間的には「教育心理学概論」が有名なようですが、私は特論のほうをお勧めします。理由は以下の記事を参照 「教育心理学概論」と「教育心理学特論」を比較してみた - 勘と経験と読経 本書は（ソフトウェア開発関係者に）お勧めなのか？ 自分にとって本書を通じた学びは知的好奇心を満たしたのみならず、今後の仕事への刺激も大きく、満足の高かったものだった。ではソフトウェア開発関係者（私の同僚や同業界人）
2017年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
昨年に引続き、2017年1月～6月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。 2017年上半期に読んだ本を並べてみた 2017年1月～6月に最後まで読み終わった本はこんな感じ。 [asin:B01MA4TKKN:title] 自分を立てなおす対話 一流の育て方―――ビジネスでも勉強でもズバ抜けて活躍できる子を育てる AIと人類は共存できるか? 考えない練習 練習シリーズ フェルドマン博士の 日本経済最新講義 (文春e-book) 想像ラジオ (河出文庫) 実践ドメイン駆動設計 紙の動物園 (新☆ハヤカワ・SF・シリーズ) 日本企業の社員は、なぜこんなにもモチベーションが低いのか？ 仕事に追われない仕事術 マニャーナの法則・完全版 職場の問題地図 ～「で
忙しい人は勉強をしている？ - 勘と経験と読経
以下のブログ記事が面白かった。勉強会に出ないと不幸になるのか。読んで考えたこと。 2013-11-17 ちなみに勉強したから偉いとか、勉強会に参加することが良い事だとも別に思っていない。 忙しい人は勉強をしている？ 以前に参加した勉強会でこんな話をしたことを思い出した。 本当に「忙しいから学習しない」のか？ 実際には忙しい人ほど勉強会などに参加しているのでは？ 忙しい人は、実際には業務をこなしている 『忙しいから勉強するのだ』 この発想ができない人が、いる。 Devlove HangarFlight -BlizzardSailing- に参加して社内内弁慶について話した - 勘と経験と読経 ところで「忙しい」というのはどんな状態のことを言うのだろう。 という形だといまいちしっくりこない。 こんな状態だろうか。 結局は能力が高いか低いか、なのかもしれない。 基本的には「どうやって左から右にシ
Devlove HangarFlight -BlizzardSailing- に参加して社内内弁慶について話した - 勘と経験と読経
2/15に「Devlove HangarFlight -BlizzardSailing-」という勉強会に参加したメモ。気楽に聴講するつもりだったのだけれども後半のFutureCenterセッションではマンマと1テーブル割り当てられてしまったので「社内内弁慶」というテーマで、エンジニアの学習姿勢などについて議論してしまったのであった。 これからの、ソフトウェア作りのために。 様々な企業の活動を支える、SI/受託開発。これからも多くの人たちから必要とされることでしょう。 そもそもソフトウェア作りとは創造的で難しく、刺激的で楽しいものです。 ソフトウェア作りは、多くの課題に直面します。自分には越えがたいと感じる課題、気持ちを砕く制約に遭遇することもあるでしょう。どのような課題を、どのようにして乗り越えていくか。 それを発見し、知恵を出し合うために、DevLOVEは存在します。 今回のDevLOV
会議進行と議事録とメタ視点 - 勘と経験と読経
ちょっとした思いつき。会議進行が下手な人や議事録を書くのが苦手な人は、メタな視点を持てていないからなのではないだろうか。喋っている自分を含めた会議全体を意識してみることについて。 セカンド自分とサード自分 大人タバコ養成講座などで有名なデザイナーの寄藤文平さんの本「絵と言葉の一研究 「わかりやすい」デザインを考える」を読んでいたら、寄藤さんの面白い趣味というかゲームのことが書かれていた。本書では「自分チャンネル」という名前で紹介されている。やり方はだいたい下記の通り。 自分を俯瞰するセカンド自分をイメージする 自分とセカンド自分を俯瞰するサード自分をイメージする この要領で俯瞰する視点を増やしていく 寄藤さんは7人目くらいで吐きそうになってしまうらしい ためしに自分でもやってみたら4段階目くらいで発狂しそうになった。7段階はもう想像だにできない。しかしやってみて気づいたのだけれども、3段階
「デザイン思考と経営戦略」を読んで、わからなかったこと - 勘と経験と読経
主に読書メモ。「デザイン思考」という言葉が巷でそれなりに話題になっているので、「デザイン思考と経営戦略」という本を手にとってみた。非常に内容の濃い本で、いろいろな部分が非常に参考になったのだけれども、ここで語られているデザイン思考はあくまで物理的モノづくり（アトムの世界）が中心になっている気がする。ビットの世界を中心にした働き、はどのように考えればよいのかわからなくなった。 この本を手にとった理由は、以下のスライドを見て気になったから。 デザイン思考による人間中心のイノベーション ちなみに本来の筆者の想定だと「デザイン思考の道具箱―イノベーションを生む会社のつくり方」が初級編で、本書は中級編という位置付けらしい。もちろん「デザイン思考の道具箱―イノベーションを生む会社のつくり方」は未読。 わかったような気がしたこと デザイン思考の方法論としての流れや意図(不連続なイノベーションを探す) 民
要求開発アライアンスでDMBOKの話を聞いてきた - 勘と経験と読経
2012/12/3に開催された、要求開発アライアンスの勉強会に参加した。実際には大いに遅刻してしまったので前半の発表内容はフォローできていないのだけど、いくつか興味深い話も伺えたので整理がてら公開するもの。 アジャイル開発を可能にするエンタープライズ・アーキテクチャ 勉強会の前半部分の発表。講演者の中山さんのご好意により資料が公開されている。 アジャイル開発を可能にするEA 痛恨なのは、この部分の発表についてわたしが遅刻した為にまったく話しを聞けていないということなのだけれども、有志の皆さんのおかげでTwitter実況されているので雰囲気をうかがい知ることができる(いい時代だ)。 発表自体は、9月に行われたE-Agilityカンファレンスの内容である。ただ、このカンファレンスの資料は参加者限りの限定公開になっている。3ヶ月遅れではあるけれどもこの資料が閲覧できることが本当に有難い。 企業シ
ソフトウェア開発プロセスを環境にする - 勘と経験と読経
最近ちょっと考えていること。ソフトウェア開発のプロセス(手順)について。よく聞く「ソフトウェア開発現場の嫌な臭い」の一つに、不適切なプロセス標準化の話がある。過剰なルールや官僚主義は、特にアジャイル開発派がムダなものとして槍玉に上げるものでもある。じゃあ、プロセスは一切要らないのかというとそうでも無い。良いプロセスとは何なのかについて少し考えた。 ルールとしてのソフトウェア開発プロセスの必要性 ソフトウェア開発プロセスは皆が守るべきルールのようなもので、ルールである以上みんながそれに従わなければいけない。CMMIなどでは遵守状況のモニタリングと継続的な改善を行う必要がある。この考え方の前提は「ルールを守らなくてもソフトウェアを作ることができる」ということなのだと思う。 ソフトウェアには物理的制約がほとんど無いので、絶対に守らなければならないルールというものは無い。例えばビルなどの建築物であ
アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経
「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である
ソフトウェア開発における将来要件の扱い - 勘と経験と読経
ソフトウェア開発におけるムダ | Ryuzee.com の記事が面白かった。別にアジャイル開発プロセスに限らず、ソフトウェア開発にはいろいろな無駄がある。身近でときどき出てくる種類のムダとして「将来の再利用性などの要件を折り込む」ということがある（「使わない機能」の一種かもしれない）。「技術的負債」の逆バージョンについて。 ソフトウェア開発における将来要件の扱い よくあるのはこういった話。 将来の機能拡張を考慮したシステムを構築するという「要求」がある。 未来の要件変更を考慮した機能設計をすることが要求される。 未来の要件変更を考慮した汎用性が求められる、といった場合もこのパターンか。 機能拡張時のコスト削減のために、将来の再利用を想定したものづくりが要求される。 アーキテクチャレベルで将来の変更を想定したり、そもそも変更しやすい設計を行うことは可能だ。しかし、上記に上げた要求に対しては「
弾丸が当たったときだけ弾の話をする - 勘と経験と読経
このブログで知ったのだけども、フレデリック・ブルックスの銀の弾丸についてWikipediaにすごく詳細なページがある。知らなかった。というわけで、今回は（みんな大好き）銀の弾丸の話。 そういえば此処にも書かれていたけれども、この本をマネージャ屋で未読なのは罪だと思うよ。 「起業のアイデアやニーズはたくさんあっても技術者の絶対的不足–その解決策は？」 - カレーなる辛口Javaな加齢日記 人月の神話 作者:フレデリック・P・ブルックス Jr.ピアソン桐原Amazon 鉛の弾丸 ブルックスもいいけれども、個人的にはアジャイルと規律にある「鉛の弾」の話もあわせて読みたい。 アジャイル手法も計画駆動型手法も、フレッド・ブルックスが言うところのソフトウェア工学の「狼男」を退治するための「銀の弾丸」の方法論とはなりえない。(中略)アジャイルや計画駆動型のアプローチはどちらも「鉛の弾丸」程度にはなれるか
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
