Agile

2020/09/02

問題解決アプローチを見極める『クネビンフレームワーク』のメモ

問題解決アプローチを見極める『クネビンフレームワーク』を知ったのでメモ。
結論のないメモ。

【参考1】
akipiiさんはTwitterを使っています 「クネビンフレームワークの説明が参考になった。問題のドメインが時代で変化しているからソフトウェア開発プロセスも変化する。非開発者のためのアジャイル開発入門 by @haradakiro #agile #complex https://t.co/2iCYVDeddY」 / Twitter

More Effective Agile ? “ソフトウェアリーダー”になるための28の道標|かず|note

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

(引用開始)
カネヴィンフレームワークは1999年にIBM Global Servicesのデイブ・スノーデン(Dave Snowden)らが提唱したもので、状況・問題を大きく4つのドメインに分類するフレームワークです。(上画像)

1.Simple(シンプル):単純
⇒問題の因果関係・構造が明確

2.Complicated(コンプリケーティッド):煩雑
⇒少し分析すれば、因果関係・構造が明確

3.Complex(コンプレックス);複雑
⇒因果関係が複雑、調査・探索が必要

4.Chaotic(カオス):混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい

その他.Disorder(ディスオーダー):無秩序
⇒直面する問題に適切な解決策がない

さらに、1のSimpleと、2のComplicatedを予測可能な問題、3のComplexと、Chaoticを予測不可能な問題と分類することもできます。
(引用終了)

製造業における製品製造の大量生産方式のビジネスと、エンジニアやコンサルタントなどの知的労働者がプロジェクトで仕事するビジネスは、本質的に何かが違うといつも思っていた。
その理由の一つは、問題解決アプローチが全く違う、という指摘を、クネビンフレームワークは教えてくれる。

クネビンについて講演してきました | サーバントワークス株式会社

(引用開始)
(クネビンフレームワークが必要とされる)背景としては、「正解がない」多様化した問題と現実解に対しての理解を深めることが第一義です。第二儀としては、アジャイルの必然性の腹落ち感があります。
(引用終了)

アジャイル開発が昨今必要とされる背景には、従来の問題解決の手法が通用しなくなってきていて、新しいフレームワークや考え方による問題解決手法が必要とされているのだろう。
「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイル開発による問題解決の観点はクネビンフレームワークの「複雑(Complex)」に当たるのではないか、という内容があるらしいので、今度読んでみたい。

【参考2】
複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

クネビンフレームワーク Cynefin Framework :臨機応変の意思決定手法 ? I & COMPANY / アイ&カンパニー

カネビン・フレームワークで問題解決策を見極める

クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案 | Developers.IO

問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩

(引用開始)
これをエンジニアのロールに置き換える広木さんのツイートはすごいなと思ったので参考まで
(引用終了)

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの?みたいなことを聞かれる。 これはクネビンフレームワークで捉えるとわかりやすい CTO は Chaoticな問題 -> Complex VPoE/EMは Complexな問題 -> Complicated TechLeadは Complicatedな問題 -> Simple 不確実性が減っていく https://t.co/un1FX3QQ53」 / Twitter

akipiiさんはTwitterを使っています 「クネビンフレームワークでカオスで複雑・複合的な問題を分類する。CTO/VPoE/TechLeadというエンジニアのロールはクネビンフレームワークで整理すると分かりやすいという指摘。 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩 https://t.co/exz3rCJnfw」 / Twitter


| | コメント (0)

2020/09/01

OODAループはScrumにどんな考え方を注入し、影響させたのか

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、OODAループが紹介されていた。
ラフなメモ書き。
考えがまとまっていない。

【参考】
アジャイルの源泉、OODAループとは何か? - Qiita

米空軍パイロット撃墜王の研究 「OODA ループ」 は、ビジネスにも示唆があり興味深い|多田 翼 - #ビジネスセンスを磨くノート|note

OODAループの歴史:世界の軍事戦略を全面転換 ? I & COMPANY / アイ&カンパニー

OODA について講演してきました | サーバントワークス株式会社

【1】OODAループの本質は何だろうか?
OODAループはScrumにどんな考え方を注入し、影響させたのか?

OODAループは、従来のPDCAサイクルと何が本質的に異なるのか?

【2】「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、Scrumを生んだサザーランドがベトナム戦争のパイロット経歴を持ち、こういう軍事経験を元にScrumを編み出した、という歴史の方が興味深かった。
生死の境にいる現場で、生き抜くために、どんな考え方や意思決定が必要なのか?
いくら軍事戦略や戦術が優れていても、戦場は刻一刻と変化して、今までの経験を多用できない。

米空軍パイロット撃墜王の研究 「OODA ループ」 は、ビジネスにも示唆があり興味深い|多田 翼 - #ビジネスセンスを磨くノート|note

(引用開始)
空軍の空中戦では、いかなる状況でも必ず敵機を撃ち落とす「撃墜王」と呼ばれるようなパイロットが現れます。
アメリカ空軍の研究目的は、空中戦での撃墜王は他の一般的なパイロット比べて何が違うのかを知ることでした。
研究結果から、パイロットが敵機を見つけてから攻撃、または回避行動をするプロセスで、優秀なパイロットとそうではないパイロットを比較すると、3つのことがわかりました。

研究結果
・敵機の観察段階 (Observe) で統計的に有意な差はない
・状況判断 (Orient) と意思決定 (Decide) の速さに有意な差がある
・行動 (Action) では有意差はない
つまり、状況判断と意思決定で、パイロットの優秀さが決まるという研究結果です。
(引用終了)

敵の意思決定より早い意思決定を行い、そこから行動することで、相手の意思決定を鈍らせる。
つまり、動く的に対し、優れた観察眼で、状況判断と意思決定を素早く行い、行動に移す。

OODA について講演してきました | サーバントワークス株式会社

(引用開始)
プロダクト開発では、正解がわかっていない状況下で推進することが多く、アジャイルに代表される実証により、経験的に推進していくことが多くなってきています。
そこでは、反復的かつ漸進的なアプローチとなるのでOODAループがそれに似ているとも言えます。
スティーブ・マコネルは著書の中で、スクラムの「検査と適応」はOODAループととても関連があると述べています。
(引用終了)

