DevOpsとは開発チーム自身が運用できるようにすること
いまさらですが、DevOpsとは何か、具体的には何に取り組むべきなのかについて整理しました。DevOpsとは、サービスの継続的な改善を実現するために、Dev自身がサービスの運用ができるよう、Opsは運用作業のツール化を進めていく取り組みです。そして、DevOpsエンジニアやSREなど、新たな役割への転換が求められます。
DevOps = 開発と運用の協業？
Velocity 2009というイベントで、写真共有サイトFlickrのエンジニアJohn Allspaw氏とPaul Hammon氏が「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」（ ビデオ / スライド ）という講演を行います。この講演ではWebサービスの運用における開発チームと運用チームの協業が語られています。両者が同じ目線に立つためにツールを活用するとともに、カルチャーも変えていこうというような呼びかけでした。
システム開発で曖昧な要望を形にしていく方法
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。
社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。
なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。
- クライアントは直接契約（プライム）
- 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある
- 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる
相手の話を整理するフレーム
まず、相手から得られる情報を4つの階層にわけて整理する必要があります。
- 目的：達成すべきこと
- 戦略：目的を確実・効率的に達成するためのシナリオ
- 戦術：戦略を実行するための具体的な手段や操作
- 兵站：戦術を実行するためのリソース（人やシステムや物やデータ）
多くの場合、クライアントは「目的」と「戦術」しか話してくれません。「〇〇を達成したいから、□□というシステムを作ってくれ」というわけです。ところが、これだけだとシステム設計がなかなか進みません。それには2つの理由があります。
フェアユースは認められたが、Googleは対価を支払うべき - Java API訴訟に寄せて
ようやく裁判の結果が出ました。結果としてフェアユースが認められたのはよかったのですが、Googleが勝訴したということは素直に喜べないので、その理由を書いておきます。
関連ニュースは、こういったところから。
約1兆円の賠償金を巡るGoogleとOracleの10年にわたる訴訟が決着、「APIのコピー」は結局違法なのか？ - GIGAZINE
Google、オラクルの著作権侵害せず 米最高裁判決: 日本経済新聞
グーグル、米最高裁でオラクルに勝訴--「Android」Javaコード訴訟で - CNET Japan
JJUG CCC Fall 2020をオンラインで開催しました
ちょっと時間が経ってしまいましたが、2020/11/7にJJUG CCC 2020 Fallをオンラインで開催しました。オンラインでのイベント開催は、まだ世の中にもノウハウがないと思うので公開報告です。
JJUG CCC 2020 Fall 会場タイムラプス
やるべきことをやる、壁を越える #devsumi 2020
久しぶりのデブサミで、世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた という講演をしました。
ともにつくる
2019/10から三越伊勢丹グループの（株）アイムデジタルラボで取締役（Graatとは兼務）として仕事をしています。会社設立＆取締役就任のきっかけであったプロダクト（YourFIT 365）が落ち着いてきたので、その成果の発表場所を探していました。
2040年問題とITエンジニア - DevLOVE Xに寄せて
エモいことで有名なDevLOVEの10周年記念イベントDevLOVE X 〜 それぞれの10年、これからの10年 〜で「エンタープライズ、アーキテクチャ、アジャイルのこれから」という講演をしてきました。資料は以下。
Togetter - #DevLOVEX 鈴木 雄介「エンタープライズ、アーキテクチャ、アジャイルのこれから」 #DevLOVEXC Day2-7C
10年間の振り返り
10年間の振り返りとして10年前に書いた記事や講演資料をみたのですが、わりと一貫していて安心しました。たとえばクラウドを超えた先の企業システム像 20091008 JJUG CCC では、
って、まさにマイクロサービスのことだし。日経SYSTEMS 2009年2月号の特集１「10年後も通用するスキル」では、（都合良く考えると）DevOps、アジャイル開発、マルチクラウドのようなことを示唆しています（手元の最終提出原稿なので、掲載原稿ではありません）。
クラウド・プラットフォームは，サーバーリソース，サービス管理機能，それらのスケーラビリティや安定性など，サービス提供に必要な機能や機構を提供するものだ。ITエンジニアはクラウド・プラットフォーム上で開発を行うことで、簡単にサービスを提供できるようになる。
＜中略＞
10年後のITエンジニアは，このクラウド・プラットフォームを利用したり，他人が開発したサービスを組み合わたりして，ユーザーの求めるサービスを作っていくようになると筆者は考える。
ではそのとき，ITエンジニアに必要なスキルはどう変わるのか。筆者は，ITエンジニアにとって重要な「問題発見」「課題解決」の二つのスキルが大きく変わってくると予測する（図2）。
例えば問題発見スキル。現在のシステム開発では，高品質・高性能を追求するのが一般的だ。しかし，インターネット上の複数のモジュールを組み合わせるサービス開発では，そもそも品質や性能を一定に保つことが難しい。ユーザーの抱える問題を的確に発見し，ユーザーの求める品質や性能のレベルがどのあたりにあるのか，確かめることが重要になる。
作るべきものを決めて手順通りに作業を進めるという課題解決スキルも変わってくる。短いサイクルでサービスを提供しているとユーザーから頻繁にフィードバックがある。よいサービスを提供するためには、常に改善をしていかなくてはいけない。こういった場合に発生する多数の課題について優先度を付けながら解決をしていかなくてはいけない。
2040年問題
さて、未来のことを考えるのに、わりと確定した未来として2040年問題を取り上げました。2040年は団塊ジュニア世代が高齢者（65歳）になる年で、高齢者数が最も多くなると予測されています。総人口は減少傾向なので、社会保障の維持、労働力の減少、地方の低密度化など、様々な社会問題が指摘されています。僕は1975年生まれなので、まさに2040年には65歳になるという世代です（参考：pdf 今後の社会保障改革についてー2040年を見据えてー）。
この解決にむけた提言に多く含まれるのがIT活用です。社会保障は原資が生産年齢人口で確定されるため、配分の最適化がポイントです。このためには正確なデータ収集が重要です。たとえばオンライン資格確認という取組みはマイナンバーカードを健康保険証代わり（2021年度5月開始予定）にするものですが、これによって薬剤情報、医療費情報、特定健診データを正確に収集できるようになります（参考：PDF オンライン資格確認等システムの検討状況）。
また、そもそも健康維持が一番よいわけで、病気の兆候を早期発見するためにAI導入やセンサー導入といったことも必要です。さらに介護業務や保育業務の効率化といったことも含まれます（参考：PDF 社会保障ワーキング・グループの会議資料 参考 医療・福祉サービス改革）
ITエンジニアのすべきこと
こうした取組みの阻害になると思うのは、いま社会を支えている企業におけるIT活用センスのなさです。残念ながらITを個別の道具としてしかとらえておらず、社会全体の良い方向にむけるITサービスを実現する、といった視点に欠けます。
2040年というと20年後です。20年後に問題が解決されているには、どう遅くても10年ぐらいで、この視点を持ってもらわないといけない。われわれITエンジニアこそ、こうしたセンスを磨き、古臭い企業の論理に屈することなく、現場でより良いサービスの実現に寄与すべきです。
幸い、多くの企業では問題に気づきつつありますし、現場にいる非IT人材も優秀です。デジタルトランスフォーメション（DX）というのが、それを象徴する言葉です。これをバズワードにしないようにしないといけません。
最近、僕が提言しているようなのは以下のようなことです。
小さいことを積み重ねる
エモい名言で有名なイチローが2004年にNBA年間最多安打を更新した時の言葉です。
いま、小さなことを多く積み重ねることが、とんでもないところへ行くただひとつの道なんだなというふうに感じています
2040年問題が解決した未来は「とんでないないところ」でしょう。そこに至るのは簡単ではありません。では、何をすべきかといえば「いま、小さなことを多く積み重ねる」しないのです。個別の現場で、より良いと思えることを1つでも積み重ねる。そういう積み重ねでしか世の中は変わらないと思います。
さあ、個別の現場で頑張りましょう！そして、色々な形で交流していきましょう。ぜひ、気軽に声をかけてください。