機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

pod内からncコマンドで疎通確認する方法

f:id:orinbou:20200510225328p:plain

k8sのトラブルシュートなどでpodから疎通確認する方法についての簡単なメモです。
時々しか使わないので、時間が経つと100%忘れるのでここにメモを残しておきます。

nc コマンドの説明

NetcatはHobbit氏によって開発された、汎用TCP/UDP接続コマンドラインツールです。
ncコマンドはNetcatの略。非常に多機能なツールですが、今回は一部機能のみ使用します。

(外部接続の疎通確認の)コマンド実行の書式は下記です。

nc [-オプション] 接続先 ポート番号

疎通確認時によく使うオプションは下記です。

オプション 覚え方 説明
-z zero I/Oの[z] ゼロI/Oモード(ポートスキャン時)
-v verboseの[v] (多弁:verbose)情報表示モード
-w secs waitの[w] タイムアウトwait時間(秒数指定)

podからncコマンドで疎通確認する方法

まず、疎通確認したい pod(接続元) へ入ります。

$ kubectl exec -it webapp-color -- sh

次に、疎通確認したい pod / service (接続先)へ nc コマンドを実行します。

疎通OKの場合

# nc -z -v -w 3 secure-service 80
secure-service (10.108.84.141:80) open

疎通NGの場合(※タイムアウト)

# nc -z -v -w 3 secure-service
nc: secure-service (10.108.84.141:0): Operation timed out

上記は、CKA / CKAD のトラブルシュート試験でよく出題されて焦るやつなので覚えておくと吉。

参考URL

この記事を書くにあたり下記の情報を参考にさせていただきました。

k8sコンテナでコマンド実行するマニフェストファイル記述例

f:id:orinbou:20200508000144p:plain

k8sコンテナでコマンドを実行するマニフェストファイルの記述例を紹介します。

TL;DR

下記の流れでk8sコンテナでコマンドを実行するサンプルをいくつか試してみました。

  • サンプル1:単純な引数ありコマンドを実行する(commandのみ)記述方法
  • サンプル2:シェルで複数の引数ありコマンドを実行する(commandのみ)記述方法
  • サンプル3:シェルで複数の引数ありコマンドを実行する(command + args)記述方法①
  • サンプル4:シェルで複数の引数ありコマンドを実行する(command + args)記述方法②
  • サンプル5:シェルで複数の引数ありコマンドを実行する(command + 環境変数)記述方法
  • まとめ

サンプル1

単純な引数ありコマンドを実行する(commandのみ)記述方法

■ sample01.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample01
spec:
  containers:
  - name: busybox
    image: busybox
    command: ['echo' , 'The sample01 app is running!']

サンプルpodをデプロイ

$ kubectl apply -f sample01.yaml
pod/sample01 created

サンプルpodの実行確認

$ kubectl logs sample01
The sample01 app is running!

ちゃんと実行されてますね。 ただし、コンテナのメインプロセスが即終了するためコンテナが再起動を繰り返してしまいます。

$ kubectl get pods sample01 -w
NAME       READY     STATUS      RESTARTS   AGE
sample01   0/1       Completed   1          7s
sample01   0/1       CrashLoopBackOff   1         7s
sample01   0/1       Completed   2         21s
sample01   0/1       CrashLoopBackOff   2         34s
sample01   0/1       Completed   3         48s
sample01   0/1       CrashLoopBackOff   3         1m

サンプル2

シェルで複数の引数ありコマンドを実行する(commandのみ)記述方法

■ sample02.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample02
spec:
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'echo The sample02 app is running! && sleep 3600']

サンプルpodをデプロイ

$ kubectl apply -f sample02.yaml
pod/sample02 created

サンプルpodの実行確認

$ kubectl logs sample02
The sample02 app is running!

ちゃんと実行されてますね。

サンプル3

シェルで複数の引数ありコマンドを実行する(command + args)記述方法①