【3】PDCAサイクルとScrumの違いは、計画駆動なのか、観察駆動なのか、という違いもあるだろう。
PDCAサイクルでは、計画にすごく時間をかけて、計画と実績の予実管理によって、リスクを測定し、判断を下す。

一方、スクラムは「経験主義」と言われる。
つまり、スクラムは実践で得られた経験を元に、あるべき方向を見極めて、意思決定を下し、そのフィードバックを経ながら軌道修正していく。
スクラムでは、最初からベストプラクティスがあるわけではない。
観察して経験していきながら、より良い対処を探していく。

スクラムガイドをきちんと読もう - Qiita

(引用開始)
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。
スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。

透明性
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
(中略)
検査
スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査担当者が念入りに行えば、検査は最大の効果をもたらす。

適応
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
(引用終了)

| | コメント (0)

2020/06/14

SaaSのビジネスモデルがアジャイル開発を促進したという仮説

「ソフトウェア・ファースト」を読んで、改めて、アジャイル開発はSaaSの開発プロセスを発展させたものとみなすのだと考えた。
ラフなメモ書き。

【参考】
ソフトウェア・ファーストの感想: プログラマの思索

【1】「ソフトウェア・ファースト」を読むと、製造業などの一般産業は、SaaSのようにどんどんサービス化すべきだ、という主張が背景にあるのが分かる。

では、SaaSというビジネスモデルの特徴や本質は何だろうか?

この問いに自分なりに考えてみたら、複数の特徴があるように思う。

【2】SaaSはScrumと相性が良い。
たとえば、パッケージ製品ビジネスや大量生産ビジネスでは、たくさん作って販売してそれで終わり。
一括請負契約で作って納品したら終わり。
顧客とメーカーは、クライアント-ベンダー-アンチパターンにはまりやすい。

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

一方、SaaSでは、常にサービスや機能を頻繁にVerUpしていく。
その頻度も1ヶ月に1回ではなく、1日に数十回もざらだ。
SaaSのインターフェイスは、ユーザがスマホやPCで触っているので、すぐにその機能を試してもらえるし、彼らの要望を即座に反映するほど、顧客満足も高まる。
そういうニーズがあるので、頻繁なリリースを実施する動機づけになる。

その場合、社内の開発体制はScrumに似せると開発しやすくなる。
マーケティング担当者や経営者がプロダクトオーナーの役割を担えば、社内に開発チームとスクラムマスターを作れば、即座にScrumが出来上がる。
SaaSの場合、プロダクトオーナーに相当する人が社内に存在し、その能力を持ち合わせている時も多いのがメリットだろう。
その後は、会社の規模やビジネスの規模に合わせて、Scrumをスケールすればいい。

【3】SaaSはDevOpsと相性が良い。
リリースしたら、その後も運用し続けるので、開発と運用保守は一体化すべき流れになる。

一方、普通のSIであれば、インフラチームと開発チームは分離されていて、機能別組織になりやすい。
機能別組織の弱点は、チームや組織ごとに体制の壁ができてしまい、意思疎通が困難になることだ。
コンウェイの法則「アーキテクチャは組織に従う」によって、システムのアーキテクチャは縦割りの複雑な組織構造を反映した形になってしまい、システムはどんどん複雑化してしまう。

もちろんSaaSも、ビジネスが発展すれば肥大化するだろう。
しかし、開発と運用保守は一体化した方がいいというビジネス要求や現場からの要求が出てきやすいので、DevOpsを推進する動機づけになる。

もちろん、技術的にも、SaaSはクラウドと相性が良い。
だから、クラウドエンジニアはインフラエンジニアだけでなく、開発者でもありうるので、事実上、インフラチームと開発チームは一体化しやすい。

また、ここからマイクロサービス・アーキテクチャも実装しやすい。
AWS上でSaaSを運用すれば、LambdaやAurora、AWSの各種サービスを利用することになるだろう。
単に性能改善やスケールメリットが活かせるだけでなく、システム基盤をマイクロサービスとして組み立て直すことにより、SaaSは汎用的なAPI基盤になっていくだろう。
そうすれば、外部サービスと連携できるので、より多種多様な機能を顧客に提供しやすくなるメリットも出てくる。

【4】SaaSはB2Cのプラットフォームビジネスと言える。

アメリカのGoogle、Amazon、Apple、Facebookがそうだし、中国のBATも同様だ。
多数の顧客に対し、プラットフォームを提供することで利便性がどんどん増していく。
そのビジネスの本質は、製造業が持つ規模の経済ではなく、ソフトウェア特有のネットワークの経済という理論が背景にあるはず。
たくさんのユーザが使ってくれるほど、SaaSは重要性を増して、売上を指数関数的増大させていく。
「プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか」を読むと、プラットフォームのビジネスモデルは独占ビジネスなので、その売上は、そのサービスの市場規模と同等になるまで高められる。
つまり、市場規模と同等だから、小さい国家のGDPよりもはるかに大きな利益を得ることも可能。

SaaSはB2Cのビジネスなので、顧客のフィードバックをすぐに取り込みやすい。
ランダム実験やABテストも実現しやすいので、サービスやビジネスモデルを仮説検証しやすい。
つまり、SaaSでは、念入りに考え抜いた計画を作って数年かけてリリースするよりも、仮設を立てたら、複数のサービスを同時リリースして、ランダム比較化実験でその効果を測定した方が速い。

興味深いのは、米国や中国では、SaaSのトッププレーヤーはB2Cなのに、日本の楽天やモノタロウなどはB2B2Cというスタイルで異なる点だ。
もちろん、LINEのように、日本国民の殆どとつながっていて、その連絡先とつぶやきのようなログデータを既に持っている会社はB2Cだ。
しかし、日本で目立つSaaSプレーヤーはB2Bのクッションを通過した後でB2Cを提供するビジネスモデルが多いように思える。
その理由は分からないので、いつか知りたい。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

規模の経済と経験曲線効果のメモ: プログラマの思索

【5】SaaSでは、大量のログデータがビジネスの副産物として採取される。
データはいくらでもある。
そこから、機械学習やディープニューラルネットワークに大量データを食わせることで、優れたAIエンジンを生み出すことも可能だ。
B2Cのプラットフォームビジネスでは、ユーザの個人情報は特定できるし、その購買行動はプラットフォーム上で全て追跡できる。
よって、ペルソナを仮想的に作って、より購買を促すようなプロモーションを打ち出して、潜在ニーズを掘り起こせる。

