フォード、トヨタ、モルモット

-モルモットは海と何の関係があるのですか？

「飛行船を設計するためのカモノハシとほぼ同じ。」

はじめに

歩きながら、いくつかの情報源からの情報をスクロールして、一致する部分を見つけます。 興味深い発見の1つは、PeoplewareのDemarcoとListerの統計的観測と、Critical ChainのGoldrattの理論計算のほぼ完全な対応です。



2011年の秋、頭をひねりました。

[1]「巨人の肩の上に立つ」イーライ・M・ゴールドラット©Eliyahu M. Goldratt、2008

[2]「生産管理：フロー管理」Oded Cowen、Elena Fedurko

[3]「単一ボードのストーリー」（http://cartmendum.livejournal.com/tag/theboard）。



さらに、「突然...」と書きたいと思いますが、これは真実ではありません。 これは突然起こったわけではありません。 数週間かかりましたが、最終的にはかなり完全な画像が頭にできました。



私が正確にキャッチしたもの：

• 小野太一（大野太一）は、彼のシステムがなぜ機能したのか理解できませんでした。
• 生産フローにはいくつかの異なるタイプがあります-V、A、T、I。各タイプのフローには特別なタスクがあります。
• 一部のユニットでのマキシムドロフェーフのボード導入の失敗
• 多くの企業は、すべての努力にもかかわらず、トヨタシステムを実装できませんでした。
• トヨタシステムとフォードシステムは同じ原理に基づいていますが、適用されるソリューションは特定の種類の生産に限定されます。

理論 ストリームの種類

フロータイプは一般に、支配的なパターンから分類されます。 純粋な（縮退した）フォームでは、フローのタイプは次のように表すことができます。



より詳細な情報が必要な場合は、Oded-CohenとElena Fedurkoの記事を参照することをお勧めします。



ソフトウェア生産の世界では、類推ができます。



主な違いは、ソフトウェアの生産には多くの場合、資料がないことです。 ソフトウェア生産の世界で、材料の類推として何を使用するかは明確ではありません。 注文はあちこちにあります。 原則として、工場での生産も注文なしでは開始されません。 おそらく、入力されたアイデアは素材と考えることができます。 開発プロセスでは、これらのアイデアが要件仕様に変換され、次にアーキテクチャソリューションに変換され、最終的に最終製品に変換されます。

免責事項 同じタイプの生産チェーンの問題が、素材生産の世界とソフトウェア開発の世界で同じであるかどうかはわかりません。 これは、多くの裏付けとなる例がある仮説です。 しかし、1つの例外でさえ、この仮説に疑問を投げかけるかもしれません。

たぶん誰かが分類を変更したいかもしれません。 たとえば、私はしたかった。 さらに2つのタイプを追加したいと思います。





しかし、この標準からの逸脱、および標準、さらには悪い方が順守する方が良いです。

ZhタイプはTタイプのより正確な名前であるという疑いがあり、アメリカ人だけがアルファベットに不運です。 ;-)

入力する

管理が最も簡単なIタイプのストリーム。



しかし、このタイプでも、よくある間違いがいくつかあります。 最も一般的な間違いは、「プッシュ」制御モデルの使用です。



IT業界に典型的な典型的な例を考えてみましょう。 「営業部」->プログラミング部->テスト部という単純な、ささいなチェーンを見てみましょう。



プロセス図：



部門に応じて処理させます。

• 営業部-週20件の注文
• プログラミング部門-週10注文
• テスト部門-週5回の注文

これに、部門が処理した注文の数に応じて、ボーナスシステムを追加します。 営業部門が処理可能なすべての注文を引き受けることは論理的です。 また、ほとんどのトップマネージャーがすべての注文を注文することも論理的です。 1年前のディスカッションの例を次に示します。



>プログラマーがやる時間よりも多くの手を打ち、プロジェクトを募集できないようにする。 当然、プログラミング部門の前に小さなプロジェクトバッファーが必要です。



これを読んだ後、少なくとも会社の最も小さな頭ができる最初のことは、著者の頭に当たり、彼は彼にナポレオンのコック付き帽子を与え、彼を愚かに送ります。 これは、プログラマーがどの程度会社が販売する必要があるかを決定するために行くべきですか？ 彼らが要求された売上に生産を増やすことは難しいことを理解していますが、販売機会の利用可能性は販売に勝るものではなく、彼らの要求を満たす可能性に取り組む機会です。



