まもなくデータ復元料金を改訂いたします

物価高騰のあおりを受けつづけてもなお、可能な限り従前の料金体系を維持しつづけるようにあれこれと努力を惜しまず対応してきたのですが、恥ずかしながら元から利幅の少ない設定だったことがアダとなりコスト増を吸収しきれなくなっております。

もちろん毎年のように原価計算見直しはしているわけなのですが、特に昨年からの急激な高騰で資材の調達価格は総上がりですし、電気料金も上がるいっぽうというのが辛いところ

現状ではすでに大半のサービスメニューで間接経費を考慮しない状態ですでに粗利マイナスという惨憺たる状態。税率アップの際に実質的にサービス料金を低く抑えた影響がここにきて目立ってきてます。

さらにカードの大容量化にともなって検査時間が長時間化傾向にあることなど楽観視できる情報がまだまだ無いこのままでは短期間で立ち行かなくなってしまう恐れすら出てくるわと算出した数字どもに脅されています私(笑)、いや笑っていられない。

■本当に検査料金をいただいていない

弊社では検査料金は一部のコースを除き設定しておりません(ドラレココースのみ検査工程が異なるため検査料金が発生しますが、それでも実は検査料金だけになった場合は完全に赤字水準です)。

慎重なお客様のなかには「本当に料金表の通りの請求しかないのはとても良心的なお値段ですね」と、実は他社ではもっと後付けの請求が多かったのでもっと上乗せの請求が来ると思っていたというお話しいただくこともあるわけなのですが、ウチの会社にそんなお客様を騙すような度胸なんてありませんから公表している料金表の内容以外にいただくことはありません。おかげさまでリピート率業界ナンバー1(自称)じゃないかと思うくらいです。

ただ、そのため大容量のカードになればなるほどマイナスになる要素も大きくなるわけなのです。

たとえば同じように成功報酬制をうたっている同業他社さんのように「重度不良なので復元できなくても分解検査料金が10万円かかります」といったよく耳にするような後出しの検査料金を設定してしまえば粗利を割るなんてことも無くなるわけですが、満足いただける結果が出せないことに対して料金をいただくことを恥じるという創業以来のこだわりをもっています。

検査料金をいただいていないという事は、1件1件ほんとに必死になって成果を出さないと直接経費が増し増しになっていくという縛りにもなっています。

さて、お客様の中には電子機器の扱いに詳しいかたもいらっしゃいますが、どちらかと言えばそうでない方のほうが圧倒的多数です。そのためか明らかに真っ二つに折れ曲がっているようなものでも依頼品として到着するのですが、もちろん喜んで受付させていただいております。(これが大抵の場合には指先を火傷するという労災の基なのですけれどね)

同業他社さんでは利益の上がらないであろう仕事(いわゆる成功率の低そうな依頼)は門前払いという姿勢が増えていると伺っています。ですが弊社としてはできるだけ現物を見ずに門前払いするようなことはしたくない、コストとして足を引っ張っているとしても可能な限り間口の広さを継続し気軽に相談してもらいたいという思いです。

■純粋に物価高騰を吸収できる水準に抑えます

ただでさえ復元業者って怪しい存在ですし、世間から暴利を貪っていると思われたって仕方ないとは思っていますし。私だって自前でFDのディスクイメージをダンプして素人ながら対処できていた頃はそう思っていましたし

ですので、とにかく物価高騰分を吸収できるようにという水準に抑えて試算を繰り返しています。もとが粗利割れなんて水準に至っていましたからなかなか難しいところなのですけれども連日頑張って試算しています。

■ただ値上げだけじゃつまらない

ただ、ひねくれものの私としては「ただの値上げ」に留まるのは楽しくない。

適性利益を確保しなくちゃならないのは大前提としても、なかなかさらっと信頼してもらいにくい業界に身を置いている以上、なにか利用してもらいやすい策は残しておきたいと模索を続けております。

その1つが「学割」みたいなもの。

もちろん個人情報保護になにかと気をつかわねばならないこのご時世に学割対象であるという情報すら本当は欲しくない(管理の手間が増えるだけなので)し、じゃあデータの中身を閲覧して判断するかというとそんな検査時間が爆増するだけの無駄なコストをかけてまで割り引くなんて論理的におかしい話

自己申告制というのがもっとも楽だけれど、では言った者勝ちなんて状況になるのは勘弁してもらいたいところで。

ではどうするか、というところなのですが妙案がありません。

修学旅行と思わしき内容に関してのみ自己申告制で、なおかつ部分的な閲覧許可としていただいて学割を適用するなんてことくらいしか思い至らないのですが、そのほか広くご意見をいただきたいところです(ご相談時に提案いただくのもアリですね)

■料金改訂は8月お盆前後の見込みです