■ sample03.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample03
spec:
  containers:
  - name: busybox
    image: busybox
    command: ['sh']
    args: ['-c', 'echo The sample03 app is running! && sleep 3600']

サンプルpodをデプロイ

$ kubectl apply -f sample03.yaml
pod/sample03 created

サンプルpodの実行確認

$ kubectl logs sample03
The sample03 app is running!

ちゃんと実行されてますね。

サンプル4

シェルで複数の引数ありコマンドを実行する(command + args)記述方法②

■ sample04.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample04
spec:
  containers:
  - name: busybox
    image: busybox
    command:
    - 'sh'
    args:
    - '-c'
    - 'echo The sample04 app is running! && sleep 3600'

サンプルpodをデプロイ

$ kubectl apply -f sample04.yaml
pod/sample04 created

サンプルpodの実行確認

$ kubectl logs sample04
The sample04 app is running!

ちゃんと実行されてますね。

サンプル5

シェルで複数の引数ありコマンドを実行する(command + 環境変数)記述方法

■ sample05.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample05
spec:
  containers:
  - name: busybox
    image: busybox
    env:
    - name: MESSAGE
      value: 'The sample05 app is running!'
    command: ['sh', '-c', 'echo $(MESSAGE) && sleep 3600']

サンプルpodをデプロイ

$ kubectl apply -f sample05.yaml
pod/sample05 created

サンプルpodの実行確認

$ kubectl logs sample05
The sample05 app is running!

ちゃんと実行されてますね。

まとめ

同じような実行結果を出力する場合でも、いろいろな書き方があります。 全てを覚える必要はありませんが、書き方は一つじゃないということと、 変にハマらないために、まずは無難な書き方を覚えて徐々に慣れるのが良いと思います。

参考URL

この記事を書くにあたり下記の情報を参考にさせていただきました。

コンテナイメージの違いによる pod のふるまい

f:id:orinbou:20200506225742p:plain

コンテナイメージの違いによる pod のふるまいに関するちょっとしたメモです。

TL;DR

下記の流れでコンテナイメージの違いによる pod のふるまいの違いを確認しました。

  • サンプルpodを作成&起動確認(メインプロセスなし <= コンテナイメージ:busybox)
  • サンプルpodを作成&起動確認(メインプロセスあり <= コンテナイメージ:nginx)
  • サンプルpodを作成&起動確認(メインプロセスあり <= コンテナイメージ:busybox + command)
  • まとめ

やったこと

まずk8sクラスタ上にテキトーなpodを配置したかったのでマニフェスト

■ busybox.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: busybox
    image: busybox

を書いてサンプルのpodをデプロイ

$ kubectl apply -f busybox.yaml
pod/busybox created

してみたら、あれ?podが起動(Running)にならない、、、

$ kubectl get pods -w
NAME   READY   STATUS              RESTARTS   AGE
busybox 0/1     ContainerCreating   0          3s
busybox 0/1     Completed           0          6s
busybox 0/1     Completed           1          9s
busybox 0/1     CrashLoopBackOff    1          10s
busybox 0/1     Completed           2          24s
busybox 0/1     CrashLoopBackOff    2          38s
busybox 0/1     Completed           3          54s
busybox 0/1     CrashLoopBackOff    3          55s
:

しかも再起動を繰り返してる、、なんでだろう?

試しに nginx のマニフェスト

■ nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx

を書いてサンプルのpodをデプロイ

$ kubectl apply -f nginx.yaml
pod/nginx created

してみたところ問題なくpodが起動(Running)した。なんでだろう?

$ kubectl get pods -w
NAME   READY   STATUS              RESTARTS   AGE
busybox 0/1     CrashLoopBackOff    5          3m46s
nginx      0/1     ContainerCreating   0          4s
nginx      1/1     Running             0          7s

次に、先ほどのマニフェストにコマンド実行を追記して

■ busybox.yaml(※command 追記)

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']

既存のpod(busybox)を削除して

$ kubectl delete pod busybox
pod "busybox" deleted

問題のpodを再作成してみる。