ロシア語：彼らは会社にお金を持ち込み、一部はそれを送るつもりです。



結果は非常に明白です。 生産チェーンは、実行された注文ですぐに詰まり、平均リードタイムは不適切な値に増加します。 この場合、わずか6か月で、注文執行の平均時間が2年に増加します。 これはあまり競争的ではありませんが、非常に頻繁に見られます。



パフォーマンス領域のバランスを取ることも幸福をもたらしません。 システムには「ビート」があり、平均リードタイムは再び不適切な値に増加します。



Max Kramarenkoには、バランスの取れた生産チェーンのモデリングに関するブログがあります。

• http://maximkr.livejournal.com/18940.html
• http://maximkr.livejournal.com/18971.html

モデリングにより、打撃の結果として、生産チェーンがすぐに詰まることがわかります。 実験の終わりに、たった4つのサイトからなる短いチェーンの場合、150のタスクが実稼働状態にありました。 これは「現代の管理職」に変換すると、4人日という労働集約度のタスクが6か月で実現されることを意味します。 マネージャーの質問「なぜこんなに長いのか！」に対する答えは簡単です。「そのように管理しているからです。」

これは重要です。 注文実行の長さが非常に長いことの原因は、ほとんど常にワークフロー管理システム（管理）にあり、エグゼキューターにではありません。 信じられない人なら誰でもシミュレーターを作成して実験することができます。 公平を期すために、「従業員の平均ダウンタイムは少なくとも20〜25％にする必要があります」というルールに従えば、バランスの取れたチェーンを使用できることに注意してください。 しかし、繰り返しますが、どのマネージャーがこれを行いますか？

フォードAタイプとソリューション

このタイプのフローの問題は、アセンブリ操作でコンポーネントが欠落していることです。



Iタイプの生産チェーンは、熊手のように原始的で、若い大根のように気取らない。 このようなチェーンを管理する最適な方法は昔から知られていましたが、残念ながら、この手法が最初に記述された世紀にはまだ情報が見つかりません。 しかし、ある時点で、子供時代は終わり、マネージャーは本当に難しい仕事に直面します。 同様の課題は、他の人とともに、ヘンリーフォードによって直面されました。 当時、フォードの自動車生産はA型生産でした。 複雑で、多くの分岐がありますが、頂点が1つあります。 単一の自動車ブランド、単一の色。 組み立て場所に部品の在庫がないことは、自動車の生産時間の増加につながります。 しかし、部品が過剰に供給されると、完成した車を鉄の岩から取り出すのにかかる時間が長くなります。 各部分が待機キューで時間のかなりの部分を費やすため、時間が増加します。



1913年、ヘンリーフォードは彼の工場で車のコンベアアセンブリ方法を導入しました。 そして、1926年までに、鉄鉱石の採掘から完成車（5,000個以上のパーツで構成される）を鉄道プラットフォームに置き、出荷の準備が整うまでの生産サイクルは81時間に達しました！.. [1]顕著な成果。 少なくとも50の生産サイトで構成されるソフトウェア生産プロセスのセットアップの複雑さを想像してください。 ほとんどの現代のマネージャーは、ワークフローを管理するために複雑なACS（自動会計システム）を要求すると信じています。 しかし、世紀の初めにはコンピューターはありませんでした...



人気の信念に反して、ヘンリーフォードの生産ラインは、組み立てられた車が同期して移動するコンベヤベルトに馴染みがありません。 これらは個別の作業区であり、部品を手動で転送します。 「ワークフローを改善するために、フォードは2つの作業センターごとに仕掛品を保管するために利用できるスペースを制限しました。 これが生産ラインの本質です。これは、最初の生産ラインには、在庫（進行中の作業）をある作業センターから別の作業センターに移動するためのコンベヤなどの機械装置がなかったという事実によって確認されます。 コンピューターが不足しているため、フォードは視覚的な作業管理システムを作成しました。 非常に使いやすい。



はい、もちろん、追加のルールが導入されていない場合、このシステムは機能しません。 「割り当てられたスペースがいっぱいになると、それを埋めるワーカーは生産を停止する必要があります。 」 散歩に出かけたり、昼寝をしたり、VKontakteに座ったり...



