David Bernstein さんの 認定スクラムデベロッパをやります

DevOpsDays Tokyo で来日して基調講演してくれる David Bernstein さんのご希望で、東京で認定スクラムデベロッパを行います(アギレルゴコンサルティング主催、通訳付き)。5日間の研修ですので、値段もそれなりに高額になりますが、スクラムからTDDまで一貫して学べるので、これからアジャイルチームを組んで始めよう、という組織の方におすすめなのではないでしょうか。講師はとにかくいい人です!

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

 

あんまわかっている人がいなくて1ヶ月を無駄に過ごすよりはだいぶ安そう(言い過ぎ)。チームに一人だけだと孤立しちゃうので二人だと堅いんですけどね。言っていただければ私の方でもサポートいたしますので、ご検討いただければ幸いです。

日程はDevOpsDays の翌週の4/15(月)-19(金)、東京都心部の予定です。

以下はコース概要と日本語訳です。おかしなところあったらご指摘いただければ幸いです。アギレルゴのWebサイトに近く掲載されると思います。

tobeagile.com

 

Certified Scrum Developer Essentials
認定スクラムデベロッパー(CSD)について

This immersive, forty-hour CSD training program contains a set of three comprehensive courses that provides the knowledge and skill to become a successful Scrum developer and a valuable member of a Scrum development team. 

40時間の集中的なCSDトレーニングプログラムには、スクラムをうまく活用できる開発者になるための、そして開発チームの価値あるメンバーになるための、知識およびスキルを提供する3つのコースの内容を含んでいます。

In our first training course, Scrum Framework Developer Essentials, we’ll explore the Scrum Framework and how it supports faster and simpler software development. In Design Pattern Developer Essentials, we’ll discover a core set of design patterns that every developer should know. The program concludes with the popular Scrum Software Developer Essentials course, in which you’ll learn how to write higher quality code more quickly and with fewer defects using practices from Extreme Programming (XP) that include test-first development, refactoring, and emergent design, as well as a variety of Agile problem-solving techniques.

一つ目の「スクラムフレームワーク開発者エッセンシャル」では、スクラムフレームワークがどのようにしてより迅速で、よりシンプルなソフトウェア開発を実現するのかを学びます。「デザインパターン開発者エッセンシャル」では、すべての開発者が知っておくべきデザインパターンのコアセットを学べます。そして最後は人気の高い「スクラムソフトウェア開発者エッセンシャル」コースです。テストファースト開発、リファクタリング、および創発的設計を含むエクストリームプログラミング(XP)のプラクティスを使用して、より高品質で欠陥の少ないコードを迅速に書く方法を学びます。また、さまざまなアジャイル問題解決手法も学びます。

You’ll be taken on a guided tour through essential developer practices, such as story writing, sprint planning, pair programming, and test driven development. We’ll learn how to discover patterns in problems and to implement designs as needed. You’ll also explore the principles behind the practices so you understand how to use them to make the best design choices, and you’ll gain a powerful framework for encapsulating and abstracting virtually any problem for maximum flexibility, without over complicating the solution.

ストーリーライティング、スプリントプランニング、ペアプログラミングテスト駆動開発など、開発者にとって欠かせないプラクティスをガイド付きツアーで紹介します。問題に隠されたパターンを発見し、必要に応じて設計する手法を学びます。また、プラクティスの背後にある原則を再確認し、最適なデザインを選択する方法を理解し、ソリューションを複雑にすることなく、あらゆる問題をカプセル化および抽象化して最大限の柔軟性を得る、強力なフレームワークを学びます。

By exploring the secrets of high-performing, cross-functional development teams you’ll gain a shared design vocabulary for dramatically improving inter-team communication that can be applied equally well to new development and to maintaining or extending existing systems. Then we’ll put theory into practice and apply your new skills by building the core of an application using the expert-level techniques you’ve learned for rapidly writing quality software.

高性能で機能横断的な開発チームの秘密を探りながら、チーム間のコミュニケーションを劇的に改善するための共通言語を学びます。これは新規開発にも、既存システムの維持または拡張にも、同じく適用できます。 次に、高品質のソフトウェアを迅速に作成するエキスパートレベルの技術を習得し、それを使ってアプリケーションのコアを構築することにより、理論を実践し、新しいスキルを適用します。

By the end of this Scrum Developer Certification class, you’ll be armed with several new, effective tools and techniques for Scrum development that will make your software more robust, manageable, and easier to extend.

この認定スクラムデベロッパー研修の間に、スクラム開発における効果的なツールとテクニックを身に付けることができます。


Who Should Take This Course
想定受講者について

