∑考=人

そして今日も考える。

ミニプログラムとかスーパーアプリとか

最近、中国を中心に「ミニプログラム」の流行に拍車がかかっている模様です。

 

テンセントっというまぁ中国のGAFA的位置付けの一つの会社が「WeChat」という日本でいうところのLINEみたいなチャットサービスを提供しているわけですが、このWeChatというアプリケーション上で動くアプリケーションを俗に「ミニプログラム」と呼ぶんですね。

 

ちなみに、LINEの場合も「ミニアプリ」と若干呼び名は異なるものの、同じような仕組みを提供していたりします。例えばジョルダン(乗り換え案内のアプリ)が使えたり、Developer's IO cafeという秋葉原にあるレジレス店舗用のアプリなんかがあります。

 

classmethod.jp

 

 で、この流れって結構面白いなーと個人的には思っているんですね。どう面白いかというと、歴史は繰り返される的な意味で。

 

例えば、昔インターネットの黎明期って各社のWebサイトに行くためにどうしてたかというと、ブラウザにURLをいちいち入力してたんですよ。ユニクロのホームページはこのURL、セブンイレブンのホームページはこのURL、みたいに各自が覚えて入力してアクセス。やってられませんね。

 

ということで、この煩雑さに対する突破口として生まれたのが、いわゆるGoogleみたいな検索エンジン。キーワードで検索してヒットしたURLへGUIで遷移できるという仕組みです。これがすごいのは、Webページへのインターフェースを一つにした点でしょう。こういう意味でもミニアプリ化も同じような流れ。

 

あとはいわゆる、VM仮想マシンみたいな考え方にも近いですよね。物理サーバを丸々一台用意するのはコストがかかるから、いっそ一台のマシンに仮想的なサーバを作ろう、みたいな。一つのアプリケーションをインストールするから容量食うから、いっそ一つのアプリに複数のアプリを入れよう、を可能にしたのとほとんど同じ。

 

ということで、今はこのミニアプリとかスーパーアプリ、みたいな流れが来ているのは確かですが、個人的には少し先にはこういう形でもなくなるのかなーと思っています。

 

例えば、スマホアプリのクラウド化。今でさえ、主要な処理はクラウド側でスマホAPIを叩くための画面のみを提供しているケースがほとんどかと思いますけど、そもそも色んなアプリ自体がスマホではなくクラウド上に保管されるようになるはずで。

 

仮想デスクトップのスマホ版、シンクライアントスマホですね。5Gとかが進化してネットワークを意識する必要がさらになくなれば必ずこの流れになると思います。今でもこそノートPCぐらいにスペックが進化しているスマホですが、どんどん最低限の形に絞られていくでしょう。もしかしたらその時はスマホの形をしていないかもしれない。

 

こんな風に新しい技術が登場した時は、それは歴史的な背景から想像しうることだったのか、そしてそうだとすると、この先どんな風になっていくのか。そういった視点を持つと新しい技術の発見が楽しくなりますよ。

デジマの幻想

個人的な見解だけど。市場で流行っているほど、私は「デジタルマーケティング」とか「データ活用」みたいな分野に未来があるとは思っていない。もちろん、今後も市場としてはまだ伸びるとは思うし、私が好きじゃないだけな可能性もある。

 

特に私がいつも疑問に思うのは消費者に対するレコメンド機能。あれって本当に機能しているのか。もちろん、効果がないとは言わない。私だってクーポン発行されたタイミングで洋服を買うこともある。でも、それはいずれは買おうと思っていた品だったりするので、購買機会を本当に増やせているのかが疑問。

 

レコメンド機能が一番フィットしていると感じるのは、やはり今でもAmazonの書籍レコメンドに限る。あれは何となく買ってしまうことがあった。ポイントなのは趣味嗜好としてのジャンル自体がちゃんと確立されている分野で使うことだ。

 

例えば、本を読む人のほとんどは「本を読むこと」それ自体が好き、それ自体が目的の人が多い。つまり、実際の中身(コンテンツ)はその枠に捉えられていれば何でも良い、みたいな場面で効力を発揮する。

 

まず、こういった意味でマーケティングとは「嗜好品」に対してのアクションにある程度限定されると私は見ていたりする。だって、家電とか生活必需品みたいなところでレコメンドされても困るわけで。冷蔵庫を買ったあなたには洗濯機をおすすめ、みたいなことをしてもうーん、という感じ。

 

もちろん、「家電」というジャンルが嗜好として好きな人には効くと思う。だからどちらかというと、必要性に駆られた購買なのか、その人の嗜好に基づく購買なのかをちゃんと見分けることが重要なのだろうと。今そう思った。

 

で、そういう意味でいくと、社会のインフラっぽいサービスとマーケティングって実は結構相性としては良くない気もしていて。例えば、コンビニ。コンビニって行きたくて行く場所ではなく、どちらかというと仕方なく行くところ。生きるためには食べ物が必要で、でも作るのはめんどくさい、だからコンビニに行く、という感じ。

 

だから、最近はO2OとかOMOとかいろいろと新しい概念が提唱されてはいるけれど、いまいち本当にハマっているのか、という感覚がある。少なくとも私は過去におそらく数十万以上、コンビニにお金を落としていると思うが、レシートについているクーポンを使ったことが一度もない。

 

つまり、クーポンを使いたくてコンビニに足を運ぶということもないのだ。コンビニでレシートを受け取らない人の多さを考えれば、私以外も同じような感覚なのではないだろうか。それが小売×マーケティングに私が懐疑的な一つの理由。

アジリティ化する世界

みなさんは読書をするだろうか?

 

私は昔は結構な読書好きだったのだけれど、最近はほとんど読書というものをしなくなった。本を購入する頻度も減っているし、購入した本を最後まで読み切ることも少なくなっている。

 

ここ十年ぐらい、大型の書店数は年々減っている。これは電子書籍や一般メディアの普及などが影響している一方で、そもそも本を読まない人が増えているというのが本質なのだと思う。事実、一日の平均読書時間が減っているというデータもある。

 

読書というのは、いわゆる速読みたいな手法を使わない限り、一冊の本を読むのに2時間かそれ以上かかるのが普通だろう。社会人にはこの時間を一冊の本のために割くのはあまりにおしい。非効率なのだ。

 

昔は本というのは非常に効率的に安く過去の賢者たちの叡智を学ぶことができるツールだった。なので誰もが本の価値を疑わなかった。しかし今はどうだろう?

 

Webには色んなメディアが溢れている。少し前であれば「ネットの情報は玉石混交」、「知識が体系化されていない」などと批判的な声もあった。でも、今はそんな批判の声を聞くだろうか。

 

もちろん、そういったデメリットはまだ残ってはいる。しかし、ネットの情報であっても、信頼のおけるメディアや著名人を抑えておけば、正しい情報にありつく可能性は高い。質の高い情報ほど提供されやすいアルゴリズムが構築されている。そもそも全体のコンテンツの質も上がっている。おまけにほとんどが無料。

 

となった今、書籍の価値は昔ほど高くないと思ってしまうのは私だけだろうか。いや、価値が変わったわけではなく、今の時代を生きる多くの人には適していないといった方が良い。

 

