泥の大きな塊、パート2

記事「泥の大玉」の継続的な翻訳。

使い捨てコード

彼は

QUICK HACK（高速ハック）

KLEENEX CODE（ナプキンコード）

使い捨てコード（使い捨てコード）

スクリプト（スクリプト）

KILLER DEMO（デモキラー）

永久プロトタイプ（永久プロトタイプ）

BOOMTOWN（急成長都市）



家の所有者は、この構造物を分解し、より永続的なものと交換するという固い意図で、一時的な格納庫またはカーポートを構築できます。 時間が示すように、そのような構造は当初の計画よりもはるかに長く生きることができます。 たぶん、彼はこれらの一時的な解決策に取って代わるお金を持っていません。 または、そのような新しい建物が現れると、「しばらく」それを使用する誘惑がすぐに生じます。



システムプロトタイピングでも同じことが起こります。コードがどれほど美しく効率的であるかについて心配する必要はありません。 動作するプロトタイプを表示するためのコードのみが必要なことを知っています。 準備ができ次第、コードは破棄され、より慎重に再登録されます。 デモンストレーションの時が来ると、クールであるが本質的には役に立たない機能をロードしたいという抵抗できない欲求が生じます。 そのような戦略が「成功をもたらす」こともあります。 クライアントは、プロジェクトの次のフェーズの開発を支援する代わりに、プロトタイプに満足しています。





軽微な問題をすぐに修正するか、すぐにプロトタイプを作成するか、概念を証明する必要があります。



時間またはその不在は、多くの場合、プログラマに1回限りのコード（THROWAWAY CODE）の作成を強いる決定的な力です。 優れた、よく考えられた、しっかりしたプログラムは、問題を解決するのに私たちが持っているよりも多くの時間を必要とします。 多くの場合、プログラマーは最小限の機能を備えたプログラムを迅速に作成し、近い将来、より洗練されたエレガントなバージョンを作成することを約束します。 同時に、再利用可能なコンポーネントを作成することで、将来発生する問題の解決がはるかに容易になり、よく開発されたアーキテクチャにより、簡単に保守および拡張できるシステムを開発できることを十分に認識しています。



ダーティコードの迅速な作成は、一時的な措置と見なされることがよくあります。 しかし、おそらくもっと頻繁に、この作業を続けるのに十分な時間がありません。 コードに弱点が現れ、逆にプログラムは急速に成長しています。



したがって、非常に多くの場合、利用可能な手段によって、問題を解決するのに役立つ単純で便利な1回限りのコードが作成されます。



ワンタイムコードは、多くの場合、他の誰かのより複雑なコードを再利用する代わりに作成されます。 プロジェクトの締め切りが近づいている場合、独自に動作する粗雑でずさんなプログラムを作成する可能性は、誰かのライブラリまたは開発環境を研究および習得するための未知のコストを上回ります。



通常、プログラマーは特定の知識分野の専門家ではありません。特にキャリアの最初期は特にそうです。 ユースケース図またはCRCカード[Beck and Cunningham、1989]は、この知識を学ぶのに役立ちます。 ただし、チームがドメインを把握するのに役立つプロトタイピングに勝るものはありません。



プロトタイプを作成するときは、必ず「そして、送信できます」と言う人が必ずいるはずです。 プロトタイプが実稼働に入るのを防ぐために、そのような言語でプロトタイプを作成するか、そのようなツールを使用して実稼働バージョンを作成できないようにすることができます。



極端なプログラミング支持者[Beck、2000]は、多くの場合、迅速な1回限りのプロトタイプを急いで作成します（スパイクソリューション）。 プロトタイプは問題の回避方法を理解するのに役立ちますが、プロトタイプを優れた設計と混同しないでください[Johnson and Foote、1988]。



すべてのプログラムが宮殿である必要はありません。 単純な1回限りのプログラムは、テント都市や預金の発見の結果として成長した都市のようなものであり、そのような都市は、5年後にはいずれにしてもゴーストタウンになるため、50年先の問題を解決する必要はありません。



ワンタイムコードの実際の問題は、このコードが再利用可能になったときに現れます。