This Certified Scrum Developer training course is for all team members, and has the greatest impact when the entire team attends. This set of Certified Scrum Developer courses will benefit Architects, DBAs, Designers, Developers, Development Managers, Directors, Product Managers, Programmers, QA Engineers, Software Engineers, Technical Analysts, Technical Leads, Technical Writers, and Testers. Familiarity with basic Object-Oriented (OO) concepts and terminology is recommended. Participants who successfully complete the programming exercises in the Scrum Software Developer Essentials training are eligible to become a Certified Scrum Developer, and require the ability to write simple programs in Java or C Sharp.

この認定スクラムデベロッパー研修は、あらゆるチームメンバーを対象としており、チーム全体が参加する場合に最大の効果を発揮します。アーキテクト、DBA、デザイナー、開発者、開発マネージャー、ディレクター、プロダクトマネージャー、プログラマー、QAエンジニア、ソフトウェアエンジニア、テクニカルアナリスト、テクニカルリーダー、テクニカルライター、テスターにとって役立ちます。基本的なオブジェクト指向(OO)の概念と用語に精通していることをお勧めします。スクラムソフトウェア開発者エッセンシャルトレーニングのプログラミング演習を修了した参加者には、認定スクラムデベロッパーになる資格が与えられます。JavaまたはC#で簡単なプログラムを書く能力を必要とします。


Course Benefits
この研修で得られるもの

Completing this Certified Scrum Developer Training Course will enable you

この認定スクラムデベロッパー研修を修了すると、こんなことができるようになります

Write stories and build features in sprints
Estimate development tasks more accurately
Master test-first development to drive design
Efficiently use TDD’s red-green-refactor cycle
Work effectively to refactor legacy code
Diagnose and fix pathologies of poor code
Exercise techniques to test untestable code
Collaborate successfully with pair programming
Employ acceptance tests to specify and document stories
Avoid upfront overdesign and practice just-in-time development
Distinguish between twelve design patterns by what they encapsulate
Define a strategy for continuously integrating software as it is built
Write software that supports an iterative process without excessive rework
Support collaborative code ownership and embrace a common aesthetic
Refactor to patterns and emerge designs in iterative development
Share a common vocabulary for evaluating and communicating designs
Implement techniques for recognizing and managing technical debt
Quantify software qualities that make code easier to maintain and extend
Recognize how test driven development informs design decisions
Appreciate the value of adopting shared coding standards
And much more…

  • スプリントでストーリーを記述し、機能を開発する
  • 開発タスクをより正確に見積もる
  • テストファースト開発をマスターし、設計を駆動する
  • TDDの Red-Green-Refactoring のサイクルを効果的に使用する
  • レガシーコードと付き合い、効果的にリファクタリングする
  • 貧弱なコードの病状を診断して修正する
  • テスト不能なコードをテストするテクニックを使う
  • 協調的なペアプログラミングを上手に行う
  • 受入テストを使って、ストーリーを定義し、ドキュメント化する
  • 事前の過剰な設計を避け、ジャストインタイムな開発を行うプラクティス
  • カプセル化する内容によって12のデザインパターンを使いこなす
  • ソフトウェア開発の際に、ソフトウェアを継続的に統合するための戦略を定義する
  • 過度の手戻りを避けながら、反復プロセスを用いてソフトウェアを作成する
  • コードの共同所有を行い、共通の美的要素を取り入れる
  • 反復的な開発を通じて、リファクタリングからパターンへ導き、デザインを創発する
  • 設計を評価し伝達するための共通言語を共有する
  • 技術的負債を認識し管理する手法を実践する
  • コードの保守と拡張を容易にするソフトウェア品質を定量化する
  • テスト駆動開発がデザイン決定にどのように情報を提供するかを認識する
  • 共通のコーディング標準を採用することの価値を評価する

そして他にも...


Agenda
各セクションの内容

Scrum Framework Developer Essentials—Covers essential elements of Scrum for software developers: Scrum principles, values, and framework; artifacts, story writing, collaboration, estimation and planning, coaching and facilitation. Hands-on exercises include story writing, defining acceptance tests, estimation and sprint planning. See the full course description for Scrum Framework Developer Essentials.