システム開発で喩えるのであれば、ウォーターフォールで数年かけてガッチリしたシステムを作るのではなく、アジャイルでクイックにサービスをローンチする、方が今の時代には合っているということ。つまりはアジリティへの対応がもっとも大事ということだ。

 

価値のある情報がまとまった本という形で執筆され、編集され、パッケージングされ市場に並ぶのを待っていれば世の中はすでに変わってしまう。「早さ」が何よりも価値を持つ現代に置いて、この損失は大きい。

 

それでも学習としての読書を続けるのであれば、要約サービスの活用を勧める。かく言う私もサブスクリプションでflierというサービスのゴールドプランに加入している。月に本を2冊買うぐらいなので、習慣的に本を読む人からすれば大した出費ではない。

www.flierinc.com

 

まずはこれで読んでみて、もう少し深く知りたいと思ったものだけ、本書を読めば良いし、別にこれだけでも本の重要なポイントはそこそこ知ることができる。目次や全体像がわからないなど、まぁ問題はあるものの、短い時間でだいたいの内容が掴めることに意味がある。

 

別にこれを紹介して私にメリットがあるわけでもないが、おすすめなのでぜひ。

AWSソリューションアーキテクトサマリ2

第二弾。だいぶ慣れてきた。フロー図とかシーケンス図とか普通に書けるといいんだが。

4. EC2/AMI/EBS/インスタンスストア

EC2起動までのステップ

# ステップ 詳細
1 AMI(Amazon Machine Image)の選択 仮想マシンのOSイメージを選択
2 インスタンスタイプの選択 マシンスペック(CPUコア数、メモリ)を選択
3 ネットワーク・IAMロールなどの設定 VPC・サブネット・IPの割当、IAMロール、ユーザデータ(OS起動時のスクリプト)を設定。
インスタンス作成時に確定していない値はメタデータを用いて記述
4 ストレージの設定 EC2インスタンスに接続するストレージをEBSとインスタンスストアから選択
インスタンスストアの選択は初回起動時のみ可
5 タグ付 検索性向上のためのキーと値のセットを付与
6 セキュリティグループの設定 FW設定として最低一つのセキュリティグループを設定
7 設定確認 1〜6の設定内容の確認
8 キーペアの選択 EC2インスタンスSSHログインする際のキーペアを選択

EC2インスタンスのライフサイクル(状態遷移図)

初期状態 起動 時間経過 再起動 停止 削除
-(未起動) pending - - - -
pending - running - - -
running - - rebooting stopping shutting-down
rebooting - running - - -
stopping - stopped - - -
stopped pending - - - shutting-down
shutting-down - terminated - - -
terminated - - - - -

EBSとインスタンスストアの比較

比較観点 EBS インスタンスストア
データ特性 不揮発性(永続的) 揮発性(一時的)
性能 数百〜2万IOPS MAX30万IOPS
価格 $/GB 無料
対応EC2 EBS-backedインスタンス instance store-backedインスタンス
対応EC2の特徴 停止、起動、再起動、削除 再起動、削除

EBSの3タイプの比較

比較観点 General Purpose SSD Provisioned IOPS SSD Magnetic
ボリュームサイズ 1G〜16T 4G〜16T 1G〜1T
IOPS 3IOPS/GB、MAX10000IOPS 容量の30倍IOPSを指定、MAX20000IOPS 平均100IOPS
価格 容量のみ 容量・指定したIOPS 容量・発生したIO
ユースケース 一般 高い性能を求め羅れるアプリ・DBなど IOの発生が少ないコスト重視のマシン
推奨運用 - ネットワークがボトルネックになるため、
EBS最適化インスタンスとしてEC2を起動
-

EBSスナップショット

S3に保存されるEBSないのデータバックアップ。 主な特徴は下記の通り。 - 圧縮保存 - 差分バックアップ - ディスクI/Oを停止するため、ボリュームをアンマウントしてからの取得を推奨 - 復元時は異なるAZ、EBSタイプ、サイズ(大きい場合)の指定が可能

プレイスメントグループ

EC2インスタンス間のネットワーク接続を高速化するためのグループ。 異なるAZ間は物理的には離れているために発生する遅延への対策として利用される。

Dedicatedインスタンス

ハードウェア占有インスタンス。EC2インスタンスを起動させる物理ホストに別アカウントのEC2が起動しないことを保証する。ソフトウェアライセンスでハードウェアの占有を求められる場合への対策として利用される。

5. オブジェクトストレージ

S3

Amazon Simple Storage Service。安価で耐久性有り。データ容量無制限。 オブジェクトには下記2種類のストレージクラスがある。 - スタンダードクラス・・・イレブンナイン(99.9・・・と9が11個続く%)の耐久性。3ヵ所に複製。 - 低冗長化(RRS)クラス・・・フォーナイン(99.99%)の耐久性。

包含関係としては、オブジェクト<<バケットである。一般的なファイルシステムのストレージは、ディレクトリ単位でファイルを管理するが、オブジェクトストレージはバケット単位でファイル(オブジェクト)を管理する。また保存形式はKey-Value Store形式である。

操作ごとにデータが整合されるタイミングは下記の通り異なる。

  1. 新規オブジェクトの書き込み(PUT)
    S3バケットに書き込み後、S3から完了が返却された後に整合される。

  2. 既存オブジェクトの上書き(PUT)
    S3バケットに上書き後、S3から完了が返却され時間経過後に整合される。

  3. オブジェクトの削除(DELETE)
    S3バケットから削除後、S3から完了が返却され時間経過後に整合される。

S3のセキュリティ

  • アクセス制限方法の比較
比較観点 ACL バケットポリシー IAMポリシー
他アカウントの設定 ×
自アカウントの設定 ×
バケットアクセス 許可のみ可 許可・拒否可 許可・拒否可
オブジェクトアクセス 許可のみ可 許可・拒否可 許可・拒否可
条件付きアクセス 不可
IAMユーザアクセス 制御不可 制御可 制御可
グループアクセス 制御不可 制御可 制御可

加えて、署名(期限)付きURLという方法があり、一時的に特定のユーザだけにアクセスを許可したい場合に用いる。

  • 暗号化とアクセスログ
    • サーバサイド暗号化・・・AWS管理の鍵、ユーザ管理の鍵を使って実施可。
    • クライアントサイド暗号化・・・暗号化データをアップロードする。
    • アクセスログは任意で取得可能、実アクセスから一定時間経過後に取得される。

Webサイトのホスティング

EC2よりも安価にWebサイト構築が可能。動的なプログラム(PHP,JSPなど)は不可だが、クライアントサイト(JavaScript)などは可能。

バージョニング機能

S3バケット単位で有効化できる。オブジェクトに対してバージョンIDが付与されるため、誤操作時に元データの復元が可能。

Glacier

データのアーカイブや長期バックアップなどの用途に適したストレージでS3に比べてコストが安い。(一方で、即時参照ができない。)S3バケットライフサイクル機能によって、指定日数経過後のオブジェクトストレージをGlacierに移行、指定日数経過後に削除などが可能。

