今から父になるから俺の悩みを聞いてくれ。

子ども産まれるんで育児とか生き方について書きます。映画とか心理学とかITとかの趣味についても書きます。

『その後の不自由 「嵐」のあとを生きる人たち』を読んで

どうもmaximonelson49です。

『その後の不自由 「嵐」のあとを生きる人たち』という本を読んだよ。

『その後の不自由 「嵐」のあとを生きる人たち』

 とりあえずAmazonリンク。

その後の不自由―「嵐」のあとを生きる人たち (シリーズ ケアをひらく)

その後の不自由―「嵐」のあとを生きる人たち (シリーズ ケアをひらく)

 

 最初に言っとくと、すげえ面白かったし、読みやすかった。書いた人はDARCっていう依存症ケアの施設で働いてる上岡さんと大嶋さん。上岡さんは自身も薬物依存の当事者だ。

ちょっとだけDARCの説明を引用すると、

ダルク(DARC)とは、ドラッグ(DRUG=薬物)のD、アディクション(ADDICTION=嗜癖、病的依存)のA、リハビリテーション(RIHABILITATION=回復)のR、センター(CENTER=施設、建物)のCを組み合わせた造語で、覚せい剤、危険ドラッグ、有機溶剤(シンナー等)、市販薬、その他の薬物から解放されるためのプログラム(ミーティングを中心に組まれたもの)を行っております。 

【日本ダルク】薬物依存症におけるあらゆる問題を統括的にサポーするオールインワンの統合施設です。

と公式サイトにある。薬物依存に限らず、なにがしかの依存症に対してケアを行う施設ってことだ。国内のこういう施設だと真っ先に名前があがるところで、俺も中学生のときDARCの方がきて薬物ダメだよ〜〜の講演をしていった覚えがある。

んで、ざっくりこの本の内容を書いてしまうと、DARCとかの施設でケアを受け、そして施設を出た「その後」の人々について描かれたもの。帯でも

トラウマティックな事件があった 専門家による援助が終わった その後、彼女たちはどうやって生き延びて来たか。

 と記されており、そういう意味でその後を描く。

私たちはなぜ寂しいのか

全編面白かったのだが、とくに面白かったのが第1章の『私たちはなぜ寂しいのか』だ。

ここでは「応援団」「境界線」という考え方を持ち出して、「家庭に問題がないわけじゃないのに問題をそこそこ乗り越えていっている」人(依存症でない人)が依存症にある人とどのように違うのか? を説明している。

応援団について

(依存症でない人は)観察してみると、どうやらそういう人たちは家族内だけで問題を解決するわけではなく、外側に応援団をもっているように見えました。

[...]たしかにまわりにいる家族が信頼できて、家族だけで解決できればいいけれど、大きな問題になればなるほど、家族だけで解決できなくなります。誰かが外にSOSをだしたり、おそらく家族以外のところともつながりながら、乗り越えていくものだろうと思います。

[...]会社でイヤなことがあったりしても、自分のコミュニティに帰ってきたら、そのなかに自分の価値を見つけられる。(P16,17)

 まあ要するに、自尊心の根底みたいなものを守るものとして「応援団」があるってことみたいです。重ねて重要なのは、家庭内の大きな問題が家庭内で完結せず、外部とうまくコミュニケーションが取られながら解決されること。なぜ外部の介入が必要になるのかというと、家庭内で解決しきれないような問題は、当然子どもにも影響を与えるから。

次に、「境界線を壊されて育つ」とはどういうことなのかについて説明します。

[...]父とおばあちゃんがすごく仲がよくて、母はその関係のなかに入れなかったので、お嫁に来ても不幸だったんですね。私は三歳ぐらいから不幸な母を背負ってきました。今でも母は「ハルエは三歳からホントに役に立った」と言います。でも三歳から頼りになっちゃいけないわけですよ(笑)。(P20)

ここで言われているように、基本的に子どもは誰かに面倒見てもらって生きることこそあれ、他人の面倒をみたり他人を背負って生きるものではない。このように他人の世話をしながら生きるというのは「境界線を壊されて育つ」ということになる。