「告発 フェイスブックを揺るがした巨大スキャンダル」によれば、Facebookで、個人に68個のいいねがあれば、その人物に関する非常に具体的な情報をモデルから予測できる。
70個のいいねで、そのユーザの友人が知るよりも、その人の多くの個人情報がモデルから推測される。
150個のいいねで、親よりも、その人の多くの個人情報がモデルから推測される。
300個のいいねで、パートナーよりも、その人の多くの個人情報がモデルから推測される。
さらにその多くのいいねを見れば、ユーザが自分自身について知っていると思っている以上の個人情報がモデルから推測される。
つまり、個人の大量のログデータを収集できれば、その個人を丸裸にできる。
その個人情報を他人が知っている情報だけでなく、その個人自身が知らない潜在ニーズまで推測できるわけだ。
すなわち、ジョハリの窓という理論は、AIを使えばほぼ完全に実現できる可能性があると思う。

(それを悪用したのが、ケンブリッジ・アナリティカであり、彼らは、どの個人にどんなプロモーションを送ればどんな選挙行動に移してくれるか、を徹底的に研究して、トランプ効果や英国のEC離脱を生み出したわけだが。)

そんなことを考えると、SaaSは機械学習やニューラルネットワークと非常に相性がいい。
だから、テスラみたいに製造業もどんどんSaaSにシフトしているのだろうと思う。

| | コメント (0)

2020/05/24

「クライアント-ベンダーアンチパターン」という根本問題

今更ながら「ユーザーストーリーマッピング」を読んだ。
この本で一番ピーンと来たのが「クライアント-ベンダーアンチパターン」。
自分が理解したメモ。

【参考】
【復習】CSPO研修(2) クライアント-ベンダー アンチパターン - きっと、うまくいく~非IT業界をスクラムで変えるための系譜~

「ユーザーストーリーマッピング」を読んで | GMOインターネット 次世代システム研究室

『ユーザーストーリーマッピング』|感想・レビュー - 読書メーター

(引用開始)
プロダクトオーナー向けの推薦図書、と紹介を受けて読む。様々な局面でのベストプラクティスとアンチパターンが書かれており、スクラムマスターや開発チームの人達と読んでも面白そう。終始いいこと書くなぁと思いつつ読む。
大きな組織内でも、社内ベンチャー的に何かサービスを作ってみよう、新規サービスを、とするチームにも必読かな。
SIer的には「クライアント-ベンダーアンチパターン」が刺さる。こうはならないように間を取り持つような、うまい関係性を構築したいものだなと思う。近いうちに再読、リファレンス的に使いたい。
(引用終了)

【1】「クライアント-ベンダーアンチパターン」こそが、ストーリーの活用を阻害する最大のアンチパターン。
「ユーザーストーリーマッピング」は、いかにしてこのアンチパターンを解決すべきか、色んな角度から解決方法を述べているように感じた。

「クライアント-ベンダーアンチパターン」では、発注者であるクライアントと提供者であるベンダーが敵対関係になる。
クライアントは要件を話して、ベンダーに見積もりを要求する。
見積もりは契約と同義語なので、ベンダーはリスク回避のために、ガチガチの要件を定義して、コンティンジェンシーも加味した見積もりを出す。
そして、リリース前後にクライアントはこんなものを期待したわけではなかった、と言い出す。

特に、日本のSIとユーザ企業は、まさに「クライアント-ベンダーアンチパターン」に陥っている場合が多い。

「クライアント-ベンダーアンチパターン」の本質は、問題と解決方法の会話が要件とその合意の議論にすり替わっている点にある。
本来、クライアントは業務上の何かの問題を解決して欲しくて、システム導入による解決方法をベンダーに期待する。
ベンダーはIT技術屋なので、技術がどのように役立つのか、をよく知っている。
しかし、「クライアント-ベンダーアンチパターン」のように、クライアントとベンダーで役割が分離されてしまうと、システム開発のリスクをどちらかに投げたい気持ちが強くなり、互いにリスク回避の行動になってしまう。
システムシンキング的には、共有地の悲劇みたいな感じかな。

「ユーザーストーリーマッピング」では、医者と患者の関係に近づけるべきだ、とアドバイスする。
医者は患者を検査し、どこに問題があるのかを調べて処方する。
同様に、ベンダーも医者のように振る舞い、要件ではなく、本来の問題解決の役割に徹するべき。

【2】「プロデューサーとしてのプロダクトオーナー」という節も重要だ。
古いIT部門にいると、プロダクトオーナーという概念が分かりにくい。
特に基幹系情報システムの担当にいると、誰が最終決定を握っているのか分からない。
なぜなら、誰もシステムの全てを知っていないから。
サブシステムや各サービスの要件を決めるプロダクトマネージャがいるだけだ。

すると、こういう古い組織では、ビジネスアナリストなる人が要件収集の役割を与えられる。
彼らは、サブシステムごとのプロダクトマネージャや利害関係者というビジネスピープルと、開発者の間の仲介者の役割を果たす。
この時に、ビジネスピープルがクライアント、ビジネスアナリストがベンダーの役割を演じて、「クライアント-ベンダーアンチパターン」が発生する。
ユーザ企業側にいると、まさにこういう症状が発生しがちで、要件定義フェーズでよく行き詰まる。

「ユーザーストーリーマッピング」では、ビジネスアナリストが音楽バンドに対するプロデューサーのような役割をにない、医者と患者の関係に近づけるべきだ、とアドバイスする。
この比喩はとても上手い。

一方、僕は当初は、ユーザ部門がプロダクトオーナーの役割を担うべきだ、と思っていた。
本来は、ユーザ企業のIT部門がベンダーと張り合えるぐらいの技術力を持たいないと、技術の目利きやベンダー管理なんてできないでしょ、と思っていた。
しかし、現実は厳しい。

プロダクトオーナーの仕事もスキルも簡単なものではない。
ユーザ部門がプロダクトオーナーの役割を全て担うのは、スキルがなければ危険だ。
ビジネスアナリストはユーザ部門を手助けするプロデューサーの役割を担う方がいい。

【3】この指摘は、「エッセンシャルスクラム」に出てくる「プロダクトオーナープロキシ」の役割に似ている。
つまり、「プロデューサーとしてのプロダクトオーナー」は「プロダクトオーナープロキシ」、つまり、プロダクトオーナーの代理人と同義語と思える。

