“日本語として意味の理解が不可能な項目のこと”
特に以下の事柄に起因する場合を指し，目的不明確と区別される．
図[日本語不良（5行目）が指摘できるチャート]のチャートには日本語不良と指摘できる項目が1箇所（5行目）ある．
チャートの5行目「希望人数の指定座席の結果を表示する」は，日本語として意味の理解が不可能である． 実はこのチャートには他にも不良 (6)が あるが，今回は指摘しないことにする（余裕のある読者はレビューをしてみると良いだろう）．
列車座席予約システムのHCPチャートでは，以下のような記述が具体例 (7) として挙げられる．
こうした記述は，項目の目的を読み取る以前の問題として，理解不可能な日本語であるため，日本語不良と分類される．
節[目的不明確]で解説する 目的不明確は，項目に記述されている日本語としての意味が通ることを前提としている．日本語不良は， あくまで日本語として意味の理解が不可能と判断された項目が属する分類であることに注意せよ．
しかし，ある項目を日本語不良と分類するか，目的不明確と分類するかの判断が難しいことが多々ある． 図[日本語不良と目的不明確の関係]のように，日本語不良は目的不明確の一種であると考えることができるためである． 節[定義]でも述べたように， 文法上の誤りや，一般的でない単語や造語の利用に起因する重度の目的不明確 を特に日本語不良として分類し，残りは目的不明確でないかを吟味すると良い． 項目が何らかの事情で書き途中であるといった場合等は，日本語不良に分類することで， 多くのケースの不良に対応することができる．
日本語不良は，初心者が作成したチャートに多く見られる． 初心者はチャートの構造や記法ばかりに注意が向くのため， 各項目の意味が明確に第三者に伝わるかという点についての思慮が浅くなる傾向がある．
自分の作成したチャートを他人にレビューしてもらう機会が一回でもあれば，初心者の意識は大きく変わり，使用する用語や， 日本語の記述に注意を払うようになる． つまり，常に他人の視点に立ってチャートを自己レビューを行うことが，日本語不良を防ぐための唯一かつ強力な方法である．
“目的が明確でない項目のこと”
指摘対象となる単一の項目の内容だけでなく， 一つ上位の階層に記述された項目（目的）を踏まえても，目的が明確でない場合を指す．
図[目的不明確（「メッセージの表示」）が指摘できるチャート]のチャートの「メッセージの表示」という項目は目的不明確と指摘できる．
実はこのチャートには他にも不良 (8)が 指摘できるが，今回は「メッセージの表示」という目的不明確の項目だけに注目する （余裕のある読者はレビューをしてみると良いだろう）．
「メッセージの表示」というのは，プログラムがユーザに対して何らかの情報を伝えるための手段であるが， そのメッセージ内容が記述されていないため，情報伝達の目的が何なのかが分からない． 節[定義]で述べたように，不良項目である2行目の一つ上位の階層の 「列車の座席を予約する」という項目を目的の判断に踏まえたとしても，目的を明確に理解することはできない． このような指摘は，4行目と13行目の「メッセージを表示する」という項目についても同じである．
節[分類のポイント]でも述べたように， 日本語として意味の理解が困難である項目は，「日本語不良」に分類せよ．
また，目的不明確はチャートのX軸方向の配置に関連する不良であるということに注意せよ．（これに対して，節[粒度不良]で解説する「粒度不良」はY軸のまとめ方に関連する不良である．）
プログラムがユーザに何らかの情報を伝えたい場合，CUI(9)を備えたプログラムであればコンソールにメッセージを表示するだろう． しかし，GUI (10)を備えたプログラムであればスプラッシュスクリーン (11)を 表示するかもしれないし，他にも音声でユーザに伝えるという方法も考えられる．
つまり，図[目的不明確（「メッセージの表示」）が指摘できるチャート]の「メッセージを表示する」という不良項目の対処案として，図[目的不明確の対処案 その1（CUI）]から図[目的不明確の対処案 その3（音声）]のような可能性が考えられるはずである． これらは現在問題になっている部分のチャートを抜粋したものであるので，「アプリケーションの開始を知らせる」の項目 の後にも他の項目が続くと考えて欲しい．
図[目的不明確の対処案 その1（CUI）]から図[目的不明確の対処案 その3（音声）]の対処案の3段目に記述されているような，瑣末な手段は チャートに 記述しない方が読み手は理解しやすいということに気づいただろうか． どのような手段で実現するかを詳細に記述なくとも， 「アプリケーションの開始を知らせる」という目的を明確に記述すれば，プログラムの設計者の意図が十分に理解できる． つまりチャートには，プログラムの実装に依存するほど細かな手段は記述しない方が好ましいと言える． 結果的に，3段目を省略した図[目的不明確の最終的な対処案]のようなチャートにするのが妥当である．
このような例から分かるように， 「メッセージの表示」 という不良は，上位の目的「アプリケーションの開始を知らせる」という項目が抜け落ちた上に， メッセージ内容の記述が不十分であったために発生したと考えられる． 目的不明確の原因はこのように複雑になることが多いが， チャートのX軸方向に関連する問題かどうかを考えて，分類の判断に利用すると良い．
項目の記述内容の不足が原因となるだけではなく，項目の配置される階層が原因になって目的不明確が発生することが多い． 発生の原因が多種多様であるため，分類はできても，原因の分析が難しいのがこの不良の特徴である．この原因分析の詳細は，章[原因の分析と対処案の提示]で詳しく述べる．
“ある項目とその下位レベルの項目間の関係が不適切なこと”
「構造不良」はさらに「構造不良/矛盾」と「構造不良/不足」に分類できる．
「構造不良/矛盾」
ある項目を達成する手段としてそぐわない項目が，その項目の下位に記述されている場合
「構造不良/不足」
ある項目に記述された目的が，その項目の下位に記述された手段群では達成不可能な場合
「構造不良/矛盾」と「構造不良/不足」の各分類を詳細に解説する前に， 初心者に多く見られるチャートの例を使って，分類の大まかな説明を行うことにする．
節[矛盾]で 「構造不良/矛盾」を，節[不足]にて「構造不良/不足」を改めて解説する．
図[「構造不良/矛盾」と「構造不良/不足」の両方が指摘できるチャート]は「構造不良/矛盾」と「構造不良/不足」の両方が指摘できるチャートの例である．
図[「構造不良/矛盾」と「構造不良/不足」の両方が指摘できるチャート]で示されたプログラムの一番大きな目的は，1行目「列車の座席を予約する」 である．また，その目的は，「予約のための情報を入力する」， 「座席を検索する」，「結果を出力する」という3つの手段で達成されることが表現されている． しかし，これらの3つの達成手段の中に「座席を予約する」という項目がないため， このチャートでは，1行目の目的が達成できるとは考えられない． これが「構造不良」の「不足」と分類される不良である．
そこで，「座席を予約する」という項目を探してみると，5行目の「座席を検索する」ための手段として記述されてしまっている． つまり，「座席を検索するために座席を予約する」という目的と手段の矛盾が起こってしまっている． これが「構造不良/矛盾」と分類される不良である．
このような指摘を踏まえて，改善を行ったチャートを図[「構造不良/矛盾」と「構造不良/不足」の両方を改善したチャート]に示す．図[「構造不良/矛盾」と「構造不良/不足」の両方を改善したチャート]のようにチャートの記述を変更することで， チャートの各項目間の関係に「矛盾」や「不足」が生じなくなる．
ここまで具体例を用いて解説した事柄をまとめると，次のようなことになる．
HCPチャートにおいて，ある項目はその1つ下位の階層に記述された手段だけで達成可能でなければならない （図[チャートにおける目的と手段の関係]）．
項目間の目的-手段の関係性が適切ではないチャートは，このチャートを基にプログラムの実装を行えないことは 勿論のこと，読み手はチャートを理解することが困難になる． HCPチャートを読む場合，大抵の人はプログラムの大きな目的から 読み始めるが，その途中に目的-手段の関係が不正な項目があると，チャートを読み進める 動作を止めることを余儀なくされる．多くの場合，記述されている手段から上位の目的を推測し，構造を補正しながら チャートを理解しなければならなくなり，読み手は非常に理解しにくいチャートだと感じるだろう．
図[チャートにおける目的と手段の関係]でも示したように，ある項目は，その直下のある階層の項目だけで実現が行えるように チャートを構成しなくてはならない．よって，レビューの際には，ある項目に注目し，その直下の階層の項目群だけで， 注目した項目に記述された目的が達成可能がどうかをチェックすると効率が良い．
図[「構造不良/矛盾」が複数指摘できるチャート]は，「構造不良/矛盾」が複数指摘できるチャートの例である．初心者はこのような チャートを書いてしまうことが多い．このチャートでは，3行目「ユーザの入力を取得する」という項目の 下位の階層で，ほぼ全ての処理を行ってしまっている． これでは当然，1行目「列車座席予約（プログラム）(12)」 という目的を2段目に項目群だけでは達成することができないため，「構造不良/不足」についても指摘の対象となる．
他の例も紹介しておこう．
1つ目は，今までのチャートの例と同じような「構造不良/不足」が指摘できる． このチャートでは，1行目「列車の座席を予約する」というプログラムの一番大きな目的を達成するために， 2段目以降の手段が必要であることが表現されている．しかし，チャートの2段目には，「現在の空席数を表示する」， 「予約希望人数を入力する」 「（日本語不良なのでなんとも言えないが）予約の結果を知らせる」，「アプリケーションを終了する」という項目しか見当たらず， 予約を行うという項目がまったく記述されていない．これでは1行目の目的を達成できるとは考えられない．
これとは別に，2行目の「現在の空席数を表示する」は確かに「列車の座席を予約する」ための手段と考えられるが， 3行目の「予約希望人数を入力する」ための手段（プロンプトのような役割を果たす）であると考えた方が理解しやすい． つまり，2行目の「現在の空席数を表示する」は 3行目の「予約希望人数を入力する」の下位に移動した方が好ましい．このような場合，完全な項目間の矛盾 とは言いがたいが，「構造不良/矛盾」の仲間として指摘する．このような不良は比較的多く見られる事例といえる．
矛盾と不足を見分けることは比較的に容易に行うことができるだろう． しかし，構造不良を的確に指摘するために は，構造不良の指摘に関連する項目について，日本語不良や目的不明確に該当するものがないことが前提になる． この事柄については，節[分類の優先度]で詳細を述べる．
既にここまで本書を読んだ読者なら，図[構造不良が指摘できるチャートの例]で示したチャートの「構造不良/不足」部分を容易に指摘できるだろう．
これまで見てきた不良の具体例から， 「構造不良/不足」で指摘された不足項目がチャート上にまったく存在しない場合は 少ないことが想像できるだろう． 具体例のように，項目はチャート上に存在しているものの，それを記述する位置と階層が不適切なために，「構造不良/不足」 が指摘されることが多い．配置場所が適切でない項目は， そこで上位の項目と「構造不良/矛盾」を起こしている場合が多いので，合わせて矛盾も指摘できないかをチェックする必要があるだろう．
「構造不良/不足」をまとめると，図[適切なチャートと構造不良/不足があるチャートの比較] のようになる．節[構造不良]で述べたように，1つ下の階層に記述された項目群のみで， 上位の目的が達成可能かどうかを順にチェックしていけば，見落としなく不良を指摘することができる．
注意すべき点は，矛盾の項で述べた事柄と同じである．
“複数の項目が適切な大きさでまとめられていないこと”
上位に新たな項目を作成した方が良い場合 ，モジュール分割によって項目をまとめた方が良い場合の両方に適用できる．
図[粒度不良が指摘できるチャート]の2，3，4行目は， 同レベルの他の項目と比較して，粒度が細かすぎる． これらの項目は，「予約のための情報を入力する」のように，まとめた項目を作ることで粒度が適切に調整される． 図[粒度不良が改善したチャート]にこの対処案を適用して改善したチャートを示す．
このような部分を 「粒度不良」と指摘する．この不良を解決することで，2段目の項目が「入力-処理-出力」というプログラムの基本的な流れと対応し， チャートの可読性が増す．
多数の手段をある粒度で必ずまとめる必要があるとは言い切れないが，1つの項目に対して下位の項目数が5つを超えるような場合は， 各項目をまとめられる可能性がないかどうかを検討すべきである．
階層を作ることによって調整した場合だけに限らず，モジュールとして複数の項目をまとめる場合， ある部分だけをモジュール化し，他の項目との粒度の不一致が起こる場合が多い（図[モジュール化による粒度不良の発生]）ので注意が必要である．
この具体例を図[モジュール化の不整合による粒度不良が指摘できるチャート]に示す．
これは， 7，8行目をまとめた方が良いという粒度不良と共に，7から10行目までを「座席の予約をする」というモジュールとして まとめた方が良いという指摘ができるチャートの例である．この指摘を踏まえ，修正したチャートを図[モジュール化の不整合による粒度不良を改善したチャート]に示す． これにより，7行目と9行目は両方ともモジュール化されることになる．モジュール間のまとめ方についての差異がなくなり， チャートが読みやすくなったことが分かるだろう．
粒度不良に分類される不良は，節[分類のポイント]で述べたように，チャートのY軸方向に関わる不良である． この不良を指摘するためには，チャートの各項目の記述と構造がきちんと記述されていることが前提になる． 初心者が作成したチャートは， 目的不明確や構造不良が多発しているために，レビューを行って，それを修正をしているうちはチャートが大きく変動するため， 粒度不良をレビューすることは難しいだろう．