ワンタイムコード（THROWAWAY CODE）の作成は、ほぼ普遍的な方法です。 あらゆるレベルの経験とスキルを持つすべてのソフトウェア開発者は、少なくとも一度はソフトウェア開発にこのアプローチを採用しています。 たとえば、パターンコミュニティには、「クイックコードとダーティコード」の2つの例がありますが、これらは長期間保存されています。 これは、PloPオンライン登録コードおよびWiki-Wiki Webページです。



実際、EuroPLoP / PloP / UPの元のオンライン登録コードは、2大陸の4つの異なるマシンで実行される分散Webベースのアプリケーションでした。 会議情報はセントルイスの車で管理され、登録情報はイリノイ州とドイツの車で保存されました。 システムは登録レポートを生成し、訪問者のオンラインリストを即座に更新することさえできます。 1995年に「高速でダーティな」HTMLコレクション、Cデモコード、およびcshスクリプトが作成されたときにすべてが始まりました。 概して、これは実験になると予想されていましたが、実際には、プロジェクトは作成者の期待を超えました。 今日では、同じHTMLコレクション、同じCデモコード、およびcshスクリプトです。 これは、「高速で汚い」コードが独自の生活をどのように始められるかを示す良い例です。



元のCコードとスクリプトには、おそらく30行未満の元のコード行が含まれていました。 多くの行は単純にコピーして貼り付けられ、生成したテキストまたはチェックしたフィールドのみが異なります。



出席レポートを生成したスクリプトの1つの例を次に示します。

echo "<H2>Registrations: <B>" `ls | wc -l` "</B></H2>" echo "<CODE>" echo "Authors: <B>" `grep 'Author = Yes' * | wc -l` "</B>" echo " " echo "Non-Authors: <B>" `grep 'Author = No' * | wc -l` "</B>" echo " "
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトは、特に登録数が増えた場合に遅く、非効率的でしたが、その利点は機能することです。 訪問者の数が100を超えた場合、スクリプトは非常に不十分で不安定に動作しました。 ただし、会議会場は100人の訪問者を収容できなかったため、登録が長期間制限され、スクリプトに問題があるとは予想していませんでした。 一般に、これは問題に対する無能なアプローチでしたが、多くを満足させ、それが書かれた機能を実行しました。 このような実際的な制限は高速コードの典型であり、ほとんどの場合文書化されていません。 概して、高速コードではほとんど文書化されていません。 ドキュメントが存在する場合、通常は無関係であり、正確ではありません。



www.c2.comのWiki-Webコードも、Ward Cunninghamが率いるCGI実験として始まり、予想を超えています。 「wiki」という名前は、カニンガムの個人的なジョークの1つです。 彼はハワイで休暇中に空港のエプロンバスでそれを見つけたとき、ハワイ語からこの言葉を借りました。 翻訳すると、この言葉は「速い」という意味です。 ワードはその後、この言葉を「迅速で汚いプロジェクト」に使用し始めました。 Wiki Webは、訪問者が自分の前に誰かが書いたすべてを変更できるという点でユニークです。 一見、これはある種の破壊行為ですが、実際にはすべてが悪くないことが判明しました。 このシステムの成功を踏まえて、作者はプロジェクトを完成させるための追加の試みを行いましたが、Perlの高速で汚いコードはシステム全体の基礎のままでした。



両方のシステムが端にあり、小さな汚れの塊から大きな汚れの塊に変わりそうだと思うかもしれません。 登録システムのCコードは、1つのNCSA HTTPDサーバーから広がりましたが、ゾンビコードがまだ含まれています。 KEEPING IT WORKING戦略は、システムを拡張するか改善するかを決定するときに最初に頭に浮かぶものです。 両方のシステムは、リソース、関心、聴衆がいる限り、再構築（RECONSTRUCTION）の悪い候補ではありません。 それまでの間、これらのシステムは、開発されたソリューションのために、依然としてタスクを非常に満足に実行していますが、そのまま残ります。 それらを維持することは、それらを完全に書き換えるために必要とされるよりもはるかに少ない力とエネルギーしか必要としません。 それらは段階的に（PIECEMEAL）ゆっくりと発展し続けます。