ユーザ部門の人に時間を与えて、プロダクトオーナーの仕事を担当してもらうが、ビジネスアナリストまたは情報システム部門がプロダクトオーナーと開発チームのやり取りを担当し、特定の状況ではプロダクトオーナーの代わりに意思決定できる役割も担えるようにする。
つまり、ビジネスアナリストまたは情報システム部門はプロダクトオーナーと同じ立ち位置にいて支援も行い、問題解決を図るようにする。

【4】「クライアント-ベンダーアンチパターン」を読み直すと、日本のソフトウェア開発の問題はここに尽きるのではないか、と思ったりもする。
ユーザ企業は一括請負契約としてベンダーを縛り、開発リスクをベンダーに負わせる。
だから、ベンダーはリスク回避のコストを見積もりに入れて、多額の開発費用を契約する。
そして、要件定義でベンダーの支援範囲を固定し、リスクを回避しようとする。
お互いに敵対関係となり、「クライアント-ベンダーアンチパターン」にはまる。

その点、スクラムはよく考えられていると思う。
プロダクトオーナーの人は、開発チームに入り、スクラムチームの一員になることで、開発チームと一体化する。
その結果、プロダクトオーナーは開発チームとコミュニケーションが取りやすくなるし、開発チームも、要件ではなく本来の問題を認識できるので問題解決がより即した形になる。

また、ユーザ部門がプロダクトオーナーとして完全に発揮できない場合、ビジネスアナリストや情報システム部門がプロダクトオーナープロキシになって、プロダクトオーナーと開発チームの仲介役を担う。
その結果、ユーザ部門の要望や問題意識は、プロダクトオーナープロキシによってシステム内容に置き換えられて、開発チームに渡されるようになる。

【5】こういう話を聞くと、日本人は、大規模な官僚組織を操縦するのが本当に下手なんだな、と思う。
中国や米国や欧州の人も上手いとは言えないが、日本はもっと下手すぎる。

中国は2千年以上も前から、非宗教的な官僚組織を作り出し、それをいかに手懐けるか、に知恵を絞ってきた。
欧米は社会心理学や行動経済学、組織行動学などの学問を揃えることで、官僚組織の運営に、概念や理論を適用してきた。

一方、日本人は腹芸や根回しみたいなスキルばかりに注力して非効率的だ。
もっと、組織運営というスキルを磨くべきなんだろうな、とか思ったりする。

【追記】先日、@ryuzeeさんと、@kyon_mmさんのやり取りも非常に参考になった。

Ryutaro YOSHIBAさんはTwitterを使っています 「そもそもPOとSMは利害相反する箇所があるので、1人に内包すると歯止めが効かない。たくさん作りたいPOと持続可能にやりたいSMでバランス取るみたいなのできないしね」 / Twitter

きょん@アジャイルコーチ、システムアーキテクトさんはTwitterを使っています 「@ryuzee なぜ人がわかれているとできるんですか?」 / Twitter

Ryutaro YOSHIBAさんはTwitterを使っています 「@kyon_mm 書き方よくなかったかもね。分かれてても出来ないこともある。当たり前だけど健全な関係性の上に成り立つので、PO・SMが主従関係みたいな感じならかわらんね。」 / Twitter

| | コメント (0)

2019/11/09

Scrum@Scale入門のリンク

原田さんのScrum@Scale入門のリンクをメモ。

【参考】
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門(前編)。Developers Summit 2019 - Publickey

スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門(後編)。Developers Summit 2019 - Publickey

Scrum@Scale Guide | Scrum at Scale Guide | Guide for Scaling Scrum

Scrum@Scale 入門 | Attractor Inc

大規模Scrumの話は最近良く聞くけれど、どのように拡張しているのか分かっていなかった。
上記の記事を読んで、何となくイメージが浮かんだ。

Scrum@Scaleで優れていると思った点は、課題管理などの意思決定プロセスが階層化されているにも関わらず、意思決定のスピードが速いことだ。
Scrum of Scrumを組織構造に合わせてマッピングさせている点がうまいな、と思った。

(引用開始)
これをSAAB Technologiesという会社、戦闘機のグリペンの開発でやっています。ゲームの「エースコンバット」をやっている人なら、グリペンは良い機体だっていう人、いますよね?

彼らは製造業なので朝が早いです(笑)

7時30分 SCRUMチームのデイリースクラムがあります。
7時45分 SoSのデイリースクラムがあります。
8時00分 SoSoSのデイリースクラムがあって、
8時15分 SoSoSoSのデイリースクラムがあって、
8時30分 EATがあります。

というわけで、スクラムチームが価値を届けることに困るような課題があれば、1時間後にはトップエグゼクティブの知るところとなって、そのEATでさっさと課題に対応できると。圧倒的に早いですよね。
(引用終了)

EATは取締役会に相当するらしい。
最終的な意思決定の責任は、会社の最高意思決定機関に委ねられる。
会社法上の仕組みとScrumの仕組みを上手く調和させるように作っているわけだ。

AgieTourOsakaに行ってきたが、最近の大規模Scrumの事例では、IT企業に限らず、一般企業にも導入されているよ、と聞いた。
話を聞くと、どうやらソフトウェア開発だけでなく、会社の一般業務にもScrumを適用しようとしているらしい。おそらく、Scrum@Scaleのように、課題に対する意思決定プロセスという現場のプロセスと、会社法上の組織としての意思決定の責任を上手く調和させるように、Scrumの仕組みを拡張しているのだろう、と直感している。

そういうことを考えると、Scrumは大したマネジメント・フレームワークなのだな、と改めて思う。
詳細は今後も調べていく。

akipiiさんはTwitterを使っています: 「すごく良い記事。大規模スクラムでも、最小限の官僚主義を入れる辺りが現実的な判断してるなー。RT @hidenorigoto: “スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門(前編)。Developers Summit 2019 - Publickey” https://t.co/1oclrFQoWe」 / Twitter

【追記】
原田さんから、Scrum Patternの本が出版されているのを教えてもらった。
ペーパーバックで高価だが、オンラインでも一部は読めるらしい。

Scrum Patterns

| | コメント (0)

2019/07/03

Redmineのワークフローをバリューストリームマップで描いてみるとどう改善できるか

バリューストリームマップを使う機会があったので、ラフなメモ書き。