6. データベース

AWS提供のマネージドデータベースサービス種類

サービス名 サービス概要
RDS リレーショナルデータベース
Dynamo DB NoSQLデータベース
ElastiCache インメモリキャッシュ
Redshift データウェアハウス
  • マネージドサービス・・・ユーザインストールすることなく利用可能なサービスであり、RDB、ELB、SQSなど様々ある。

Amazon RDS

データベースエンジンを下記から選択可能。 - Amazon AuroraAWS独自、MySQLと互換性あり) - MySQL - MariaDBMySQLから分岐、オープンソース) - PostgreSQL - Oracle - Microsoft SQL Server

RDSの主要機能と特徴

  • マルチAZ配置

    • 複数のAZにRDSインスタンスを配置して可用性を向上。
    • スレーブ最新化の仕組みは下記の通り。
    • 読み取り性能のためにリードレプリカを用意する構成がある(スレーブは読み書き不可)
    • フェイルオーバーはマスター障害、メンテナンス、インスタンス再起動時に発生(数分程度)
    • Auroraは3AZにクラスターボリュームを作成し、各AZでデータを保持、プライマリインスタンス以外にはリードレプリカを配置する構成
  • 自動バックアップ機能

    • 1日1回スナップショットを取得
    • スナップショット保持期間はデフォルト7日(0〜35日で指定可)
    • トランザクションログを取得しているため、復元が可能
  • パッチ適用

    • 指定の曜日・時間帯に自動でパッチ適用
    • スレーブ→スタンバイの順番で適用
    • 重要なセキュリティ脆弱性対応の場合は無効でも適用される場合あり
  • ストレージ

    • EBSと同様のタイプから選択可

DynamoDB

  • 必要に応じてストレージ自動拡張
  • 秒間あたりのI/O性能を指定可能
  • SSDのみのため性能安定
  • 3つのデータセンターにデータ複製(高可用性・高耐久性)
  • 読み込み整合性の強弱を指定可能(性能と整合性のバランス調整)
    ※読み込み整合性=データが整合されるタイミングの早さのようなもの

一つ一つの項目は400KBを超えられないため、サイズは小さいが項目数が多いデータに適している。

  • セッション
  • ゲームの点数
  • 買い物カゴ
  • センサーデータ

ElastiCache

下記のいずれかを選択。

  • Memcached・・・Key-Value Store形式。マルチノードのキャッシュクラスタ構成
  • Redis・・・Key-Value Store形式。マスターースレーブ構成

RDSへのアクセス負荷の軽減、セッションデータの格納などの用途に用いられる。

7. Amazon CloudWatch

Amazonのモニタリングサービス。 下記のような監視項目(メトリックス)が存在する。 - EC2のCPU利用率 - EBSのディスクI/O - S3の格納オブジェクト総数 - RDSインスタンスのメモリ空き容量 - DynamoDBに書き込まれたユニット数

など

EC2のモニタリング

  • EC2のメトリックス

    • 標準(デフォルト)メトリックス・・・ハイパーバイザが取得(12種類)
    • カスタムメトリックス ・・・OSにインストールしたエージェントが取得
  • データプロット間隔

    • 基本モニタリング・・・3種類のステータスチェックは1分間隔、その他は5分間隔
    • 詳細モニタリング・・・標準メトリックスを全て1分間隔(要追加料金)

アラーム

