なぜウォーターフォール型の受託開発では終盤に問題が起きがちなのか
結論から言うと
「システムの発注者が受注者に対して設計段階で適切なフィードバックをできていない」
から。
はじめに
これは個人的な経験に基づく意見であり、観測範囲はすごく狭く、広範囲の調査を行ったものではありません。あくまで個人的にはこうだったから、こうなんじゃないかなという仮説とポジショントークてんこもりの話です。
前提とか背景とか
私の経験では受託開発の受託側で仕様の検討から実装・テストまで担当することが比較的多く、また、システム開発にあまり詳しくない発注者が、実際にシステムの開発を行う受注者に発注する開発スタイルが多かったです。
また、開発体制などの都合からまっとうなアジャイル開発やスクラム、テスト駆動開発をやったことがありません。
また、この記事での機能仕様書とは、システムの振る舞い=どういう入力があって、どのように処理されて、どのように出力されるかを定義したものであり、Joel on softwareで述べられているところの機能仕様書を想定しています。
場所によっては外部設計などとよばれているかもしれません。
影響を受けているもの
リーンソフトウェア開発の作りすぎの無駄を極力避けるという考え方に、Joel on Softwareの機能仕様書の考え方を混ぜた感じと言ったらいいんでしょうか。
ろくに仕様の検討や設計もせずに先に実装を進めてしまうと、間違って作ってしまった実装やテストの修正コストが無駄になり、何より貴重な時間というリソースを浪費してしまうので、分かる範囲で仕様の検討や設計を行ってから実装しよう。 仕様書の修正コストは実装の修正コストよりも低いからなるべくそこで問題を見つけよう。 仕様書にはシステムがどのように振る舞うか、入力に対してシステムがどのような反応をするか、具体的に、詳細に、網羅的に記述しよう。
そんな考えです。
これまでの経験をふりかえる
私がやってきた仕事の範囲でいうと、発注者側からまともな機能仕様書をもらったことも、発注者の代わりに機能仕様書を作成してその仕様に対して文言・フォーマット・体裁以外で設計に関わる重要なフィードバックをもらった事も、残念ながらほとんどなかった。
これは別に「私の機能仕様書作成能力が高いからフィードバックが無かった」とかそんな理由ではない。 他人が書いた機能仕様書であれば、多かれ少なかれ考えが違う部分はあるはずで、ここはこうしてほしいとか、そういうフィードバックは少なからずあったはずだ。
私の機能仕様書作成能力が低くて、発注者が読んでも分からなかったからフィードバックが無かった？ 別に分からないなら分からないでそのことをフィードバックすればいい話だ。
だが、そういったシステム開発を行う上で重要なフィードバックはほとんどもらったことがなかった。 20年ほど前にウォーターフォール型の開発をした時もそうだったし、最近ウォーターフォール型の開発をしたお客さんもそうだった。
ウォーターフォールと修正コスト
一般的なウォーターフォール
一般的なウォーターフォール型の開発はこんな感じ。
バグの修正コスト
で、設計時の問題が後工程になるほど修正コストは指数関数的に跳ね上がる。
http://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf
図は2009年のもので、オンラインでアップデートが当たり前になった現在の状況はどうなっているか不明だけど、それでも稼働中のシステムの修正には注意と慎重さが必要なので、そのまま利用できると思っている。
この修正コストをウォーターフォールの図に反映するとこうなる。
本来のウォーターフォール
本来のウォーターフォールでは、開発の各工程で見つけた問題を前の段階にフィードバックする前提があったとか無かったとか。
うん、適切にフィードバックがあれば、バグの修正コストの問題が解決できそうですね。 適切にフィードバックがあれば。
でも、なんで今になってもいつもシステム開発の終盤になってから重大な問題が見つかっているのか？ バグの原因をたどっていくと、仕様の検討不足や考慮漏れが多いのはなぜなのか？ 仕様書のレビューで平仄やフォーマットの指摘が多めになり、設計に関わる部分でのまともなフィードバックが少ないのはなぜなのか？
ウォーターフォールの工程が会社をまたがって分断されている
まず、ウォーターフォールの工程が会社をまたがっており、分断されていることが原因の1つに挙げられる。 契約や納品が絡んでくると、前工程の成果物が間違っていたから修正するというのは難しくなる。 問題がみつかっても、「すでに納品しちゃってるし」「修正するとやり直しが手間だし」「原因究明の報告書を書かないとならんし」みたいな感じで適切なフィードバックがしにくくなる。
本来のウォーターフォール開発では各工程を会社をまたいで行う前提はなかったんじゃないか？
システムの発注者が機能仕様書を読めないのではないか？
会社間をまたぐのが多少手間でも、納品前であればフィードバックはできるはず。 しかしそれすらできていないのはなぜか？ もしかして、発注者が書いてもらった機能仕様書を読めていないのではないか？
本来のウォーターフォール開発が提案された時期、大昔のシステム開発は組織内で行うものであり、システム開発に詳しい発注者が仕様を決めるものであり、その前提だったのではないか？
一方で、現代の日本においてはシステムに詳しくない発注者がシステムの開発を依頼するパターンが多いのではないか？
だとすると、システムの発注者がシステムの受注者に機能仕様書を作成してもらったところで、機能仕様書の内容を読み込めず、そのためレビューでは設計に関わる指摘よりもドキュメントの平仄やフォーマットの指摘が多くなり、問題が後工程まで残存し、実際に受け入れ段階になって動かしてみて初めて問題に気づくのではないか？
ではどうするか？
システムの発注者が機能仕様書を読めない、仕様のレビューでフィードバックもできないのだとしたら、根本的に開発プロセスを変える必要がある。
いくらちゃんとした機能仕様書を書いても受け入れテストのときに「思ってたんと違う」をやられて無駄だから、先に動くものを作って確認してもらおうぜっていうアジャイル的開発スタイルにするしかないし、そのスタイルが流行るのもわかる。
しかし、発注側にシステム開発の経験が少ない場合、こういったアジャイル的開発スタイルを利用しても開発コストは減らないし、システム全体の完成時期も早くならない。逆に前工程での無駄を削減できない分開発コストは増えるし、システム全体の完成時期も伸びる。 とりあえず動いているシステムだけは手に入ることだけが救いだ。
結局、先に動くものを作って確認してもらおうぜっていうスタイルであっても発注者側の力量を上げないと解決しない問題なのではないか？
理想的には
- 実際に作って動かして確認する部分と、機能仕様書を先に作成して開発の無駄を削減する部分を分けること
- システム発注者が機能仕様書をレビューできること
- システム発注者が機能仕様書をレビューできないのであれば、その分増える開発コストを負担すること。
システム発注者に言いたいこと
いくらシステム開発を依頼して作ってもらっているとはいえ、どういうシステムを作って欲しいかは依頼者が決めなければなりません。仕様を提案してもらったり、他人に書いてもらってもいいですが、その仕様をレビューしてフィードバックを行う責任は発注者側にあります。
この世の中にまだ存在していないものを作ろうとしているのですから、「全部おまかせしますからいい感じで」では本当にほしいシステム、役に立つシステムは手に入らないでしょう。
具体的には
- あなたがほしいと思っているシステムは、まだこの世には存在しておらず、実現可能な仕様として文書化され、網羅されていなければ作ることができません。まずそのような仕様書があれば出してください。
- そのような仕様書がなく他人に書いてもらうのなら、仕様書を書いてもらうために必要な打ち合わせの分のお金もちゃんと払ってください。
- 他人の時間と頭脳は無償のリソースではありません。
- また書いてもらった仕様書のレビューを行い、自分がほしいと思っているシステムと一致しているかの判断と、設計への具体的なフィードバックが必要です。
- 以上の全てができないのであれば、実際に動くものを作ってもらって、それからフィードバックをかけるしかありません。そのせいでよけいにかかる実装やテストなどの時間的、金銭的コストはあなたが負担してください。
最後に
こういう事を書いてますが、 「仕様を誰かに決めてもらって、決まったモノをそのまま作りたい」 という考えではなく、
- 自分で良い仕様や適切な仕様を考えたり、提案したりしたいけど、それを無償でやらせられると商売あがったりなので、他人の時間と頭脳に金をちゃんと払え。
- 設計でなるべく品質を向上させて、バグが後工程に流れることで発生する無駄なコストを削減したい。
- いちいち作ったあとで間違いだったと気づくのは無駄なので、問題になりそうなところは先に文書という形で明確化し同意をとっておく。
やってみなければ分からない部分はもちろんあるけど、実際に作る前に机上で検討することで削減できるコストもある。 ならば、それぞれを区別して無駄を少なく開発できればいいな。 そういう感じ。
Ergo42(Towel)をLEDテープでアンダーグロウ化した
はじめに
LEDテープを使ってErgo42Towelのアンダーグロウ化に成功したので、記録を残しておきます。
SK6812miniを搭載したLEDテープを利用したので、Ergo42本体に付属しているスペーサーを交換せずにアンダーグロウ化できました。
※この改造は自己の責任で行ってください。
参考にさせて頂いたもの
#ergo42 のアンダーグローですか。左は、こんな感じです。Dinはオレンジから入ってDOの茶色に抜けます。GNDの黒は見えづらいので、拡大して見てください pic.twitter.com/LfT3nOisfa
— Lime (@lime55) 2019年5月30日
目次
必要な材料
- 超極細 NeoPixel MiniテープLED(テープ幅4mm SK6812)
- LEDパラダイスで購入(https://www.led-paradise.com/product/2277)
- よくあるLEDテープはテープ幅が10mmですが、キースイッチの端子の間を通すために超極細 NeoPixel MiniテープLEDを選択
- 小さくなればなるほどLEDテープのはんだ付け用のランドも小さくなるので注意。
- AWG24相当の配線
- 今回つかったのは住友電工製のイラックスA
- カプトンテープ
- 基板のスイッチをはんだ付けした部分とのLEDテープ絶縁のため。
- 6mmと10mmを使った。
- フラックス
- LEDテープのはんだ付け用のパッドおよび導線に塗ってはんだ付けしやすくする。
必要な工具
- ワイヤストリッパ
- 曲尺(かねじゃく)
- LEDテープをコの字型に配置したので直角を作るのと、縦と横のLEDテープの相対位置を決めるのに利用した。
- ピンセット
- 配線を持ってはんだ付けするために必要。
作業手順
LEDテープを接続する端子の特定
- Ergo42のKiCadデータを見てVCC, GND, TX0, TRRSジャックのXTRA DATAを見つけておく。
- Ergo42左手側のTX0から左手側LEDテープのData-INへ、
- 左手側LEDテープのData-OUTからErgo42左手側のTRRSジャックのXTRA DATAへ
- Ergo42右手側のTRRSジャックのXTRA DATAから右手側LEDテープのData-INへ
左手側
右手側
LEDテープ配置の検討と切り出し
- Ergo42の基板に切り出す前のLEDテープを重ねて、どのように配置するか検討する。
- LEDテープから利用する分のLEDテープを切り出す
- 今回は片手分を 縦LED3個x2, 横LED6個 x1にした。
- 今回は4mmのLEDテープを利用したので、スイッチの端子の間に通すことができた。
※LEDテープの側面がキースイッチの足に触れないように注意する。
LEDテープ同士のはんだ付け
LEDテープ同士をはんだ付けしたらErgo42の基板上においてみて問題ないかチェックしつつやると良い。
- 切り出したLEDテープを実際に配置する場所において、曲尺(かねじゃく)で縦のLEDテープと横のLEDテープの相対位置を調べる。
- はんだ付けマットの上にLEDテープを移して、調べたLEDテープ同士の相対位置を再現して、マスキングテープで固定する。
- 配線材を切り出す。
- 今回利用した配線材はあまり柔軟性が無いものだったので、事前にちょうどよい長さになるように切り出した。
- 配線材をはんだ付けする。
- LEDテープ側にはんだを盛っておく。
- 剥いた配線材にもフラックスを塗っておく。
- はんだがブリッジしやすいので注意。
- はんだ付けした部分がブリッジしていないかテスターの導通モードを使って確認する。
- 真ん中のData-IN/Data-OUTとVCCは導通していないこと。
- 真ん中のData-IN/Data-OUTとGNDは導通していないこと。
- 接続したLEDテープ同士のVCCとVCCは導通していること。
- 接続したLEDテープ同士のGNDとGNDは導通していること。
- 接続したLEDテープの末端同士のData-INとData-OUTは導通していないこと。
Ergo42とLEDテープのはんだ付け
TX0へのはんだ付けはProMicroを外して、他の端子にはんだが付着しないようにカプトンテープなどで保護しておく。 また短い導線からはんだ付けすると良い。
- Ergo42の基板上にLEDテープを仮止めする。
- 配線材をちょうどよい長さになるように切り出す。
- 配線材をLEDテープにはんだ付けする。
- LEDテープから出ている配線をErgo42の基板にはんだ付けする。
Ergo42の端子とLEDテープが正しくはんだ付けされているかテスターで導通チェック
- 左手側
- Ergo42のVCCとLEDテープのVCC
- Ergo42のGNDとLEDテープのGND
- Ergo42のTX0とLEDテープのData-IN
- LEDテープのData-OUTとErgo42のXTRA_DATA
- 右手側
- Ergo42のVCCとLEDテープのVCC
- Ergo42のGNDとLEDテープのGND
- Ergo42のXTRA_DATAとLEDテープのDATA-IN
Ergo42のアンダーグロウLED対応ファームウェアを書き込む
RGBLIGHT_LIMIT_VALがデフォルト値のままだと電力不足で不安定になるため、最大輝度に制限を入れる。
デフォルト値のままRGBLED_NUMを14から24に増やしたところ、 一瞬だけテープLEDが光って消えるようになり、リセットスイッチを押してもファームウェアの書き込みすらできなくなってしまった。 ProMicroを取り外して、RST端子とGND端子をピンセットで短絡させ、ファームを書き込んで戻したところ問題なく動作するようになった。
※TRRSケーブルを外してファームウェアを書き込む
※左手、右手とも同じファームウェアを書き込む。
- qmk_firmwareのkeyboards/ergo42/keymaps/default-underglow以下のconfig.hに以下の変更を入れる
- RGBLED_NUMを14から24に変更する。
- 「#undef RGBLIGHT_LIMIT_VAL」を追加する
- 「#define RGBLIGHT_LIMIT_VAL 128」を追加する。
- コマンドラインから「make ergo42:default-underglow:flash」を実行してファームウェアを書き込む。
テープLEDを仮止めして動作チェック
テープLEDのはんだ付け部分がErgo42のはんだ付け部分に接触しないように、マスキングテープなどで覆ってから動作チェックを行う。
まずは左手側のみで動作チェックを行う。
問題なければ右手側もTRRSケーブルで接続して動作チェックを行う。
右手側だけではテープLEDの動作チェックはできない。
Ergo42の基板にカプトンテープを貼ってパターンとスイッチのはんだ付け部分を絶縁
LEDテープを貼って完成
環境センサviewerというAndroidアプリを作った
どういうアプリ？
Omronの環境センサ2JCIE-BL01の測定データの読み取り、測定データのグラフ表示、測定データのエクスポートができるアプリです。
環境センサ2JCIE-BL01を使ったデータ観測の例では、環境センサの動作モードをデータ保存なしのビーコンモード(IM/EP)に変更して観測する例が多いのですが、他のアプリとの同時利用も想定してデータ保存ありのモードでの運用ができるようにしました。
できること
- 環境センサの現在の測定データの読み取り
- 環境センサ内の過去の測定データの読み出し
- アプリ内に取り込んだ測定データのグラフ表示(最大二週間まで)
- アプリ内に取り込んだ測定データのTSVエクスポート
- 環境センサの測定間隔の変更&内部タイマー設定
作った動機
- スキルアップ
- KotlinでAndroidアプリを1本つくってみたい。
- 既存アプリへの不満
- 複数の環境センサーのデータが読めない。
- データのエクスポートができない。
- 動作が不安定
- わざわざアカウントつくらないと使えない
- 日時設定にタイムゾーン周りのバグがあるらしく、時刻が9時間ずれる。
アプリを作る過程で習得したこと
- Kotlinをそこそこ使えるようになった
- AndroidでBLEデバイスを扱えるようになった
- Omronの環境センサを扱えるようにった
- 環境センサから測定データを読み出す
- 環境センサから読みだしたデータを加工して表示する
- 環境センサから読みだしたデータをアプリ内DB(Room)に保存する
- アプリ内DBに保存したデータを利用して測定データの差分読み込みを行う
- Android Jetpackを扱えるようになった
- DataBinding
- LiveData
- Room
- Navigation
- その他
- グラフ描画ライブラリandroidplotの利用
必要になりそうな新しい技術を、別の実験的なプロジェクトで試してみて、おおよその使い方が分かって行けそうだと思ったらアプリに組み込むという事を繰り返していました。
苦労したところ
測定データの差分取り込み
とくに何も考慮しない、アプリ内の取り込み済みのデータと、環境センサの現在の測定データまでの差分取り込みだけは割と楽に実装できましたが、 環境センサのリングバッファ構造を考慮した差分取り込みのための工夫とか、 環境センサが測定間隔の変更などを行うと最新ページが0にリセットされるので、その後どうやって差分取り込みを行うかとかで2,3回くらい内部の方式を変更しました。
グラフ表示に使ったAndroidplot
サンプルは豊富にあったんですが、日時でグラフを表示する例がなくて試行錯誤が必要でした。 まだ表示に改良の余地があるかなと思います。
Android BLEの133エラー
やっぱりよくわからん。 端末のbluetoothのON／OFF切り替えで直るときもあるし、だめなときはだめだし。
アプリに組み込んだ便利だったライブラリ
- peko
- https://github.com/deva666/Peko
- AndroidPermission用のライブラリ
- Perrmission関係のコールバックをcoroutineやLiveDataなどに置き換えられる。神
- 特にViewModel側でPermissionが必要な処理を一旦Activityに戻して処理する必要がある場合に便利。
- able
- https://github.com/JuulLabs-OSS/able
- AndroidのBLE用のライブラリ
- これもBLEのコールバック部分の処理をcoroutineに置き換えられる。神
- androidpolot
- http://androidplot.com/
- グラフの表示用
- MPAndroidChartでは精度がfloatしか使えず、今回の用途には不十分だったので。
- databinding-ktx
- https://github.com/wada811/DataBinding-ktx
- DataBindingを使った時のbinding用変数の初期化をかなり楽にしてくれる。神
つくってみて
ちょっとずつですが、機能が増えていくのが楽しかったです。
XD75Reを組み立てた
今回のキーボードの構成
- XD75Re Type-C
- 60% ポリカーボネートケース
- XD75RE用ステンレスプレート
- Kailh Box Royal 80個(必要75個,予備5個)
- DSA PBT レーザーエッチングキーキャップ(DOLCH)
組み立て
はんだ付け箇所はなし、スイッチはめてネジ止めするだけのハズだったんですが、ポリカーボネートケースの加工が必要だったのと、使用したステンレスプレートの制限から、PCBをケースにネジ止めした後にスイッチを固定する必要があるなどハマりポイントがありました。
ポリカーボネートケースの加工
XD75Reにはケース側の面にキースイッチ用のソケットとダイオードがついているため、 そのままだと60%のポリカーボネートケースについているネジ止め用の突起が邪魔になって組付けできませんでした。
どこかで買ってきた3本組(平、丸、半丸)で売ってるヤスリを使って、ネジ止め用の突起を削って対応しました。
※PCBのリビジョンや、ケースのモノによっては加工方法が変わるかもしれないので、現物に合わせてください。
加工箇所
- ネジ止め用の突起を削る 3箇所
- USBケーブル接続用の口の拡張
左上のネジ止め用の突起を削る
赤がMXソケット用に削った部分で、 緑がダイオード用に削った部分です。
真ん中のネジ止め用の突起を削る
ガタつかないようにするには、 ここが一番重要かも。
MXソケットに対応するためにかなり深くまで削ります。
右上のネジ止め用の突起を削る
ここもMXソケットに対応するために、かなり深くまで削ります。
USBケーブル接続用の口の拡張
手持ちのケーブルだと根本までちゃんと刺さらなかったので、ヤスリで削って穴を拡張しました。
ポリカーボネートケースへの組付け
XD75Re用のステンレスプレートですが、空いているネジ穴が小さすぎて、PCBとポリカーボネートケースを止めるためのネジをステンレスプレートの上から通すことができません。
また、ステンレスプレートに空いている穴を通るような ドライバーも手持ちではありませんでした。
つまり、PCBとステンレスプレート、キースイッチを組み付けた後ではポリカーボネートケースに固定することができません。
先にPCBをポリカーボネートケースにネジで固定したあとで、キースイッチを組み付ける必要がありました。
はんだ付けが必要なタイプのXD75Amだったら詰んでたかも。
PCとの接続
macとXD75ReをType-C to Type-Cのケーブルで接続しても、電源が入らないみたいでキーボードを認識しませんでした。
Type−C to Type−Aメスの変換ケーブルをかまして Type−C to Type−Aメスの変換ケーブル --> Type-Aオス to Type-Cケーブルという形だと電源が入りました。
kbdfansのkbd75v2では同じType-C to Type-Cケーブルで認識しているので、XD75Reの方の問題だと思います。
解体して確認するのが手間なので確認してないんですが、どうもXD75ReのType-Cコネクタ側にUSBデバイス(Upstream facing port (UFP))として認識させるために必要なプルダウン抵抗が入っていないらしい。
キーボードブリッジを作った
Amazonに売ってるクリアーのやつはやたら高いし、 アクリル板1枚だしレーザー加工機で作れそうだなって思ったので作ってみた。
設計
mac book pro 13インチのおおよその寸法を採取
- 本体の横幅が300mm
- 本体の上端からキーボードの下端までの縦幅が120mm
- トラックパッドの横幅が135mm
PFUのを参考にトラックパッドにかからないように適当に下に20mm伸ばして、凹みを作る。
できたデータ
※見やすいように線幅を広めにしてあります。 レーザー加工機の仕様に合わせて線幅や線の色を調整してください。
切り出しデータの作成ソフトと出力形式
切り出しデータは利用するレーザー加工機に合わせて作る必要があります。
私がよく利用しているFabLab世田谷のレーザー加工機では、Adobe Illustratorで切り出しデータを読み込める形式になっていないといけないため、Adobe Illustratorを使うのがまっとうな方法なのですが、 年に数回程度のちょっとしたレーザー加工のデータを作るのに使うには値段が高すぎるため、Affinity Designerを使って以下のようなフローで加工しています。
- Affinity Designerを使ってデータを作成
- データをPDFで出力してUSBメモリに保存
- FabLabのAdobe IllustratorでUSBメモリに保存されたPDFを読み込み
- Adobe Illustratorで最終的な調整を行って加工データを保存
これまでの経験から言うと、なんだかんだでPDFが一番安定して読み込めるみたいです。
Inkscapeから出力したPDFでも加工できなくは無いんですが、Inkscape自体の操作がいろいろとつらいのでAffinity Designerを使っています。
テスト印刷
紙に印刷してmac bookの実物に合うか試してみようとして、セブンイレブンのネットプリントで出力してみたところ、微妙に縮尺がずれていたり、端っこがかけていたりとあんまり参考にはなりませんでした。
A4ギリギリサイズのデータだったので、余白のあるB4の紙の中央に印刷したらなんとかなったのかも。
素材
- アクリル板(270x320×3mm ガラスカラー)
- ゴム足
東急ハンズでアクリル板を買ってきました。
東急ハンズには135x320x3mmの板があったようなので、 トラックパッド用の凹みとか角の加工とか気にしなければこれで間に合うかも。
はざいやさんだと 220x300x3mmのサイズのアクリル板があるけど、 余白がまったくなく加工が難しそうだったので、 今回は使いませんでした。
切り出し
FabLab 世田谷のレーザー加工機を借りて切り出しました。
※機器を利用するには事前に講習を受ける必要があります。
予約を入れて1枠45分 2000円で借りる事ができます。
結果
目論見どおりという感じです。
- レーザー加工機の利用料 2000円
- アクリル板の材料費 2000円
PFUのヤツとそんなに値段が変わらないけど、 まあガラス色がキレイなので良しとしよう。
自作キーボードのアンダーグロウ用アクリルの検討
はじめに
自作キーボードのアンダーグロウLEDがちょっと眩しすぎるのと、 光があまり広がらないので マット加工されたアクリルでもう少しなんとかならないかと、 色んな種類のアクリルでどのように見えるか比較してみました。
比較したアクリル一覧
- 透明アクリル
- 両面マット 透明 カナセライト #77300
- 両面マット 乳半 コモグラス DFA2 446L
- 片面マット ファンタレックス ドリーム D-707M
- 片面マット ファンタレックス ドリーム D-710M
「透明アクリル」と「両面マット 透明 カナセライト #77300」
キット付属の透明アクリルと、 両面マット 透明 カナセライト #77300の比較です。
両面マットでも透明だとあんまり光が拡散しないみたいです。
「両面マット 透明 カナセライト #77300」と「片面マット ファンタレックス ドリーム D-710M」
ファンタレックス ドリームは 高透過、高拡散をうたうアクリルです。
片面マット ファンタレックス D-710Mの方が、 両面マットの透明 カナセライト #77300よりも光が拡散しています。
「片面マット ファンタレックス ドリーム D-710M」と「片面マット ファンタレックス ドリーム D-707M」
D-710Mの方が透明度が高く、すごくうっすらPCBが見えてますが、 D-707MはほとんどPCBが見えません。
D-707Mの方がより光が拡散しています。
「片面マット ファンタレックス ドリーム D-707M」と「両面マット 乳半 コモグラス DFA2 446L」
あんまり違いがわかりません。
結論：アンダーグロウに良さそうなアクリル
「両面マット 乳半 コモグラス DFA2 446L」
- 両面マットで扱いやすい
- 値段が手頃
- 光の拡散具合もファンタレックス ドリーム と比較しても遜色ない
Helixを組み立てる際に工夫した所とか失敗した所とか
はじめに
自作キーボードHelixを組み立てる際に工夫した所とか失敗した所を記録に残します。
モデルは「Helix ステンレス5行版バックライト 両手セット」、 キースイッチはkailhのロープロファイル茶軸と白軸です。
工夫した所
ステンレスプレートのバリ取り
指でステンレスプレートのエッジを触ったときにバリが気になったので、 ヤスリをかけてバリを取りました。
あと角の鋭さも気になったので、角もほんの少し削って丸くしました。
製造時にステンレスプレートの角にもうちょっとアールをつけてほしいかも。
ステンレスプレートの絶縁
同梱されていた絶縁シールがうまく貼れなかったので、100均で買ってきた手貼りのラミネートシールを加工して絶縁しました。
helixのステンレス版のモデルを買うと絶縁用のシールも同梱されてくるんですが、 手先が器用ではなかったのでうまく貼れませんでした。 絶縁用のシール部分がかなり細くてしかも切れやすいんです。
あと、ボトムプレート用のステンレス板も絶縁のためにカプトンテープなんかを貼るといいらしいんですが*1、 幅の広いカプトンテープなんか持ってなかったんで、100均で買ってきた手貼り用のラミネートシールで代用しました。 加工は手間でしたが、割と硬めでしっかり貼れて、見た目もそんなに悪くなかったので気に入ってます。
手貼りラミネートシールを使った絶縁方法
ラミネートシールの厚い方(硬い方)をステンレス板に大雑把に貼って、 ステンレス板に沿ってカッターではみ出た部分を切り落とします。
ネジ用の穴は穴に沿ってデザインナイフを缶切りのように動かして開けます。
フィルムが一部だけつながったままで、きれいにはずれなかったときは、デザインナイフの刃をネジ穴に突っ込んで、 バリをとるような感じでグリッとやります。
刃がだめになるかもしれないので、切れ味の落ちた使い古しの刃を使ったほうがいいかも。
キースイッチのマウント用ステンレスプレートも同様にラミネートシールを貼り付けて穴を開けます。
ラミネートシールを貼った反対側からデザインナイフでキースイッチ用の穴をなぞって切り出します。
実際に組んでみてわかったんですが、ロープロファイルスイッチだと、 helixのPCBとキースイッチのマウント用ステンレスプレートとの間にはほとんど隙間はありません。 絶縁用のフィルムを貼らないとショートします。
失敗した所
熱でバックライト用LEDを壊した
はんだがよく流れて作業しやすいので、いつも270度の設定で作業しているんですが、 270度の設定ではんだ付けしていたら4個くらいLEDを壊しました。
多少作業性が悪くても220度の設定を厳守しましょう。
また、片側のバックライトLEDをすべてはんだづけしてから動作確認をしたら、 どこが壊れているのか特定するが難しく、点灯しないLEDを交換したり、その一つ前を交換したりとなかなか大変でした。
そこで、もう片方のPCBをはんだづけをする際に、以下のことを守ったら1つもLEDを壊すことなくはんだづけできました。
バックライトLEDを壊さないための対策
- はんだごての温度設定は220度
- フラックスは必須。ケチケチしないで基盤とLEDのパッドにたっぷり塗る。
- 1個ずつ点灯するか確認しながらはんだ付けする。
点灯の確認にはhelixのled_testファームウェアを使いました。
マウントプレートにキースイッチを組み付ける際に、キースイッチの爪にダメージを入れてしまった
キースイッチがなかなかマウントプレートの穴に入ってくれないため、 力任せにに押し込んだ所、いくつかのキースイッチのトップ側の爪が外側に広がってしまいました。
この時点では爪は割れてはいなかったので、広がった爪を手で戻して組み付けなおしたのですが、 この時にダメージが入っていたらしく、キースイッチを半田づけした後で貝みたいに開いてしまいました。
最終的に組み上がるまでにはんだ付けした後にキースイッチを5個交換しました。
キースイッチの組み付け対策(案)
おそらく次のような手順が良いのではないかと思いますが、 もう組み上がってしまったので、試すことができません。
また、キースイッチの組み付け時にPCBがたわみ、 バックライトLEDのはんだにクラックが入る可能性もあるので、 おすすめできないかも。
- 最初にマウントプレートに組み付けるのは、4隅と真ん中。
- キースイッチ用の引き抜き工具を使って、左右の爪を少し押し込んでやるとハマりやすいです。
- 4隅と真ん中をキースイッチのマウントプレートに組み付けたら、PCBと合体させる
- 4隅と真ん中のキースイッチをはんだづけ
- まず大雑把に4隅をはんだ付けして固定することでプレートとPCBの間を並行に保つ意図
- あとは真ん中から十字状にキースイッチを組み付ける。
- 組み付けの際に上から押し込むため、マウントプレートがPCB側に落ちる可能性があるので、なにか間に挟むものがあったほうがいいかも。
- 十字状に組み付けたキースイッチをはんだ付け。
- 外周部分を組み付けてはんだ付け。
- のこりの部分を組み付けてはんだ付け。
キースイッチをはんだ付けした後にフラックスクリーナーをかけてしまった
キースイッチをはんだ付けした後に、PCBに残っているフラックスをきれいにしようと スプレータイプのフラックスクリーナーをかけた所、溶けたフラックスがキースイッチ内に侵入してしまいました。
その結果、キースイッチの軸がベタベタになり、キースイッチの交換が必要ではないかと考える程度に軸の戻りが劣悪になってしまいました。
試行錯誤のリカバリ
何回かスプレータイプのフラックスクリーナーをかけてみたものの、ほとんど改善しませんでした。
刷毛で塗るタイプのフラックスクリーナーを軸の周りにたっぷり塗って、 何度もキースイッチを押しながらキムワイプで拭き取るというのを繰り返した所、 ほぼ問題がない程度には回復しました。
しかし、フラックスクリーナーを使ったせいで本来のキーの感触とは違うものになってしまったかもしれません。
その他
フラックスの利用
PCBのパッド部分の色からすると、金メッキ処理されているみたいですが、 フラックスを使わないとはんだの濡れ性が悪く、ツノがたちやすかったです。
使っているはんだとの相性もあると思うんですが、 私の使っているhakkoのヘクスゾールだとフラックスは必須でした。