【非エンジニア・QA向け】なんちゃってQAのススメ - Qiita
本記事はGoodpatch Advent Calendar 2016 の20日目の記事です！ Goodpatchで唯一QAの肩書をいただいているenpipiと申します。 普段は社内SEとして活動しておりますが、Prottの大幅な改修時などスポットでQAとして参加しています。 専任のQAがいれば良いのですが、ディレクターや手が空いている人がQA的なことをしているチームも多いのではないでしょうか。 本記事では、非エンジニア・QAに向けた簡単なQAのコツについて紹介します。 スタンスの話 QAは、平たく言えばサービスの品質に責任をもつ仕事です。 しかし、片手間でQAをやる場合や専任じゃない人に同じ責任を求めるのは酷です。 バグを絶対に出さないと意気込むよりも、エンジニアがやらなくても良い仕事を引き受けて、開発に集中してもらう環境を作るくらいで考えている方がモチベーションを保てると思います。 テス
使いにくいアプリ・ウェブサイトの原因である「認知的負荷」を削減するためのデザインの基本原則
by Nicola Albertini ウェブサイトやアプリを初めて使うとき、私たちは無意識のうちにコンテンツをどのように操作するのか、つまり、「タップするのか」「スライドするのか」「メニューはどこか」といったことに頭を働かせています。初めてのコンテンツを操作するにはさまざまな情報を一時的に記憶する必要があるのですが、この時、タスクが多すぎて一度に記憶を保てる容量の限界を超えてしまうと、人は「よくわからない」と、ウェブサイトやアプリの使用を途中でやめてしまいます。処理するタスクが多すぎることを「認知的負荷が高い」と言いますが、ウェブサイトやアプリを作る上でこの「認知的負荷」をできるだけ少なくする基本原則が、ウェブデザイン作成サービスMarvelのブログで公開されています。 Design Principles for Reducing Cognitive Load - Marvel Blog
「問題文を読んでもそこに何が書かれているのかわからない」子を教えていた時のお話
この記事を読んで、昔塾講師やら家庭教師やらを掛け持ちしていた頃のことを思い出しました。 AI研究者が問う ロボットは文章を読めない では子どもたちは「読めて」いるのか？ これまでのところ、テストを受験した公立中学校生340人のうち、 約5割が、教科書の内容を読み取れておらず、 約2割は、基礎的な読解もできていない ことが明らかになってしまった。 以前Books&Appsさんに寄稿させて頂いた記事でも触れたんですが、塾講師を「出来る子をもっと伸ばす」人と「出来ない子をなるべく救い上げる」人に分けたとしたら、私はもっぱら後者でした。 で、私が塾講師をやっていた頃も、「問題文を読解する」という段階で苦戦する子は何人もいました。 手前みそですが、上記記事からの引用です。 塾講師時代、子どもの「勉強わからない」に対処するうちに学んだこと 国語で印象に残っているのは、「そもそも数行以上の文章を、意味を
原稿の推敲・校正・リライトを支援する8つの文章チェックツールを作りました！ - ときまきドッペル！
お久しぶりです。タロットプロット広報担当の海鳥まきです。このたび、タロットプロットに8つの文章チェックツールを追加しました。 原稿の推敲・校正・リライト作業を支援するためのツールです。お役に立てるかどうかは分かりませんが、なかなかに面白いものができました。 （※記事投稿時は3種類でしたが、その後ツールが5つに増え、さらに8つに増えました！） 原稿チェックマーカー4種 1.「リライトマーカー」多用・乱用しがちな文章表現をハイライト 文章推敲支援ツール「リライトマーカー」 リライトマーカーは、主にWebライターの方向けのリライト支援ツールです。 テキストボックスのなかに文章をコピー&ペーストするだけで、注意すべき表現に赤色マーカーをつけてくれます。（上記画像をご参照ください） 画像中では「こと」や「もの」といった単語がハイライト表示されています。「～すること」「～するもの」は得てして抽象的な表
なぜプロジェクトは炎上するのか？炎上しやすい4つの傾向と、炎上を防ぐ3つの対策 - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
「誰がこんなネーミングにしたんだ……。」プログラミングのネーミングルールを決める時に参考にしたい情報まとめ
サイトのメンテナンスにおいてしばしばネックになるのは、どんなネーミング・構成で制御しているのか分からなくなってしまうことです。しっかりと基準に則った、誰がいつ見てもわかりやすいネーミングでコーディングしていくことは、非常に重要なことです。 今回は、プログラマーがネーミングを考える際に参考にしたいサイトを選んでご紹介いたします。 1. codic - プログラマーのためのネーミング辞書 https://codic.jp/ 様々なサイトに紹介され、「ネーミング」で検索しても上位に表示される素晴らしいツールです。例えば、Webサイトの背景に動画を設置する際に、class名をどうしようか悩んだとします。そこでcodicに「背景動画」と入力すれば「background_videos」と提案してくれます。提案されたネーミング以外にも、その他の候補も出てきます。 考える労力を省くことができるという点で優
今さら聞けない、変数や関数の命名規則と、まず覚えるべき英単語200
（Wikipediaより） ハンガリアン記法のメリット 論理型であるbFlagと、文字列型であるsNameが bFlag + sName となっていれば誤りであることがわかる。 型の記述が2文字程度で済むので、変数名が短く済む。 ハンガリアン記法のデメリット 暗黙の型変換ができない。変数の型を変更するごとに変数名まで変更しなくてはならず、命名法に添って名前を付けるのが面倒。 （同じユーザーIDでも使い方によってはsUserid、iUseridなど） キャメル記法 文字のラインが凸凹になる様をラクダのこぶになぞらえてキャメル記法と名付けられた。 大文字小文字を区別する言語と区別しない言語があるので使う場合は全体を統一すること。 先頭の文字を大文字にするか小文字にするかで2つのパターンがある。 アッパーキャメルケースまたはパスカルケース（1単語目から大文字） 悪い例 $userparamete
IT芸人が訊く、おっさんエンジニアが“老害”にならないために（後編） | HRナビ by リクルート
増井さんが「今、気になる人」に直撃する新連載。「スタートアップにベテランエンジニアが加入した影響」をテーマに、Incrementsの海野弘成社長と語った前編の続きです。後編はIncrementsに2016年5月に入社したベテランエンジニア、田中洋一郎さんも交えて、「ベテランと若い会社の上手な付き合い方」について語りました。 IT芸人が訊く、なぜ優秀なおっさんエンジニアを次々と採用できるんですか？（前編） おっさんが“老害”にならないために （前編からの続き。増井さん、田中さんを連れて会議室に戻ってくる） 増井：洋一郎さん、お仕事中に突然声かけちゃってすみません（笑） 田中：大丈夫だけど、僕なんで呼ばれたの？（笑） 増井：今、海野さんに「若い会社におっさんが入ったことによって、どんな変化が起こったか」という話を伺っていたんですよ。それで、せっかくだから“入社したおっさん側”の話も聞きたいな、
IT芸人が訊く、なぜ優秀なおっさんエンジニアを次々と採用できるんですか？（前編） | HRナビ by リクルート
変化の激しいエンジニアの世界で、どうすれば成長し続けられるのか。飲食店向け予約台帳アプリを手がける「トレタ」の増井雄一郎さんが、そのヒントを解説する連載がリニューアルしました。今回からは、「IT芸人」の異名を持つ増井さんが今、気になる人に直撃。エンジニアとしてのキャリアパスや最新のテクノロジーなどについてインタビューします。 今回登場いただいたのは、プログラマ向け技術情報共有サービス「Qiita」を運営するIncrementsの海野弘成社長。同社には昨年11月、元グーグルの及川卓也さんが入社、その前後にも著名なエンジニアがジョインしています。なぜ、いちベンチャー企業が次々と優秀なエンジニアを獲得できたのかーー海野さんに聞きました。 ※後編はこちら IT芸人が訊く、おっさんエンジニアが“老害”にならないために 平均年齢20代の会社に40代が入社……摩擦はなかった？ 増井：海野さん、今日はよろ
視覚障がい者が仕事をする上で感じる課題～暇すぎるという問題 | セキュリティ対策のラック
7/10に、私が個人的に参加している、視覚障がい者団体BLPC主催の「働く視覚障がい者の情報交換会」に運営スタッフとして参加してきました。視覚障がい者が仕事をする上で感じている課題等について、参加者の方＆スタッフでディスカッションを行いました。その中から個人的に白熱したと思う内容をいくつか紹介してみたいと思います。「視覚障がいがあるとそういうところで困るのか」くらいに頭の片隅に入れておいていただけますと幸いです。 1.漢字って難しい この記事の文章自体そうですが、メールを打つにしろ、オフィスソフトを使って資料を作るにしろ、日本語で文章を書く以上、漢字は避けて通れません。視覚障がい者の内、全盲（視力がほぼ0）の場合、このブログでも何度か取り上げている、スクリーンリーダー（画面読み上げソフト）を利用するのが一般的です。スクリーンリーダーを使うことで、たとえば以下のような内容で漢字変換についても
わかりやすさの技術 - やしお
社内向けの教育資料を、ど素人でもわかるようにと思いながら作っていて、じゃあ「わかりやすい」って何だろうって考えてた。今まで読んできたいろんなわかりやすかった本とそうでない本を思い浮かべながら、一般的にここを注意すればわかりやすさを確保できるだろうっていうポイントを一旦まとめておこうと思った。そうしてまとめてみると、本に限らず人に何かを伝えること一般に適用される話だなと思った。 読む側の負担を減らす わからない＝理解をはばむ障害物がある。この障害物を取り除く／回避する作業が「わかる」ために必要になる。その作業を、作者ではなく読者が負担するとき「わかりにくい」本になる。 日本社会だと情報の受け手の側がこの「わかる」ための作業を負うことでコミュニケーションを成立させる傾向にある。空気を読むというようなことだ。そのため発信者側が事前に手を尽くしてわかりやすく発信するというのが苦手で、相手が汲み取っ
40歳になってようやくわかる8つのこと。
40歳前後の人に話を聴くと「40歳は人生の転機なのだな」とつくづく思う。つまり「ようやく自分のことがわかる歳」が40歳だ。 孔子は「四十にして惑わず」と言ったが、自分のことがわかれば、惑うこともないのだろう。 40歳は、会社の中で出世ができるかどうかが、ある程度見える 40歳は、会社内での評価はほぼ固まっている時期だ。この時期に高評価を受けていなければ、部長、役員になれる見込みはない。 ヒラ社員や課長に徹するか、それとも一念発起して独立するか、新天地を見つけるべく努力するか。いい加減、40にもなれば決めなければならない。 これ以上先送りできないのが、40歳だ。 40歳は、自分の苦手なことと得意なことがわかる 40歳ともなれば、自分の得意なことと不得意なことはわかっている。今更不得意なことに手を出しても、卓越することはできない。 若い時は時間を投入することで克服できたことも、体力の低下で無理
実力以上の給料を受け取っている時、気をつけるべきこと
これも、昔の先輩に教えてもらった話。よく憶えている。 その日は、ある大手企業のコンサルティングに行った後、近くの喫茶店で振り返りのミーティングをしていた。 先輩は、私に問いかけた。 「今日のメンバーの中で、一番優秀だと思ったのは誰だ？」 「リーダーのYさん…ですかね。彼の意見は非常に的確で、他の方と視点が違っていると感じます。」 「当たり。」 「ありがとうございます。」 だが、先輩の次の質問は、想定していなかった。 「じゃ、もう一つ聞くけど、一番給料が高いのは誰だと思う？」 「給料……？」 「そう、給料。」 「……一番優秀な人だと思いますから、リーダーのYさんですか？」 「本当にそう思う？」 私はあの部屋にいた人物を思い浮かべた。 リーダーのYさん、その脇に「メンバー」として年配の方が一人、Yさんと同年代の方が3名、若手が2名いた。彼らの発言を思いだす。 若手の一人はなかなか良い議論をして
「この仕事をやる意味は？」に誰も答えられなくなる。
ある会社で、後輩が先輩に 「この仕事をやる意味を教えて下さい。なぜ必要なのでしょう？」 と言っていた。 おそらく、単調でつまらない仕事をやれ、と言われたのだろう。「とりあえず意味がほしい」という様子だった。 ところが先輩は 「オマエになんでそんなことをいちいち説明する必要があるのだ。なぜ必要かだと？会社員で、給料をもらっているからだ。」 と言った。 後輩は諦めた様子で、仕事に取り掛かった。 ——————————– この話を他の方にすると、2通りの反応がある。 「酷い先輩だな。きちんと理由も説明しないと、後輩のモチベーションが下がるし、仕事の意味がわからなきゃ、工夫もできないじゃないか。」 という後輩に同情する方と、 「まあ、当たり前だな。会社員ならつべこべ言わずに、言われたことをまずやらなけりゃダメだ。大体仕事の意味なんて教えてもらうものじゃなく、自分で見出すものだ。」 という先輩派だ。
米マイクロソフト本社で目の当たりにしたビル・ゲイツの決断力
６月１日発売の『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』には、いくつかマイクロソフト時代のエピソードが書かれていますが、これもその一つです。この「シカゴ対カイロ」の社内抗争はマイクロソフト時代の思い出の中でも、筆頭のものです。 ◇ ◇ ◇ ビル・ゲイツの意思決定は光速 ビル・ゲイツが仕事で重要視していたのは、＂光速＂と言っても過言ではない迅速な意思決定です。これについては、どのくらい迅速だったかを象徴するエピソードを紹介します。 あれは忘れもしない1995年1月、シアトルの冬らしい小雨の降る昼下がりのことでした。米マイクロソフト本社内にはＯＳの開発に関する派閥争いがありました（ＯＳとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。＂カイロ＂というグループと＂シカゴ＂という
自前で技適を取得し、中華の安価なBluetoothモジュールを使って製品を作る方法
TechBlogをご覧のみなさん、こんばんは。Cerevoにて電気設計を担当している馬橋です。 製品に無線機能を実装するにあたり、電波の送受信を自前で設計するのはいささかハードルが高いものです。こういう場合に、Wi-FiやBluetooth、ZigBeeなどの機能があらかじめ小型基板にまとまっているモジュールを利用することで、開発を簡略化することができます。最近ではnRF51822を使ったモジュールがまるっとmbedに対応していたりと、非常に扱いやすくなりました。 一方で、海外製(特に中国)の超安価な無線モジュールでは、国内の技術適合証明（以下、略称として技適と呼ぶ）を受けていないものがほとんどです。当然ですがこれをそのまま組み込んで使うわけにはいきません。また、モジュールでさえ大きい、あるいは機能的にちょうど良いモジュールがないという場合に、電波の送受信を行なう回路を自作することになりま
安倍政権の政策に背を向けるIT業界、問題是正は元から絶たなきゃダメ
「我々の業界は、企業や社会のインフラを担う重要な産業だ」。大手SIerの経営者らが好んで用いるフレーズだが、私はどうも気に食わない。「なに因縁を付けているんだ」と言われるだろうが、この言葉には欺瞞の匂いがプンプンする。もちろん情報システムが、企業や社会の重要なインフラであることはアグリーだ。だが「IT業界を重要な産業」というのは、ある種の免罪符にすぎない。 免罪符というのは、多重下請け構造による賃金格差を温存し、長時間労働を常態化させていることに対する免罪符である。「どこの後進国の話だ」と思うほど前近代的な環境に技術者を放り込んでおきながら、社会インフラを担う重要な産業と自らを位置付けることで「仕方がない」と居直る。居直るというのは言い過ぎかもしれない。SIerの経営者も少しは後ろめたいだろうから、そう言うことで自己欺瞞を図っているのかもしれない。 前近代的なIT業界でいうところの重要なイ
ドキュメントの継続的な開発方法 | IIJ Engineers Blog
私はソフトウェア開発を主体とするエンジニアで、 クラウドサービスの開発・運用 分散処理技術の検証とサービス利用の検討 社内の開発支援環境の開発・運用 などの業務に従事していますが、今回の記事は業務とは直接的な関係は無く、私が会社で勝手自発的に行っている取り組みについて書きたいと思います。 昨今、インターネットは生活に深く浸透し、クラウドサービスを利用することで安く簡単にWebサービスを開発、公開できるようになりました。Web技術の進化や流行の移り変りも非常に激しく、既存サービスの機能追加や新規サービスの開発は頻繁に行われています。それは弊社も例外ではありません。 このような開発の現場では、リーンソフトウェア開発への取り組みなど開発手法の最適化が積極的に行われ、様々なベストプラクティスが生みだされています。それらのベストプラクティスには、 継続的インテグレーション や 継続的デプロイメント
「組織的負債」を貯めないための、プログラマの哲学によるチームのマネジメント術 | Social Change!
プログラマの世界には「技術的負債」という言葉がある。ソフトウェアを開発していく中で、時間がなくて妥協したり、技術力が足りなかったりして、適当に作ってしまった部分が、後々になって不具合を引き起こしたり、改修にかかるコストをあげたりすることを言う。 後になればなるほど、悪影響が大きくなることから負債と喩えられる。そんな技術的負債と同じように、組織やチームのマネジメントでも、後になればなるほど悪影響が出てくるような「組織的負債」とも言えるような現象が起きてしまうことがある。 本記事では、私たちソニックガーデンで「組織的負債」を貯めないようにチーム経営してきた経験をもとに、プログラマの哲学を応用したマネジメント術について書いた。（今回の記事では「である」調にしてみた） 技術的負債と組織的負債の生まれる背景 技術的負債が生まれるのは、スタートアップの初期段階に多い。その時期は得てして、経験豊富な技術
使いやすいアプリを作る簡単な方法
使いやすいアプリを作るための、とても簡単で、確実な方法があります。 それは、ユーザの問い合わせに対応することです。具体的に言うと、問い合わせが気軽にできるようなUIにして、そこで得た情報源を元にUIを分かりやすく改良していく。(機能追加とはまた別の話) ただ、直感的に感じるように、これは手間がかかるのでたくさんの人は逆のことをしようとする。つまり、ユーザヘルプを設置して、問い合わせ先は出来るだけ発見しにくい洞窟の奥深くに設置する。 でも、問い合わせには、アプリの利便性向上につながるヒントが豊富に隠されています。ユーザがどんな問題やニーズを持っているかのヒントもザックザック出て来ます。ザックザックです。 アプリ開発にとって、やったことがいい事は星の数ほどあって、そのどれもをやろうとすると時間やお金がいくらあっても足りません。だから、”やったほうがいい事”の優先順位は常に意識して、メリットとそ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