境界線を壊されて育つとは

 回復というのは、他人を優先していたことが「自分を真ん中にして考える」ことへと変わっていくことです。特にボーダーラインとよばれる境界性パーソナリティ障害の人ほど他人を中心にしています。彼らは自分中心の極みのように思われていますよね。でも違うんです。真ん中に「自分」じゃなくて「他人」がいる人たちなのです。

(P18)

 人はみな、自分自身のためにしか生きていけない。自分が悲しく思えば泣けばいいし、嬉しければニコニコとすればいい。が、他人の世話をするというのは他人の気持ちに寄り添うということだ。

他人の気持ちに寄り添うってのは、字面だけ見ればとてもよろしいことに思える。しかし家庭環境が不安定な状況下では、他人の気持ちに寄り添うことは自らが望んだものではなく、これはもっと切実なものだ。だって自分が頑張らなきゃ、家庭が崩壊してしまうのだから。そういう切迫感とともに生きている。

幼い頃から他人を背負って生きる人々が、何を感じるようになるか。自他の境界があやふやで、他人の責任を取ってきた人々は、自分が感じる気持ちがほんとうに自分のものなのか、それとも他人のものなのか、分からない。そもそも、そこに区別があることすら分からないかもしれない。

お父さんとお母さんの問題を自分のものとして背負っているので、いつもお父さんとお母さんの痛みも感じている。そうすると、やがてそれが自分の痛みなのか、お父さんお母さんの痛みなのかがわからなくなるんです。このことを自助グループで言うと、みんな「そうそう」と共感しますね。そういう区別のつかなさみたいなものが、大人になってもずっとある。(P27)

 そうなると、どうなるか。他人の痛みを感じとると、まるで自分のことのように感じてしまう。すごく助けなきゃと思う。

んで、助けなきゃって思うような相手って、端的にいって人からケアが必要な人なんですよね。だからこういう人ほど誰かにケアしてもらえず、ケアする側に回りがち。単にケアするだけならまだいいけれど、トラブルの多い人(ヤクザ屋さんとか)と付き合ったりしてしまうと、もう大変。そこから薬物につながったりもある。

んで、寂しさ

 こういう自他の境界があいまいな人が、(言い方はアレだけど)普通の人と付き合うとどうなるか。今まで密着して他人の意図を汲むことが愛情だと思っていたから、普通の人を相手にすると遠く感じて、「寂し」いと思ってしまう。相手と重なり合うような(自他の曖昧な)関係を求めてしまう、というわけ。

 その他のこと

 寂しさについてはこんなもん。これだけでも十分面白いんだけど、他にもマジで面白い内容たくさん。下記にメモ。

①支援者側のスタンス、自傷されたときの対応
②からだと薬物
③薬物が精神の均衡を守っている
④虐待されている人がより弱い人を虐待してしまう、ということがある

あと、ここら辺のこと俺もブログにまとめてるんで、まあよかったらちょっと読んでみてくださいよ。ちょっと分かりにくいかもだけど。

優しさと責任範囲について - 今から父になるから俺の悩みを聞いてくれ。

 

はい、これで今回はおしまい。マジでこの本面白かったから読んでくれよな。

カウンセリング行ってきた

おつです。maximonelson49です。カウンセリングに行ってきたので雑に感想を書いておく。

 

感想 

先にどんなところでカウンセリングやったのかだけ書いとくけど、近所の大学の心理相談室でやってもらった。50分間のカウンセリングで、料金は安い飲み会一回ぶんくらい。普通にカウンセリングを調べると¥12,000とかのそんだけ金あったら悩みもクソもねえだろみたいなカウンセリングがヒットするんだけど、大学でやってる心理相談室は学生がカウンセリングすることになるから安い。(重篤化した症状については専門の機関への取り次ぎとかをやってくれるはず)

今回は初回ってこともあり、ざっくりなにを喋りたいかみたいなところを確認したり、家族構成についての確認をしたりした。

