マクドナルドメソッドで、一個それなりのアイデア出すと、わりとみんながアイデア出しはじめるので、みんなやればいいのにって思います。
「マクドナルド理論」を使うとより優れたアイデアが出てきてプロジェクトが進行する - GIGAZINE
でも、実現性なさすぎるネタだとみんなネタに走っちゃうから難しくて。あきらめも伝染する感じですね。
あと、時間内に検証不可能なアイデアも難しいです。ささっと作って見せられるようなものでないと。作れないアイデアの後に待ってるのは他人のエゴを聞かされたあとの疲弊だけだったりして。
目の前に操作可能なオブジェクトがあって、あれがどう、これをどうする、って話ができるとよさそう。RSGTでやったパターンのワークショップはそんな感じに見えました。
アジャイルコーチとして社内でスクラムを始める人のサポートをちょくちょくやってきたのですが、一番多い質問の一つが「緊急の割り込み仕事が多くて予定が立たない」です。作業をどうやって安定させるかはスクラムの本線なのでチームで考えるとして、結構ストレスなのが、割り込みたい人への対処だったりします。
割り込みを持ってくる人は断られないようにむしろ緊急にしてから持ってくる傾向があります。列に割り込んで一歩でも前に出られたなら承認欲求が満たされるケースとか。私が責任者だから私の意見が通らないといけないと思っているとか。
透明性と心理的安全性を確保して、早めに相談する方が得な環境を作れるといいんじゃないかなぁって思います。スクラムだと、プロダクトバックログを透明に保って、誰でも見られるようにして、その上で何番目にその案件を位置付けるかを決める。
そういえば、Kanban手法を提唱したデヴィッドアンダーソンさんは東京の観光地で順番待ち札を渡しているのを見て閃いたのだとか。何人が待っているのかが分かると待ってる側に諦める選択肢があっていいですよね。もっといいのはなるべく待たせないようにすることだけど。
反対の作戦がいわゆる「窓口」というやつで、処理をブラックボックスにしておく代わりにゲートキーパーがきちんとご案内をする。
窓口モデルは一見よくできてるんだけど、ソーシャルハックに弱くて、この案件は最優先だからとか、偉い人の発言を使ったりして、権威を積みまして早く通ろうとする作戦に弱い感じがします。そういう人に媚を売ってうまい商売も出来そうな気がするけど、それは官僚制が賄賂でハックされる歴史に似ている感じもします。
まあそこまで行かなくても、最適かどうかがわかりにくいとか、窓口の人に情報が集まりすぎるとか、窓口が休むと業務が止まるとか弊害も多くて。
社内の実務者同士のやりとりなら、相手が不特定多数ではない点を利用して、手の内を隠すよりむしろさらけ出してしまって、信頼をやり取りするゲームに持ち込めると、だいぶ効率化しそうです。
「今こんなキューになってるんですけど、どの辺に入れますか」「あれ、もうちょっと早めに言ってただけるともうちょっと考慮できたかもですね。」「ゆるい段階でいいので軽く教えておいてもらえればキューに入れときますよ。」
見える化ってそういうことかな。
DevOpsDays Tokyo で来日して基調講演してくれる David Bernstein さんのご希望で、東京で認定スクラムデベロッパを行います(アギレルゴコンサルティング主催、通訳付き 認定スクラムデベロッパー研修 by David Bernstein)。5日間の研修ですので、値段もそれなりに高額になりますが、スクラムからTDDまで一貫して学べるので、これからアジャイルチームを組んで始めよう、という組織の方におすすめなのではないでしょうか。講師はとにかくいい人です！
Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software
あんまわかっている人がいなくて1ヶ月を無駄に過ごすよりはだいぶ安そう(言い過ぎ)。チームに一人だけだと孤立しちゃうので二人だと堅いんですけどね。言っていただければ私の方でもサポートいたしますので、ご検討いただければ幸いです。
日程はDevOpsDays の翌週の4/15(月)-19(金)、東京都心部の予定です。
以下はコース概要と日本語訳です。おかしなところあったらご指摘いただければ幸いです。アギレルゴのWebサイトに近く掲載されると思います。
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.
この認定スクラムデベロッパー研修の間に、スクラム開発における効果的なツールとテクニックを身に付けることができます。
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#で簡単なプログラムを書く能力を必要とします。
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…
そして他にも...
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/ 英語)を参照してください。
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年間で、Microsoft、IBM、Yahoo！、Boeing、AT＆T、Sprint、Medtronic、SunGard、State Farm、MetLife、Weyerhaeuserなどの顧客を含む8000人以上の開発者を養成することにつながりました。IBMのコンサルタントとして長年、世界中のソフトウェアエンジニアを訓練し、IBMの教育史上、最高の満足度の評価を得ながら、次世代のアプリケーションやオペレーティングシステムソフトウェアを書くスキルを身に付けました。 2006年からはコンサルティングを手がけ、ソフトウェア開発者やアジャイル／スクラムに移行するチームのためのトレーニングとコーチングを、さまざまな組織に提供することに注力してきました。
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が福岡市で実験を始めるというニュースが流れてきました。
...という昨今なのですが、東京近郊でもはじめたいという熱い想いで「いまできること」からはじめている、Kimさんのスクーターシェアの情報をいただきまして、さっそくですが、試乗させてもらってきました。
光栄なことに私たちが最初のユーザーだということです。わーい。
機材はシンガポールの企業が作っているものに、ミラーやウインカーなどを追加で装備して、ナンバーを取得しているとのこと。
電動スクーターは、スクーターみたいに場所取らないので、都市部の足に最適なんです。荷物は載せられないので、観光とか、通勤とか、ちょっとした足に最適です。自転車より全然楽しいし、個人的な感覚では歩道を走ってくる自転車よりも恐怖感がないです。
もう自動運転までは次のイノベーションはないんじゃないかとおもっていたモビリティ業界に、彗星の如く現れた電動スクーター。アメリカではすでにBirdとLimeがユニコーン企業になっています。日本でも乗れる日が来るといいなぁと思います。
毎週末に横浜で試乗会をやって、少しずつ認知を広げていきたいとのこと。
ぜひ体験してください。正式サイトオープンだそうです。
P.S. もう100kmも走ってるのか！
#7 都内で電動キックボード100km走って見てきた景色｜chocopie116｜note
Regional Scrum Gathering Tokyo 2019 は今週水曜日から開催です。チケット、スポンサー枠ともに完売しております。皆様のお越しをお待ちしております。
Day3は、昨年から復活しました、オープンスペーステクノロジーを行います。
概要は昨年と同じです。
OSTは事前にアジェンダを決めないセッションです。その場にいる人が議論したい内容を提案し、自分でセッション枠を割り当て、自己組織化でセッション表を作っていきます。OSTはスクラム "ギャザリング(集まる)" の象徴ともいえるセッションの１つで、海外で行われる Global Scrum Gathering では定番となっており、近年ではさらにCSPやCSTだけが集まる前日イベントでも同様の形式が取り入れられています。実践者自らが未来を考え、同じ課題を持つ人同士が繋がりあう、この"ギャザリング"とクロージングキーノートをもって会期を締めくくります。
クロージングキーノートは、ヤッホーブルーイングの井手社長です。「13年連続増収増益・国内クラフトビールNo.1」のチーム作りについてお話しいただきます。もちろんクラフトビールで乾杯しましょう！
今年も皆さんによってよい場所になればと願っております。
では、会場で！
前回のエントリもずいぶん多くの方に読んでいただいたようで、大変驚いております。
さらに、いただいたフィードバックから、もう一点補足した方がよいかなと思いまして、このエントリを書き始めました。補足の補足ですみません。
前回、IT技術者ではないキャリアを歩んでいる方々がプログラミングを学んだ事例としてジャパンタクシーの川鍋社長のエピソードと、若手向けプログラミング研修の例を出しました。
ビジネスマンがプログラミングを学ぶ価値
アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、１週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動かない。」「怖い。」ということだそうです。そのあとエンジニアに、そこで学んだようなプログラミングの延長で自社のアプリはうごいているのかを聞いたところ「そうだ」という答えが返ってきて、そのあと何もいえなくなったとのこと。
togetter.com
同じように、私にもビジネス系の若手にプログラミングを教える機会があったのですが、そこで最初に上がった声が「エラーヘル」でした。動かない。プログラミングをした人は誰でも知っていることですが、プログラムっていうのは正しく書こうとしても動かないわけです。これを肌身で理解しているかどうかは、「話が通じるかどうか」の大きなポイントかなと感じました。
これらの例に対して(だと思いますが)、IT技術者が経営を学ぶ方が早い、というご指摘をいただきました。この点はまったく同意です。
個人のキャリアパスでいうと、経営や管理手法を先に学ぶより、まず基盤となるコンピュータサイエンスや数学や統計を学んでおく方がスムーズかなと思います。すでにIT技術者としてキャリアを積まれている方が、経営について学ぶほうが、ビジネスマンにITを教えるより早い感じがします。
なのに、なぜ逆手順ともいえる例を紹介したのかといいますと、組織の観点で考えた時に、経営側・マネジメント側の主流がITに明るくない人だった時に、どうやってIT側の人を必要な職につけるのか？という大きな課題があると感じたからです。
前のエントリでも Microsoftの例を出しましたが、以前のスティーブ・バルマーCEOはマーケティングやセールスの側の方と聞いています*1。そのバルマー前CEOの下で、自社WebサービスBingやAzureを立ち上げてきたのが現在のサティア・ナデラCEOということです。有能な雇われCEOがポッと組織に入っていきなり社長になったわけではなく、実ビジネスをやりながら昇進のステップを踏んで、CEOになったというわけです。
多くの大企業で、同様に社内評価をえながら、同社を任せるに足る実績とビジョンを持った人材を育て、いずれ組織長に据える、ということを理想としていると思います。その人物が何者なのかを事前に見極めるステップがあります。次に優れたリーダーが選ばれるためには、その前に選球眼を持ったリーダーが必要になります。
任天堂の故岩田聡さんを社長にしたのは、創業2代目で花札の会社からテレビゲームの会社に導いた山内溥さんです。ファミコン初期から実際にゲームをプログラミングしてきた本当のハッカーの社長登用(その前のHAL研究所の支援の経緯も含め)は大きな決断であったろうと思います。
ナデラ氏や岩田さんを社長に据えたバルマー氏や山内さんの選球眼が鋭かったことに反論の余地はないと思います。そして彼らは、もともとコンピュータ技術者であったわけではありません。エンジニア出身のリーダーを、彼らが引き上げていなければ、エンジニア出身者が社長になることは、なかったわけです。
最近の日本の事例だと、DMM.comの亀山さんがピクシブ創業者の片桐さんを社長に登用したのも記憶に新しいところです。
ところで業界には「ITに明るくない人に上手に説明する、そこそこITがわかっている人」というのが大勢いらっしゃいます。プロジェクトマネージャーとか副部門長とかをされてたりするかもしれません。コンサルタントさんかもしれません。パワポが上手で、細かいところをさっと端折って、AかBか選べば経営判断下せる感じにしてくれる人たち。ITがわからない経営陣にとっては手放せない存在であることでしょう。
一見、優秀そうな方々なのですが、経営やマネジメントを任せた途端にボロを出してしまう方もいるようです。たとえばこんなような理由が思い浮かびます(実例ではないです)。
自分の言うことを聞いてくれた人をリーダーに据えるパターンは、なかなかうまくいかないというのは想像しやすいところかなと思います。
選球眼がだいじという話でした。選球眼を養っていただくためにも、ビジネスマンがITを実体験することで、共通言語を持つことはとても大事だと思います。もちろん、現役の経営者やリーダーが少しでもITに明るくなることは、組織にとっても即効性が高いのではないかと思います。話が通じるだけでずいぶん働きやすくなるわけです。
そして、数の問題があります。IT技術者の数を増やすことも重要でしょうが、ビジネスマンの数はもっと多いので、ビジネスマン自身が積極的にITを学んでいけば、何倍も早いスピードで業界が変わっていくのではないでしょうか。その学習への投資が、将来的に無駄になるとも思えないので、個人としても組織としても積極的に投資して良いのではないかと思っています。あ、翻訳者を増やすためのパワポやレポーティングばかり学ばせてもダメかもしれませんけれど。その点は人事／教育研修担当さんの選球眼も必要になりますね。
ところで、ビジネスマンの方々で、プログラミングの現場を直接見たことがある人ってどのくらいいるものなのでしょう？ポストイットを壁に貼っているアジャイルの現場を見た、ということではなく、コードを書いている現場や、コードそのものを見た経験のことです。どうでしょう？
2017年から自分たちでも取り組み、様々な形で紹介してきた、モブプログラミングという仕事の進め方があります。これは一箇所に開発者も企画者も集まって、一緒に作業を進めていく、という考え方です。会議の時だけ集まって資料を見ながら議論をするのではなく、常にそこにいて、仕事の状況を把握し、いつでも質問や議論を進められる状態を保ちながら、コードも書いていきます。
この手法を編み出したのが 米Hunter Industries。スプリンクラーの大手企業です。CEOがWoody Zuill氏にIT部門の再生を託し、あるチームが成功を納め、そのやり方を全体に広めたものだそうです。
私が所属していた楽天の部門でもこれを取り入れました。そして、さらに多くの人に広め、仲間を集めるべく、見学会を多数おこなってきました。(この点もHunterから学んだことです。)
ある見学会の時に、プログラマー出身じゃない方からこう言われたことがあります。
エンジニアの人って、一日中パソコンに向かって打ち込んでいるのだと思ってました。
その方ももちろん、キーボードを握ってコードを書いていただいたのですが、それだけでなく、観察によって、プログラマーがどのように仕事を進めているのかを発見されたようです。逆にいうと、こんな基本的なことも私たちは共有できていないのか！と気づかされました。まさに現地現物です。現場に行って、見てみるだけで、こんなことも発見できるのですね。
ビジネスマンがITを学ぶのは大変かもしれませんが、モブプログラミングをやってみることは、それほどハードルは高くないと思います。それだけでも、多くのことが学べるのだとわかりました。
モブプログラミングについては、昨年のDevelopers's Summitで実演を行い、ベストスピーカー第２位に輝きました。
また、これは宣伝になってしまいますが、Hunterの現役DirectorのChris Lucian の来日に合わせてモブプログラミング体験会を行います。Chrisは上のビデオで「Driver」の吹き出しのところにいる人です。
ご興味のある方はぜひ実際にどうやっているのかを覗きにきてみてください。ほんとうは現地に見にいくのが一番学びが多いと思いますが、全員がそうすわけにもいかないと思いますので、電車で行ける体験の機会を生かしていただければと思います。
多くの企業で、ITが急速に経営課題になってきたのが、この20年くらいの変化だと思います。さまざまな業種の方が、ITをさまざまなレベルで理解する必要が出てきました。なぜなら、それが仕事の重要な一部になったからです。
何か新しいことを理解するために必要なことは、まず第一歩、学び始めることです。人間は、今持っている知識を元に、新しいことを学ぶので、下手でも苦手でも、まずは第一歩を学んでみることが、大事なのかなと思います。
「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(三宅芳雄, 三宅なほみ 『教育心理学概論』 第一章 P.13-14)
また長くなってしまいました。みなさまの参考になれば幸いです。
*1:ただ、日本にきた時に「Developer! Developer! Developer!」と連呼するなど、開発者の重要性は同社の根幹をなす、という感覚は持たれていたようです。
昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。
この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。
システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か？みたいなエントリが盛り上がってました。
私はSIerにいたことがないので、そのあたりどうも疎いのですが、私としては「業務知識といえば、業務実現に必要な知識すべて」のことで、それは担当する業務によって変わってくる、ということではないかな、と思っております。そういう筋で前回のエントリを書きました。
もちろん、SIerの業務であるところの「ユーザー企業から発注をもらってシステム開発をする業務」においては、業務知識といえばお客様が実現したい業務に関する知識ということになろうかなと思います。ドメイン知識とも言ったりしますね。
で、そう考えると、マネジメント層にとっての業務知識は、部下や組織をマネジメントするために必要な知識、という感じではないかなと思います。前回のエントリで参照した米Microsoftの河野さんの話でも、マネージャーにとっての主たる業務はそこにあるようです。
私の業務知識に関する認識は上記のようなものなのですが、その前提で、さらにIT知識というものをどう捉えるか、というところに前回エントリの主題がありました。伝わるように書けてなかったみたいですけれど(ごめんなさい)。
全ての業務にITが入り込んできているので、もはやITと業務を明確に分解することが難しく、業務知識の範疇にITの基本的な理解が入り込んできている、ということです。
マーク・アンドリーセンが書いたように「ソフトウェアが世界を飲み込む」の時代なので、あらゆる業務がITを一緒に考えないと回らないようになってきている、もしくは、ITをうまく使わないと競争に勝てない／儲からないというところに来ている、ということかなと考えております。(池田信夫 blog : ソフトウェアが世界を食う に一部日本語訳がありましたのでそちらもご参照ください。)
っていうことで、「業務知識の一部となったITがわからない経営層やマネジメント層のままで大丈夫か？」というのがエントリでの核となる問いでした。
経営やマネジメントにIT知識が必須だなんて言っても、急に関係者のみなさんがITに詳しくなるわけでもないので非現実的と思うかもしれません。GAFAじゃないんだし。私もそう思ってました。Microsoftに遊びに行くまでは。
少なくとも米国で時価総額一位に返り咲いた米Micriosoftでは、エンジニアの上司はCEOまで遡ってもエンジニアないしエンジニアの言葉がさっと通じる人になったみたいです。現在のサティア・ナデラ氏がCEOになったのは2014年だそうです。30年企業ですので、それなりに分厚いマーケティング企業になっていたところを、グッと技術側に引き戻したのがここ数年の躍進につながっているのではないかとおもいます。
Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来
日本でも2013年に創業したメルカリや、AIで躍進するPreferred Networks(2014創業)などは、同じように経営陣までその言語で通じる人たち、な感じがします。もはや業務知識とIT知識を分けるというマインドはかけらも持ってないんじゃないかと思います。
アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、１週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動かない。」「怖い。」ということだそうです。そのあとエンジニアに、そこで学んだようなプログラミングの延長で自社のアプリはうごいているのかを聞いたところ「そうだ」という答えが返ってきて、そのあと何もいえなくなったとのこと。
togetter.com
同じように、私にもビジネス系の若手にプログラミングを教える機会があったのですが、そこで最初に上がった声が「エラーヘル」でした。動かない。プログラミングをした人は誰でも知っていることですが、プログラムっていうのは正しく書こうとしても動かないわけです。これを肌身で理解しているかどうかは、「話が通じるかどうか」の大きなポイントかなと感じました。
そんなような話をユアマイスターの高山さんにお話ししたような気がするのですが、そのあとブログにこんなことを書いてくれました。ビジネス側でキャリアを積んできた方からみても、腑に落ちる点があったようです。
takayamamusashi.hatenablog.com
業務知識とIT知識の話から、長い話をしてきましたが、IT知識、開発、営業、文系、理系 ... クロスボーダーで理解し話し合わないと解けない問題が主戦場になってきた、というのが背景にあるかなと思います。ひとことで言えば、業務に関して話が通じる組織が強いということかなと。あれ、これは別に新しいことでもなさそうです。
自動車会社でいえば、現地現物や三現主義。クルマやユーザーの話が通じることを大事にしているわけです。米Microsoftであればソフトウェアやそれを開発する人々について、すぐ判断ができるくらいは知っていないと、マネジメントは開発者をサポートすることができません。簡単なことではないと思いますが、それを維持している企業が時価総額の上の方にいる感じがします。
業務知識とIT知識で分けて考えるのは、そんなに普遍的な話でもなさそうだし、あったとしてもそんな時代はとっくに終わっているのかもしれません。
蛇足ではありますが、金融とかはそうじゃない...とおっしゃる方がいるかもしれませんが、AIでトレーダーが激減してみたり、当の金融機関の方はそんな悠長なことは考えてないと思います。
gigazine.net
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。
ああそうでした。それは多いでしょうね。でも必要な知識だと思います。持たなくても食っていけるっていうのは、SIerの非常に限られた世界の常識に過ぎず、しかも、そもそもそれすら間違いなのではないかと思いました。
業務とITはもうとっくに切り離せないのだとすると、「こっから先は学ばなくてもよい」と言っていた領域がいろいろ言い訳できなくなってきてしまうなぁ、と言う感じがします。すくなくとも、相手と話せるくらいの理解がある方が、仕事が進めやすそうです。小学生向けにプログラミングを教える時代です。教材はたくさんあります。
ということで、またも答えはないわけですが、今後のヒントになれば幸いでございます。
(追記) さらに補足を書きました
