シリコンバレースーパーウエア

ホーム ブログ Firebase情報 全部やる方が簡単か？ 2021年7月29日 全部やる方が簡単か？ プログラミングの学習だけではありませんが、「全部」勉強する方が簡単です。しかし、全部勉強したとしても、全てが身につくわけではありません。実際に効果があるのは「必要なことに集中」して学習する方法です。この記事では、ポイントを絞ることの大切さについてまとめてみました。 なぜ全部やる方が簡単か？ 全部学習する方が簡単なのには理由があります。 その理由とは、「考える必要がないから」と言うのが一番の理由です。 本ならば最初から最後まで勉強すれば良いということになります。学校へ行く場合でも、学校のカリキュラムを一通り勉強すれば良いので余り考える必要がないので簡単です。 学校の場合は大抵は試験があると思いますので、ある程度の「知識」は身につくと思いますが、実際に使える物になるかは別の話になります。 試験の勉強も、試験の範囲を全部勉強する方が時間はかかりますが簡単です。 十分に時間をかけて勉強できる場合には、一通り全部を丁寧に勉強する方が確実ですし、外す可能性も低くなります。 問題は時間が無い事！ 全部やると言うのは、十分に時間をかける事ができて、一つ一つを丁寧に理解しながら進める事ができる場合には有効な方法です。 しかし、時間が限られている場合が多いのが現実です。十分な時間が無いのに全部やるのは、当たり前ですが無理があります。 十分な時間をかけずに形だけ全部やったとしても、身につくものは限られてしまうと言うのは、敢えて説明しなくてもお分かりかと思います。 試験勉強でも直前に勉強する場合は、全部やるよりはポイントを絞って勉強した方が効果が高いと言うのは経験された事があるかたも多いと思います。試験前に、試験に出そうな場所に山をかけて勉強すると言うのは、やった事がある方も多いかと思います。また、苦手な部分を重点的に勉強すると言うのも一つの方法です。 ここで、ポイントとなるのは、「出そうな箇所」や「苦手な部分」を特定しないと

ホーム ブログ Firebase情報 縄張りを作ろう！ 2021年7月28日 縄張りを作ろう！ プログラミングでも仕事でも縄張りを持つことはとても大切です。ところで、プログラミングや仕事で言う縄張りとは何でしょうか、この記事ではプログラミングや仕事で大切な縄張りについて考えてみました。 縄張りとは何か？ いつものように、最初は縄張りについて考えてみます。 一言で言えば、「自分でコントロールできる範囲」のことです。逆にいうと縄張りを出ると、自分ではコントロールできない世界があるという意味です。もの凄くシンプルな事ですが、意外に難しいことでもあります。 何故難しいかと言うと、縄張りの外に出ても自分でコントロールしようとする場合がかなりあるからです。 簡単な例で言えば、貴方が住んでいる家を考えてみてください。基本的には、自分の家ならば、中に置くものや、中に入って良い人を管理・コントロールできます。しかし、家の外に出て家の前の道路は、殆どの場合は貴方の物ではないと思います。その場合は、その道路に他の人が車を止めても文句は言えませんよね？すなわち、貴方の管理外と言うことです。 しかし、管理外にも関わらす、無理にコントロールしようとするとトラブルになります。 そう考えると、どこまでが自分の縄張りなのかをきちんと認識して置く必要があります。 縄張りを作るには、一番大切なのは、境目がどこにあるかをきちんと知る必要があります。 境目をきちんと把握していれば、境目の内側はある程度、貴方がコントロールできると言うことです。 プログラムでも仕事でも、その境目をきちんと作って取り組むとうまくいきます！ プログラミングの縄張りとは？ 最初はわかりやすいプログラミングの縄張りから考えてみます。 プログラミングをする上での境目は、「インターフェース」と呼ばれています。 大きなプログラムでは、いくつもの小さなプログラム（モジュール）からできています。 その小さなプログラムが、お互いにデータをやりとりしながら動作するように設計されます。 ど

ホーム ブログ Firebase情報 知っていると得する「役割」と「責任」 2021年7月26日 知っていると得する「役割」と「責任」 「役割」と「責任」は、知っているといろいろ便利で得することが多いものです。この記事では、何故得するのかを紹介しています。 シリコンバレーの仕事では常識！ 「役割」と「責任」は、英語では、「role and responsibility(R & R)」と言われます。 シリコンバレーというかアメリカでは、仕事にはこの「役割」と「責任」というのが、ほぼ全ての仕事に割り当てられていて、採用もこれをベースに行うのが普通です。仕事の募集要項にも、これに相当する記述が書かれているのが普通です。 簡単に言うと、「何をするのか（役割）」と「求められる成果（責任）」です。 例えば、あるプログラマの仕事の場合、 役割：XX の処理を行うモジュールの、仕様設計とコーディング、及び基本機能のテスト 責任：担当モジュールの、設計仕様書、XX の処理を行うモジュール（プログラム）、基本機能のテストプランとレポート のようになります。 これを柱にして、さらに細かい必要なスキルなどが書かれているのが普通です。 日本の採用形態の場合、ある特定の仕事に就くとうより、会社に入るという意味合いが大きいため、「役割」と「責任」を意識する機会が少ないと思います。しかし、シリコンバレーをはじめとする海外の場合、特定の仕事に対する求人という考え方が強い場合が多いので、「役割」と「責任」がとても重要になってきます。従って、意識をしないと上手く仕事に就けなかったり、仕事を獲得できないことになるので自然と意識するようになっています。 どうして、「役割」と「責任」が大切なのか？ でも、どうして？と思われる方も多いかと思います。 もちろんちゃんとした理由があるからです。 例えば、職歴や経歴を聞かれた時に、誰でも知っている「XXX の Web サイト（Web サービス）」の開発に従事したと言うとインパクトが強いので良いと思う