【参考】
VSM (Value Stream Mapping) のススメ?開発プロセス可視化? - Qiita

バリュー・ストリーム・マップを作る 22 のステップ ? リーンシックスシグマの現場

バリューストリームマップを描く時のポイント - Togetter

「リーン開発の現場」はアジャイルサムライの再来となるか: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

「リーン開発の現場」の感想part5~かんばんと因果関係図がセットで運用されるのは何故か: プログラマの思索

【1】バリューストリームマップを使ってみて、Redmineのプロセス改善に使える感触を持った。
特に、Redmineのワークフローを見直す時に有効だろうと思う。

一般に、Redmineのワークフローは既存業務のワークフローをそのままマッピングする場合が多い。
すると、ToBeでなくAsIsの業務フローをそのままマッピングしてしまうので、既存の問題点を残したままRedmineに実現してしまう。
その問題点はRedmineで可視化されるので、改善すべきだという意識改革にはつながるが、改善の方向性はすぐには決まらない。
問題点のどこに着目すればよいか、観点が発散してしまいがちだからだ。

そこで、バリューストリームマップでワークフローを見える化し、問題点を明確にしてみるやり方が有効のように感じた。

一般に、日本企業は縦割り組織なので、業務フローも縦割りで分断されてしまう為に、ワークフローが非常に長くなりがちだ。
そういう部分をバリューストリームマップで描くと、タスクは必ず担当する組織・部門で表現され、そのタスクごとにステータスが割り当てられる。
いわゆる官僚制組織になりがち。

バリューストリームマップでは、ステータスが切り替えられるタイミングで、リードタイム(経過時間)とプロセスタイム(作業時間)、作業人数を必ず書く。
この点が非常に重要だ。
なぜなら、リードタイム-プロセスタイムに当たる待ち時間が長い部分こそが、このワークフローのボトルネックだからだ。
そのボトルネックをいかになくすか、という観点がプロセス改善策につながるからだ。

【2】実際にやってみると、ワークフローの最初から最後までのリードタイムに対し、待ち時間は80%を超える場合が意外に多い。
その原因は様々だ。
たとえば、プロマネの承認、レビューアのレビュー承認、顧客の仕様変更の承認など、第三者の承認で待ち時間が長期間発生する。
あるいは、並行タスクで忙しいために、本来着手すべきタスクを放置してしまった、とか。
あるいは、IT全般統制の成約のために、開発部門とインフラ部門の間で無駄にキャッチボールしている、とか。

実際、放置チケットで、新規から完了ステータスまでの日数と、チケットで実際に作業した稼働日数を比べると、チケットの稼働率は10%とかひどい数字になりがちだ。
そういう状況は、バリューストリームマップで一目で表現できるので、どこに問題があるのか、分かりやすいメリットがある。

【3】バリューストリームマップをワークショップで描いてみて面白いと感じる部分は、全体のワークフローを知る人が実はその会社にはいない、という事実が判明した時だ。
各担当者は担当する業務だけに閉じていて、タコツボ状態になっている。
実は、ワークフロー全体を統括するプロマネがいないわけだ。
だからこそ、既存の業務フローに問題が発生しているわけだ。

Redmineで放置チケットが発生しやすい問題も、実は、チケット管理のワークフローの全体に責任を持つ人がいないことが最大の原因だろうと思う。
チケットを完了ステータスへ持っていく、という責任感をチームのメンバー全員が認識していなければ、当然、チケットが放置されても、自分は関知しない態度に落ち着くからだ。

その解決手段として、その責任感を自然に生み出す仕組みとして自己組織化が使われていたり、その責任感の重さを感じさせないような仕組みとして心理的安全性が生み出されたりしたのだろうとも思う。

アジャイル開発からDevOps、自己組織化、心理的安全性へつながる昨今のマネジメント技術の流れは、そういう一連の流れから捉えると理解しやすいと思う。

一方、Redmineによるチケット管理の観点では、チケット管理のプロセスを守る守護神は、Redmineエバンジェリスト、Redmine警察やRedmineマイスターになるのだろう。

【4】バリューストリームマップでは、LT(リードタイム)、PT(プロセスタイム)だけでなく、手戻り率や直行率を求めている点が面白かった。
そこまで計算しているのか、と。

自動車メーカーに勤務しているんですが、合格率と直行率の求め方(計算式)、... - Yahoo!知恵袋

直行率(%)=一発合格数÷製造実績数×100

たとえば、手戻り率が10%ならば、直行率=90%になる。

実際にソフトウェア開発の業務フローで計算してみると、各タスクの手戻り率を合計していくと、直行率は50%を切る場合が多かった。
つまり、完成品の中身の半分は、手戻り作業で作られたことになる。
一般の現場は知らないが、この事実を悪いと見るかどうか?

【5】バリューストリームマップをRedmineの一機能として実現できると面白いと思う。
具体的には、Redmineのワークフローにおけるステータス間の稼働日数(プロセスタイム)と滞留日数(放置日数)がグラフィックに表現されると良い。
例えば、レビュー待ち→レビュー完了のステータス間では、稼働日数は1日以下なのに、滞留日数が5日以上とか普通にありがちだ。

あるいは、1チケットのサイクルタイム(新規~完了までの日数)と稼働日数の割合を各プロジェクト、各バージョン単位で集計する、とか。
つまり、プロセスサイクル効率(=作業日数/経過日数)を表現したいわけだ。

【6】実は、この概念は「プロセスサイクル効率」として、既に「リーン開発の現場」で既に紹介されている。

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

プロセスサイクル効率=作業日数/経過日数

・作業日数=実際に開発(作業)していた日数。
 ⇒WIPステージ(開発中→システムテスト準備OK→システムテスト中)で貼られていた期間。
・経過日数=サイクルタイム。
 ⇒開始日(次の10機能→開発中)から終了日(システムテスト中→受入テスト準備OK)までの期間。

「リーン開発の現場」では、プロセスサイクル効率を効率化する意識がない限り、普通の企業では10~15%程度だろうと言っている。
つまり、一般企業では、1チケットのサイクルタイムのうち、85~90%は待ち時間であり、真の稼働時間(プロセスタイム)はわずか10~15%に過ぎない事実を示している。
すなわち、チケット管理の計画を立てた時点で、チケットの予定期間の9割は無駄な時間を消費しているわけだ。

