「人が増えても速くならない」と素朴概念の問題 - 勘と経験と読経
読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第55回。同僚と読書期日を約束することによって消化が捗るという仕組み。過去記事はこちら。 さて、今回取り上げるのは話題（？）の本「人が増えても速くならない ～変化を抱擁せよ～」である。 人が増えても速くならない ～変化を抱擁せよ～ 作者:倉貫 義人技術評論社Amazon非エンジニア（起業家、経営者、マネージャ）向けに、ソフトウェア開発でよく起こる誤解を解くという目的で書かれた本書である。結論から言うと良い本であった。一方でいくつか気になる点もある。そういった事を書いていく。 ソフトウェア開発における素朴概念との戦い 先ほど「ソフトウェア開発でよく起こる誤解を解く」と書いたが、最近勉強している心理学の用語でいうと、この誤解は素朴概念の一種であると言えるのではないかと最近
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
「セキュア・バイ・デザイン」を読んだ（3） #デッドライン読書会 - 勘と経験と読経
読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第41回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。 #40 「セキュア・バイ・デザイン」を読んでいる（２） #デッドライン読書会 - 勘と経験と読経 #39 「セキュア・バイ・デザイン」を読んでいる（１） #デッドライン読書会 - 勘と経験と読経 #38 「Team Topologies」後半読んだ #デッドライン読書会 - 勘と経験と読経 #37 「Team Topologies」前半読んだ #デッドライン読書会 - 勘と経験と読経 #36 「恐れのない組織」読んだ #デッドライン読書会 - 勘と経験と読経 さて、今回は3回にわたって読んできた「セキュア
アラフィフ理系が放送大学の教養学部に入った記録（1年目前期完了） - 勘と経験と読経
2020年4月から放送大学の教養学部「人間と文化コース」に入学して、これまで勉強してこなかった人文系の勉強を始めている。最初の半期が終わったので感想などをまとめてみた。 学期はじめに書いた記事はこちら。 agnozingdays.hatenablog.com 1年目前期の感想 授業は4月からスタートであったが、実際には印刷教材とオンラインサービスのIDが発行された3月から受講を開始した（放送内容はスタート時点ですべて視聴可能） 毎週末に受講科目を視聴した。科目に応じて予習または復習を実施してた（詳細は後述）。 5月に通信指導(ミニテストを実施して提出する)、7月に試験を実施。なお試験は当初、各地にある学習センターでのオンサイト試験を予定していたが在宅試験への切替となった。 在宅試験はCBTというわけではなくて、単に自宅で試験問題を解いて解答用紙を郵送するだけ。なお元々オンサイト試験でもテキ
アフターコロナ時代を想定して分散アジャイル開発について調べてみた（Agile Software Development with Distributed Teams） - 勘と経験と読経
ウィズコロナなのかアフターコロナなのかはよくわからないけど、今回の新型コロナ感染拡大の事態を踏まえて分散アジャイルについての勘所について整理しようと思って、いろいろな調べてみた。世の中にはTips集と精神論ばかりが溢れている気がする。知りたいのは戦術だ。先人たちの知見から学ぶことはあるのだろうか？ Agile Software Development with Distributed Teams: Staying Agile in a Global World 以前に「A Practical Guide to Distributed Scrum」という本を読んでいる（DAD本で紹介されていた）。 agnozingdays.hatenablog.com この本は基本的に「複数のグローバルなサイトに分散されたチームでのスクラム」について書かれていたと記憶している（若干自信はない）。今回読みたい
2016年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経
昨年に引続き、2016年1月～6月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。全般的には旬な本をぜんぜん読んでいないな・・・ 2014年に読んだ68冊からお勧め図書を選んでみる(文芸、ビジネス、技術書) - 勘と経験と読経 2015年上半期に読んだ本のふりかえり - 勘と経験と読経 2015年下半期に読んだ本のふりかえり - 勘と経験と読経 2016年上半期に読んだ本を並べてみた View this post on Instagram A post shared by Kent Ishizawa (@agnozingdays) View this post on Instagram A post shared by Kent Ishizawa (@agn
技術士（情報工学）の勉強法 - 勘と経験と読経
ソフトウェア開発の分野では比較的マイナーな資格ではあるが、技術士（分野は情報工学）の資格を取得したので参考までに勉強法を公開する。技術士という資格についてはWikipediaも参照のこと。ソフトウェア開発の分野では様々な資格や試験があるが、知識や能力だけではなく、特に「技術者倫理」や「継続的な資質向上に努める」といった姿勢が評価されるのが特徴である。私は尊敬するエンジニアが技術士だったことが主な受験動機だつたが、ITエンジニアのひとつの目標としてチャレンジする価値は十分にあると思う。すくなくとも思考の訓練にはなる。 受験検討 とりあえず試験の仕組みや雰囲気を以下の書籍で確認。 新版 技術士補試験に合格する本 作者:福田 遵日本能率協会マネジメントセンターAmazon 挑戦するとなると最短でも2年以上のチャレンジとなるので、勉強を始める前にどのような勉強を今後していくのかを確認するのが重要だ
価値創造と契約 - 勘と経験と読経
XP祭り2014というイベントで発表された「俺の価値創造契約」というスライドが話題になっている。株式会社永和情報システムマネジメントさんが行っているソフトウェア開発の新しい契約形態が苦戦しているという話。いくつかの関連記事を読んで思ったこと。 俺の価値創造契約 永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance photo by TeryKats 公開されている事業計画と並べて読む 永和情報システムマネジメントさんのアジャイル事業部では、今年度の事業部計画書が公開(!)されている。こちらもあわせて読むと興味深いと思う。 http://www.esm.co.jp/agile/business_plan_esm_agile_div_35th.pdf うまくいっている(ように見える)ソニックガーデンさんの「納品のない受託開発」との大きな差異はやはり、 『仮説：シ
いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経
今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型本 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍（most thoroughly useful book）」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛
目標設定ゲーム - 勘と経験と読経
目標設定とか会社の評価制度に関するブログの記事をいくつか見た感想。個人的にはこの手の制度は「殴ったら手が腐る」ものだと思っている。ゲームとして考えたらいいんじゃないだろうか。 ITエンジニアの評価制度をどげんかせんといかん - ぐだぐだ言ってないでコードを書けよ、ハゲ。 目標管理シートドリブン開発はくそ - razokulover publog 目標管理制度（笑） - カレーなる辛口Javaな加齢日記 「目標による管理」そのものが理屈として成立しにくい この手の評価制度の根底にはドラッカーの「目標による管理」が根底にあるのだと思うのだけど、たぶんこれを適用するシチュエーションから間違っているような気がする。 目標による管理 - Wikipedia Wikipediaの記事を読むだけでイマイチ感が満載。 前提として「組織の大目標が個人レベルまで分割できる」必要があると思うのだけれども、組織の
社内内弁慶について - 勘と経験と読経
割と気軽に使っていた「社内内弁慶」というキーワードについてのまとめ。ブログ等で反応いただいたり、それを読んで考えたことなど。発端のエントリはこちら。 社内勉強会をやらない理由 - 勘と経験と読経 社内内弁慶の定義 社内内弁慶という単語は以下の過去記事で最初に触れたのだけれども、「オレオレプロフェッショナル」というイメージで使っている。 Devlove HangarFlight -BlizzardSailing- に参加して社内内弁慶について話した - 勘と経験と読経 『自所属組織の中ではそれなりの立場・肩書きで行動する割に社外に出て行かない人、のことをイメージして書いた言葉。オレオレプロフェッショナルのこと』 どの業界でもそんな人は一定割合いると思っている。ただ、技術進歩が早くまた知識体系がうまく整備されていないソフトウェア技術者の世界では、社内内弁慶でいることは危ういのではないだろうか。
「システム設計の謎を解く」の感想 - 勘と経験と読経
書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。 以前に書いた記事はこちら 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経 アジャイルフリーでテクノロジーフリーな基本設計の本 本書は一言で言うとそんな感じ。 要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている） アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度 詳細設計についても範囲外 オブジェクト指向設計については軽く触れる程度 アジャイル開発も触れる程度 この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。 顧客の立場からすると アーキテクチャの
社内勉強会をやらない理由 - 勘と経験と読経
ときどき「社内勉強会をやってほしい」という事を言われることがあるのだけれども、基本的には断るようにしている。その理由について。 社内勉強会は言われて始めるものじゃない 「社内勉強会をやってほしい」と人に言われても基本的には断っている。こういったことを言うのは自分の上司や関連部門の偉い人に多い。言う人は、きっとこんな期待をしている。 メンバーの底上げやレベルアップ 生きた知識を現場間で情報共有する メンバー間の交流でより良い結果が得られるようになる でも実際に言われるがままに勉強会を企画しても、 人が集まらない 発表者が偏る 発表者の負担が増えていき、開催されなくなる ということになるのがわかっているから、実施しないのだ。 どうしてこんな事が起こるのかというと、単純にマーケットが小さすぎて、企画が成立しないのだからだと思っている。そもそも、コミュニティ活動を真っ当に実施できているエンジニアは
アジャイル開発モデルは準委任契約を結べば良いという誤解 - 勘と経験と読経
最初に注意書きを。本エントリは法務面で専門家ではない私が個人として意見見解を述べているものであり内容を保証するものではない(他のエントリもそうなのだけれども)。アジャイル開発に関する諸契約については専門家(自組織の法務部門等)に確認していただきたい。なんとなく本邦のIT業界には「アジャイル開発モデルは準委任契約を結べば良いという誤解」があるような気がしている。今年、IPAから『日本におけるアジャイル開発に適した契約モデル案』などが出てきているので、それを改めて読みながら論点を整理したいと思った次第。 請負、準委任 いろいろ整理する前提として、請負、準委任というものについて簡単に整理しておく。私の理解が誤っている可能性もあるのでお気づきの点があれば指摘いただきたい。たぶんポイントは「民法上(契約法)」と「労働者派遣法」の2つのスタンダードがあるという事だ。 民法上(契約法)の「請負、準委任」
顧客レビューのうまいやり方 - 勘と経験と読経
お客様から発注されたソフトウェアを請負で開発する場合に悩ましいのが、顧客(発注者)レビューの扱いだ。そもそもソフトウェアの設計をレビューすること自体が難しいアクティビティである。その難易度に加えて、ソフトウェア開発の専門家ではない顧客(発注者)に要求や設計をレビューするのだから、相当難しい。結果として、大量の顧客(発注者)指摘事項が出てきて途方に暮れる、というのがソフトウェア開発の現場でよく見る風景だ。顧客(発注者)レビューのうまいやり方というのは無いのだろうか。 指摘に苦しめられた（？）特許庁システム 膨大な指摘で苦戦する話、で思いだすのは2012年初めに報じられた特許庁基幹システム刷新中止の件だ。公開されている議事録別紙資料などを見ると目眩がするようなグラフが書かれている。スライド9ページあたり。 特許庁情報システムに関する調査委員会報告書(技術検証チーム)ご指摘に関する状況について(
ソフトウェア開発プロジェクトは「負ける」宿命なのか - 勘と経験と読経
「どうやったらプロジェクトの失敗を防げるか」について話していたら、後輩の一人が面白い事を言った。「システム屋は最初から負けている」。くわしく聞くと、こういうことらしい。 ソフトウェア開発プロジェクトの総予算は早い段階で確定していて、増額は困難である。 早期に全ての要求を見通すことは不可能であり、プロジェクトを始めていくとスコープは少しづつ増えていく。原価も増えていく。 プロジェクトを開始した以上、途中でバスを降りることは不可能である。収益が悪化しても走り続けるしかない。 故に、われわれシステム屋は「負ける」宿命を負っている。 いろいろとツッコミどころはあるのだけれど、想う所を整理してみたい。 じゃあビジネスアジャイルだ、ということではない アジャイル脳的な反応が容易に予測できる。 最初に大きく計画し一括で開発しようとすること自体が誤り。リスクを極小化しビジネス価値を最大化するために、アジャ
朝会を進捗会っぽくしない - 勘と経験と読経
朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれることはある。 朝会のミニ進捗会化 デイリースタンドアップ／スクラムはスクラムマスタのためのものではない そもそも朝会のようなコミニュケーションの場は特殊で、（日本人にとって）普通に学校や社会で学ぶような機会はあまりないと思う。いちばん経験するのはトップダウンの情報共有（先生や上司の話を聞く）かボトムアップの報告（上司やリーダーに報告連絡）だから、放っておくと朝会もそうなりやすい。 うまくいっていない朝会だと、そもそもメンバーの会話を他のメンバーが聞いていない。というか、自分が発言するまでは「なにを発言するか」ばかりを気にしているし、自分の番が終わるともう終わっ
ソフトウェア開発における多能工の問題 - 勘と経験と読経
ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェクトが大規模より中小規模・短工期にシフトしていることが、専門家(単能工)による開発を難しくしつつある状況も、開発エンジニアの多能工化を後押ししている。しかし、多能工によるソフトウェア開発はベストプラクティスかというと、そうではないと思う。多能工アプローチの問題点について考察して望まないと、思わぬところから足をすくわれる事がある。 なぜ多能工なのか？専門家(単能工)はなぜだめなのか？ ファクトリー型アプローチは一時期流行し、いまなお一定の価値をもってはいるが、ほとんどのアプリケーション・ソフトウェアの開発には、現在これよりも有効な手法が存在している。 ソフトウ
アジャイル手法によって生産性が上がりプロジェクトは成功するか？（いいえ） - 勘と経験と読経
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？ その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