方針決定しだい公式サイト側でもちろんアナウンスしますが、公表前から相談などいただいているお客様には当然ながら従来料金での対応を継続しますのでご安心ください

新料金についてもさほど余裕があるわけではないのですが、さすがに2倍なんてわけにもいかず(適正料金シミュレーションでは2倍が最低条件だったのですが)可能なかぎり抑え込んでいます。たぶん1TBくらいの容量のものが一般に広まるまでは耐えられる・・・という期待をこめて。

なんとか7月中に結論を出し8月あたまには公表したいと準備を急いでおります。

■こまった事がただ1つ

できるだけ間口を広く保ち、ダメ元でもまあいいやと預けてもらえるようになれば上等と可能な限り柔軟な対応を心がけておりますおかげか、お客様にも恵まれ、応援いただき、なんとか生かされているなと感謝するばかりです。

ですが、ごくまれに困ったことが起こります。

年間に数件ほどではあるのですが、検査結果をご報告させていただいたり作業指示をいただいたのち、連絡が取れなくなってしまうお客様の依頼品が長期間保管されたままになります。

まったく連絡が取れない場合でも規定により最長6か月間はいつでも納品可能な状態で保管しておりますが、その保管している間も管理はしなくてはいけませんし、物理的に場所も圧迫されます。その管理コストは間接経費に乗るわけですが実は馬鹿になりません

可能な限り連絡が取れるように弊社からもアプローチし続けるのですが、多様なご依頼があるなかでお客様から連絡いただけない限りは勝手に返却するわけにもいかずとても困ってしまいます。

返却不要であれば即座に廃棄させていただくことも対応しておりますし、納品保留のまま保管が必要ということであれば長期保管サービスをご案内させていただくこともできますでご相談いただければ嬉しいのになと頭を悩ませるところです。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

共通テスト手順記述標準言語(DNCL)ってなに?

DNCLの説明ドキュメント

もう何年も前から小学校や中学校でも「情報」という時間があるとか「プログラミング」があるのだとかいう話しを耳にすることが増え、なんとなく漠然としててどんなことをしているのか雲をつかむような印象を持っているわけなのですが。

入門用の学習教材などをながめていると現物のブロックを並べ替えながら流れを作っていくようなものだと未就学児用として準備されていたり、小学生では画面上でスクラッチを並べてプログラムを組んでいたり、中学生になるともうコーディングをしていたりと、思ったよりもちゃんと組ませているじゃないかとヘンに感心してしまうわけです。

■大学入試にも関わってくるとは!

いまや高校生でも当たり前のように「情報」の時間があってプログラミングを学ぶようで、大学入試にもプログラミングの知識が問われるようになってくるのですね。

「プログラミングの知識」とか「ロジカル思考」とか表現していますけれど、結局のところプログラミングそのものの知識を問う問題になってくるようで、そうなると数あまたあるプログラミング言語のどれを標準知識として定義できるのか?という壁が当然ながら出てきます。

なので、いっそのこと世の中に無い 試験のためだけに特化したプログラミング言語(DNCL)で出題してしまおう、というのが大学入試センターのたどり着いた答えのようです。

■私は大昔にCASLを選択しましたが

試験用に特化した言語という共通点だけで思い浮かべてみるとCASLなんてのがあったなあと懐かしく思ってしまう世代なのですが。

あ、個人的に情報処理試験(1種とか2種とか特種とかシステム監査とか呼んでいた頃なのでかなり大昔です)を受けるときにプログラム言語を選択できたのですが、たしか選択肢がFORTRAN,COBOL,CASLあたりの世代で、その当時は「仕様をあらかじめ覚えなくても問題用紙に言語仕様が掲載されるから」という理由だけで仮想の機械語CASLで受けた覚えがあります。

今に比べればとても広く浅く知識を問われる試験だったのでその程度の気持ちで充分だったわけですが、いまや一言で情報処理と言っても領域が細分化されて問われる知識も深くなっていますからなかなか難しいのかもしれません。

■DNCLって何の略?

一説には「Daigaku Nyushi Center Language(大学入試センター言語)」の略称ではないかとの事ですが公表はされていないようですね。DNCL自体は20年ほど前に作られており工業系の生徒を対象とした試験で使われていたようです。

そのDNCLの仕様説明はココで配布されています。(その後より一般的なプログラム言語に近づけるような形で修正が入っているようなのですが、DNCL2で探してもなかなか見つからず今後の出題例の記述とは相入れない記述方法の部分がけっこうありますね)

試験では令和7年度から出題されることとなるようです。ざっくりとした印象ではIPAのITパスポート試験か基本情報処理試験かな?というような広範囲の基礎的な知識を問われるような問題文が例示されていました。

そのなかで、実際に問題文に即した動作ができるようにDNCLで作成されたプログラムコードを見て穴埋めをする、という形で出題されるような問題の作りになっていました。

