サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
qiita.com/kazuo_reve
はじめに 派生開発推進協議会(AFFORDD)の皆様のお力で清水吉男さんの「"硬派"のホームページ」を復活させていただけました。感謝申し上げます。 清水吉男さんの「"硬派"のホームページ」には、多くの有益な記事があります。 この中から私が個人的におすすめする記事を、12件選び、まとめておきます。 "硬派"のホームページ おすすめ記事 「1番」を目指すことの意義 シェアでも利益でも構いません。あるいは絶対額では規模の大きな先発企業に叶わないというのなら「率」でも構いません。「顧客満足度」でも構いません。仕事の仕方でも、残業時間の少なさでも構いません。とにかく「1番になる」という目標の存在が、そこに居る人たちの脳を刺激します。道を歩いていても、何かを考えようとするはずですし、そのような“思い付き”を大事にしたいという思いから、歩きながら記録するための「道具」を使う工夫も生まれてきます。 自分を
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム,「派生開発におけるスペックアウト手法の提案」,派生開発カンファレンス2015,2015 http
はじめに @kaizen_nagoyaさんと出会ってから、たくさんの知見を教えていただいた。 私が重要だと思い、実践し、効果を確認した考え方を、感謝の意を込めて「小川メソッド」と名付けまとめておく。 私の経験則をもとに重要な考え方を選択をしているため、@kaizen_nagoyaさんの考えられている優先度とは異なる可能性が高い。 小川メソッド 2016年に考えていた小川メソッド 3つやる、もつ、使う 最初は50点でよい DoCAP 図にする 上から見る 当時、この考え方をFacebookで展開したところ、日産自動車のエンジニア(鈴木卓馬氏)から、「うちのチームの標語に限りなく近い(驚。」と驚かれた。 2021年にまとめなおした小川メソッド 以下の5つの考え方は、実践し効果を確認している。 DoCAP 1人作業のあとに班作業 30点を目指す 逆に考える 参考文献駆動執筆 将来小川メソッドに加
はじめに 私のプロジェクトでスクラムを実施するうえで参考になった資料・記事・書籍をまめておきます。 以下の項目に分けてまとめておきます。 アジャイル スクラム全般 スプリントレビュー モブプログラミング インセプションデッキ おまけ 1. アジャイル Jonathan Rasmusson,「アジャイルサムライ−達人開発者への道−」,オーム社,2011 重要なことは、次の4つだと思った。 早くフィードバックを得る 仕事は小さくする QCDではなくスコープを調整する 共有と協力 平鍋健児,「初歩から学ぶアジャイル開発入門」,ET/IoT 2016 SEC先端技術入門ゼミ,2016 @Koki_jp,「アジャイルかウォーターフォールか、どちらが品質を「保証」できるのか -トヨタの自工程完結に学ぶソフトウェア開発-」 スクラムでいうと、スプリントを工程と位置づけるのは良さそう。工程間流出欠陥=スプ
はじめに 形態素解析を活用した推敲の方法「形態素ベースドレビュー」を提案する. [2]「数学文章作法 推敲編」では,多様な読み方で多様な推敲を行うのが良い方法であると述べられている. 提案手法は,多様な推敲の一つとなりうる. 手法の対象とする文書は,要求仕様書とする.ただし,論文などの文書にも適用可能と考えられる. 検出したい問題 提案手法は,以下の問題を解決することを目的とする. あいまい表現により,誤解釈が発生する 統一されていない表現により,検索で関連文章を抽出できない あいまい表現 [3]「情報伝達型の日本語文章に現れるあいまい表現の類型化とその改善例」で,あいまい表現の類型が示されている.あいまい表現の類型は大きく「文レベルのあいまいな表現」「語レベルのあいまいな表現」「意味の通じない表現」「表現の意味する範囲が広すぎる「あいまいさ」」に分類されている.提案手法で検出したい問題は
はじめに チェックリストは、組織にたくさんあります。 チェックリストは、世の中にもたくさんあります。 Qiitaでも、「チェックリスト」という単語で検索をかけると10000件以上の記事がヒットします。 先人たち(自分も含めて)が、自分の知識・経験を伝えるために、たくさんのチェックリストを作ってくださっています。ただし、それを受け取る側としては、うまく活用できていない場面が、たくさんあります。 そんな中、私たちのプロジェクトで、チェックリストをうまく活用するため、やったことを記録しておきます。 チェクシートについて思うこと列挙します。 与えられたチェックリストはうまく使えない チェックリストは自分で作るのが一番良い チェックリストはチームで作るのも良い 先人に作成していただいたチェックリストを無駄にはできない 与えられたチェックリストはうまく使えない 「使え!」と与えられたチェクリストは「使
はじめに Qiitaで私が集めた有益な情報・知見のまとめ記事をいくつか投稿してきた。 記事へのアクセスをしやすくするために、そのまとめ記事のまとめ記事を作っておく。 継続的に更新予定。 まとめ記事のまとめ 記事は、代表的なタグで分類をしておく。 新人プログラマ応援 プロジェクト管理 アジャイル プロセス改善 レビュー なぜなぜ分析 データ分析 ソフトウェアテスト ソフトウェア工学 ポエム
はじめに 私がマネージャーの立場で工夫したことをQiitaでいくつか記事にしてきた。 その工夫のまとめ記事を作っておく。 マネージャーの立場で工夫したこと チームビルディング 圧をかけない ふりかえり メンバから”継続して欲しいこと”を聞く 計画立案 見積り 段階的詳細化とPFD 進捗管理 アンブロック リスク管理 オニオンモデル風の図&プロセス図&未来予想図の活用 予兆を掴む 知識管理 ナレッジスタッフを中心としたニーズ駆動知識共有アプローチ 検証 チェックリスト活用法 レビュー技法(リーディング技法) エンジニアリング USDMの活用 形態素解析を活用した推敲 コードメトリクスの活用 最悪実行時間計測 トラブルシューティング(デバッグ) 関連記事
はじめに トム・デマルコの書籍「ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解」に、以下の一文があります。 第7章 プレッシャーの代償 プレッシャーはパフォーマンスとまったく無関係ではないが、私たち多くが考えるほど、少なくとも管理者になってある時期に考えるほど重要なものではないことは確かである。 優秀な管理者は、プレッシャーをめったに使わず、また長期間にわたって使うこともない。 また、ティム・リスターの言葉に以下があるそうです。 人間は時間的なプレッシャーをいくらかけられても、速くは考えられない これに関連する、マネージャーの圧について、教えていただいたこと・議論したことをまとめておきます。 教えていただいたこと 2019年くらいに、松尾谷徹さん・小川清さんに、マネージャーの行動や心理的安全性について教えていただき、マネージャーにとって、以下は重要な考え方だと思いました。 ※注意
はじめに Vモデル(V字モデル)について、勘違いしていたと思ったことを記録しておく。 ただし、ここに記録していることも勘違いの可能性もある。 最初に、勘違いを気づかせてくださったのは、小川清氏と白坂成功氏だったと記憶している。 V字モデル Wikipediaでは以下のように説明されている。 V字型に表される概念図の左側はシステムの仕様を記述していく流れを示している。右側はテストの流れを示す。 世の中のVモデルの図を見ると、左上から真ん中下に、真ん中下から右上に、矢印が記載されていることが多くあると感じている(統計的な確認は未実施)。 勘違いしていたこと 『Vモデルは順序を示している』 「Vモデルは、左上から真ん中下に、真ん中下から右上の順番に、開発を行うことを示している」と思っていた。 しかし、今はこれが勘違いだと思っている。 参考メモ 白坂成功氏の資料 参考文献[1]で、白坂成功氏が、以
はじめに 私にとって有効だった学び方を5つ紹介します。 手を動かす 比較する 読書・セミナー受講 論文・記事を書く コメントをする 学ぶ対象は、技法・手法・方法・アプローチ・メソッド・道具・ツールなどと呼ばれるようなものです。 学び方の説明 1. 手を動かす 小池利和さんからは、何かを学ぶときに、「手を動かしなさい」と教えていただきました。 書籍「ソフトウェアメトリクス統計分析入門」に以下の言葉があります。 学び方としては、実践→理論→考察→実践→・・・というスパイラルで徐々に深めていくのが得策です. 私にとっては、理論を体系立てて知るより前に、とりあえずやってみるということが、物事を学ぶ上でとても有効でした。 人は、自分の経験を結び付けながら、理論の理解を進めるのだと思っています。経験がなければ、結び付けるものがありません。 先日、fromdusktildawnさんの以下のツイートに多く
はじめに 今更ながら、GitHubを使い始めた。 GitHubを使い始めたときに参考にさせていただいた記事をまとめておく。 トラブルシューティング等を自分でまとめようと思ったが、皆様がまとめていただいた記事で、ほぼ何のトラブルもなく使い始められた。 今後も、GitHubを使いながら、参照させていただいた有益な記事等を随時整理していく。 参照記事 チュートリアル 意味が分からなかったことの解説記事 トラブルシューティング これから参照させていただこうと思っている記事 MS Officeファイルの管理 論文執筆 謝辞 記事を執筆していただいている皆様に感謝申し上げます。
はじめに コードの不吉な臭い(Code smell)という言葉があります。 仕様や設計にも不吉な臭いはある気がします。 仕様スメル・制約スメル・設計スメル・コードスメルを独自に整理していきます。臭いを検知するための道具・方法も検討していきます。 皆様の嗅いだことのある不吉な臭いも教えていただけますと幸いです。 先行研究 参考文献[1]「新装版 リファクタリング―既存のコードを安全に改善する―」に示されている『コードの不吉な臭い』 重複したコード(Duplicated Code) 長すぎるメソッド(Long Method) 巨大なクラス(Large Class) 長すぎるパラメータリスト(Long Parameter List) 変更の偏り(Divergent Change) 変更の分散(Shotgun Surgery) 特性の横恋慕(Feature Envy) データの群れ(Data Cl
はじめに 今までに、論文・発表資料を作成し、以下のシンポジウムで発表する機会をいただきました。 ソフトウェア品質シンポジウム ソフトウェア・シンポジウム SPI Japan 論文・発表資料を作成を作成するときに、多くの皆様にご指導いただきました。本当にありがとうございます。 皆様からのご指導を受けた結果、論文・発表資料を作成するときに意識していることをまとめておきます。 意識することは変わると思いますので、随時追記・整理していきます。 意識していること 論文・発表資料共通で意識していること 内容 自分のプロジェクトで見受けられる問題を扱う。 自分のプロジェクトで効果を確認する。 解決する課題は小さくする(小さくてもいい)。 盛りだくさん内容を詰め込んだら、「Busy」とご指導いただいたことがあった。 大きすぎる課題にしたときに、「あきらめなさい」とご指導いただいたことがあった。 自分の経験
はじめに 組込みソフトウェア開発において、アーキテクチャ設計のプロセスを改善をするために(アーキテクチャの評価方法の考案などをするために)、参照した論文や資料や記事をまめておきます。 以下で分類して、論文や資料や記事を整理します。 設計者 設計原則 設計事例 設計プロセス 設計評価 設計改善(リファクタリング) 1. 設計者 山田大介,「連載コラム アーキテクトへの道」 「ソフトウェアアーキテクトが知るべき97のこと」 2. 設計原則 @hirokidaichi,「技術選定/アーキテクチャ設計で後悔しないためのガイドライン」 @hirokidaichi,「なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか」 「The #1 bug predictor is not technical, it's organizational complexity」,2019 @MinoDriv
はじめに 昔(2018年12月くらいに)、体制変更で業務が変わるかもしれないので、マネージャーの役割を引き継ごうとしました。 今まで取り組んだことで、価値のないこと(価値を感じてもらえていないこと)は自分がいなくなれば、自然とやられなくなります。 今まで取り組んだことで、価値があることでも、やる人がいなくなれば、やられなくなる可能性があります。 そこで、メンバに『私が抜けても継続して欲しいことある?』と質問してみました。 自分が取り組んだことで、メンバに価値があったこと/価値を感じてないことがよくわかり、有益でした。 自分は価値があると思っていたのに、意見がなかったこともあります・・・ 継続してほしいこと一覧 情報共有 みんなが見えるところに日報を書く 日報を利用し困っていることの打ち上げ チームまたいだ全体の情報共有会 協力会社リーダも情報共有会に参加 slack(Mattermost)
はじめに マネージャー・リーダーの私にとって有益な知見が得られた書籍を、簡単な所感とともに、まとめておきます。 随時、更新していく予定です。 ここに示した書籍は、マネージャー・リーダーの経験を得た後に、自分の経験を頭に置きながら、読んでみたほうがよいと思います。 経験がない状態で、ここに示した書籍を読んでも、得られる気づきなどは少ないと思います。 書籍は、「以下の順で読むとよいかもしれない」という順に並べてみます。 また、おまけとして、以下の情報もまとめてみました。 マネージャーとして意識的に実行していること マネージャーの立場で工夫してみたこと 書籍ではなくメンバから学んだこと 書籍一覧 「先端技術者のためのトラブルシューティング技術―組込みシステムの品質問題をこの一冊で原因究明」,金子 龍三 金子龍三さんの講演は楽しい、刺激がある。経営者やPMは、是非一度話を聞いてみるみよい。トラブル
ワークショップ「ソフトウェア開発におけるHAZOP入門」を3回開催した。 その結果(参加者の所感)を記録する。 開催シンポジウム ソフトウェアテストシンポジウム(JaSST : Japan Symposium on Software Testing)でワークショップを開催させていただいた。 http://www.jasst.jp/ JaSST'18 Tokai(参加者:13名) JaSST'19 Tokai(参加者:8名) JaSST'19 Shikoku(参加者:19名) 参考文献 [1]小川清, 「一人HAZOPを組み合わせた効率的な分析作業」, WOCS2011, JAXA/IPA, 2011 [2]日高隆博, 山崎二三雄, 中本幸一, 本田晋也, 高田広章, 「HAZOP分析によるソフトウェア異常動作検出条件の導出手法の提案と実装」, 組込みシステム(EMB) Vol.2009-E
背景 にしさんの以下のツイートをきっかけに、「規模あたりのテストケース数」というメトリクスについて考えてみた。 https://mobile.twitter.com/YasuharuNishi/status/1203344174864453634 規模あたりのテストケース数はもはや意味をなさないという意見に賛成する人は、その理由を最低2つと、じゃあ何をするかを答えられるようにしておくこと。ここ試験に出すからな。 — Yasuharu NISHI (@YasuharuNishi) December 7, 2019 (注意) 規模はソースコードの規模であることを前提とする。 "もはや"ではなく、"以前から"意味をなさない理由とした。 問いに対する考え 「規模あたりのテストケース数」が意味をなさない理由 その1:有効なアクションを起こしにくい 前提:しっかりテスト設計をしている テスト観点ツリー
個人的にソフトウェアテストに関して有益(後から見返したい)と思った論文・資料を列挙しておく。 随時、追加・更新していく。 [1]秋山浩一,「テスト技法の位置づけとテストの十分性」,JaSST'09 Tokai,2009 http://jasst.jp/archives/jasst09n/pdf/S2.pdf この講演で初めて「品質コスト分析」を知った。テスト技法の全体象を教えていただいた。 [2]鈴木誠,「品質判定マップによる人員配置とテストマネジメント」,JaSST'09 Tokai,2009 http://jasst.jp/archives/jasst09n/pdf/S3-2.pdf 「品質判定マップ」という仕組みは、すごく面白い。活用できそうと感じた。その後、活用する場面に出くわしてはいない。 [3]松尾谷徹,「テストから観た実体のモデリングと実装構造の評価~ 検証指向設計の実現に向
個人的にプロセス改善に関して有益(後から見返したい)と思った論文・資料等を列挙しておく。 随時、追加・更新していく。 論文・資料 清水吉男,「硬派のホームページ」 清水吉男,「Index of "Software Process について"」,2006 https://affordd.jp/koha_hp/process/Proc.Index.html 清水さんがSoftware ProcessとCMMについて語られている。 清水吉男,「これまでの「標準化」の間違い」,2003 https://affordd.jp/koha_hp/process/Proc.WhyStd.html 「プロセスを設計する能力」の必要性について述べられている。 清水吉男,「PFD(Process Flow Diagram)の書き方」,2009 https://affordd.jp/koha_hp/process
見積りツールが以下のサイトにある。 http://itref.fc2web.com/management/cocomo.html CoBRA見積りモデル[5] 独フラウンホーファー財団実験的ソフトウェア工学研究所協会(IESE)から発表された。 考え方 規模がほぼ同じでも、かかる工数に違いがある。 見積り式 実績データに照らして、変動要因とその定量化を検証し、αを計算。 コスト変動要因のオーバーヘッドを考慮。経験豊富なPL等の熟練者の知見を基に、変動要因とその影響を定量化。 見積り手順 規模の推定 変動要因の影響度の評価 見積りの実行 CoBRAモデルの構築手順 変動要因の抽出・定義 実績データの収集 モデルの構築・改善 規模の計測補法 ファンクションポイント[6] 概要と特徴 ファンクションポイントは、ソフトウェアの機能の大きさを表す指標で、誰が計測しても同じ値になるという特徴があります
次のページ
このページを最初にブックマークしてみませんか?
『@kazuo_reveのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く