この事実が自分のRedmineに当てはまるのか、実際に試してみればいい。
Redmineでは予実の全情報が蓄積されているので、プロセスサイクル効率の検証は可能なはずだ。
もしその事実が自分のRedmineに当てはまるならば、改善すべき点が山ほどあることを示している。

Redmineエバンジェリストは、まさにそのボトルネックを改善すべき役割を担っているのだろう。

| | コメント (0)

2019/06/15

「アジャイル時代の開発」スライド資料のリンク

「アジャイル時代の開発」スライド資料が素晴らしいのでメモ。
以下は感想を交えたポエム。

【参考】




下記の文言が心に響いた。

(引用開始・一部修正)
プログラミングはエラーとの戦い。
巨人の肩に乗るために巨人を探す作業。
リアルを知らない人は嘘(の数字)を欲しがる。
(引用終了)

自分の興味の赴くままにソフトウェア開発をするのは楽しい。
でも、請負契約やビジネス上のプレッシャーを強いられるソフトウェア開発では、もっとシビアな環境でプログラミング作業を強いられる。
たった一つのバグが、プロジェクトの評価を左右したり、最終的に会社の株価を下げる要因にもなりうる。

だから、ソフトウェア開発のベストなプロセス、プラクティスを探す作業がずっと行われてきたと思う。
その一つの解がアジャイル開発、と思う。
ソフトウェア開発の特徴を最も活かしたプロセス、それがアジャイル開発ではないか。

そういえば、下記の記事も印象に残った。

本田圭佑が開発者に熱く語った50分「僕がエンジェル投資家をする理由」【de:code2019】 | BUSINESS INSIDER JAPAN

(引用開始)
「プログラミングを学んで、率直に教えてください。面白かったですか?」

西脇が投げかけると、思わず本田は無言になった。

「あれ……これ流れ的には……」と西脇が苦笑に包まれた観客に続けると、本田は少し黙ったあと、こう続けた。

「大変だな、と思いました。……僕はうそをつくのがあまり好きではないので……。面白いか面白くないかというのは、なかなか分かっていない段階なので、そのレベルまでまだ行っていない」(本田)
(引用終了)

このインタビューを読んで、本田さんは非常に正直な人なのだ、と思った。
自分が実現したいモノがあったとしても、それをプログラムで表現するにはそれなりのコード量、テクニックを必要とする。
特に、システムはその整合性を取るのが難しい。
だから、アジャイル開発などのプロセス面、自動テストや仮想環境などの開発環境面のスキルも必要になってくる。
もっともっと色々必要になってくる。

| | コメント (0)

2019/02/11

法律のケース問題をモデル化するアイデア

法律のケース問題を図解する事例を、ネットサーフィンしながら見つけたのでメモ。
アイデアをラフなメモ書き。

【参考】
中小企業診断士試験 一発合格道場 ≫ Blog Archive ≫ 【法務】ケース問題を打破する図解術

UMLの概念モデルで法律を理解するアイデア: プログラマの思索

法務脳の作り方part1: プログラマの思索

【1】上記の記事によると、法務のケース問題を図解するパターンは2つある。

【1-1】一つは、民法のように「誰がどんな権利を主張できるか」のケース。
重要ポイントは、利害関係者とその権利・義務の関係を明確にすること。
つまり、利害関係者の関係を明確にできるようにモデル化すること。

なぜなら、民法では、被害者・加害者、あるいは背信的悪意者のようなステークホルダーのうち、誰が権利を持っているのか、権利を主張できるのか(対抗要件)をケースごとに見抜くのが重要だからだ。

(引用開始)
1. 図解術その1~登場人物を整理してみる
冒頭にトラブルについての長い状況説明があり、「どのような権利を主張できるか」等の設問があるタイプの問題です。
主に民法関連の問題に多い形式です。

例として、H18年度の第9問-設問1を見てみましょう良い
不法行為と債務不履行の問題です。
(中略)
「X社が主張できるもの」を問われているので、X社をとりまく登場人物とその関係を図で整理してみます
(中略)
作図する際に意識した点は、大きく以下3点です。

・登場人物を明確にする (X社/Y/Z社/B社)
・登場人物の属性を示す (X社はライセンス利用者/Yは保持者/等)
・登場人物の関係性を示す (ライセンス契約/等)

このように登場人物が多く事象が複雑な場合には、一目で全体を俯瞰できることが重要なポイントになると思いますキー
(引用終了)

【1-2】もう一つは、知的財産法のように「ある時点で権利の出願を行うが、他社より「権利侵害である」と言われる」ケース。
重要ポイントは、時系列で権利の出願・公開・侵害の申請などのイベントを整理すること。
なぜなら、「多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要である」ためだ。

(引用開始)
2. 図解術その2~時点を意識する
知的財産権関連の問題に多い形式、過去のある時点で権利の出願を行うが、他社より「権利侵害である」と言われるようなタイプの問題です。

例として、H21年度の第9問を見てみましょう
商標権の問題です。

商標権登録を行うためにライバルであるD社への対処を問われているので、C社とD社の現在までの行動を時間の流れと共に整理してみます。
例えば、こんな感じです。

作図する際に意識した点は、大きく以下3点です。

・誰が (C社またはD社)
・いつの時点で
・何を始めたのか

多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要であると思っています
(引用終了)

【2】上記の事例より、下記でまとめられるだろう。

・民法は「利害関係者の図」が有効。
 なぜなら、権利・義務・対抗要件を明確にしたい為。
 →パッケージ図、クラス図、ユースケース図、コラボレーション図が有効か?

・知財は「イベントの時系列」が有効。
 なぜなら、先願主義なので、誰の行動が一番先なのかを明確にしたい為。
 →アクティビティ図、タイミング図?

過去にも、UMLの概念モデルで法律を理解するアイデア: プログラマの思索で、刑法の概念をクラス図でドメインモデルで描いてみる、という事例もあった。

この辺りを整理してみたいと思う。

| | コメント (0)

2018/07/05

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアというものがあるという前提で、従来から研究されている信頼度成長曲線の理論を適用した論文が非常に面白い。
もし、この論文の指摘内容が実際のソフトウェア開発の現場に適用できるならば、そんなソフトウェアはアジャイル開発こそ向いている、と言えるし、アジャイル開発の有効性の範囲が特に最近は広がっている、という事実を補強できるのではないか、と思う。
ちなみに、この論文は@sakaba37さんから教えてもらった。