$ kubectl apply -f busybox.yaml
pod/busybox created

ちゃんと起動しました。

$ kubectl get pods -wNAME    READY   STATUS    RESTARTS   AGE
busybox 1/1     Running   0          56s
nginx      1/1     Running   0          13m

この理由ですが、k8sコンテナは、実行中のメインプロセスが終了するとコンテナも終了しようとするためです。 つまり、nginxイメージを使用するpodは、メインプロセスであるnginxが動作し続けているため、 podは起動状態(Running)になり、その状態を維持し続けますが、busyboxイメージを使用するpodは、 実行コマンドが指定されていない場合、メインプロセスがすぐに終了してしまうため、podは、 ほんの一瞬だけ起動状態(Running)になりますが、すぐに完了(Completed)してしまいます。

今回マニフェストに追記したコマンド(sleep)により3600秒間(1時間)はメインプロセスが終了しないため、 busyboxイメージを使用するpodも起動状態(Running)となりました。 が、その時間が経過すると、先ほどと同様に再起動を繰り返すようになります。

ちなみに、busyboxイメージを使用する kubernetes の資料やマニフェストのサンプルの多くはコマンドを指定して使用されています。

知っていればそれまでなのですが、テキトーにサンプルをつくると、想定外の事象に苦しむことになりがちなので、 ご注意ください。

参考URL

この記事を書くにあたり下記の情報を参考にさせていただきました。

自粛の息抜きにkubectlでちょっとだけ遊んでみる

f:id:orinbou:20200506231120p:plain

CKADの勉強してたら楽しいクジラちゃんコンテナ(docker/whalesay)と出会いました。
ので、自粛の息抜きに kubectl でちょっとだけ遊んでみました。(笑

デフォルトはクジラちゃん(オプション指定:なし)

kubectl run whaleme --image=docker/whalesay --restart=Never --rm -it  -- sh -c "cowsay Hello!"

を実行すると、、、デフォルトはクジラちゃん。

 ________
< Hello! >
 --------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/
pod "whaleme" deleted

次は象さん(オプション指定:-f elephant)

kubectl run whaleme --image=docker/whalesay --restart=Never --rm -it  -- sh -c "cowsay -f elephant Hello!"

を実行すると、、、パオーン!

 ________
< Hello! >
 --------
 \     /\  ___  /\
  \   // \/   \/ \\
     ((    O O    ))
      \\ /     \ //
       \/  | |  \/
        |  | |  |
        |  | |  |
        |   o   |
        | |   | |
        |m|   |m|
pod "whaleme" deleted

次は竜と牛さん(オプション指定:-f dragon-and-cow)

kubectl run whaleme --image=docker/whalesay --restart=Never --rm -it  -- sh -c "cowsay -f dragon-and-cow Hello!"

を実行すると、、、牛さん危うし!もうすぐステーキに、、、

 ________
< Hello! >
 --------
                       \                    ^    /^
                        \                  / \  // \
                         \   |\___/|      /   \//  .\
                          \  /O  O  \__  /    //  | \ \           *----*
                            /     /  \/_/    //   |  \  \          \   |
                            @___@`    \/_   //    |   \   \         \/\ \
                           0/0/|       \/_ //     |    \    \         \  \
                       0/0/0/0/|        \///      |     \     \       |  |
                    0/0/0/0/0/_|_ /   (  //       |      \     _\     |  /
                 0/0/0/0/0/0/`/,_ _ _/  ) ; -.    |    _ _\.-~       /   /
                             ,-}        _      *-.|.-~-.           .~    ~
            \     \__/        `/\      /                 ~-. _ .-~      /
             \____(oo)           *.   }            {                   /
             (    (--)          .----~-.\        \-`                 .~
             //__\\  \__ Ack!   ///.----..<        \             _ -~
            //    \\               ///-._ _ _ _ _ _ _{^ - - - - ~
pod "whaleme" deleted

次はベーダー卿(オプション指定:-f vader)