フォードは現代の経営の主要な規定の1つを放棄しました。 しかし、今、99年後、ほとんど変わっていません。 フォードはインタビューのために典型的なロシアの会社に来て、 パートタイムの仕事が会社の収入を増やすための前提条件であると言い、彼は本当の生産を管理する方法を知らないと言われるだろう。

より複雑なタイプとトヨタシステム

V型フローの問題-「材料の盗難」。

Tタイプのフローの問題-「盗難」および欠落コンポーネント。



フォードの視覚モデルはAタイプに最適です。 しかし、マージは行われず、分岐（1つの作業センターが複数のセンターに部品を供給）するとすぐに問題が始まります。 ゼネラルモーターズが広範囲に市場に参入した当時、フォードの生産ラインの利点を排除したのはこれらの問題でした。 会社のマネージャーは再び挑戦を受けました。



このグローブは、1943年にトヨタ自動車で働き始めた小野太一によって育てられました。 1950年代半ばに、彼は特別な生産組織システムを構築し始めました。これは後にトヨタ生産システムと呼ばれます（誤ってカンバン、リーン、ジャストインタイムとも呼ばれます）。



フォードと同様に、小野は自動制御システムを持っていなかったため、かんばんに基づいた視覚的なワークフロー管理システムを開発しました（翻訳オプション：視覚カード）。 ただし、このシステムは、追加の要件がなければこのような効果をもたらすことはありません。 各時点で、パワーリザーブがあるエリアでは、2つの改善のいずれかを行う必要があります。バッチサイズを小さくする（切り替えと関連する損失の数を増やす）か、再調整時間を短縮します。



「当時、TPSが世界的な名声を得るまで、ロットのサイズを大きくすることは、切り替え時間を短縮する伝統的な方法と考えられていました。「経済的に健全なロットサイズ」は、何千もの記事に当てられた非常に人気のある用語でした。 この伝統的な経験をすべて拒否しました。」[1]



現代の管理システムに挑戦しました。 彼らが彼を許さなかったのは論理的です。 40代後半から60年代前半まで、彼のシステムは「嫌な小野システム」と呼ばれていました。



ただし、60年後、リーンサポーターと呼ばれる人々の間では、切り替えをなくすことがアクセスを増やす最も強力な方法の1つと考えられています。 そうは思いませんでした。 小野太一が無駄のない製造に関する会議に参加し、あなたの立場を明確にすると、実際の生産を管理する方法がわからないと言われるでしょう。

追加ルール

そして、楽しみが始まります。 作業区が複数のチェーンに関与している場合、これらのチェーンをダイアグラムに追加する必要があります。



Aタイプの左右の流れはFordビジュアルモデルで制御できますが、ワークセンター「3」と「4」の併用により、スキームは複雑であり、オンモデルに進む必要があります。 このような複雑なモデルを使用したくない場合は、作業区「3」、「4」を「3 '」、「3」、「4'」、「4」に分割する必要があります。



管理モデルの適用可能性とその複雑さを理解することは、企業の組織構造と開発規制を変更する決定に大きな影響を与えるはずです。

例。 歴史的に、同社には4つの異なる内部製品のサポートを担当する4つの異なる開発センターがあります。 ある時点で、テストグループが最初のセンターに作成されました。 このイノベーションは非常に効果的であることが判明し、テストグループを4つの開発センターすべてにテストサービスを提供する個別のサービスに分離する問題が検討されています。 長所と短所？ 短所：ストリームのタイプが変更され、管理性の問題が発生します。 4つのI型チェーンの代わりに、1つの複雑なチェーンがあります。 テストワークセンターにパワーリザーブが用意されている場合、変換によって悪影響が生じることはありません。 しかし、テストはシステムの限界になり、その後の悲惨な結果を招くことになると、何か（以前の経験すべて）が教えてくれます。

歴史的に、会社には社内製品のサポートと複数の顧客の改善を担当する部門が1つあるとしましょう。 「プログラミング->テスト」というかなり一般的な構造を取ります。 最も簡単で些細なIストリームで、簡単に制御できます。 ある時点で、配達の質が顧客を満足させるのをやめ、会社は受け入れ段階の導入を検討しています。 長所と短所？ 短所：ストリームのタイプが変更され、管理性の問題が発生します。 1つのIタイプチェーンの代わりに、1つの複雑なチェーンがあります。 改善の配信がすべての顧客に共通のパッケージに編成されている場合、1人の顧客が他の全員への現在の配信と後続の配信の両方をブロックできます。

