[VPS] メールサーバを XSERVER にしたよ [SaaS]

疲労困憊ってこういうことなのかな、を実感しているしょっさんです。


悲壮 + メール

今年は精神的にも肉体的にもストレスのかかる事案が多いので、みなさまもお体には気をつけてくださいますよう。

メールサーバの移行先を決定しました!

先日、メールサーバーを比較してみたよ 2017 のとおり、月額 ¥1k未満で利用できるメールサーバを調べて、実際にいくつか試用してみた結果、XSERVER1に決定したことをご報告します。ワーワー

決定した理由をご説明するにあたり、今一度、我が家でのメールサーバに求める要件をご紹介します。

oshiire さんがメールサーバに求める主な要件

細かいところでは色々ありますが、試用しながら最終的に落とし込んだ「絶対必要条件」をピックアップしました。

  1. ユーザが各自でメールのパスワードを変更できること
  2. マルチドメインであり、ドメイン毎にメールフォルダが異なる(ユーザが異なる)こと
  3. バックアップが取得できること
  4. imap/smtp が利用できること

です。各要件と、サーバの機能比較をしてみます。

要件 ConoHa さくら XSERVER KAGOYAメールプラン(共用)
1. △(開発必須) △(ユーザ数制限)
2. △(ドメイン数制限)
3. △(オプション) △(手動/制限あり)
4.

この時点で、ほぼほぼ “XSERVER” 一人勝ちでした。さくらは値段のやすさは相当の魅力がありますが、ドメイン毎にメールボックスはやはり、別々に運用せざるを得ない状況でした。KAGOYAはオプションを追加購入すればよいのですが、例えば 1ドメイン ¥540/月 の追加となり、ドメインが増えれば増えるほど泣けてくることがマイナス要因です。
ConoHa は、APIが公開されていて自由度が高いところはポイントですが、開発はしたくなかった…おしい…

XSERVER のメールサーバの良かったところ

その他、あ、これできて良かったというところです。次の二つですね。

  1. メーリングリスト
  2. ssh 接続
  3. webサーバ

これまでも、ほんの 3つくらいですが、メーリングリストを使っていて、別になくなってもよいのですが、アルニコしたことはありません。ちょっと嬉しい。

sshでつなげるのはヒジョーに良いポイントです。なぜなら、scp/rsync 使って、過去のメールボックス内のメールを移行できちゃうんです。@prfm.jpドメインのメールは既に移行済みですが、とても助かってます。imapで管理しているので、過去メールもそのまま入っていてくれると、過去メールもバックアップ対象になってくれるので、安心材料が増えます。

XSERVERは共有のサーバなので、WebやMySQL機能も持っているので、Wordpressのサーバとかもそのまま作れます。ふと、今のサーバを移行したり、ドメインの標準ページを適当に置いとくにはちょうどいいかと。 kashiyuka.infoドメインをタダでくれたので、適当に設定していますが、ひとまず webページおいて置けるのは、一旦ありがたいです。

まとめ

まだ @prfm.jp ドメインしか移行できていないのですが、3月に @oshiire.to ドメインを 1ヶ月間、現行と併存移行します。ここで問題がなければ、そのまま完全に XSERVERへ移行して、幾つかのWebサーバもそっちへ持っていく予定です。これで、家のふるーいサーバなくせそうです。ああ、良かった。


  1. X10プラン 

[ITA] ITアーキテクトの役割とは(3) [コミュニケーション]

2週間位の難産だった原稿がひとまずの完成を見て、天気同様晴れやかなしょっさんです。


良いコミュニケーション...?

それにしても、文章隠し事終わった後に、また文章書いてるとか、どっか頭おかしい気がします。

コミュニケーションェ…

ITアーキテクトの役割とは(2)の最後に記載した

ただし、技術的知識よりもITアーキテクトは、コミュニケーション能力が重視されます。

ということで、私がこれまでにために溜め込んでいて、あまり外部に公開してこなかったコミュニケーション術について、しばらく何度かに分けて書いていきます。今日は、軽く全体のご紹介です。前に、「コミュニケーションテクニック」としてプレゼンしてたんですけど、公開してなかった模様。それで適当のお茶を濁そうとした、わたしの軽率さを呪いたい。

「コミュニケーションは重要だ」

とは言いますけれども、何のために必要なのか。それはお互いの意思疎通のためで、こちらの意思を相手に伝えることも、相手の考えていることを理解するためにも、必要な最小限の社会行動です。人が社会的な活動を行う上で、まず最初に習うことが「コミュニケーション」です。赤ちゃんは、生まれた直後から、泣くことで相手へその意志を伝えようとします。それを正しく受け取れるかどうかは、また別です。