kubectl run whaleme --image=docker/whalesay --restart=Never --rm -it  -- sh -c "cowsay -f vader Hello!"

を実行すると、、、牛ベーダー卿??? なんだコレwww

 ________
< Hello! >
 --------
        \    ,-^-.
         \   !oYo!
          \ /./=\.\______
               ##        )\/\
                ||-----w||
                ||      ||

               Cowth Vader
pod "whaleme" deleted

まだまだある(オプション指定:cowsay -l)

kubectl run whaleme --image=docker/whalesay --restart=Never --rm -it  -- sh -c "cowsay -l"

を実行するとオプション指定可能な動物(???)が全部表示(↓)される。

Cow files in /usr/local/share/cows:
beavis.zen bong bud-frogs bunny cheese cower daemon default docker dragon
dragon-and-cow elephant elephant-in-snake eyes flaming-sheep ghostbusters
head-in hellokitty kiss kitty koala kosh luke-koala meow milk moofasa moose
mutilated ren satanic sheep skeleton small sodomized squirrel stegosaurus
stimpy supermilker surgery telebears three-eyes turkey turtle tux udder
vader vader-koala www
pod "whaleme" deleted

やばい、なんかこれ楽しい!!!

自粛の息抜きに是非どうぞ(笑)

Certified Kubernetes Administrator (CKA) 試験に合格しました

f:id:orinbou:20200429032015p:plain

昨日(4/28)Certified Kubernetes Administrator (CKA) 試験に合格(1回目[4/14]:不合格、2回目[4/26]:合格)しました。合格するまでの勉強方法などのメモです。誰かの何かの役に立てば幸いです。

 

■ Kubernetes認定資格について

CKAは、Linux Foundationが認定するKubernetesに関するスキルを証明するための、コマンドラインを使ったハンズオン形式の資格試験です。詳細はこちら(↓)です。

Kubernetesは、Googleの社内技術を元にオープンソース化されたコンテナオーケストレーションのデファクトスタンダードとも言うべきものです。ググればいくらでも情報が見つかるのでここでの説明は割愛します。

 

Linux Foundationが認定するKubernetesの認定資格は、次の2種類(CKA/CKAD)があります。 日本語(の試験官)で試験を受けたい場合はJPが付いているものを選択します。

略称 正式名 概要

CKA

CKA-JP

Certified Kubernetes Administrator (CKA) 試験 Kubernetes管理者の責任を果たすためのスキル、知識、およびコンピテンシーを持っていることを保証するもの

CKAD

CKAD-JP

Certified Kubernetes Application Developer (CKAD)試験 Kubernetesのクラウドネイティブ アプリケーションを設計、構築、構成、および公開する能力を証明するもの

今回は「CKA-JP」で試験を申し込んで受験しました。受験費用は何れも$300です。この費用に1回分の再受験が含まれているので心理的にもお財布的にも嬉しいですね。時々割引キャンペーンで受験費用が10〜30%OFFになることがあるので、試験対策を進めながらこまめにチェックするとお得に受験できるかもしれません。

 

■ 試験対策について

試験対策については、様々なサイトやBlogでいろいろと情報が公開されており、こちらもググればたくさん出てくるので、ここでは取得までに実践した内容を簡単に記載しておきます。

 

Udemy(※有償:¥24000 → 1380yen)★94%OFF!

去年のクリスマスセール中に激安で購入した英語のオンライン教材です。割引キャンペーン時に購入すれば、コスパ最強の教材です。Udeimyは頻繁に割引セールを実施しているので、キャンペーンを利用して上手に購入してください。ちなみに、このブログ書いている今も割引中でした(笑)

f:id:orinbou:20200429013959p:plain

Certified Kubernetes Administrator (CKA) with Practice Tests