「高速でダーティな」コードによって引き起こされたアーキテクチャの劣化を修正し、システムの他の部分から隔離し、独自のオブジェクト、パッケージ、およびモジュールを保存することができます。 そのようなコードが隔離されている限り、システムの健全な部分の整合性に影響を与える機能は最小限に抑えられます。 このアプローチは、パターン「ラグの下でスワップ」のフレームワークで議論されています（SWUGING IT UNDER THE RUG）。 1回限りのアーティファクトがしばらく存在することが明らかになったら、段階的な成長の反復プロセス（PIECEMEAL GROWTH）、または「再構成」パターンで説明されている新しいドラフトプロジェクトのいずれかを使用して、構造の改善に注意を向けることができます（再構築）。

ステージ成長

彼は

自然な成長

反復的かつ漸進的な開発



ロシアの宇宙複合施設ミールは、構成を変更してモジュールをビルドするために作成されました。 基本モジュールは1986年に発売され、モジュール「Quantum」と「Quantum-2」はそれぞれ1987年と1989年に複合施設に加わりました。 Crystalモジュールは1990年に追加されました。1995年には、Spectrumモジュールとドッキングコンパートメントが接続されました（1986年には、このコンパートメントについても考えませんでした）。 最後に、最後のモジュール「Nature」が1996年に発売されました。複数のモジュールを使用してこのような操作を行うことで、複雑な建物を数回再構築することができました。



都市計画は安定した成功物語を誇ることはできません。 たとえば、米国の首都ワシントン市は、フランスの建築家ピエールランファンのマスタープランに従って建設されました。 ブラジル（ブラジル）とナイジェリア（アブジャ）の首都も最初の紙の都市でした。 ヒューストンなどの他の都市は、サポートプランなしで成長しました。 各アプローチには欠点があります。 たとえば、道路が中心からさらに遠くなり始めるとすぐに、廊坊計画の放射状の道路システムは失敗しました。 一方、計画がなかったため、ランダムに配置された住宅、商業、工業地域で構成されるパッチワークキルトが出現しました。



ほとんどの都市は、アブジャよりもヒューストンのように見えます。 都市は、入植地、土地、ドック、または鉄道駅として始まります。 これらの人々の場所には、金や森、交通網へのアクセス、誰にも属さない土地が描かれた可能性があります。 時間が経つにつれて、一部の集落では、人数が重大なレベルに達し、その後、肯定的なフィードバックを伴うサイクルが始まりました。 街の成功は職人、商人、医者、司祭を引き付けました。 人口の増加は、インフラストラクチャ、政府機関、および警察の保護をサポートできます。 そして、これはさらに多くの人々を引き付けます。 いくつかの例外を除いて（私はすぐにソルトレークシティの街を思い出します）、そのような入植地の創設者は、大都市の基礎を築くとは考えませんでした。 彼らの野心は非常に控えめで、瞬間的でした。



過去数年にわたって、ソフトウェア開発プロセスの「伝統的な」カスケードモデルを批判することが流行になってきました。 読者には、そのような攻撃は死んだ馬をキルティングすることに似ているように見えるかもしれません。 しかし、もしそうなら、馬は死んだ動物には強すぎます。 このアプローチは長い間信用を失っていると多くの人が信じていますが、プロセスや方法論の遺産を生み出し、今日までさまざまな仮面の下で生き残ってきました。



カスケードモデルが登場する前の期間、プログラミングの先駆者は、ソフトウェア開発の「コンパイルと修正」（コードと修正）に、単純で、不注意で、比較的混乱したアプローチを使用していました。 当時の問題は原始性の危機にthatしていたことを考えると、このアプローチはほとんどの場合報われました。 しかし、組織の欠如の結果は、ほとんど常に大きな汚れの塊になりました。



この湿地に応じてカスケードモデルが登場しました。 また、「コンパイルと修正」モデルが小規模なプロジェクトに適している場合、より大きなタスクに対処できませんでした。 ソフトウェアがますます複雑になるにつれて、オフィスでプログラマーのグループを集めてコードを書くよう指示するだけでは不十分になりました。 大規模プロジェクトでは、チーム全体の適切な計画と調整が必要でした。 なぜ疑問に思うのは、問題を徹底的に分析し、詳細かつ事前に考え抜かれた設計で、車や橋を開発するのと同じ方法でソフトウェアを開発できないことです。 実際、ソフトウェア開発コストの調査では、プログラムのサポート中に問題を解決することは、ほとんど常に設計開発中よりも費用がかかることが示されました。 もちろん、ソフトウェアサポート中のコストを回避するために、すべてのリソースとすべての専門家を動員する方が適切でした。 疑いもなく、まず下水システム全体を敷設してから壁を構築し、次にそれらに穴を開ける方が賢明です。 7回測定し、1回切ります。



