仕様書のないプログラミングをした
先日、仕様書なし（設計書なし）でのプログラミングを初めてやった。こういうふわっとしたボールの受け取り方は今後必要なスキルだと思うので、反省しとく。
【状況】
●当初
・当初はメモ書き。3日で作って欲しいと言われる。
・IN01のIDを元にDB２つ３つ呼び分けて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.作業に区切りを持たせる
・やり方を最初に考えろ
（どう進めるのか、つまりだらだらとやってしまったのがよくなかった。なんつーか、終わりの見えないコーディング作業だった。何が必要なのかわかってなかった。全体のコーディングをざっくりやって、それからサブプログラムのパラメータ調査をして、、、、とかって考えてない。何のためにそのやり方を整理するのかというと、あれもこれもとなってしまってどこまで終わったのか分かんないし、調査するときも対象範囲が狭まらない。おかしいところがどこなのか、わからない。進んでいる感じもしない）
・マジ面倒クセェ…と思わない
・ダラダラコーディングしない。
・「とりあえず枠だけ」これはいい。が、それをチェックしてもらわないと意味がない。仕様の確認になってない。
・仕事の進め方を相手と握る、相手の責任にする
・次に進んで良いかのジャッジを下してもらう
こういうの、アジャイル開発？てきになる。下記の記事など参照。あと『アジャイルサムライ』とか読む。
2-3.おメンタルの弱さ
・期限は延びたら延びたなりに再度引き直す
・コミュニケーション密に。相手が忙しかろうと聞く。
・結合テストとなった時点で、無限にかかるのでは？ ということは指摘しておけば良かった。スケジュール的なところで未来のタラレバ考えとけば良かった。
・あと、コーディングについての細かな指摘（ここはフラグ使わなくてよくない？）とかに対してうまく反応できてない。意図を読み取れなかったり。
こんな感じ。もちっとしたらもっとわけわかんない開発しそうなので、単独で動けるようになっときたい。あとおメンタル。以上！！
FileMakerの勉強 vol.9（第13章）
どもっす勉強する（この記事３回消えました。）
『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章（スクリプトの実行）
ここからはスクリプト。ってなんなのかというと、なんだろ、一言で言えば機能のことだ。例えばはてなブログとかでも、画面上部のヘッダー部分に色々ボタンが付いてて、押すと画面が切り替わったりする。そういう機能をスクリプトによって追加できる。
一般的なWEBサイトのそういう機能はPHPとかJavaScriptとかで（たぶん）作られている。じゃあFileMakerはどんな言語で機能を持たせるんですか、というと専用のやつがある。
名前が付いてんのかしらないが、FileMakerにはスクリプトを書く画面が用意されててそこでスクリプトを作成可能だ。少し書いてみたが、関数？ 的なものが全て日本語で表現されているらしく、まあ使いやすい。
こんな画面。
画像が見づらくて大変恐縮だが、右側にたくさんの三角形がついてる一覧がある。これが選択できるスクリプトであり、これらの機能を組み合わせて、実現させたい機能を作る、というわけだ。
また、一応これもプログラミングなので、分岐や繰り返しといった処理も可能である。
●スクリプトの実行
機能を作っても、その機能を実行させられなければ使いようがない。テキストにはそこらへんのことも書いてあった。
「何を起因にスクリプトを実行するか」については、大きく３つあるそうだ。
①ファイルのスクリプトトリガ
特定のFileMakerファイルを開けた時に処理が走る。
②レイアウトのスクリプトトリガ
特定のレイアウトを開いた時に処理が走る。
③レイアウトオブジェクトのスクリプトトリガ
特定のレイアウトオブジェクト（ボタンとか、フィールドとか）がアクティブになったとき、処理が走る。
こういう何かのイベント（ボタン押すとか）によって処理が走るプログラミング言語をイベントハンドラ（イベントで制御する）言語って言ったりする。PHPとかJavaScriptとかもたしかイベントハンドラ言語で、まあスクリプト言語ってイベントハンドラなのかもね。ここらへんは適当言ってます。
システム作ったりしたことある人ならすぐ分かると思うけど、スクリプトから別のスクリプトを呼び出すことも可能だ。
例えば①一から十までの要素を合計してフィールドAに設定するというスクリプトと、②一から十までの要素を合計してフィールドBに設定するというスクリプトを書きたいとする。
このとき、一から十までを合計するってのはスクリプト①②に共通する処理だ。スクリプト①②の作成時にいちいち書くより、一から十までを合計するって処理をスクリプト③として独立させ、スクリプト①②を作るときにスクリプト③を呼び出すほうが楽だ。
んで、処理がより複雑になるほど、こういうことは増える。またこのような共通化を目指さずとも、単にスクリプトが長大になることを嫌ってスクリプトを機能ごとに分けることもある。
第11章はこんな感じ。やっと開発らしいところまできた。次も引き続きスクリプトだ。
育休っていう国の制度使えば給料の8割くらいの手当てがもらえるらしいじゃん？？？
どうもmaximonelson49です。短いやつ書くよ。
京大の男性准教授が育休を取って知った“後悔”とは〈dot.〉
って記事読んだ。んで、せやせや！ ってめっちゃ思ったので記録。
男性正社員に「育休を取得しなかった理由」を尋ねると、その主要トップは、「職場が育休を取得しづらい雰囲気だったから」（27％）、「会社で育休制度が整備されていなかったから」（26％）、「残業が多い等、業務が繁忙であったため」（21％）、「休業取得による、所得減等の心配があったから」（19％）とつづく（2015年厚労省委託調査）。
たしかに、所得についていえば、育休を取得した期間は、手取り月収が8割ほど（生後半年目からは6割ほど）になり、取得期間に応じてボーナスも減ってしまう。
しかし、「会社で育休制度が整備されていなかったから」は、本来理由にならない。育休は、1年以上雇用されていて近々に契約満了しないならば、基本的に誰でも（非正規雇用労働者でも）制度上は取得できる。会社で育休制度が整備されていなくても、取得できるのだ。
この事実がもっと知られるようになれば、取得希望率はもっと高まるかもしれない。というのも、「休業制度・両立支援制度が会社に整備されていなくても法律上、制度の対象であれば利用できることを知っていた」のは、男性正社員のたった32％で、取得希望率36％とほぼ同率だからだ（2015年厚労省委託調査）。
（太字は俺がつけてます）
育休が会社の制度だと思われてる、って勘違いは本当に多い。子持ちじゃない人に特に多くて、俺が「育休とりますよー」と言ったとき「よく取れたね」とか「いい会社だね」とかのリアクションをとる。が、これは会社ではなくて国の制度だ。最長一年（場合によっては一年半）の育児休暇と、その間の給付金は国の制度だとして認められている。
給付金について言えば、記事にある通り最初の半年は直近半年の給与の8割ていどが支給される。支給額自体は育休半年までが6.6割、半年から一年までが5割なんだけど、社会保険料（健康保険料と厚生年金保険料）が全額免除になったり、自治体によっては住民税も減免されるところがある。かつ、収入もゼロ扱いなので所得税だってかからない。ここらへんの税金関連の免除で6,7万くらいが浮く。そんなこんなで、俺は毎日定時退社で働いたときと同じ額の給付金が得られることになった。働かないで金が貰えるなら働きたくない。ので俺は育休を取った。（もちろんそれは育児休暇取得直前の半年間で残業をそれなりにした計算だからなんだが）
まあそんだけ。今回は以上です。
FileMakerの勉強 vol.6（第10章）
はい勉強。
『FileMakerMasterBook 初級編』第10章（データベースの画面を作ろう）
タイトル通り、今回からは画面作り。8章とかで作ったテーブルたちに対する画面をつくる。
●レイアウトモードからの詳細画面作成
基本的にはこんな流れ。
- 必要となる画面を考える
- FileMaker提供の大枠の中から画面を選ぶ
- レイアウトを決めフィールドを配置する
こんなん。
1,2はまあいいとして、3番を今回は色々と触った。覚えときたいのが下記。
①画面を作るためにテーブルオカレンスを作る。
なんだか理屈が分かってないんだが、8章で用意していた３つのテーブル（タスク、担当者、添付ファイル）の他にそれらをそれぞれコピーしたタスク管理、タスクの担当者、タスクの添付ファイルという３つのテーブルを、リレーションシップのダイアログで作成した。
なんでこれわざわざ存在してるやつもう１つ作ったんだろ？ バックアップか？
②画面に紐付けられるのは単独のテーブルのみ
画面を作るときに対象のテーブルを指定する。画面に表示できる項目は、そのテーブルに限る。ただ、そのテーブルと関連付けた上でリレーションシップのオプションからテーブル作成を許可すれば、ほかのテーブルの項目も置けるようになる。
③レイアウトの配置がクッソ操作性悪い
愚痴だけど、操作しづらい。FileMakerは基本的にMac用のソフトなんだが、今回自分はWindowsから触ってて、そのせいかクッソ操作性が悪い。せめてエクセルのオートシェイプ並みにしてくれ。あとマジで米粒みたいなボタン操作を要求される。全然ユーザーに優しくない。高齢者は使えなくないですか？ FileMaker。
●ブラウズモードでの入力
詳細画面が作れたので、入力してみる。が、ここにきて上手くいかないことが出てくる。
①何故か他のテーブルから引き込んだフィールドの入力情報が保持されない。
入力はできるんだが、地のエリアを触ると情報が消えてしまう。他のフィールドに行く、とかだと消えない。なんなん？？？
テラテイルにも起票してみたが、反応なし。
https://teratail.com/questions/94544
➡︎ リレーション付けをしていたデータ間で、タイプの齟齬があった。だから紐付けすることができず、入力にも影響出てたっぽい。なるほど！
②バージョン管理
FileMakerは自動保存なんだが、これバージョン管理どうすんだ。作りかけで置いとくとか出来ないのか？？？？？分かんねーな。
③スライドコントロールのレイアウト
テキストにはタブコントロールのボタンを長押しでスライドコントロールが出る、と記載あるが、出ない。うーん、Windowsだとやっぱりだめなのか？
➡︎ できた。プルダウン？で選べた。
④タブ順の設定
タブキーで次のフィールドを選択する、みたいなの、普通のWEBサイトとかでもあるじゃないすか。ああいうのの設定ができた。ここではどのフィールドが対象で、どの順番で選択されるのかを設定できる。あら嬉しい。
こんなかんじの画面。
これ、分かりますか？沢山矢印があって、その矢印ついてるフィールドはタブで選択できるフィールドなわけです。んでね、この操作はタブ順の設定なんすよ。順番。あれ、どこで順番設定すんのかな？って思ったらさあ。
だからなんでそんな米粒みてえなサイズなんだよ！！！！ 視力検査でひらがな読ませるやつじゃねーか。ちなみにこれ俺は眼鏡かけても順番完全に分かりません。
うーん、まさか公式テキストで煮詰まるとは。今回は以上。直ったら更新するかも。
FileMakerの勉強 vol.5（第8,9章）
どもですmaximonelson49です。
『FileMakerMasterBook 初級編』第8章（新しいデータベースを作ろう）
この章からやっと、本格的にデータベースを作るような感じになってきた。ので、ここからはほとんどが細かい操作方法の説明だ。いちいち書いてもしょうがないし、簡単にこんなことが書いてあった、とだけまとめる。
また、テキストではゼロからデータベース作る感じのことが書いてあり、どんなデータベースにします、みたいなデータベース設計のところにも少しページが割かれていた。システムを作るときはなんでもだが、もっともキモなのはこの設計の部分だ。どんなふうに考えて設計するのか。そこもちゃんとまとめたいんだが、現段階ではちとまとめようがないので、割愛させてもらう。
下記、書いてあったことまとめ。
●フィールドオプションについて
①新規データベースファイル
②データベースの管理オプション
[ファイル]タブ⇨[管理]⇨[データベース]からデータベースの管理オプションにいける。以降の作業はこのオプション画面で行われた。
③テーブルの作成
④フィールドの作成
⑤フィールドオプション 自動入力
タイムスタンプや作成者のアカウント名を自動入力させることができる。ハウスキーピングフィールドにこういうの設定する。また、デフォルト値の設定もできる。
⑥フィールドオプション 入力値の制限
タイプとか上限下限とか。計算式で制限かけることも可能で、ここで簡単なデータチェックのモジュール作ったりするのだろうか？ と思った。それとも外部化できたりすんのか。
あと間違った値が設定された時のポップアップとかも、ここで設定できる。
⑦フィールドオプション データの格納
グローバル格納（すべてのレコードに同じ値をいれるやつ）の設定など。またオブジェクトデータ（添付ファイルとか）を外部に持っといて、そこと紐付ける設定とかも。
●データベースの見た目
レイアウトの作成。FileMakerは単なるデータベースだけでなくて、表示させる画面まで作れる。その画面のレイアウトをどのように考えて作るのか？ の部分。
①使うシチュエーションを考える
②そのとき、ざっくりどんな画面になるか考える
これは一覧形式がいいなとか詳細画面がいいなとか印刷画面が必要とか、その程度の話だ。
③どんな画面の遷移が必要か考える
一覧画面からは詳細画面に画面が遷移できると便利だな、とか。
詳しいところは次の章で扱うようだ。
『FileMakerMasterBook 初級編』第9章（レイアウトの種類やツール）
ここではレイアウトモードの簡単な説明があった。さっと示す。
①レイアウトは大きく3種類
コンピュータ、タッチデバイス、印刷の3種。
②レイアウトのツール
主要なのはインスペクタとフィールドピッカー。インスペクタでだいたいのレイアウトいじりはできる。フィールドピッカーではフィールドの配置？ができる（どういうことだろ？）
③画面構成
レイアウトモードには基本となる画面の構成がある。 例えばそれはナビゲーションのエリアだったり。いじれないところはFileMaker自身の機能に属するので、Appの完成品にはたぶん表示されない？ のかな、わかんねえ。
今回は以上。簡単でしたね。