この教材の優れた点は、下記の点です。

  • 動画で体系的に学べる(英語苦手ですが図の説明で何とか理解できる)
  • 動画で学んだあと、すぐにテストで手を動かして確認できる
  • 実践に近い模擬テスト(Mock Exam)が3セット用意されている

    実際に手を動かす(kubectlコマンドなどを打つ)テストはUdeimyのコース購入で利用可能になるサイト(kodekloud.com)上でWeb経由で実施できるため、手持ちのPCにk8sクラスタ環境を準備する必要がなく非常に手軽にトレーニングすることができます。試験対策という意味では、もうホントこれだけでいいっていう感じです。特に最後の模擬テスト(Mock Exam)は3~5周くらいやって反射的に手が動くように訓練しました。

このコースは、全17章242セッションあり、かなりボリュームがあります。私の場合、週末の時間&通勤移動時間を活用して学習を進めたのですが、全体で約3ヶ月くらい(2020年1~3月)かかりました。この準備期間を経て、4月に受験&再試験(不合格→合格)という流れでした。受験と再試験の間は2週間ほど空けて、受験の記憶が新鮮なうちに、解けなかった系の問題(トラブルシュート、JsonPath、Ingressなど)を中心に復習を行いました。

 

参考サイト:

  •  Kubernetes道場1~25日目:Udemyを見ても理解できない時よく助けられました。

    https://cstoku.dev/tags/kubernetes-dojo/

     

  • Kubernetesドキュメント:試験中に閲覧できる公式ドキュメント

    特に、ここの中でUdemy模擬試験でも試験本番中も最も利用するのが下記のチートシートのページになります。これは試験対策としてブックマーク必須です。

     

  1. Kubectlコマンドの補完(コマンド短縮のためのalias設定は必須:kubectl → k)
  2. kubectlチートシート - Kubernetes(どんなサンプルがあるか把握しておくこと)
  3. Expert Certification - Cloud Native Computing Foundation(CKA & CKAD FAQ)

 

Google翻訳(Chrome 拡張機能)

英語に慣れていない場合は、Google翻訳のChrome拡張をオススメします。Udemyの模擬テスト(kodekloud.com)の問題文や参照サイトの英語ドキュメントを選択状態にするだけで画面遷移することなく翻訳(※長文は画面遷移する必要あり)してくれます。

 

身分証明書:

受験時に身分証明書の提示が必要です。パスポートの準備をくれぐれもお忘れなく!!

 

参考書籍:

試験対策として特に書籍は読みませんでした。(※試験対策とは別でDockerやk8sの本は読みましたが、直接の試験対策にはならないと思うので、ここでは割愛します)

 

■ 試験本番の注意点!

ありがたいことに多くの人が本当によくまとめてくれています。例えばコチラです。

CNCF が提供する Kubernetes の認定資格 CKA を取得した - reboooot․net

同じことを記載してもあまり意味がないので、今回の受験に際して調査した結果、どのサイトにも記載されていなかった(地味に重要な)点を下記に記載しておきます。

 

試験環境のクリーンデスク:

この資格試験は自宅で受験することができますが、事前のクリーンデスクのチェックがとても厳しかったです。初回受験時に、本受験で使用するノートPCを机上に置いて、外付けキーボードを接続して受験しようとしたところ、本受験で使用するノートPCにも関わらず、机上から撤去しろと言われてしまいました。チャットで試験官に説明しても、聞き入れられませんでした。最終的に机の裏側に小さな棚を持ってきて、その上にノートPC置いたら何とかOKをもらえました。受験で使用するPCを机の上に置くことも許されないとは思いませんでした。そんなやり取りをやっていたせいで、試験開始予定時刻を20分くらい経過してから試験開始になりました。そのせいで試験時間が短くなってしまうのではないかと心配しましたが、遅れて開始した分は、ちゃんと試験終了時刻も延びていましたので、もし同じ目にあっても安心して下さい。再受験時は、クリーンデスクに十分配慮して望んだのでスムーズに試験を開始することができました。

 

試験中に閲覧可能なページ:

試験ハンドブックやQAでは、試験中は下記のページのみ閲覧可能とされています。

https://kubernetes.io/docs/ ←翻訳ページもOK(例:https://kubernetes.io/ja/docs/