マトリックスシステムは、従業員が2人のマネージャー（機能部門の責任者とプロジェクトマネージャー）を同時に抱えている場合にも悪影響をもたらします。 Truffaldinoでさえ、2人のマスターに仕えるという悪い仕事をしました。 そして、実際のプロジェクトの実際の会社では、これはすべてのプロジェクトの時間の素晴らしい混乱と途方もない増加につながります。

リトリート。 トヨタの製品開発システムに関するリッカーの本には、マトリックス研究は正確にトヨタの研究センターで行われていると書かれています。 さらに、彼らは有意義にこれに来て、これを変えたくありません。 実際、それらにはマトリックスを機能させる他のあらゆる種類のトリックがあります。 その1つは、プロジェクトマネージャーが同僚の間で大きな権限を持つ専門家であることです。 原則として、彼は会社で10-25年働かなければなりません。 この場合、彼はリーダーであり、彼にとって正式なコントロール手段は必要ありません。 マトリックスは悪ではなく、ただ難しくしている

時には、大企業では、「2人の主人のしもべ」の出現を厳しく抑制します。 私が聞いた選択肢の1つは、内部労働交換です。 対応する専門分野のエンジニアは、構造ユニット（プログラマーのプール内のプログラマー）に配置され、プールマネージャーに報告されます。 プロジェクトに転送されるまで送信します。 その後、プロジェクトマネージャーのみに報告します。 プロジェクトマネージャー以外の誰かがプロジェクトに従事しているエンジニアに直接命令を与えることは、人事異動につながる可能性が高い攻撃です。 パートタイムの従業員のために会社は少し落ち込みますが、管理の容易さの利点は非常に大きいため、これらの損失を上回ります。 これに加えて、「私の家臣の家臣は私の家臣ではない」という原則が使用されます-小隊司令官は兵士に直接命令を与えることはできません。 そして、彼が与えるなら、彼は新しい軍曹を探すでしょう。 または、軍曹は新しい小隊司令官を探します。

かんばんとモルモット

ロシア連邦で人気のあるMSProjectは、プロジェクトの計画に悪影響はありません。 計画プロセスでは少し悪いです。 多くの場合、計画プロセスには、一般的なトラッカーの方が適しています。 しかし、これは重要ではありません。 トラッカーとプロジェクトは両方とも「情報冷蔵庫」です（クイックソフトウェア開発の方法論に関する最高の本の1つでAlistair Coburnによって造られた用語）。 開発効率を高めるには、「情報ラジエーター」が必要です。 そして当然、作業管理ルールが必要です。



ここでは、ボードが情報ラジエーターのように見えるかもしれません。 実際、ファッショナブルなボードは同じトラッカー、つまり同じ冷蔵庫です。 ボードをラジエーターに変えるには、公共の場所に吊るす必要があります。 そして、彼らがボードの下でウェブツールを使い始めるとすぐに、それはすぐに冷蔵庫になります。 まあ、それを廊下や天井の下のプラズマに持っていかないと。



数年前、タスクの説明が記載されたステッカーが貼られたボードを使用することが提案されました。 今、これはかなりファッショナブルな趣味です。 「かんばん掲示板」のリクエストで、検索エンジンは次のようなものへの多くのリンクを提供します。

この図は、Iタイプのストリームの視覚制御システムを明確に示しています。 小野太一システムとは関係ありません。 さらに、このシステムはヘンリーフォードシステムよりも原始的です。 この「プログレッシブ」モデルは、「わずか」99年のワークフローを管理する科学の理論と実践に遅れをとっています。

かんばんとモルモットの共通点は何ですか？ かんばんボードは、海へのモルモットとほぼ同じかんばんとの関係を持っています。

まあ、彼らはそれを間違って呼び出したように見えるでしょう、それで何ですか？ そして、間違った用語がツールの普遍的な適用可能性の幻想を与えるという事実。 多くの場合、コンサルタントはこの掲示板を不適切なストリームタイプに適用しようとします。 当然、試行は失敗しますが、何らかの理由でコンサルタントがパフォーマーを非難します。 「XP / SCRUM / Kanban / ...を誤用しただけです」紳士、プラスドライバーで釘をねじ込むのに失敗した場合、ドライバーを誤って保持したことをアーティストに責めるべきではありません。 彼にハンマーを与えるだけです。