以下は、浅はかな理解の元でのラフなメモ書き。

【参考】
ソフトウェア・シンポジウム 2018 表彰論文

ソフトウェア・シンポジウム 2018 最優秀論文賞 [研究論文]バグ修正時間を考慮したソフトウェア最適リリース問題についての一考察

【1】研究論文の内容は、正直難しいです。
僕も細かな内容は分かってない。
しかし、言わんとする内容は、とても刺激的。

【2】従来のWF型ソフトウェア開発では、「バグ発見時間が遅いほど、バグ修正時間も長くなる」という前提で、いかにバグを早く発見して修正するか、さらに、バグを作り込まないように予防対策を行うか、という考え方が主流だった。

この発想は、製造業の源流管理ともマッチするので、日本のWF型開発では、上流工程や超上流工程でいかにバグを作り込まないように、漏れなく高品質なものを作って後工程に流すことばかり、考えるように仕向けられていた。

つまり、「バグ発見時間が遅いほど、バグ修正時間も長くなる」は正の相関関係を意味している。

【2-1】しかし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが存在するとしたら、どうなるのか?

もし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが世の中の大半を占めていたとしたら、今までの品質予防の対策ノウハウは無意味になるのではないか?
むしろ、バグなんか気にせずにいち早く作ってリリースして、ユーザの反応を見ながら修正していく方が効率的ではないのか?

つまり、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアとは、アジャイル開発が適用できるソフトウェアと同一視できるならば、ソフトウェア開発はアジャイル開発に特化してしまえばいいのではないか?

すなわち、「バグ発見時間が遅いほど、バグ修正時間が短くなる」は負の相関関係を意味している。

【3】この論文では、信頼度成長曲線という古典的理論を使って、「修正時間を考慮した最適リリース問題」として置き直して、モデル上で理論的な計算を行っている。
確率分布を使った計算なので、細かい内容はきちんと追わないと理解したとは言えないので、僕はすぐには分かってないが、下記の結果は理解できた。

【3-1】「バグ発見時間とバグ修正時間の相関関係」について、いくつかの前提をおいた上で、モデル上で計算を行った結果は、4ページの「表 1. 最適リリース時刻と最小総期待費用」で説明されている。

ここで、α:相関関数なので、
α=+1:完全な正の相関
α=-1:完全な負の相関
になる。

また、総期待費用 C(T) 、最小総期待費用 C(T*)である。

その結果、αが+1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が増えていくので、「バグを放置していたら、修正コストは増えていくよ」というメッセージなのだと常識的に理解できる。

一方、αが0から-1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が小さくなっている。
つまり、このモデルでは、「バグを故意に放置した方が、修正コストは最小になるよ」というメッセージを伝えている。
これは、従来のWF型開発における品質の源流管理という常識とは異なる結果だ。

【3-3】この結果は、反常識的で面白いが、「バグ発見時間とバグ修正時間の相関関係」の観点で読み直せば、ストーリーはよく分かる。
つまり、従来の源流管理重視の品質管理では、「バグ発見時間とバグ修正時間は正の相関関係」の前提で語っていたけれど、それはWF型開発しか頭にない人がそういう前提で語っているだけ、とみなせる。
「負の相関関係」の前提となるソフトウェアもあるのではないか?

常識で考えると「バグ発見時間とバグ修正時間は負の相関関係にある」ソフトウェアはすごく変だ。
なぜなら、バグを放置した方がバグを速く直せる、と言っているのだから。

しかし、MTBFを高めることに注力するよりも、MTTRを短くする方に注力するソフトウェア開発プロセスがあるように、「負の相関関係」の前提となるソフトウェアもあるはずだ。
たぶん、そのようなソフトウェアはアジャイル開発に向いているソフトウェアなのだろう。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

実際、昨今のWebサービス開発では、いち早くリリースして、頻繁にリリースしながら品質向上していく開発プロセスが主流だ。
何年もかけて品質を作り込んで、ドカンと一発リリースするソフトウェアとは全く違う。

もちろん、そういうコストを掛けて品質を高く保つソフトウェアもあるし、従来はそういうソフトウェアばかりだったように思う。
今でも、航空宇宙や組込みソフトウェア、業務システムはそういう部類に属するだろう。

しかし、従来は周辺的な位置付けに過ぎなかったWebサービスのマーケットが広がり、皆が24時間スマホを触っているのが普通な現代では、アジャイル開発に向いているソフトウェアが多くなった。

とすれば、アジャイル開発に向いているソフトウェアでは、「バグ発見時間とバグ修正時間は負の相関関係にある」という事実と表裏一体なのではないか。

【4】但し、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張は、僕個人の意見に過ぎない。
上記の研究論文でも、そこまで触れられてはいない。
しかし、上記の研究論文では、理論上そういうソフトウェアが存在する前提で、モデルから何が言えるのか、を示唆している。

自分のラフなイメージとしては、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張が、上記の研究論文の発展形で保証できれば、アジャイル開発の有用性を証明できた、ということになる、と思う。

そのためには、実際のアジャイル開発の現場で、そのようなソフトウェアメトリクスを採取して、上記の研究論文の理論的検証が正しかった、という体験論文ないし実験論文が続編になればいいだろうな、と思う。

【5】信頼度成長曲線の理論は1970年代からずっと研究し尽くされていて、かなり枯れた理論と聞いているが、この研究論文では、アジャイル開発の要素を取り入れたモデルで考え直すと、古典的な理論から新たな知見が生まれる、という可能性を示唆している、と思う。
そういう意味では、久しぶりに自分の中ですごくホットになって、面白かった。

個人的には、「アジャイル開発はソフトウェア開発ですごく有効である」と証明できるソフトウェア工学の学術論文をもっと読んでみたいし、そういう論文集があると面白いだろうな、とも思う。


| | コメント (0)

2018/04/28

技術革新とエンジニアのキャリア形成にオープンソースコミュニティの存在が重要性を増している

Publickey主宰者のインタビュー記事を読んで、気付いたことをメモ。
ラフなメモ書き。

【参考】
Publickey主宰者・新野淳一氏に聞く、エンジニアのキャリア・スキルの磨き方、「稼ぐ力」の付け方 - GeekOut

