IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
今回は前回「セル生産方式+アジャイルという枠組み」のセル生産方式+アジャイルに続いて、制約理論+アジャイルという枠組みを考えてみる。参考にしながら読むのは以下の書籍だ。ただし制約理論に関してはこれ(「ザ・ゴール」)は代表的な1冊にすぎず、さまざまなトピックに関して多くの書籍が出版されている。 今回参考にするのは以下の3冊である。 「アジャイルソフトウェアマネジメント」(David J. Anderson(著)、宗雅彦(翻訳)、前田卓雄(翻訳)、日刊工業新聞社)(残念ながら原著のせいか、翻訳のせいか、はたまた読者たる筆者の能力不足のせいか、解読には若干の困難を伴う) 「ザ・ゴール――企業の究極の目的とは何か」(エリヤフ・ゴールドラット(著)、三本木亮(翻訳)、ダイヤモンド社) 「目標を突破する実践プロジェクトマネジメント」(岸良裕司(著)、中経出版) 筆者は制約理論の専門家ではないので、記述
概要 今回から数回に分けてゴールドラットの論理思考プロセスを紹介しよう。ゴールドラットは制約理論(TOC, Theory of Constraint)で有名だ。数年前に日本でも紹介されて話題になった「ザ・ゴール」[1]という本をご存知の方も多いのではないか?論理思考プロセスは制約理論に基づくシステム変革案を現場に導入していくためにゴールドラットによって考案された6つの図式からなる分かりやすい手法だ。今回はまず制約理論のポイントを紹介し、論理思考プロセスの構成と現状分析ツリーを説明する。現状分析ツリーは論理思考プロセスで最初に用いられる図式で、人間活動を含めたシステムのボトルネックとしての好ましくない問題の根本原因を発見する手法だ。 制約理論 制約理論は制約条件の理論とも呼ばれる。もともと製造業の生産プロセスを全体最適するために考案された理論である。生産プロセスを構成する各プロセスごとに最適
ソースコードを書く時、スキルの低い人ほどバグが入ったコードを書きやすい。 しかし、ソースコードレビューで発見されたバグの数を元に、ヤバそうなモジュール(やエンジニア)を知ろうなどと、エンジニアのスキルを評価しようとするのは、止めた方が良い。 なぜなら、バグの多さは、エンジニアのスキルだけに依存するわけではないバグを隠そうとし、適切なレビューが行われなくなる可能性がある ■バグの多さとエンジニアのスキル 一般的には、バグが多い→エンジニアのスキルが低い、と見られがちだが、レビュー時にバグの発見数が多い原因は他にも考えられる。エンジニアのスキルが本当に低い。そのモジュールはもともと複雑度が高く、バグになりやすい。プレゼンがうまいので、バグが見つかりやすい。(「このへんがあやしいので、重点的に見てください」など)レビュアーのスキルが高い。 このように様々な原因があり、バグが多く発見される事とエン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く