スクラムフレームワーク開発者エッセンシャル - ソフトウェア開発者向けに、スクラムの重要な要素をカバーします。スクラムの原理、価値、そしてフレームワーク。生成物、ストーリーの書き方、コラボレーション、見積もりと計画、コーチングと円滑化。ハンズオン演習で、ストーリーの記述、受入テストの定義、見積もり、スプリント計画を行います。Scrum Framework Developer Essentialsの詳しいコース説明( http://tobeagile.com/issd/ 英語)を参照してください。

Design Pattern Developer Essentials—Covers Agile principles and patterns: approaches to design, key principles, problem-solving techniques, seeing patterns by what they encapsulate, discovering patterns in problems, design exercise, what patterns teach us, emergent design and refactoring to patterns. Includes an in-depth design exercise and debrief. See the full course description for Design Pattern Essentials for Developers.

デザインパターン開発者エッセンシャル - アジャイルの原則とパターンをカバーします。デザインへのアプローチ、重要な原則、問題解決のテクニック、カプセル化することによるパターンの発見、問題のパターンの発見、デザイン演習、私たちに教えるパターン、創発的なデザインとパターンへのリファクタリング。 詳細な設計演習と報告を含みます。 Design Pattern Essentials for Developersの詳しいコース説明( http://tobeagile.com/dpde/ 英語)を参照してください。

Scrum Software Developer Essentials—Covers essential practices from Scrum and XP: continuous integration, pair programming, coding standards, test-first development (TDD), red-green-refactor cycle, using TDD to inform design, code qualities, discovering design patterns, conducting code reviews, essential Scrum developer practices, writing testable code, advanced testing techniques, refactoring legacy code, and emerging solutions. Includes six hands-on programming exercises in Java or C Sharp. See the full course description for Scrum Software Developer Essentials.

スクラムソフトウェア開発者エッセンシャル - 継続的インテグレーションペアプログラミングコーディング標準テストファースト開発(TDD)、TDDを使用した設計、コード品質、デザインパターンの発見など、スクラムとXPの基本的なプラクティスをカバーします。コードレビュー、スクラム開発者にとっての重要なプラクティス、テスト可能なコードの作成、高度なテスト手法、レガシコードのリファクタリング、および新たなソリューションの提供。 JavaまたはC#での6つの実践的なプログラミング演習が含まれています。Scrum Software Developer Essentials コースの説明( http://tobeagile.com/ssde/ 英語)を参照してください。


Your Instructor, David Bernstein
インストラクター: デヴィッド・バーンスタイン

My continuing passion for software design and construction has led me to train more than 8,000 developers in the last twenty-six years for clients that have included Fortune 500 firms such as Microsoft, IBM, Yahoo!, Boeing, AT&T, Sprint, Medtronic, SunGard, State Farm, MetLife and Weyerhaeuser. As a longtime IBM consultant, I trained software engineers around the globe, giving them the skills to write the next generation of applications and operating system software while earning one of the highest satisfaction ratings in the history of IBM education. Since 2006, I’ve devoted my consulting practice to providing organizations with training and coaching for software developers and teams transitioning to Agile and Scrum.

私のソフトウェア設計と構築への情熱は、過去26年間で、MicrosoftIBM、Yahoo!、Boeing、AT&T、Sprint、Medtronic、SunGard、State Farm、MetLife、Weyerhaeuserなどの顧客を含む8000人以上の開発者を養成することにつながりました。IBMコンサルタントとして長年、世界中のソフトウェアエンジニアを訓練し、IBMの教育史上、最高の満足度の評価を得ながら、次世代のアプリケーションやオペレーティングシステムソフトウェアを書くスキルを身に付けました。 2006年からはコンサルティングを手がけ、ソフトウェア開発者やアジャイルスクラムに移行するチームのためのトレーニングとコーチングを、さまざまな組織に提供することに注力してきました。

 

Certification
認定について

The three CSD training courses of this forty-hour training program (which together comprise Our Certified Scrum Developer Essentials Training Week) satisfy all the training requirements for becoming a Certified Scrum Developer (CSD) through the Scrum Alliance. These courses count for forty Professional Development Units (PDUs). See http://ToBeAgile.com/faq for more details.

この40時間のトレーニングプログラムの3つのCSDトレーニングコース(これらのコースは、ともに認定スクラム開発者エッセンシャルトレーニングウィークを構成します)は、スクラムアライアンスを通じて認定スクラム開発者(CSD)になるためのトレーニング要件をすべて満たします。 これらのコースは40のProfessional Development Units(PDU)を対象としています。 詳細は http://ToBeAgile.com/faq をご覧ください。

 

 

横浜で電動スクーター(電動キックボード)を体験してきた!

8月にサンディエゴに行った時に感動した電動スクーターシェアですが、日本でもAnyPayが福岡市で実験を始めるというニュースが流れてきました。

kawaguti.hateblo.jp

prtimes.jp

...という昨今なのですが、東京近郊でもはじめたいという熱い想いで「いまできること」からはじめている、Kimさんのスクーターシェアの情報をいただきまして、さっそくですが、試乗させてもらってきました。

f:id:wayaguchi:20190113130529j:plain

ナンバー取得済みの電動スクーター!公道を走れます(要原付免許、ヘルメット)

光栄なことに私たちが最初のユーザーだということです。わーい。 
機材はシンガポールの企業が作っているものに、ミラーやウインカーなどを追加で装備して、ナンバーを取得しているとのこと。

f:id:wayaguchi:20190113141153j:plain

説明を受けて、ヘルメットをつけて、公道へ!


Scoot20190113

電動スクーターは、スクーターみたいに場所取らないので、都市部の足に最適なんです。荷物は載せられないので、観光とか、通勤とか、ちょっとした足に最適です。自転車より全然楽しいし、個人的な感覚では歩道を走ってくる自転車よりも恐怖感がないです。


電動キックボードでみなとみらい走ってみた 

もう自動運転までは次のイノベーションはないんじゃないかとおもっていたモビリティ業界に、彗星の如く現れた電動スクーター。アメリカではすでにBirdとLimeがユニコーン企業になっています。日本でも乗れる日が来るといいなぁと思います。

www3.nhk.or.jp


毎週末に横浜で試乗会をやって、少しずつ認知を広げていきたいとのこと。

ぜひ体験してください。正式サイトオープンだそうです。

https://form.run/@hop-on


P.S. もう100kmも走ってるのか!

#7 都内で電動キックボード100km走って見てきた景色|chocopie116|note

 

 

 

RSGT2019 も Day3(金曜日) はオープンスペーステクノロジーとクロージングキーノートです

Regional Scrum Gathering Tokyo 2019 は今週水曜日から開催です。チケット、スポンサー枠ともに完売しております。皆様のお越しをお待ちしております。

confengine.com


Day3は、昨年から復活しました、オープンスペーステクノロジーを行います。
概要は昨年と同じです。

kawaguti.hateblo.jp

OSTは事前にアジェンダを決めないセッションです。その場にいる人が議論したい内容を提案し、自分でセッション枠を割り当て、自己組織化でセッション表を作っていきます。OSTスクラム "ギャザリング(集まる)" の象徴ともいえるセッションの1つで、海外で行われる Global Scrum Gathering では定番となっており、近年ではさらにCSPやCSTだけが集まる前日イベントでも同様の形式が取り入れられています。実践者自らが未来を考え、同じ課題を持つ人同士が繋がりあう、この"ギャザリング"とクロージングキーノートをもって会期を締めくくります。

f:id:wayaguchi:20190107153102j:plain f:id:wayaguchi:20190107152958j:plain

f:id:wayaguchi:20190107152935j:plain f:id:wayaguchi:20190107152901j:plain


クロージングキーノート

クロージングキーノートは、ヤッホーブルーイングの井手社長です。「13年連続増収増益・国内クラフトビールNo.1」のチーム作りについてお話しいただきます。もちろんクラフトビールで乾杯しましょう!

confengine.com


今年も皆さんによってよい場所になればと願っております。
では、会場で!

経営者がITを学ぶインパクトは、プログラマが経営を学ぶより大きいかもしれない

前回のエントリもずいぶん多くの方に読んでいただいたようで、大変驚いております。

kawaguti.hateblo.jp

さらに、いただいたフィードバックから、もう一点補足した方がよいかなと思いまして、このエントリを書き始めました。補足の補足ですみません。

 

リーダーがITを学ぶのが早いか、IT技術者が経営を学ぶのが早いか

前回、IT技術者ではないキャリアを歩んでいる方々がプログラミングを学んだ事例としてジャパンタクシーの川鍋社長のエピソードと、若手向けプログラミング研修の例を出しました。

ビジネスマンがプログラミングを学ぶ価値 

アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、1週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動かない。」「怖い。」ということだそうです。そのあとエンジニアに、そこで学んだようなプログラミングの延長で自社のアプリはうごいているのかを聞いたところ「そうだ」という答えが返ってきて、そのあと何もいえなくなったとのこと。

togetter.com
同じように、私にもビジネス系の若手にプログラミングを教える機会があったのですが、そこで最初に上がった声が「エラーヘル」でした。動かない。プログラミングをした人は誰でも知っていることですが、プログラムっていうのは正しく書こうとしても動かないわけです。これを肌身で理解しているかどうかは、「話が通じるかどうか」の大きなポイントかなと感じました。 

confengine.com

これらの例に対して(だと思いますが)、IT技術者が経営を学ぶ方が早い、というご指摘をいただきました。この点はまったく同意です。

個人のキャリアパスでいうと、経営や管理手法を先に学ぶより、まず基盤となるコンピュータサイエンスや数学や統計を学んでおく方がスムーズかなと思います。すでにIT技術者としてキャリアを積まれている方が、経営について学ぶほうが、ビジネスマンにITを教えるより早い感じがします。

なのに、なぜ逆手順ともいえる例を紹介したのかといいますと、組織の観点で考えた時に、経営側・マネジメント側の主流がITに明るくない人だった時に、どうやってIT側の人を必要な職につけるのか?という大きな課題があると感じたからです。

誰がITに明るい人間をマネジメントに引き上げるのか?

前のエントリでも Microsoftの例を出しましたが、以前のスティーブ・バルマーCEOはマーケティングやセールスの側の方と聞いています*1。そのバルマー前CEOの下で、自社WebサービスBingやAzureを立ち上げてきたのが現在のサティア・ナデラCEOということです。有能な雇われCEOがポッと組織に入っていきなり社長になったわけではなく、実ビジネスをやりながら昇進のステップを踏んで、CEOになったというわけです。

多くの大企業で、同様に社内評価をえながら、同社を任せるに足る実績とビジョンを持った人材を育て、いずれ組織長に据える、ということを理想としていると思います。その人物が何者なのかを事前に見極めるステップがあります。次に優れたリーダーが選ばれるためには、その前に選球眼を持ったリーダーが必要になります。

任天堂の故岩田聡さんを社長にしたのは、創業2代目で花札の会社からテレビゲームの会社に導いた山内溥さんです。ファミコン初期から実際にゲームをプログラミングしてきた本当のハッカーの社長登用(その前のHAL研究所の支援の経緯も含め)は大きな決断であったろうと思います。

matome.naver.jp

www.mag2.com

ナデラ氏や岩田さんを社長に据えたバルマー氏や山内さんの選球眼が鋭かったことに反論の余地はないと思います。そして彼らは、もともとコンピュータ技術者であったわけではありませんエンジニア出身のリーダーを、彼らが引き上げていなければ、エンジニア出身者が社長になることは、なかったわけです。

最近の日本の事例だと、DMM.comの亀山さんがピクシブ創業者の片桐さんを社長に登用したのも記憶に新しいところです。

logmi.jp

f:id:wayaguchi:20190105034307p:plain

翻訳者がいいリーダーになるとは限らない

ところで業界には「ITに明るくない人に上手に説明する、そこそこITがわかっている人」というのが大勢いらっしゃいます。プロジェクトマネージャーとか副部門長とかをされてたりするかもしれません。コンサルタントさんかもしれません。パワポが上手で、細かいところをさっと端折って、AかBか選べば経営判断下せる感じにしてくれる人たち。ITがわからない経営陣にとっては手放せない存在であることでしょう。

一見、優秀そうな方々なのですが、経営やマネジメントを任せた途端にボロを出してしまう方もいるようです。たとえばこんなような理由が思い浮かびます(実例ではないです)。

  • 上を見て仕事をしていて部下に人望がない
  • 資料はまとめられるが本質の理解がない
  • 他人を信用出来ず、任せるのが不得意
  • リーダーシップ経験がない
  • たんに権力が好きすぎる

自分の言うことを聞いてくれた人をリーダーに据えるパターンは、なかなかうまくいかないというのは想像しやすいところかなと思います。

全部当たるわけではないけど、数を増やせば当たりも増える

選球眼がだいじという話でした。選球眼を養っていただくためにも、ビジネスマンがITを実体験することで、共通言語を持つことはとても大事だと思います。もちろん、現役の経営者やリーダーが少しでもITに明るくなることは、組織にとっても即効性が高いのではないかと思います。話が通じるだけでずいぶん働きやすくなるわけです。

そして、数の問題があります。IT技術者の数を増やすことも重要でしょうが、ビジネスマンの数はもっと多いので、ビジネスマン自身が積極的にITを学んでいけば、何倍も早いスピードで業界が変わっていくのではないでしょうか。その学習への投資が、将来的に無駄になるとも思えないので、個人としても組織としても積極的に投資して良いのではないかと思っています。あ、翻訳者を増やすためのパワポやレポーティングばかり学ばせてもダメかもしれませんけれど。その点は人事/教育研修担当さんの選球眼も必要になりますね。

モブプログラミング体験会で得られた反応

ところで、ビジネスマンの方々で、プログラミングの現場を直接見たことがある人ってどのくらいいるものなのでしょう?ポストイットを壁に貼っているアジャイルの現場を見た、ということではなく、コードを書いている現場や、コードそのものを見た経験のことです。どうでしょう?

2017年から自分たちでも取り組み、様々な形で紹介してきた、モブプログラミングという仕事の進め方があります。これは一箇所に開発者も企画者も集まって、一緒に作業を進めていく、という考え方です。会議の時だけ集まって資料を見ながら議論をするのではなく、常にそこにいて、仕事の状況を把握し、いつでも質問や議論を進められる状態を保ちながら、コードも書いていきます。


A day of Mob Programming

この手法を編み出したのが 米Hunter Industries。スプリンクラーの大手企業です。CEOがWoody Zuill氏にIT部門の再生を託し、あるチームが成功を納め、そのやり方を全体に広めたものだそうです。

私が所属していた楽天の部門でもこれを取り入れました。そして、さらに多くの人に広め、仲間を集めるべく、見学会を多数おこなってきました。(この点もHunterから学んだことです。)

ある見学会の時に、プログラマー出身じゃない方からこう言われたことがあります。

エンジニアの人って、一日中パソコンに向かって打ち込んでいるのだと思ってました。 

その方ももちろん、キーボードを握ってコードを書いていただいたのですが、それだけでなく、観察によって、プログラマーがどのように仕事を進めているのかを発見されたようです。逆にいうと、こんな基本的なことも私たちは共有できていないのか!と気づかされました。まさに現地現物です。現場に行って、見てみるだけで、こんなことも発見できるのですね。

ビジネスマンがITを学ぶのは大変かもしれませんが、モブプログラミングをやってみることは、それほどハードルは高くないと思います。それだけでも、多くのことが学べるのだとわかりました。

モブプログラミングについては、昨年のDevelopers's Summitで実演を行い、ベストスピーカー第2位に輝きました。

speakerdeck.com

 

本場HunterのDirectorが来日するので、モブプログラミング体験会をやります

また、これは宣伝になってしまいますが、Hunterの現役DirectorのChris Lucian の来日に合わせてモブプログラミング体験会を行います。Chrisは上のビデオで「Driver」の吹き出しのところにいる人です。

ご興味のある方はぜひ実際にどうやっているのかを覗きにきてみてください。ほんとうは現地に見にいくのが一番学びが多いと思いますが、全員がそうすわけにもいかないと思いますので、電車で行ける体験の機会を生かしていただければと思います。

www.eventbrite.com

 

さいごに、新しいことを理解するには

多くの企業で、ITが急速に経営課題になってきたのが、この20年くらいの変化だと思います。さまざまな業種の方が、ITをさまざまなレベルで理解する必要が出てきました。なぜなら、それが仕事の重要な一部になったからです。

何か新しいことを理解するために必要なことは、まず第一歩、学び始めることです。人間は、今持っている知識を元に、新しいことを学ぶので、下手でも苦手でも、まずは第一歩を学んでみることが、大事なのかなと思います。

「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(三宅芳雄, 三宅なほみ 『教育心理学概論』 第一章 P.13-14) 

kawaguti.hateblo.jp

 

また長くなってしまいました。みなさまの参考になれば幸いです。

*1:ただ、日本にきた時に「Developer! Developer! Developer!」と連呼するなど、開発者の重要性は同社の根幹をなす、という感覚は持たれていたようです。

業務知識とIT知識を分けて考える時代は終わったんじゃないか

昨日のエントリは思いがけずアクセスをいただきまして、はてブホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。

kawaguti.hateblo.jp


この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。

SIerで業務知識といえばお客さんの業務に関する知識

システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か?みたいなエントリが盛り上がってました。

d.hatena.ne.jp

業務知識は業務実現に必要な知識すべて ... だと思う

私はSIerにいたことがないので、そのあたりどうも疎いのですが、私としては「業務知識といえば、業務実現に必要な知識すべて」のことで、それは担当する業務によって変わってくる、ということではないかな、と思っております。そういう筋で前回のエントリを書きました。

もちろん、SIerの業務であるところの「ユーザー企業から発注をもらってシステム開発をする業務」においては、業務知識といえばお客様が実現したい業務に関する知識ということになろうかなと思います。ドメイン知識とも言ったりしますね。

で、そう考えると、マネジメント層にとっての業務知識は、部下や組織をマネジメントするために必要な知識、という感じではないかなと思います。前回のエントリで参照した米Microsoftの河野さんの話でも、マネージャーにとっての主たる業務はそこにあるようです。

logmi.jp

IT知識と業務知識って分けられなくなってきた

私の業務知識に関する認識は上記のようなものなのですが、その前提で、さらにIT知識というものをどう捉えるか、というところに前回エントリの主題がありました。伝わるように書けてなかったみたいですけれど(ごめんなさい)。

全ての業務にITが入り込んできているので、もはやIT業務を明確に分解することが難しく、業務知識の範疇にITの基本的な理解が入り込んできている、ということです。

マーク・アンドリーセンが書いたように「ソフトウェアが世界を飲み込む」の時代なので、あらゆる業務がITを一緒に考えないと回らないようになってきている、もしくは、ITをうまく使わないと競争に勝てない/儲からないというところに来ている、ということかなと考えております。(池田信夫 blog : ソフトウェアが世界を食う に一部日本語訳がありましたのでそちらもご参照ください。)

a16z.com

っていうことで、「業務知識の一部となったITがわからない経営層やマネジメント層のままで大丈夫か?」というのがエントリでの核となる問いでした。

経営陣がIT知識を持っていて瞬時に判断ができるグローバル企業との競争 

経営やマネジメントにIT知識が必須だなんて言っても、急に関係者のみなさんがITに詳しくなるわけでもないので非現実的と思うかもしれません。GAFAじゃないんだし。私もそう思ってました。Microsoftに遊びに行くまでは。

少なくとも米国で時価総額一位に返り咲いた米Micriosoftでは、エンジニアの上司はCEOまで遡ってもエンジニアないしエンジニアの言葉がさっと通じる人になったみたいです。現在のサティア・ナデラ氏がCEOになったのは2014年だそうです。30年企業ですので、それなりに分厚いマーケティング企業になっていたところを、グッと技術側に引き戻したのがここ数年の躍進につながっているのではないかとおもいます。

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

 

日本でも2013年に創業したメルカリや、AIで躍進するPreferred Networks(2014創業)などは、同じように経営陣までその言語で通じる人たち、な感じがします。もはや業務知識とIT知識を分けるというマインドはかけらも持ってないんじゃないかと思います。

ビジネスマンがプログラミングを学ぶ価値 

アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、1週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動かない。」「怖い。」ということだそうです。そのあとエンジニアに、そこで学んだようなプログラミングの延長で自社のアプリはうごいているのかを聞いたところ「そうだ」という答えが返ってきて、そのあと何もいえなくなったとのこと。

togetter.com
同じように、私にもビジネス系の若手にプログラミングを教える機会があったのですが、そこで最初に上がった声が「エラーヘル」でした。動かない。プログラミングをした人は誰でも知っていることですが、プログラムっていうのは正しく書こうとしても動かないわけです。これを肌身で理解しているかどうかは、「話が通じるかどうか」の大きなポイントかなと感じました。 

confengine.com

そんなような話をユアマイスターの高山さんにお話ししたような気がするのですが、そのあとブログにこんなことを書いてくれました。ビジネス側でキャリアを積んできた方からみても、腑に落ちる点があったようです。

takayamamusashi.hatenablog.com

結局、話が通じる組織が強そう

業務知識とIT知識の話から、長い話をしてきましたが、IT知識、開発、営業、文系、理系 ... クロスボーダーで理解し話し合わないと解けない問題が主戦場になってきた、というのが背景にあるかなと思います。ひとことで言えば、業務に関して話が通じる組織が強いということかなと。あれ、これは別に新しいことでもなさそうです。

自動車会社でいえば、現地現物や三現主義。クルマやユーザーの話が通じることを大事にしているわけです。米Microsoftであればソフトウェアやそれを開発する人々について、すぐ判断ができるくらいは知っていないと、マネジメントは開発者をサポートすることができません。簡単なことではないと思いますが、それを維持している企業が時価総額の上の方にいる感じがします。

業務知識とIT知識で分けて考えるのは、そんなに普遍的な話でもなさそうだし、あったとしてもそんな時代はとっくに終わっているのかもしれません。

金融機関とかはそうじゃない説

蛇足ではありますが、金融とかはそうじゃない...とおっしゃる方がいるかもしれませんが、AIでトレーダーが激減してみたり、当の金融機関の方はそんな悠長なことは考えてないと思います。
gigazine.net

えっと、業務知識ってなんの話でしたっけ。

SI業界が開発するシステムの目的は何か? それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。

https://aike.hatenablog.com/entries/2008/06/15

ああそうでした。それは多いでしょうね。でも必要な知識だと思います。持たなくても食っていけるっていうのは、SIerの非常に限られた世界の常識に過ぎず、しかも、そもそもそれすら間違いなのではないかと思いました。

業務とITはもうとっくに切り離せないのだとすると、「こっから先は学ばなくてもよい」と言っていた領域がいろいろ言い訳できなくなってきてしまうなぁ、と言う感じがします。すくなくとも、相手と話せるくらいの理解がある方が、仕事が進めやすそうです。小学生向けにプログラミングを教える時代です。教材はたくさんあります。

 

ということで、またも答えはないわけですが、今後のヒントになれば幸いでございます。

 

(追記) さらに補足を書きました

kawaguti.hateblo.jp

 

 

業務知識を持たないリーダーで大丈夫か?

2017年1月に米Microsoftに遊びにいって感じたことを、そのあといろんな人に伝えてきたのですけど、ブログには書いていなかった気がしますので、年頭にあたり書いておきます。

f:id:wayaguchi:20190102225644j:image

機動警察パトレイバー アーリーデイズ | Netflix (ネットフリックス)

ツアーの際に現地で講演してくれた方の1人が河野さんで、ありがたいことに翌年のRSGTで基調講演していただきました。(もう1人Chap AlexはDevIpsDaysでお呼びできました。)

米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part1 - ログミーTech

ここで痛感したのは、ビジネスに必要な業務知識を経営層・マネジメント層が持っていないと、もう儲からないんじゃないか?ということです。ソフトウェアに関する業務知識というと、コンピュータサイエンスだったり、もうちょっと基本的なレベルで、エンドユーザーに価値を感じてもらうことを、プログラミングを通じて実現するという行為を、自分ごととして認知可能かどうか?ということにあたるのではないかと思います。

 

「かわぐちくんの言うことは難しすぎる。私にわかるように説明してほしい。」

これまで社会に出てから、このような質問をいくつか受けてきた気がします。アジャイルの文脈だと「どうやって上司に説明したらいいでしょう?」という質問は必ず出てきます。いまやソフトウェアが関係しないビジネスはほとんどなくなったわけですし、なんらかのソフトウェア開発(Excelかもしれないし、自動生成のものも含め)とその生成物のマネジメントは必須の知識だと思うんです。わからないのが普通ではなく、危険なことなんじゃないかと思うんです。そして、多くの日本企業には機能不全のリーダーを見つけ出す仕組みとしての360度評価がありません(360度評価は多面的評価の仕組みではなさそう - kawaguti’s diary )。危険は危険のまま放置されて、スキルのある若手社員の絶望を生み出してしまっているかもしれません。あたりまえを疑うには、他人の言葉ではなく自分自身の目と耳で現場を見ることが必要で、理解するには業務知識が必要なのだろうと思います。部下や業者に求める業務知識を当事者の方々は持っているのでしょうか?学ぼうとしてきたのでしょうか。

 

エンジニアの環境がどうこう、給与・待遇がどうこうという話は、それはそれで大事なんですけど、お金や予算以前に、話が通じるか?が大事なんじゃないかと思います。「お前コード書いてんの?」という話でもたぶんないです。

これから景気後退局面に入るようです。そういえば、シリコンバレーで2001年のネットバブル崩壊後に伸びていた企業はGoogleVMwareだという話も聞きました。トップは創業者であり、ITサイドのネイティブで言葉を理解する人たちでした。テクノロジーを使ってもっと活人・活スペース(山田日登志さんの言葉)を進められる実行者に利があります。同じ価値をもっと効率的に生み出せるのです。

ちなみに、ソフトウェア業界経験は長いけど、指示出しとかマネジメントしかしてない人たちもいらっしゃって、こういう方々はわからない人にわかりやすく説明してくれるものの、効率化はしない傾向があります。そして、どんどん付加価値のない人を増やす傾向もあり、注意が必要です。組織ばかり作っても、製品はよくなりません。儲からんのです。あれっ?と思ったら、ちょっと考えてみてください。

 

皆様のご健勝をお祈りしております。

 

 

 

(追記 “業務知識”の使い方が違うというご指摘をいただきまして、補足的なエントリを書きました。)

業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary

 

2015年の Rakuten Tech Confの後の感想

Facebookから出てきたので貼っときます。特に深い意味はないです。あーそんなこと考えてたのかぁ。

年末最終日に2つ3つ請求書の処理をお願いして、TechConfのあらかたの作業が終わった(気がする)。請求書系は膨らむことを覚悟してたけど、きっちり仕事できる人達が動いてくれたおかげでほとんど自分でやることはなかった(多少のカバーだけ)。後回しにしたやり残しが2つあるけど順々に。様々な人々に明示的にも自働的にも動いていただいて、自分に全体が見えきっているかというと全然そうじゃないし、決して平坦ではなかったし、途中で誰かが気づいてカバーした課題は多量にあったし(見えてないところもきっと多量にあっただろう)、問題がなかったといえば全くもって嘘になるけど、昨年よりはいくつかうまくできたんじゃないかとも思う。そういうのは昨年やってない人には見えないだろうし、未経験の人にとって難しいのもとても認識した。こだわりたい(やるべきという義務感がある)ところにそこそここだわれるように、というように(個人的には)お任せしたいと思うのだけど、それじゃわからんという反応ももちろんいただいて、そりゃそうですよね私もわからん、という件は結構あったけど、結果的にはいい感じにしていただけたので、みなさんすごいな、と勝手に思う。初年度から、誰も燃え尽きないカンファレンスにしたいとだいたいいつも言っている気がするんだけど、そんなん聞いてないよという人もいるだろうし、実際にうまくいってないところもあったと思う。怒られたところもあった。ごめんなさい。そういう部分はたぶん来年やりたいって言ってくれないはずなので、対応が必然になる。ツーマンセル、スリーマンセルで動けるようになっていけばノウハウが引き継がれるのだろうけど、役割的に多重化できてなくて、人がばさっと抜けちゃう部分は難しい。ともあれ、会として(外から見る限りは)大きな事故も怪我もなく終えられたことに、1メンバーとして大変感謝しております。ありがとうございました。

「去年やったからって今年も当然できると思っちゃ困るよ」って2年目に言われた気がするけど、それは自分でも毎年思っている(すべての仕事に対して)。必要でないならやらないし、実際担当できるかもわからず、確定要因はない。病気するかもしれないし。