カスケードモデルが1世代前に繁栄を達成できた理由の1つは、コンピューターとビジネスの要件がかなり遅いペースで変化しているためです。 ハードウェアは非常に高価だったため、このソフトウェアで作業するために雇われたプログラマの給与は大幅に削減する必要がありました。 今日の標準では、ユーザーインターフェイスは原始的でした。 英数字の「グリーンスクリーン」であれば、必要なユーザーインターフェイスを取得できます。 カスケードモデルが普及したもう1つの理由は、より高度なエンジニアリングおよび生産分野で使用されているプラ​​クティスとの類似性であり、非常に便利でした。



現代のデザイナーは、絶えず変化する要求の猛攻撃に対処しなければなりません。 一部には、これは技術自体の急速な成長によるものです。 部分的には、これはビジネス環境の急速な変化によるものです（一部の変化は技術によって引き起こされます）。 顧客はより高度なソフトウェアに慣れており、より多くの選択肢と柔軟性を求めています。 かつて単一のプログラマーによってゼロから開発された製品は、サードパーティのコードおよびアプリケーションと統合する必要があります。 ユーザーインターフェイスは、内部的および外部的に洗練されています。 実際、ユーザーインターフェイスを提供するために、システム全体を割り当てる必要がある場合があります。 変化は彼らに追いつく能力を超えてしまうという脅威があります。



マスタープランは、多くの場合、厳格で不正確で時代遅れです。 ユーザーは時間の経過とともに変更が必要になります。



変更 ：トップダウン設計の基本的な問題は、現実の要件が必然的にターゲットを移動させることです。 問題を一度だけ解決したいと考えることはできません。問題が解決するまでに、問題はすでに変化しているからです。 多くの場合、顧客自身が自分が何を望んでいるのか分からないため、顧客が求めることを行うことはできません。 計画するだけで適応することはできません。 何が起こっているかを完全に予測できない場合は、柔軟性と迅速な対応に備える必要があります。



美学 ：上から下まで設計する目的は、システムの重要なアーキテクチャ要素を事前に認識して特定できるようにすることです。 この理解の観点から、高品質の設計は、1行のコードを記述する前にシステムの構造をエレガントかつ完全に決定します。 これらの大まかな計画と現実の不一致は、標準からの逸脱と見なされ、設計者によるエラーと見なされます。 デザインが高品質である場合、そのような省略はその中に予見されます。 一貫性のない要件が存在する場合、このような非の打ちどころのないデザインの希望は、常に最初にボールを打つという願望と同じくらい無駄です。



この厄介さを回避するために、デザイナーは、他の人がこれらのアーティファクトを作成するタスクを引き受けなければならないことを知って、いくつかの問題に対してより複雑でより一般化されたソリューションを提案することによって自分自身をカバーしようとすることができます。 複雑さについてのそのような仮定が真実であるとき、それらは強さと満足の源になりえます。 これは、ウィトルウィウスが語った美しさ（ベヌスタス）です。 ただし、予想される状況が決して実現しない場合があり、設計者と開発者が誰も遭遇していない問題を解決するために時間を浪費していることがわかります。 別の状況では、予想される問題が発生しなかっただけでなく、解決策自体が別の方向に発展しなければなりませんでした。 そのような場合、理論的な複雑さがその後の適応に対する不必要な障害になる可能性があります。 逆説的に、優雅さの追求は、意図しない複雑さと混乱の原因になることがあります。



最も見苦しい形で、変化を予測して防止したいという欲求は、「分析的麻痺」につながる可能性があります。これは、知覚される矛盾の凝縮ネットワークが、設計の可能性が制限されすぎるほど大きくなるためです。



したがって、変化と成長に寄与する力に常に注意を払わなければなりません。 成長の機会を最初にローカルで使用します。 常にリファクタリング。



優れたソフトウェアはより多くの視聴者を引き付け、その結果、プログラムに対する要求が増える可能性があります。 多くの場合、これらの新しい要件は満たすことができますが、元のアーキテクチャと完全に矛盾するソリューションの開発コストがかかります。 [Foote、1988]は、この建築破壊を「中年の一般性の喪失」と呼びました。