ホーム ブログ Firebase情報 プログラミングの実績のアピールの仕方 2021年7月26日 プログラミングの実績のアピールの仕方 仕事を受注するに当たって、「実績」は一つの評価基準です。いかに実績をアピールするかで仕事の受注も変わってきます。この記事では、実績をアピールする一つの方法を紹介します。 実績とは何か？ 最初に、実績とは何かを考えてみます。 簡単に言って仕舞えば、実際にやった成果というのが実績という事になります。 ところが、実績をアピールするという事になると、実は結構むずかしいものです。 例えば、「経験 5 年」というのが実績かというと、少し疑問ですよね？ 大切なのは、５年間で何をやってきたかという事が実は一番大切な事です。従ってこの表現だけだと、アピールされた側でも判断に困るのが普通です。 この実績のアピールは、フリーランスが仕事を受注する時だけではなく、就職活動でも必要な物の一つです。 特に英語のレジュメを書く場合には、このアピールの仕方次第で面接に辿り着けるかの明暗を分ける事の一つです。 ポイントは、今までどんなことをやってきたかを出来るだけ具体的に示すのが大切です。 具体的とはどういうことか？ そこで、今までの実績を具体的に示してくださいと言われた時、あなたならどのように示しますか？ よく見かける表現には、「XXX の開発に従事した」とか「OOO のプロジェクトに参画した」と言われる方がたくさんいらっしゃいます。具体的な開発名やプロジェクト名が挙げられているので、「具体的」に説明した様に見えるので、こうした表現を使う場合が非常に多くなっています。 実は、「XXX の開発」とか「OOO のプロジェクト」というのは、「場所」を示しています。大切なのは、その中（場所）で「あなた」が「何」をして「どうなったか（結果）」です。これを、きちんと表現して、初めて具体的に示す事になります。 これを、アメリカでは「役割と責任（Role and Responsibility）」と呼んでいます。これに、

ホーム ブログ Firebase情報 ドキュメントをいつかくか？ 2021年7月25日 ドキュメントをいつかくか？ プログラム開発でドキュメントが必要なのは既にいくつかの記事で書いてきました。この記事では、いつドキュメントを書くのが良いのかを考えてみました。 ドキュメントは後回しになりがち！ 会社などでの開発は、開発の「プロセス」があるので、ドキュメントを作成するタイミングは基本的に決まっています。 特に、複数の人で開発する場合は、ドキュメントを基にした開発というのが基本なので、ドキュメントは、実際にコーディングに着手する前に作成するのが普通です。 ところが、フリーランスでプログラムを開発する場合、一人で開発する場合が殆どなのでドキュメントが無くてもコーディング上はドキュメントが無くても進めることは可能なので、ドキュメントの作成は後回しになる場合が多いようです。仕事の中心がコーディングだと考えている場合も多くドキュメントの作成はどうしても二番目以降になってしまいます。 会社では、何故ドキュメントを先に作るのか？ では、会社ではなぜ最初にドキュメントを作成するのかを考えてみましょう。 幾つか理由がありますが、ここでは二つの大きな理由をあげてみました。 全体の設計と仕事の割り当てをするため 各モジュールのインターフェースの明確な定義 当たり前ですが、全体の設計をしないと仕事の割り当てができません。会社では多くの人が一つの大きな開発に参加するのが普通です。そのために、まずは全体の設計をして、どのよう仕事の分担を決めます。また、全体の機能が明確になるので、テストの計画の開発もプログラムの開発と同時に進める事ができます。 また、各モジュールの設計をするのに必要なインターフェースを明確にして、モジュールの設計が勧められるようにするという重要な役割もあります。 チームで開発をする場合には、こうした全体の「プラン」が必要なのは言うまでありません。 では、フリーランスの開発の場合はどうでしょうか？ 一人で開発する場合は、そ