メトリックスの閾値を超えた際に所定の動作(アクション)を行う機能。 下記のような動作が可能。

  • メール通知(SNS
  • Auto Scalingポリシー(インスタンス数の増減)
  • EC2アクション(停止/削除/再起動/復旧)

アラームは3つの状態を持つ。 - OK・・・閾値未満 - アラーム・・・閾値以上 - 不足・・・データ不足

SNS

Amazon Simple Notification Service。ユーザやアプリケーションにメッセージを送信できる通知サービス。

  • メッセージ・・・通知するメッセージ
  • サブスクライバ・・・通知を受け取るクライアント。対応プロトコルは下記の通り。
    • Eメール
    • SMS
    • モバイルプッシュ
    • HTTP/HTTPS
    • SQS
    • Lambda
  • トピック・・・単一、複数のサブスクライバをまとめたもの

アラームアクションSNS設定・検知の流れ

  1. システムアラートが通知されるトピックを作成
  2. トピックにサブスクライバを登録
  3. トピックにCloudWatchのアラームとSNSのアクションを設定
  4. アラーム検出時、トピックにメッセージを送信
  5. SNSがサブスクライバにメッセージを送信

アフターコロナの世界はどうなる?

アフターコロナポストコロナ、そしてウィズコロナ。こんな言葉が徐々にだが各所で使われるようになってきている。今の私たちはナウコロナの時代に生きているため、あまりピンとこないけれど、この状況はきっとリーマンショック東日本大震災などにも匹敵する歴史的大事件ということだ。

大事件があると、社会のあり方は変わる。大事件から二つのものを得るからだ。それは解決策と経験である。今回社会として手に入れたものはリモート"の基盤である。リモートの基盤は元々あったし、一部の人には使われていたが、今ほど社会的に普及した事はないだろう。リモートが一部のITリテラシー層だけではなく民主化したことが大きい。

そして、あえて経験という言葉で分けているが、これはつまり「リモートという手段を使うとどうなのか」を経験したことで今までと何が違うのか、どっちがいいのかを個人個人が判断することが可能になった、ということ。これが大きい。

経験するというのは大きい。事前にメリットとデメリットを知ってわかった気になる人間は非常に多いが、実は体験してみないとメリットとデメリットが自分にとってどうなのかがわからないから。今回リモートで色んなことを経験した人は自分にとってどっちが向いているか、どうするのがいいのかが昔よりも見えているはず。

なので、アフターコロナというのは”非接触”というキーワードを皮切りにリモート化、無人化、非同期化が進んでいく。たとえ、コロナが落ち着いたとして、もし次に同じような事件になったときに対応できるようにしておかなければならないという教訓を得ているからだ。

私の仮説としては、ネットスーパーが進化すると思われる。ネットスーパーは利用率が一般のECなどに比べて低い。宅配ボックスに届けるとかができないことや、今すぐ欲しいに対応できなかったり、鮮度などの問題への懸念など様々な理由はあるだろう。

でも、これらの理由を解決しないとマズいということは今回わかったと思う。今、スーパーがもしかすると最も混雑しているのでは?というぐらいに人が混んでいる。もちろんできる限りの対策をしているから大問題にはなっていないが、対策としてはかなりローテクだ。

もっと進化するべきだし、そう強く思った人がたくさんいるはずなので、きっと進化していくと思う。ネットスーパーを利用する人も増えていく。

あとはなんちゃらR系の技術も間違いなく伸びる。特に労働への適用という文脈で成長する会社も出てくるのでは。例えば、リモートワークをやってみた上で発生した課題として、相手の表情や反応が見えない、でもビデオ通話にすると結局身嗜みを整えないとだめでめんどくさい、とかポツポツとある。

まとめると、一つはセキュリティとプライバシーの問題。つまり、こういう情報はみたいけれど、こういう情報はみられたくない、という二律背反の要望事項を満たす必要がある。もちろん、この点だけであれば、別にZoomなどのWeb会議ツールでも対応はできるかもしれない。

しかし、基本的にPC画面から取得できる視界情報には限界があると私は今回痛感した。例えば、Web会議中に資料を投影すると、会議に参加している全メンバの顔を見渡すことなんてできない。逆にメンバの顔をみるようにすると、投影資料の端が見切れたり、サイズがすごく小さくなってしまう。オンライン飲み会についても、十分に楽しめることはわかったが、今だとおそらく4,5人ぐらいが限界だろう。

こういった情報量の限界への対策には今だとVRかMRでしか対応できないと思う。もちろん、今の技術レベルで可能なのかはわからないけれども、HWのフォーマットとしてVRかMRに絞られるのでは?と私は考えている。

CtoCビジネスの本質

既存業界をディスラプトするCtoCというビジネス形態

攻めのITとはマッチングだと言われることがある。確かにデジタル変革の文脈で語られるITサービスの例としてよくあげられるのが、

そんなところだ。

まぁメルカリはビジネスの形としてはすごく新しいわけではないけれど、これらのビジネスがこれまでマッチングできなかった人たちをマッチングさせたことで、ビジネスとして成立する仕組みを作った点が新しい。 CtoC市場とも言われる。CtoCの出現によって、タクシー業界や民泊業界は脅かされている。今となっては同じようなマッチングサービスの出現には枚挙に暇がない。今は大丈夫な業界でもこの先、デジタルディスラプターに脅かされる業界は必ず現れる。

CtoCの本質

実はCtoCビジネスが成立するための原則がある。「本質的な提供価値がコモディティなもの」はいずれCtoCとして提供される。 タクシーが提供してくれる価値は何か?楽な移動だ。出前が提供してくれる価値は何か?食材を家まで運んでくれることだ。 ではそれらの価値を提供するために高度なスキルが必要だろうか?車を運転できる必要はあるが、高度な運転技術は要らない。

ちなみに、日本の人口が1億2000万人程度の中で、運転免許を持っている人は8000万人程度なので、2/3は同等の価値を提供できる、ということ。 誰でも代替可能なスキル、これがつまりコモディティである、ということだ。

他にも大量のリソースを保有することのみが強みにサービス提供している企業もCtoCサービスに奪われる可能性が高い。 だって少量のリソースを持っている人がたくさん集まれば、大量のリソースを持っていることと同義だから。 わたしが働いているSIerというのもある意味、大量にエンジニアを抱えていることが一つの武器だったりするので、 クラウドソーシングとかにとって変わられる可能性もあり、ひやひやしちゃう。

コモディティとは何か

時間さえあれば誰でもできるようなことはコモディティであると言える。例えば、ダフ屋のようにチケット購入のために1時間並ぶ、 授業中の黒板を一字一句正確にノートに書く、などもCtoCビジネスとして十分成立する。 私、個人で言えば、美味いラーメン屋とかは代わりに並んでくれる人がいればお金を払し、間違いなくそういう”お金で時間を買いたい”と思う人はいる。

ちなみにコモディティでなければ安心、ということもない。 CtoCはコモディティではない業界の仕事でも奪っていく可能性がある。要するに業界を問わず、中抜き現象がおこるのであって、単純に仲介業者として管理する立場は淘汰される。 強いていうのであれば、コモディティ化がそこまで進んでいない仕事であれば、素性のわからない人間に作業を委託しにくい心理が働いて、ビジネスが活性化されにくい、というだけだ。 時間がたてば、別にクラウドソーシングでも全然問題ないね、と誰もが思うことだろう。

事業化する力が必要

そもそも、今の時代に本当の意味でコモディティではない力なんてものはない。無理だ。だから身に着けるべきなのは事業化できる力。事業化する力はたとえコモディティ化しても稼げる。 逆に稼げないということは事業化する力がないということ。 少し上の視点から世の中を俯瞰したい。

AWSソリューションアーキテクトサマリ1

Markdown記法の慣れとAWSの勉強を兼ねて、学習内容を整理した上でアップしていこうと思う。全4回分ぐらいに分けて投稿する予定。GWは奇跡的に12連休もいただけちゃうのだが、あまりにやることがないので、こんな取り組みをしてみる。今回は第一弾。基本的には下記のテキストを改めてまとめているだけなので、もう少し丁寧に知りたい人は本書を購入されたし。

1. リージョンとAZ(アベイラビリティゾーン)

AZ:物理的なデータセンター郡
リージョン:複数のAZが存在する世界各国の地域
つまり、サーバ<<ラック<<データセンタ<<AZ<<リージョンという包含関係。

AWSのサービスには3つのサービスレベルがある。 特徴および具体例は下記の通り。

サービスレベル 特徴 サービス例
リージョンサービス リージョンごとに作成・管理 S3, DynamoDB, SQS, CloudSearch
AZサービス AZごとに作成・管理 EC2, RDS, ELB, ElastiCache
グローバルサービス どのリージョンからでも共通利用可 IAM, Route53, CloudFront

2. セキュリティモデルとIAM

セキュリティモデル

利用者とAWSが協力することでセキュリティを高める必要がある。(責任分担セキュリティモデル
AWSサービスによって、責任分担範囲が異なる。

サービス形態 利用者責任範囲 AWS責任範囲 サービス例
インフラストラクチャ OS以上のレイヤ・NW・データ・ユーザ 物理層 EC2
コンテナ データ・FW・ユーザ プラットフォーム以下のレイヤ RDS
アブストラク データ・ユーザ・クライアント暗号化 プラットフォーム以下のレイヤ・サーバ暗号化 S3, DynamoDB

IAM

  • ルートアカウント
    アカウント取得時に登録したメールアドレス。全ての操作が可能。
  • ユーザ
    アカウント内に複数作成することが可能。実際の操作はユーザにて実施。
  • IAM
    AWS内のユーザ管理やAWSリソースに対するアクセス制御行う。 IAMグループ・IAMユーザを作成し、IAMポリシーを適用する。 ユーザ<<グループの包含関係。IAMポリシーはどちらに対しても適用可能。拒否が優先される。

  • AWSサービスの利用方法と認証情報

利用方法 手段 認証情報
マネージメントコンソール Webブラウザ ユーザ名/パスワード
AWS CLI コマンドライン アクセスキー/シークレットアクセスキー
AWS SDK プログラム アクセスキー/シークレットアクセスキー

AWS SDKでのアクセスキー/シークレットアクセスキーの利用は推奨されておらず、IAMロールの利用が推奨されている。IAMロールはEC2インスタンスなどに割り当て可能な権限。

  • IAMロールとIAMポリシーの違い
サービス 何に対して付与? どんな権限?
IAMロール AWSリソース(EC2など) AWSリソースへのアクセス権限
IAMポリシー IAMユーザ(IAMグループ) AWSリソースへのアクセス権限

つまり、付与する対象が違うだけ。概念としては、IAMポリシー<<IAMロールの包含関係であり、IAMロールを付与することで、各種AWSサービスに対する複数のIAMポリシーがAWS内部で許可されている。

フェデレーション

IDフェデレーション

AWS以外(自社内)の認証基盤で認証されたユーザに対して、一時的にAWSサービスの利用を許可すること。 全従業員から月末にレポートをアップロードさせるなど、IAMユーザの作成が非効率な場合に利用。 STS(Security Token Service)を利用して実現する。

認証フロー

  1. ユーザが社内のIDブローカー(IDプロバイダー)にアクセス
  2. IDブローカーが社内のIDストア(Active Directoryなど)でユーザ認証
  3. IDブローカーがSTSに対して一時的に認証情報を要求・取得
  4. ユーザが一時認証情報を利用してS3バケットにアップロード

3. VPC

VPC

利用者ごとのプライベートネットワークを構築し、外部ネットワークとの接続を提供する仕組み。Virtual Private Cloud。

VPC構築手順

  1. VPC作成
    • 特定リージョンに対して作成(リージョン跨がり不可)
    • クラスA〜Cのネットワークアドレスを設定
  2. サブネット作成
    • 一つのAZに対して作成(AZ跨がる不可)
    • サーバの機能・役割に応じて分割するのが一般的
    • AZ単位で冗長化するのが一般的
  3. ゲートウェイ作成
    • VPC〜外部NW間の出入り口(以下2種類)
    • VPCにアタッチ
  4. ルートテーブル作成
    • パブリックサブネットとプライベートサブネットを定義
      • パブリックサブネット・・・インターネットアクセス許可
      • プライベートサブネット・・・プライベートアクセス許可
    • VPC内通信はルートテーブルで制御不可(サブネット間通信可)
  5. NATインスタンス作成
    • プライベートサブネットから一時的にインターネットアクセスを可能にするために必要
      • パッチダウンロード
      • リージョンサービスへのアクセス etc
    • パブリックサブネットに作成
    • 送信元/送信先チェック機能を無効化
    • プライベートサブネットのルートテーブルのデフォルトGWにNATインスタンスを指定

EC2のIPアドレス

VPCのFW機能

  • セキュリティグループ
    インスタンスごとのFW。受信(インバウンド)と送信(アウトバウンド)のアクセス制御が可能。
  • ネットワークACL(NACL)
    サブネットごとのFW。

観点別の比較結果は下記の通り。

比較観点 セキュリティグループ ネットワークACL
適用単位 インスタンス サブネット
作成可能ルール 許可のみ 許可/拒否
デフォルトルール インバウンド:全て拒否 インバウンド:全て許可
- アウトバウンド :全て許可 アウトバウンド :全て許可
特徴 ステートフル ステートレス

VPCピア接続

プライベートIPで2つのVPCを接続。双方のVPCにPCX(ゲートウェイに相当)が作成される。 同じリージョン何のVPCしか接続できない。VPCは直接繋ぐ必要がある。

独断で選ぶ家での楽しみ方3選

今の引きこもりの状況、普段よく出かけている人からすると結構しんどいらしいっすね。

 

私には正直わからん。笑。もちろんまぁずっと家、というのは多少つらいけれど、家の中でもやることがあったり、夢中になれることがあれば、正直全く気にならない。というわけで、生活としては今はかなり特殊な状況だけれど、私個人としてはかなり充実している。

 

考えてみれば、受験勉強で家に引きこもっていた時にもこんな感じだったし、修士論文を本格的に書き出したの時もこんな感じだったわけで。出かけないから疲れがたまらないため、ハイパフォーマンスなのでは、と思ったり。最近は仕事中以外はほぼWebサービス制作に時間をかけているし、休日の朝も早起きになった。

 

休みの日にやることがなくて困るみたいな人も発送を変えてみればチャンス。こんなに新しいことに挑戦する時間とエネルギーが余るなんてことはこの先ないぜ。 

 

ということで家での楽しみ方5選を紹介する。

 

第1位:プログラミング

まずはPCを買うところから。やぱりプログラミングはいい暇つぶしになる。私は今の休日はもっぱらプログラミングしている。実際、私だけでなく、世間敵に需要も増えているらしい。

www.sankeibiz.jp

 

初心者が始めるならHTMLがおすすめ。内部の処理じゃなくて見た目なので、作った部分が見えるので、やった感がある。そこそこやってみて、なんか普通のWebサイトみたいにカッコよくできない、イライラと思ったら「CSS フレームワーク」とかで検索してみるといい。CSSが使えると格段にWebサイト作りが楽しくなるはずだ。

 

まぁもちろん、見た目とかどうでもいい、ゴリゴリロジック考えたいぜ、みたいなは人はCでもJavaでもpythonでもどうぞ。

 

第2位:楽器

私はギター。やっぱり楽器があると家での退屈しのぎになるし、楽しい。休日に外出しないなら、上達の時間も確保できるでしょう。

 

初心者セットなら、1万円でそこそこの物が買えるのでおすすめ。

 

第3位:ルービックキューブ

こういうちょっと普通なら手をつけないようなことをやってみると面白い。私は数年前からやっていてもう飽きたので、片手間でしかやらないけど。新しく始めるにいいとおもう。ちょっとした特技として言えるし。

 

どうせならちょっといい奴を買ってみると、続けられるかも。おすすめはこれ。  インテリアとしてもお洒落。

 

 

もちろん、他にも、映画鑑賞とか読書とかもあるけれど、インプットばかりだと人間は疲れてしまうので、少しでも自分をあげるもの、クリエイティブなものを紹介しました。

外出することの意味を考えてみる

あいかわらず、在宅勤務継続中です。どうも生活にメリハリが無くなって、それがしんどいという人が結構目立ってきている印象です。私の妻もそうだし、会社の同僚や上司もそんなことを言っています。

 

確かに、平日なのに休みのようでもあるし、休日でも家にいるので、プライベートと仕事の境目はかなり曖昧になっている気はします。まぁ私個人としてはそういう方が向いているなぁという感じはありますけど。

 

しかし、まぁ前回の記事でも書きましたけど、「家にいなければならない」という前提で皆が考えだしたせいか、仕事以外も色んなことが家でもできるようになりましたね。例えば、Zoom飲み会なんてものが今は流行っているらしいですが、実際私もこの2ヶ月で3件実際にオンラインで飲み会をやりました。

 

で、何か問題があるかというと、別に問題じゃないんですね。普通に話できるし、楽しいし、まぁ美味しい飯は食べられないけれど、友人と話すという観点においてはなんの問題もない。ちょっと聞き返さないとダメとか、同居人に迷惑がかからないようにしないと、とかはあるけれど、本質的には同じように楽しめるんです。

 

買い物とかもおそらく以前よりも通販とかオンラインショッピングみたいなものが多くの人に使われだしていると思うんです。私も最近はUbereatsとかかなり使うようになったので。

 

で、こういったものに嫌悪感を示していた人も、実際にやってみると以外といいじゃん、という感触を得た人もいると思うんです。となった時に、はて外出する意味って何だろう?と少し思ったりするわけです。

 

例えば、今私は完全にフルリモートワークですけど、別に仕事できてるんですよ。まぁもちろん効率は少し落ちている可能性もありますけど、クオリティオブライフは確実に高いわけです。なら、外出して会社に行く必要ってあるのかね?と今は思っていたりします。たとえ、コロナが収束しても、「もう会社行く必要ないんじゃ?」という感じです。まぁ週に何回かはいくんでしょうけど。

 

他にも、友人と飲むというのもそうですね。今までであれば、長期休暇に地元に帰って旧友と集まって飲む、というのが当たり前でしたが、オンライン飲み会などが流行る世界観では、そもそも「会いにいく」必要がないわけです。

 

もちろん、直接会えるに越したことはないけど、毎回直接である必要もないかな、と。こうちょうどいい中間ができるというか。外出というのは実は多くの場合は手段の一つだったことに気づくわけです。

 

で、外出しなくても良いと、実に色んなものが要らなくなって。身嗜みを整える必要もないし、外出するようの洋服も要らない。靴、アクセサリー全般も要らない。それはそれで結構味気なかったりするんですが。

 

一方で、公園に行くとか散歩に行くとか、普段ならやらないようなこと、つまりは外出自体を目的とした行動が活発になっている点もちょっとおもろいですね。

 

私の予想では5月6日以降も今の状況は続くので、外出できないうちに外出の意味を皆が考えてみるといいと思います。

 

在宅勤務で生産性は下がるのか?1ヶ月を過ごした結果。

在宅勤務が始まってから、一ヶ月を超えているが、通常勤務の目処は立っていない。今週からは週1、2ぐらいで出社するけれど、この先果たして通常出社できる体に戻れるのだろうか。

 

そしてこうもコロナが大問題化して、志村けんが亡くなるなど、少し身近に感じる事件があると少しずつ心配にもなってくる。

 

ただ、このコロナ問題は悪い面もあったけれど、社会としては一つ確実に成長したなと思う今日この頃でもある。

 

例えば、今の状況になるつい最近までの私の会社といえば、「テレワークなんかできるのは一部のやつだけ」とか「自宅からだとネットワーク繋がらないじゃん」とか「打ち合わせは対面でやらないと伝わらないでしょ」など、テレワークができない言い訳ばかり並べて、結局誰も本気で変えることをしようとしてこなかったんですな。

 

でも、こうしてテレワークをやらないとならない、という状況に追い込まれると、工夫の方向性が変わってくる。

 

例えば、これまでWeb会議をやっていたら、「音声が途切れるよね、声が遅延するよね、だからやっぱり対面で」という結論が導かれていたはずだけれど、「音声が途切れるから喋らない人はミュートにしよう」とか「声が遅れるから音声だけはLINEを使おう」みたいに”Web会議のままで上手くやる方法を考えようになる。

 

これが人間の面白いところで人間のすごいところだなーと思う。そもそも、ほんの2ヶ月前まではIT企業にもかかわらず、「Zoomってなんですか?」みたいなところからスタートしている組織もいっぱいあったはずだけど、「意外とやってみれば使える」みたいな空気になっていて。

 

たぶん、こういうことは色んな中間層の会社の中で怒っている革新ではないかなと思う。その一方で、果たして本当にテレワークでこれまでの生産性が維持できているのか?は皆が疑問視しているところかもしれない。

 

私自身、約一ヶ月テレワークをしてみて所感としては、トータルでの生産性は落ちないと考えている。

 

生産性が上がる要素としては、例えば下記がある。

1. 仕事を遮られず、作業に集中しやすい。

2. 無駄な仕事が生まれにくい。

3. 通勤の負担がないから日々疲れにくい。

 

1. はまぁその通り。特にやるべきことが明確なときや自分一人でできる作業は圧倒的に集中して作業できるから捗る。打ち合わせに関しても、システムで時間を制御されるため、だらだらと延長することがなくなりやすい。

 

2. に関しては、結局人と会話をしないから、やった方が良いけど必須ではないような仕事を依頼されにくいのだ。実際面白いデータがあるらしく、どうも、「人の顔を見ることでその人に依頼する仕事を思い出す」というのだ。重要な仕事であれば、人の顔をみなくてもメールなりで依頼がくるはずなので、重要度フィルタがかけられる。

 

3. に関してもいわずもがなだろう。加えて、特に営業、それも旧時代的に客先に足を運ぶタイプの営業の場合は、これまで客先訪問するための移動時間が労働時間にカウントされていたため圧倒的に作業時間が増える。私の嫁も営業だが、在宅勤務をすると休みの気分になると豪語していた。

 

当たり前だが、もちろん生産性が下がる要素もある。

1. 強制力がなく、労働のモチベーションが維持しづらい。

2. ファシリテーション、コミュニケーションスキルや準備が必要な場合がある。

 

1. は特に人によってその影響は大きく変わるかもしれないが、私もやはりずっと在宅勤務をしていると、サボることが増えた。たぶん生産性が上がったことで、少し暇になり、暇になった時間をサボりに使っているという感じ。だから生産性がプラマイゼロ笑。

 

2. について、やはりホワイトボードなどを使ってその瞬間に意識を合わせたりするのが少し難しいため、うまく打ち合わせをファシリテートしたり、コミュニケーションを取りやすくするための資料を用意しておくなどの工夫が必要になる。パワポで絵を書きながらやったりするけど、それも少し時間がかかる。

 

もちろん、そもそも在宅勤務などできない業種は当然致命的に生産性は下がってしまうだろうが、実際のところ、どうなのかは国の偉い人が統計してくれているのだろうか。ぜひとも確かめたいものである。

 

ただ、私自身としては、生産性が仮に少し下がっていたとしても、生活自体に非常にゆとりはできるので、ワークライフバランスとかを考えると、良い傾向だと思う。これまでは仕事から帰ってきたら、もう何もしたくない、という感じであったが、最近は仕事以外の活動をする気も出てきている。

 

もし、通常勤務ができるようになったとして、働き方を戻す必要もないのかもしれない。

テレワーーーーーク

 少し前のNTTデータの協働者に引き続き、電通の社員もコロナ感染が発覚したのはつい先日のことであるが、本社勤務の5000人がテレワークというまさかの対応には驚いた。ここまでの判断が過去にあっただろうか。

 

そんな波風を受けてか、二日ほど前に私の会社(もう少し性格に言うと本部)からも、「原則在勤務」という通達が社員に降った。夕方5時くらいに管理職が緊急召集されてなんとなく予感はしていたけれど。

 

テレワークではなく、在宅勤務としているのは、家から極力出るな、と言われているので、それはつまりテレワークではなく在宅勤務なのだ。ちょっとお洒落なカフェで仕事できるならテレワーク。そういう使い分け。

 

実際、他の会社でも在宅勤務はやはり進んでいるらしい。

www3.nhk.or.jp

 

そんなこんなで私はこの二日間は家から出ずに仕事をしていた。最近はWeb会議とかも結構普通にやるようになってきたので、以外と家でも仕事ができてしまうのだ。これが何とも生産的で驚いた。考えてみれば一日中会社ではないところで一人で仕事をする、なんてことはこれまでなかったからだ。

 

感じたメリットを雑に上げてみる。

・通勤時間分だけお得。(寝れる)

・身嗜みを整えなくてもいい。その時間がお得。

・余計な雑談に巻き込まれない。

・余計な仕事を振られない。

・自由にお茶とか飲める。

・電話に出なくていい。

・よって仕事が捗る。

 

もちろん、デメリットも少し感じている。

・ちょっと困ったときに非公式な軽めの相談ができない。

・Web会議の準備が少し面倒。

・みんな仕事してんのか?と疑心暗鬼になる。

・緊張の糸が切れるとやる気をなくす。

・別のことをしてしまう。

・何より孤独。

 

私は休日家で一人のことが結構あるので、平日もこうだと死んじゃうなぁとしみじみ。

採用の合否を分けるポイントは◯◯だったという話

どうも。

唐突だが、私の会社の同期は数百人ぐらいいる。そして、入社6年目ともなると、色んな組織に散らばって活躍している。

独立したという話はあまり聞かないけれど、イケイケのベンチャーに転職、外資系コンサルに転職する人もいれば、会社の中で地方に転勤、子会社に出向、海外常駐みたいなケースももちろんある。

ちなみに私の嫁と親しい同期の場合は、人事部に異動した。開発が合わず、営業も合わず、最終的に人事になってそこそこ楽しくやっているらしい。

「そんなに合わないなら会社やめれば?」とか個人的には思ったが、諦めずに自分に合った場所を探すという姿勢はどうも大事らしい。

とまぁ私の感想はどうでもいいとして。人事の大きな仕事と言えばやはり採用である。中でも私の会社の場合は新卒採用が大半を占めるので、「いかに優秀な新卒を採用できるか」が重要視されている。

優秀をもう少し平たく言うのであれば、自社の仕事の中で成果を挙げられる人、極論を言うと速く出世していく人、といってもいいかもしれない。そんな人をいかに採用していくかが鍵なのだ。(私自身は出世していく人=成果を出している人とは思わないけれどそう考えた方が単純なためここではそういうことにしておく。)


であれば、どういう人が速く出世するのか?というのをトレースすれば結果は一目瞭然な気はするのだが、現段階ではそういったトレースは難しいそうで。


おそらく数年前は採用活動にデータが活用されていなかったのだろう。どんなファクターが出世スピードに影響を与えているのかが厳密には特定できていないらしいのだ。

これは個人的にも非常に興味があって。思い出しても見てほしい。新卒採用の面接の時は、リーダーシップ、協調性、コミュニケーション能力、プレゼンテーション能力、論理的思考能力、独創性、英語力、などキリがないほどの能力を求められなかっただろうか。そんなスーパーマンがどこにいるんだと。

だから、結局のところ何が本質なのかを掴めないままなぜか就職だけが決まった、というのが正直な感想で。一体どんな資質が大事なのか、は私自身ずっとわかっていないのだ。もっと言えば採用を担当した人事の人ですら私を雇って正解だったのかもわかっていないはず。

とまぁ採用の完全な正解はわかっていないのが現状なのだが、少なくとも採用活動を行う以上は合否を分けるポイントはあって然るべきだろう。と思っていればやはり現時点で採用の際に最も重視しているポイントはある、というのだ。

さて。どんな資質が評価されるのか、想像できるだろうか。

これはたぶん会社によっても異なるとは思う。私の会社の場合はなんと・・・

ストレス耐性

とのこと。つまりストレス耐性が強い人が私の会社に残る傾向が認められ、成果を出す傾向が認められている、ということだ。

この回答には驚きと共感しかなかった。

2020年やらないことを決める

まぁ守れる守れないは別として。

 

普通新年って「これをやろう」みたいな目標を立てるのが一般的だと思うし、個人的にも達成したいことがないわけではないんですが。目標って何となく立ててもだいたい達成できないもので、この理由って時間の有限性に起因すると思ってます。

 

仕事でもそうですよね。こんな反省があるから次はこうしよう!とか言うけど、結局できなかったりする。当たり前。時間を増やさないと新しいことはできないんです。だから今までやっていたことをいかに効率化するか、とか考えるんですけど、効率化するよりもやめた方が断然効果は高いです。

 

一例をあげるならば、例えば私はyoutubeとかで動画を見る時はだいたい2〜2.7倍速ぐらいで見てます。要は倍の生産性が出てるわけです。じゃあ時間が余るかというと余りません。だって別の動画を見ますからね。

 

でもこれが例えば「動画を見るのを止める」という判断をすると、どうなるでしょう。これまで動画を見ていた時間はゼロになりますし、侵食されることもなく、完全に別のことに時間を使えます。

 

だから、まず「やらないこと」を決める。それが正解と思った次第です。ただ、やらないことを決める上で、一体自分が何に時間を使っていたのか?を知っておくことも重要だと思います。そういう情報がApple Watchとかで取れるといいな、と思いますが、ないので、記憶を頼りに。みなさんも去年の予定表とか見ながら考えてみると面白いかも。

 

大前提として、1年間は24時間×365日なので、総パイは8760時間あります。これは全員同じです。

 

おそらく最も多いであろう睡眠時間から。まず私の場合、基本的に1時〜8時まで毎日寝てます。はっきり行って休日は11時ぐらいまで寝てることがほとんど。だいたい年間120日(≒1/3)が休日だと考えると(7時間×2/3+10時間×1/3)×365日=2920時間は寝てる、ということになります。つまり、ちょうど1/3が睡眠ということですね。実質、活動に費やせる時間が5840時間しかないということです。

 

次に労働時間。昨年度の労働時間は推定ですけれども、残業時間が確か年間トータル600時間ぐらいなので、20日×7.5時間×12ヶ月+600時間=2400時間は働いているということになります。36協定に引っかかりそうな数字なので、実際にはもう少し少ないはずですが、お昼休憩の1時間も労働時間内と考えれば、ほぼ同じくらいの数値かな、という感じです。

 

すると余った自由に使える時間は2440時間。意外にも働いている時間と同じくらいの時間が余ってます。これだけの時間を自由に使えるはず、というのは少し気が早いです。例えば、通勤時間とかもこの中に含まれています。

 

私の場合は電車通勤で、だいたい往復1時間ぐらいです。なので、240時間は自由には使えません。残り2200時間になりました。あとは例えば、会社の飲み会などが頻繁に開催される人であればそこも計算に入れる必要がありますね。週1で2時間飲みに行くとすると、52週×2で100時間ぐらいが引かれます。残り2100時間です。

 

労働以外でも、生活に必要な時間もあります。朝起きて髪を整える、歯磨きをする、顔を洗う、用を足す、ご飯を食べる、お風呂に入る、などもあります。毎日トータル1〜2時間ぐらいはかかっているでしょうね。私はお風呂も5分ぐらいなので365×1=約360時間で、これはなかなかインパクトありますね。1740時間まで減ってしまいました。

 

家事に費やす時間もあります。人によっては一番インパクトがあるかもしれません。私は料理は基本的にやらないし、掃除はルンバにお任せで洗濯物ぐらいなので、週1回で20分ぐらいですか。年間20時間ぐらいですね。(嫁に怒られそうな時間感。)残り1720時間。

 

結局、残るのって20%にも満たないってことなんですね。私の場合でそうだから家事をキッチリやって仕事もしている人とか、子育てしている人とかってこんな比ではないはず。

 

で、その余った20%を何に使っているのか。休日の1/4は嫁と外出するから100時間ぐらいは時間使っていて。昨年で言うと、毎日1時間ぐらいはギターを引いていた気がするので360時間。たぶん、読書とブログ書くのは合わせても50時間ぐらいしか使っていない気がする。

 

となると、残りの1720-100-360-50=1210時間はどこに消えているのか。きっとアマゾンプライムYouTubeなわけで。こう考えると、積み重ねってすごく恐ろしいなと。

 

最近はYouTubeのコンテンツは本当に充実していて、それこそ私の好きなお笑いのコンテンツは山ほどあるし、教育系、ビジネス系の動画もある。見ていて勉強にはなるし面白い。面白いからいいかと思っていたけれど、なんとなくで今の自分に必要ではないコンテンツを受動的に選ぶのは良くないという思いが強くなり。

 

だからもう目的のない動画鑑賞は2020年やめることにします。

私たちはいつまで紙で採点を使うのか

どうも。この度秋期のシステムアーキテクト試験に合格しました。

 

私は前回応用情報技術者の資格を取得してからとっくに2年以上経っているため、午前試験の免除が効かず、シンプルに覚えなければならない知識量が多いんですな。おまけに年に1回しかチャンスもなく、タイミングも選べない。そもそも丸一日ペーパーテストで潰れるのがこの歳になると惜しいし、体力的にもきつい。。。

 

と、まぁ色んな嫌な要素があって、ここ数年間は情報処理試験からずっと手を引いていたんですが、出世のために高度資格が必要とのことで、上司からの圧力を受けながら今回受験することにした、という背景です。

 

システムアーキテクトを選んだ理由はまぁいくつかあるんですが、強いて言うならば持っていた時に目立つかな?ぐらいで。ネットワークスペシャリストとかDBスペシャリストってこの世界にいるとよく聞くんですが、システムアーキテクトってあんまり聞かないんですね。

 

たぶん論文問題があるからで(これが後述の通り相当しんどい)、勉強する気が削がれるんでしょうね。私はこれでも割と文章を書くのは多分得意な方なので、今ならいけるんじゃね?ぐらいの感じでチャレンジしたわけです。

 

結局、論文対策なんてやっている時間はほぼなくて、当日にフル活用に無理やり回答した、という感じです。そもそも回答用紙に余白ありまくりだったので、100%落ちたと思っていましたが、まぁラッキーでしたね。

 

と、まぁ私の自慢話はここまでにして、本題なのは、この論文問題についてです。午後2時間半ぐらいで、トータル4000文字ぐらいを書かなければなりません。たぶんシステムアーキテクトに限らず他の高度情報系の資格とか、もしかしたら全然別の資格でもそういうのがあるかもしれませんね。

 

私はぶっちゃけ1時間で2000文字以上ぐらいは書けるんですが、それはタイピングを前提とした話。試験の時は「紙に筆記で書かなければならない」ことが最大の障害になりました。

 

まず、はっきり言って全然時間が足りませんでした。何を書くか考えなければならない難しさももちろんありますが、考えたことを書くスピードが追いつかないんですね。だから一度考えたことが書いている間にどこかへ行ってしまう。

 

また、ブログなどもそうで、書き出すことで初めて頭の中が整理されたりするものなんだけど、気軽に書き直すことができない。例えば、文章の構成を途中で変更しようものなら、最初から全て書き直さなければならなくなったりするので、基本的に最初に決めた通りに書くしかないんです。

 

最後に、漢字が出てこない瞬間とかもありましたね。やっぱり自動変換に慣れすぎるのもよくないです。

 

と、まぁ色んな障害をクリアする必要があるんですが、「この障害って今の時代に必要なのか?」と強く思いました。あくまで、知識や技能を持っていることを評価するための媒体に紙を使っているだけで、書面に自分の考えを時間内に筆記できる力は必要ないはずじゃないですか。

 

漢字がわからなくて落ちたり、途中で文章構成を変更する時間がなくて落ちてしまう人が実務でそのスキルが発揮できていないかというと、たぶんそんなことはなくて。だって、PCを使えば自分の知識やスキルを使って表現できるはずだから。

 

こう考えると、紙で採点を行うというのは機会損失ではないか、と思うんですね。本当に柔軟に自分の考えを表現する人は不合格になり、逆に初めに構成や文章量をかっちり固めている人が評価される。

 

教育の現場は古い慣習に縛られていることで、どれだけ損失を出しているか自覚した方がいいでしょうね。

プログラミング言語を勉強してもサービスが作れない理由

最近は、IT系の人とかSEじゃなくてもプログラミング言語を学習する人が増えてる気がする。私の友人にも何人かいる。「今、Python勉強してるで」みたいな。

 

プログラミング学習サービスが沢山登場して学習のハードルが下がってきたこともあるし、サービスを作りたいと考える人が増えたからなのだと思う。で、はじめの一歩としてプログラミング言語を勉強する、というわけだ。

 

私はプログラミング言語の勉強はまったく否定しないどころか良い事だと思っている。少なくとも何かの言語を一通りやってみることは重要だ。どの言語にも共通する考え方を学ぶことができるからだ。

 

しかし、特定の言語(例えばPython)だけを一通り学習すれば、サービスが作れるようになるか。もちろん答えはNOである。プログラミング言語を知っているだけでは不十分なのだ。

 

かく言う私がそうだった。大学院時代にC言語の教科書を一通り学習した後にWebサービスを作ろうと思ったが、全くわからなかった。サービスを作る上で必要なことを理解していなかったからだ。

 

 

プログラミング言語を理解するよりもずっと大切なこと、それはアーキテクチャの本質を理解することである。ズバリ言ってしまうと、アーキテクチャの本質とは入出力、データ、加工方法、この3つ。これだけ。システム風な言葉としては、それぞれ、インターフェース、データベース、ビジネスロジックなどと言う。

 

簡素なWebシステムでさえ、インターフェースはブラウザなので、htmlやphpが使われるし、データベースを扱うためにはsqlが必要、そしてビジネスロジックでCとかJavaとかPythonとかを使う。

 

Androidアプリも同じ。私が過去に作った簡単なやつでも、アプリの画面はxml、データベースはsqlビジネスロジックJavaと3種類は必要だった。結論から言うと、1つの言語で今風のサービスを作ることなんてできないということ。(もちろん、C言語だけで画面もデータベースの仕組みも作れることは作れるけれど、コード量が膨大になって保守性も悪いのでもはやできないと考えた方が良い。)

 

もっと言えば、それらを動かすために必要なミドルウェアとかフレームワークも理解する必要がある。

 

私の場合は、「Webサービスの作り方」的な本を買って勉強して、始めてこのアーキテクチャを理解した。だから、いきなり言語の本を買うよりも、「チャットサービスの作り方」とか「作って覚えるゲームプログラミング」的な本を目的に応じて選んだ方がサービスを構成する全体像が見えて良い。