https://github.com/kubernetes/

https://kubernetes.io/blog/

説明には、上記およびそのサブドメインの閲覧が許可されているため、下記のページも閲覧してOKです。自信を持ってブックマーク&閲覧してください。

https://discuss.kubernetes.io/

上記ページには、試験問題を解くにあたり、具体的で有益な情報が掲載されていることがあります。ブックマークしてうまく活用しましょう。また、許可ページ以外を閲覧すると失格になる可能性があるため十分注意しましょう。

 

■ 最後に

2回目の試験中、後半のトラブルシュート系の問題で、クラスタの各ワーカノードへsshして作業することがあるのですが、行ったり来たりsshしているうちに、今どこに居るか分からなくなって、うっかり大元の作業場所で「exit」コマンドを実行してしまい、画面が飛びました。試験官にチャットで助けを求めたところ、再読み込みしろと言われたので、そのとおり実行したら、試験の残り時間だけが減った状態で、それ以外の全てがリセットされているような状態で、試験が再開されました。分からない問題に目印(Flag)が付けられるのですが、それも全てキレイに消えて無くなっていました。そこまでの回答も消えてそうだ、、、完全にやっちまったな、、、と思いつつ試験官に確認したところ、回答は保存されているよと言われました。半信半疑のまま試験を続けましたが、残りの試験中も試験終了後も本当に回答が保存されていたのかが気になって、ずっとソワソワしてました。受験が終了して約31時間くらいで試験結果通知メールが来てなんとか合格してました。回答がちゃんと保存されてたみたいです(笑)。とりあえず受かってて良かった。

 

いま世界は新型コロナウイルス感染症(COVID-19)の影響で多くの人が外出できず不自由な生活を余儀なくされています。ですが、そんな状況だからこそ自宅でじっくり勉強できますし、この資格試験は自宅で受験することもできます。この機会を自己研鑽への投資に活用してみるのもまた、ひとつの有意義な過ごし方なんじゃないでしょうか。

 

次は、CKAD(CKAD-JP)試験に挑戦してみたいと思います。

*[本]業務システムクラウド移行の定石

f:id:orinbou:20200301141128p:plain

業務システムクラウド移行の定石

オンプレからクラウドへシステム移行する際の手順がステップごとに分かりやすく記載してある。経験値が少ない人、ある程度経験はあるが進め方や観点の漏れ抜けがないか気になる人にとって良い本だと思う。教科書的な内容になってて、技術的な深さはあまりなく泥臭い話(具体的な事例)とかは出てこない。

 

クラウド移行の全体手順は下記の5ステップに分けて説明されている。(※大項目)

  • Step1:企画フェーズ

 クラウドとは何かを理解したうえで、クラウド移行の目的を明らかにし、目標を設定し合意を取る。さらに、その後の進め方や体制を計画し、承認を得る

  • Step2:戦略・分析フェーズ

 現状のインフラやシステムの状況を把握するとともに、クラウドに要求される事項などを明確にする。移行の対象候補システムや移行の順番付けの考え方などを明らかにする

  • Step3:PoC(実証実験)フェーズ

 詳細な設計作業や標準化作業にはいる前に、実際にサービスを利用しながら、プラットフォームに関する懸念点などを検証する

  • Step4:設計・移行フェーズ

 ここまでの内容を踏まえ、システムごとに設計や移行を行う。必要に応じて、標準化や共通化も推進する

  • Step5:運用・改善フェーズ

 運用を開始する。運用を通じて得た知見に基づき、戦略を見直したり設計内容を改善したりする

 

また、移行プロジェクトを進めるにあたり、主導権を社内の情シスがCoEを組織して担当することの重要性についても言及している。これは 前回記事 にも通じるものがある。(丸投げは空洞化を招くのでアンチパターンという文脈のやつ)

 

最終章(5.5章)の、某ITコンサルタントの次のセリフが印象的でした。