ホーム ブログ Firebase情報 プログラムの詳細のドキュメントは必要か？ 2021年7月22日 プログラムの詳細のドキュメントは必要か？ プログラムを開発する場合、ドキュメントが必要なのは言うまでもありません。プログラムの中身をどのように作るかを詳しく書いたドキュメントいわゆる、設計仕様書は必要でしょうか？この記事では設計仕様書の考え方についてまとめてみました。 プログラムの設計仕様書とは？ 最初に、プログラムの設計仕様書とは何かをハッキリさせておきましょう。 これは、プログラムを「どのように作るか（作ったか）」を各ドキュメントです。 プログラムは将来的にも不具合の修正や機能拡張などで、手を入れることも多く、実際にコーディングをした設計者でもその中身の詳細を覚えていることは難しくなります。多くの場合は、最初のコーディングをした人と別の人がプログラムに手を入れる事も多いので、プログラムがどのように作られているかを書いたドキュメントがないと、コードを読みながら理解して修正する事になるので効率が悪くなります。従って、きちんと設計仕様のドキュメントを残すことはとても重要です。 操作の説明（取り扱い）のドキュメントは、利用者のためのドキュメントですが、設計仕様書の場合は、プログラマーのためのドキュメントという事になります。従って、内容は専門的で問題ありませんが、プログラムがどのように作られているかを分かりやすく書く必要があります。 操作の説明と詳しい設計仕様はどっちが大切？ 会社などでプログラムを開発する場合は、操作の説明のドキュメントも、設計の仕様書も両方きちんと作ることが求められます。当然と言えば当然ですが、フリーランスの場合は、短期間での開発を求められる場合も多く、時間との兼ね合いで両方作成する時間がない場合もあります。 その場合は、どちらのドキュメントが大切かというと、個人的には「操作の説明のドキュメント」だと思います。 理由は簡単で、前回の記事で説明した通り、この操作の説明は、利用者だけではなく、プ

ホーム ブログ Firebase情報 プログラムのドキュメントの書き方 2021年7月21日 プログラムのドキュメントの書き方 プログラミングを仕事として行う場合、プログラミングのドキュメントは必須の物の一つです。趣味でプログラムを作るのとは違って、いろいろな人が作成するプログラムに関わってきます。作成するプログラムがどんな物なのかをプログラムを作った人以外の人が理解するのにドキュメントは重要です。 どんなドキュメントが必要か？ 会社などでプログラムを開発する場合、沢山のドキュメントが作成されます。 基本的に、割り当てられた仕事毎に幾つか必要なドキュメントがあります。 殆どの仕事には、「入力（インプット）」と「出力（アウトプット）」があります。 その仕事を進めるために必要な情報が「入力（インプット）」で、仕事の結果（成果）が「出力（アウトプット）」になります。プログラムを作る場合の入力は、「どんな機能が必要か」が入力（インプット）になります。この入力の情報に基づいて「どんなプログラム」を作るかが、プログラムを設計する人の出力（アウトプット）になります。 多くの場合、仕事と仕事を繋げる役割をするのが、ドキュメントになります。 従って、一つのプログラムの開発プロジェクトの場合でも、沢山のドキュメントが必要になります。 利用者の要望、意見、フィードバックをまとめたもの 実際のプログラムの要求をまとめた物 実際のプログラムで実現する機能や方法（やり方）をまとめたもの プログラムの使い方をまとめた物 プログラムのテストの方針をまとめた物（テストプラン） プログラムのテスト結果をまとめた物（テストレポート） など基本的なものだけでも結構な数になります。 当然ですが、作成するドキュメントによって書き方も内容も大きく変わってきます。 この記事では、プログラムを作る人が作成するドキュメントで特に大切な「プログラムの使い方」をまとめたドキュメントに絞って考えてみます。 誰が使うドキュメントか？ プログラムの使い方をまとめたド

ホーム ブログ Firebase情報 手抜きができれば一流！ 2021年7月20日 手抜きができれば一流！ 何かやる時に時間がなかったり、早く終わらせたいときは「手抜き」をする事があります。実は、手抜きが出来るという事は一流の証です。この記事では手抜きについて書いてみました。 手抜きとは何か？ 最初に、まず「手抜き」とは何か考えてみてください。 実際に説明しようとすると意外に上手く説明できないものです。 手抜きとは、「やることを省いて短時間で簡単に終わらせる」ということです。ポイントは二つです。 やることを省く 終わらせる です。原理も簡単です、「やる事が少なくなるので早く終わる」という事です。至ってシンプルで簡単ですよね。 特に「終わらせる」というのが最重要のポイントです。やり方や結果は別として、きちんと終わらせるというのが「手抜き」です。つまり、終わらない（完了しない）場合は手抜きになりません。 やる事を省くのは必須、でも難しい！ 手抜きに対する取り組み方は、「丁寧にやる」ということになるかと思います。 当然、丁寧にやった方が、より高い品質（クオリティ）の結果が得られるのが普通です。 しかし、丁寧にやるということは、やることも多くなりますし、より細部まで拘って実行することになるので、時間がかかります。 手を抜く一番の理由は、「短時間」で「終わらせる（完了させる）」のが一番の理由です。 従って、やる事を選ばないとできません。 ところが、何をやる場合でも、やる事はたくさんあります。また、「やった方が良いこと」もたくさんあります。手を抜く場合に大切なことは、やる事を二つに分ける事です。 絶対にやらなければいけないこと できれば、やった方が良いこと（つまりやらなくてもなんとかしてなること） です。ところが、このやる事を洗い出して、この二つの分類に分けることは簡単ではありません。 「目的」がよくわかっていないとできません。しかも、やる事を厳選して絞り込まないと、短時間で簡単に終わらせることができません。 手抜き