さて、DNCLの仕様説明をパラパラとめくっているとなにやらなじみのない記述があるなあと思ったわけなのですが(私が不勉強なだけかもしれませんが)命令文が日本語なのはさておき、たとえば以下のような点は押さえておいたほうが良いかもしれません。

共通テスト用の例題
  • 小文字で始まるものは「変数」、大文字で始まるものは「配列」

tensu や goukei みたいに書けば変数とみなされるのはプログラミングではだいたいの言語でお馴染みですが、Tensu や Goukei みたいに先頭を大文字で書くと配列とみなされるというのはなかなか見ない体系かと思います。
配列なのでTensu[0] や Goukei[1,2 ]などのような表現になります。プログラム慣れした方だとうっかり小文字で配列を書いてしまいそうなので注意が必要ですね。

  • すべて大文字の変数は「実行中に変化しない値を保持する」

変化しない値と言えば javaの final だったり swiftの let だったりといった印象でしょうか。「すべて大文字」の「変数」ということなのでなんとなく配列の定義と被っているのが気持ち悪い印象ですが、なかなか普段のプログラミングでも全て大文字というのは通常は使いたくないもの(シフトキーを押しながら入力するのはめんどくさいという理由)なので間違えることはないかと。

  • 文字列はダブルクォーテーション(”)かカッコ(「」)で囲む:修正あり

一般的にシングルクォーテーション(’)かダブルクォーテーション(”)で文字列を囲むものと刷り込まれていますが、カッコ(「」)を使うというのは経験がないですね。ちょっと問題文を読むのに誤解してしまいそうで心が落ち着かない仕様です。

ただしカッコ(「」)で囲む側については今後の例題では使用されていないので廃止された仕様かもしれません。

  • 代入分は左矢印(←)を使う:修正あり

うっかりイコール(=)で代入したくなるのが一般的なプログラミング言語に慣れた方だとおもいますが、DNCLでは左矢印(←)で表現するようです。=で書くよりも直感的な表現ですし動作も見た目通りですね。でもうっかり=と書いてしまいそうですが。

すると右矢印(→)は代入文にはならないのだろうかとふと意地悪心が湧きましたが、残念ながら仕様説明には右矢印は含まれていませんでした。(もし含まれていたらややこしいことこの上ない仕様になりましたね)

ここの部分もすでに今後の例題には矢印(←)の記述がなく、一般的なプログラミング言語で用いられるイコール(=)がさらっと記載されているので仕様変更があったのでしょう。

ちなみに x += 1、とか x++ という感じでよく表現されるようなインクリメント(およびデクリメント)については 『x を増やす(xを減らす)』と言う書き方と記載されていますが、この部分についても廃止になったのかもしれませんし積極的に使う理由がないですね。

  • 比較演算子に「≠」がある:修正あり

not equalについてはよく x != 0 とか x <> 0 (たまに x -ne 0 など)といった具合に記述しますが、DNCLだとそのまんまノットイコール記号(≠)を使うことになります、すげえ。

キーボードで入力することを考えたら『≠』って打ちにくいと思うのだけれどな、手書きだったらむしろ良いという判断なのか。

こちらもさすがに入力のしにくさという問題があったのか、今後の例題ではごくごく一般的な(!=)に差し代わっているようです。

  • 論理演算子は日本語:修正あり

あと、もちろん論理演算子はand, or, not ではなく『かつ』『または』『でない』の日本語化していますので注意しておかないとうっかり間違えそうですね。

なんて懸念していたのですが、やはりこちらも一般的な and, or, not に差し代わっているようで一安心です。

■上述以外はさほど違和感ないかな

変数・配列・文字列・代入文や演算子などの表現では慣れている人ほどうっかりミスを記述してしまいそうですが、それ以外の部分ではさほど心配ないように個人的には思いました。

ただ、制御の範囲が縦線で結ぶような表現をするので、どちらかといえばCやjavaよりもPythonの字下げ構造での記述方法に慣れているほうが違和感ないと思います。

そういえばここにもひとつ、DNCLの説明にはこの字下げ構造が縦線(|)だけで表されていたのに対して、例題では範囲の下端はL字(∟)で表すように記述されていましたのでより直感的にわかりやすい記述へと修正されている様子が見て取れます。

「DNCLだけを使えるようになること」を目指すような教え方はされないと思いますが、やはりこの言語を学ぶだけでは現実には使えない、と、いうか楽しさが見当たらないです。

あくまでもプログラミングってこんな感じの流れなんですよ、ということを体験するという点までがこの言語に与えられた役割だと思いますので、徹底して記憶する必要はまったく無いけれど一般的なものとどこが違うのかというのだけは間違わないようにしておかないと点数は取れないのだろうなと強く思ったしだいです。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/