生産フローの理論を知らない「XP / SCRUM / Kanban」の「コンサルタント」には用心深く注意することをお勧めします。 それらがまったく使用できなかったわけではなく、フローの理論を適用できないこと、シェハートのカード、締め切りが大幅にずれている履行の確率を合計できないことなどです。



将来、このようなボードをIボードと呼びます。



管理ルールに関しては、セミナーでスレン・サマルチャン（ビデオキャスト：http://spmguild.org/news/618/）は、プログラマーの1人が解放された場合にのみタスクを実稼働に移すことができると述べました。 これは、システムの制限（多くの場合「ボトルネック」と呼ばれます）が生産チェーンの最初にある場合にのみ機能することを理解するのは簡単です（ゴールドラットの本「The Goal」の観光コラムの管理を参照）。



孤立した小さな部門をまたいだ開発チームでは、これがまさに起こることです。 制限は、生産チェーンの最初にあります。 そして、すべてが順調です。 しかし、システムの制限が他の場所に行くとすぐに...すべてのコメディの終わり。 「少しポッドシャマニット」というシステムが必要です。 マキシム・ドロフェーフは、「生産中のタスクの数がプログラマーの数を2を超えて超えてはならない」という経験則を見つけました。 これは通常のシャーマニックルールです。

より興味深いボードチューニングは、記事「ITのかんばん（かんばん開発）」（http://habrahabr.ru/blogs/development/64997/）でOlegによって提案されました（姓を示していませんでした）。 そして今、最も重要なこと。 各列の下の数字をご覧ください。 これは、これらの列に同時に存在できるタスクの数です。 数値は実験的に選択されていますが、チーム内の開発者の数に依存すると考えられています。



Fordの生産ラインに似ていますが、Iタイプのストリームに適用されます。 実際、これはヘンリーフォードのルールの視覚化です。「2つの作業センター間で進行中の作業の量を制限する必要があります。」



奇妙なことに、多くの場合、システムの制限は、顧客がタスクを受け入れる場所です。 この効果が観察された少なくとも3社を知っています。



Iボードの使用には別の制限があります。 この制限は、1つの生産サイト（1つの請負業者）でのサイクルの効率に関連しています。 サイクル効率が50％未満の場合、「1人のアーティストには1つのジョブしかありません」というルールが失敗し始めます。



ご注意 サイクルの効率は、生産サイトで費やされた合計時間に対する処理時間の比率です。 午前中にタスクを取得し、出発直前にタスクを実行した場合、合計時間は8時間です。 2時間タスクに取り組んだ場合、サイクルの効率は25％です。



単位時間あたりのエグゼキューターの1つのタスクの制限が無効になる例を示します。

• 警察プロジェクト（www.toc-center.ru/politseiskie_proekty.html）
• TKおよびPMIの作成（GOST 34.602および34.603）。 ドキュメントは互いに強く影響し、2つのドキュメントを同時に書く方が簡単な場合があります。
• ガラディナーを調理します。 煮るスープは、調理中に数分間力を合わせて参加する必要があります。 現時点では、サラダを調理することはかなり可能です。 ホステスがスレンサマルチャンシステムに従ってお祝いのクリスマスディナーを準備していた場合、ゲストは空腹のままになります。 システムがそこでは適用されないというだけです。
• 多くの場合、テクニカルサポートサービスに送信されるアプリケーションはこのカテゴリに分類されます。 たとえば、調達要求には多くの場合、従業員が他のことを行うことができる長い停止期間があります。

この場合、使用条件を厳しくしてください。 請負業者が複数のタスクで同時に作業できるようにします。



そしてもう1つの制限。 Iボードは、タスク間の関係を十分に視覚化しません。 これは、独立したタスクを伴うメンテナンスプロセスに適していますが、プロジェクトにはさらに適しています。 疎結合タスクを持つ短いプロジェクトには適していますが。



それにもかかわらず、そのようなボードは非常に使いやすく、ユニットが実装に適している場合、これはフローを管理する最も効果的な方法の1つです。 Fordシステムとシステムの両方が同じで、視覚化するのは非常に困難です。



そのようなボードを導入する直前に、チェックリストを確認する必要があります。