「実はこの考え方は、クラウド移行だけに当てはまるものではありません。新規ビジネスの立ち上げや新しいシステムの構築など、変化する環境の中で早く成果を出す必要のある領域全てに適用できます」

アジャイルコーチ Ryutaro YOSHIBA (@ryuzee) | Twitter さんらしいですね(笑)

 

books.rakuten.co.jp

*[本]百年アーキテクチャ~持続可能な情報システムの条件~

f:id:orinbou:20200224113125p:plain

オージス総研の本 [百年アーキテクチャ]

10年近く前に書かれた本ですが、それほど古さを感じない内容でした。この本が本質を突いているということもあるんだろうけど、日本のIT活用や業界構造の課題がこの10年間それほど変わっていないってことなのかもしれない。アジャイル開発やレガシーオフショア(主に中国に対する)による失敗などについても言及されており、なかなか共感できる点も多かった。

 

この本で語られている「百年アーキテクチャ」のコンセプトは、ビジネス(業務)とそれを支える情報システム(IT)をモデルの形で整理しておき、ビジネスを変更した際に、遅れなく情報システムも変化修整(※「修正」でなく)できるようにする、というものだそうだ。

 

この本の全体を通じて、下記に示す4つのアーキテクチャ成熟度ステージ(MIT Sloan)を前提にして様々なことが語られており、このステージ間の移行には、技術、プロセス、そして何よりも社員の文化が深く影響するんだとか。各ステージに見合った戦略をとらないとうまくいかない、ってのは確かに。あまり体系的に考えたことなかったのでこの観点は参考になる。

  • ステージ1.Business Silos:個別IT(サイロ型システム)

 個々の利用部門のビジネスニーズやシステムへの要求を最大限満たすことに注力

  • ステージ2.Standardized Technology:標準化でコストダウン(IT標準化)

 技術の標準化や集中化を通じてITの効率化を追求

  • ステージ3.Optimized Core:企業全体視点(ビジネス最適化)

 企業のビジネスモデルに応じて、全社視点からのコア業務とコアデータの標準化を進める

  • ステージ4.Business Modularity:戦略視点(ビジネスモジュール化)

 疎結合状態でサービス化されたビジネスプロセスコンポーネントを再利用して、コア部分はグローバル標準を担保しつつローカルの自由度を許している

 

この本の中で紹介されているシステム・ダイナミックス(SD)モデルによるステージアップのシナリオでは、1つのステージに必要な期間を5年として、4つのステージを20年かけて上がっていくと説明されているのだが、これではいくらなんでも遅すぎるように思えた。ただ、百年アーキテクチャ、って言ってるので、本気で100年を前提にするなら、その1/5の20年をかけるってのは、妥当ってことなのか。ケース・バイ・ケースなんでしょうけど、この時間感覚にはちょっと共感できなかった。

 

ビジネスにおいて企業のIT戦略が重要な地位を占めるようになっていく(※現在は、もう既になっていると思うけど)ので、企業のIT部門(情シス?)も成長していく必要がある。というのは、ずっと言われていることですね。今後は、今以上にビジネスにスピートが求められてくるとなると、多重請負構造による丸投げ開発っていう伝家の宝刀は、今までみたいには使えなくなりますね。

 

下記の図は、この書籍(P.133)でも紹介されている情報サービス産業協会(JISA)が2009年5月に今後5~10年間の業界構造変化についてまとめたもの(つまり10年前の資料)です。既に10年が経過していますが、まだ展望のようにはなってないかもしれません。しかし、これからベンダが生き残っていくためには右側(展望)で飯食えるようになっていかないと淘汰されるんでしょうね。

f:id:orinbou:20200224143828p:plain

巷では、DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~(METI/経済産業省)とかって言われてますし、最近の採用の動向を見てみても、IT企業じゃない企業(製造業や量販店など)のIT部門強化と思われる中途採用の求人も非常に多いので「全ての企業が“IT企業”に」っていう時代になりつつあるのを感じます。

 

books.rakuten.co.jp