ソフトウェア 変化に適応する！システム機能分解の妙
システムの機能をどのように分解すればよいかという点について、これといった正解や法則が見当たらず悩ましい。ひとつの視点として、適切に機能分解されていると変更に対して全体を改造しなくても「組合せ」を変えるだけで容易に対応が可能となる。
ソフトウェア
ソフトウェア ソフトウェア あらゆる要件の組合せを想定せよ！
要件を整理する段階でどれだけの組合せを想定できるかが、その後の成否を大きく左右する。「あらゆる要件の組合せを想定」するのは、実はそれほど難しもなく、特別な能力が必要なわけでもない。要件を5W2Hで整理して、これらのケースに条件成立と不成立のケースを掛け合わせればよい。
ソフトウェア ◆アジャイルなウォーターフォールのすすめーアジャイルに向けて
現在、ASDの適用率も10%以下である。いずれも成功事例として注目を集めているものの、実際に適用するとなると様々な障壁に直面する。また、新しい方式が全ての環境下で、全ての問題を解決できるわけではない。実際にやってみなければわからないことも沢山ある。それでも改善への一歩を踏みださなければ、明日はない。“障子を開けてみよ、外は広いぞ”(豊田佐吉)
ソフトウェア ◆アジャイルなウォーターフォールのすすめーウォーターフォールからアジャイルへ
WFDを採用してきた組織がASDに安全に移行するには、WFDの枠組みを基にASDのプラクティスを段階的に取り入れることである。過去の財産を全て捨てる必要は無く、意識改革と温故知新や永続的な改善でWFDの上にASDを積み上げることは可能であり、そうすることがより安全にASDに移行することを可能とする。つまり、「アジャイルなウォーターフォール」への斬新的・継続的な改善である。
ソフトウェア ◆アジャイルなウォーターフォールのすすめーはじめに
従来のWFDの課題を解決するとして、ASDが注目されている。しかし、一方で多くのソフトウェア組織がWFDを採用しているという報告もある。また、ASDを試行したものの失敗してWFDに回帰する例もある。その結果、（特に大規模開発で）ASDに懐疑的になり、有益なプラクティスに耳も貸そうとしない。
ソフトウェア ◆アジャイルなウォーターフォールのすすめー要約と目次
アジャイル開発では、計画が不要で変更はいつでも自由に顧客が要求できるなど極端な考え方がされてしまうことがある。そのため、ウォーターフォール開発（以下、WFD）からアジャイル開発（以下、ASD）への移行を敷居の高いものやリスクの高いものと感じたり、試験的に適用して失敗したりするケースも少なくない。そこで、ウォーターフォール開発をベースとしながらアジャイル開発の要素を少しずつ取り入れ漸進的な改善に取り組むことを提言する。
ソフトウェア 情報の最小単位は単語 単語の正確な理解がキモ
どんなに大きな情報システムであっても。扱う情報の最小単位は単語。単語と単語の組み合わせが様々な意味を表す。大きな情報を塊のままなんとなく理解したような気になっているのが一番危険！取り扱う情報を最小単位の単語に分けて認識合わせする必要がある。
ソフトウェア “技術力を活かすための”業務知識がシステムエンジニアに必要なわけ
システムエンジニアには技術力を活かすための業務知識が必要である。優秀なベテランのシステムエンジニアでも業務知識が不足していたために性能を改善することができなかった。例え、業務知識があってもシステムズエンジニアリングに活かせなければ宝の持ち腐れになる。
ソフトウェア 要件の裏を取れ！
刑事ドラマで事情聴収した内容の事実確認を「裏を取れ！」という。同様にヒアリングを主体としてシステム技術者が要件定義を行う場合、要件の事実確認を怠るべきではない。「裏を取れ！」はやはり重要である。運用試験以降にあるはずのデータが無いことが発覚すれば、大きな手戻りが発生する。それを思えば「裏を取る」手間を惜しんではならない。
ソフトウェア 無欠陥より価値創出を！
日本のものつくりは高品質。これと同じようにソフトウェアにも求めすぎていないだろうか。無欠陥なソフトウェアを作ることは難しいのも事実。それより新しい価値を創造することを主眼にアジャイルに作るのが得策ではないだろうか。完璧を求めすぎず固執せず、８０点の完成をめざそう。