• I型ストリーム？ そうでない場合、ほとんどの場合、単純なボードを導入する試みを放棄する必要があります。
• 制限はチェーンの先頭にありますか？そうでない場合は、供給バッファーに注意してください。 サブルールを考え出します。
• 1つの生産サイトでのサイクル効率は50％を超えていますか？そうでない場合は、一度に1つのタスクのみを処理するという制限を取り除きます。
• 受注は相互に接続されていますか、または単独で実行できますか？接続されている場合は、視覚化するために別のものが必要です。 ネットワーク図の描画に切り替える必要がある場合があります。 たぶん何か他のもの。

多くの場合、つまずきブロックは複合型のストリームです。 フローのタイプを簡素化するための効果的な薬は、個々のプロジェクトチームと機能単位の分離と分離です。



しかし、あまりにも頻繁に、私たちは次のフレーズを聞きます。 彼以外は誰もこれを行うことができません。 そして、あなたはそれを私たちに完全に転送することはできません。 彼には週4時間しか必要ありません。」



解決策は、かけがえのない効果を排除することです。 XP-shnyコードの所有権と関連する専門分野のコーディング標準とトレーニングの導入（プロジェクトの1つで私たちを大いに助けたエキゾチックな組み合わせの1つは、1人の「システム管理者」と「コンピューターアーティスト」です）。



会社を独立したグループに分離することは、より多くの、より多くの部門をまたがるスペシャリストにとって有益です。



ある会社では、システム管理者を開発グループに、プログラマーをシステム管理グループに入れることの賢明さについて真剣に議論しましたが、実験として実装されたこのルールは良い結果を示したと同僚は言います。



Andrei Orlovは、Automatorのノートで、簡単な経験則を提案しました：「プログラマーが不可欠になったら、すぐに彼を解雇してください。」

提案は完全に理にかなっています。 かけがえのない従業員は、現地の生産性が最も高いかもしれませんが、その不可欠性はフローを不安定にしすぎます。



別のオプションは、ストリームの長さを短くすることです。 作業場の数を減らすと、状況が劇的に変わります。



実在の企業における実在のプロセスの観察に基づいた好奇心のタスク。

. $2 000 ( ). . , , . , $2 000 : + . , . – 4 , – 6 , - $12 000 4 , . , . – 4 , – 4 , - $8 000.: « ROI ?» : : 18*2000 = $36000… , , , , . : 1 , (18-1)*… , , , , , .… : . « ». «, », «, » « ». - . . – (18-4)*2 000 = 28 000, – 28 000-12 000=16 000, ROI=133%. . . . . . . , . (18-12)*2000 = 12 000. – 4 000, ROI – 50% ROI, . , .





観察から：厳密な一般管理によって接続されていない5〜6の作業センターのチェーンは、多くの場合、プロジェクトの立ち上げを無意味にします。 2つの作業センターを備えた比較的安定したチェーン。 3つはすでに問題を抱えています。 チェーン1-> 2-> 1は、おそらく1-> 2-> 3よりも安定しています。



バリューストリーム内の作業区の数を減らします。 直接的なコストを増やすために行ってください。 フローを安定させ、平均リードタイムを短縮することは、これらのコストをカバーする以上のものです。



選択したアナリストを拒否できます-拒否します。 選択したテスターを拒否できます-拒否します。 専用のテストまたは専用の分析を拒否できない場合は、テスターとシステムアナリストの役割を1人で組み合わせてみてください。

システムが適用されない場合はどうなりますか？

次に、完全な目次に切り替える必要があります。 作業管理システムの視覚化として、Goldrattが記事「巨人の肩に立つ」で提案した優先順位変更システムを試してみたいと思います。 「金属」でそれを実装する方法はここだけですか？ システムアナリストにとって興味深いタスク：「アイデアを理解し、エンジンを選択し、カスタマイズのためのステートメントを記述します。」 私の本能は、エンジンとして中間レベルの追跡システムを採用することはかなり可能であることを教えてくれます。 TrackStudioが表示される場合があります。

あとがきの代わりに

また、グループのワークフローのタイプを混同しないようにしてください。 下痢や便秘の治療は非常に簡単です。 しかし、薬物を混ぜると、結果は多少驚くかもしれません。



タイプのフローを混同し、TタイプのフローにIボードを使用しようとすると、結果はそれほど驚くことではないかもしれませんが、下痢のために薬を混合した場合よりも会社にとっての結果は著しく悪くなります。