新・風の谷の生活

食糧自給率の向上を目指して!

「なぜ、この谷のように暮らせぬのか」
腐海という危機を前にしても戦争に明け暮れる諸国を、ユパはこう嘆いています。
現在の地球が置かれている状況は、この台詞に表されているように思えませんか。
ならば、風の谷のように暮らしてみよう。
私なりの解釈の元、片田舎で自給自足型農業を始めることを決意したのです。

砕いたエノキダケを煮詰めた後に凍らせた食材だそうです。
JA中野市が商品化しました。
味噌汁や煮物、カレー等に、凍ったまま入れて使うそうです。
 
健康や美容に良いとされているようですが、
栄養バランスを崩すような摂取は逆効果でしかありません。
この辺りは、注意して使うべきでしょう。
 
エノキダケさえ入手(栽培)すれば、調味料として使えるメリットがあります。
というわけで、作り方です。
 
★材料:エノキダケ300g
    水    400g
★道具:製氷皿  2枚
 
☆作り方
 (1)エノキダケの石づき(約1.5cm)を除き、ざく切りにする。
 (2)ミキサーにかけてペースト状にする。(約30秒) ※1
 (3)鍋にペーストを入れて掻き混ぜながら煮詰める。(約60分) ※2
 (4)粗熱を取る。
 (5)製氷皿に移し、冷凍庫で凍らせる。
 ※1:始める前に1時間程度 日光に当てるとビタミンD₂が増える。
 ※2:煮詰めると、煮詰める前の7割程度になる。
 

前回は、現状を踏まえて、食糧自給率を100%した際に、農業従事者の比率をどこまで増やせるかを検討しました。
その結果、全人口の2.9%まで農業従事者を増やせることがわかりました。
これは、現状の約1.5倍に当たります。
ですが、肉食をやめたとしても、現状の2倍の生産量に増やさなければ、食料自給率を100%にすることができません。
これでは、農業従事者一人当たりの生産量を1.3倍余りに増やさなければなりません。
 
そこで、気になるのが、W/R係数です。
日本は、流通や仲買の割合が欧米の1.5~2倍もあります。
小売価格の56%が流通や仲買なので、これを三分の二にできれば、小売価格が同じでも農家の収入は増えます。
具体的には、56%の三分の二は39%なので、農家の取り分は44%から61%に増えます。
農業従事者人口に変換すると、4.1%になり、約500万人まで増やせます。
これは、現在の農業人口の約2倍に当たるので、食糧自給率を100%にするために生産量を倍増させたとしても、農業従事者一人当たりの生産量は、現状とほぼ同じとなります。
 
 
食糧時自給率から離れるとしても、W/R係数を向上させれば、農家の収入が向上することは変わりません。
 
私には、日本の食料自給率が向上しない影の要因として、日本の高いW/R係数があるように思えてしまいます。
 

農業人口比は、何%であるべきでしょうか。
 
農地は、現在の食生活を続ける限り、一人当り10.7aが必要と分かっています。
でも、肉食をやめれば、7.5aで足ります。
 
現在の日本は一人当り3.6aで、食糧自給に必要な面積の約半分しかありません。
肉食を完全にやめた上で、人口を半分に減らすか、農地を倍に増やすか、単位面積当たりの収穫量を倍に増やすか、これらを組み合わせれば、食糧自給できるようになるはずです。
 
では、食糧生産するための農業人口は、どれくらいになるのでしょうか。
 
最も単純な計算方法は、エンゲル係数から逆算する方法です。
日本のエンゲル係数は、23%です。
小売価格の56%(品目により異なる)は、流通や仲買によるもので、農家の収入になるのは44%です。
 ちなみに、W/R係数というのがあります。
 これは、卸/小売の比率で、欧米の2程度に対し、日本は3~4と高い比率です。
 単純にみれば、日本の流通費が欧米の1.5~2倍なのです。
農家の収入ですが、資材費等の支出が71%を占めるので、実質の収入は29%程度です。
 
では、一般消費者の収入の何%が農家の収入になっているか、計算してみましょう。
 
計算式は、以下とします。
[農家の収入になる確率]=
 [エンゲル係数]×[小売価格に占める農家収入]×[必要経費を除いた利益率]
 [23%]   ×[44%]         ×[29%]
 
計算結果は、約2.9%でした。
収入面から見ると、農業人口は、全人口に対して2.9%となります。
人口に直すと、約360万人です。
現在の日本の農業労働人口は約230万人ですので、食糧の完全自給を果たせば、1.5倍程度に増やせるはずです。
 

今回は、工程管理における具体的な優先度について、検討してみたいと思います。
 
下記のようなプロジェクト、タスク、イベントの構成とします。
この場合に、処理する順番を考えます。
親プロジェクト内の各イベントの日限は、上ほど早く、下ほど遅いものとします。
 
 ├親プロジェクト1
 │ ├タスク1        ①
 │ ├子プロジェクト1
 │ │ ├タスク11     ①
 │ │ └イベント11    ②
 │ ├子プロジェクト2
 │ │ ├タスク21     ①
 │ │ └孫プロジェクト21
 │ │   ├タスク211  ①
 │ │   └イベント211 ②
 │ ├タスク2        ③
 │ ├タスク3        ④
 │ └イベント1       ⑤
 │
 └親プロジェクト2
   ├タスク4        ①
   ├イベント2       ②
   ├タスク5        ③
   └イベント3       ④
 
 
処理順は、①~⑤で表しました。
①が非常に多いことに気付くと思います。
同じ処理順の場合、その後ろにあるイベントの優先度に従い、処理順を決めます。
 
次回は、優先度が異なるタスクやイベントの処理順の決定方法を検討します。
 

前回、プロジェクト、タスク、イベントの入力項目について考えましたが、
イベントを軸に優先度を管理すべきと考え直し、前回分を見直すことにしました。
以下は、見直し分です。
 
プロジェクトの入力項目です。
1.所属プロジェクト<省略可>
2.プロジェクト名
3.発生日(開始日)
4.日限 (最終日)
5.依頼元     <省略可>
 
タスクの入力項目です。
1.所属プロジェクト
2.処理順(自動生成の予定)
3.タスク名
4.成果物
5.予想作業時間
6.作業開始予定日<省略可>
7.日限
※作業開始予定日を省略した場合は、所属プロジェクトの発生日を使用する。
 
イベントの入力項目です。
1.所属プロジェクト
2.優先度
3.イベント名
4.主催者
5.招待者<省略可>
6.開始日時
7.終了日時
 
 
工程管理の主要なテーマは、どのタスクから処理していくかを決めることです。
一言にまとめるなら、「各タスクの優先度をどう管理するか」です。
 
これを実現するために、以下の考え方をします。
1.一つのプロジェクトの中では、タスクとイベントはシリーズに処理する。
2.イベントの優先度に合わせて、それ以前のタスクの優先度を決定する。
3.プロジェクト同士は、同列かつ平行に処理する。
 
 
※次は、具体的な優先度の考え方をまとめようと思います。
 

↑このページのトップヘ