最近は、特にコミュニケーションを使わなくても生きていくことが可能になりました。ネットの発達のおかげです。Amazonや楽天のプロトコルは利便性も高く、宅配ボックスを使えば人間との関わり合いなく、生きていくことのできるプロトコルをも生み出しました。仕事に至っても、決められたプロトコルでやりとりできるケースもあり、コミュニケーションを重視しなくても生きていく方法はあるでしょう。

しかし、ITアーキテクトにとって重要なのは、言葉にできるかどうかもわからない想いを抱いている、複雑なプロトコルを持つ顧客を相手に、様々なことを理解させたり、理解したりする必要があります。人との会話が得意tion:で友人も多くいるようなリア充爆発しろ的な人であったとしても、上辺の会話で済まされてしまって、本当に重要なことを聞き出せるかどうかはわかりません。ではどうするのでしょうか。

フレームワークです。ババーン

自分に不足しているコミュニケーションは何か、そしてそれはどのような考え方、フレームワークによって実現されているのか。それを学ぶことによって、よりよいコミュニケーションを実現できる「かも」しれません。知らないよりかは、知っている方が良い程度かもしれませんが、知らないよりかはマシです。「所詮ただのテクニックじゃねぇか」と感じる人は、それはそれで独自に腕をみがけば良いですし、あらたなテクニックを生み出すでも良いです。これから紹介するフレームワークで世界が平和になるわけでもないですし、それが全てではないとも理解しています。とは言え、次のステップへ進む足がかりとして、理解いただければ幸いです。

しょっさんの使うコミュニケーションフレームワーク

過去の集大成です。というか、ごめんなさい、ホントはもう少し色々あるんですが、ベースのフレームワークはこれです。


Communication FrameWork

初出は 2012年ですが、#showstudy なるわたしの勉強会で発表したものからの抜粋です。個人的にはこれで全てです。

  • Active Listening: 積極的傾聴。相手の深層心理、上辺だけでは出てこない、本当に考えていることを引き出す技術
  • Logical Thinking: 論理的思考。相手の話を理解する上でも、自分から相手に伝えるためにも、話は理論的であることが前提
  • Assertiveness: 自己主張。こちらの意見を、相手の権利・権限を侵略せず、不快にせず、誠実に、正当に要求すること
  • Negotiation: 交渉。いわゆる Win-Win。お互いに利益・利得を得ることのできる最善策を見出し、決断させること
  • Facilitation: 合意形成。人の立場や権利を理解した上で、ゴールに対して最適な合意形成を実現すること

二つの原則的な技術を元に、どのように対話すべきか、その手法をまとめたものが、このフレームワークです。個人的にたどり着いたものなのですが、車輪の再発明的なものだったらごめんなさい。ここまで、全体を記しているような文献を見たことがないので、もしあるようなら、むしろ教えていただきたい次第。

これらについて、詳細を書くかどうかは、様子を見ながら少し悩みます。あと、お前はこれらができているのかと問われたら、成長曲線の中にいます、と答えます。人生死ぬまで成長です(;´Д`)

とりあえず、店が混んできたから、そろそろ退出する(;´Д`)

[ITA] ITアーキテクトの役割とは(2) [良い要件定義]

元ネタがあれば、書くことには困らないし、すぐに書き終わるぞ( ^ω^ )と考えた、しょっさんです


後悔先に立たず

実際に書いてみると、おおまちがいだったことに気が付きました。原稿書けよ、俺って本気で感じています。

要件定義をしていく

要求編はまだ続きます。前回では、「想いを言葉にできる」人をアーキテクトとすると定義しました。では、その想いをどうやって言葉にしていくか。手法とフレームワーク、注意点を確認します。

良い要件定義とは

まず、そもそもの「要件定義」の目標を定めましょう。

先日ご紹介したIT アーキテクト育成ハンドブックや、Wikipediaでは、次のように記されています。

要求の充足評価では、ビジネスシステムの効果測定が可能な評価項目を明確化し、それを具体的に計
測できる基準を明確にしてゆきます。その上で設計したアーキテクチャに基づくシステムの要求に対す
る目標達成の見通しを明確にするのです。そしてその結果は要求者に対して合意形成すると共に、下流
のシステム設計者に技術移管と指導することが重要です。 「IT アーキテクト育成ハンドブック