設計者がゼロからエレガントなものを作成するか、既存のシステムのアーキテクチャを破壊して問題を迅速に解決するかの選択に直面すると、アーキテクチャは失われます。 これは、システムの進化における自然な段階です[Foote and Opdyke、1995]。 この段階は「クリーンキッチン」と呼ばれ、システムの一部がテーブルの周りに散らばり、最終的に取り除かれるのを待ちます。 危険は収穫が待てないことです。 ケータリング施設での実際の料理については、衛生および伝染病ステーションがこの状況に介入します。 残念ながら、ソフトウェアの場合、そのような怠慢を制御する特別な機関を見つけることはめったにありません。 制御されない成長は、最終的に悪意のある力になる可能性があります。 また、放置すると、大量の汚れが発生します。



Stuart Brand（1994）は、著書「How Buildings Learn」で、彼が「高道路建築」と呼ぶものは、変更が困難な高価な建物につながることが多いと指摘しています。 一方、バンガローや倉庫などの民俗建築物はより適応性がありました。 ブランドはまた、機能が徐々に形に変わりつつあり、公共の建物は変化に適応していると述べました。 同様に、ソフトウェアを使用する場合、他のプログラマの聖地を冒とくすることはまずありません。



クリストファー・アレクサンダーは、彼の著書「オレゴン実験[ブランド、1994] [アレクサンダー、1988]」で次のように書いています。

主要な開発は、交換のアイデアに基づいています。 断片的な成長は、修正という考え方に基づいています。 主要な開発は、理想的な建物を建設できるという誤りに基づいています。 段階的な成長は、間違いは避けられないという、より健康的で現実的な視点に基づいています。 これらのエラーを修正する手段がない場合、各建物は、建設されるとすぐに、ある程度まで刑を宣告されます。どんな状況でも、一挙に達成することはできません。

アレクサンダーはまた、私たちの住宅ローンと設備投資の方針は多額の資金を利用できると述べましたが、この方針は支援、改善、開発のためのリソースを提供しません[Brand、1994] [Alexander、1988]。 ソフトウェアの世界では、ライフサイクルの最初から、最も才能のある経験豊富な人々と関わってきました。 その後、ソフトウェアサポートは中級レベルの従業員によって提供され、リソースは非常に不足する可能性があります。 いわゆるサポートフェーズは、架空のマスタープランの価格を実際に支払わなければならないライフサイクルの一部です。 テクニカルサポートプログラマーは、すでに確立された設計と絶えず変化する世界との間で絶えず増大する矛盾に対処するように招待されています。 アーキテクチャの詳細な理解がライフサイクルの後半に来るという仮説がある場合は、このプラクティスを検討する必要があります。



ブランドは、サポートが教育であることを認識しています。 彼は、システムのコンテキストで学習の3つのレベルを識別します。 最初のレベルは、システムが開発されたパラメーター内でその機能を適切に実行する場合の習慣です。 第2レベルは、システムが変化に適応する必要がある場合に機能します。 ここでは、通常、システムを変更する必要があり、そのような変更に耐える能力がその適応性の程度を決定します。 3番目のレベルは最も興味深いものです。学ぶこと、学ぶことです。 建物の場合、例は追加の床の建設です。 システムは構造の重大な変更を受けることを余儀なくされるため、適応し、その後の適応の痛みは軽減されます。



段階的成長は、状況に応じて、システムの実行可能性を損なわないように、既存の生きている呼吸システムから始めて、段階的に外で作業する代替ソリューションとして使用できます。 使用するにつれてプログラムを強化します。 すべての面での大規模な進歩はありません。 代わりに、変更は小さな実行可能なタスクに分割されます。



段階的な成長で驚くべきことは、リバーススワップ（フィードバック）の役割です。 ハーバートサイモン（Simon、1969）は、進化の結果として作成されたシステムまたは人によって作成されたシステムは、予測に依存している（将来に対処するための主な方法である）少数のシステムのみであると述べました。 彼はまた、恒常性（自己調節）や遡及的反応などの支援メカニズムがはるかに効果的な手段であると指摘しました。 ホメオスタシスは、環境の短期的な変動からシステムを保護します。応答メカニズムは、システムの実際の動作と望ましい動作の間の長期的な不一致に対応し、適切な調整を行います。 Alexander [Alexander 1964]は、適応において恒常性と応答が果たす役割を詳細に説明しました。