自分がカウンセリングを利用する目的を書いとくと、
①愚痴を聞いてほしい
②コミュ障を治したい
の2点。

①は今後子育てだとか仕事だとかで悩むことがあったとき、相談できる相手がいないときついだろうなと思ったから。今は妻だけで、単純にひとりしか頼れる人がいないのは厳しいし、何より妻は俺の利害関係者なので相談しにくいことが出てくると思う。また、子育てを妻と自分で完結させると近視眼的になっちゃいそう。家庭内で認知できない問題にも対処できない。ので、予防としての意味で、カウンセリング。

②は自分がコミュ障だと思うから。コミュ障で死にはしないけど実際困ってるしみんなと仲良くおしゃべりしたいけどできないので、相談。

そんなかんじ。今回聞きそびれたこととしては、どんくらいのペースでカウンセリングをするのかについて。週一とかだと流石にきつい気もするが、しかし歯医者は週一とかでいくわけだしメンタルで週一がダメなのはメンタル軽視という気もする。

 

まあ今回は以上!オゥイェ

FileMakerの勉強 vol.10(第14章)

はい勉強。今回で初級編はおしまい。頑張った!!

 

 『FileMakerMasterBook 初級編』第14章(データベースの機能を作ろう(出力と集計)

スクリプトとかをさらに書いていく。

①出力の形

スクリプトを使った出力には以下の形がある。

1.検索の実行
2.ソートの実行
3.印刷
4.集計の実行
5.PDF保存
6.グラフの作成
7.エクスポート

スクリプトトリガ

ユーザーの動作をきっかけ(トリガー)にして、スクリプトを動かすことができる。OnObjectSaveとか。

スクリプト書くときの注意点

・レイアウトとスクリプト

スクリプトはそれが実行できるレイアウトってのがある。だから、実行できないレイアウトでそのスクリプトを実行する、みたいなことが起きないようにしなきゃならない。具体的には、レイアウト変更のスクリプトを最初に入れて、指定のレイアウトに切り替えてやる。

・エラー処理

仕事でもサブプログラム呼び出して、そんでそのリターンステータスで判定かけて必要に応じて亜ベンド処理する。ファイルメーカーでは、ファイルメーカー自体がいくつかのエラーを返してくれて、それがこのスクリプトで分かる。

get(最終エラー)

エラーがないときは0、エラーが検出されたときは0以外の値を返すとのこと。

 ・ウインドウの固定

スクリプトの実行中画面を更新しないようにするスクリプトExcelマクロを起動したら画面がバチバチバチって更新されまくってパソコンがめっちゃ重くなる、って現象を体験したことがあるだろうか。それを防ぐ。

 

 『FileMakerMasterBook 初級編』第15章(セキュリティの設定)

 セキュリティについて。

簡単に言えば「誰がアクセスできるか」「ある人にはどの程度の権限を与えるか」についてまとめてあった。

①「誰がアクセスできるか」

(ちゃんと設定していれば)ファイルメーカーは起動時に認証のダイアログが表示される。アカウント名とパスワードで管理するアレだ。ふつうのパソコンと同じっすね。

②「どの程度の権限を与えるか」

完全な権限とか入力のみとか閲覧のみとかを決められる。

 

 『FileMakerMasterBook 初級編』第16章(複数人が同時に利用するデータベース)

共有機能について。

なんとなくExcelのファイル共有みたいなものを思い浮かべていたけれど、それとは違うらしい。ファイルサーバにfilemakerのファイルを置いてみんなで更新する、みたいなのと、filemakerが提供する共有機能は違う、とのこと。正直よくわかんなかった。

 

 以上。次からは中級編。長い道のりだなあ。

仕様書のないプログラミングをした

先日、仕様書なし(設計書なし)でのプログラミングを初めてやった。こういうふわっとしたボールの受け取り方は今後必要なスキルだと思うので、反省しとく。

【状況】
●当初
・当初はメモ書き。3日で作って欲しいと言われる。
・IN01のIDを元にDB2つ3つ呼び分けてOUTを吐くプログラム。DB呼ぶサブプログラムのパラメータは不明。DB読めなかったらエラーを吐かせる。DB読む順番、回数は聞いて分かった。
●3日目
・サブ呼ぶパラメータは不明のままなので、とりあえず大枠だけ作ることに。
・ざっくり作ったのち、結合テストにて検証すると言われるも、結合テストの実施は初めて。
・言われた通りテストパック作成するも、サブプログラムを呼んだ後リターンステータスのエラーで流れない。サブプログラムのパラメータが間違っているっぽい。どのパラメータ起因なのか特定するために2日程度デバッグ
・「複数回呼ばれる/違う場面でも呼ばれるサブプログラムのコールセクションを共通化するか否か」がパラメータの内容に依存するため、ここら辺でセクション分割したり統合したりワークエリア新設したりとコードが荒れ始める。
・編集セクションとコントロールセクションを分けよとの指令。
●6日目
・使用するサブプログラムの変更。
・OUT2,3が追加。
結合テストに使えるデータが無くて困るなど。
・DBの説明を聞く。
●8日目
・方針転換で半分くらいの機能が消える。
・確認した当日が納期と判明する。


【思ったこと】
1.技術的な部分
1-1.コーディングに関するもの
・仕様書がなくメモ書きのみ ⇒ 行間から機能が増える ⇒ ソースがこんがらがってやる気なくす。最初に全体の仕様が分かってればセクションの分け方も綺麗になるはず。
・そういう意味では、仕様変更に耐えられるようなコーディングはしてなかったということ。保守性が低いというか、メンテナンスビリティについて考えてコーディングしていなかった???
1-2.仕様的な面に関するもの
・DBの構造について色々聞けたのは良かった。わかってなかった。
1-3.結合テストに関するもの
結合テストは何をもって終わりなのか
・TSOの使い方がマジ分かんなくて話にならねえなとなってた

2.マインドセット? 的な部分

2-1.「問題⇒解決」のサイクルが遅い

・「わかんないところをあげる⇒答え聞く」のサイクルが遅くなってる。
・「問題⇒解決」のサイクルは将来についても言えること。あらかじめ問題になりそうなところは想定して答えを貰っておく。
・具体的には、結合テストは必要なデータを先に洗って、貰っておけばよかった。
・また、何度も問題になる(ボトルネックになる)問題については、もっと高次のアプローチを。やり方・考え方教えてもらうとか。
・今回の例だと、将来の問題を見越すために仕様書を自分で書いてしまうとか。
  ⇒とっ散らかってきたのでまとめると

問題解決のサイクルを早めろ。

問題解決サイクルにはふたつの観点。問題の立てるってことと解決するってこと。問題の立て方として、問題点をざっと書きだしてしまうこと(今回なら仕様書を書くこと)。解決の方法には低次な方法として答えを聞く、高次な方法としてやり方考え方を聞くなどがある。

2-2.作業に区切りを持たせる

・やり方を最初に考えろ
(どう進めるのか、つまりだらだらとやってしまったのがよくなかった。なんつーか、終わりの見えないコーディング作業だった。何が必要なのかわかってなかった。全体のコーディングをざっくりやって、それからサブプログラムのパラメータ調査をして、、、、とかって考えてない。何のためにそのやり方を整理するのかというと、あれもこれもとなってしまってどこまで終わったのか分かんないし、調査するときも対象範囲が狭まらない。おかしいところがどこなのか、わからない。進んでいる感じもしない)
・マジ面倒クセェ…と思わない
・ダラダラコーディングしない。
・「とりあえず枠だけ」これはいい。が、それをチェックしてもらわないと意味がない。仕様の確認になってない。
・仕事の進め方を相手と握る、相手の責任にする
・次に進んで良いかのジャッジを下してもらう
こういうの、アジャイル開発?てきになる。下記の記事など参照。あと『アジャイルサムライ』とか読む。

フロー効率性とリソース効率性について #xpjug

2-3.おメンタルの弱さ
・期限は延びたら延びたなりに再度引き直す
・コミュニケーション密に。相手が忙しかろうと聞く。
結合テストとなった時点で、無限にかかるのでは? ということは指摘しておけば良かった。スケジュール的なところで未来のタラレバ考えとけば良かった。
・あと、コーディングについての細かな指摘(ここはフラグ使わなくてよくない?)とかに対してうまく反応できてない。意図を読み取れなかったり。

 

 こんな感じ。もちっとしたらもっとわけわかんない開発しそうなので、単独で動けるようになっときたい。あとおメンタル。以上!!

FileMakerの勉強 vol.9(第13章)

どもっす勉強する(この記事3回消えました。)

 

『FileMakerMasterBook 初級編』第13章(計算式をきちんと理解しよう)

①計算式とは

 ファイルメーカーではExcelみたいな乗りでフィールドに計算式を入れることができる。例えば、期限までの残り日数を表示させたいとしよう。こんなとき指折り数えて残り日数を計算し、そんで「期限までの日数」フィールドに日にちを入力するのはクッソ面倒くさい。そんなときファイルメーカーがどうするかっていうと、下記のように計算式を設定させることができる。

「タスクの期限」 - 「本日の日にち」

タスクの締め切り日から今日の日にちを引けば、まあ残り日数が設定できる。かつ、とても都合がいいのは、本来毎日カウントダウンされ変化するはずの「期限までの日数」を毎日入力しなおす必要がないってことだ。「本日の日にち」が更新されれば「期限までの日数」も更新される。こういうのを再評価という。再評価については次の項目でも軽く解説する。

②計算式と再評価

計算式の内容が、その計算式の中で使われている項目の更新に合わせて更新されることを再評価という。上の例だと、「期限までの日数」はその計算に使われる「本日の日にち」の更新に合わせて更新される、という具合。んで、ここは理解できるんだが、ちょっとわからないところがあったのでメモ。

それは、再評価に索引の概念が関係してくるってこと。索引というと、ちょっとまえの記事で軽くまとめたアレだ。俺の中では検索の中で使われるもので、検索の速度をより早くための、リストみたいなものだと思っていた。しかし、この索引が設定されているか否かによって再評価のタイミングが異なるようだ。まあ、よくわかんねえっすね!! 

③関数

 ファイルメーカーにも関数がある。関数がなにかというと、ユーザーがよく使うであろう計算式をある程度まとめておいてくれた便利なやつだ。Excelにもあるアレです。構文もだいたいExcelと同じで、入社以来Excelを主要ツールにしてきた自分にとっては、まあとっつきやすかった。

また面白かったのが、変数宣言用の関数としてLet関数があるってこと。Swiftの定数宣言としてLetがあるけど、それと語源が同じなのかな? つーかファイルメーカーにおける変数っててっきりまあフィールドで代替されるのかと思ってたから、少し意外に思った。けどよく考えればワーク項目の宣言とかのために必要なんだな。

また変数にはローカル変数とグローバル変数があるとも。そこらへんはCOBOLにもExcelにもない概念なので、ちと勉強が必要だなと思った。

④コーディングてきなところ

 関数の一部としてIF関数やCASE関数もあった。これらは条件分岐の関数だ。このノリでFOR文とかまであれば、もう順次・分岐・反復の三要素がそろうことになる。これだけそろえばプログラミングができちゃうので、いつものノリでコーディング可能。

ただし、ファイルメーカーには良いエディタも搭載されていないし、インデント下げようと思ってTabキーを押したら別の項目に移動してしまうので、ウーム。このコーディングのしにくさはどうにかしたいところ。

 

今回は以上。オゥイェ。 

FileMakerの勉強 vol.8(第12章)

勉強。

 

『FileMakerMasterBook 初級編』第12章(データベースの機能を作ろう(入力))

引き続きスクリプトを作って機能を実装していく。

今回の12章で作ったのは下記。

①レコードの追加・削除

②ポータルメニューでの追加・削除

 まあ、ここに書いてもしゃあないので割愛。

 ●入力補助の設定

ここからなぜか入力補助の説明が入った。

①値一覧の設定

エクセルには入力値に制限かけて一覧から選ばせる、みたいな機能があるけどそれと同様の機能がFileMakerにもある。それが値一覧。手順としては値の一覧を先に作っておいて、それを使ってインスペクタから設定すればよい、とのこと。

 ②ドロップダウンカレンダー

日付を入力しやすいよう、キーボードで打つのでなくマウスで選択できるようにしたもの。

プレースホルダテキスト

未入力項目にテキストを表示させることができるやつ。

④その他

・マージフィールド

文字列の最後に敬称をつけるなど。

・ポップオーバーボタン

押すとメニューが出てくるようなアレ。

 ・ボタンバー

 ボタンがいくつか並んだもの。綺麗に並べられる。

 

 まあ今回も単純でしたね。以上!

FileMakerの勉強 vol.7(第11章)

どもっす勉強する。

 

  『FileMakerMasterBook 初級編』第11章(スクリプトの実行)

ここからはスクリプト。ってなんなのかというと、なんだろ、一言で言えば機能のことだ。例えばはてなブログとかでも、画面上部のヘッダー部分に色々ボタンが付いてて、押すと画面が切り替わったりする。そういう機能をスクリプトによって追加できる。

FileMakerスクリプト

一般的なWEBサイトのそういう機能はPHPとかJavaScriptとかで(たぶん)作られている。じゃあFileMakerはどんな言語で機能を持たせるんですか、というと専用のやつがある。

名前が付いてんのかしらないが、FileMakerにはスクリプトを書く画面が用意されててそこでスクリプトを作成可能だ。少し書いてみたが、関数? 的なものが全て日本語で表現されているらしく、まあ使いやすい。

こんな画面。

f:id:MaximoNelson49:20171003192033j:image

画像が見づらくて大変恐縮だが、右側にたくさんの三角形がついてる一覧がある。これが選択できるスクリプトであり、これらの機能を組み合わせて、実現させたい機能を作る、というわけだ。

また、一応これもプログラミングなので、分岐や繰り返しといった処理も可能である。

 スクリプトの実行

機能を作っても、その機能を実行させられなければ使いようがない。テキストにはそこらへんのことも書いてあった。

「何を起因にスクリプトを実行するか」については、大きく3つあるそうだ。

①ファイルのスクリプトトリガ

特定のFileMakerファイルを開けた時に処理が走る。

②レイアウトのスクリプトトリガ

特定のレイアウトを開いた時に処理が走る。

③レイアウトオブジェクトのスクリプトトリガ

 特定のレイアウトオブジェクト(ボタンとか、フィールドとか)がアクティブになったとき、処理が走る。

こういう何かのイベント(ボタン押すとか)によって処理が走るプログラミング言語イベントハンドラ(イベントで制御する)言語って言ったりする。PHPとかJavaScriptとかもたしかイベントハンドラ言語で、まあスクリプト言語ってイベントハンドラなのかもね。ここらへんは適当言ってます。

スクリプトからスクリプトを呼ぶ

システム作ったりしたことある人ならすぐ分かると思うけど、スクリプトから別のスクリプトを呼び出すことも可能だ。

例えば①一から十までの要素を合計してフィールドAに設定するというスクリプトと、②一から十までの要素を合計してフィールドBに設定するというスクリプトを書きたいとする。

このとき、一から十までを合計するってのはスクリプト①②に共通する処理だ。スクリプト①②の作成時にいちいち書くより、一から十までを合計するって処理をスクリプト③として独立させ、スクリプト①②を作るときにスクリプト③を呼び出すほうが楽だ。

んで、処理がより複雑になるほど、こういうことは増える。またこのような共通化を目指さずとも、単にスクリプトが長大になることを嫌ってスクリプトを機能ごとに分けることもある。

 

第11章はこんな感じ。やっと開発らしいところまできた。次も引き続きスクリプトだ。