「要件定義」は(開発依頼のあったソフトウェアやシステムについて)顧客が望んでいる機能や仕様などについて、その概略をまとめた文章・文書を指すこともある[3]。ただしこうしたことをまとめた文書は通常は「要件定義書」と呼ばれる。Wikipedia

重要なポイントは次の二つです。

  1. 機能や仕様をまとめたもの
  2. 効果測定可能な評価項目

簡単にまとめましたが、いずれも難関です。それでは、これらポイントから「良い」要件定義と評価するための、具体的な内容に落とし込んでいきましょう。

1. 機能や仕様をまとめたもの


その機能は必要ですか

個人的な経験則も踏まえて、次の3つがポイントです。

  1. お客様が必要と認識しているすべての機能が、網羅されていること (FR:needs)
  2. 実際に利用するユーザーの視点に立って、期待値を超える機能が網羅されていること (FR:seeds)
  3. 異常動作時における動作・方針が定められていること (FR:exception)

これらが「網羅」されていることが重要です。1.に特に重点が置かれがちですが、実現したい機能以上に、その機能が利用しやすかったり、利用したくなるような UI/UXは重要です。Web系やモバイル系では、UI/UXデザインの画面デザインベースで勧められるケースも多く、解消されている感はありますが、それらの正当性や提案は ITアーキテクトからできるべきと考えます。

忘れがちな「障害が発生した場合」の処理は、方針が定まっていないと、個々に方向性の異なった異常対処を行うことになりますので、かならず含めましょう。「それって可用性要件では?」としか感じないインフラエンジニアは、「クレジットカード番号の検証が済んで、カード会社への要求もすんで、お客様への請求処理まですすんだけれども、そこで障害が発生してDBに処理状況が保管できなかった」ケースは、どの非機能要求に含めるのか考えてみてください。なお、このフロー自体おかしいので、真似しないでくださいネ。

最後に、「その機能は本当に必要ですか?」

2. 効果測定可能な評価項目


品質チェックに余念なく

  1. 技術動向や、お客様の経営課題・経営状況・予算など制約条件が考慮されていること (NFR:制約)
  2. すべての機能は、効果測定可能な評価基準を定めて「数値で」判断できること (NFR:品質)
  3. すべての機能は実現可能であること (reliability)

これらも「網羅」できていることが、必須条件です。さっきから「MECEMECEMECEMECE」うるせえよ( ゚д゚ )クワッ!!と思われるかもしれませんが、これが担保できないとなりませんし、担保する方法も無きにしもあらずです。今日は書きませんが。

多少 ITアーキテクトをかじっていた人にはおなじみの、「非機能要件」です。可用性、性能・拡張性、移行性、セキュリティなどなどがここに含まれます。しかし、それらは 2.で示している、ソフトウェア(アプリケーション)の品質的要件です。それらすべてを実現することが正しいのではなく、1.の社会的、企業的制約条件にしたがって、何をどこまで実現するかが関わってきます。

なお、「制約」とは、今のお客様の力では変更することができないもの、例えば法的効力、予算などです。「非機能要件」とは、お客様が個々で定めることのできる「目標」です。すべてのシステムは24/365で稼働する必要などなく、自社営業時間内(たとえば、9:00-17:00)だけ 99.9%のシステム稼働率を目標にすれば、夜は止まっていても良いなど、そのシステムの目的によって変わるものです。重要性などにより、データの保全性や、可用性も変わることでしょう。しかし、システム稼働要件を100%とすることは実質不可能ですから、落とし所をどこにするかを、納得いく「数値」へ確定することが重要なポイントです。

そして、「数値化」です。「システムテストしますよー」といったとき、一体何を基準にそれらを評価するのでしょうか。「〜の機能が動くこと」とは何を持って動くことと判断するのでしょう。「それは、すべての機能が正しく動作することです」といった場合「では、1万人が同時にアクセスする可能性があるこのシステムにおいて、それらの機能は、どのように動作することが正常動作でしょうか」という反証に答えるすべがなければなりません。機能テストだけを済ませておいて、実際にサービスインした後、「動かないんだけどー」は、この数値目標がないために起こります。性能テストを行うにしても、「何をクリアできたら、この性能テストはいいんだっけ…」となったら、破綻目前です、おめでとうございます、サービスイン後に寝られない日々が続きますね( ^ω^ )ニコニコ

