ヒンディー語の文字（デーヴァナーガリー文字）を学習するアプリを作ってみた
ついに本格的にヒンディー語の勉強を始めたのですが、やはりヒンディー語の文字である"デーヴァナーガリー文字"が最初のハードルです（こういうの → नमस्ते）。「これは繰り返し書いて覚えるしかないなあ」と感じる一方で、紙にペンというアナログ学習は性に合わない...。ということで、手書きでヒンディー語の文字を学習できるアプリを自作してみました。
HindiScript - Devanagari | スマホアプリ
言語学習の初期で重要なのは、その言語の音と文字を一致させながら記憶していくことだと思います。そこで、"手書きで学習できて簡単に模範の文字と比べられる"、"模範の音声が聞ける"、"発音の説明がある"、という3点に絞って、アプリを開発しました。学習の流れを簡単に紹介します。
学習の流れ
1. 模範文字を真似て覚える
「母音」「子音」「母音記号」などのカテゴリーから学習したいものを選びます。すると、模範文字が薄く表示されているので、それを真似しながら、文字を一つずつ記憶していきます。「簡単」「普通」「難しい」と自己評価をするようになっているので、繰り返し学習をしていき、覚えた！というタイミングで「簡単」を押してください。
2. 模範文字なしで練習する
「簡単」が押された文字は次の学習ステージに進み、模範文字の表示がなくなります。アルファベットの読みと音声を頼りに、文字を書いてみてください。その状態で練習を続け、もう大丈夫！というタイミングで「簡単」を押してください。2回の「簡単」でクリアとなって学習対象から外れます。これを繰り返し、全ての文字にクリアしたら完了です。
3. 学習Tipを読む
母音や子音はそのまま覚えるだけで大丈夫なのですが、結合文字など複雑なものに取り組むときはTipを読んでください。より理解を深められます。
搭載コンテンツ
- 母音
- अ, इ, ई, उ, ऊ, ऋ, ए, ऐ, ओ, औ
- 子音
- क, ख, ग, घ, च, छ, ज, झ, ट, ठ, ड, ड़, ढ, ढ़, ण, त, थ, द, ध, न, प, फ, ब, भ, म, य, र, ल, व, श, ष, स, ह
- 母音記号
- क, का, कि, की, कु, रु, कू, रू, कृ, के, कै, को, कौ
- 単語（母音と子音）
- अगर, आम, इधर, ईख, उमर, ऊब, ऋण, एक, ऐनक, ओर, और
- 単語（母音記号）
- नाम, पिता, पानी, बहुत, रुपया, दूध, शुरू, कृपा, देश, भैया, लोग, सौ, हाँ, नहीं,
- 単語（子音結合）
- स्कुल, अच्छा, अम्मा, अक्सर, फ़्लू, छुट्टी, उद्भव, अक्षर, कुत्ता श्वेत, नष्ट, आह्लाद, सह्य, धर्म, धर्मेतर, प्रेम, ट्रक, मित्र, ज्ञान
学習後のあなたのレベル
このアプリでの学習終了時は上記を想定しています。基本的な文字の学習は全て終了、単語の中での読みや書きに一部未習がある状態です。残りは次のステップになるであろう文法や語彙の学習をする際に慣れていけば良いかなと、敢えて情報量を制限しました。
技術的な話を少し
React Native (Expo) + Reduxで開発しました。手書き機能はexpo-pixi、合成音声はAmazon Polly、多言語対応はi18n-js、UIはReact Native Elementsを使っています。カラーをインドの国旗に合わせて、オレンジ、緑、青で構成したのが個人的なこだわりです。取り扱うデータ量が多くなかったので、サーバーを立てず、アプリ側に全ての情報を持たせています。
開発期間は3ヶ月程度ですが、本業の出勤前後の隙間時間と休日の一部を使って作業したので、実質的な工数は20人日ぐらいでしょうか。実際はアプリ開発よりもコンテンツ制作に苦労しました。模範文字は文字データとして持っているのですが、もちろんそれらは自分でタイピングする必要があり、ヒンディー語学習とアプリ開発を並行させるのが大変でした。その大変さもあって、今回は有料アプリにしています。ポチって頂けると飛び跳ねて喜びます。
終わりに
ヒンディー語を独学で学習している人はどのぐらいいるのでしょうか。日本語はもちろんですが、英語でググってもあまりヒンディー語に関する情報がないなあと感じています。IT業界にいる自分としては、自身で学習しながら、役に立つアプリや情報を発信していけたらなと考えています。ヒンディー語学習者の皆さん、ぜひ引き続きよろしくお願いします。
※新たにスピーキングの練習をするアプリと音読・リピーティング・シャドーイングの練習をするアプリも開発しました。
2018年を振り返って
あっという間に2018年も終わりですね。仕事納めが12月28日で無事に終わり、自宅に戻って振り返りの記事を書いています。この振り返りエントリーは2012年から続けているので、こうしてPCに向かうといよいよ年末だなあという実感が湧きます。気持ち良く1年を締めくくり、幸先良い新年を迎えたいものですね。
2018年の振り返り
- 1月 ... Gantt Chart Generatorをリリース
- 3月 ... Precedence Diagram Makerをリリース
- 5月 ... PMだった大型プロジェクトが終了
- 5月 ... 初めてのアメリカ旅行
- 6月 ... PMとして超大型プロジェクトが開始
- 8月 ... 鹿児島旅行
- 9月 ... サウナと出会う
- 10月 ... バクシンをリリース
- 11月 ... ダーツの旅
昨年末のエントリーでは「プロジェクトマネジメントのスキルアップ」「PythonとSQLを覚える」「中学数学、数学IAをやり直す」「筋力トレーニングを始める」の4つを2018年の目標として掲げていました。これらに関しては、途中で方向転換したものや、達成できていないものもあるのですが、おおむね満足のいく1年間になりました。一つずつ振り返ってみたいと思います。
目標 1. プロジェクトマネジメントのスキルアップ
スキルアップには、知識のインプットと、実践のアウトプットの両方が必要です。幸いなことに、2018年は○億円規模の大型プロジェクトを2つもPMとして担当することができて、非常に多くの経験値を積むことができました（その内の一つは今も継続中）。
知識のインプットでは、本を読んでまとめを言語化する、というサイクルを意識して取り組みました。ちなみに、読んだ本の一覧は下記です。プロジェクトマネジメントだけではなく、システムテストや要件定義、エンジニアリングなど、関連する分野の勉強も必要かなと思い、対象範囲を拡げて選択しました。もうちょっと読めたかなあという感じもありますが、実践に活かせる知識もたくさん得られたので及第点としたいと思います。★をつけたのはお薦めの本です。皆さんも是非読んでみてください。
2018年で読んだ本一覧
- ★ エンジニアリング組織論への招待
- 曖昧性との共存
- ★ 曖昧性とのたたかい
- 失敗しないITマネジャーが語る プロフェッショナルPMの神髄
- エクストリームプログラミング
- ユーザーストーリーマッピング
- カンバン仕事術
- 演習で身につく要件定義の実践テクニック
- はじめよう! プロセス設計 ~要件定義のその前に
- ★ Inspired: 顧客の心を捉える製品の創り方
- ★ 知識ゼロから学ぶソフトウェアテスト 【改訂版】
- ★ アジャイルな見積りと計画づくり
- ★ スクラム 仕事が４倍速くなる“世界標準”のチーム戦術
- ★ トヨタ 仕事の基本大全
- 無印良品は、仕組みが9割
- ★ 世界を動かすプロジェクトマネジメントの教科書
目標 2. PythonとSQLを覚える
これは方向転換をして、Python・SQLではなく、JavaScriptに取り組みました。JavaScriptで出来ることも増えていますし、元々JavaScriptは少し書けたので、素人が広く薄くやるよりは、一つを深めていった方が良いだろうという判断です。
アウトプットとしては、Google App Scriptのアドオンを2つ、React NativeでiOSアプリを1つリリースしています。また、仕事のプロジェクトを推進していく為に、AsanaのAPIと連携したSlack Botなど、業務改善ツールにも取り組みました。純粋にモノづくりそのものが楽しかったですし、プログラミングで得られた経験や知見は、本業のプロジェクトマネジメントにも大きなプラスになっていると思います。
プログラミング関連で2018年で一番の経験は、Gantt Chart GeneratorというGoogle App Scriptのアドオンが想像以上にダウンロードされたことです。12月28日時点のユーザー数が 21848人、レビューは57件ついています。1口9.8ドルからという強気な寄付リンクを小さくつけていたら、数十人の方が寄付をしてくれました。2口以上寄付をしてくれる人もいて大変ありがたかったです。その中でも一番嬉しかったのは、コードをGithubに公開しているのですが、ここにスターが50弱ついたことです。自分が作ったものが評価されるということは本当に嬉しいものですね。
また、多くの人が使うからこそ得られる気づきがたくさんありました。例えば、設計の甘さから起こるバグ。世界各国で使われる想定をしていなかったので、時差やサマータイムの対応に苦しみました。他にも、メンテナンス性が考慮できていなくてアップデートするときに特定の手順を踏んでもらわないと動かなくなるとか、本当に様々なトラブルに遭遇しました。設計やテストの重要さを実体験で理解できたのは大きかったです。今後の個人開発、仕事のプロジェクトにこの経験を活かしていきたいと思います。
目標 3. 中学数学、数学IAをやり直す
これは途中で挫折しました。中1から始めて中2の図形までいきましたが、これがもう本当に面白くなかった。気分転換に中3の平方根とかやってみましたが、モチベーションがあがらず、あえなく断念しました。 無念。
目標 4. 筋力トレーニングを始める
これはバッチリ達成できました。NHKの筋肉体操を見ながら毎日やっています。プロテインも飲み始めました。筋肉は裏切らない。筋トレで70kgまでの増量を目指します。
その他
2018年の大きなトピックの1つはサウナとの出会いです。先輩サウナーに導かれて、錦糸町のニューウイングに行ったのですが、完全にやられました。今では週2でサウナに通っています。僕はもうお酒をやめてしまったので、友人の皆さん、今後は飲みではなくサウナに行きましょう。一緒に整いましょう。
2019年の目標
2019年はこの3つを目標にしたいと思います。ヒンディー語はずっとやりたいと思っていていて、インドから帰国して4年近く経ちましたが、ようやく始められるほどの時間的余裕が作れそうです。まずは基本的なヒンディー語を覚えて、インド料理屋で裏メニューを頼むことを目指します。ゆくゆくはインド人をあっと驚かすほどの流暢なヒンディー語が話せるようになりたいです。
怒りの感情のコントロールはずっと自分の課題だと思っていて、仕事で感情的な議論をしてしまう度に反省をしていました。アンガーマネジメントは、anger（怒り）をmanagement（管理）するというもので、精神的ではなくシステム的なアプローチで怒りをコントロールするものです。これが出来たら一つ上のステージに自分が成長できる気がします。
筋トレとサウナはもはや習慣化しているのですが、引き続き継続して、心身の健康を維持したいと思います。2019年で32歳になりますし、これからは健康第一ですね。
終わりに
さて、2018年も皆さま大変お世話になりました。年末はどのようにお過ごしでしょうか。僕は明日から家族旅行に出かけ、大晦日に戻って自宅でゆっくりと年越しをする予定です。歳を重ねるに連れて、こういう年越しが理想的になってきました。それでは皆さまも良いお年をお迎えください。 2019年もどうぞよろしくお願いします。
「人生の100のリスト」作ってみた
もうすぐ32歳。ふと「残りの人生で自分のやりたいことが全部できるのかな？」「そもそも人生でやりたいことって何だったっけ？」と疑問に思うことがありました。そこで、今更ながら作ってみました、人生の100のリスト。作りながら自分が客観視できて、思いのほかやって良かったです。人生、楽しんだもの勝ち。
死ぬまでにやる人生の100のリスト
- 自分のやりたいことを仕事にする
- 海外で働く 達成（2014 - インドで働きました）
- スタートアップで働く 達成（2017 - COMPASSで働いています ｲﾏｺｺ!）
- 外資系企業で働く
- 多国籍のチームで働く
- 少数精鋭のチームで働く
- 旅をしながら働く
- プロジェクトベースで働く
- チャリンチャリンビジネスを細々と運営する 達成（2021 - GASのアドオンを有料化しました）
- 教育機会の平等化の為に働く
- ソーシャルビジネスをする
- ボランティアをする
- 外貨を稼ぐ 達成（2015 - 初めてのお客さんはエジプト人でした）
- 時間単価1万円で働く
- 月に10日間だけ働いて暮らす
- 何かの分野のスペシャリストになる
- 起業する 達成（2009, 2015 - Omorey, Wasabiで起業しました）
- Exitする 達成（2016 - Wasabiを事業売却。志半ば...という感じでしたが）
- エンジェル投資をする
- 怒りの感情をコントロールする
- 承認欲求をコントロールする
- 寛容になる
- 相手を尊重してコミュニケーションできるようになる
- 煩悩を断ち切る
- 悟りを開く
- 英語を話せるようになる 達成（2016 - 英語学習についてはここ）
- ヒンディー語を話せるようになる
- プログラミングを出来るようになる 達成（2018 -プログラミング学習についてはここ ）
- 資産運用をする 達成（2018 - 投資信託を始めました）
- 日本史の勉強をする
- 世界史の勉強をする
- 哲学の勉強をする
- 宗教の勉強をする
- 数学の勉強をする
- 経済の勉強をする
- 社会学の勉強をする
- 学士を取得する
- 修士を取得する
- 自分のブログを通じて人と会う
- 英語でブログを書く 達成（2019 - Mediumを始めました）
- 世界中の人とインターネットを通じて交流する
- Webアプリをリリースする
- スマホアプリをリリースする 達成（2018 - 予防接種の管理アプリ作りました ）
- ○万人規模のサービス/メディアを運営する 達成（2018 - GASのアドオンのユーザーが2万人超えました ）
- ○億人規模のサービス/メディアを運営する
- Webメディアに載る 達成（2015 - 東洋経済に載りました ）
- ラジオに出る 達成（2016 - NBC長崎放送に出ました ）
- 新聞に載る 達成（2016 - 島原新聞に出ました ）
- テレビに出る
- 探偵ナイトスクープに出る
- 講演をする
- パネルディスカッションに出る
- 大学で授業を持つ
- 電子書籍を出版する 達成（2017 - 日本語の文法書を書きました）
- 紙の本を出版する
- 47都道府県を全て訪れる
- 世界一周旅行をする
- インド一周旅行をする
- 宇宙旅行をする
- （もう一度）自転車旅行する
- （もう一度）ヒッチハイク旅行する
- 海外で暮らす 達成（2014, 2017 - インド、中国で暮らしました）
- 南国で暮らす
- 田舎で暮らす 達成（2016 - 島原半島で暮らしました）
- 島で暮らす
- インドの文化を体験する（まだまだ足りない）
- イスラムの文化を体験する
- 共産主義の文化を体験する
- アフリカの文化を体験する
- 信仰心を持つ
- 民族衣装を着て生活をする
- ○百万単位で寄付をする
- 漫画家に資金援助をする 達成（2020 - 00:00 Stadio を通じてやりました）
- 政治家を支援する
- 行きずりの困っている人を助けて格好良く立ち去る
- カウチサーフィンのホストをする
- オーケストラを見る
- ミュージカルを見る 達成（2019 - 劇団四季 パリのアメリカ人見てきました）
- ジャズバーに行く 達成（2019 - BLUE NOTE TOKYO 行ってきました）
- 映画の舞台挨拶を見る 達成（2020 - えんとつ町のプペルの舞台挨拶を見ました）
- Got Talentを見る
- TEDを見る 達成（2019 - TEDxOtemachiを見ました）
- フラッシュモブに出くわす
- スタンディングオベーションの一人目で立つ
- ブラボー/ブラバー と一人目で言う
- ベジタリアンになる
- 筋トレで70kgまで増量する（2018/12/22現在は62kg）
- 現金を持たない生活をする
- 職住近接な生活をする
- ホログラム（立体映像）を自宅に導入する
- 自宅に書斎を作る 達成（2020 - コロナ禍によって広い家に引っ越しました）
- アーロンチェアを買う 達成（2019 - エルゴヒューマン プロにしました）
- ディスプレイを2枚買う 達成（2019 - ASUS ZenScreenとiPadのDuetを導入）
- Macbook Proを買う 達成（2018 - 最高！）
- ルンバを買う 達成（2020 - これも最高！）
- 食洗機を買う 達成（2018 - 人類が生み出した最高傑作でした）
- 乾燥機付き洗濯機を買う 達成（2018 - これまた最高でした）
- 一泊20万円以上のホテルに泊まる
- 一食5万円以上の食事をする
- 「人生の100のリスト」を全て達成して新しい100のリストを作る
100個もリストアップできないと思いましたが意外に大丈夫でした。ただ、これらを達成したら人生満足かと言うと、きっとそうではない気がしています。達成する後には新しい価値観を持つ自分がいるだろうし、そのときの自分でまた新しい「人生の100のリスト」を作りたいなと思います。人生はたった一度きり。精一杯楽しみたい。
プログラミングを独学で脱初心者する為のロードマップ
元々IT系ではなかった僕ですが、必要に迫られてホームページを作ったことをキッカケに、コードを書くようになりました。「もっと上手くなりたい」と試行錯誤をしている内に、気がつけば仕事の中でもコードを書いて業務効率化するようになっていました。そして、先日ついに初めてのiOSアプリをリリースしました。ようやく自分の中でも、プログラミング初心者を脱した感覚があり、これまでの勉強法をまとめておきたいと思います。
*いまや黒い画面も怖くないぞ
独学で身につけるプログラミング
プログラミングの上達のコツは「作りたいものを作る」ことにあると思います。僕はホームページがキッカケだったので、HTML, CSS, JavaScriptから学習が始まりました。Web系の学習は成果が見えやすく、モチベーションが保ちやすいのでお薦めです。具体的なインプット（学習リソース）とアウトプット（成果物）を合わせて記述していくので、学習者の皆さんの「このぐらい勉強すれば、こういうことが出来るようになる」という指標になれば嬉しいです。
1. WordPressでWebsiteを作る
インプット
Codecademy
ドットインストール
書籍
アウトプット
メモ
まず初めに、WordPressというブログソフトウェアを使ってホームページの作成をしました。WordPressはPHPという言語で動いているので、一応PHPの入門コースの動画を見てみたのですが、ほとんど理解できずに意味がありませんでした。しかし、実際にアウトプットのホームページは完成しています。この"わからないけど動く"というのは大事なことだと思っていて、乱暴に言えば初めのうちは理解できてなくても動けば良いぐらいだと思います。
僕はCodecademyというサービスを使って、HTMLとCSSの勉強をしましたが、英語が得意ではない人はProgateを使うのが良いかもしれません。両サービスとも手を動かしながら学習できるのが特徴で、とても頭に入りやすいです。HTMLとCSSできるようになれば、それだけで見栄えの良いWebsiteを作ることが可能です。WordPressの環境設定は手間ではありますが、ググると大量に情報が出てくるので、特に気合を入れて勉強しなくて大丈夫だと思います。
2. JavaScriptで動的なWebsiteを作る
インプット
Codecademy
ドットインストール
- JavaScript入門
- JavaScriptで文字数チェッカーを作ろう
- JavaScriptで割り勘電卓を作ろう
- JavaScriptでパスワードジェネレータを作ろう
- JavaScriptで5秒当てゲームを作ろう
- JavaScriptでストップウォッチを作ろう
- JavaScriptでおみくじを作ろう
- jQueryで作るスライドショー
- jQueryで作るキャラ診断
書籍
アウトプット
メモ
次にJavaScriptを使って、動きのあるホームページを作りました。アウトプットにあげたのは、友人のBarのホームページを作成したときのものです。Bootstrap を中心に外部のライブラリを使って実装しています。ある程度のプログラミングの基礎を掴めば、公開されているライブラリを活用して、それっぽいものが作られるようになってきます。
このときの学習は、お手本通りに書き写す「写経」が中心でした。写経はあまり楽しい学習法ではありませんが非常に効果的です。Codecademyと書籍で基本的な文法を学び、後はひたすらドットインストールの動画を真似していました。紹介している「JavaScript本格入門 」はとてもお薦めです。初級レベルならこの一冊で良いぐらいだと思います。ホームページを公開するには、独自ドメインをとってレンタルサーバーを借りてと、JavaScript以外の知識も入りますが、Google先生に聞きながら真似するだけで事足りると思います。
3. Node.jsでWebアプリケーションを作る
インプット
- プログラミング入門 Webアプリコース
書籍
アウトプット
メモ
ここでは外部のAPIを使ってアプリケーションを作り始めました。APIが使えるようになると、一気にプログラミングが楽しくなってきます。紹介している振り仮名ジェネレーターは業務の中でも大活躍してくれました。が、独学者にとっては、この辺りが学習の一つのハードルではないでしょうか。内容も難しくなってくるので挫折する人も多いと思います。
そこでお薦めするのがドワンゴが提供するN予備校です。はっきり言って、めちゃめちゃクオリティが高いです。環境構築、コマンドラインの使い方、セキュリティなど、実践的な内容がカリキュラムに組み込まれています。N予備校で勉強しつつ、JavaScript 第6版、通称サイ本で知識を深めるというのが自分に合っていて、かなりレベルアップすることができました。
4. React NativeでiOSアプリを作る
インプット
Udacity
アウトプット （※現在はストア掲載は停止）
メモ
JavaScriptでもReact Nativeという技術を使えばスマホアプリの開発が可能です。JavaScriptの魅力の一つは、この言語だけで様々なことを実現できることだと思います。ES6, ES7と、コードの書き方が多少変わったりするものの、基本的にはこれまで学習した内容を活かしてスマホアプリを作ることができました。
ここではUdacityのNanodegree Prgramを受講しました。安くはないですが（しかも最近値上げをしている）、カリキュラムの充実度を考えると費用対効果は悪くないと思います。Nanodegree Prgramの良いところは、1. コードレビューがあること、2. 学習コミュニティがあること、です。独学をしているとコードレビューを受ける機会があまりないので、凄く勉強になりました。
おわり
以上です。最近は、大人こどもを問わず、プログラミングの必要性が社会で論じられています。僕は全員がプログラミングを学ぶべきとは思いませんが、ひとつ確かに言えるのは、プログラミングがわかると仕事が楽になる、ということです。僕は1~2年間はプログラミングを勉強していますが、その時間的投資に対するリターンは充分にあったと感じています。単純作業が自動化できますから。それになにより純粋に、モノづくりは楽しいです。PC1台から始められて、仕事にも活かせる大人の趣味。そんな風に気軽に始めてみるのも良いかもしれません。独学者の皆さん、お互い頑張りましょう！
「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト
「曖昧性とのたたかい」という本をご存知でしょうか？日立製作所で、みどりの窓口などの開発に携わった名内氏が、自身のプロジェクトマネジメントの経験をまとめた名著で、プロジェクトマネージャーなら必読の一冊です。アジャイルやリーンというモダンな開発手法が確立されていないなかで、大型のシステム開発をする厳しさは想像に難しくありません。また、その厳しさがタイトルによく現れていると思います。
システム開発に関わるプロマネに必須のチェックリスト
「曖昧性とのたたかい」は疑うことのない名著ですが、SE出身の著者ということもあってか、システム設計への言及などその内容は多岐にわたります。そこで純粋なプロジェクトマネジメントの要素に主眼を置いて、自分に刺さったところを「契約フェーズ」「設計フェーズ」「実装フェーズ」に分けてリストアップしてみました。詳しくは本書の購入をお薦めしますが、概要を斜め読みしたい人は参考にどうぞ。
契約フェーズ
提案と交渉
ポイント
- 提案依頼書に要求仕様などの詳細が書かれていることはまずない
- 完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
- 曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
チェックリスト
- 仕様が膨張するものとして、予算増額の必要性があることを事前に伝える
- 顧客からの仕様変更要求に際しては、必要な対策日程の確保と対策費用を負担していただくことを契約に盛り込む
- 予算増額の論拠を用意しておく（当初見積もりの前提条件を明確にしておく）
- 時間の許す限り、顧客の要求を文書化する
- 仕様の膨張が濃厚であれば、開発段階を区切り、最初の段階だけを見積もらせてもらう
- 契約納期と絶対納期（顧客側で死守しなければならない期限）を把握しておく
- 契約納期には「仕様凍結後○ヶ月」のような条件をつけておく
- 検収条件を「条件Xのとき結果Y」のような明示的なものにするか、検収期間を有限にして検収テストは全て顧客に実施してもらう
- 見積もりは再見積もりが許される条件設定をしておく
- 要求仕様が曖昧すぎる場合は、仕様確定までは「要員派遣ベースによる仕様確定契約」としてもらい、仕様確定後に「システム開発請負契約」にしてもらう
設計フェーズ
要件定義
ポイント
- 受注が決定したら、全力を挙げて受注条件の明確化、再確認、システム仕様の早期確定に努めなければならない
- 基本的に契約金額内で仕様をまとめることが両者にとって大事なことであり、かつ両者の利益につながるのだという共通認識を確認し合って仕様の確定に臨む
チェックリスト
- 契約書のみならず（提案と交渉の時の）覚書や議事録も確認する
- 検収条件をよく読み、無理なく検収されるような検収条件になっていることを確認する
- 見積り条件や検収条件に不備があれば、今後どう正常化してゆくべきかを営業担当者とともに善後策、および顧客といかに交渉するか戦略を立てる
- 打合せに入る前に、まず見積り / 契約条件に盛り込んだ（受注者側の考えている）システム仕様をより具体的に文書化して提示する
- 詳細を説明した後、発注者からの「変更要求」を聞くようにするのが仕様の早期確定に有効であるばかりでなく、「仕様変更要求項目」の明確化にも役立つ
- システム全体の開発費用は仕様確定後に決めるという段階的契約方式をとる場合も、顧客側には予算の腹づもりがあるはずなので 、総予算を聞き出して、この予算枠内で仕様をまとめるように顧客をリードする
-
いつまでにシステム仕様を固めるか全体工程の中で顧客と合意し決める
-
もし発注者側の体制や統制力に問題がある場合には、幹部、営業と協力して、発注者幹部に善処してもらえるよう早めに申し入れる
- 業務仕様をどういう順序で確定していくかあらかじめ作戦を立てておく
- プロトタイプ方式を採用するときは、終結時限（仕様凍結時限）を明確に定め、いつまでもやり直しや修正が続かないようにする
- 何のためにシステムが必要とされ、何が一番重要なことなのかを全員が正しく理解する（真の目的を把握していれば、より合理的、より経済的な代案システムの提案も可能となり、システム機能の膨張の抑制につながる）
- 業務の正確な理解に努める（正確な理解とは、その業務の目的、やらなければどういう不都合が生じるのかということまで理解すること）
- 仕様追加がある場合は、要求しても無理だろうなどと考えず、粘り強く予算増額交渉をする
- 仕様が凍結したら、新たな仕様変更要求が出てくる前に、仕様変更案件管理、変更承認手続き、顧客による変更予算認可手続きなどの管理方式を顧客と共同で用意する
- 受注したら直ちに第三者を含めてプロジェクト推進作戦会議を開催し、多角的にリスク回避戦略を議論する
工程設計
ポイント
-
受注後、プロジェクトマネジャーがまずやらねばならないことは、工程の設計と目標原価の設定
-
プロジェクト工程計画とは、そのプロジェクトに挑むプロジェクトマネジャーの作戦計画であるから、まさにマネジャーの、そのプロジェクトに関するすべての知識と認識、今後発生しうる各種の事態に対する予測を含めた見解を表現したものとなる
-
人件費は、ざっと言えば投入工数のみで決まる。投入工数が予算以上に増えるのは工程（スケジュール）が遅延するか、開発量が膨れ上がるか、予想以上に品質が悪いかが主たる原因である。したがって、 コスト管理はとりも直さず、進捗管理、品質管理、仕様変更管理の問題に帰着する
チェックリスト
- 稼働日（=納期）に絶対不可欠な機能と、無理をすればあとからでも追加可能な機能に分ける
- やってみなければわからないことが多くても、最初に全貌を考えぬく積りで極力詳細な工程を設計する
- PERT図の考えを取り入れ、前後関係、相互依存関係が明確になるようにする
- 重要な仕事にはその前に必ず準備作業（仕事の前の仕事）が必要であることを忘れないように
- 工程配分は過去のプロジェクト実績データを参考にすべきであるが、少なくとも3分の1の工程を設計工程に割り当て、手戻りのない設計を目指す
- あらかじめどういう手段で進捗を計るのか考えておく。特に各工程の終了条件を明確に決めておく必要がある（定量的進捗度の把握が大事であるが、質的な進捗度の把握については中身のレビューで補う）
- 計画時には悲観的に最悪事態を想定した準備を行い、実行時は楽観的に明るくプロジェクトを推進する
- 最悪の事態に陥った場合、納期延期を申し入れる日を秘かに決めておく
- 同時に納期までに完成が困難と予想されるときは逃げ道を考えておく（代替手段、部分稼働、従来システムとの並行運転など）
- 工程表が作成できたら顧客と打合せを実施する。このときには、特に仕様凍結日、提出書類の承認期限、顧客側で準備してもらう各種ドキュメントなどの準備期限について合意を得る
- プロジェクトで用意するドキュメント体系、およびその作成基準を定める
- よく使われる業務用語（ジャーゴン）については、素人の人にもわかるような用語集（グロッサリー）を用意し、プロジェクトのステークホルダー全員が共通の理解を持てるようにする
- 大規模プロジェクトの場合はプロジェクトマネジャーの補佐組織として、ライン設計部隊とは別のプロジェクト統括部隊を編成する
- 開発するシステムの目的や基本コンセプト、プロジェクト運営の基本的考え方、プロジェクト共通基準、工程計画に関するプロジェクトマネジャーの考え方などを説明し、全員に理解してもらう（このような全員ミーティングは少なくともプロジェクトのスタート時、主要メンバーが揃って定期的進捗管理が始まったとき、全メンバーが揃ったときの3回は実施したほうがよい）
実装フェーズ
進捗管理
ポイント
- 進捗を定量的、客観的に捉えるとともに、質的な面、つまり設計の充実度、ドキュメントの記述レベル、その内容なども重視して、工程（あるいはスケジュール）の進捗を妨げる問題点の早期把握に努めなければならない
- 仕様変更はプロジェクトの円滑な遂行にはマイナスの影響を与えるが、仕様変更なしのプロジェクトは稀である。したがって、適切な仕様変更管理が必須になる
- プロジェクトの成否を決めるのは、プロジェクトメンバーの力であり、そのチームとしての組織力
チェックリスト
- 計画と実行の差を明確化することに主眼を置かなければならない。すなわち、遅れを遅れとして正しく認識できること
- 進捗度の事前定義と全員への徹底
- プログラム開発においては、無理をしてでも進捗度を定量的に把握する（ページ数、画面数、帳票数、コーディング行数、メモリー量、項目数、定義数、チェックリスト消化数など）
- 責任追及より実態把握を重視。何の助言もなく厳しいだけの管理はかえって実態を隠蔽する危険性がある
- 仕様確定工程は絶対遅れさせないようする。不幸にして顧客の体制が整備されていなかったり、顧客の決定が遅れてきたときは、幹部や営業の協力を得て、顧客幹部に善処してもらえるよう申し入れる
- 進捗把握は担当者から報告された内容だけに頼ってはならない。自分の目で、現場現物を確認する
- 定量的進捗度と同じぐらい重要なのがレビューを活用した質的な進捗度の把握・評価
- レビューは部厚い仕様書ができ上がってから実施するのでなく、ある程度まとまれば少しずつ実施し、だんだんレビューの質あるいは難易度を高めてゆく
- レビュアーの誰かが大幅な変更ややり直しの必要性を訴えるような場合、プロジェクトマネジャーは一番悲観的な意見を採択し、設計のやり直しを決断したほうがよい
- ある担当者の開発部分の品質が時間が経っても一向に改善しないとき、その担当を更迭して一からやり直すのは勇気がいるが、思い切ってやり直しをしたほうが良い結果を生む
- 要員不足だからといって、能力の劣る要員による応援はかえって混乱を招く
- 工程表を書き直していると、工程が遅れてきた実態がわからなくなり危機感も薄くなる。工程表の書き直しは極力やめるべき（やむを得ず書き直して納期を先に延ばす場合は、思い切って実態を正直に反映したものにする）
- 進捗状況がかんばしくないときは早めに営業担当者にその旨漏らしておく
- 混乱したら思い切って開發を止めて、マネージャーの頭の中に実態が正しく認識されるまで徹底的に実態把握に努めるべき
仕様変更管理
ポイント
- 顧客と開發側双方が仕様凍結を宣言できたあとでさえ、さらなる仕様変更が出てくることは実際には多い
- 「仕様変更は不可避」であることを覚悟し、仕様変更による工程の混乱や、収益悪化のリスクを回避するために、変更があってもミニマムな対応ですませる作戦と仕掛けをあらかじめ用意する
チェックリスト
- 仕様変更が続くということは単にベンダーだけの損失でなく、顧客にとってもリスクであり、損失であることを顧客によく理解してもらう
- 仕様変更要求が出た場合、窓口は一元化し、案件管理の手順を定め、変更決定時のソフトウェア/ハードウェア/ドキュメントなどの変更手続きもあらかじめきちんと決めておく
- バグの管理と仕様変更の管理ははっきり分け、別管理にしておく
- システム稼働開始前後数ヶ月の仕様変更は、稼働に不可欠の機能を除き、絶対禁止
組織管理
ポイント
-
プロジェクトメンバーに意欲を持って仕事を行わせるにはモラル（morale: 士気）管理が欠かせない
-
数十名、数百名に及ぶプロジェクトにおいては、メンバー間、チーム間、組織幹部や顧客との間の適切なコミュニケーションが大きな課題になる
チェックリスト
-
担当する仕事が本人や会社にとっても、社会にとっても、どれだけ重要でどんな意義を持っているかを全員にはっきり意識させる
-
チーム編成にあたっては単に技術力中心に考えるのでなく、メンバーのモラルにもできるだけ配慮する
-
プロジェクトメンバーが揃った時点で顧客のリーダーから、開発しようとしているシステムの目的やシステムの全貌、将来構想などを説明してもらう
-
プログラム開発担当の人たちも、積極的に仕様決定プロセスに参加し、設計方式についても積極的に提案を行い、顧客とも直接議論する機会を増やす
-
プロジェクトメンバー全員を集め、各サブシステムの代表者が、自分たちが何をやって何に苦しんでいるのかを説明し合うプロジェクト説明会を開催する
-
担当させている作業が終わったら次に何をやるのかを早めに示しておく（次の仕事がないと思って、仕事をペースダウンさせてしまうメンバーが出てくるため）
-
あとからプロジェクトに入ってきたメンバーには、単に設計基準を手渡すだけでなく、どうしてそういう基準を作っているのかにまで言及した教育をする
-
大事な内容については別のルートからも確かめるなどのダブルチェックをする
-
大事な連絡や決定事項は文書化が必要
-
仕事の指示をするときは、やるべき仕事と、仕事の期限をはっきり設定することは当然として、何のためにその仕事をやる必要があるのか、仕事の目的を明示する
-
逆に上位者からおおまかな指示を受けた場合、自分と上位者の間には経験や問題意識の差があるのが普通であるから、自分の理解したイメージを自分の言葉で表現して上位者に質問する
-
良い報告はサボってもよいが、悪い報告はできるだけ早くする
-
マネジャーは嫌な報告でも喜んで聞いてやらなければならないし、なんらかの見返りも必要だ。適切なアドバイスが一番望ましいが、最低限激励だけでも良い
-
悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違い
-
週報や月報は、プロジェクト終了後の反省会の資料にもなるので、大規模プロジェクトや難プロジェクトでは必ず書くようにする
-
部下やチームメンバーに週報、月報等の定期的報告を要求するなら、報告に対して、なんらかの返事やコメントを書くようにする
-
報告に必ず部下を同行する人がいるが、こういうことは極力やめたほうがよい（部下の貴重な時間が無駄であるし、自分一人でゆけば、自分のわかっていないところが明確になって勉強になる）
最後に
プロジェクトマネジメント、簡単な仕事ではありませんよね？プロジェクトでは不確実性、曖昧性が不可避であり、どうしてもドタバタっとしてしまう時が出てしまいます。そんな時は、自分ひとりの知識で戦うのではなく、「曖昧性とのたたかい」のような先駆者の残した知見を頼りに、立ち向かっていきたいものです。本書のなかには、テストや外注先との付き合い方などにも触れられていますので、興味のある人はぜひ手に取ってみてください。自分も経験が積み重なっていけば、現代のシステム開発に適した知見をまとめて本にしたいなとも思ったり。今日も一日がんばりましょう。
「知識ゼロから学ぶソフトウェアテスト」でテストの基本を学ぶ
ソフトウェア開発において切っても切り離すことのできないのが不具合（バグ）。そして、そのバグと表裏一体な存在がテスト。プロジェクトマネジメントをするうえで、テストを適切に工程へ組み込むことは非常に重要なことですが、PMがテストの中身を全く把握していないのは良くないと思い、「知識ゼロから学ぶソフトウェアテスト」を読んでみました。この本、本当に知識ゼロでも読むことができるのでお薦めです。
ソフトウェアテストの実力診断
この本は「完全無欠なソフトウェアテストは可能か？」という問いかけから始まります。そして、いかに完全なソフトウェアテストが難しいものであるかを示すために下記の演習問題が出題されます。
このプログラムでは、ユ ーザーが三つの整数を入力します。この三つの値は 、それぞれ三角形の3辺の長さを表すものとします 。プログラムは、三角形が不等辺三角形 、二等辺三角形 、正三角形のうちのどれであるかを決めるメッセ ージを印字します 。このプログラムをテストするのに十分と思われる一連のテストケースを書いてください。
いかがでしょうか。テストケースのイメージ、湧きますか？僕もこの問題にチャレンジしてみたので、参考まで三角形の判定プログラムとそのテストコードを貼っておきます。※Node.jsのMochaとChaiで書きました。
どう思いますか？これで適切にテストパターンの洗い出しが出来ていると思いますか？...残念ながら答えは「いいえ」です。例えば、僕が書いたコードだと"0, 0, 0"とユーザーが入力した場合でも、正三角形と判定されてしまいます。これは正しい挙動とは言えません。
こうして実際に自分でやってみるとテスト設計の難しさがよくわかります。やはり専任の経験あるテスト担当者がいなければ、品質を担保して製品をリリースすることは難しいでしょう。
では、次に実際にどのようなテストが行われるべきなのかを見てみたいと思います。
ブラックボックステスト
ブラックボックステストは、プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せず（見ずに）行う、というものです。本によれば、現在のソフトウェアテストの大半はこの手法が使用されているとのこと。さっそく詳細を見てみましょう。
同値分割法と境界値分析法
同値分割法
同値分割法は大きく次のような手順で進んでいきます。
- 同値分割
- 有効同値、無効同値に分類
- テストケースを書く
同値分割とは、入力領域をいくつかのクラスに分けて、そのクラスの中の値は同値とみなす行為です。先ほどの三角形判定プログラムのUIが、ユーザーが任意の値を自由に入力できるフォームであると仮定すると、「数字」「文字」「記号」というようにクラス分けできると思います。
次に、有効同値と無効同値ですが、システム仕様から見て、有効な値か無効な値かという意味です。三角形判定プログラムでは、三つの整数が求められている値ですから、有効同値が「数字」、無効同値が「文字」「記号」ということになります。
最後にテストケースを書いていきます。三角形判定プログラムは、入力値が三つの整数だけで、無効同値も2種類しかありませんので、全ての有効同値と無効同値の組み合わせの強固なテストケースが書けると思います。しかし、実際のプログラムでは、無効同値の数や組み合わせ数が多く、テストケースを作ることが困難なこともあります。その場合は、テストケースを省略せざるを得ませんが、だからと言ってバグが起きても良いわけではありません。ちなみに、僕が書いた三角形判定プログラムでは「あ、あ、あ」と入力しても正三角形と出力されます。苦笑
境界値分析法
境界値分析法は、入力領域の境界に焦点を置いてテストを行う手法です。三角形判定プログラムでは、そもそも仕様が「三つの整数」としてあるのが問題でもあるので、整数の境界に焦点を置くのはあまり良いアイディアではありません。ここは三角形が成り立つ数値か？というところに視点を切り替えるべきでしょう。そうすると、入力領域は整数の中の「正の数（1以上の数値）」となります。
では、正の数の境界はどこか考えてみましょう。下の境界は簡単ですね。0以下は正の数ではなくなります。一方、上の境界はどうでしょうか。正の数に上限はありませんので、数値はどこまでも大きくなります。しかし、システム的に処理できる数値には上限があります（JavaScriptの場合は 2^53 - 1）。なので、仕様ではどこかに上限を設定しておくべきだと思います。
実際のテストでは、異なる処理が行われる一番近い2地点を用います。三角形判定プログラムの下の境界で言うと、「0」と「1」です。この境界値分析法と同値分割法を組み合わせることで、効果的かつ効率的にテストケースを作ることができます。
ディシジョンテーブル
ディシジョンデーブルは、すべての入力の組み合わせとそれに対する出力を表にまとめたものです。三角形判定プログラムでは、数値によって、「正三角形」「二等辺三角形」「不等辺三角形」と出力結果が変わります。組み合わせの複雑になるので、それらを表に可視化することで、漏れを防ぐことができます。基本のアイディアは同値分割法・境界値分析法と同じですが、多数の入出力をチェックするときに有効な手段となります。
自分の書いたコードでやってみました。本プログラムでは、各三角形ごとの組み合わせの入力値を書いてまとめた方がわかりやすいかなと思いました。本では、状態は「TRUE」「FALSE」だけの記載でしたが、実態に合わせて臨機応変にしても良いと思います。しかしまあ散々な結果ですね。ひどい。苦笑
状態遷移テスト
状態遷移テストは、状態によって出力結果が変わる場合に用いられるテストです。どういうイベントのときに、どのように状態が遷移するかを一覧にし、各遷移をチェックしていくというものですが、この三角形判定プログラムの例では説明できそうにありません。詳細は下の記事がよくまとまっているので参考にしてください。
ランダムテスト（モンキーテスト）
これはランダムにソフトウェアを操作し、バグを洗い出すテストです。著者はこの手法に関しては、批判的な意見を持っているようで、推奨していませんでした。テスト設計の必要もないし、一定数のバグは見つかるだろうが、バグはランダムテストでは見つからないところにまだまだ潜んでいると。
以上がブラックボックステストの手法として紹介されているものでした。ソフトウェアの複雑さにもよりますが、「同値分割と境界値分析 → ディシジョンテーブル → 状態遷移テスト」は、どのソフトウェアにおいても最低限実施すべきものだと思います。ランダムテストについては、個人的にはそこにテスターの労力を割くのであれば、別のテストを実施した方が良いと思いますね。
まとめ
本では、ブラックボックステスト以外にも「探索テスト」「非機能テスト」「セキュリティテスト」などの重要なものが説明されています（詳細はぜひ本をお読みください）。月並みな感想ですが、テストの奥深さと難しさに驚きました。プログラムを書くこと以上にテストを作ることの方が難しいのではと思ったぐらいです。品質要求を満たしたプロダクト、不具合のないプロダクトを出すために必要な労力を改めて認識し、今後のプロジェクトマネジメントに活かしていきたいと思います。
マイヒーロー、イチロー
イチローの試合を観戦するために、シアトルのセイフコ・フィールドに行ってきました。が、残念ながらイチローのプレーを観ることはできませんでした。ご存知の通り、5月4日にイチローは球団の特別アドバイザーに就任し、今シーズンはもう試合に出場しないという報道が出ています。僕がチケットを取ったのは4月16日だったので、タッチの差で間に合いませんでした。僕のことをよく知る人は「あれ？そんなに野球が好きだったっけ？」と思うかもしれません。実際、野球がそこまで好きというわけではありません。ただイチローが好きでした。セイフコ・フィールドに行ってきて、高まった気持ちを胸に盛大にポエらせて頂ければと思います。
あいにくの曇り。それでも美しいセイフコ・フィールド
イチローとの出会い
そもそも野球を見ない僕は、日本でのイチローをあまり知りません。パワプロで「サクセスじゃないのにオールAに近い選手がいる」と思っていた程度です。むしろイチローは扱いづらいキャラでした。ミートが広くてパワーが中途半端にあると打ち損じが出やすいというの僕の自論です。ヒット狙いの選手はミートC、パワーCぐらいがちょうど良い。...話を戻します。
僕がイチローの試合を初めて見たのは、メジャー移籍後のオールスターゲームでした。当時の僕は中学校3年生。試合は学校の時間でしたが、野球部の同級生が「先生、お願い！イチローの打席だけ見せて！」と懇願しました。「第一打席だけだぞ」と返す先生。いま思うとこの先生も見たくて堪らなかったに違いありません（ちなみに野球部の顧問の先生でした）。そして、僕たちはイチローがランディー・ジョンソンから内野安打を打つところを目撃したのです。
イチローに興味を持つ
それから3年後、イチローはメジャーリーグの年間最多安打記録を塗り替えようとしていました。当時の僕は高校3年生。学校へ行く前にテレビを見ていたのですが、イチローのニュースは毎日取り上げられていました。しかし、はっきり言って、僕は無理だと思っていました。たしか夏休みの終わった9月中頃に、イチローは一度無安打をやってしまいます。その時、ニュースのレポーターも「これで残り◯試合で◯本、1日◯本のペースでヒットを打たないといけません。厳しくなってきました。（※はっきりと数字を覚えていないが15試合で20本ぐらいの厳しい数字だったはず）」と話していたのを覚えています。ところがどっこい、その後イチローは5打数5安打, 6打数4安打とヒットを量産して逆境をひっくり返してしまうのでした。
そしてその瞬間へ。もうね、映画ですよね、これ。鳴り止まない歓声と拍手、駆け寄るチームメイト、前記録保持者のジョージ・シスラーの娘との握手、まるでひとつのショーを見ているようです。
イチローのファンへ
僕は2004年の記録達成をきっかけにイチローのファンになったわけではありません。 ファンになるのはそれから3年ほど経ってからのこと。当時の僕は成人して、社会人になっていました。仕事は個人宅への外回りの営業職、簡単な仕事ではありませんでした。「いま天ぷら揚げているから結構です！」何度こう断られたことでしょう。「マジでこの断り文句が使われるのか」などと思いながら、毎日16時〜21時の間は外回りをしていました。
夏は暑いし冬は寒い。業務の過酷さに加えて、なかなかのブラック企業だったので、酷いときは2ヶ月間休みがないときもありました。仕事の調子の良いときは、稼げせてそれなりに楽しい仕事でしたが、調子の悪いときはかなり辛いものでした。1日誰にも話すら聞いてもらえず、インターホンで断られ続け、会社に戻ると上司に激詰めされる。「売れるまで帰って来るな！」と、電話で突き放される日もありました。そんな職場だったので、モチベーションをいかに管理するかは多くの社員の共有の悩みでした。
「トッキー、良い本があるよ。」
そう声をかけてくれて、とある人に手渡されたのが、イチロー 262のメッセージという本です。
- 作者: 『夢をつかむイチロー262のメッセージ』編集委員会
- 出版社/メーカー: ぴあ
- 発売日: 2005/03/11
- メディア: 単行本
- 購入: 12人 クリック: 143回
- この商品を含むブログ (119件) を見る
この本にはイチローがメジャーデビューから4年の間にした発言が抜粋して載せられています。特になにか解説があるわけでもなく、ただ淡々とイチローの発言が紹介されているだけなのですが、これが妙に心に刺さりました。一部を引用して紹介します。
こんなに苦しいのは自分だけか、と思うこともあります。それを見せるか見せないかだけの話です。みなさん、ぼくのことは、疲れていないと思っていませんか？
ぼくも、グラウンドに行きたくない日はたくさんあるのです。そのときには職業意識が出てきます。「仕事だからしょうがない」と、自分に言い聞かせるときもあるのです
グラウンドの上では、自分の築きあげてきた技術に対する自信、今までやってきたことに対する自信、「やりたい」と思う強い気持ちが、支えになります
僕はこの本を読むまで、イチローがこんなに苦しみながら野球をしているとは考えたこともありませんでした。メンタルをコントロールし、高いプロフェッショナル意識をもって野球と向き合うイチロー。一気にイチローのファンになりました。
それから毎日イチローのニュースを追いかけました。勝手にイチローをライバル視して、イチローがヒット2本なら、僕も2契約を取るまで頑張ろうと、仕事の目標にしたりもしました。他にも、mixiのイチローコミュニティで実況しながら試合を見たり、「Road to 4256」というトピックでイチローのヒットを皆でカウントしたりとか。ちなみに、4256とはピート・ローズが残した通算安打数のMLB記録です。当時カウントしているときは遥か先の夢のような数字でしたが、本当に達成してしまうイチローは本当に凄いです。
仕事の営業の数字に追われていた日々の中で、イチローの安打数という他に意識を置く数字ができたことは本当に救いでした。また、イチローの野球への姿勢を少しでも見習おうと心がけて仕事をすることで、自分の中にも徐々にプロフェッショナル意識が生まれてきたように思います。職業人の理想像であり続けてくれたイチローには感謝しかありません。
最後に
特別アドバイザーに就任して試合にはもう出場しないということから、事実上の引退という声も出ています。マリナーズとの契約としては、来季試合に出場する可能性は残した内容になっているそうですが、僕も来年になって第一線へ復帰するのは難しいと言わざるをえないと思います。しかし、イチローは常々50歳までプレーしたいと公言していますし、チームに帯同しての練習は続けていくそうです。現在44歳のイチロー、今後どうなっていくのか、何をしていくのか、まだまだ目が離せません。最後の最後までイチローを応援していきたいと思います。ありがとう、イチロー！
All the feels.
— MLB (@MLB) 2018年5月3日
💚 💙 #ThankYouIchiro pic.twitter.com/U5fQAx1uWW
おまけ
オバマ前大統領がイチローの話をしているこのシーンがとても好き。
I talked to Ichiro and I said, now, how exactly do you throw that ball from in the outfield to home plate like a laser? He said, "Soft muscle." He said, "You don't need to be big." it was a very zen-like answer. He's an impressive guy.
レーザービームのような送球をどうやって投げるのか？というオバマの問いに対して、「ソフトマッスルです。大きな筋肉は必要ありません。」と答えたイチロー。オバマはそれを”まるで禅のような答え”とコメントしています。オバマにさえ認められるイチロー、素敵すぎる。
後、イチロー 262のメッセージ、イチローが好きな人には本当お薦めです。 未読の方はぜひどうぞ。
- 作者: 『夢をつかむイチロー262のメッセージ』編集委員会
- 出版社/メーカー: ぴあ
- 発売日: 2005/03/11
- メディア: 単行本
- 購入: 12人 クリック: 143回
- この商品を含むブログ (119件) を見る
- 作者: 「未来をかえるイチロー262のNextメッセージ」編集委員会
- 出版社/メーカー: ぴあ
- 発売日: 2007/12/19
- メディア: 単行本
- 購入: 6人 クリック: 84回
- この商品を含むブログ (36件) を見る