変更にすばやく適応できる場合、変更の予測はそれほど重要ではなくなります。 ブランドは、レトロスペクティブな外観は予想よりも優れていると述べています[Brand、1994]。このような迅速な適応は、極端なプログラミングのマントラの中心にあります[Beck、2000]：必要ありません。



極端なプログラミングの支持者は、あなたは自分が思っているほど頭が良くないふりをして、あなたの賢いアイデアが必要になるまで待つ必要があると言います。あなたはこのアイデアを急いで話す必要はありません。あなたが正しい場合、あなたはそうだと思ったと言うので、あなたは何をすべきかを知っています。間違いを犯した場合、そこにない問題を解決するために努力する必要はありません。



極端なプログラミングはフィードバックに大きく依存しているため、すべての要件はコードと同期され、短期（3週間）の反復と、開発プロセス全体の設計および開発の優先順位に関するユーザーとの広範な長期協議に重点が置かれます。極端なプログラマーは、大規模な事前計画に関与しません。代わりに、フィードバックに基づいてユーザーが何を望んでいるかに応じて、可能な限り迅速にコードを記述し、これらのプロトタイプをトラックに戻します。



フィードバックは、コードの所有者を決定する役割も果たします。開発者が期限に間に合わない場合、次の反復中に、前のタスクの完了にどれだけ近いかに関係なく、別のタスクが与えられます。



極端なプログラミングでは、テストは開発プロセスの不可欠な部分です。理想的には、コードを記述する前にテストを開発します。コードは開発の過程で常にテストされています。極端なプログラミングでは、「未来への回帰」から何かがあります。多くの点で、このアプローチはコンパイルおよび修正方法に似ています。極端なプログラミングを区別する唯一のことは、システムの開発に貢献するフィードバックの中心的な役割です。また、システムの開発は、最新のオブジェクト指向プログラミング言語と強力なリファクタリングツールによって促進されます。



極端なプログラミングの支持者は、この最小限の計画と設計前の注意を呼びます。代わりに、フィードバックと継続的な統合に依存しています。ある程度の予備計画と設計は重要であるだけでなく、避けられないものであると確信しています。誰も盲目のプロジェクトを行いません。基盤を築き、インフラストラクチャに関する決定を下し、ツールを選択し、一般的な方向性を設定する必要があります。初期段階では、全体的なアーキテクチャのビジョンと戦略に集中する必要があります。



変更がチェックされていない場合、システムの実行可能性が損なわれます。そして、計画された変更はシステムを強化します。変化は悪意のある広がりや健全で適切な成長を引き起こす可能性があります。



過去10年間、オブジェクト指向環境では、反復的かつ漸進的な進化プロセスからオブジェクトが出現することが合意されてきました。例[Booch、1994]を参照してください。ソフトウェアテクトニクスモデル（SOFTWARE TECTONICS）[Foote and Yoder、1996]は、システムが変化を漸進的に処理する方法を研究しています。



段階的な成長に伴う最大のリスクは、この成長によりシステムの構造全体が徐々に破壊され、必然的に大きな塊に変わることです。 「ラグの下でのスワップ」戦略は、段階的な成長と連動します。どちらのパターンも、局所的な深刻な問題を特に重視しており、アーキテクチャに関する大きな問題に注意を払っていません。



これらの力に立ち向かうためには、絶えず統合（統合）に従事し、リファクタリングを実行する必要があります。これらのプロセスにより、ローカルおよびグローバルな力が時間の経過とともに解決されます。このライフサイクルの観点は、フラクタルモデルを複製します[Foote and Opdyke、1995]。アレクサンダーを引用する[ブランド、1994] [アレクサンダー、1988]：

成長と回復の有機プロセスにより、変化の段階的なシーケンスが作成され、これらの変化はすべてのレベルに均等に分散される必要があります。[キャンパスを開発する場合]、完全に新しい建物を作成するよりも、部屋、建物のスパン、窓、通路などの細部を復元することに注意を払う必要があります。この場合にのみ、全体としてのバランスの取れた環境と、歴史の各段階でのその要素について話すことができます。

記事1のその他の部分