最後に「実現可能性」が担保できるシステムであることを、よくよく検証してください。すべての要件と非機能要件がでてきて、それらをすべて記述できたら「完成ヽ(´ー`)ノ」ではありません。例えば「役所に問い合わせが必要な処理があり、これは1分間に20回しかコールできない制約がある」のに「役所へ問い合わせる機能は、最大で1分間に100回コールする可能性がある」は相反する要件です。よくあるのは予算が不足するケースです。要件定義では「要件まとめたぞヽ(´ー`)ノ」で終わりではなくて、システムの概要が見えている、または想定アーキテクチャは記述できているべきです。そして、実現するべきシステムの概算は準備できていて、ホントに予算内に納まりそうかどうかのアセスも必要です。デスマーチの温床となる基本は、スケジュール不足ですが、その要員工数は1日を何時間で作業させるつもりなのか、テストを実施する環境はあるのか、法的にリスクはないのか、お客様の責任者は退職しないか、十分にあんテナを貼る必要があります。

良い要件定義を実現するには

これらを遂行するために必要なことは、システム工学において要求分析として定められています。実際に、この要求分析に従って実現することは、不可能であることは見ていただければ明確です。とは言え、本来、ITアーキテクトやコンサルタント、ITエンジニアに求められる能力とは、それ相応のものであることは理解しておかねばなりません。とは言え、何を学んでおくべきか、何を知り得るべきか、については世の中に便利なフレームワークや体系がありますので、これらを利用しない手はありません。ただし、技術的知識よりもITアーキテクトは、コミュニケーション能力が重視されます。

それらについては、次回以降。これ、完成するのかな。

まとめ

まだ推敲したい段階ですが、FR/NFRともに3:3の項目が出ているので、後はより詳細に書いていくくらいしかなさそうなので、この辺にしました。

[ITA] ITアーキテクトの役割とは(1) [要求]

blogも連続で40日を超え、さすがにそんなに毎日ネタなんてねぇよ、と考える程度になりました、しょっさんです


都市計画・ビル設計

嘘です。ネタはあるんです。ただ、どう考えても長くなるので、時間が取れないと無理だなーと思う次第だけです。

IPAネタでしばらく時間稼ぎをするの巻

IPA作ったあるあるシリーズを久々にネタモノにして、しばらく何度かに分けて書いていきます。

最近、ITABoK v2日本語版が刊行されまして、これを読むにはちょいとハードルが高いと感じていたところで、IPAのつくったITアーキテクト育成ハンドブックというものを発見しました。作成年月が 2007年6月と随分と昔なのですが、今でも役に立つことはたくさん書いてあります。これらを元に、この10年間で変わったことや、モダンな考え方に修正していこうかという、天に向かって何かをはく行為です。