【1】Publickey主宰者のインタビュー記事を読んで、印象に残った点は2つある。
一つは、クラウドとオープンソースにより技術革新の場がベンダからオープンソースのコミュニティへ移ったこと。
もう一つは、エンジニアのキャリア形成に、オープンソース活動やコミュニティ活動による貢献が重要性を増していること。

【2】現在では、技術革新の場はベンダーから発信されるよりも、オープンソースのコミュニティを中心に発信させる場合の方が多い。
たぶん、その事実もかなり知られている。

(引用開始)
取材するスタイルも昔とはずいぶん変わりました。かつてはベンダが一番情報を持っていたので、発表会に出席して、新製品や技術のことを取材していましたが、いまのメインストリームは明らかにコミュニティです。僕もオープンソースのコミュニティの情報や、フォローしているオープンソースエンジニアのTwitterを見て、業界動向をウォッチしています。
(引用終了)

上記の記事のように、一昔前は、IBMやMSなどの大企業の技術動向をウォッチするために、大企業のイベントに出向いて、情報収集するのが普通だった。
でも、今では、LinuxやRuby、Python、Wordpress、LibreOfficeなど数多くのオープンソースが市場を支配して影響を与えている。
これらオープンソースコミュニティに出向いて、優れたコミッタやそのリーダーをウォッチしたり、直接話したりする方が、情報収集が速い。

この変化によって、大企業よりも、優れた中小ベンチャーやコミッタの方がIT業界において、政治的影響力を増している、という事実が挙げられるだろう。
たとえば、UberやAirbnbなどのシェアリングサービスも一気に普及し、昨今のAIブームに乗って大きく成長している。

つまり、オープンソースを中心としたコミュニティが技術革新と新しいビジネスの創出を生み出している。
その変化にエンジニアも付いていかないといけない。

【3】すると、エンジニアのキャリア形成に、オープンソース活動が大きな影響を与えてきている。

【3-1】エンジニアがスキルを向上させるために、オープンソース活動に積極的に関わり、貢献することで、周囲に彼のスキルを認めてもらい、彼自身の価値を上げていく、という成長のらせん構造が生まれている。

(引用開始)
 そうすると、エンジニアの働き方やキャリアも変わります。それまでは、最新技術はほとんどベンダに集まっており、ベンダの技術に詳しい人が求められてきました。しかし、オープンソースという新しい価値観が生まれることで、コミュニティへの貢献がキャリアに好影響を及ぼし、スキルアップにつながるようになりました。そういう新たなエンジニアのヒーロー像が生まれたのです。

 あとは、やっぱりクラウドですね。クラウドの最大の特徴は、一言では表現できないジャンルの広さです。その分、クラウドを活用することは非常に難しくなっている。社内で学べる範囲を超えているんですね。あらゆるレイヤーに精通する必要がありますし、オープンソースやベンダの技術も追っていかなければなりません。技術だけではなく、仕事や業務についても勉強する必要があります。そういう包括的な知識は、単に仕事をこなすだけではなかなか学べないのです。会社の枠を超えて物事を学ぶ姿勢を保ち続けないと、クラウドをキャッチアップできないと思います。

 クラウドとオープンソースが出てきたおかげで、会社の中でキャリアを考える時代から、会社を超えて自分のスキルやキャリアを考える時代へと変化しました。そうでないと、エンジニアは自分のキャリア人生を生き抜けなくなってきています。Linuxが出てきた頃からそういう雰囲気はありましたが、クラウドの登場で、その傾向が一段と鮮明になってきた。僕はそう思っています。
(引用終了)

【3-2】似たような話として、下記の記事もあった。

会津大学で「これからのエンジニア像」についてお話してきました - インフラエンジニアway - Powered by HEARTBEATS

(引用開始)
これからのエンジニア像

この先とか言ってるけど、未来人じゃないから先に事はわからないよ
・なので歴史を踏まえて推測するね

ここ20年を振り返ると、ITは10年でスキルの価値がなくなる業界です
・最先端の貴重なスキル =(10年)=> ふつうのスキル =(10年)=> こどもでもできる

世間的なエンジニアの評価軸が技術領域ベースから価値ベースにシフトしてきたよ
・ネットワークエンジニア => Webサービスエンジニア...

みなさんはきっと75歳くらいまでは働く必要があります
・たぶん私もね

ホワイトカラーは一生勉強し続ける必要があります
・宿命ってやつですね

いまのうちにじっくり基礎から勉強の仕方・活かし方を身に着けておくとよいですよ
・基礎知識と、学びの習慣化をしておこう

とにかくまず学校の勉強をきちんと真面目にやるのが最高
(引用終了)

IT業界にいて、つくづく思うのは、身につけた技術は10年経つと陳腐化してしまい、無意味になってしまう可能性が高い事実だろう。
実際、Cobolやメインフレームでバリバリ、プログラミングして経験を積んで、部課長に成り上がった人達を見ると、彼らの話が既に時代に合わなくなっていることをいつも感じる。
そして、彼らの経験やノウハウが陳腐化されるのと同様に、自分もそうならないか、といつも自問している。

アジャイル開発は常識だ: プログラマの思索

ライフ・シフト」のように、人生100年時代の中で、現代を生きる人は皆、死ぬ直前まで働くことを前提に、一生勉強し続けることを準備しなくてはならないのだろう。

たとえば、昨今は、いわゆる文系の士業は人工知能で代替されるニュースが相次いでいるので、士業の受験者数がかなり減少していて、危機感を持つ人が増えている、という話も聞いた。
いわゆる士業のAI受難だ。
よって、士業だけでなく、普通のホワイトカラーも、価値を生み出さないエンジニアもAIで代替されてしまうリスクがあるのだろう。

AIによる代替可能性90%以上の士業は3つの士業 | 株式会社ネクストフェイズ

では、技術や知識を得たとしてもすぐに陳腐化してしまう時代において、どんな方針で働くべきなのか?

現状では、社内研修やOJTだけでは、エンジニアのキャリア形成は不十分だ。
むしろ、エンジニア自身が積極的に、オープンソース活動に加わった方がいい。

現代では、オープンソースコミュティが技術革新の発信源であるからだ。
だからこそ、オープンソース活動に加われば、自身より優れた開発者と交流することで、やる気も出るし、自身の能力向上にも役立つ。

自分にも銘じておく。

| | コメント (0)

より以前の記事一覧