これだけだと偏ってしまいうので、他にも幾つかの書籍をベースに、しばらく ITアーキテクトとアーキテクチャについて記していきます。あとでまとめて、社内に展開するためのメモだと認識してくださって構いませんヽ(´ー`)ノ

ITアーキテクトは「想いを言葉にする」

まず「アーキテクチャとは」から入るべきか、それとも「ITアーキテクトとは」から入るか悩みましたが、話の流れ的に「アーキテクチャを作る人」を知ってから、その人の作るものを「アーキテクチャ」と呼べば理解しやすいかと、というか書きやすいのでその流れにします。

ITアーキテクトを一言で表すと「想いを言葉にできる人」です。

この2週間で二番目のスマッシュヒットのセンテンスだと自負してます。さきほどのITアーキテクト育成ハンドブックにも出てきますが、顧客の「想い」を言語化できることが重要であると記されています。原文では

「思い」の中に明確にされていない隠れた要求を引き出し、

とありますが、要求とか要件とかグダグダいうよりも「新しいことを始めたい」という、その想いを受け取って、何をやり遂げたいのか、どんな夢があるのか、それらを一緒に話し合って、考え込んで、それを具体的なシステムにできる人、それが「ITアーキテクト」の役割です。

巷では、この「要求・要件」をどのように網羅的に洗い出すかのフレームワークや、ツールがたくさんありますが、それはあくまでも要件定義と設計を支援するだけのものです。まず、お客様が本当に実現したかったこと、必要なものは何だったのか。そこをコミュニケートできる力が第一です。


顧客が必要だったもの(v3.0)

かの有名な「How Projects Really Work」も、知らぬ間に版を重ねて 3.0になっていましたが(正式かどうかは知らぬ)、どうやって、この差を縮めていくことができるのかが、ITアーキテクトの力量と言っても過言ではありません。そのためには、どうやって、その想いを言語化、可視化できるかが必要です。そのための方法に、フレームワークは必要かもしれません。

[設計] 図にしないとわからない病 [アーキテクチャ]

今日は仕事しないと決めて、仕事はしなかったんだけど、なんか休んだ記憶が全くない、しょっさんです。


お天気病で予定全部くるった

1日って大したことができないんだなぁとか、ホント切に感じてしまってツライ。体調も崩しやすいし、動けなくもなる。これが、老いか。

可視化は重要

500ステップもない数クラスのプログラム書いてるんだけど、それでも全体が見通せなくなってきてる自分に、やっぱり老いを感じていて。

しゃぁないと、久しぶりにUMLちょろっと書いてみたら、見通しが良くなってしまって設計とかアーキテクチャの重要性を、こんなことで感じてしまっていた今日このごろです。可視化は重要です…。

命名規則に悩む

最近の困り事といえば、Class/method/変数の名前。色んな人の命名規則を参考にしながらやってるんだけど、それに時間取られちゃうのが馬鹿らしいと思いつつも、a,b,c,i,j,x,y,z みたいな変数で適当に使ってたら、意味不明にもなるしめっちゃ困る。i,j あたりは想像ついてるから良いものの…。

[JTF] #jtf2016 で、"また" Microservices について話してきた [Microservices]

やってますか、ポケモンGO (そうじゃない)、しょっさんです。


0I9A2575 TP V

バッテリーヤバイとか言いつつも、ついつい起動してしまうところは某Ingressと等しく同じですね。そりゃそうか。

“[JTF] #jtf2016 で、"また" Microservices について話してきた [Microservices]”の続きを読む

[インフラ] インフラエンジニアの将来は明るいのか:その1 [アプリ]

3日は書かないと、三日坊主すら名乗ることができないので、3日目はなんとかしてすごしたい、しょっさんです。


Shared img thumb 150415152047 TP V

今日も内容とは関係なく女子です。ゆかちゃんです。やっぱり、ゆかちゃんがカワイイ。よこたんに、みんなと被っていて、どっかで見たことがあるとか言われても、そんなことはどうでも良くて、カワイイものはカワイイ。正義だ。

“[インフラ] インフラエンジニアの将来は明るいのか:その1 [アプリ]”の続きを読む

[cman] Proxmox で 2ノードクラスタ構成をやってみた [rgmanager]

猛暑の続く中、久しぶりに、家に引きこもってサーバこねくり回している、タイミング良く夏休みにした感が凄いしょっさんです。


Https www pakutaso com assets c 2015 07 YUKA862 megahon15203358 thumb 1000xauto 18586

最近のキュレーション系とか、おかしなニュースサイトとかで、この娘が使われてること多くて嘆いてるけど、カワイイから仕方ないよね。カワイイだけじゃなくて名前もいい。「ゆか」とか、素晴らしすぎる「河村友歌オフィシャルサイト」どうぞ。Twitter IDも出てきたけど、おっさんそこまで必死じゃない。

それにしても、被りすぎて、何の記事だか分からなくなりすぎてる。

“[cman] Proxmox で 2ノードクラスタ構成をやってみた [rgmanager]”の続きを読む

[SOA] #JTF2015 で発表してきた('A`) [Microservices]

しばらくさまざまな活動に影響をあたえていたJTF2015 (July Tech Festa)が終わりました (自分の出番が)


OK

何はともあれ、終わったので良しです。構想期間が長かった割には、言い切りたいポイントが多すぎて発散してしまったのは反省材料です。45分て大した時間じゃないので、もっと範囲を狭めるべきだった(‘A`)

“[SOA] #JTF2015 で発表してきた('A`) [Microservices]”の続きを読む

[IPA] 見積の元ネタに「ソフトウェア開発データ白書」がありがたい件 [ハイパー上流]

お前は「[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG」で味をしめたからといって、また「IPA 独立行政法人 情報処理推進機構」ネタなのかと言われそうですけれども、そうじゃない、だってそうじゃない。

Origin 116455401

基本的に、その日にあった、または最近あった出来事を元に blogのネタを日々書いているので、実は、毎日 blog書くのは結構大変です。そんなに、毎日、なにかあるわけじゃなく、ナニゴトも無く穏やかに過ごす日だってあるわけで、なかなか大変なのです、これでも。ただ、落書きしてるわけじゃなくて、これでもすこしは頭を使ってるんです…( ゚д゚ )クワッ!!

“[IPA] 見積の元ネタに「ソフトウェア開発データ白書」がありがたい件 [ハイパー上流]”の続きを読む